ENISA EUVD 2026: ISO 27001 za NIS2 in CRA

Ura je 08:17 v torek leta 2026. Maria, vodja informacijske varnosti hitro rastoče fintech SaaS platforme, v nekaj minutah prejme dva signala. Najprej SOC v kanal za incidente objavi opozorilo iz podatkovne zbirke EU o ranljivostih ENISA. Prizadeta komponenta ni neposredno v Marijini lastni kodni bazi. Nahaja se v SDK za avtentikacijo tretje osebe, vdelanem v mobilno aplikacijo, ki jo vzdržuje zunanji razvojni partner.

Nato varnostni raziskovalec pošlje e-poštno sporočilo na javni varnostni kontakt z zadevo: “Razkritje ranljivosti – vaš SaaS produkt”. Raziskovalec trdi, da bi napaka pod določenimi pogoji lahko razkrila nekritične metapodatke strank.

Potrjene kršitve ni. Nobena stranka ni prijavila škode. Nadzorna plošča orodja za pregled ranljivosti ni rdeča. Vendar se vprašanja pojavijo takoj.

Ali smo izpostavljeni? Katere storitve, namenjene strankam, uporabljajo SDK? Ali gre za pomemben incident po NIS2, incident, povezan z IKT, po DORA, kršitev varnosti osebnih podatkov po GDPR ali vprašanje varnosti produkta po Aktu o kibernetski odpornosti? Ali moramo obvestiti dobavitelja, stranko, pristojni organ ali ENISA? In najpomembneje: ali lahko dokažemo, kdaj smo se z zadevo seznanili?

Tu številne organizacije ugotovijo, da obveščevalni podatki o ranljivostih niso težava vira podatkov. So težava operativnega modela.

ENISA EUVD bo postala praktična referenčna točka za obveščevalne podatke o ranljivostih v EU, usklajeno razkrivanje ranljivosti in preglednost varnosti produktov. Vendar sama podatkovna zbirka Marii ne bo povedala, ali je prizadeta storitev v obsegu uporabe NIS2, ali DORA velja zaradi dejavnosti finančnih storitev, ali je verjetna izpostavljenost osebnih podatkov oziroma ali se sproži pripravljenost na poročanje po CRA. Te odločitve morajo nastati znotraj upravljanega, dokumentiranega in preverljivega sistema upravljanja informacijske varnosti.

Pristop Clarysec je operativna uvedba EUVD prek upravljanja po ISO/IEC 27001:2022, implementacije kontrol po ISO/IEC 27002:2022, lastništva politik in dokazil za skladnost med različnimi okviri. Cilj ni ustvariti še ene preglednice z imenom “sledilnik EUVD”. Cilj je zgraditi utemeljljiv model obveščevalnih podatkov o ranljivostih in poročanja, ki vzdrži vprašanja regulatorjev, presoje strank, certifikacijske presoje ISO 27001 in pregled organa upravljanja.

Zakaj ENISA EUVD leta 2026 spreminja upravljanje ranljivosti

Varnostne ekipe so obveščevalne podatke o ranljivostih dolga leta obravnavale kot vhod za nameščanje popravkov. Pojavi se CVE, orodje za pregled ranljivosti zazna izpostavljenost, operativna ekipa namesti popravek in zahtevek se zapre. Ta model za organizacije, regulirane v EU, ne zadostuje več.

NIS2 premika upravljanje tveganj kibernetske varnosti v upravljanje organizacije. Article 20 zahteva, da organi upravljanja bistvenih in pomembnih subjektov odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirajo njihovo izvajanje in se udeležujejo usposabljanja o kibernetski varnosti. Article 21 zahteva sorazmerne tehnične, operativne in organizacijske ukrepe, vključno s politikami, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varno nabavo in vzdrževanjem, obravnavo in razkrivanjem ranljivosti, oceno učinkovitosti, kibernetsko higieno, kriptografijo, kadrovsko varnostjo, nadzorom dostopa, upravljanjem sredstev ter, kjer je ustrezno, večfaktorsko avtentikacijo ali neprekinjeno avtentikacijo.

