Pripravljenost na Akt EU o kibernetski solidarnosti z ISO 27001

Incident ob 03:17, ki sodelovanje EU spremeni v vaš presojni problem

Ob 03:17 v torek zjutraj Maria, vodja informacijske varnosti v podjetju InnovateCloud, gleda zaslon, poln opozoril. Njeno podjetje je srednje velik evropski ponudnik SaaS, ki podpira logistične stranke v Nemčiji, Franciji in na Poljskem. Prvo opozorilo kaže na sumljiv privilegiran dostop v produkcijskem najemniku. Deset minut pozneje ponudnik upravljanih varnostnih storitev poroča o podobni dejavnosti pri dveh drugih strankah. Do 04:00 SOC zazna klice API iz infrastrukture, ki je bila prej povezana s pripravo napadov z izsiljevalsko programsko opremo.

InnovateCloud ni bil prvotna tarča. Kaže, da je v območju vpliva ključni ponudnik infrastrukture. Vpliv pa je zdaj Mariin problem.

Ena prizadeta stranka je nemška banka, ki zahteva odgovore po DORA. Druga je kritični dobavitelj v energetskem sektorju, ki je že razvrščen po nacionalnih pravilih NIS2. Okolje lahko vsebuje osebne podatke, vendar odtujitev podatkov še ni potrjena. Varnostna ekipa želi grožnjo takoj zajeziti. Pravna služba želi vedeti, ali je začel teči 24-urni rok za zgodnje opozorilo po NIS2. Pooblaščenec oziroma odgovorna oseba za zasebnost sprašuje, ali bi lahko šlo za kršitev varnosti osebnih podatkov po GDPR. Upravni odbor želi vedeti, ali bi se izpad lahko razširil med državami članicami.

Leta 2026 to ni več samo interna kriza.

Akt EU o kibernetski solidarnosti spreminja operativno realnost pri obsežnih in čezmejnih kibernetskih incidentih. Uvaja mehanizme odkrivanja, pripravljenosti in odzivanja na ravni EU, vključno z evropskim sistemom za opozarjanje na kibernetsko varnost, mehanizmom za izredne razmere na področju kibernetske varnosti in rezervo EU za kibernetsko varnost. Tudi če organizacija nikoli neposredno ne zaprosi za pomoč iz rezerve, lahko njena dokazila, kontakti pristojnih organov, pogodbe z dobavitelji, časovnice incidentov in komunikacija s strankami postanejo del širše evropske odzivne verige.

Vrzel se pokaže hitro. Številne organizacije imajo orodja, zahtevke in politike, nimajo pa dokazil, ki prestanejo regulativni pregled. Lahko rečejo: »obvestili smo regulatorja«, ne morejo pa dokazati, kdo je bil pooblaščen, kateri prag je sprožil stik, kaj je bilo sporočeno, ali so bili dnevniki ohranjeni, ali je bil dobavitelj pogodbeno zavezan pomagati in ali je mogoče končno poročilo rekonstruirati iz odločitev, sprejetih med dogodkom.

Odgovor ni še ena ločena mapa za »Akt o kibernetski solidarnosti«. Odgovor je sistem upravljanja informacijske varnosti po ISO/IEC 27001:2022, ki dokazila ustvari enkrat in jih ponovno uporabi za pričakovanja NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019.

Ta dokazila nastajajo že pred incidentom.

Zakaj Akt EU o kibernetski solidarnosti zvišuje prag dokazil

Akt o kibernetski solidarnosti je zasnovan za odkrivanje kibernetskih groženj, pripravljenost in krizno odzivanje na ravni EU. Njegov praktični učinek za vodje informacijske varnosti, presojevalce in vodje skladnosti je jasen: koordinacija obsežnih incidentov zahteva dokazila, ki so hitrejša, bolj urejena, bolj dosledna in jih je lažje deliti z zaupanja vrednimi deležniki.

Kadar je mogoč čezmejni vpliv, se mora organizacija morda usklajevati z nacionalnimi CSIRT, pristojnimi organi, sektorskimi regulatorji, organi za varstvo podatkov, finančnimi nadzorniki, organi pregona, strankami, obdelovalci podatkov, dobavitelji in zunanjimi izvajalci odzivanja na incidente. Rezerva EU za kibernetsko varnost dodaja novo razsežnost, ker lahko vnaprej preverjeni zasebni ponudniki podpirajo pripravljenost, odzivanje in obnovitev. Zato so upravljanje dobaviteljev, pravna pooblastila, ravnanje s podatki in ohranjanje dokazil še pomembnejši.

Zasebni subjekti so v središču te realnosti. Ponudniki storitev v oblaku, podatkovni centri, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev, operaterji digitalne infrastrukture, fintech podjetja in platforme SaaS pogosto hranijo telemetrijo, dnevnike, podatke o vplivu na stranke in tehnična dejstva, ki jih organi potrebujejo za razumevanje večjega incidenta.

