CVD za NIS2 in DORA: mapa dokazil ISO 27001

V torek ob 08:17 varnostni poštni predal prejme sporočilo neodvisnega raziskovalca. Zadeva je mirna, skoraj vljudna: »Možen prevzem računa v vašem portalu za stranke.« Vsebina je manj prijetna. Raziskovalec trdi, da verižna ranljivost v vaši aplikaciji SaaS enemu najemniku omogoča dostop do evidenc računov drugega najemnika. Priložen je dokaz koncepta, šifriran z vašim objavljenim ključem PGP.

Za Mario, novo vodjo informacijske varnosti pri FinanTechSaaS, trenutek ne bi mogel biti slabši. Njeno podjetje je pravkar podpisalo pomembno pogodbo z vodilno banko v EU. Naročnikova ekipa za skrbni pregled je že zahtevala »Politiko usklajenega razkrivanja ranljivosti« in dokazila o izvajanju, z izrecnim sklicevanjem na NIS2 in DORA. Podjetje ima e-poštni naslov security@, vendar ga spremlja en razvijalec. Ni formalnega registra prejetih prijav, ni opredeljenega SLA za preverjanje, ni eskalacijske poti do vodstva in ni revizijske sledi.

Hkrati začnejo teči tri ure.

Prva ura je operativna. Ali je ranljivost resnična? Ali jo je mogoče izkoristiti v produkciji? Ali jo kdo že aktivno zlorablja?

Druga ura je regulativna. Če so podatki strank izpostavljeni, se začne presoja kršitve po GDPR. Če je izvajanje storitve prizadeto pri bistvenem ali pomembnem subjektu po NIS2, se lahko sprožijo pragi za poročanje o incidentih. Če je podjetje finančni subjekt ali ponudnik IKT, ki podpira finančne storitve, lahko postanejo relevantna pravila DORA o upravljanju incidentov, razvrščanju, eskalaciji in komunikaciji s strankami.

Tretja ura je dokazna. Šest mesecev pozneje lahko presojevalec ISO/IEC 27001:2022, nadzornik finančnega sektorja, naročnikova ekipa za zagotavljanje zaupanja ali odbor za notranjo revizijo vpraša: »Pokažite nam, kako ste obravnavali to ranljivost.«

Pri tem vprašanju številne organizacije ugotovijo, da usklajeno razkrivanje ranljivosti ni samo varnostni poštni predal. Je sistem upravljanja. Potrebuje lastništvo politike, javni kanal za poročanje, delovni tok triaže, SLA za odpravo, eskalacijo dobaviteljev, logiko odločanja o incidentih, pregled z vidika zasebnosti, poročanje vodstvu in dokazila, ki vzdržijo presojo.

Clarysec obravnava CVD kot integriran vzorec kontrol, ne kot samostojen nabiralnik. V Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint se obravnava ranljivosti pojavi v fazi Udejanjanje kontrol, 19. korak: Tehnološke kontrole I, kjer so navodila jasna: organizacije ugotovitev o ranljivostih ne smejo pasivno arhivirati, temveč morajo izvesti triažo, jih dodeliti in spremljati do zaprtja. Enak standard velja za zunanja razkritja. Če vam nekdo pove, kako lahko vaša storitev odpove, je pravo vprašanje: ali lahko dokažete, da ste prijavo prejeli, ocenili, prednostno obravnavali, odpravili, komunicirali in iz nje izpeljali pridobljene izkušnje?

Zakaj je CVD po NIS2 in DORA vprašanje na ravni upravnega odbora

Varnostno ozaveščene organizacije so leta vabile etične hekerje k poročanju o ranljivostih, ker je bila to dobra praksa. Po NIS2 in DORA je ta praksa postala del regulirane digitalne odpornosti.

NIS2 velja za številne srednje velike in večje subjekte v sektorjih visoke kritičnosti in drugih kritičnih sektorjih, vključno s ponudniki digitalne infrastrukture, ponudniki storitev računalništva v oblaku, ponudniki storitev podatkovnih centrov, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev ter nekaterimi digitalnimi ponudniki, kot so spletne tržnice, iskalniki in platforme družbenih omrežij. Ne glede na velikost se lahko uporablja tudi za kategorije, kot so ponudniki storitev zaupanja, ponudniki storitev DNS, registri TLD ter ponudniki javnih elektronskih komunikacijskih omrežij ali storitev.

