SLA-ji za odpravljanje ranljivosti za NIS2 in DORA

Ob 08:17 v torek zjutraj v začetku leta 2026 Anna, CISO hitro rastočega fintech podjetja, prejme prvo sporočilo, še preden spije kavo.

SOC je zaznal razprave o aktivnem izkoriščanju ranljivosti v prehodu API, namenjenem strankam. Inženiring sporoča, da je popravek na voljo, vendar je njegova uvedba tvegana, ker je prehod postavljen pred plačilne delovne tokove. Vodja skladnosti posreduje uradno zahtevo nacionalnega pristojnega organa, ki zahteva dokazila o »obravnavi in razkritju ranljivosti« ter dokaz, da je bil proces v zadnjih 12 mesecih učinkovit. Nabava doda tretjo težavo: prehod upravlja ponudnik upravljanih storitev, pogodba pa določa le, da bo ponudnik »pravočasno namestil varnostne posodobitve«.

Do 09:00 to ni več samo vprašanje nameščanja popravkov. Gre za vprašanje dokazil po ISO/IEC 27001:2022, vprašanje kibernetske higiene po NIS2, vprašanje upravljanja tveganj IKT po DORA, vprašanje upravljanja dobaviteljev in potencialno vprašanje poročanja o incidentih, če izkoriščanje vpliva na neprekinjeno izvajanje storitev ali na osebne podatke.

To je praktična vrzel skladnosti, s katero se bo v letu 2026 srečalo veliko organizacij. Imajo skenerje, nadzorne plošče, zahtevke in orodja za nameščanje popravkov, vendar na revizijska vprašanja ne morejo jasno odgovoriti:

• Kdo je odobril SLA za odpravo?
• Kako je SLA zasnovan na podlagi tveganja?
• Kaj se zgodi, ko kritični popravek zamudi rok?
• Kako se prednostno obravnavajo sredstva, izpostavljena internetu?
• Kako se od dobaviteljev zahteva upoštevanje enakih rokov?
• Kje je zapis o sprejemu tveganja za sistem brez nameščenega popravka?
• Katera dokazila dokazujejo, da je kontrola delovala, in ne le, da je obstajala?

Odgovor ni še ena preglednica rokov zapadlosti. SLA-je za odpravljanje ranljivosti je treba upravljati kot živ sistem kontrol, ki povezuje lastništvo sredstev, točkovanje ranljivosti, obveščevalne podatke o grožnjah, upravljanje sprememb, SLA-je dobaviteljev, obravnavo izjem, spremljanje, odziv na incidente in vodstveni pregled.

Tu postanejo uporabni Clarysecova podjetniška Politika upravljanja ranljivosti in popravkov (VPMP), Politika upravljanja ranljivosti in popravkov za mala in srednja podjetja (VPMP-SME), Politika varnosti tretjih oseb in dobaviteljev za mala in srednja podjetja (TPSSP-SME), Zenith Blueprint (ZB) in Zenith Controls (ZC). Skupaj pristop »hitreje nameščajte popravke« spremenijo v dokazljiv proces upravljanja, ki prestane presojo po ISO, NIS2, DORA, GDPR, NIST in revizijski pristop v slogu ISACA.

Zakaj so SLA-ji za odpravljanje ranljivosti postali dokazila na ravni upravnega odbora

Odpravljanje ranljivosti se je nekoč obravnavalo kot kazalnik higiene IT. V letu 2026 je bližje regulirani zavezi za operativno odpornost.

NIS2 kibernetsko varnost postavlja kot vprašanje odgovornosti vodstva. Bistveni in pomembni subjekti morajo zagotoviti, da organi upravljanja odobrijo ukrepe za obvladovanje kibernetskih tveganj, nadzirajo njihovo izvajanje in prejmejo usposabljanje, da razumejo tveganja ter vpliv varnostnih praks na storitve. NIS2 Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganj, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varno nabavo in vzdrževanjem, obravnavo in razkritjem ranljivosti, kibernetsko higieno, usposabljanjem, nadzorom dostopa, upravljanjem sredstev in avtentikacijo.

Za finančne subjekte je DORA specializiran režim operativne odpornosti. Zahteva ureditve upravljanja in kontrole za tveganja IKT, pri čemer organ upravljanja opredeli, odobri in nadzira upravljanje tveganj IKT ter zanj ostaja odgovoren. Zahteva tudi identifikacijo sredstev IKT in odvisnosti, zaščitne in preventivne kontrole, kot sta nameščanje popravkov in upravljanje sprememb, upravljanje incidentov, povezanih z IKT, testiranje digitalne operativne odpornosti in upravljanje tveganj tretjih oseb na področju IKT.