NIS2 že kaže v to smer. Velja za številne srednje velike in velike subjekte v sektorjih iz Priloge I in Priloge II, ki zagotavljajo storitve ali izvajajo dejavnosti v EU. Zajema tudi nekatere subjekte ne glede na velikost, vključno s ponudniki storitev zaupanja, ponudniki storitev DNS, registri vrhnjih domen in ponudniki storitev registracije domenskih imen. Priloga I vključuje digitalno infrastrukturo, kot so storitve računalništva v oblaku, storitve podatkovnih centrov, omrežja za dostavo vsebin, ponudniki DNS, ponudniki storitev zaupanja in registri TLD. Vključuje tudi upravljanje storitev IKT B2B, vključno s ponudniki upravljanih storitev in ponudniki upravljanih varnostnih storitev. Priloga II vključuje digitalne ponudnike, kot so spletne tržnice, spletni iskalniki in platforme storitev družbenih omrežij.

DORA dodaja drugi sloj za finančni sektor. Od 17. januarja 2025 velja za širok nabor finančnih subjektov, vključno s kreditnimi institucijami, plačilnimi institucijami, institucijami za elektronski denar, investicijskimi podjetji, ponudniki storitev v zvezi s kriptosredstvi, mesti trgovanja, zavarovalnicami in pozavarovalnicami, bonitetnimi agencijami, ponudniki storitev množičnega financiranja in drugimi. Ustvarja tudi pomembna pričakovanja za tretje ponudnike storitev IKT, ker finančni subjekti ostajajo odgovorni za zunanje izvajane storitve IKT.

Fintech incident leta 2026 se zato lahko usklajuje prek nadzornih kanalov DORA, medtem ko je ponudnik SaaS ali MSSP, ki podpira to fintech podjetje, lahko zavezan po NIS2. Isti tehnični dogodek lahko za različne akterje ustvari različne obveznosti poročanja, pričakovanja glede dokazil in pogodbene obveznosti.

ISO/IEC 27001:2022 organizacijam zagotavlja operativni sistem za upravljanje te kompleksnosti. Klavzule 4.1 do 4.4 zahtevajo, da organizacija opredeli ISMS v svojem poslovnem kontekstu, prepozna zainteresirane strani ter njihove zakonske, regulativne in pogodbene zahteve, določi meje in odvisnosti ter vzpostavi sistem upravljanja. Klavzule 5.1 do 5.3 zavezujejo vodstvo k odgovornosti za politiko, vire, integracijo in dodelitev vlog. Klavzule 6.1.1 do 6.1.3 zahtevajo ponovljivo oceno tveganj, obravnavo tveganj in izjavo o uporabnosti. Klavzula 8.1 zahteva operativno načrtovanje in nadzor, vključno z nadzorom nad zunanje zagotovljenimi procesi, proizvodi in storitvami.

To je jedro pripravljenosti na Akt o kibernetski solidarnosti: dokazati, da je krizni odziv upravljan, preizkušen in preverljiv, ne improviziran.

Model dokazil Clarysec: en incident, številne obveznosti

Čezmejni incident ne čaka, da ga pravne ekipe razvrstijo. Dokazila je treba zajemati od prvega opozorila naprej, nato pa jih usmeriti v ustrezne poti poročanja in koordinacije.

Pristop Clarysec povezuje tri sredstva:

1. Zenith Blueprint: 30-koračni načrt presojevalca Zenith Blueprint, ki implementacijo ISO/IEC 27001:2022 pretvori v zaporedno pot, pripravljeno za presojo.
2. Zenith Controls: vodnik po skladnosti med okviri Zenith Controls, ki kontrole ISO/IEC 27002:2022 preslika na povezane kontrole, atribute, operativne zmogljivosti, varnostna področja in pričakovanja glede dokazil med okviri.
3. Predloge politik Clarysec za odzivanje na incidente, zbiranje dokazov, varnost dobaviteljev, beleženje, spremljanje in neprekinjeno poslovanje, prilagojene za podjetniška okolja in okolja MSP.

V Zenith Blueprint, v fazi Controls in Action, korak 22 obravnava kontrolo ISO/IEC 27002:2022 5.5, stik z organi. Navaja:

Kontrola 5.5 zagotavlja, da je organizacija pripravljena sodelovati z zunanjimi organi, kadar je to potrebno, ne reaktivno ali v paniki, temveč prek vnaprej opredeljenih, strukturiranih in dobro razumljenih kanalov.

Isti razdelek postavlja vprašanje, na katerega mora vsak vodja informacijske varnosti odgovoriti pred krizo:

Če bi bila vaša organizacija tarča kibernetskega napada, vključena v kršitev varnosti osebnih podatkov ali predmet preiskave, kdo bi vzpostavil stik z organi? Kako bi vedel, kaj povedati? Pod katerimi pogoji bi se tak stik začel?

To ni administrativna dokumentacija. V okolju Akta o kibernetski solidarnosti je to razlika med mirnim zgodnjim opozorilom in protislovnimi sporočili po jurisdikcijah.

Zenith Controls obravnava kontrolo ISO/IEC 27002:2022 5.5, stik z organi, kot preventivno in korektivno kontrolo, povezano z zaupnostjo, celovitostjo in razpoložljivostjo ter usklajeno s koncepti Identify, Protect, Respond in Recover. Kontrolo 5.5 povezuje z načrtovanjem in pripravo upravljanja incidentov, poročanjem o dogodkih, obveščevalnimi podatki o grožnjah, posebnimi interesnimi skupinami in odzivanjem na incidente.

Isti vodnik obravnava kontrolo ISO/IEC 27002:2022 5.24, načrtovanje in priprava upravljanja incidentov informacijske varnosti, kot korektivno kontrolo, povezano z Respond in Recover. Njene povezave s presojo dogodkov, odzivanjem na incidente, pridobljenimi izkušnjami, beleženjem, spremljanjem, varnostjo med motnjo in neprekinjenim poslovanjem kažejo, kaj presojevalci pogosto preverjajo: ali vaš načrt povezuje odkrivanje, razvrščanje, eskalacijo, dokazila, obnovitev in učenje.

Za ravnanje z dokazili je posebej pomembna kontrola ISO/IEC 27002:2022 5.28, zbiranje dokazov. Zenith Controls jo povezuje z odzivanjem na incidente, beleženjem, spremljanjem in poročanjem o dogodkih. Pri resnem čezmejnem incidentu tu tehnična preiskava postane zagovorljiva.

Preslikava pripravljenosti na Akt o kibernetski solidarnosti na dokazila ISO 27001

Akt EU o kibernetski solidarnosti ustvarja okolje pripravljenosti in koordinacije. ISO/IEC 27001:2022 zagotavlja mehanizem dokazil. NIS2, DORA in GDPR določajo številna specifična pričakovanja glede poročanja, upravljanja in zaščite.

Opazite, česa ni: ločenega silosa skladnosti. Ista dokazila, ki podpirajo certifikacijo ISO/IEC 27001:2022, lahko podpirajo odgovornost vodstva po NIS2, upravljanje IKT-tveganj po DORA, odgovornost za varnost po GDPR, komunikacijske izide NIST CSF in pričakovanja glede zagotovil COBIT 2019.

NIS2: ura za poročanje začne teči s seznanitvijo

NIS2 je osrednji element pripravljenosti za leto 2026, ker določa stopenjski delovni tok poročanja o incidentih.

Člen 23 od bistvenih in pomembnih subjektov zahteva, da svoj CSIRT ali pristojni organ brez nepotrebnega odlašanja obvestijo o pomembnih incidentih, ki vplivajo na zagotavljanje storitev. Zgodnje opozorilo je treba predložiti brez nepotrebnega odlašanja in najpozneje v 24 urah po tem, ko se subjekt seznani s pomembnim incidentom. Kadar je ustrezno, mora navesti, ali obstaja sum zlonamernih ali nezakonitih dejanj in ali je mogoč čezmejni vpliv.

Obvestilo o incidentu sledi brez nepotrebnega odlašanja in najpozneje v 72 urah po seznanitvi, pri čemer posodobi zgodnje opozorilo ter poda začetno oceno resnosti, vpliva in razpoložljivih kazalnikov kompromitacije. Končno poročilo zapade v enem mesecu po obvestilu o incidentu ter vključuje resnost, vpliv, verjetno vrsto grožnje ali temeljni vzrok, ukrepe za ublažitev in čezmejni vpliv.

Zato se odziv na incidente ne sme začeti s praznim dokumentom.

Podjetniška Politika odzivanja na incidente Incident Response Policy navaja:

NIS2 člen 23 (obvestilo v 24 urah po seznanitvi z incidentom)

Politika Politika odzivanja na incidente - MSP Incident Response Policy - SME isto časovno logiko prenese v praktično upravljanje:

»Časovnice odziva, vključno z obnovitvijo podatkov in obveznostmi obveščanja, morajo biti dokumentirane in usklajene z zakonskimi zahtevami, kot je 72-urna zahteva GDPR za obveščanje o kršitvi varnosti osebnih podatkov.«

Iz Incident Response Policy - SME, razdelek »Zahteve upravljanja«, klavzula 5.3.2.