NIS2 Article 21 od bistvenih in pomembnih subjektov zahteva uvedbo ustreznih in sorazmernih tehničnih, operativnih in organizacijskih ukrepov za obvladovanje tveganj kibernetske varnosti z uporabo pristopa, ki zajema vse vrste nevarnosti. Eno od minimalnih področij je varnost pri nabavi, razvoju in vzdrževanju omrežnih in informacijskih sistemov, vključno z obravnavo in razkrivanjem ranljivosti. Ista izhodiščna zahteva zajema tudi obravnavanje incidentov, varnost dobavne verige, neprekinjeno poslovanje, nadzor dostopa, upravljanje sredstev, usposabljanje, kriptografijo in postopke za ocenjevanje učinkovitosti kontrol.

NIS2 Article 20 izrecno določa tudi odgovornost vodstva. Organi vodenja morajo odobriti ukrepe za obvladovanje tveganj kibernetske varnosti, nadzorovati njihovo izvajanje in se usposabljati. Za program CVD to pomeni, da morata upravni odbor ali višje vodstvo razumeti kanal za poročanje, skupino za odziv na ranljivosti, roke za preverjanje, pričakovanja glede odprave, odvisnosti od dobaviteljev in sprožilce poročanja o incidentih.

DORA od 17. januarja 2025 uvaja sektorski režim za finančne subjekte. Zajema upravljanje IKT-tveganj, poročanje o incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti, izmenjavo informacij, tveganja tretjih oseb na področju IKT, pogodbene zahteve, nadzor nad kritičnimi ponudniki storitev IKT tretjih oseb in sodelovanje z nadzornimi organi. Za finančne subjekte, ki jih zajema DORA, ima DORA pri upravljanju IKT-tveganj in poročanju o incidentih praviloma prednost pred NIS2, ker je sektorski pravni akt Unije. Praktična zahteva pa ostaja enaka: finančni subjekti in ponudniki IKT, ki jih oskrbujejo, morajo izvajati strukturiran, dokumentiran in preverljiv proces za identifikacijo, analizo, razvrščanje, eskalacijo, odpravo in učenje iz slabosti na področju IKT.

Poročilo o ranljivosti se lahko začne kot tehnična ugotovitev, postane varnostni dogodek, eskalira v incident, sproži presojo kršitve varnosti osebnih podatkov po GDPR, zahteva ukrepanje dobavitelja in se pozneje pojavi v izjavi o uporabnosti (SoA) po ISO/IEC 27001:2022. Zato mora biti CVD zasnovan kot enoten operativni model za varnost, skladnost, inženiring, pravo, zasebnost, nabavo in vodstvo.

Temelj ISO 27001: od razkritja do dokazil ISMS

ISO/IEC 27001:2022 vodjem informacijske varnosti in odgovornim za skladnost zagotavlja sistem upravljanja, zaradi katerega je CVD primeren za presojo.

Klavzule 4.1 do 4.4 zahtevajo, da organizacija razume notranja in zunanja vprašanja, zahteve zainteresiranih strani, meje ISMS in odvisnosti od drugih organizacij. Tu v ISMS vstopijo NIS2, DORA, GDPR, pogodbe s strankami, obveznosti dobaviteljev in zaveze glede razkrivanja ranljivosti.

Klavzule 5.1 do 5.3 vzpostavljajo odgovornost vodstva. Najvišje vodstvo mora informacijsko varnost uskladiti s strateško usmeritvijo, zagotoviti vire, dodeliti odgovornosti in zagotoviti, da ISMS dosega predvidene rezultate. Za CVD to pomeni imenovanje skupine za odziv na ranljivosti, opredelitev pooblastil za sprejem preostalega tveganja in eskalacijo ranljivosti z velikim vplivom vodstvu.

