Haavatavuste kõrvaldamise SLA-d NIS2 ja DORA kontekstis

2026. aasta alguses, teisipäeva hommikul kell 08:17, saab kiiresti kasvava fintech-ettevõtte infoturbejuht Anna esimese sõnumi enne, kui kohv on lõpuni joodud.

SOC on tuvastanud aktiivse ärakasutuse arutelud seoses kliendile suunatud API-lüüsi haavatavusega. Arendus ütleb, et paik on olemas, kuid riskantne, sest lüüs paikneb maksetöövoogude ees. Vastavusjuht edastab riikliku pädeva asutuse ametliku päringu, milles nõutakse tõendusmaterjali „haavatavuste käsitlemise ja avalikustamise“ kohta ning tõendeid selle kohta, et protsess on viimase 12 kuu jooksul olnud tõhus. Hankeüksus lisab kolmanda probleemi: lüüsi haldab MSP ja lepingus on kirjas üksnes, et teenuseosutaja rakendab „turvauuendusi õigeaegselt“.

Kell 09:00 ei ole see enam ainult paikamise küsimus. See on ISO/IEC 27001:2022 tõendusmaterjali küsimus, NIS2 küberhügieeni küsimus, DORA IKT-riski juhtimise küsimus, tarnijajuhtimise küsimus ja potentsiaalselt ka intsidentidest teavitamise küsimus, kui ärakasutus mõjutab teenuse järjepidevust või isikuandmeid.

See on praktiline vastavuslünk, millega paljud organisatsioonid 2026. aastal kokku puutuvad. Neil on skannerid, juhtpaneelid, piletid ja paikamistööriistad, kuid nad ei suuda auditiküsimustele selgelt vastata:

• Kes kinnitas kõrvaldamise SLA?
• Kuidas on SLA riskipõhine?
• Mis juhtub, kui kriitilise paiga tähtaeg ületatakse?
• Kuidas prioriseeritakse internetile avatud varad?
• Kuidas kohustatakse tarnijaid järgima samu tähtaegu?
• Kus on paikamata süsteemi riski aktsepteerimise kirje?
• Milline tõendusmaterjal tõendab, et kontrollimeede toimis, mitte ainult ei eksisteerinud?

Vastus ei ole järjekordne tähtaegade tabel. Haavatavuste kõrvaldamise SLA-sid tuleb hallata elava kontrollisüsteemina, mis seob vara omamise, haavatavuste skoorimise, ohuteabe, muudatuste juhtimise, tarnijate SLA-d, erandite käsitlemise, seire, intsidentidele reageerimise ja juhtkonna läbivaatuse.

Siin muutuvad kasulikuks Claryseci ettevõttetasandi haavatavuste ja paikade halduse poliitika (VPMP), VKE-dele mõeldud haavatavuste ja paikade halduse poliitika (VPMP-SME), kolmandate osapoolte ja tarnijate turbepoliitika VKE-dele (TPSSP-SME), Zenith Blueprint (ZB) ja Zenith Controls (ZC). Koos muudavad need nõude „paigake kiiremini“ kaitstavaks juhtimisprotsessiks, mis peab vastu ISO, NIS2, DORA, GDPR, NIST ja ISACA-laadsele auditikontrollile.

Miks muutusid haavatavuste kõrvaldamise SLA-d juhatuse tasandi tõendusmaterjaliks

Haavatavuste kõrvaldamist käsitleti varem IT-hügieeni mõõdikuna. 2026. aastal on see pigem reguleeritud talitluspidevuse kohustus.

NIS2 muudab küberturbe juhtkonna vastutuse küsimuseks. Oluliste ja tähtsate üksuste juhtorganid peavad küberturbe riskijuhtimismeetmed heaks kiitma, nende rakendamist jälgima ning saama koolitust, et mõista riske ja turbetavade mõju teenustele. NIS2 Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, sealhulgas riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist hankimist ja hooldust, haavatavuste käsitlemist ja avalikustamist, küberhügieeni, koolitust, juurdepääsukontrolli, varahaldust ja autentimist.

Finantsüksuste jaoks on DORA spetsiaalne operatsioonilise toimepidevuse raamistik. See nõuab IKT-riski jaoks juhtimis- ja kontrollikorraldust, mille raames juhtorgan määratleb, kinnitab ja jälgib IKT-riski juhtimist ning jääb selle eest vastutavaks. Samuti nõuab see IKT-varade ja sõltuvuste tuvastamist, kaitse- ja ennetusmeetmeid, nagu paikamine ja muudatuste juhtimine, IKT-ga seotud intsidentide haldust, digitaalse operatsioonilise toimepidevuse testimist ning IKT kolmandate osapoolte riskijuhtimist.

Praktiline mõju on märkimisväärne. Paikamise tähtaja ületamine võib viidata järgmiste valdkondade tõrkele:

• juhtimine, kui juhtkond ei ole riskipõhiseid SLA-sid kinnitanud;
• varahaldus, kui mõjutatud süsteemi omanik ei ole teada;
• muudatuste juhtimine, kui erakorralist paikamist ei kontrollita;
• tarnijahaldus, kui teenuseosutaja tähtajad on ebamäärased;
• intsidentidele reageerimine, kui ärakasutuse märke ei hinnata;
• tõendusmaterjali haldus, kui piletid ja logid ei tõenda sulgemist;
• riskikäsitlus, kui erandeid ei kinnitata ega vaadata läbi.

ISO/IEC 27001:2022 annab juhtimissüsteemi selgroo. Punktid 4.1 kuni 4.3 nõuavad, et organisatsioon mõistaks sisemisi ja väliseid asjaolusid, huvitatud osapoolte nõudeid, õiguslikke ja lepingulisi kohustusi ning liideseid teiste organisatsioonidega. Punktid 6.1.1 kuni 6.1.3 nõuavad riskihindamist, riskikäsitlust, kohaldatavusdeklaratsiooni (SoA) ja riskiomaniku heakskiitu jääkriskile. Punktid 9.1, 9.2, 9.3, 10.1 ja 10.2 nõuavad seiret, siseauditit, juhtkonna läbivaatust, pidevat täiustamist, parandusmeetmeid ja säilitatavat tõendusmaterjali.

Lihtsalt öeldes: kui soovite, et haavatavuste kõrvaldamise SLA-d oleksid auditiks valmis, peavad need olema osa infoturbe juhtimissüsteemist, mitte pelgalt DevOpsi mõõdik.

SLA mudel, mida audiitorid ootavad

Haavatavuse kõrvaldamise SLA peab vastama kolmele küsimusele:

1. Kui kiiresti peame tegutsema?
2. Kes vastutab?
3. Milline tõendusmaterjal tõendab tulemust?

Haavatavuste ja paikade halduse poliitika määratleb praktilise lähtekoha riskipõhiste kõrvaldamistähtaegade jaoks:

Organisatsioon peab klassifitseerima kõik tuvastatud haavatavused standardiseeritud metoodika alusel (nt CVSS v3.x) ja rakendama kõrvaldamistähtaegu, mis on kooskõlas ärikriitilisusega: 5.2.1 Kriitiline (CVSS 9.0–10.0): viivitamatu läbivaatamine; paikamise tähtaeg maksimaalselt 72 tundi. 5.2.2 Kõrge (7.0–8.9): reageerimine 48 tunni jooksul; paikamise tähtaeg 7 kalendripäeva. 5.2.3 Keskmine (4.0–6.9): reageerimine 5 päeva jooksul; paikamise tähtaeg 30 kalendripäeva. 5.2.4 Madal (<4.0): reageerimine 10 päeva jooksul; paikamise tähtaeg 60 kalendripäeva.

See punkt on tugev, sest eristab reageerimisaega paikamise tähtajast. Kõrge tõsidusega haavatavus ei tohi jääda kuueks päevaks märkamata ja saada paigatud alles seitsmendal päeval. Reageerimisaeg kinnitab esmase hindamise, omamise, mõjuhindamise ja kõrvaldamise kavandamise. Paikamise tähtaeg kinnitab tehnilist sulgemist või heakskiidetud erandit.

Väiksemate organisatsioonide jaoks kasutab VKE-de haavatavuste ja paikade halduse poliitika lihtsamat, kuid endiselt auditeeritavat sõnastust:

Kriitilised paigad tuleb rakendada 3 päeva jooksul pärast avaldamist, eriti internetile avatud süsteemide puhul

Ja laiema paikamiskeskkonna kohta:

Kõik muud paigad tuleb rakendada 30 päeva jooksul, välja arvatud juhul, kui dokumenteeritud on kehtiv erand

Asi ei ole selles, et iga organisatsioon peaks kasutama identseid tähtaegu. ISO/IEC 27001:2022, NIS2 ja DORA toetavad kõik proportsionaalsust. Oluline on, et kõrvaldamise SLA-d oleksid määratletud, kinnitatud, riskipõhised, seiratud ja tõendatud.

Siin ebaõnnestuvad paljud ettevõtted. Nad määratlevad SLA, kuid ei määratle tõendusmaterjali. Audiitori vaates on poliitika ilma tegevuskirjeteta lubadus, mitte kontrollimeede.

Vara omamine on varjatud sõltuvus

Skanner võib öelda, et serveris esineb CVE. See ei saa öelda, kas server toetab kriitilist makseprotsessi, talletab eriliigilisi isikuandmeid, ühendub arveldusteenuse pakkujaga või on planeeritud kasutuselt kõrvaldamiseks.

See kontekst tuleb varahaldusest, andmete klassifitseerimisest, tarnijate registrist ja riskihindamisest.

ISO/IEC 27001:2022 lisa A kontroll 8.8 „Tehniliste haavatavuste haldus“ on keskne, kuid see ei toimi üksi. See sõltub tugevalt konfiguratsioonihaldusest, muudatuste juhtimisest, tarnijate seirest, pilveteenuste juhtimisest, logimisest, seirest ja riskikäsitlusest.