Prav tako v postopek obravnave incidenta vgradi presojo več režimov:

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

Iz Incident Response Policy - SME, razdelek »Obravnava tveganja in izjeme«, klavzula 7.4.1.

V scenariju Akta o kibernetski solidarnosti postane izjava »čezmejni vpliv je mogoč« operativno pomembna. Zgodnje opozorilo morda še ne vsebuje vseh dejstev, vendar mora organizacija znati pokazati, zakaj je glede na razpoložljiva dokazila sumila ali ni sumila na čezmejni vpliv.

Zapis o incidentu mora zajeti:

• Kdaj se je organizacija seznanila z dogodkom.
• Kdo je dogodek razglasil za potencialni incident.
• Katere storitve, države, stranke ali sektorji so bili potencialno prizadeti.
• Ali je obstajal sum zlonamerne ali nezakonite dejavnosti.
• Kateri kazalniki kompromitacije so bili na voljo.
• Katera pot za stik z organom je bila uporabljena.
• Ali je bila potrebna komunikacija s strankami.
• Katera dokazila so bila ohranjena pred obsežnejšo sanacijo.

Najboljši čas za oblikovanje teh polj je pred 03:17.

DORA: ko je stranka regulirana, dobavitelj pa hrani dnevnike

DORA spreminja pogovor z dobavitelji. Finančni subjekti morajo upravljati tveganje tretjih ponudnikov IKT kot del svojega okvira upravljanja IKT-tveganj. Zunanje izvajanje storitev IKT ne prenese regulativne odgovornosti s finančnega subjekta.

DORA zahteva strategije za tveganje tretjih ponudnikov IKT, registre pogodb o storitvah IKT, skrbni pregled, načrtovanje revizij in pregledov, pravice do odpovedi in preizkušene izstopne strategije za kritične ali pomembne storitve IKT. Člen 30 zahteva pogodbeno jasnost, vključno z opisi storitev, lokacijami, ravnanjem s podatki, zaupnostjo, celovitostjo, razpoložljivostjo, ravnmi storitev, pomočjo med incidenti IKT, sodelovanjem z organi in pravicami do odpovedi. Za kritične ali pomembne funkcije veljajo strožje določbe.

Vrnimo se k Mariinemu incidentu. Nemška banka je regulirana po DORA. InnovateCloud zagotavlja storitve SaaS. MSSP zazna sumljivo dejavnost. Ponudnik infrastrukture v oblaku ima del ključnih revizijskih dnevnikov. Podizvajalec upravlja del telemetrijskega cevovoda. Banka ostaja odgovorna, vendar brez dokazil dobaviteljev ne more ustrezno razvrstiti incidenta in poročati o njem.

Clarysec to obravnava z razvrščanjem dobaviteljev in pogodbenimi dokazili. Podjetniška Politika varnosti tretjih oseb in dobaviteljev Third party and supplier security policy zahteva:

Pogodbe z dobavitelji morajo vključevati:

Politika Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME uporablja isto logiko skladnosti v lažjem operativnem modelu:

Pogodbe morajo vključevati obvezne klavzule, ki zajemajo:

Vrednost je v seznamu za temi besedami: obveznosti obveščanja o incidentih, dostop do dnevnikov, pravice do revizije, zaupnost, lokacija podatkov, kontrole podizvajalcev, sodelovanje z organi, podpora pri obnovitvi in izstopne obveznosti.

Zenith Blueprint, faza Controls in Action, korak 23, podaja pot implementacije:

Sestavite popoln seznam trenutnih dobaviteljev in ponudnikov storitev (5.19) ter jih razvrstite glede na dostop do sistemov, podatkov ali operativni nadzor. Za vsakega razvrščenega dobavitelja preverite, da so varnostna pričakovanja jasno vgrajena v pogodbe (5.20), vključno z zaupnostjo, dostopom, poročanjem o incidentih in obveznostmi skladnosti.

Nadaljuje s tveganjem v nadaljnji verigi:

Za vsakega kritičnega dobavitelja ugotovite, ali uporablja podizvajalce (podobdelovalce), ki lahko dostopajo do vaših podatkov ali sistemov. Dokumentirajte, kako se vaše zahteve informacijske varnosti prenašajo na te strani, bodisi prek pogodbenih določil vašega dobavitelja bodisi prek vaših neposrednih klavzul.

To je tudi pripravljenost za rezervo za kibernetsko varnost. Če zunanji izvajalec odzivanja med izrednimi razmerami vstopi v vaše okolje, morate poznati pravno podlago, obseg dostopa, pravila glede dokazil, obveznosti glede ravnanja s podatki, pot koordinacije z organi in pogoje izstopa. DORA to izrecno določa za finančne subjekte. NIS2 to naredi relevantno za bistvene in pomembne subjekte. ISO/IEC 27001:2022 to naredi preverljivo.

