Od skeniranj do dokazil: ISO 27001:2022, NIS2, DORA

Ponedeljek je, ura 08:16. Na nadzorni plošči za aplikacijski strežnik, izpostavljen internetu, se je pravkar pojavila kritična ranljivost za oddaljeno izvajanje kode. Infrastrukturna ekipa sporoči, da je popravek dobavitelja na voljo. Lastnik aplikacije opozori, da strežnik podpira delovni tok za stranke, ki je ključen za prihodke. Pravna služba vpraša, ali bi izkoriščanje lahko sprožilo poročanje po NIS2, DORA ali GDPR. CISO, Maria, odpre koledar presoj in vidi pravo težavo: nadzorna presoja ISO 27001:2022 se začne naslednji teden, pregled pripravljenosti na NIS2 že poteka, pomembna fintech stranka pa je zahtevala dokazila za DORA.

Skenirnik kaže rdeče. Tabla zahtevkov kaže dejavnost. Preglednica kaže vložen trud. Vendar nič od tega samo po sebi ne dokazuje delovanja kontrole.

To vrzel številne organizacije odkrijejo prepozno. Skeniranje ranljivosti ni isto kot pripravljenost upravljanja ranljivosti na presojo. Skeniranje pove, da je lahko nekaj narobe. Dokazila za presojo dokazujejo, da je organizacija vedela, kaj ima, ocenila tveganje, določila lastništvo, ukrepala skladno s politiko, nadzorovala spremembo, dokumentirala izjeme, preverila rezultate in pregledala izid.

Za ISO/IEC 27001:2022, NIS2 in DORA je ta veriga dokazil enako pomembna kot tehnični popravek. Skenirnik začne zgodbo. Zaključijo jo evidenca sredstev, register ranljivosti, zahtevek, odločitev o tveganju, zapis o spremembi, evidenca popravkov, dokazila o validaciji, odobritev izjeme in vodstveni pregled.

Pristop Clarysec je preprost: upravljanja ranljivosti ne obravnavajte kot mesečni tehnični ritual. Obravnavajte ga kot upravljan delovni tok dokazil.

Zakaj poročila o skeniranju niso zadostna dokazila za presojo

Skeniranje ranljivosti je tehnična ugotovitev v določenem trenutku. Prepozna lahko CVE, manjkajoč popravek, nepodprto knjižnico, izpostavljeno storitev ali šibko konfiguracijo. To je uporabno, vendar nepopolno.

Presojevalec bo postavil drugačna vprašanja:

• Ali je bilo prizadeto sredstvo vključeno v obseg?
• Kdo je lastnik sredstva in poslovne storitve?
• Ali je bila ranljivost ocenjena glede na izpostavljenost, možnost izkoriščanja, poslovni vpliv in občutljivost podatkov?
• Ali je bila odprava zaključena v opredeljenem časovnem okviru?
• Če je bila odprava odložena, kdo je sprejel preostalo tveganje?
• Ali je bil popravek uveden prek nadzorovanega upravljanja sprememb?
• Ali je bil popravek preverjen s ponovnim skeniranjem ali tehnično validacijo?
• Ali so bila dokazila hranjena in jih je pregledalo vodstvo?

Mapa izvozov iz skenirnika redko odgovori na ta vprašanja. Pri presoji ISO 27001:2022 presojevalec preverja, ali ISMS deluje tako, kot je zasnovan. Po NIS2 morajo upravljalni organi odobriti in nadzorovati ukrepe za obvladovanje tveganj kibernetske varnosti. Po DORA finančni subjekti potrebujejo dokumentiran okvir za upravljanje tveganj IKT, življenjski cikel incidentov, testiranje odpornosti in kontrole tveganj tretjih oseb na področju IKT. Po GDPR postane ključno vprašanje, ali so ustrezni tehnični in organizacijski ukrepi varovali osebne podatke ter ali je mogoče dokazati odgovornost.