Praktični vpliv je pomemben. Zamujen rok za popravek lahko kaže na odpoved:

• upravljanja, če vodstvo ni odobrilo SLA-jev na podlagi tveganj;
• upravljanja sredstev, če lastnik prizadetega sistema ni znan;
• upravljanja sprememb, če nujno nameščanje popravkov ni nadzorovano;
• upravljanja dobaviteljev, če so roki ponudnika nejasni;
• odziva na incidente, če znaki izkoriščanja niso triažirani;
• upravljanja dokazil, če zahtevki in dnevniki ne morejo dokazati zaprtja;
• obravnave tveganj, če izjeme niso odobrene in pregledane.

ISO/IEC 27001:2022 zagotavlja okvir sistema upravljanja. Klavzule 4.1 do 4.3 zahtevajo, da organizacije razumejo notranja in zunanja vprašanja, zahteve zainteresiranih strani, zakonske in pogodbene obveznosti ter vmesnike z drugimi organizacijami. Klavzule 6.1.1 do 6.1.3 zahtevajo oceno tveganj, obravnavo tveganj, izjavo o uporabnosti in odobritev preostalega tveganja s strani lastnika tveganja. Klavzule 9.1, 9.2, 9.3, 10.1 in 10.2 zahtevajo spremljanje, notranjo presojo, vodstveni pregled, nenehno izboljševanje, korektivne ukrepe in hranjena dokazila.

Preprosto povedano: če želite, da so SLA-ji za odpravljanje ranljivosti revizijsko pripravljeni, morajo biti del ISMS, ne le metrika DevOps.

Model SLA, ki ga presojevalci pričakujejo

SLA za odpravljanje ranljivosti mora odgovoriti na tri vprašanja:

1. Kako hitro moramo ukrepati?
2. Kdo je odgovoren?
3. Katera dokazila potrjujejo rezultat?

Politika upravljanja ranljivosti in popravkov opredeljuje praktično izhodišče za roke odprave na podlagi tveganj:

Organizacija mora vse zaznane ranljivosti razvrstiti z uporabo standardizirane metodologije (npr. CVSS v3.x) in uporabiti roke odprave, usklajene s poslovno kritičnostjo: 5.2.1 Kritična (CVSS 9.0–10.0): takojšen pregled; rok za namestitev popravka največ 72 ur. 5.2.2 Visoka (7.0–8.9): odziv v 48 urah; rok za namestitev popravka 7 koledarskih dni. 5.2.3 Srednja (4.0–6.9): odziv v 5 dneh; rok za namestitev popravka 30 koledarskih dni. 5.2.4 Nizka (<4.0): odziv v 10 dneh; rok za namestitev popravka 60 koledarskih dni.

Ta določba je močna, ker loči odzivni čas od roka za namestitev popravka. Visoka ranljivost ne sme šest dni ostati neopažena in biti nato odpravljena sedmi dan. Odzivni čas potrjuje triažo, lastništvo, oceno vpliva in načrtovanje odprave. Rok za namestitev popravka potrjuje tehnično zaprtje ali odobreno izjemo.

Za manjše organizacije Politika upravljanja ranljivosti in popravkov za mala in srednja podjetja uporablja preprostejše, vendar še vedno preverljivo besedilo:

Kritične popravke je treba namestiti v 3 dneh od izdaje, zlasti za sisteme, izpostavljene internetu.

Za širše okolje nameščanja popravkov pa:

Vse druge popravke je treba namestiti v 30 dneh, razen če je dokumentirana veljavna izjema.

Bistvo ni, da mora vsaka organizacija uporabljati enake roke. ISO/IEC 27001:2022, NIS2 in DORA podpirajo sorazmernost. Bistvo je, da morajo biti SLA-ji za odpravo opredeljeni, odobreni, zasnovani na podlagi tveganj, spremljani in podprti z dokazili.

Tu številna podjetja odpovejo. Opredelijo SLA, ne opredelijo pa dokazil. Z vidika presojevalca je politika brez operativnih zapisov obljuba, ne kontrola.

Lastništvo sredstev je skrita odvisnost

Skener vam lahko pove, da CVE obstaja na strežniku. Ne more pa povedati, ali strežnik podpira kritični plačilni proces, hrani posebne vrste osebnih podatkov, se povezuje s ponudnikom poravnave ali je načrtovan za izločitev iz uporabe.

Ta kontekst izhaja iz upravljanja sredstev, razvrščanja podatkov, evidence dobaviteljev in ocene tveganj.

ISO/IEC 27001:2022 Priloga A, kontrola 8.8, upravljanje tehničnih ranljivosti, je osrednja, vendar ne deluje samostojno. Močno je odvisna od upravljanja konfiguracij, upravljanja sprememb, spremljanja dobaviteljev, upravljanja oblaka, beleženja, spremljanja in obravnave tveganj.