GDPR: vprašanje kršitve varnosti osebnih podatkov znotraj kibernetske krize

Ni vsak kibernetski incident kršitev varnosti osebnih podatkov, vendar je treba vsak resen incident presoditi tudi z vidika te možnosti.

GDPR se uporablja za obdelavo v okviru dejavnosti ustanovitve v EU ter tudi za upravljavce ali obdelovalce zunaj EU, ki posameznikom v EU ponujajo blago ali storitve ali spremljajo njihovo vedenje v EU. Opredeljuje osebne podatke, obdelavo, upravljavca, obdelovalca in kršitev varnosti osebnih podatkov. Njena načela vključujejo celovitost, zaupnost in odgovornost, kar pomeni, da morajo upravljavci znati dokazati skladnost.

Med incidentom ob 03:17 se mora Mariina ekipa vprašati:

• Ali je bil do osebnih podatkov omogočen dostop, ali so bili razkriti, spremenjeni, izgubljeni ali uničeni?
• Ali je InnovateCloud upravljavec, obdelovalec ali oboje za prizadete podatke?
• Ali so vključene posebne vrste osebnih podatkov?
• Katere stranke ali posamezniki so prizadeti?
• Ali so dnevniki zadostni za oceno obsega?
• Ali obveznosti obveščanja po GDPR tečejo vzporedno z obveznostmi po NIS2 ali DORA?

Zato koordinacija zasebnosti spada v eskalacijo incidenta, ne v pozni pravni pregled po tem, ko so sistemi že obnovljeni in so se dnevniki že prepisali.

Politika Politika beleženja in spremljanja - MSP Logging and Monitoring Policy - SME navaja:

Opozorila visoke prioritete je treba v 24 urah eskalirati generalnemu direktorju in koordinatorju za zasebnost

Ta klavzula je preprosta, vendar rešuje realen vzorec odpovedi. Odgovorne osebe za zasebnost potrebujejo dokazila, dokler so še dovolj sveža za ugotovitev, ali je prišlo do kršitve varnosti osebnih podatkov in ali so posamezniki izpostavljeni tveganju.

Sestavite 24-urni paket dokazil za čezmejni incident

Praktična vaja pripravljenosti mora simulirati prvih 24 ur čezmejnega incidenta. Cilj ni pretirano poročanje. Cilj je dokazati, da organizacija lahko zbere dejstva, sprejema zagovorljive odločitve in ohranja dosledno komunikacijo.

Scenarij

Vaš MSSP zazna sumljiv privilegiran dostop iz neobičajne regije do vašega produkcijskega najemnika. Ista izvorna infrastruktura se pojavi v opozorilih, ki vplivajo na dve stranki v dveh državah članicah. Ena stranka je finančni subjekt. Prizadeto okolje vsebuje osebne podatke, vendar odtujitev podatkov ni potrjena.

1. korak: odprite zapis o incidentu

Ustvarite zahtevek za incident z odobrenimi polji za razvrščanje. Vključite čas seznanitve, vir zaznave, prizadeta sredstva, prizadete storitve, potencialno prizadete države, sumljivo zlonamerno dejavnost, začetno resnost in vodjo incidenta.

To povežite s kontrolami ISO/IEC 27002:2022 5.24, 5.25 in 5.26 ter s kontrolami Priloge A ISO/IEC 27001:2022 A.5.24, A.5.25 in A.5.26.

2. korak: sprožite delovni tok odločanja o organih

Uporabite matriko kontaktov organov, ki jo zahteva Zenith Blueprint korak 22. Ugotovite, kateri organi so lahko relevantni: nacionalni CSIRT, organ za varstvo podatkov, finančni regulator, organi pregona in sektorski regulator.

Zabeležite odločitev in utemeljitev. Če zgodnje opozorilo po NIS2 ni podano, zajemite razlog. Če je čezmejni vpliv mogoč, zabeležite dokazila, ki podpirajo ta sklep.

3. korak: ohranite dokazila pred obsežnejšo sanacijo

Podjetniška Politika zbiranja dokazov in forenzike Evidence Collection and Forensics Policy navaja:

Vsa zbrana dokazila morajo biti enolično identificirana, označena in shranjena v varnem repozitoriju z:

Politika Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME isto disciplino podaja v enostavnejši obliki:

»Vsak element digitalnih dokazov mora biti evidentiran z:«

Iz Evidence Collection and Forensics Policy - SME, razdelek »Zahteve upravljanja«, klavzula 5.2.1.

Za namizno vajo zberite vzorčne vnose dokazil: izvoz opozorila SIEM, dnevnike ponudnika identitet, zapise privilegiranih sej, posnetek končne točke, dnevnike požarnega zidu, revizijske dnevnike v oblaku, zapiske o vplivu na stranke in odobritve komunikacij.