Klavzule ISO/IEC 27001:2022 4.1 do 4.4 od organizacije zahtevajo razumevanje njenega konteksta, zainteresiranih strani, zahtev in obsega ISMS. Upravljanja ranljivosti in popravkov ni mogoče zasnovati ločeno. Odražati mora pogodbe s strankami, regulatorje, odvisnosti od oblaka, zunanje izvajane storitve IKT, obveznosti varstva podatkov in kritične storitve.

Klavzule ISO/IEC 27001:2022 6.1.1 do 6.1.3 zahtevajo oceno tveganja, obravnavo tveganja, izbiro kontrol, izjavo o uporabnosti in odobritev preostalega tveganja s strani lastnika tveganja. To pomeni, da morajo biti dokazila o ranljivostih povezana z registrom tveganj, načrtom obravnave tveganj in SoA.

ISO/IEC 27005:2022 ta model utrjuje s spodbujanjem organizacij, naj zahteve iz Priloge A, sektorskih obveznosti, predpisov, pogodb, notranjih pravil in obstoječih kontrol združijo v izhodišče za oceno tveganja. Poudarja tudi merila za verjetnost, posledice, zakonske obveznosti, odnose z dobavitelji, vpliv na zasebnost in vpliv tretjih oseb. V praksi ranljivost ni zgolj številka CVSS. Je tvegan dogodek, povezan s sredstvi, obveznostmi, deležniki in poslovnimi posledicami.

Regulativni pritisk v ozadju dokazil o popravkih

Sodobna regulacija kibernetske varnosti je vse manj strpna do neformalnega nameščanja popravkov.

NIS2 se uporablja za številne srednje in velike subjekte v zelo kritičnih in kritičnih sektorjih, lahko pa zajame tudi nekatere subjekte ne glede na velikost. Njen obseg vključuje ponudnike digitalne infrastrukture, kot so storitve računalništva v oblaku, storitve podatkovnih centrov, omrežja za dostavo vsebin, ponudniki javnih elektronskih komunikacij, storitve zaupanja, storitve DNS in TLD, ter ponudnike upravljanja storitev IKT, kot so ponudniki upravljanih storitev in ponudniki upravljanih varnostnih storitev. Zajema tudi pomembne digitalne ponudnike, kot so spletne tržnice, spletni iskalniki in platforme družbenih omrežij.

NIS2 Article 20 določa, da je kibernetska varnost odgovornost upravljalnega organa. 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, varnim razvojem, varnim vzdrževanjem, obravnavo in razkrivanjem ranljivosti, ocenjevanjem učinkovitosti, kibernetsko higieno, nadzorom dostopa, upravljanjem sredstev in avtentikacijo. Article 23 vzpostavlja stopenjski postopek obveščanja o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah, obvestilom v 72 urah in končnim poročilom v enem mesecu, kadar je to ustrezno.

DORA od 17. januarja 2025 vzpostavlja neposredno uporabna pravila digitalne operativne odpornosti za finančne subjekte. Zajema upravljanje tveganj IKT, poročanje o večjih incidentih, povezanih z IKT, testiranje operativne odpornosti, izmenjavo obveščevalnih podatkov o kibernetskih grožnjah, upravljanje tveganj tretjih oseb na področju IKT ter nadzor nad kritičnimi tretjimi ponudniki storitev IKT. Articles 5 in 6 uvrščata upravljanje tveganj IKT pod odgovornost upravljalnega organa in zahtevata dokumentiran, integriran in redno pregledovan okvir za upravljanje tveganj IKT. Article 8 krepi zahtevo po identifikaciji poslovnih funkcij, podprtih z IKT, informacijskih sredstev, sredstev IKT in odvisnosti. Articles 17 do 20 zahtevajo zaznavanje, evidentiranje, razvrščanje, eskalacijo, poročanje, komuniciranje, odpravo in učenje pri incidentih, povezanih z IKT. Articles 28 do 30 zahtevajo obvladovanje tveganj tretjih oseb na področju IKT prek registrov, skrbnega pregleda, pogodbenih zaščitnih ukrepov, pravic do revizije, načrtovanja izstopa in nadzora.