Klavzule 6.1.1 do 6.1.3 zagotavljajo mehanizem za upravljanje tveganj. Organizacija mora določiti merila tveganj, oceniti tveganja informacijske varnosti, dodeliti lastnike tveganj, izbrati možnosti obravnave tveganj, primerjati kontrole s Prilogo A, pripraviti izjavo o uporabnosti in pridobiti odobritev preostalega tveganja. Klavzule 8.1 do 8.3 nato zahtevajo operativni nadzor, načrtovane spremembe, nadzor zunanje zagotovljenih procesov, ocene tveganj v načrtovanih intervalih ali po pomembnih spremembah ter dokazila o rezultatih obravnave tveganj.

V Zenith Blueprint, faza Upravljanje tveganj, 13. korak, je izjava o uporabnosti opisana kot več kot preglednica skladnosti:

»SoA je dejansko povezovalni dokument: povezuje vašo oceno/obravnavo tveganj z dejanskimi kontrolami, ki jih imate.«
Vir: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Upravljanje tveganj, 13. korak: Načrtovanje obravnave tveganj in izjava o uporabnosti (SoA) Zenith Blueprint

Za usklajeno razkrivanje ranljivosti mora SoA povezati regulativne obveznosti, poslovno tveganje, kontrole iz Priloge A, klavzule politike in operativna dokazila.

Cilj ni ustvariti vzporednih silosov skladnosti. Politika CVD mora biti nadzorovan proces ISMS, ki hkrati podpira certifikacijo ISO/IEC 27001:2022, skladnost z NIS2, pripravljenost za DORA, zagotavljanje zaupanja naročnikov in varnostne operacije.

Izhodišče politike: kaj mora določati vaša politika CVD

Prva vidna kontrola je javni kanal za razkritje. Raziskovalci, stranke, dobavitelji in partnerji morajo vedeti, kam poročati ranljivosti in kako zaščititi občutljiva dokazila.

Clarysecova Politika usklajenega razkrivanja ranljivosti Politika usklajenega razkrivanja ranljivosti zagotavlja izhodišče za podjetja:

»Javni kanali za razkritje: organizacija mora vzdrževati jasen kanal za poročanje o ranljivostih, kot je namenski varnostni e-poštni naslov za stik (na primer security@company.com) ali spletni obrazec. Te informacije morajo biti objavljene na varnostni strani spletnega mesta podjetja skupaj z javnim ključem PGP organizacije, da se omogočijo šifrirane oddaje.«
Vir: Politika usklajenega razkrivanja ranljivosti, zahteve za implementacijo, klavzula 6.1

Ta klavzula odpravlja pogosto pomanjkljivost pri presoji. Številne organizacije trdijo, da sprejemajo prijave, vendar je pot poročanja skrita, nešifrirana ali v lasti napačne ekipe. Zrel kanal je javen, varen, spremljan in dodeljen odgovorni funkciji.

Naslednja kontrola je disciplina odzivanja. Kritična prijava, ki ji sledi molk, ustvarja tveganje razkritja, tveganje ugleda in tveganje izkoriščanja. Politika usklajenega razkrivanja ranljivosti določa konkretno pričakovanje glede potrditve prejema in preverjanja:

»Triaža in potrditev prejema: ob prejemu poročila ga mora VRT evidentirati in poročevalcu v 2 delovnih dneh poslati potrditev prejema ter dodeliti referenco za sledenje. VRT mora izvesti preliminarno oceno resnosti, na primer z uporabo točkovanja CVSS, in preveriti težavo, po potrebi tudi s podporo IT- in razvojnih ekip, v ciljnem roku 5 delovnih dni. Kritične ranljivosti, na primer tiste, ki omogočajo oddaljeno izvajanje kode ali večjo kršitev varnosti osebnih podatkov, je treba obravnavati pospešeno.«
Vir: Politika usklajenega razkrivanja ranljivosti, zahteve za implementacijo, klavzula 6.4

To besedilo takoj ustvari dokazilne točke: čas prejema, čas potrditve, referenco za sledenje, preliminarno resnost, izid preverjanja in odločitev o pospešeni obravnavi.

Za MSP Clarysec uporablja isto logiko s sorazmerno implementacijo. Politika zahtev za varnost aplikacij za MSP Politika zahtev za varnost aplikacij - SME od organizacij zahteva, da:

»določijo obveznosti glede razkrivanja ranljivosti, odzivnih časov in nameščanja popravkov.«
Vir: Politika zahtev za varnost aplikacij za MSP, zahteve upravljanja, klavzula 5.3.2

Za odgovornost ne potrebujete velike ekipe za varnost produktov. Potrebujete izrecne obveznosti, realistične roke, imenovane lastnike in dokazila, da proces deluje.

Delovni tok prejema CVD: od e-pošte raziskovalca do zapisa odločitve

Dober delovni tok prejema je dovolj preprost za izvajanje pod pritiskom in dovolj popoln, da zadosti presojevalcu. Začeti se mora z namenskim kanalom, kot je security@[company], spletni obrazec ali objavljena datoteka security.txt. Pot oddaje mora omogočati šifrirana dokazila, navedbo prizadetega produkta ali končne točke, korake za reprodukcijo, kontaktne podatke poročevalca, želeni čas razkritja ter vsak znak izpostavitve podatkov ali aktivnega izkoriščanja.

Po prejemu mora skupina za odziv na ranljivosti ustvariti zapis v orodju GRC, sistemu za upravljanje zahtevkov, sistemu za upravljanje ranljivosti ali nadzorovanem registru. Orodje je manj pomembno kot doslednost in kakovost dokazil.

Delovni tok mora nato potekati skozi sedem operativnih korakov.

1. Prejem: poročilo je prejeto prek javnega kanala in samodejno ali ročno zabeleženo.
2. Potrditev prejema: VRT odgovori v 2 delovnih dneh in dodeli referenco za sledenje.
3. Preverjanje: tehnična ekipa reproducira težavo, potrdi prizadete sisteme in izvede preliminarno točkovanje resnosti.
4. Presoja dogodka: VRT ugotovi, ali je ranljivost zgolj slabost, dogodek informacijske varnosti ali incident.
5. Eskalacija: visoke ali kritične zadeve se po potrebi posredujejo lastnikom sistemov, CISO, funkciji zasebnosti, pravni službi, dobaviteljem in vodstvu.
6. Odprava: odgovorna ekipa izvede popravek, ukrep za ublažitev, kompenzacijsko kontrolo ali začasno omejitev.
7. Zaprtje: VRT preveri popravek, komunicira z raziskovalcem, posodobi datoteko dokazil in zabeleži pridobljene izkušnje.

Clarysec ta operativni korak prek Zenith Controls: The Cross-Compliance Guide Zenith Controls mapira na kontrolo ISO/IEC 27002:2022 A.5.25, Presoja in odločanje o dogodkih informacijske varnosti, ter kontrolo A.8.8, Upravljanje tehničnih ranljivosti. Za A.5.25 Zenith Controls pojasnjuje, da je presoja dogodkov funkcija triaže med surovimi opozorili spremljanja in formalnim obravnavanjem incidentov, pri čemer uporablja dnevnike, pragove in merila odločanja za določitev eskalacije. Za A.8.8 Zenith Controls povezuje upravljanje tehničnih ranljivosti z zaščito pred zlonamerno programsko opremo, upravljanjem konfiguracije, upravljanjem sprememb, varnostjo končnih točk, obveščevalnimi podatki o grožnjah, spremljanjem, varnim razvojem, presojo dogodkov in odzivom na incidente.

En odlomek iz Zenith Controls je posebej uporaben, kadar obstaja sum aktivnega izkoriščanja:

»Obveščevalni podatki o grožnjah pokažejo, katere ranljivosti se aktivno izkoriščajo, in usmerjajo določanje prioritet pri nameščanju popravkov.«
Vir: Zenith Controls: The Cross-Compliance Guide, kontrola ISO/IEC 27002:2022 8.8, povezava s kontrolo 5.7 Obveščevalni podatki o grožnjah Zenith Controls

To je pomembna točka upravljanja. Resnost ni samo CVSS. Ranljivost s srednjo oceno, ki se aktivno izkorišča proti vašemu sektorju, lahko prehiti teoretično kritično težavo na neizpostavljenem testnem sistemu.

Kdaj ranljivost postane incident