Article 23 dodaja fazno poročanje o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah od seznanitve, obvestilom o incidentu v 72 urah in končnim poročilom v enem mesecu. Če opozorilo EUVD preraste v izkoriščeno motnjo storitve, organizacija potrebuje dokazila o seznanitvi, triaži, presoji vpliva, ublažitvi in odločitvah o poročanju.

DORA ustvarja vzporeden, vendar sektorsko specifičen režim za finančne subjekte. Zahteva notranje ureditve upravljanja in kontrol za IKT-tveganja, odgovornost organa upravljanja, procese upravljanja incidentov, upravljanje tveganj tretjih oseb na področju IKT, testiranje, odpornost, pogodbene kontrole in poročanje o večjih incidentih, povezanih z IKT, po DORA Article 19. Za finančne subjekte v obsegu uporabe DORA deluje kot sektorsko specifičen okvir za IKT-tveganja in poročanje o incidentih.

GDPR dodaja dodatno razsežnost. Če bi izkoriščanje lahko povzročilo nepooblaščen dostop, razkritje, izgubo, spremembo ali uničenje osebnih podatkov, se mora potek dela za ranljivosti povezati s presojo kršitve varnosti osebnih podatkov. Načelo odgovornosti po GDPR pomeni, da mora upravljavec dokazati skladnost, ne zgolj zatrjevati, da je ravnal razumno.

Akt o kibernetski odpornosti določa obravnavo ranljivosti in usklajeno razkrivanje kot obveznost varnosti produktov z digitalnimi elementi. Uvaja tudi pričakovanja glede poročanja o aktivno izkoriščanih ranljivostih in hudih varnostnih incidentih, kadar je to ustrezno. Tudi kadar končna pravna odločitev o poročanju zahteva specialistični pregled, so operativna dokazila varnostna dokazila: prizadeti produkt, prizadeta različica, možnost izkoriščanja, ublažitev, status razkritja, vpliv na stranke, usklajevanje z dobavitelji in časovnica.

Ko je ranljivost javno vidna prek EUVD, lahko presojevalci in regulatorji vprašajo, zakaj ni bila ocenjena, zakaj prizadeta sredstva niso bila identificirana, zakaj dobavitelji niso bili kontaktirani ali zakaj poročanje ni bilo obravnavano. Najmočnejše organizacije bodo lahko z dokazili odgovorile na šest vprašanj:

1. Katera opozorila EUVD so za nas pomembna?
2. Katera sredstva, produkti, dobavitelji in stranke so prizadeti?
3. Kdo je lastnik odločitve?
4. Kateri rok za odpravo ali ublažitev velja?
5. Kdaj obravnava ranljivosti postane poročanje o incidentu?
6. Kako dokazujemo zaprtje in nadzor vodstva?

Temelj ISO 27001:2022 za dokazila EUVD

ISO/IEC 27001:2022 je naravna hrbtenica sistema upravljanja za operativno uvedbo EUVD, ker izhaja iz konteksta, zainteresiranih strani, obsega, tveganja in dokazil.

Klavzule 4.1 do 4.4 zahtevajo, da organizacija opredeli notranja in zunanja vprašanja, zainteresirane strani, pravne, regulativne in pogodbene zahteve, obseg ISMS, vmesnike in odvisnosti. Za pripravljenost na EUVD se obseg ISMS ne more končati pri notranjih strežnikih. Upoštevati mora SaaS produkte, storitve v oblaku, zunanji razvoj, ponudnike upravljanih storitev, dobavitelje IKT, zaveze do strank, regulativne obveznosti in pričakovanja glede ranljivosti produktov.

Klavzule 5.1 do 5.3 zahtevajo voditeljstvo, uskladitev politik, vire, komunikacijo, odgovornost in odgovornosti poročanja. Tu najvišje vodstvo sprejme, da obveščevalni podatki o ranljivostih niso tehnična vljudnost. So signal poslovnega tveganja.