Za finančne subjekte, zajete z DORA, DORA praviloma nadomesti enakovredne obveznosti NIS2 glede upravljanja tveganj in poročanja. Vendar je NIS2 še vedno pomembna za usklajevanje ekosistema in subjekte zunaj obsega DORA. Za ponudnike SaaS, ponudnike upravljanih storitev in ponudnike upravljanih varnostnih storitev, ki oskrbujejo finančne stranke, je praktična posledica neposredna: stranke lahko zahtevajo vaša dokazila o ranljivostih, da izpolnijo svoje obveznosti po DORA.

GDPR dodaja še eno plast. Articles 2 in 3 se lahko uporabljata za organizacije s sedežem v EU in organizacije zunaj EU, ki ponujajo blago ali storitve posameznikom v EU ali spremljajo njihovo vedenje. Article 5 zahteva varstvo osebnih podatkov in odgovornost za skladnost. Article 4 opredeljuje kršitev varnosti osebnih podatkov kot varnostni incident, ki povzroči nenamerno ali nezakonito izgubo, uničenje, spremembo, nepooblaščeno razkritje osebnih podatkov ali nepooblaščen dostop do njih. Odložen popravek na podatkovni bazi, platformi za identitete ali portalu za stranke lahko postane vprašanje dokazovanja odgovornosti na področju zasebnosti.

Od politike do dokazil

Prvi korak je opredelitev pravil. Močna Politika upravljanja ranljivosti in popravkov ni samo dokument za presojo. Je operativna ustava za kontrolo.

Za poslovna okolja Politika upravljanja ranljivosti in popravkov izrecno povezuje tehnično nameščanje popravkov z navzkrižno skladnostjo:

Ta politika podpira skladnost z ISO/IEC 27001 Prilogo A, kontrola 8.8, in smernicami ISO/IEC 27002 ter obravnava regulativne zahteve iz DORA Article 8, NIS2 Article 21, GDPR Article 32 ter domen COBIT 2019 DSS in APO.

Iz razdelka “Namen”.

Ista politika določa upravljavski pričakovani rezultat za osrednji artefakt dokazil:

Ekipa za varnostne operacije mora vzdrževati centraliziran register upravljanja ranljivosti, CISO ali pooblaščena delegirana oseba pa ga mora pregledati mesečno.

Iz razdelka “Zahteve upravljanja”, klavzula politike 5.1.

Določa tudi pogostost skeniranja:

Vse sisteme je treba skenirati najmanj mesečno; sredstva z visokim tveganjem ali zunanje izpostavljena sredstva je treba skenirati tedensko.

Iz razdelka “Zahteve za izvajanje politike”, klavzula politike 6.1.1.

In preprečuje, da bi nujno nameščanje popravkov postalo nenadzorovana tehnična dejavnost:

Vse dejavnosti odprave morajo biti usklajene prek procesa upravljanja sprememb (skladno s P5 - Politika upravljanja sprememb), da se zagotovita stabilnost in ohranitev revizijske sledi.

Iz razdelka “Zahteve upravljanja”, klavzula politike 5.5.

Za mala in srednja podjetja je mogoče ista načela dokazil uvesti preprosteje. Politika upravljanja ranljivosti in popravkov za mala in srednja podjetja določa:

Vzdržujte točne evidence uporabljenih popravkov, odprtih težav in izjem, da zagotovite pripravljenost na presojo.

Iz razdelka “Cilji”, klavzula politike 3.4.

Nato opredeli evidenco popravkov kot dokazilo za presojo:

Evidenco popravkov je treba vzdrževati in pregledovati med presojami ter dejavnostmi odzivanja na incidente.

Iz razdelka “Zahteve upravljanja”, klavzula politike 5.4.1.

Določa tudi minimalno vsebino:

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

Iz razdelka “Zahteve upravljanja”, klavzula politike 5.4.2.

Za nujno izpostavljenost internetu politika za mala in srednja podjetja določa merljivo zahtevo:

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

Iz Politike upravljanja ranljivosti in popravkov za mala in srednja podjetja, razdelek “Zahteve za izvajanje politike”, klavzula politike 6.1.1.