Vsako poročilo o ranljivosti ni incident. Manjkajoča varnostna glava v pripravljalnem okolju ni enaka izkoriščenemu obvodu avtorizacije, ki izpostavi račune strank. Vsako verodostojno poročilo o ranljivosti pa mora skozi odločitvena vrata za incident.

NIS2 Article 23 od bistvenih in pomembnih subjektov zahteva, da svojemu CSIRT ali pristojnemu organu brez nepotrebnega odlašanja priglasijo incidente, ki pomembno vplivajo na zagotavljanje storitev. Pomemben incident je incident, ki je povzročil ali lahko povzroči hudo operativno motnjo ali finančno izgubo ali je vplival oziroma lahko vpliva na druge s povzročitvijo znatne materialne ali nematerialne škode. Zaporedje poročanja vključuje zgodnje opozorilo v 24 urah po seznanitvi, obvestilo o incidentu v 72 urah, vmesna poročila na zahtevo in končno poročilo v enem mesecu po 72-urnem obvestilu.

DORA Articles 17 to 20 od finančnih subjektov zahtevajo zaznavanje, upravljanje, evidentiranje, razvrščanje, eskalacijo, obveščanje in komuniciranje incidentov, povezanih z IKT, ter pomembnih kibernetskih groženj. Večje incidente, povezane z IKT, je treba eskalirati višjemu vodstvu in organu upravljanja. Komunikacija s strankami je lahko zahtevana, kadar so prizadeti finančni interesi.

Pri MSP mora biti kultura poročanja enako jasna. Clarysecova Politika odzivanja na incidente za MSP Politika odzivanja na incidente - SME določa:

»Osebje mora vsako sumljivo dejavnost ali potrjen incident prijaviti na incident@[company] ali ustno generalnemu direktorju ali ponudniku IT-podpore.«
Vir: Politika odzivanja na incidente za MSP, zahteve za izvajanje politike, klavzula 6.2.1

V Zenith Blueprint, faza Udejanjanje kontrol, 16. korak: Kontrole za ljudi II, je načelo še preprostejše:

»Če ste v dvomih, poročajte.«
Vir: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Udejanjanje kontrol, 16. korak: Kontrole za ljudi II (A.6.5 to A.6.8)

Ta stavek mora veljati za razvijalce, podporne ekipe, upravljavce dobaviteljev, vodje zasebnosti, izvršno vodstvo in zunanje izvajalce. Ranljivost, ki lahko vpliva na zaupnost, celovitost, razpoložljivost, zaupanje strank, regulativno poročanje ali finančno poslovanje, mora biti evidentirana in ocenjena, ne neformalno obravnavana v klepetu.

Odprava, nameščanje popravkov in kompenzacijske kontrole

Ko je ranljivost preverjena, jo je treba obravnavati. Obravnava mora temeljiti na tveganju, biti podprta z dokazili in časovno omejena.

Politika usklajenega razkrivanja ranljivosti določa pričakovanje za podjetja:

»Načrt odprave: za vse potrjene ranljivosti mora biti pripravljen načrt odprave ali ublažitve. Implementacija popravka mora biti prednostno razvrščena glede na resnost. Kritične ranljivosti je treba na primer odpraviti ali ublažiti v 14 dneh, kadar je to izvedljivo, ali prej, kadar je zaznano aktivno izkoriščanje, medtem ko je treba zadeve nižje resnosti obravnavati v razumnem roku. Kadar se celovita odprava zamakne, je treba uvesti kompenzacijske kontrole ali začasne ukrepe za ublažitev, kot sta onemogočanje ranljive funkcionalnosti ali povečanje spremljanja.«
Vir: Politika usklajenega razkrivanja ranljivosti, zahteve za implementacijo, klavzula 6.6

Za disciplino nameščanja popravkov v MSP Politika upravljanja ranljivosti in popravkov za MSP Politika upravljanja ranljivosti in popravkov - SME določa:

»Kritični popravki morajo biti nameščeni v 3 dneh od izdaje, zlasti za sisteme, izpostavljene internetu«
Vir: Politika upravljanja ranljivosti in popravkov za MSP, zahteve za izvajanje politike, klavzula 6.1.1