NIST CSF 2.0 väljendab sama probleemi tulemuspõhises keeles. GOVERN-funktsioon eeldab, et õiguslikud, regulatiivsed ja lepingulised küberturbenõuded on mõistetud ja hallatud, riskivalmidus ja riskitaluvus on dokumenteeritud, rollid ja ressursid määratud ning küberturbepoliitikad kehtestatud, rakendatud, läbi vaadatud ja ajakohastatud. IDENTIFY tulemused hõlmavad riistvara, tarkvara, teenuste, süsteemide, andmete ja elutsükli registreid koos haavatavuste tuvastamise, riskianalüüsi, erandite halduse ja haavatavuste avalikustamise protsessidega.

Anna teisipäevahommikuses stsenaariumis on esimene tehniline küsimus: „kus asub haavatav komponent?“ Esimene juhtimisküsimus on: „millist teenust ja riski see mõjutab?“

Zenith Blueprint, riskijuhtimise faas, samm 13: riskikäsitluse kavandamine ja kohaldatavusdeklaratsioon, käsitleb seda, sidudes riskid kontrollimeetmete, omanike ja tähtaegadega:

Samuti määrake igale tegevusele omanik ja tähtaeg (vajaduse korral eraldi veerus või kommentaarides). Nt „Omanik: IT-juht, tähtaeg: 2025. aasta III kvartaliks.“ See teeb sellest tegeliku plaani.

Täpselt seda haavatavuste kõrvaldamine nõuabki. Leid ilma omanikuta muutub tööjärje müraks. Leid koos omaniku, tähtaja, riskikäsitluse otsuse ja tõendusjäljega muutub auditeeritavaks kontrollimeetmeks.

Kuidas Zenith Controls kaardistab kontrollimeetmete seosed

Zenith Controls käsitleb ISO/IEC 27002:2022 kontrolli 8.8 „Tehniliste haavatavuste haldus“ ennetava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust. See seob kontrolli küberturbe mõistetega Identify ja Protect, ohtude ja haavatavuste halduse operatiivse võimekusega ning juhtimise, ökosüsteemi, kaitse ja tõrje turbevaldkondadega.

See on oluline, sest kõrvaldamise SLA-d ei ole ainult kaitsemehhanism. Need on ka juhtimismehhanism ja ökosüsteemi mehhanism. Teie kokkupuudet kujundavad tarnijad, pilveplatvormid, hallatud teenused, avatud lähtekoodiga komponendid ja internetile avatud sõltuvused.

Zenith Controls kaardistab 8.8 mitme toetava kontrollimeetmega:

Zenith Controls seob haavatavuste halduse ka standardiga ISO/IEC 27005:2024, eelkõige haavatavuste tuvastamise ja paikamata süsteemidega seotud riskistsenaariumidega. See tugevdab argumenti, et paikamise tähtajad peavad olema riskipõhised, mitte suvalised. Samuti seob see tarnijate seire standardiga ISO/IEC 27036-4:2016 pilveteenuse lepingute turbetasemete kohta ning standardiga ISO/IEC 20000-1:2018 teenuse osutamise planeerimise ja muudatuste juhtimise kohta.

Selline standarditeülene struktuur on auditi ajal oluline. Kui organisatsioon ütleb, et „kriitilised haavatavused paigatakse 72 tunni jooksul“, kontrollib audiitor, kas seda väidet toetavad riskihindamine, varade klassifitseerimine, tarnijakohustused, muudatuste kirjed ja seiretõendid.

NIS2 küberhügieen: haavatavuste käsitlemisest parandusmeetmeteni

NIS2 Article 21 nõuab võrgu- ja infosüsteemide puhul kõiki ohte hõlmavat lähenemist. Haavatavuste kõrvaldamise SLA-de jaoks on mitu Article 21 elementi otseselt asjakohased:

• riskianalüüs ja infosüsteemide turbepoliitikad;
• intsidentide käsitlemine;
• talitluspidevus ja kriisijuhtimine;
• tarneahela turve;
• turvaline hankimine, arendus ja hooldus, sealhulgas haavatavuste käsitlemine ja avalikustamine;
• protseduurid küberturbe tõhususe hindamiseks;
• põhiline küberhügieen ja koolitus;
• juurdepääsukontroll ja varahaldus;
• mitmefaktoriline autentimine või pidev autentimine, kui see on asjakohane.

NIS2 Article 20 muudab juhtorganid vastutavaks küberturbe riskijuhtimismeetmete heakskiitmise ja järelevalve eest. See tähendab, et haavatavuste kõrvaldamise mõõdikud ei tohi elada ainult arendusmeeskonna juhtpaneelil. Need peavad kajastuma juhtkonna aruandluses, riskikomitee materjalides või infoturbe juhtimissüsteemi juhtkonna läbivaatuse kirjetes.