Klavzule 6.1.1 do 6.1.3 zagotavljajo mehanizem za oceno tveganja, obravnavo tveganja, izbiro kontrol, primerjavo s Prilogo A, Izjavo o uporabnosti, odobritev preostalega tveganja in načrtovanje obravnave tveganja. Ko vnos EUVD vpliva na okolje, mora odziv sprožiti ponovljiv potek dela za tveganja, ki poveže prizadeta sredstva, verjetnost, vpliv, obstoječe kontrole, možnosti obravnave in odobritev lastnika tveganja.

Klavzule 8.1 do 8.3 in 9.1 do 9.3 ta model pretvorijo v operativni cikel. Organizacije morajo načrtovati in nadzorovati procese ISMS, hraniti dokumentirane informacije, nadzorovati zunanje zagotovljene procese, ponovno ocenjevati tveganja, izvajati načrte obravnave tveganj, spremljati in meriti uspešnost, izvajati notranje presoje in opravljati vodstvene preglede.

V praksi Clarysec EUVD preslika v tri plasti:

Ključno načelo je preprosto. Opozorila EUVD morajo postati zapisi znotraj ISMS, ne neformalna sporočila v klepetu, ki izginejo po namestitvi popravka.

Nabor kontrol ISO 27001, ki omogoča izvedljivo EUVD

Najpomembnejše kontrole iz Priloge A ISO/IEC 27001:2022 za operacije EUVD so 5.7 obveščevalni podatki o grožnjah, 8.8 upravljanje tehničnih ranljivosti, 5.21 upravljanje informacijske varnosti v dobavni verigi IKT in 5.31 pravne, zakonske, regulativne in pogodbene zahteve.

Clarysec jih preslika prek Zenith Controls: vodnik za skladnost med okviri Zenith Controls, ki deluje kot kompas za skladnost med ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF in načrtovanjem presojevalskih dokazil.

Preslikava Zenith Controls za kontrolo ISO/IEC 27002:2022 5.7, obveščevalni podatki o grožnjah, jo označuje kot preventivno, odkrivalno in korektivno, podpira zaupnost, celovitost in razpoložljivost ter se usklajuje s koncepti kibernetske varnosti prepoznavanja, zaznavanja in odzivanja. Njena operativna zmožnost je upravljanje groženj in ranljivosti, z varnostnima področjema obrambe in odpornosti.

Preslikava Zenith Controls za kontrolo ISO/IEC 27002:2022 8.8, upravljanje tehničnih ranljivosti, jo označuje kot preventivno, podpira zaupnost, celovitost in razpoložljivost ter se usklajuje s prepoznavanjem in zaščito. Njena operativna zmožnost je upravljanje groženj in ranljivosti, njena varnostna področja pa vključujejo upravljanje, ekosistem, zaščito in obrambo.

Preslikava Zenith Controls za kontrolo ISO/IEC 27002:2022 5.21, upravljanje informacijske varnosti v dobavni verigi IKT, jo označuje kot preventivno, podpira zaupnost, celovitost in razpoložljivost ter se usklajuje s prepoznavanjem. Njena operativna zmožnost je varnost odnosov z dobavitelji, s področji upravljanja, ekosistema in zaščite.

Zenith Blueprint: 30-koračni časovni načrt za presojevalca Zenith Blueprint v koraku 23 prav tako poudarja kontrolo 5.31, pravne, zakonske, regulativne in pogodbene zahteve:

Varnost ne obstaja v vakuumu. Deluje v mreži obveznosti, nekatere določa zakon, druge pogodba, tretje pa sektorsko specifična regulativa.

To je upravljavski most med EUVD in regulativnim poročanjem. Zapis o ranljivosti se lahko začne kot obveščevalni podatek o grožnjah, postane zahtevek za tehnično ranljivost, sproži sodelovanje dobavitelja in nato postane odločitev o incidentu ali pravnem obvestilu.

Zato EUVD ne sme biti obravnavana kot še en vir podatkov. Je točka integracije kontrol.

Model politik Clarysec: od opozorila do odgovorne odločitve

Zrel operativni model EUVD potrebuje besedilo politik, ki ekipam pove, kaj morajo storiti, še preden prispe prvo kritično opozorilo.