Ti roki si ne nasprotujejo. Popravek dobavitelja za sistem, izpostavljen internetu, lahko zahteva zelo hitro uvedbo. Ranljivost produkta, ki zahteva spremembe kode, regresijsko testiranje, usklajevanje s strankami in postopno izdajo, lahko zahteva načrt odprave z začasnimi ukrepi za ublažitev. Ključno je, da je odločitev dokumentirana, da ima lastnika tveganja in da je odobrena, kadar preostalo tveganje ostane.

Praktičen potek primera je takšen:

1. Raziskovalec prijavi obvod avtorizacije v API za obračunavanje strankam.
2. VRT zabeleži CVD-2026-014 s časovnim žigom in potrdi prejem v 2 delovnih dneh.
3. Varnost produktov v 24 urah preveri napako in zaradi dostopa do podatkov med najemniki dodeli visoko resnost.
4. Funkcija zasebnosti izvede presojo kršitve po GDPR, ker lahko evidence računov vsebujejo osebne podatke.
5. Vodja incidentov odpre presojo dogodka po kontroli ISO/IEC 27002:2022 A.5.25.
6. Lastnik sistema z začasno funkcijsko zastavico onemogoči ranljivo končno točko.
7. Inženiring pripravi hitri popravek po kontroli ISO/IEC 27002:2022 A.8.32, upravljanje sprememb.
8. Dodana so pravila spremljanja za kazalnike izkoriščanja, povezana z A.8.15, beleženje, in A.8.16, dejavnosti spremljanja.
9. CISO obvesti višje vodstvo, ker je zadeva visoko tvegana.
10. VRT se z raziskovalcem uskladi glede ponovnega testiranja in časa razkritja.
11. Lastnik tveganja odobri zaprtje šele po preveritvenem testiranju in pregledu vpliva na stranke.
12. SoA, register tveganj, zahtevek, dnevniki, obvestilo vodstvu in pridobljene izkušnje se posodobijo.

To je razlika med »namestili smo popravek« in »lahko dokažemo, da smo zadevo upravljali«.

Odvisnosti od dobaviteljev in oblaka: skrita točka odpovedi

Številni neuspehi CVD so v resnici prikriti neuspehi dobaviteljev. Ranljivost lahko vpliva na komponento SaaS, storitev v oblaku, ponudnika upravljanih varnostnih storitev, plačilni prehod, posrednika avtentikacije, odprtokodno knjižnico, zunanjo razvojno ekipo ali podizvajalca.

NIS2 Article 21 zahteva varnost dobavne verige, vključno z odnosi z neposrednimi dobavitelji in izvajalci storitev. Ukrepi dobavne verige morajo upoštevati ranljivosti dobaviteljev, kakovost produktov, prakse kibernetske varnosti in postopke varnega razvoja.

DORA Articles 28 to 30 za finančne subjekte zahtevajo več. Zahtevajo, da se tveganje tretjih oseb na področju IKT upravlja kot del okvira upravljanja IKT-tveganj, z registri pogodb o storitvah IKT, razlikovanjem med kritičnimi ali pomembnimi funkcijami, predpogodbenim skrbnim pregledom, pogodbenimi varnostnimi zahtevami, pomočjo pri incidentih, sodelovanjem z organi, pravicami do revizije, pravicami do odpovedi in izhodnimi strategijami. Finančni subjekti ostanejo v celoti odgovorni za skladnost z DORA tudi pri uporabi ponudnikov IKT tretjih oseb.

Clarysecova Politika varnosti tretjih oseb in dobaviteljev za MSP Politika varnosti tretjih oseb in dobaviteljev - SME vključuje preprosto pravilo eskalacije:

»Mora takoj obvestiti generalnega direktorja o vsaki varnostni kršitvi, spremembi ali incidentu«
Vir: Politika varnosti tretjih oseb in dobaviteljev za MSP, vloge in odgovornosti, klavzula 4.4.3

Za pogodbe z dobavitelji v podjetjih Zenith Blueprint, faza Udejanjanje kontrol, 23. korak, priporoča vključitev obveznosti glede zaupnosti, odgovornosti za nadzor dostopa, tehničnih in organizacijskih ukrepov, rokov za poročanje o incidentih, pravice do revizije, kontrol podizvajalcev in določb ob koncu pogodbe. Navaja:

»Pomembno je, da obstajajo ter da jih obe strani razumeta in sprejemata.«
Vir: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Udejanjanje kontrol, 23. korak: Organizacijske kontrole (5.19 to 5.37)

Pripravljenost dobaviteljev za CVD mora odgovoriti na ta vprašanja:

• Ali dobavitelj objavlja kanal za poročanje o ranljivostih?
• Ali so roki za obveščanje o ranljivostih določeni v pogodbi?
• Ali se kritične ranljivosti dobaviteljev sporočajo brez nepotrebnega odlašanja?
• Ali so slabosti, ki vplivajo na stranke, povezane z obveznostmi pomoči pri incidentih?
• Ali lahko dobavitelj zagotovi dokazila o odpravi ali varnostna obvestila?
• Ali se obveznosti glede ranljivosti prenesejo na podizvajalce?
• Ali obstaja izhodna strategija, če je odprava neustrezna?

Tu se NIS2, DORA in ISO/IEC 27001:2022 združijo. Upravljanje ranljivosti dobaviteljev ni kljukica v nabavi. Je del operativne odpornosti.

Mapiranje dokazil za ISO 27001, NIS2, DORA, GDPR in COBIT

Najmočnejši programi CVD izhajajo iz dokazil. Predpostavljajo, da lahko vsako pomembno poročilo pozneje pregledajo notranja revizija, certifikacijski presojevalci, regulatorji, stranke, zavarovalnice ali odbor za tveganja na ravni upravnega odbora.

Clarysecova Politika spremljanja presoje in skladnosti za MSP Politika spremljanja presoje in skladnosti - SME zajame podrobnost, ki jo številne ekipe spregledajo:

»Metapodatki (npr. kdo jih je zbral, kdaj in iz katerega sistema) morajo biti dokumentirani.«
Vir: Politika spremljanja presoje in skladnosti za MSP, zahteve za izvajanje politike, klavzula 6.2.3

Posnetek zaslona popravljenega strežnika je šibko dokazilo, če nihče ne ve, kdo ga je zajel, kdaj, iz katerega sistema in kako se mapira na ranljivost. Zahtevek s časovnimi žigi, izhodom skenerja, zahtevkom za združitev kode, odobritvijo spremembe, dnevniki uvedbe, poizvedbo spremljanja, potrditvijo ponovnega testiranja in metapodatki je veliko močnejši.

Podrobnejša matrika sledljivosti pomaga pri skrbnem pregledu strank in notranji reviziji.

Različni presojevalci bodo isti proces preizkusili z različnih vidikov.

Presojevalec ISO/IEC 27001:2022 bo začel pri ISMS. Vprašal bo, ali so obveznosti glede razkrivanja ranljivosti vključene v zahteve zainteresiranih strani, ali se tveganja ocenjujejo dosledno, ali so kontrole navedene v SoA, ali obstajajo operativna dokazila in ali vodstvo pregleduje trende ter zapadle zadeve.

Pregledovalec po DORA ali v finančnih storitvah se bo osredotočil na operativno odpornost. Pregledal bo integracijo IKT-tveganj, razvrščanje incidentov, eskalacijo višjemu vodstvu, komunikacijo s strankami, odvisnosti od tretjih oseb, testiranje in pridobljene izkušnje. Če ranljivost vpliva na kritično ali pomembno funkcijo, bo pričakoval tesno povezavo med tehničnim zahtevkom, poslovnim vplivom, posledicami za neprekinjeno poslovanje in obveznostmi dobaviteljev.

Pregledovalec po GDPR se bo osredotočil na osebne podatke. Ali so bili vključeni osebni podatki? Ali je prišlo do nepooblaščenega dostopa, izgube, spremembe ali razkritja? Ali so bile vloge upravljavca in obdelovalca jasne? Ali je bil prag kršitve ocenjen? Ali so bila relevantna varovala, kot so šifriranje, nadzor dostopa, beleženje in minimizacija?