Article 21 eeldab ka, et üksused, kes tuvastavad nõutavate meetmetega seotud mittevastavuse, võtavad põhjendamatu viivituseta parandusmeetmeid. See sõnastus on oluline. Kui juhtpaneel näitab tähtaja ületanud kriitilisi haavatavusi, ei tohi vastavuse tõendusmaterjal piirduda lausega „me teame“. See peab näitama eskaleerimist, riski läbivaatamist, juhtkonna nähtavust, parandusmeetmeid ja kordushindamist.

NIS2 Article 23 lisab teise mõõtme. Kui paikamata haavatavuse ärakasutus põhjustab või võib põhjustada olulise tegevushäire, rahalise kahju või kahju teistele isikutele, võib see muutuda oluliseks intsidendiks. Teavitamise elutsükkel hõlmab varajast hoiatust 24 tunni jooksul pärast olulisest intsidendist teadlikuks saamist, intsidenditeavitust 72 tunni jooksul, vahearuandeid nõudmisel ja lõpparuannet ühe kuu jooksul pärast intsidenditeavitust. Lõpparuanne peaks hõlmama tõsidust, mõju, tõenäolist algpõhjust, leevendusmeetmeid ja vajaduse korral piiriülest mõju.

Seetõttu peab SLA protsess olema seotud intsidentidele reageerimisega. Aktiivse ärakasutuse tõendusmaterjaliga kriitiline haavatavus peab käivitama turbe esmase hindamise, seire, tõendusmaterjali säilitamise ja teavitamishinnangu, mitte ainult rutiinse paikamispileti.

DORA IKT-risk: kõrvaldamistähtajad kui toimepidevuse tõendusmaterjal

Finantsüksustele kohaldub DORA alates 17. jaanuarist 2025 ning see loob ühtsed nõuded IKT-riski juhtimisele, olulistest IKT-ga seotud intsidentidest teavitamisele, digitaalse operatsioonilise toimepidevuse testimisele, teabe jagamisele ja IKT kolmandate osapoolte riskijuhtimisele. NIS2 riiklike eeskirjade alusel määratletud hõlmatud finantsüksuste puhul käsitatakse seda sektoripõhise ELi õigusaktina.

DORA toimimismudel sarnaneb integreeritud infoturbe juhtimissüsteemiga. Articles 5 ja 6 nõuavad juhtimist, poliitikaid, protseduure, tööriistu, iga-aastast või perioodilist läbivaatust, auditit, kriitiliste auditileidude kõrvaldamist ja digitaalse operatsioonilise toimepidevuse strateegiat. Article 8 nõuab IKT-toega ärifunktsioonide, teabevarade, IKT-varade, sõltuvuste, kolmandate osapoolte protsesside ja pärand-IKT riskide tuvastamist ja registreerimist. Article 9 nõuab kaitse- ja ennetusmeetmeid, sealhulgas paikamist ja muudatuste juhtimist. Articles 11 ja 12 nõuavad järjepidevust, reageerimist, taastet, varundamist, taastamist ja taaste-eesmärke.

DORA Articles 17 kuni 19 nõuavad IKT-ga seotud intsidentide halduse protsessi, mis tuvastab, haldab, registreerib, klassifitseerib, eskaleerib, teavitab, suhtleb, analüüsib algpõhjust ja taastab turvalised toimingud. Articles 24 kuni 26 nõuavad digitaalse operatsioonilise toimepidevuse testimist, sealhulgas IKT-tööriistade ja -süsteemide asjakohast testimist, haavatavuste hindamist, võrguturbe hindamist, puudujääkide analüüse, lähtekoodi läbivaatust, kui see on teostatav, penetratsioonitestimist ning teatud finantsüksuste puhul ohupõhist penetratsioonitestimist. Articles 28 ja 30 nõuavad IKT kolmanda osapoole riski juhtimist, IKT-teenuste lepingute registreid, taustakontrolli, auditi- ja inspekteerimisõigusi, teenustasemeid, teenuseosutaja abi intsidentide ajal, lõpetamisõigusi ja väljumiskorraldust.

Kõrvaldamise SLA-de puhul muudab DORA tõendusmaterjali ootusi kolmel viisil.

Esiteks peavad testimisest tulenevad haavatavusleiud toitma prioriseeritud kõrvaldamisprotsessi. Skaneerimisaruanne üksi ei ole piisav.

Teiseks tuleb kriitiliste leidude kõrvaldamist jälgida juhtimise ja auditi kaudu. DORA eeldab, et mittemikroettevõtted kõrvaldavad kriitilised auditileiud ametlikult.

Kolmandaks tuleb IKT kolmandatest osapooltest teenuseosutajatele kehtestada mõõdetavad kohustused. Kui teie pilveteenuse, SaaS-i või MSP teenuseosutaja kontrollib paikamisakent, peavad teie leping ja register näitama, kuidas nende kõrvaldamistähtajad toetavad teie toimepidevuskohustusi.