4. korak: aktivirajte pomoč dobaviteljev

Preverite evidenco dobaviteljev. Identificirajte MSSP, ponudnika storitev v oblaku in kritične podizvajalce. Potrdite klavzule podpore pri incidentih, eskalacijske kontakte, roke hrambe dnevnikov, format dokazil in obveznosti sodelovanja z organi.

To neposredno podpira zahteve DORA glede tveganja tretjih ponudnikov IKT in pričakovanja NIS2 glede varnosti dobavne verige.

5. korak: pripravite tri komunikacije

Pripravite tri komunikacije iz iste dejanske podlage:

6. korak: zaključite s pridobljenimi izkušnjami

Posodobite register tveganj, izjavo o uporabnosti, evidenco dobaviteljev in načrt odzivanja na incidente. Če vaja pokaže manjkajoče dnevnike, nejasne kontakte organov ali šibke dobaviteljske klavzule, odprite korektivne ukrepe.

Zenith Blueprint, faza Controls in Action, korak 23, organizacijam naroča, naj zmogljivosti za incidente preverijo tako:

Izberite nedavni dogodek ali izvedite namizno vajo za preverjanje svojega načrta. Zajemite in evidentirajte vse odločitve, vloge in komunikacije (5.26) ter posodobite načrt s pridobljenimi izkušnjami (5.27). Potrdite, da so vzpostavljeni postopki za ohranjanje forenzičnih dokazov (5.28), vključno s posnetki dnevnikov, varnostnimi kopijami in varno izolacijo prizadetih sistemov.

Ta odstavek je agenda vaje, pripravljena za presojo.

Beleženje: razlika med koordinacijo in ugibanjem

Koordinacija čezmejnih incidentov odpove, kadar imajo vsi mnenja, nihče pa časovnih žigov.

Zenith Blueprint, faza Controls in Action, korak 19, to jasno pove:

Beleženje je življenjska sila vsakega varnega IT okolja. Brez njega incidenti ostanejo nevidni, odgovornost zbledi, vzročno-posledične povezave pa izginejo v prazno.

Nadaljuje:

V svojem bistvu je beleženje povezano s sledljivostjo. Ko gre nekaj narobe, ne glede na to, ali gre za neuspešen poskus prijave, izbris kritičnih datotek ali neodobreno skripto, ki teče na strežniku, dnevniki zagotavljajo forenzično nit, ki vam pomaga razplesti, kaj se je zares zgodilo.

Za NIS2 dnevniki podpirajo 72-urno obvestilo o incidentu z začetno resnostjo, vplivom in kazalniki kompromitacije. Za DORA dnevniki podpirajo razvrstitev večjega incidenta, povezanega z IKT, analizo temeljnega vzroka, operativni vpliv in odgovornost tretjih oseb. Za GDPR dnevniki podpirajo presojo, ali je bil omogočen dostop do osebnih podatkov ali so bili ti razkriti. V kontekstu Akta o kibernetski solidarnosti dnevniki podpirajo skupno situacijsko zavedanje, ne da bi se morali odzivniki zanašati na ugibanja.

Če je odgovor na katero koli vprašanje »nisem prepričan«, zadeva sodi v načrt obravnave tveganja.

Neprekinjeno poslovanje in varno krizno delovanje

Razprava o Aktu o kibernetski solidarnosti se naravno osredotoča na odzivanje na incidente, vendar odpornost pomeni tudi varno ohranjanje kritičnih storitev med motnjo.

Člen 21 NIS2 zahteva pristop za vse vrste nevarnosti, ki zajema obravnavanje incidentov, neprekinjeno poslovanje, upravljanje varnostnega kopiranja, obnovitev po nesreči, krizno upravljanje, varnost dobavne verige, obravnavanje ranljivosti, oceno učinkovitosti, kibernetsko higieno, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev, večfaktorsko avtentikacijo, varne komunikacije in, kadar je ustrezno, zavarovane komunikacije v sili.

DORA podobno zahteva upravljanje, upravljanje IKT-tveganj, upravljanje incidentov, testiranje odpornosti, upravljanje tveganj tretjih oseb, neprekinjeno poslovanje in obnovitev. Manjši subjekti imajo lahko poenostavljene zahteve, vendar še vedno potrebujejo dokumentirano upravljanje IKT-tveganj, spremljanje, odporne sisteme, obravnavanje incidentov, identifikacijo odvisnosti od tretjih oseb, varnostne kopije, obnovitev, testiranje, učenje po incidentu in usposabljanje.

Podjetniška Politika neprekinjenega poslovanja in obnovitve po nesreči Business Continuity Policy and Disaster Recovery Policy izhaja iz preproste zahteve:

Načrti morajo zajemati:

Za to besedno zvezo stojijo dokazila neprekinjenega poslovanja, ki jih presojevalci pričakujejo: prioritete obnovitve, ciljni časi obnovitve, ciljne točke obnovitve, urniki varnostnega kopiranja, testi obnovitve, krizne vloge, nadomestne komunikacije, odvisnosti od dobaviteljev in ukrepi izboljšav po vaji.

Kontroli ISO/IEC 27002:2022 5.29 in 5.30 sta tu osrednji. Kontrola 5.29 obravnava informacijsko varnost med motnjo. Kontrola 5.30 obravnava pripravljenost IKT za neprekinjeno poslovanje. V Zenith Controls je načrtovanje incidentov pod 5.24 povezano z varnostjo med motnjo in širšim načrtovanjem neprekinjenega poslovanja. To je posebej pomembno, kadar običajni kanali niso na voljo, so sistemi identitet degradirani ali se morajo krizne ekipe usklajevati z organi prek zavarovanih komunikacij v sili.

Preslikava med več okviri skladnosti: NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019

Vodja informacijske varnosti ne potrebuje petih ločenih programov za incidente. Potrebuje en model dokazil, ki ga je mogoče gledati skozi pet zornih kotov.

Metoda trenutnega in ciljnega profila NIST CSF 2.0 je posebej uporabna za organizacije, ki še niso dovolj zrele za popolnoma integrirano platformo GRC. Organizacije spodbuja, naj določijo obseg profila, zberejo vhodne podatke, kot so politike, prioritete korporativnih tveganj, analize vpliva na poslovanje, zahteve, standardi, postopki, varovalni ukrepi in vloge, nato analizirajo vrzeli in pripravijo prednostno razvrščen akcijski načrt. To je blizu praktičnemu sprintu pripravljenosti na Akt o kibernetski solidarnosti: trenutna dokazila, ciljne obveznosti, načrt vrzeli, lastniki, datumi in revizijska sled.

Presojevalci COBIT 2019 in presojevalci v slogu ISACA običajno sprašujejo, ali imajo cilji upravljanja lastnike ter ali se merijo in spremljajo. Ne bodo zadovoljni z odgovorom »to ureja SOC«. Vprašali bodo, kako organi upravljanja odobravajo ukrepe za tveganja, kako se poroča o uspešnosti, kako se upravlja tveganje tretjih oseb, kako se sprejemajo izjeme in kako se spremljajo korektivni ukrepi.

Kako bodo presojevalci preverjali isti incident

Isti incident ob 03:17 ustvari različna presojna vprašanja glede na mandat ocenjevalca.

Presojevalec ISO/IEC 27001:2022 bo začel pri ISMS. Vprašal bo, ali je proces incidentov v obsegu, ali zahteve zainteresiranih strani vključujejo NIS2, DORA, GDPR in pogodbe, ali je ocena tveganja upoštevala čezmejne in dobaviteljske scenarije, ali so bile kontrole Priloge A izbrane v izjavi o uporabnosti in ali operativni zapisi dokazujejo, da je bil proces upoštevan.

Organ ali ocenjevalec, osredotočen na NIS2, se bo osredotočil na odgovornost vodstva, ukrepe za upravljanje tveganj iz člena 21 in poročanje po členu 23. Vprašal bo, kdaj se je organizacija seznanila z incidentom, zakaj je bil ali ni bil pomemben, kako je bil ocenjen čezmejni vpliv, ali so bile stranke obveščene in ali so bili korektivni ukrepi izvedeni brez nepotrebnega odlašanja.

Nadzornik DORA ali skupina za notranjo revizijo bo vprašala, ali je incident vplival na kritične ali pomembne funkcije, ali so tretji ponudniki IKT podprli odziv, ali je finančni subjekt ohranil odgovornost, ali je bil register informacij točen, ali je bil incident pravilno razvrščen in ali so se pridobljene izkušnje vrnile v testiranje odpornosti in nadzor nad dobavitelji.

Presojevalec GDPR ali organ za varstvo podatkov bo vprašal, ali je imela organizacija dovolj dokazil za ugotovitev, ali je prišlo do kršitve varnosti osebnih podatkov, ali so bile vloge upravljavca in obdelovalca jasne, ali so bili posamezniki, na katere se nanašajo podatki, izpostavljeni tveganju, ali so bile kontrole zaupnosti in celovitosti ustrezne ter ali so se vzdrževali zapisi odgovornosti.

Ocenjevalec NIST CSF 2.0 bo dogodek prevedel v rezultate Govern, Identify, Protect, Detect, Respond in Recover. Iskal bo pričakovanja zainteresiranih strani, zakonske obveznosti, apetit po tveganju, upravljanje dobaviteljev, beleženje, spremljanje, izvedbo odziva, komunikacije in preverjanje obnovitve.