Clarysecova Politika upravljanja ranljivosti in popravkov Politika upravljanja ranljivosti in popravkov daje podjetniškim ekipam jasen mandat za spremljanje in eskalacijo:

Spremljajte obvestila o grožnjah (npr. CVE, CISA KEV, varnostne biltene dobaviteljev) in eskalirajte kritične ranljivosti.

Ista politika zahteva centralno bazo dokazil:

Ekipa za varnostne operacije mora vzdrževati centraliziran register upravljanja ranljivosti, ki ga mesečno pregleda vodja informacijske varnosti ali pooblaščeni organ.

Za MSP Clarysecova Politika upravljanja ranljivosti in popravkov – MSP Politika upravljanja ranljivosti in popravkov – MSP izrecno opredeljuje model virov, saj vključuje:

Zaupanja vredna obvestila obveščevalnih podatkov o grožnjah (npr. CISA, ENISA, opozorila nacionalnih CERT)

Ohranja tudi presojevalsko sled:

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

Te klavzule preprečujejo pogosto napako. Če prispe opozorilo EUVD in nihče ne ve, ali sodi v register ranljivosti, čakalno vrsto incidentov, sledilnik dobaviteljev ali pravno presojo, organizacija izgubi čas. Besedilo politike naredi prvi korak samodejen.

Razsežnost CVD se obravnava prek Clarysecove Politike usklajenega razkrivanja ranljivosti Politika usklajenega razkrivanja ranljivosti, ki zagotavlja potek dela za sprejem, potrditev, oceno resnosti in preverjanje:

Ob prejemu prijave jo mora VRT evidentirati in prijavitelju v 2 delovnih dneh poslati potrditev ter dodeliti referenco za sledenje. VRT mora opraviti predhodno oceno resnosti, na primer z uporabo točkovanja CVSS, in preveriti zadevo, po potrebi tudi s podporo ekip IT in razvoja, 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.

Povezuje tudi ranljivosti tretjih oseb s sodelovanjem dobaviteljev:

Za vsako potrjeno kritično ali visoko tvegano ranljivost mora CISO takoj obvestiti višje vodstvo in zadevne lastnike sistemov. Kadar ranljivost vpliva na produkte ali storitve, ki jih zagotavlja dobavitelj ali druga tretja oseba, mora VRT brez nepotrebnega odlašanja obvestiti varnostni kontakt dobavitelja in zahtevati sodelovanje pri odpravi.

Clarysecova Politika zahtev za varnost aplikacij – MSP Politika zahtev za varnost aplikacij – MSP krepi pričakovanja glede produktov in dobaviteljev, saj od ekip zahteva, da:

določijo obveznosti glede razkrivanja ranljivosti, odzivnih časov in nameščanja popravkov.

Za pogodbe z dobavitelji Clarysecova Politika varnosti tretjih oseb in dobaviteljev – MSP Politika varnosti tretjih oseb in dobaviteljev – MSP vključuje:

časovne roke za obvestila o kršitvah podatkov (npr. v 24–72 urah)

Nazadnje Clarysecova Politika odzivanja na incidente Politika odzivanja na incidente povezuje regulirane podatke in sektorsko poročanje z odločitvijo o incidentu prek klavzule 6.4.1:

Različica za MSP ohranja isti praktični sprožilec. Clarysecova Politika odzivanja na incidente – MSP Politika odzivanja na incidente – MSP določa:

Kadar so vključeni podatki strank, mora generalni direktor presoditi zakonske obveznosti obveščanja glede na uporabljivost GDPR, NIS2 ali DORA.

To je most med “videli smo ranljivost” in “presodili smo, ali je treba o tem poročati”.

Praktičen vnosni zapis EUVD

Predpostavimo, da EUVD objavi ali posodobi vnos ranljivosti, ki vpliva na SDK za avtentikacijo v Marijini mobilni aplikaciji. SDK vzdržuje dobavitelj, integrira ga zunanji razvojni partner, uporabljajo pa ga stranke, ki se avtenticirajo v fintech SaaS produkt. Javna razprava o izkoriščanju obstaja, vendar v dnevnikih najemnikov ni potrjenega izkoriščanja.