Te klavzule tehnično delo pretvorijo v dokazila. Politika določi pričakovanja. Register evidentira ugotovitve. Zahtevek dodeli delo. Zapis o spremembi nadzoruje uvedbo. Evidenca popravkov dokazuje ukrepanje. Register tveganj zajame izjeme. Zapisniki pregledov dokazujejo nadzor.

Model Clarysec, usmerjen v dokazila

Model Clarysec, usmerjen v dokazila, se začne z enim načelom: vsaka ugotovitev ranljivosti mora biti sledljiva od odkritja do odločitve.

V Zenith Blueprint: 30-koračni načrt za presojevalca faza Kontrole v praksi, korak 19: Tehnološki nadzorni ukrepi I, obravnava upravljanje ranljivosti kot ponovljivo kontrolo in ne kot teoretično zahtevo:

Upravljanje ranljivosti je eno najkritičnejših področij sodobne kibernetske higiene. Čeprav požarni zidovi in protivirusna programska oprema zagotavljajo zaščito, jih lahko spodkopljejo nepopravljeni sistemi ali napačno konfigurirane storitve, ki ostanejo izpostavljene.

Isti korak pojasnjuje, da morajo organizacije uporabljati redne urnike nameščanja popravkov, skenirnike ranljivosti, triažo, dodeljevanje, sledenje odpravi, kompenzacijske kontrole in sprejem preostalega tveganja. Najpomembneje pa pravilno postavi presojevalno miselnost:

Kontrola ni namenjena popolnosti, temveč vzpostavitvi organiziranega, preglednega in odgovornega procesa.

Za presojevalce je ta razlika pomembna. Zrela organizacija ima lahko odprte ranljivosti in kljub temu dokaže nadzor, če ima prednostno razvrščanje na podlagi tveganj, dokumentirano lastništvo, odobrene izjeme, kompenzacijske kontrole in preverjeno odpravo.

Zenith Blueprint opozarja tudi, da bodo presojevalci to področje podrobno pregledali:

To je kontrola z visoko prioriteto za presojevalce in običajno se bodo vanjo poglobili. Pričakujte vprašanja o tem, kako pogosto se sistemi popravljajo, kakšen proces uporabite ob objavi ranljivosti ničtega dne in katere sisteme je najtežje popraviti.

Zato CISO v presojo ne sme vstopiti samo z nadzorno ploščo skenirnika. Paket dokazil mora pokazati upravljanje, proces, izvedbo, preverjanje in izboljšave.

Preslikava kontrol ISO 27002 v dokazila za presojo

Zenith Controls: Vodnik za navzkrižno skladnost deluje kot kompas navzkrižne skladnosti, saj preslika kontrole ISO/IEC 27002:2022 in pokaže, kako so povezane s presojevalnimi pričakovanji. Za upravljanje ranljivosti in popravkov tri kontrole ISO/IEC 27002:2022 tvorijo operativni trikotnik.

Kontrola ISO/IEC 27002:2022 8.8, Upravljanje tehničnih ranljivosti, je osrednja kontrola. Je preventivna, podpira zaupnost, celovitost in razpoložljivost, usklajena je s konceptoma kibernetske varnosti Identify in Protect ter je povezana z upravljanjem groženj in ranljivosti.

Kontrola ISO/IEC 27002:2022 8.32, Upravljanje sprememb, je prav tako preventivna. Nameščanje popravkov povezuje z nadzorovano uvedbo, testiranjem, odobritvijo, načrti povrnitve in preverljivostjo.

Kontrola ISO/IEC 27002:2022 5.36, Skladnost s politikami, pravili in standardi informacijske varnosti, zagotavlja, da proces ni neobvezen ali odvisen od individualnega herojstva. Upravljanje ranljivosti povezuje z upoštevanjem politik, zagotavljanjem zaupanja in nadzorom.

Ta preslikava prepreči pogosto pomanjkljivost pri presoji. Varnost pravi: »Popravili smo.« Operativa pravi: »Uvedli smo.« Skladnost pravi: »Zaporedja ne moremo dokazati.« Preslikana veriga dokazil vsem trem ekipam omogoča isto zgodbo.

Veriga dokazil, ki jo pričakujejo presojevalci