Haavatavuste ja paikade halduse poliitika käsitleb seda otse:

Kolmandate osapoolte paikamine ja SaaS-i riskijärelevalve 6.6.1 Kõik kolmandate osapoolte süsteemid (SaaS, PaaS, MSP hallatavad) peavad tõendama piisavaid haavatavuste ja paikade halduse kontrollimeetmeid. 6.6.2 Tarnijate SLA-d peavad sisaldama kõrvaldamistähtaegu, mis on samaväärsed sisemiselt määratletud kriitilisuspõhiste lävenditega.

See punkt on sageli puuduv sild sisemise ISO tõendusmaterjali ja DORA tarnijajärelevalve vahel.

GDPR: kui paikamisviivitused muutuvad isikuandmetega seotud vastutuse puudusteks

GDPR ei ole haavatavuste halduse standard, kuid see muudab paikamistõrke tagajärgi.

GDPR Article 5 nõuab isikuandmete turvalist töötlemist ja seda, et vastutav töötleja suudaks tõendada vastavust. Article 32 nõuab asjakohaseid tehnilisi ja korralduslikke meetmeid, et tagada riskile vastav turvalisuse tase. Kui paikamata süsteemid töötlevad isikuandmeid, eriti identiteediandmeid, finantsandmeid, biomeetrilisi andmeid, terviseandmeid, töösuhteandmeid või KYC-teavet, muutuvad kõrvaldamise SLA-d töötlemise turvalisusega seotud vastutuse osaks.

Viivitatud paik võib olla kaitstav, kui risk on hinnatud, kompenseerivad kontrollimeetmed on rakendatud ja jääkriski on aktsepteerinud õige isik. Seda on palju raskem kaitsta, kui haavatavus oli tähtaja ületanud, internetile avatud ja omanikuta.

Zenith Controls kaardistab haavatavuste halduse GDPR Articles 32 ja 5(1)(f) juurde, sest õigeaegne paikamine vähendab riske isikuandmete konfidentsiaalsusele ja terviklusele. Samuti kaardistab see muudatuste juhtimise GDPR Article 24 ja Article 32 juurde, sest isikuandmeid töötlevate süsteemide muudatused peavad olema riskihinnatud, kinnitatud, dokumenteeritud ja läbi vaadatud.

Vastavuse õppetund on lihtne: kui mängus on isikuandmed, peab paikamise tõendusmaterjal sisaldama andmekonteksti. Audiitorid ja regulaatorid ei küsi ainult „kas see paigati?“, vaid ka „millised andmed olid riskile avatud, kui kaua ja millised kontrollimeetmed seda riski vähendasid?“

Praktiline Claryseci töövoog auditiks valmis SLA tõendusmaterjali jaoks

Küps haavatavuste kõrvaldamise protsess ei alga siis, kui audiitor küsib kirjeid. See on kavandatud looma kirjeid iga kuu.

Samm 1: kinnita SLA poliitika

Alustage haavatavuste ja paikade halduse poliitikast või VKE-de haavatavuste ja paikade halduse poliitikast, sõltuvalt teie toimimismudelist. Kohandage SLA lävendeid vastavalt riskivalmidusele, regulatiivsele ulatusele, teenuse kriitilisusele, andmete tundlikkusele ja tehnilistele piirangutele. Tagage kinnitamine infoturbejuhi, riskikomitee või juhtorgani poolt.

Ettevõttekeskkondades kasutage CVSS-i, vara kriitilisust, ärakasutatavust, internetile avatust, andmete tundlikkust ja ärimõju. VKE-de puhul hoidke mudel lihtne, kuid selgesõnaline: kriitilised paigad kolme päeva jooksul, muud paigad 30 päeva jooksul, välja arvatud juhul, kui on olemas kehtiv erand.

Samm 2: kaardista varad omanike ja kriitiliste teenustega

Iga haavatavusleid peab olema seotav järgmisega:

• vara nimi ja unikaalne tunnus;
• äriteenus või rakendus;
• süsteemiomanik;
• tehniline omanik;
• andmete klassifitseerimine;
• internetile avatus;
• tarnijasõltuvus, kui see on asjakohane;
• toetatava funktsiooni kriitilisus.

See toetab ISO/IEC 27001:2022 riskivastutust, NIS2 varahaldust, DORA IKT-varade ja sõltuvuste registrit ning NIST CSF IDENTIFY tulemusi.

Samm 3: hinda haavatavust esmaselt

Looge pilet iga leiu või grupeeritud leidude kogumi kohta. Lisage CVSS-skoor, lähte-skanner, mõjutatud vara, ärakasutuse staatus, ohuteave, ärikriitilisus ja nõutav SLA. Kui kahtlustatakse ärakasutust, siduge pilet intsidendi hindamisega.

Samm 4: teosta muudatuste juhtimise kaudu