NIST CSF 2.0 isti problem izraža z jezikom rezultatov. Funkcija GOVERN pričakuje, da so zakonske, regulativne in pogodbene zahteve kibernetske varnosti razumljene in upravljane, da sta apetit po tveganju in toleranca dokumentirana, da so vloge in viri dodeljeni ter da so politike kibernetske varnosti vzpostavljene, uveljavljene, pregledane in posodobljene. Rezultati IDENTIFY vključujejo popise strojne opreme, programske opreme, storitev, sistemov, podatkov in življenjskega cikla ter procese identifikacije ranljivosti, analize tveganj, upravljanja izjem in razkritja ranljivosti.

V Anninem torkovem jutranjem scenariju je prvo tehnično vprašanje: »kje je ranljiva komponenta?« Prvo vprašanje upravljanja pa je: »na katero storitev in tveganje vpliva?«

Zenith Blueprint, faza upravljanja tveganj, korak 13: Risk Treatment Planning and Statement of Applicability, to obravnava tako, da tveganja poveže s kontrolami, lastniki in časovnicami:

Prav tako dodelite lastnika in časovnico za vsak ukrep (morda v ločenem stolpcu ali komentarjih). Npr. »Lastnik: vodja IT, časovnica: do Q3 2025.« S tem postane pravi načrt.

Prav to zahteva odpravljanje ranljivosti. Ugotovitev brez lastnika postane hrup v zaostanku nalog. Ugotovitev z lastnikom, časovnico, odločitvijo o obravnavi tveganja in sledjo dokazil postane preverljiva kontrola.

Kako Zenith Controls mapira razmerja med kontrolami

Zenith Controls obravnava kontrolno zahtevo ISO/IEC 27002:2022 8.8, upravljanje tehničnih ranljivosti, kot preventivno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost. Povezuje jo s konceptoma kibernetske varnosti Identify in Protect, operativno zmožnostjo upravljanja groženj in ranljivosti ter varnostnimi področji upravljanja, ekosistema, zaščite in obrambe.

To je pomembno, ker SLA-ji za odpravo niso le zaščitni mehanizem. So tudi mehanizem upravljanja in mehanizem ekosistema. Vašo izpostavljenost oblikujejo dobavitelji, oblačne platforme, upravljane storitve, odprtokodne komponente in odvisnosti, izpostavljene internetu.

Zenith Controls mapira 8.8 na več podpornih kontrol:

Zenith Controls upravljanje ranljivosti povezuje tudi z ISO/IEC 27005:2024, zlasti z identifikacijo ranljivosti in scenariji tveganj, ki vključujejo sisteme brez popravkov. To okrepi utemeljitev, da morajo roki za nameščanje popravkov temeljiti na tveganju, ne na poljubnih odločitvah. Spremljanje dobaviteljev poveže tudi z ISO/IEC 27036-4:2016 za varnostne ravni pogodb o storitvah v oblaku in ISO/IEC 20000-1:2018 za načrtovanje izvajanja storitev in upravljanje sprememb.

Ta medstandardna struktura je pri presoji pomembna. Če organizacija trdi, da so »kritične ranljivosti popravljene v 72 urah«, bo presojevalec preveril, ali to izjavo podpirajo ocena tveganja, razvrščanje sredstev, obveznosti dobaviteljev, zapisi o spremembah in dokazila o spremljanju.

Kibernetska higiena po NIS2: od obravnave ranljivosti do korektivnega ukrepa

NIS2 Article 21 zahteva pristop k omrežnim in informacijskim sistemom, ki zajema vse nevarnosti. Za SLA-je za odpravljanje ranljivosti je neposredno relevantnih več elementov Article 21:

• analiza tveganj in politike varnosti informacijskih sistemov;
• obravnavanje incidentov;
• neprekinjeno poslovanje in krizno upravljanje;
• varnost dobavne verige;
• varna nabava, razvoj in vzdrževanje, vključno z obravnavo in razkritjem ranljivosti;
• postopki za ocenjevanje učinkovitosti kibernetske varnosti;
• osnovna kibernetska higiena in usposabljanje;
• nadzor dostopa in upravljanje sredstev;
• večfaktorska avtentikacija ali neprekinjena avtentikacija, kjer je ustrezno.

NIS2 Article 20 določa odgovornost organov upravljanja za odobritev in nadzor ukrepov za obvladovanje kibernetskih tveganj. To pomeni, da metrike odpravljanja ranljivosti ne smejo obstajati samo na inženirski nadzorni plošči. Pojaviti se morajo v poročanju vodstvu, gradivih odbora za tveganja ali zapisih vodstvenega pregleda ISMS.