Zagovorljiva veriga dokazil pri upravljanju ranljivosti ima sedem faz.

Praktična razlika med »izvajamo skeniranja« in »pripravljeni smo na presojo« je neprekinjena sledljivost. Če ranljivosti ni mogoče slediti od odkritja do zaprtja, je kontrola šibka. Če obstajajo izjeme, vendar jih nihče ni odobril, je proces šibek. Če popravki obidejo upravljanje sprememb, je revizijska sled šibka. Če kritične ranljivosti ostajajo odprte brez kompenzacijskih kontrol, je upravljanje šibko.

Politika spremljanja presoj in skladnosti podpira avtomatizacijo kot del tega modela:

Avtomatizirana orodja morajo biti uvedena za spremljanje skladnosti konfiguracij, upravljanja ranljivosti, statusa popravkov in privilegiranega dostopa.

Iz razdelka “Zahteve za izvajanje politike”, klavzula politike 6.4.1.

Za mala in srednja podjetja Politika spremljanja presoj in skladnosti za mala in srednja podjetja opredeli preverjanje tehničnih kontrol v praktičnih izrazih:

Preverjanje tehničnih kontrol (npr. stanje varnostnega kopiranja, konfiguracija nadzora dostopa, zapisi o popravkih).

Iz razdelka “Zahteve za izvajanje politike”, klavzula politike 6.1.1.2.

Majhne organizacije ne potrebujejo orodij ravni velikih podjetij, da postanejo pripravljene na presojo. Potrebujejo dosledna dokazila. Enostaven register, tabla zahtevkov, evidenca popravkov in mesečni pregled so lahko zadostni, če so popolni, ažurni in povezani s tveganji.

Primer: ena kritična ugotovitev, v celoti pripravljena za presojo

Marijino tedensko zunanje skeniranje prepozna CVE-2026-12345 na internetno izpostavljenem plačilnem prehodu API. Skenirnik jo oceni kot kritično. Storitev obdeluje podatke o identiteti strank in metapodatke transakcij, zato so možne posledice po GDPR in DORA. Prehod je v lasti ekipe za platformski inženiring, vendar popravek zahteva kratek izpad.

Tako je videti delovni tok, pripravljen za presojo.

1. Ustvarite vnos v registru ranljivosti

Varnostna ekipa zabeleži ugotovitev v centralni register:

• ID ugotovitve: VULN-2026-0142
• Vir: tedensko zunanje skeniranje
• Datum in čas odkritja
• Sredstvo: api-gw-prod-01
• Lastnik: ekipa za platformski inženiring
• Izpostavljenost: dostopno iz interneta
• Kontekst podatkov: identiteta strank in metapodatki transakcij
• Resnost: kritična
• SLA: 72 ur ali strožje glede na politiko
• Zahtevek: SEC-4821
• Zapis o spremembi: CHG-10988
• Status: odprava načrtovana

2. Izvedite triažo glede na poslovni in regulativni kontekst

Ekipa preveri razpoložljivost izkoriščanja, napadalno površino, zahteve avtentikacije, poslovni vpliv in občutljivost podatkov. Ker je sistem izpostavljen internetu in podpira delovne tokove za stranke, ranljivost ostane kritična. Lastnik tveganja je vodja platforme, CISO pa je obveščen zaradi možnih posledic po NIS2, DORA in GDPR.

Klavzule ISO/IEC 27005:2022 7.1 do 7.4 podpirajo identifikacijo tveganj, lastništvo, posledice, verjetnost in prednostno razvrščanje. Klavzule 8.2 do 8.6 podpirajo izbiro obravnave, določitev kontrol, povezavo s SoA, načrtovanje obravnave in odobritev preostalega tveganja.

3. Odprite nadzorovano nujno spremembo

Popravek je načrtovan za isti večer. Zapis o spremembi vključuje referenco dobavitelja, prizadete storitve, testni načrt, načrt povrnitve, vzdrževalno okno, odločitev o komunikaciji s strankami, odobritve in zahtevo za validacijo po uvedbi.