Utemeljljiv vnosni zapis mora zajeti tako tehnični kot regulativni kontekst.

Ta zapis ni okras za skladnost. Je nadzorni center za odločitve.

Praktičen potek dela je videti tako:

1. SOC prejme opozorilo EUVD in ustvari zapis o ranljivosti.
2. Lastnik sredstva potrdi, ali prizadeta komponenta obstaja v produkciji.
3. Varnostna ekipa opravi oceno resnosti z uporabo tehnične resnosti, možnosti izkoriščanja, izpostavljenosti, občutljivosti podatkov in kritičnosti storitve.
4. Lastnik dobavitelja kontaktira dobavitelja SDK ali zunanjega razvojnega partnerja prek vnaprej opredeljenih varnostnih kontaktov.
5. Vodja odzivanja na incidente odloči, ali obstajajo dokazila o izkoriščanju, vplivu na storitev ali škodi za stranke.
6. Pravna služba, pooblaščena oseba za varstvo podatkov in funkcija skladnosti presodijo, ali se sprožijo poteki dela, povezani z GDPR, NIS2, DORA ali CRA.
7. Inženiring uvede popravek ali ublažitev.
8. Varnost preveri odpravo s skeniranjem, preverjanjem različice, pregledom dnevnikov ali testom kompenzacijske kontrole.
9. CISO pregleda kritične in visoke zapise ter o trendih poroča v vodstveni pregled.

V fazi Kontrole v praksi, korak 19, Tehnološke kontrole I, Zenith Blueprint pojasni upravljanje tehničnih ranljivosti v jasnem presojevalskem jeziku:

Pri kontroli ne gre za popolnost, temveč za organiziran, pregleden in odgovoren proces.

Ta stavek je pomemben. Regulatorji in presojevalci ne pričakujejo, da bo vsaka ranljivost odpravljena takoj. Pričakujejo, da organizacija ve, kaj obstaja, določa prioritete, izvaja sorazmerne ukrepe, evidentira izjeme in dokaže nadaljnje ukrepanje.

Obveščevalni podatki o grožnjah so odločitvena funkcija, ne poštni predal

Največja napaka pri načrtovanju EUVD je dodeliti vir enemu analitiku in to poimenovati “obveščevalni podatki o grožnjah”. Zenith Blueprint v fazi Kontrole v praksi, korak 22, Organizacijske kontrole, pojasnjuje kontrolo ISO/IEC 27002:2022 5.7 tako:

Najboljši viri obveščevalnih podatkov o grožnjah so pogosto kombinacija notranjega spremljanja, zunanjih partnerstev in sodelovanja s skupnostjo.

Opozarja tudi, da morajo obveščevalni podatki postati ukrepanje:

Ta kontrola resnično zaživi pri odločanju. Obveščevalni podatki o grožnjah morajo neposredno vplivati na to, katere kontrole se zaostrijo, katera sredstva se ponovno razvrstijo ali izolirajo, kateri scenariji se testirajo v namiznih vajah in kako hitro se uvedejo popravki ali ublažitve.

Za EUVD morajo biti uporabniki obveščevalnih podatkov opredeljeni po vlogah.

NIST CSF 2.0 lahko pomaga strukturirati ta model. Njegova funkcija upravljanja poudarja pričakovanja deležnikov, pravne in regulativne obveznosti, apetit po tveganju, odgovornost vodstva, opredeljene vloge, politiko, vire in nadzor. Njegove operativne funkcije pomagajo organizirati evidenco sredstev, identifikacijo ranljivosti, zaščito, zaznavanje, odziv, obnovitev in izboljševanje. Metoda profila NIST CSF se lahko uporabi za opredelitev trenutnega in ciljnega stanja operacij EUVD ter pretvorbo vrzeli v prednostno razvrščen akcijski načrt.