Article 21 prav tako pričakuje, da subjekti, ki ugotovijo neskladnost z zahtevanimi ukrepi, brez nepotrebnega odlašanja sprejmejo korektivne ukrepe. Ta izraz je pomemben. Če nadzorna plošča prikazuje zapadle kritične ranljivosti, se dokazila o skladnosti ne smejo končati pri »vemo«. Pokazati morajo eskalacijo, pregled tveganja, vidnost za vodstvo, korektivni ukrep in ponovno oceno.

NIS2 Article 23 doda še eno razsežnost. Če izkoriščanje nepopravljene ranljivosti povzroči ali bi lahko povzročilo hudo operativno motnjo, finančno izgubo ali škodo drugim osebam, lahko postane pomemben incident. Življenjski cikel poročanja vključuje zgodnje opozorilo v 24 urah od seznanitve s pomembnim incidentom, obvestilo o incidentu v 72 urah, vmesna poročila na zahtevo in končno poročilo v enem mesecu po obvestilu o incidentu. Končno poročilo mora vključevati resnost, vpliv, verjetni temeljni vzrok, omilitvene ukrepe in čezmejni vpliv, kjer je to relevantno.

Zato mora biti proces SLA povezan z odzivom na incidente. Kritična ranljivost z dokazili o aktivnem izkoriščanju mora sprožiti varnostno triažo, spremljanje, ohranjanje dokazil in presojo obveznosti poročanja, ne le rutinski zahtevek za popravek.

Tveganja IKT po DORA: roki odprave kot dokazila odpornosti

Za finančne subjekte se DORA uporablja od 17. januarja 2025 in uvaja enotne zahteve za upravljanje tveganj IKT, poročanje o večjih incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti, izmenjavo informacij in upravljanje tveganj tretjih oseb na področju IKT. Obravnava se kot sektorsko specifični pravni akt EU za zajete finančne subjekte, opredeljene po nacionalnih pravilih NIS2.

Operativni model DORA je blizu integriranemu ISMS. Articles 5 in 6 zahtevata upravljanje, politike, postopke, orodja, letni ali periodični pregled, revizijo, odpravo kritičnih revizijskih ugotovitev in strategijo digitalne operativne odpornosti. Article 8 zahteva identifikacijo in popis poslovnih funkcij, podprtih z IKT, informacijskih sredstev, sredstev IKT, odvisnosti, procesov tretjih oseb in tveganj zastarele IKT. Article 9 zahteva zaščitne in preventivne kontrole, vključno z nameščanjem popravkov in upravljanjem sprememb. Articles 11 in 12 zahtevata neprekinjenost, odziv, obnovitev, varnostno kopiranje, ponovno vzpostavitev in cilje obnovitve.

DORA Articles 17 do 19 zahtevajo proces upravljanja incidentov, povezanih z IKT, ki zaznava, upravlja, zapisuje, razvršča, eskalira, poroča, komunicira, analizira temeljni vzrok in ponovno vzpostavi varno delovanje. Articles 24 do 26 zahtevajo testiranje digitalne operativne odpornosti, vključno z ustreznim testiranjem orodij in sistemov IKT, ocenjevanjem ranljivosti, ocenami varnosti omrežja, analizami vrzeli, pregledi izvorne kode, kjer je to izvedljivo, penetracijskim testiranjem in penetracijskim testiranjem na podlagi groženj za določene finančne subjekte. Articles 28 in 30 zahtevata upravljanje tveganj tretjih oseb na področju IKT, registre pogodb o storitvah IKT, skrbni pregled, pravice do revizije in inšpekcije, ravni storitev, pomoč ponudnika med incidenti, pravice do odpovedi in izstopne ureditve.

Za SLA-je za odpravo DORA spremeni pričakovanja glede dokazil na tri načine.

Prvič, ugotovitve ranljivosti iz testiranja morajo vstopiti v prednostno obravnavan proces odprave. Poročilo o skeniranju ni dovolj.

Drugič, odpravo kritičnih ugotovitev je treba spremljati prek upravljanja in revizije. DORA za podjetja, ki niso mikro podjetja, pričakuje formalno odpravo kritičnih revizijskih ugotovitev.

Tretjič, ponudniki IKT tretjih oseb morajo imeti merljive obveznosti. Če vaš ponudnik oblaka, SaaS ali ponudnik upravljanih storitev nadzira okno za nameščanje popravkov, morata vaša pogodba in register pokazati, kako njihovi roki odprave podpirajo vaše obveznosti glede odpornosti.

Politika upravljanja ranljivosti in popravkov to obravnava neposredno:

Nameščanje popravkov pri tretjih osebah in nadzor tveganj SaaS 6.6.1 Vsi sistemi tretjih oseb (SaaS, PaaS, sistemi, ki jih upravljajo ponudniki upravljanih storitev) morajo dokazati ustrezne kontrole upravljanja ranljivosti in popravkov. 6.6.2 SLA-ji dobaviteljev morajo vključevati roke odprave, enakovredne interno opredeljenim pragom na podlagi kritičnosti.

Ta določba je pogosto manjkajoči most med internimi dokazili ISO in nadzorom dobaviteljev po DORA.

GDPR: ko zamude pri popravkih postanejo odpoved odgovornosti za osebne podatke

GDPR ni standard za upravljanje ranljivosti, vendar spremeni posledice odpovedi pri nameščanju popravkov.

GDPR Article 5 zahteva, da se osebni podatki obdelujejo varno, in zahteva, da lahko upravljavec dokaže skladnost. Article 32 zahteva ustrezne tehnične in organizacijske ukrepe za zagotovitev ravni varnosti, primerne tveganju. Kadar sistemi brez popravkov obdelujejo osebne podatke, zlasti podatke o identiteti, finančne podatke, biometrične podatke, zdravstvene podatke, podatke o zaposlitvi ali informacije KYC, SLA-ji za odpravo postanejo del odgovornosti za varnost obdelave.

Zamujen popravek je lahko zagovorljiv, če je bilo tveganje ocenjeno, kompenzacijske kontrole uporabljene in preostalo tveganje sprejeto s strani ustrezne osebe. Veliko težje ga je zagovarjati, če je bila ranljivost zapadla, izpostavljena internetu in brez lastnika.

Zenith Controls mapira upravljanje ranljivosti na GDPR Articles 32 in 5(1)(f), ker pravočasno nameščanje popravkov zmanjšuje tveganja za zaupnost in celovitost osebnih podatkov. Prav tako mapira upravljanje sprememb na GDPR Article 24 in Article 32, ker morajo biti spremembe sistemov, ki obdelujejo osebne podatke, predmet ocene tveganja, odobrene, dokumentirane in pregledane.

Lekcija glede skladnosti je neposredna: če so vključeni osebni podatki, morajo dokazila o popravkih vključevati podatkovni kontekst. Presojevalci in regulatorji ne bodo vprašali le »ali je bilo popravljeno?«, temveč tudi »kateri podatki so bili izpostavljeni tveganju, kako dolgo in katere kontrole so to tveganje zmanjšale?«

Praktični Clarysecov delovni tok za revizijsko pripravljena dokazila SLA

Zrel proces odpravljanja ranljivosti se ne začne, ko presojevalec zahteva zapise. Zasnovan je tako, da zapise ustvarja vsak mesec.

Korak 1: Odobrite politiko SLA

Začnite s Politiko upravljanja ranljivosti in popravkov ali Politiko upravljanja ranljivosti in popravkov za mala in srednja podjetja, odvisno od vašega operativnega modela. Pragove SLA prilagodite apetitu po tveganju, regulativnemu obsegu, kritičnosti storitev, občutljivosti podatkov in tehničnim omejitvam. Zagotovite odobritev CISO, odbora za tveganja ali organa upravljanja.

Za podjetniška okolja uporabite CVSS, kritičnost sredstev, možnost izkoriščanja, izpostavljenost internetu, občutljivost podatkov in vpliv na poslovanje. Za mala in srednja podjetja naj bo model preprost, vendar izrecen: kritični popravki v treh dneh, drugi popravki v 30 dneh, razen če obstaja veljavna izjema.

Korak 2: Mapirajte sredstva na lastnike in kritične storitve

Vsaka ugotovitev ranljivosti mora biti povezana z:

• imenom sredstva in edinstvenim identifikatorjem;
• poslovno storitvijo ali aplikacijo;
• lastnikom sistema;
• tehničnim lastnikom;
• razvrstitvijo podatkov;
• izpostavljenostjo internetu;
• odvisnostjo od dobavitelja, če je relevantno;
• kritičnostjo podprte funkcije.

To podpira lastništvo tveganja po ISO/IEC 27001:2022, upravljanje sredstev po NIS2, popis sredstev IKT in odvisnosti po DORA ter rezultate IDENTIFY po NIST CSF.

Korak 3: Izvedite triažo ranljivosti

Ustvarite zahtevek za vsako ugotovitev ali skupino ugotovitev. Vključite oceno CVSS, izvorni skener, prizadeto sredstvo, status izkoriščanja, obveščevalne podatke o grožnjah, poslovno kritičnost in zahtevani SLA. Če obstaja sum izkoriščanja, zahtevek povežite z oceno incidenta.

Korak 4: Izvedite prek upravljanja sprememb