Presojevalec COBIT 2019 ali ISACA se bo osredotočil na upravljanje in učinkovitost sistema upravljanja: lastništvo, pravice odločanja, metrike, sprejem tveganja, uspešnost procesov, zagotovila in nenehno izboljševanje.

Tu je Zenith Controls uporaben kot kompas skladnosti med okviri. Ne preimenuje uradnih kontrol in ne ustvarja vzporednega okvira kontrol. Prikazuje, kako se kontrole ISO/IEC 27002:2022, kot so 5.5, 5.24 in 5.28, povezujejo z operativnimi zmogljivostmi, povezanimi kontrolami in dokazili, relevantnimi za presojo.

Kaj morajo vodje informacijske varnosti storiti zdaj za pripravljenost v letu 2026

Če se pripravljate na operativno realnost Akta EU o kibernetski solidarnosti, začnite z dokazili, ne s slogani.

Najprej posodobite kontekst ISMS in analizo zainteresiranih strani. Ugotovite, ali vaša organizacija, stranke ali dobavitelji spadajo pod NIS2, DORA ali GDPR. Vključite prisotnost po državah članicah, sektorsko razvrstitev, kritične stranke, odvisnosti od storitev IKT in kontakte pristojnih organov.

Drugič, izvedite namizno vajo čezmejnega incidenta. Uporabite scenarij, ki vključuje dobavitelja, več kot eno državo članico, možno izpostavljenost osebnih podatkov in regulirano finančno stranko. Časovno omejite prvih 24 ur.

Tretjič, preglejte pogodbe z dobavitelji. Potrdite obveznosti obveščanja, dostop do dnevnikov, forenzično podporo, sodelovanje z organi, prenos obveznosti na podizvajalce, lokacijo podatkov, pravice do revizije, podporo neprekinjenemu poslovanju in pravice do odpovedi.

Četrtič, preizkusite zbiranje dokazov. Izvozite dnevnike, ohranite posnetke, označite dokazila, zabeležite verigo skrbništva in preverite dostop do repozitorija. Če vaša politika pravi, da so dokazila enolično identificirana in varno shranjena, to dokažite.

Petič, uskladite komunikacije o incidentu. Vaše zgodnje opozorilo po NIS2, eskalacija po DORA, ocena kršitve po GDPR in obvestilo stranki si ne smejo nasprotovati. Lahko imajo različne pravne namene, vendar morajo izhajati iz iste dejanske podlage.

Šestič, vključite upravni odbor v vajo. NIS2 in DORA obe povečujeta odgovornost vodstva. Klavzule vodstva v ISO/IEC 27001:2022 to naredijo preverljivo. Upravni odbor, ki še nikoli ni videl 24-urnega roka za kibernetsko obvestilo, ni pripravljen na čezmejno krizo.

Naslednji koraki s Clarysec

Prihodnost kibernetske varnosti EU temelji na sodelovanju in dokazanem zaupanju. Organizacije, ki NIS2 in DORA obravnavajo kot ločene kontrolne sezname, bodo imele težave med čezmejnimi incidenti. Organizacije, ki gradijo operativne sisteme ISO/IEC 27001:2022, podprte z dokazili, bodo lahko regulatorjem, strankam, presojevalcem in kriznim odzivnikom odgovarjale z zaupanjem.

Clarysec pomaga vodjem informacijske varnosti, vodjem skladnosti, presojevalcem in lastnikom podjetij pretvoriti kibernetsko regulativo EU v operativna dokazila, pripravljena za presojo, prek:

• Zenith Blueprint: 30-koračni načrt presojevalca za strukturirano implementacijo ISO/IEC 27001:2022 in zaporedje presoje.
• Zenith Controls: vodnik po skladnosti med okviri za preslikavo kontrol za incidente, organe, dobavitelje, dokazila, beleženje in neprekinjeno poslovanje med okviri.
• Predlog politik Clarysec, vključno z Politiko odzivanja na incidente, Politiko zbiranja dokazov in forenzike, Politiko varnosti tretjih oseb in dobaviteljev, Politiko neprekinjenega poslovanja in obnovitve po nesreči, ter različicami za MSP, kadar je pomembna sorazmernost.

Najboljši čas za pripravo na koordinacijo čezmejnih incidentov je pred opozorilom ob 03:17. Drugi najboljši čas je danes.

Začnite s pregledom pripravljenosti Clarysec, prenesite ustrezen nabor politik ali zahtevajte predstavitev, kako lahko Zenith Blueprint in Zenith Controls pomagata vašemu ISMS ustvariti dokazila, ki jih bo kibernetska odpornost leta 2026 zahtevala.