Paikamine on muudatus. Kasutage rutiinsete uuenduste puhul standardmuudatust ja kriitiliste ärakasutatud haavatavuste puhul erakorralist muudatust. Lisage testimistõendus, heakskiit, rakendamise ajatempel, tagasipööramiskava ja muudatusejärgne valideerimine.

See vastab Zenith Controls seosele 8.8 ja 8.32 vahel, kus paikade rakendamist juhitakse muudatuste juhtimise kaudu, et tasakaalustada kiireloomulisust ja tegevusstabiilsust.

Samm 5: valideeri sulgemine

Ärge sulgege pileteid üksnes märke „paik paigaldatud“ alusel. Nõudke valideerimist kordusskaneerimise, versiooni kinnitamise, konfiguratsiooni kontrolli või kompenseeriva kontrollimeetme kinnitamise kaudu. Kui paika ei saa rakendada, avage erand.

Samm 6: registreeri erandid ja jääkrisk

Haavatavuste ja paikade halduse poliitika määratleb nõutava erandi sisu:

Eranditaotlused peavad sisaldama järgmist: 7.2.1 äriline põhjendus viivitusele või kõrvaldamata jätmisele; 7.2.2 riskihindamine (CVSS-i, vara kriitilisuse ja ohuteabe alusel); 7.2.3 kavandatud kompenseerivad kontrollimeetmed; 7.2.4 kõrvaldamise või kordushindamise ajakava.

Samuti määratleb see heakskiitmise ja läbivaatamise:

Erandid peab kinnitama infoturbejuht või delegeeritud riskikomitee ning need tuleb registreerida infoturbe juhtimissüsteemi erandite registris, läbivaatamise intervalliga kuni 90 päeva.

See erandiregister muutub oluliseks tõendusmaterjaliks ISO/IEC 27001:2022 punktis 6.1.3 käsitletud riskikäsitluse ja jääkriski aktsepteerimise ning juhtkonna läbivaatuse jaoks.

See kirje näitab, et organisatsioon ei ignoreerinud haavatavust. Ta hindas riski, rakendas kompenseerivaid kontrollimeetmeid, kinnitas jääkriski ja määras läbivaatamise kuupäeva.

Samm 7: koosta igakuine tõendusmaterjali pakett

Teie igakuine haavatavuste kõrvaldamise tõendusmaterjali pakett peab sisaldama järgmist:

VKE-de puhul võib tõendusmaterjal olla kergem, kuid see peab siiski olema järjepidev. VKE-de haavatavuste ja paikade halduse poliitika nõuab jälgitavusega paikamisloge:

Logid peavad sisaldama seadme nime, rakendatud uuendust, paikamise kuupäeva ja iga viivituse põhjust

See üks punkt on auditi seisukohalt väga väärtuslik. See muudab paikamise väitest kirjeks.

Tarnijate paikamine: leping peab vastama teie SLA-le

Kui MSP, SaaS-i teenuseosutaja, PaaS-i teenuseosutaja või pilveteenuse pakkuja kontrollib paikade juurutamist, on sisemised SLA-d kasutud, kui tarnijakohustused nendega ei ühti.

Kolmandate osapoolte ja tarnijate turbepoliitika VKE-dele hõlmab juhtimisnõudena infoturbekohustusi. Haavatavuste kõrvaldamise jaoks peavad need kohustused muutuma mõõdetavaks lepingukeeleks:

• kriitilisest haavatavusest teavitamise ajad;
• kriitiliste, kõrgete, keskmiste ja madalate haavatavuste kõrvaldamistähtajad;
• erakorralise muudatuse protsess;
• kliendi heakskiidu nõuded katkestuse korral;
• paiga rakendamise lõpetamise tõendusmaterjali vorming;
• haavatavuste avalikustamise protsess;
• intsidentide ajal abistamise kohustused;
• õigus auditeerida või saada kindlustandvaid aruandeid;
• alltöötleja või alltöövõtja paikamiskohustused;
• kriitiliste teenuste lõpetamise ja ülemineku tugi.

Zenith Blueprint, kontrollimeetmete rakendamise faas, samm 20, kontroll 8.21 „Võrguteenuste turve“, sõnastab põhimõtte selgelt:

Kui teenuseid osutatakse väliselt, sealhulgas internetiteenuse pakkujate, SD-WAN tarnijate või privaatpilve teenuseosutajate poolt, tuleb turbenõuded lisada lepingutesse ja SLA-desse. See hõlmab tööaja tagatisi, intsidentidele reageerimise aegu, kohustusi haavatavuste paikamiseks või maandamiseks ning selgeid andmekäitluse piire. Ärge kunagi eeldage, et teenuseosutaja vastab teie ootustele, kui see ei ole kirjalik, mõõdetav ja auditeeritav.

DORA muudab selle eriti oluliseks finantsüksuste jaoks. IKT kolmandate osapoolte kokkulepped peavad sisaldama teenustasemeid, teenuseosutaja abi IKT-intsidentide ajal, juurdepääsu andmetele ja nende taastamist, koostööd asutustega, lõpetamisõigusi ning rangemaid sätteid kriitiliste või oluliste funktsioonide kohta, sealhulgas seire, auditiõigused, talitluspidevuse plaanid ja turvameetmed.