To neposredno podpira kontrolo ISO/IEC 27002:2022 8.32 in zahtevo poslovne politike, da se odprava uskladi prek upravljanja sprememb.

4. Namestite popravek in posodobite evidenco popravkov

Evidenca popravkov zabeleži ime naprave, uporabljeno posodobitev, datum namestitve popravka in razlog za zamudo, če obstaja. Če bi bila namestitev popravka odložena, bi ekipa dokumentirala kompenzacijske kontrole, kot so pravila WAF, začasne omejitve dostopa, okrepljeno beleženje, izolacija ali okrepljeno spremljanje.

5. Preverite in zaprite

Varnost ponovno skenira prehod API. Ranljivost se ne pojavi več. Zahtevek se posodobi z dokazilom čistega skena, različico popravka, časovnim žigom uvedbe in povezavo do zapisa o spremembi. Status v registru ranljivosti se spremeni v »Zaprto, preverjeno«.

6. Preglejte vpliv na poročanje

Če ni bilo izkoriščanja in ni bilo prekinitve storitve, poročanje o incidentu po NIS2 ali DORA morda ni sproženo. Če se odkrijejo indikatorji kompromitacije, mora proces upravljanja incidentov razvrstiti vpliv in eskalacijo. Po NIS2 lahko pomemben incident zahteva zgodnje opozorilo in stopenjsko poročanje. Po DORA večji incident, povezan z IKT, zahteva razvrstitev in poročanje prek ustreznega postopka pristojnega organa.

7. Vključite pridobljene izkušnje v vodstveni pregled

Ob koncu meseca pregled CISO zabeleži, da je bila ranljivost zaznana s tedenskim zunanjim skeniranjem, odpravljena znotraj SLA, preverjena s ponovnim skeniranjem in zaprta brez incidenta. Če se podobne težave ponavljajo, lahko načrt obravnave tveganj vključuje izhodišča varne konfiguracije, avtomatizirano uvajanje popravkov, eskalacijo pri dobavitelju ali modernizacijo aplikacije.

Ko presojevalec vpraša o CVE-2026-12345, lahko Maria namesto e-pošte in posnetkov zaslona predstavi urejen paket.

To je pripravljeno za presojo. Ne zato, ker organizacija ni imela ranljivosti, temveč zato, ker je imela nadzor.

En nabor dokazil, več obveznosti

Dobro zasnovan program upravljanja ranljivosti in popravkov lahko izpolni več okvirov brez podvajanja dela.

Za ISO 27001:2022 dokazila podpirajo ISMS na podlagi tveganj, implementacijo kontrol iz Priloge A, izjavo o uporabnosti, načrte obravnave tveganj, notranjo presojo in nenehno izboljševanje. Če je kontrola ISO/IEC 27002:2022 8.8 v SoA uporabljiva, mora biti organizacija sposobna prikazati pravno, regulativno, tveganjsko ali poslovno utemeljitev. Ta utemeljitev pogosto vključuje NIS2 Article 21, obveznosti DORA glede tveganj IKT, odgovornost po GDPR, pogodbe s strankami in potrebe po operativni odpornosti.

Za NIS2 ista dokazila pomagajo dokazati ukrepe iz Article 21, vključno z analizo tveganj, obravnavo ranljivosti, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, kibernetsko higieno, nadzorom dostopa in ocenjevanjem učinkovitosti. Article 20 se dokazuje s pregledom CISO, poročanjem upravnemu odboru, odobritvijo vodstva in usposabljanjem za kibernetsko varnost. Article 23 postane relevanten, če izkoriščanje povzroči ali bi lahko povzročilo resno operativno motnjo, finančno izgubo ali škodo drugim.

Za DORA dokazila o ranljivostih in popravkih podpirajo okvir za upravljanje tveganj IKT, nadzor upravljalnega organa, strategijo odpornosti, zaznavanje in razvrščanje incidentov, testiranje odpornosti ter nadzor tretjih oseb na področju IKT. Kadar ponudnik IKT gosti ali upravlja prizadeti sistem, Articles 28 do 30 zahtevajo skrbni pregled, pogodbene zaščite, pravice do revizije, pomoč pri incidentih in premisleke o izstopu.