Nameščanje popravkov je sprememba. Za rutinske posodobitve uporabite standardno spremembo, za kritične izkoriščane ranljivosti pa nujno spremembo. Vključite dokazila o testiranju, odobritev, časovni žig izvedbe, načrt povrnitve in validacijo po spremembi.

To ustreza razmerju v Zenith Controls med 8.8 in 8.32, kjer je uporaba popravkov urejena prek upravljanja sprememb za uravnoteženje nujnosti in operativne stabilnosti.

Korak 5: Validirajte zaprtje

Zahtevkov ne zapirajte zgolj na podlagi izjave »popravek nameščen«. Zahtevajte validacijo s ponovnim skeniranjem, potrditvijo različice, preverjanjem konfiguracije ali potrditvijo kompenzacijske kontrole. Kadar popravka ni mogoče uporabiti, odprite izjemo.

Korak 6: Evidentirajte izjeme in preostalo tveganje

Politika upravljanja ranljivosti in popravkov opredeljuje zahtevano vsebino izjeme:

Zahteve za izjemo morajo vključevati: 7.2.1 Poslovno utemeljitev zamude ali neizvedene odprave 7.2.2 Oceno tveganja (na podlagi CVSS, kritičnosti sredstva, obveščevalnih podatkov o grožnjah) 7.2.3 Predlagane kompenzacijske kontrole 7.2.4 Časovnico odprave ali ponovne ocene

Opredeljuje tudi odobritev in pregled:

Izjeme mora odobriti CISO ali pooblaščeni odbor za tveganja in morajo biti zapisane v registru izjem ISMS, pri čemer interval pregleda ne sme presegati 90 dni.

Ta register izjem postane ključno dokazilo za obravnavo tveganj in sprejem preostalega tveganja po ISO/IEC 27001:2022 Clause 6.1.3 ter za vodstveni pregled.

Ta zapis dokazuje, da organizacija ranljivosti ni prezrla. Ocenila je tveganje, uporabila kompenzacijske kontrole, odobrila preostalo tveganje in določila datum pregleda.

Korak 7: Pripravite mesečni paket dokazil

Vaš mesečni paket dokazil o odpravljanju ranljivosti mora vključevati:

Za mala in srednja podjetja so dokazila lahko lažja, vendar morajo biti še vedno dosledna. Politika upravljanja ranljivosti in popravkov za mala in srednja podjetja zahteva dnevnike popravkov s sledljivostjo:

Dnevniki morajo vključevati ime naprave, uporabljeno posodobitev, datum namestitve popravka in razlog za morebitno zamudo.

Ta ena določba je revizijsko izjemno dragocena. Nameščanje popravkov spremeni iz trditve v zapis.

Nameščanje popravkov pri dobaviteljih: pogodba se mora ujemati z vašim SLA

Če ponudnik upravljanih storitev, ponudnik SaaS, ponudnik PaaS ali ponudnik storitev v oblaku nadzira uvedbo popravkov, so interni SLA-ji neuporabni, če se obveznosti dobaviteljev z njimi ne ujemajo.

Politika varnosti tretjih oseb in dobaviteljev za mala in srednja podjetja vključuje obveznosti informacijske varnosti kot zahtevo upravljanja. Za odpravljanje ranljivosti morajo te obveznosti postati merljiv pogodbeni jezik:

• roki obveščanja o kritičnih ranljivostih;
• roki odprave za kritične, visoke, srednje in nizke ranljivosti;
• proces nujnih sprememb;
• zahteve za odobritev izpada s strani naročnika;
• oblika dokazil o dokončanju popravka;
• proces razkritja ranljivosti;
• obveznosti pomoči pri incidentih;
• pravica do revizije ali prejemanja poročil o zagotovilih;
• obveznosti podobdelovalcev ali podizvajalcev glede popravkov;
• podpora pri izstopu in prehodu za kritične storitve.

Zenith Blueprint, faza Controls in Action, korak 20, Control 8.21 Security of network services, načelo jasno opredeli:

Kadar storitve zagotavljajo zunanji izvajalci, vključno z ISP-ji, ponudniki SD-WAN ali zasebnimi ponudniki oblaka, morajo biti varnostne zahteve vključene v pogodbe in SLA-je. To vključuje jamstva razpoložljivosti, odzivne čase za incidente, obveznosti nameščanja popravkov ali ublažitve ranljivosti ter jasne meje ravnanja s podatki. Nikoli ne smete predpostavljati, da ponudnik izpolnjuje vaša pričakovanja, če to ni zapisano, merljivo in preverljivo.