NIST CSF 2.0 ütleb sama tarneahela riskitulemuste kaudu: tarnijad peavad olema teada, prioriseeritud kriitilisuse alusel, hinnatud enne kaasamist, juhitud lepinguliste nõuetega, seiratud kogu suhte jooksul, kaasatud intsidentide planeerimisse ja hallatud suhte lõpetamisel.

Mida audiitorid tegelikult küsivad

Auditivestlus muutub sõltuvalt audiitori taustast.

ISO/IEC 27001:2022 audiitor alustab infoturbe juhtimissüsteemist. Ta kontrollib, kas haavatavuste haldus on kohaldatavusdeklaratsioonis, kas riskihindamine käsitleb paikamata süsteeme riskina, kas riskikäsitlusplaanidel on omanikud ja tähtajad, kas lisa A kontroll 8.8 on rakendatud, kas tõendusmaterjali säilitatakse ning kas siseaudit ja juhtkonna läbivaatus hindavad toimivust.

Zenith Blueprint, kontrollimeetmete rakendamise faas, samm 19, muudab auditi ootuse selgesõnaliseks:

See on audiitorite jaoks kõrge prioriteediga kontrollimeede ja nad süvenevad sellesse tavaliselt põhjalikult. Oodake küsimusi selle kohta, kui sageli süsteeme paigatakse, millist protsessi järgite nullpäeva-haavatavuse avalikustamisel ja milliseid süsteeme on kõige raskem paigata.

See jätkab praktiliste tõendusmaterjali ootustega:

Audiitorid küsivad tõenäoliselt haavatavuse skaneerimise tulemusi. Kui kasutate tööriistu nagu Nessus, OpenVAS või Qualys, eksportige aruanne, mis näitab hiljuti tuvastatud haavatavusi ja seda, kuidas neid käsitleti. Ideaalis peaks see sisaldama riskihinnanguid (CVSS) ja kõrvaldamistähtaegu.

NIS2-le keskenduv audiitor või pädev asutus otsib juhatuse heakskiitu, proportsionaalsust, küberhügieeni, haavatavuste käsitlemist, tarnijate turvet, intsidentide käsitlemist, tõhususe hindamist, põhjendamatu viivituseta parandusmeetmeid ning teavitamisotsuste kirjeid, kui ärakasutus põhjustas olulise mõju.

DORA järelevalveasutus kontrollib, kas haavatavusleiud on integreeritud IKT-riski juhtimisse, digitaalse operatsioonilise toimepidevuse testimisse, intsidendi klassifitseerimisse, algpõhjuse analüüsi, kolmandate osapoolte registritesse, lepingulistesse kohustustesse, auditiõigustesse ja kriitiliste leidude kõrvaldamisse.

NIST CSF hindaja korraldab läbivaatuse tõenäoliselt funktsioonide GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER ümber. Ta küsib, kas õiguslikke ja lepingulisi nõudeid mõistetakse, kas riskitaluvus on dokumenteeritud, kas haavatavused tuvastatakse ja prioriseeritakse, kas erandeid hallatakse, kas seire tuvastab ärakasutust ning kas reageerimis- ja taastetegevused on koordineeritud.

COBIT 2019 või ISACA-laadne audiitor keskendub juhtimiseesmärkidele, protsessivõimekusele, juhtimistavadele, mõõdikutele, omamisele, kontrollidisainile, kontrolli toimimisele ja tõendusmaterjali piisavusele. Ta küsib, kas haavatavuste kõrvaldamine on korratav, mõõdetud, eskaleeritud, täiustatud ning kooskõlas ettevõtte eesmärkide ja riskivalmidusega.

Eskaleerimine ja mõõdikud: kuidas tõendada, et SLA-sid juhitakse

SLA ilma eskaleerimiseta on lihtsalt siht. Kaitstav haavatavuste kõrvaldamise programm vajab eskaleerimist enne rikkumist, rikkumise ajal ja korduva tõrke järel.

Clarysec soovitab neljatasandilist eskaleerimismudelit:

1. Operatiivne eskaleerimine: pileti omanikku ja tehnilist juhti teavitatakse enne rikkumist.
2. Riskide eskaleerimine: varaomanik ja riskiomanik vaatavad mõju läbi, kui rikkumine on tõenäoline.
3. Turbejuhtimise eskaleerimine: infoturbejuht või riskikomitee kinnitab erandi või erakorralise tegevuse.
4. Juhtkonna eskaleerimine: korduvad või kriitilised SLA rikkumised esitatakse juhtkonna läbivaatusele koos parandusmeetmetega.

Haavatavuste ja paikade halduse poliitika tugevdab seda auditi ootust:

Siseaudit või sõltumatu kolmas osapool peab tegema perioodilisi auditeid, et kontrollida järgmist: 5.6.1 vastavus SLA-dele; 5.6.2 tõendusmaterjal riskipõhise prioriseerimise kohta; 5.6.3 rakendatud paikade tõhusus; 5.6.4 kontrollimeetmed paikamata süsteemide üle.

Mõõdikud peavad toetama otsuseid, mitte kaunistama juhtpaneele. Tugevaimad 2026. aasta mõõdikud on järgmised:

• kriitiliste SLA-de vastavuse protsent;
• kõrgete SLA-de vastavuse protsent;
• keskmine esmase hindamise aeg;
• keskmine kõrvaldamisaeg varaklassi lõikes;
• tähtaja ületanud kriitiliste haavatavuste arv;
• aktsepteeritud erandite arv vanuse järgi;
• üle 90 päeva kestvad erandid;
• internetile avatud kriitiliste kokkupuudete arv;
• tarnija SLA rikkumised;
• pärast valideerimist taasavatud haavatavused;
• ärakasutatud haavatavustest põhjustatud erakorralised muudatused;
• paigatõrked platvormi või äriüksuse lõikes.

Siduge need mõõdikud ISO/IEC 27001:2022 punkti 9.3 juhtkonna läbivaatuse, DORA juhtimisaruandluse ja NIS2 juhtkonna järelevalvega. NIST CSF 2.0 puhul kasutage neid praeguste ja sihtprofiilide, puudujääkide analüüsi ning tegevusplaanide ajakohastamiseks.

Claryseci kõrvaldamise SLA kontrollnimekiri

Kasutage seda kontrollnimekirja oma praeguse programmi hindamiseks:

• Kas olemas on kinnitatud haavatavuste ja paikade halduse poliitika?
• Kas kõrvaldamise SLA-d on määratletud tõsiduse ja ärikriitilisuse alusel?
• Kas internetile avatud ja ärakasutatud haavatavuste käsitlemist kiirendatakse?
• Kas varad on kaardistatud omanike, teenuste, andmete ja tarnijatega?
• Kas skannerileiud teisendatakse määratud piletiteks?
• Kas paigad rakendatakse muudatuste juhtimise kaudu?
• Kas erakorralised muudatused dokumenteeritakse ja vaadatakse läbi?
• Kas kõrvaldamistulemused valideeritakse kordusskaneerimise või versioonikontrolliga?
• Kas erandid hinnatakse riskipõhiselt, kinnitatakse ja vaadatakse üle vähemalt iga 90 päeva järel?
• Kas paigatamatute süsteemide jaoks dokumenteeritakse kompenseerivad kontrollimeetmed?
• Kas tarnijalepingud on kooskõlas sisemiste kõrvaldamislävenditega?
• Kas paikamislogid on piisavalt täielikud, et tõendada, mis juhtus ja millal?
• Kas SLA rikkumised eskaleeritakse ja parandatakse?
• Kas juhtkond vaatab mõõdikud läbi?
• Kas ärakasutuse kahtluse korral käivitatakse intsidendi- ja rikkumishinnangud?

Kui mitu vastust on „ei“, ei ole probleem tööriistades. Probleem on kontrollidisainis.

Järgmised sammud: muuda paikamistähtajad auditiks valmis toimepidevuseks

2026. aastal peavad haavatavuste kõrvaldamise SLA-d tegema enamat kui rahuldama skanneri juhtpaneeli. Need peavad tõendama, et teie organisatsioon suudab tuvastada kokkupuute, prioriseerida riski, tegutseda kinnitatud tähtaegade jooksul, juhtida erandeid, hallata tarnijaid ja tõendada otsuseid ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT 2019 auditi ootuste lõikes.

Clarysec aitab liikuda killustatud paikamispiletitelt integreeritud, tõendusmaterjalipõhisele haavatavuste kõrvaldamise programmile järgmiste vahenditega:

• Haavatavuste ja paikade halduse poliitika
• VKE-de haavatavuste ja paikade halduse poliitika
• Kolmandate osapoolte ja tarnijate turbepoliitika VKE-dele
• Zenith Blueprint: audiitori 30-sammuline teekaart
• Zenith Controls: vastavusvaldkondadeülene juhend

Alustage ühest kõrge riskiga teenusest. Kaardistage selle varad, tarnijad, haavatavused, piletid, muudatused, erandid ja tõendusmaterjal. Seejärel rakendage sellele auditiküsimused. Kui te ei suuda tõendada SLA-d tuvastamisest sulgemiseni, on see teie esimene kõrvaldamisprojekt.

Eesmärk ei ole täiuslik paikamine. Eesmärk on juhitud, riskipõhine, mõõdetav ja auditeeritav kõrvaldamine. Laadige alla Claryseci poliitikamallid, tehke sihitud puudujääkide hindamine või broneerige Claryseci demo, et muuta haavatavuste kõrvaldamine auditipingest operatsiooniliseks toimepidevuseks.