Za GDPR ista dokazila podpirajo odgovornost po Article 5 in varnostni profil tveganj, pričakovan po Article 32. Če ranljivost povzroči nepooblaščen dostop, spremembo, izgubo ali razkritje osebnih podatkov, postanejo časovnica ranljivosti, zapisi o popravkih, dnevniki spremljanja in zapiski ocene kršitve bistveni.

Za COBIT 2019 in zagotavljanje zaupanja po pristopu ISACA se upravljanje ranljivosti ocenjuje prek operativne varnosti, spremljanja kontrol, omogočanja sprememb in odgovornosti upravljanja. Reference navzkrižne skladnosti v Zenith Blueprint izpostavljajo COBIT 2019 DSS05.04 in BAI09.02 ter pričakovanja ITAF glede zagotavljanja zaupanja pri upravljanju ranljivosti, nameščanju popravkov in varnem upravljanju sprememb.

Podporni standardi ISO krepijo operativni model. ISO/IEC 27005:2022 podpira oceno in obravnavo tveganja. ISO/IEC 27035:2023 podpira odziv na incidente, ko se ranljivosti izkoristijo. ISO/IEC 30111 podpira procese obravnave ranljivosti. ISO/IEC 29147 podpira razkrivanje ranljivosti in obvestila. ISO/IEC 27017 podpira upravljanje ranljivosti v oblaku. ISO 22301 podpira načrtovanje neprekinjenega poslovanja, kadar bi tehnične ranljivosti lahko prekinile poslovne storitve.

Kako različni presojevalci testirajo isti proces

Različni ocenjevalci uporabljajo različne poglede. Dokazila so lahko ista, vprašanja pa se spremenijo.

Politika pove, kaj se mora zgoditi. Operativna dokazila pokažejo, kaj se je zgodilo. Zapisi pregledov pokažejo, da je vodstvo vedelo, izpodbijalo in ukrepalo.

Pogosti razlogi, zakaj upravljanje popravkov ne prestane presoje

Večine ugotovitev ne povzroči odsotnost skenirnika. Povzroči jih prekinjena sledljivost.

Evidenca sredstev je nepopolna.
Če skenirnik najde sredstva, ki manjkajo v CMDB ali registru sredstev, lastništva in poslovnega vpliva ni mogoče zanesljivo oceniti. To spodkopava obseg, oceno tveganja in obravnavo tveganja po ISO 27001:2022.

Ranljivosti se spremljajo samo v skenirniku.
Nadzorne plošče skenirnikov niso upravljavski registri. Pogosto nimajo odobritve lastnika tveganja, utemeljitve izjeme, sklicev na spremembe in poslovnega konteksta.

Kritične ugotovitve nimajo dokazil o SLA.
Politika lahko določa, da se kritične ranljivosti odpravijo v treh dneh. Presojevalno vprašanje je, ali zapisi dokazujejo, da se je to zgodilo.

Izjeme so neformalne.
Zastareli sistemi, omejitve zaradi izpadov in zamude dobaviteljev se dogajajo. Toda »nismo mogli namestiti popravka« mora postati dokumentirana izjema s kompenzacijskimi kontrolami, datumom poteka in odobritvijo preostalega tveganja.

Nujno nameščanje popravkov obide upravljanje sprememb.
Nujne spremembe so še vedno spremembe. Če ni dokazil o odobritvi, testiranju ali povrnitvi, lahko presojevalci sklenejo, da je odprava ustvarila operativno tveganje.

Sistemi tretjih oseb so nevidni.
Po NIS2 in DORA sta tveganje dobaviteljev in tveganje tretjih oseb na področju IKT osrednja. Če ponudnik popravi platformo, še vedno potrebujete dokazila, pogodbene pravice, poročanje o storitvah in eskalacijske poti.

Nihče ne pregleduje trendov.
Ponavljajoče se ranljivosti lahko kažejo na šibko upravljanje konfiguracije, slabe prakse varnega razvoja kode, nepodprta sredstva ali odpoved dobavitelja. Mesečni pregled tehnične podatke pretvori v upravljavsko ukrepanje.