V terminologiji Clarysec je NIST CSF uporaben organizacijski sloj, ISO/IEC 27001:2022 je preverljiv sistem upravljanja, Zenith Controls pa kompas za skladnost med okviri, ki ohranja preslikave koherentne.

Sledenje ranljivostim dobaviteljev in produktov

NIS2 Article 21 varnost dobavne verige uvršča med minimalne ukrepe za obvladovanje tveganj kibernetske varnosti. Article 21(3) zahteva, da subjekti upoštevajo ranljivosti, specifične za vsakega neposrednega dobavitelja in izvajalca storitev, kakovost produktov ter prakse kibernetske varnosti dobaviteljev, vključno s postopki varnega razvoja. Uvodni izjavi 85 in 86 poudarjata tveganje tretjih oseb zaradi obdelave podatkov, upravljanih storitev, dobaviteljev programske opreme in ponudnikov upravljanih varnostnih storitev.

DORA je za finančne subjekte bolj predpisovalna. Zahteva, da se tveganje tretjih oseb na področju IKT upravlja kot del okvira IKT-tveganj, z informacijskimi registri, skrbnim pregledom, analizo tveganja koncentracije, pisnimi pogodbami, pravicami do presoje in pregleda, pomočjo pri incidentih, vidnostjo podizvajanja, varnostnimi zahtevami, pravicami do odpovedi in preizkušenimi izstopnimi strategijami.

EUVD bo šibko vidnost dobaviteljev naredila boleče očitno. Če je prizadeta komponenta dobavitelja, organizacija potrebuje več kot kontakt v nabavi. Potrebuje:

1. Imenovani varnostni kontakt dobavitelja.
2. Pogodbene obveznosti obveščanja o ranljivostih.
3. Evidenco produktov in različic.
4. SBOM ali preglednost komponent, kjer je relevantno.
5. SLA za odpravo in obveznosti nadomestnih ukrepov.
6. Pravice do presoje ali zagotavljanja zaupanja.
7. Obveznosti podpore pri incidentih.
8. Načrte izhoda ali zamenjave za kritične odvisnosti.

Zato Clarysec operacije EUVD preslika v kontrolo ISO/IEC 27002:2022 5.21 prek Zenith Controls. Področja upravljanja, ekosistema in zaščite ustrezajo praktičnemu problemu dobaviteljev: ne morete odpraviti nečesa, česar ne morete slediti, in ne morete dokazati nečesa, česar niste pogodbeno zahtevali.

Za pripravljenost na poročanje po CRA isti zapis o ranljivosti dobavitelja in produkta postane ključen. Tudi kadar končna regulativna odločitev zahteva pravno analizo, operativni dokaz izhaja iz varnostnih in inženirskih dokazil.

Kdaj ranljivost EUVD postane incident

Ni vsaka ranljivost incident. Vendar mora biti vsaka resna ranljivost sposobna hitro postati zapis o incidentu.

Praktični sprožilec je naslednji: če obveščevalni podatki EUVD kažejo na možno izpostavljenost, odprite zapis o ranljivosti. Če obstajajo dokazila o izkoriščanju, vplivu na storitev, izpostavljenosti reguliranih podatkov, škodi za stranke ali motnji delovanja, zapis povežite z incidentom ali ga pretvorite v zapis o incidentu.

NIS2 Article 23 zahteva obveščanje o pomembnih incidentih, ki vplivajo na zagotavljanje storitev, vključno z incidenti, ki povzročijo ali bi lahko povzročili resno operativno motnjo ali finančno izgubo oziroma vplivajo na druge z znatno materialno ali nematerialno škodo. DORA zahteva, da finančni subjekti evidentirajo incidente, povezane z IKT, in pomembne kibernetske grožnje, razvrstijo večje incidente, povezane z IKT, o njih poročajo po Article 19, kadar je to potrebno, komunicirajo s strankami, kadar so prizadeti finančni interesi, in zaključijo z analizo temeljnega vzroka. GDPR zahteva presojo kršitve varnosti osebnih podatkov, kadar varnostni incident povzroči naključno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih.

Zenith Blueprint, faza Kontrole v praksi, korak 16, Kontrole za ljudi II, krepi pomen kulture poročanja:

Spodbujajte miselnost “nizkega praga za poročanje”; sporočilo mora biti: “Če ste v dvomih, poročajte.”

Za EUVD to velja za inženirje in dobavitelje enako kot za zaposlene. Če razvijalec opazi prizadeto odvisnost, če dobavitelj potrdi možnost izkoriščanja ali če podpora zazna sumljivo vedenje stranke, mora organizacija dati prednost zgodnji triaži pred zapoznelo gotovostjo.

Kako bodo presojevalci testirali vaš program EUVD

Močan operativni model EUVD mora biti zasnovan za več presojevalskih pogledov. Ista dokazila lahko izpolnijo različna pričakovanja, če so dobro strukturirana.

Presojevalec ISO 27001 bo običajno vzorčil zapis z visoko resnostjo, sprožen z EUVD, in preveril, ali je povezan z obsegom, obveznostmi zainteresiranih strani, oceno tveganja, obravnavo, kontrolami Priloge A, operativnimi dokazili in pregledom. Ocenjevalec, usmerjen v NIST, se bo osredotočil na rezultate. Presojevalec v slogu COBIT se bo osredotočil na upravljanje, lastništvo, uspešnost in zagotavljanje. Pregledovalec DORA bo posebno pozornost namenil odvisnostim od tretjih oseb na področju IKT, pogodbenim kontrolam in razvrstitvi incidentov.

Poročanje organu upravljanja brez šuma CVE

NIS2 in DORA postavljata organe upravljanja v središče odgovornosti za kibernetsko varnost. Vendar izvršno vodstvo ne potrebuje izpisa vnosov EUVD. Potrebuje poročanje, primerno za odločanje.

Mesečno poročilo o obveščevalnih podatkih o ranljivostih mora vključevati:

1. Kritične in visoke ranljivosti, povezane z EUVD, ki vplivajo na sredstva v obsegu.
2. Odprte ranljivosti zunaj SLA za odpravo.
3. Zamude, ki jih povzročijo dobavitelji, in pogodbene eskalacije.
4. Ranljivosti, povezane z incidenti ali skorajšnjimi incidenti.
5. Sprožilce in rezultate poteka dela za ranljivosti produktov po CRA.
6. Presoje poročanja po NIS2, DORA ali GDPR.
7. Sprejeta preostala tveganja in kdo jih je sprejel.
8. Trende po poslovni storitvi, produktu, dobavitelju in temeljnem vzroku.
9. Kazalnike učinkovitosti kontrol in ukrepe izboljšav.

To se neposredno preslika v pričakovanja vodstvenega pregleda po klavzuli 9.3 ISO/IEC 27001:2022, vključno s spremembami konteksta, potrebami zainteresiranih strani, trendi uspešnosti, rezultati presoj, izpolnjevanjem ciljev, povratnimi informacijami, rezultati ocen tveganj, statusom obravnave in priložnostmi za izboljšave.

Pogoste napake pri pripravljenosti na EUVD

Organizacije, ki imajo težave z obveščevalnimi podatki o ranljivostih, običajno odpovedo na predvidljive načine.

Prvič, nimajo zanesljive evidence sredstev in programske opreme. Relevantnosti EUVD ni mogoče oceniti brez imen produktov, različic, knjižnic, storitev v oblaku, dobaviteljev in tokov podatkov.

Drugič, ločujejo upravljanje ranljivosti od odzivanja na incidente. Ekipa za ranljivosti zapira zahtevke, ekipa za incidente pa nikoli ne presodi, ali je prišlo do izkoriščanja. To ustvarja slepe pege pri poročanju.

Tretjič, pogodbe z dobavitelji molčijo. Če dobavitelj ni zavezan obvestiti, sodelovati, namestiti popravka, predložiti dokazila ali podpreti odziva na incident, ima naročnik v kritičnem obdobju malo vzvodov.