DORA to še posebej poudarja za finančne subjekte. Dogovori s tretjimi osebami na področju IKT morajo vključevati ravni storitev, pomoč ponudnika med incidenti IKT, dostop do podatkov in njihovo obnovitev, sodelovanje z organi, pravice do odpovedi in strožje določbe za kritične ali pomembne funkcije, vključno s spremljanjem, pravicami do revizije, načrti za nepredvidene dogodke in varnostnimi ukrepi.

NIST CSF 2.0 enako sporoča prek rezultatov tveganj v dobavni verigi: dobavitelji morajo biti znani, prednostno razvrščeni po kritičnosti, ocenjeni pred začetkom sodelovanja, upravljani s pogodbenimi zahtevami, spremljani skozi celoten odnos, vključeni v načrtovanje incidentov in upravljani ob prenehanju.

Kaj bodo presojevalci dejansko vprašali

Revizijski pogovor se spremeni glede na ozadje presojevalca.

Presojevalec ISO/IEC 27001:2022 bo začel pri ISMS. Preveril bo, ali je upravljanje ranljivosti vključeno v izjavo o uporabnosti, ali ocena tveganj opredeljuje sisteme brez popravkov kot tveganje, ali imajo načrti obravnave tveganj lastnike in časovnice, ali je kontrola 8.8 iz Priloge A implementirana, ali se dokazila hranijo ter ali notranja presoja in vodstveni pregled ocenjujeta uspešnost.

Zenith Blueprint, faza Controls in Action, korak 19, revizijsko pričakovanje izrecno opredeli:

To je kontrola visoke prioritete za presojevalce in običajno se ji bodo podrobno posvetili. Pričakujte vprašanja o tem, kako pogosto nameščate popravke v sistemih, kakšen proces uporabite ob objavi ranljivosti ničtega dne in katere sisteme je najtežje popravljati.

Nadaljuje s praktičnimi pričakovanji glede dokazil:

Presojevalci bodo verjetno zahtevali rezultate skeniranja ranljivosti. Če uporabljate orodja, kot so Nessus, OpenVAS ali Qualys, izvozite poročilo, ki prikazuje nedavno zaznane ranljivosti in način njihove obravnave. V idealnem primeru mora vključevati ocene tveganja (CVSS) in roke odprave.

Presojevalec ali pristojni organ, osredotočen na NIS2, bo iskal odobritev upravnega odbora, sorazmernost, kibernetsko higieno, obravnavo ranljivosti, varnost dobaviteljev, obravnavanje incidentov, oceno učinkovitosti, korektivne ukrepe brez nepotrebnega odlašanja in zapise odločitev o poročanju, če je izkoriščanje povzročilo pomemben vpliv.

Nadzornik DORA bo preverjal, ali so ugotovitve ranljivosti vključene v upravljanje tveganj IKT, testiranje digitalne operativne odpornosti, razvrščanje incidentov, analizo temeljnega vzroka, registre tretjih oseb, pogodbene obveznosti, pravice do revizije in odpravo kritičnih ugotovitev.

Ocenjevalec NIST CSF bo pregled verjetno organiziral okoli GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER. Vprašal bo, ali so zakonske in pogodbene zahteve razumljene, ali je toleranca do tveganja dokumentirana, ali so ranljivosti identificirane in prednostno obravnavane, ali so izjeme upravljane, ali spremljanje zaznava izkoriščanje ter ali so odzivne in obnovitvene aktivnosti usklajene.

Presojevalec v slogu COBIT 2019 ali ISACA se bo osredotočil na cilje upravljanja, zmožnost procesov, upravljavske prakse, metrike, lastništvo, zasnovo kontrol, delovanje kontrol in zadostnost dokazil. Vprašal bo, ali je odpravljanje ranljivosti ponovljivo, merjeno, eskalirano, izboljševano in usklajeno s cilji podjetja ter apetitom po tveganju.

Eskalacija in metrike: kako dokazati, da je SLA upravljan

SLA brez eskalacije je le cilj. Zagovorljiv program odpravljanja ranljivosti potrebuje eskalacijo pred kršitvijo, ob kršitvi in po ponavljajoči se odpovedi.

Clarysec priporoča štiristopenjski model eskalacije:

1. Operativna eskalacija: lastnik zahtevka in tehnični vodja sta obveščena pred kršitvijo.
2. Eskalacija tveganja: lastnik sredstva in lastnik tveganja pregledata vpliv, ko je kršitev verjetna.
3. Eskalacija varnostnega upravljanja: CISO ali odbor za tveganja odobri izjemo ali nujni ukrep.
4. Eskalacija vodstvu: ponavljajoče se ali kritične kršitve SLA se poročajo v vodstveni pregled skupaj s korektivnimi ukrepi.

Politika upravljanja ranljivosti in popravkov krepi to revizijsko pričakovanje:

Periodične presoje mora izvajati notranja revizija ali neodvisna tretja oseba, da preveri: 5.6.1 skladnost s SLA-ji 5.6.2 dokazila o prednostni obravnavi na podlagi tveganj 5.6.3 učinkovitost uvedenih popravkov 5.6.4 kontrole nad sistemi brez popravkov

Metrike morajo podpirati odločitve, ne krasiti nadzornih plošč. Najmočnejše metrike za leto 2026 vključujejo:

• odstotek skladnosti s SLA za kritične ranljivosti;
• odstotek skladnosti s SLA za visoke ranljivosti;
• povprečni čas do triaže;
• povprečni čas do odprave po razredu sredstev;
• število zapadlih kritičnih ranljivosti;
• število sprejetih izjem po starosti;
• izjeme, starejše od 90 dni;
• število kritičnih izpostavljenosti, dostopnih iz interneta;
• kršitve SLA dobaviteljev;
• ranljivosti, ponovno odprte po validaciji;
• nujne spremembe zaradi izkoriščanih ranljivosti;
• odpovedi popravkov po platformi ali poslovni enoti.

Te metrike povežite z vodstvenim pregledom po ISO/IEC 27001:2022 Clause 9.3, poročanjem o upravljanju po DORA in nadzorom vodstva po NIS2. Za NIST CSF 2.0 jih uporabite za posodobitev trenutnih in ciljnih profilov, analizo vrzeli in akcijske načrte.

Clarysecov kontrolni seznam SLA za odpravo

S tem kontrolnim seznamom ocenite trenutni program:

• Ali obstaja odobrena politika upravljanja ranljivosti in popravkov?
• Ali so SLA-ji za odpravo opredeljeni glede na resnost in poslovno kritičnost?
• Ali so ranljivosti, izpostavljene internetu, in izkoriščane ranljivosti pospešeno obravnavane?
• Ali so sredstva mapirana na lastnike, storitve, podatke in dobavitelje?
• Ali se ugotovitve skenerjev pretvorijo v dodeljene zahtevke?
• Ali se popravki izvajajo prek upravljanja sprememb?
• Ali so nujne spremembe dokumentirane in pregledane?
• Ali so rezultati odprave validirani s ponovnimi skeniranji ali preverjanjem različic?
• Ali so izjeme predmet ocene tveganja, odobrene in pregledane vsaj vsakih 90 dni?
• Ali so kompenzacijske kontrole dokumentirane za sisteme, ki jih ni mogoče popraviti?
• Ali so pogodbe z dobavitelji usklajene z internimi pragovi odprave?
• Ali so dnevniki popravkov dovolj popolni, da dokazujejo, kaj se je zgodilo in kdaj?
• Ali se kršitve SLA eskalirajo in odpravijo?
• Ali vodstvo pregleduje metrike?
• Ali se ob sumu izkoriščanja sprožijo ocene incidentov in kršitev?

Če je več odgovorov »ne«, težava ni v orodjih. Težava je v zasnovi kontrol.

Naslednji koraki: spremenite roke za popravke v revizijsko pripravljeno odpornost

SLA-ji za odpravljanje ranljivosti v letu 2026 morajo narediti več kot zadovoljiti nadzorno ploščo skenerja. Dokazati morajo, da lahko vaša organizacija identificira izpostavljenost, prednostno obravnava tveganje, ukrepa v odobrenih rokih, nadzira izjeme, upravlja dobavitelje in dokazuje odločitve glede na revizijska pričakovanja ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019.

Clarysec vam lahko pomaga preiti od razdrobljenih zahtevkov za popravke k integriranemu programu odpravljanja ranljivosti, ki temelji na dokazilih, z uporabo:

• Politika upravljanja ranljivosti in popravkov
• Politika upravljanja ranljivosti in popravkov za mala in srednja podjetja
• Politika varnosti tretjih oseb in dobaviteljev za mala in srednja podjetja
• Zenith Blueprint: 30-koračni načrt za presojevalce
• Zenith Controls: vodnik za navzkrižno skladnost

Začnite z eno visoko tvegano storitvijo. Mapirajte njena sredstva, dobavitelje, ranljivosti, zahtevke, spremembe, izjeme in dokazila. Nato nanjo uporabite revizijska vprašanja. Če SLA-ja ne morete dokazati od zaznave do zaprtja, je to vaš prvi projekt odprave.

Cilj ni popolno nameščanje popravkov. Cilj je upravljana, na tveganju temelječa, merljiva in preverljiva odprava. Prenesite Clarysecove predloge politik, izvedite ciljno oceno vrzeli ali rezervirajte predstavitev Clarysec, da odpravljanje ranljivosti iz revizijskega pritiska spremenite v operativno odpornost.