Presojevalni paket Clarysec za ranljivosti

Za prihajajoči pregled pripravljenosti na ISO 27001:2022, NIS2 ali DORA Clarysec organizacijam pomaga sestaviti presojevalni paket za upravljanje ranljivosti in popravkov, ki vključuje:

• Politiko upravljanja ranljivosti in popravkov, vključno z obsegom, vlogami, pogostostjo skeniranja, SLA za popravke in pravili izjem
• Izvleček evidence sredstev, ki prikazuje sisteme v obsegu, lastnike, kritičnost in izpostavljenost
• Najnovejša notranja in zunanja poročila o skeniranju ranljivosti
• Centralni register upravljanja ranljivosti z odprtimi, zaprtimi in izvzetimi postavkami
• Evidence popravkov, ki prikazujejo napravo, posodobitev, datum popravka in razloge za zamudo
• Zapise o spremembah za vzorčene kritične in visoke ranljivosti
• Dokazila o ponovnih skeniranjih ali validaciji po odpravi
• Odobritve izjem in preostalega tveganja za sisteme z odloženo odpravo ali sisteme, ki jih ni mogoče popraviti
• Proces spremljanja varnostnih obvestil za dobavitelje, knjižnice in storitve v oblaku
• Mesečne zapisnike pregledov CISO ali vodstva
• Navzkrižno preslikavo na obveznosti ISO 27001:2022, NIS2, DORA, GDPR in COBIT 2019
• Rezultate notranje presoje ali preverjanja tehničnih kontrol

V Zenith Blueprint, faza Presoja, pregled in izboljšanje, korak 24, Clarysec poudarja sledljivost med izjavo o uporabnosti, registrom tveganj in načrtom obravnave tveganj:

Vaša SoA mora biti skladna z registrom tveganj in načrtom obravnave tveganj. Dvakrat preverite, da je vsaka kontrola, ki ste jo izbrali kot obravnavo tveganja, v SoA označena kot »Applicable«.

To je posebej pomembno za upravljanje ranljivosti. Če je kontrola 8.8 uporabljiva, mora presojevalni paket dokazati ne le, da se skeniranje izvaja, temveč tudi, da so ugotovitve upravljane prek obravnave tveganj in nenehnega izboljševanja.

30-dnevni sprint pripravljenosti

Če je presoja blizu, ne začnite s prepisovanjem vsega. Začnite s hitrim ustvarjanjem dokazil.

Ta sprint ne bo odpravil vsega tehničnega dolga. Spremenil pa bo presojevalni pogovor. Namesto zagovarjanja neurejenega izvoza iz skenirnika lahko pokažete upravljan proces z lastniki, časovnicami, ukrepi, odločitvami in nadzorom.

Prehod od skeniranj k zagovorljivim dokazilom

Pripravljenost upravljanja ranljivosti in popravkov na presojo ne pomeni dokazovanja, da nimate ranljivosti. Pomeni dokazovanje, da jih znate najti, razumeti, prednostno razvrstiti, odpraviti, nadzorovati izjeme in dokazati nadzor.

Clarysec Zenith Blueprint, Zenith Controls, Politika upravljanja ranljivosti in popravkov, Politika upravljanja ranljivosti in popravkov za mala in srednja podjetja, Politika spremljanja presoj in skladnosti in Politika spremljanja presoj in skladnosti za mala in srednja podjetja zagotavljajo strukturo za vzpostavitev tega delovnega toka dokazil.

Če se vaša organizacija pripravlja na certifikacijo ISO 27001:2022, pripravljenost na NIS2, digitalno operativno odpornost po DORA, skrbni pregled strank ali notranjo presojo, začnite z enim vprašanjem:

Ali je mogoče vsako kritično ranljivost slediti od skeniranja do zaprtja?

Če je odgovor ne, vam Clarysec lahko pomaga vzpostaviti register, nabor politik, preslikavo navzkrižne skladnosti, paket vodstvenega pregleda in delovni tok dokazil, pripravljen za presojo, ki tehnično skeniranje pretvori v zagovorljivo upravljanje.