Presojevalec COBIT 2019 ali ISACA se bo osredotočil na upravljanje, odgovornost, uspešnost in zagotovilo. Iskal bo opredeljeno lastništvo, metrike, eskalacijo, cilje kontrol, nadzor vodstva in sledenje izjemam. Zapadla kritična ranljivost ni samo tehnična težava. Je vprašanje upravljanja, razen če je formalno eskalirana in je tveganje sprejeto.

Ocenjevalec, usmerjen v NIST, bo razmišljal v okviru Identify, Protect, Detect, Respond in Recover. Želel bo lastništvo sredstev, identifikacijo ranljivosti, določanje prioritet, zaščitno spremembo, zaznavanje izkoriščanja, koordinacijo odziva in preverjanje obnovitve.

Prednost integriranega modela CVD je, da lahko ista dokazilna hrbtenica podpira vse te preglede.

Mesečna kontrolna zanka: metrike, ki jih vodstvo lahko uporablja

CVD se ne konča, ko se zahtevek zapre. Politika usklajenega razkrivanja ranljivosti zahteva redni pregled dnevnika:

»VRT mora vzdrževati dnevnik razkrivanja ranljivosti, ki spremlja vsako poročilo od prejema do zaprtja. Dnevnik je treba pregledovati mesečno, da se zagotovi pravočasen napredek odprtih zadev. Zapadle zadeve je treba eskalirati.«
Vir: Politika usklajenega razkrivanja ranljivosti, spremljanje in presoja, klavzula 9.1

Ta mesečni pregled razkrivanje ranljivosti spremeni v upravljanje, pripravljeno za upravni odbor. Vodstvo ne potrebuje vsake tehnične podrobnosti. Potrebuje trend, izpostavljenost, odgovornost in zapadlo tveganje.

V zreli implementaciji Clarysec ta mesečni pregled dnevnika napaja register tveganj, izjavo o uporabnosti, zaostanek nalog varnega razvoja, preglede dobaviteljev, pridobljene izkušnje iz incidentov, načrt notranje revizije in paket poročanja vodstvu.

Proces vzpostavite, preden prispe resna prijava

Najslabši čas za zasnovo usklajenega razkrivanja ranljivosti je po tem, ko je raziskovalec javno objavil vašo slabost ali je kritična bančna stranka zamrznila uvajanje. NIS2, DORA, GDPR, ISO/IEC 27001:2022, pričakovanja odpornosti po vzoru NIST in upravljanje COBIT 2019 kažejo v isto smer: razkrivanje ranljivosti mora biti načrtovano, imeti lastnika, biti testirano, podprto z dokazili in izboljševano.

Začnite s temi petimi ukrepi:

1. Sprejmite ali prilagodite Politiko usklajenega razkrivanja ranljivosti.
2. Z uporabo Zenith Blueprint vzpostavite delovni tok prejema in triaže, zlasti 13. korak za sledljivost SoA, 16. korak za kulturo poročanja, 19. korak za upravljanje tehničnih ranljivosti in 23. korak za sporazume z dobavitelji.
3. Delovni tok mapirajte prek Zenith Controls, s poudarkom na kontrolah ISO/IEC 27002:2022 A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 in A.8.32.
4. Dodajte klavzule, primerne za MSP, iz Politike odzivanja na incidente za MSP, Politike upravljanja ranljivosti in popravkov za MSP, Politike varnosti tretjih oseb in dobaviteljev za MSP, Politike zahtev za varnost aplikacij za MSP in Politike spremljanja presoje in skladnosti za MSP, kjer je pomembna sorazmernost.
5. Izvedite namizno vajo, ki simulira prijavo raziskovalca z vplivom na osebne podatke in komponento, gostovano pri dobavitelju, nato preizkusite potrditev prejema, triažo, razvrščanje incidenta, nameščanje popravkov, komunikacijo s strankami, zajem dokazil in eskalacijo vodstvu.

Clarysec vam lahko pomaga to pretvoriti v delujočo politiko CVD, register prejetih prijav, mapo dokazil ISO/IEC 27001:2022, odločitveno drevo NIS2 in DORA, model eskalacije dobaviteljev in paket kontrol, pripravljen za presojo. Cilj je preprost: ko prispe naslednje poročilo o ranljivosti, vaša ekipa ne sme improvizirati. Izvajati mora z zaupanjem, dokazili in nadzorom.