Četrtič, pravne ekipe in pooblaščena oseba za varstvo podatkov so vključene prepozno. Če se odločitve o poročanju, povezane z GDPR, NIS2, DORA ali CRA, začnejo šele po tem, ko je inženiring že namestil popravek in nadaljeval z delom, časovnica seznanitve postane nejasna.

Petič, poročanje vodstvu je preveč tehnično. Organi upravljanja prejmejo dolge sezname CVE brez vpliva na poslovanje, regulativne relevantnosti, trendov dobaviteljev ali odločitev o preostalem tveganju.

Metodologija Clarysec to popravi s povezovanjem kontrol. V Zenith Blueprint korak 19 krepi upravljanje tehničnih ranljivosti, korak 22 operacionalizira obveščevalne podatke o grožnjah, korak 16 krepi kulturo poročanja o incidentih, korak 23 pa ohranja pravne, zakonske, regulativne in pogodbene obveznosti vidne.

30-dnevni sprint pripravljenosti na EUVD

Če vaša organizacija potrebuje hitro pot, začnite z usmerjenim 30-dnevnim sprintom.

Prvi teden: opredelite obseg in obveznosti. Potrdite, ali je organizacija potencialno bistven ali pomemben subjekt po NIS2, ali DORA velja za finančne dejavnosti, ali GDPR velja za obdelavo osebnih podatkov in kje so lahko relevantne obveznosti glede ranljivosti produktov po CRA. Posodobite pravni in pogodbeni register ISMS.

Drugi teden: zgradite vhodni potek dela. Dodajte EUVD, nacionalne CERT, obvestila dobaviteljev in sektorske vire na seznam virov obveščevalnih podatkov o ranljivostih. Določite, kdo odpira zapise, kdo preverja izpostavljenost, kdo kontaktira dobavitelje, kdo presoja poročanje in kdo odobri preostalo tveganje.

Tretji teden: povežite dobavitelje in produkte. Identificirajte kritične produkte, storitve, namenjene strankam, neposredne dobavitelje IKT, zunanje razvijalce, ponudnike storitev v oblaku in ponudnike upravljanih varnostnih storitev. Potrdite varnostne kontakte, pogodbene klavzule, obveznosti odziva na ranljivosti in pričakovanja glede dokazil.

Četrti teden: testirajte potek dela. Izvedite namizno vajo z realističnim opozorilom EUVD. Od ekipe zahtevajte zapis o ranljivosti, komunikacijo z dobaviteljem, presojo incidenta, pravno odločitev o obveščanju, evidenco popravkov, odobritev preostalega tveganja in povzetek za vodstvo.

Rezultat ne sme biti predstavitev. Biti mora paket dokazil, ki ga lahko presojevalec vzorči.

Naj EUVD postane kontrolni sistem, ne še en vir podatkov

Do leta 2026 organizacije, ki bodo dobro obvladovale ENISA EUVD, ne bodo tiste, ki se zgolj naročijo na več opozoril. To bodo organizacije, ki javne obveščevalne podatke o ranljivostih pretvorijo v ukrepanje na podlagi tveganj, odgovornost dobaviteljev, usklajeno razkrivanje, odločitve o poročanju in presojevalska dokazila.

Clarysec vam lahko pomaga zgraditi ta model z uporabo Zenith Blueprint Zenith Blueprint, knjižnice politik Clarysec in Zenith Controls Zenith Controls. Klavzule ISO/IEC 27001:2022 in kontrole ISO/IEC 27002:2022 preslikamo v pričakovanja NIS2, DORA, GDPR, NIST CSF in presojevalska pričakovanja v slogu COBIT, nato pa preslikavo pretvorimo v praktične registre, odzivne priročnike, klavzule za dobavitelje in poročanje vodstvu.

Če se vaša ekipa pripravlja na obravnavo ranljivosti po NIS2, pripravljenost na poročanje po CRA, operacije CVD ali obveščevalne podatke o ranljivostih, ki jih poganja EUVD, začnite s Clarysec pregledom pripravljenosti na EUVD. Pomagali vam bomo identificirati vrzeli, prednostno razvrstiti kontrole in zgraditi dokazno sled, preden prvo kritično opozorilo preizkusi vaš program.