NIST reaģēšanas uz incidentiem kartēšana 2026. gada auditiem

Ir otrdiena, 07:42. Anja, strauji augošas finanšu tehnoloģiju platformas galvenā informācijas drošības vadītāja, saņem pirmo brīdinājumu: neiespējamas pārvietošanās pazīme administratora kontā. Seko vairāki neveiksmīgi pieteikšanās mēģinājumi, pēc tam veiksmīga sesija no nepārvaldītas ierīces. Pēc piecām minūtēm klientu atbalsts ziņo, ka lietotāji nevar piekļūt pamata SaaS darbplūsmai. Plkst. 08:10 mākoņvides informācijas panelis rāda anomālus API izsaukumus pret glabāšanas konteineru, kurā var atrasties personas dati.
Informācijas drošības komanda rīkojas ātri. SIEM ģenerē brīdinājumu, mākoņvides inženieris atsauc sesiju, un pakalpojuma īpašnieks sāk atjaunot piekļuvi. Taču īstā krīze nav tikai tehniska. Tā ir pārvaldības krīze.
Anjai līdz pirmās stundas beigām jāatbild uz trim jautājumiem.
Pirmkārt, vai tas ir informācijas drošības incidents, personas datu aizsardzības pārkāpums, NIS2 būtisks incidents vai DORA būtisks ar IKT saistīts incidents?
Otrkārt, kurš ir jāinformē, līdz kuram termiņam un ar kādiem pierādījumiem?
Treškārt, vai organizācija var pierādīt, ka tās reaģēšanas uz incidentiem process faktiski tika izpildīts, kā paredzēts?
Tieši šajā brīdī daudzas organizācijas saprot atšķirību starp reaģēšanas uz incidentiem plānu un reaģēšanas uz incidentiem pārvaldības sistēmu. NIST SP 800-61 reaģēšana uz incidentiem un NIST CSF 2.0 vairs nav tikai SOC rokasgrāmatu tēmas. 2026. gadā tās ir tieši saistītas ar valdes pārskatatbildību, ISO/IEC 27001:2022 auditiem, NIS2 pakāpenisku ziņošanu, DORA darbības noturību, GDPR personas datu aizsardzības pārkāpumu lēmumiem un piegādātāju pārskatatbildību.
Spēcīgākās programmas neveido atsevišķus reaģēšanas ceļus katram ietvaram. Tās izmanto NIST CSF 2.0 kā darbības karti, ISO/IEC 27001:2022 kā pārvaldības sistēmas mugurkaulu un vienotu pierādījumu modeli, kas vienlaikus atbalsta NIS2, DORA un GDPR. Tā ir Clarysec pieeja: politiku vadīti lēmumi, galda mācībās pārbaudītas darbplūsmas, regulatoriem sagatavotas pierādījumu pakotnes un starpietvaru kartēšana, izmantojot Zenith Blueprint: auditora 30 soļu ceļvedi un Zenith Controls: starpatbilstības ceļvedi.
2026. gada problēma: viens incidents, vairāki pārskatatbildības režīmi
Incidents, ar kuru saskaras Anja, nav viena atbilstības problēma. Tie ir vairāki pārklājošies lēmumu pieņemšanas ceļi.
Ja organizācija nodrošina mākoņpakalpojumus, SaaS, pārvaldītus pakalpojumus, pārvaldītus drošības pakalpojumus, DNS, datu centra pakalpojumus, uzticamības pakalpojumus vai citus digitālās infrastruktūras pakalpojumus, var būt piemērojama NIS2. Būtiskas vai svarīgas vienības klasifikācija ir atkarīga no nozares, lieluma un nacionālās ieviešanas, taču virziens ir skaidrs: incidentu apstrāde tagad ir regulēta vadības atbildība.
Ja organizācija ir finanšu vienība, DORA var būt galvenais darbības noturības regulējums. DORA ir piemērojama no 2025. gada 17. janvāra un aptver IKT risku pārvaldību, būtisku ar IKT saistītu incidentu ziņošanu, darbības noturības testēšanu, informācijas apmaiņu, IKT trešo pušu risku un kritisku IKT trešo pušu pakalpojumu sniedzēju uzraudzību. Aptvertajām finanšu vienībām, uz kurām attiecas arī NIS2, DORA darbojas kā nozares specifiskais ietvars pārklājošiem IKT riska un incidentu ziņošanas pienākumiem.
Ja personas datiem tika piekļūts, tie tika mainīti, zaudēti, iznīcināti vai izpausti, GDPR kļūst par daļu no reaģēšanas uz incidentiem lēmumu koka. GDPR definē personas datu aizsardzības pārkāpumu kā drošības pārkāpumu, kura rezultātā notiek nejauša vai nelikumīga personas datu iznīcināšana, nozaudēšana, izmainīšana, neatļauta izpaušana vai piekļuve tiem. GDPR prasa arī pārskatatbildību, proti, pārzinim jāspēj pierādīt atbilstību apstrādes principiem, tostarp integritātei un konfidencialitātei.
Ja uzņēmums ir sertificēts atbilstoši ISO/IEC 27001:2022 vai gatavojas sertifikācijai, incidents kļūst par IDPS pierādījumiem. Auditori pārbaudīs piemērošanas jomu, juridiskos pienākumus, lomas, riska apstrādi, kontroles pasākumu atlasi, darbības izpildi, dokumentētu informāciju, gūtās mācības un nepārtrauktu uzlabošanu. ISO/IEC 27001:2022 4.1 līdz 4.4 punkti prasa, lai IDPS atspoguļotu kontekstu, ieinteresētās puses, pienākumus, piemērošanas jomu un procesu savstarpējo mijiedarbību. 5.1 līdz 5.3 punkti prasa vadību, pārskatatbildību un piešķirtus pienākumus. 6.1.1 līdz 6.1.3 punkti prasa informācijas drošības risku pārvaldību, riska apstrādi un Piemērojamības paziņojumu. 8.1 līdz 8.3 punkti prasa kontrolētu darbību, pierādījumus, ka procesi tika izpildīti, kā plānots, ārpakalpojumā nodotu procesu kontroli un riska apstrādes ieviešanu.
Organizācijas problēma nav ietvaru trūkums. Tā ir vienota darbības modeļa trūkums, kas pārvērš ietvarus savlaicīgos lēmumos un uzticamos pierādījumos.
Izmantojiet NIST CSF 2.0 kā kopīgu valodu
NIST CSF 2.0 ir noderīgs, jo tas vadībai, drošības, juridiskajām, privātuma, operāciju komandām un piegādātājiem nodrošina kopīgu valodu kiberdrošības rezultātiem. Tā GOVERN funkcija ir īpaši svarīga reaģēšanai uz incidentiem, jo tā liek organizācijām pirms krīzes risināt pārraudzību, politikas, risku stratēģiju, lomas un piegādes ķēdes risku.
Reaģēšanai uz incidentiem CSF 2.0 sasaista pārvaldību ar darbības dzīves ciklu: IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER. Šī struktūra palīdz pārvērst trokšņainu incidentu kontrolētā pierādījumu plūsmā.
| Reaģēšanas uz incidentiem jautājums | CSF 2.0 rezultātu joma | Izveidotie atbilstības pierādījumi |
|---|---|---|
| Kam pieder lēmums? | GOVERN, tostarp GV.RR, GV.OV un GV.PO | RACI, incidenta vadītāja ieraksts, vadības atjauninājumi, valdes paziņojumi |
| Kuri aktīvi un pakalpojumi ir ietekmēti? | IDENTIFY, tostarp aktīvu un risku redzamība | Aktīvu uzskaite, pakalpojumu karte, datu uzskaite, kritisko piegādātāju saraksts |
| Kuri kontroles pasākumi nedarbojās vai nostrādāja? | PROTECT, tostarp piekļuve, datu drošība, konfigurācija un rezerves kopijas | MFA žurnāli, priviliģētas piekļuves ieraksti, rezerves kopiju ieraksti, bāzes konfigurācijas |
| Kā notikums tika atklāts? | DETECT, tostarp DE.CM un DE.AE | SIEM brīdinājumi, EDR brīdinājumi, mākoņvides žurnāli, korelācijas piezīmes, incidenta deklarēšanas ieraksts |
| Kā tas tika apstrādāts? | RESPOND, tostarp RS.MA, RS.AN, RS.CO un RS.MI | Incidenta pieteikums, smaguma pakāpes klasifikācija, laika skala, lēmumu žurnāls, ierobežošanas darbības |
| Kā pakalpojums tika atjaunots? | RECOVER, tostarp RC.RP un RC.CO | Atjaunošanas izpilde, rezerves kopiju validācija, atjaunota pakalpojuma pierādījumi, komunikācija, slēgšanas pārskats |
CSF 2.0 organizācijas profili padara to praktiski izmantojamu. Pašreizējais profils parāda organizācijas reālās reaģēšanas uz incidentiem spējas, tostarp trūkumus, neskaidrības un apiešanas risinājumus. Mērķa profils definē vēlamo stāvokli, piemēram, smaguma pakāpes klasifikāciju vienas stundas laikā, dokumentētus paziņošanas lēmumus, pierādījumu saglabāšanu, trešo pušu koordināciju un regulatoriem sagatavotas ziņošanas pakotnes.
Anjas finanšu tehnoloģiju uzņēmumā pašreizējais profils parādīja ierastu modeli: spēcīgi rīki, vāja lēmumu pārvaldība. Mērķa profils koncentrējās uz konkrētiem CSF 2.0 rezultātiem, tostarp:
- RS.MA-01, pēc incidenta deklarēšanas reaģēšanas uz incidentiem plāns tiek izpildīts koordinācijā ar attiecīgajām trešajām pusēm.
- RS.MA-02, incidentu ziņojumi tiek sākotnēji izvērtēti un validēti.
- RS.MA-03, incidenti tiek kategorizēti un prioritizēti.
- RS.MA-04, incidenti pēc vajadzības tiek eskalēti vai paaugstināti.
- RS.AN-03, tiek veikta analīze, lai noteiktu incidenta laikā notikušo un pamatcēloni.
- RS.AN-06, izmeklēšanas laikā veiktās darbības tiek reģistrētas, un tiek saglabāta ierakstu integritāte un izcelsme.
- RS.AN-07, incidenta dati un metadati tiek vākti, un tiek saglabāta to integritāte un izcelsme.
- RS.CO-02, iekšējās un ārējās ieinteresētās puses tiek informētas par incidentiem.
- RS.MI-01, incidenti tiek ierobežoti.
- RS.MI-02, incidenti tiek izskausti.
- RC.RP-03, pirms rezerves kopiju un citu atjaunošanas aktīvu izmantošanas atjaunošanai tiek pārbaudīta to integritāte.
Ietvars pats par sevi nav auditējama programma. Rezultātiem jābūt iekļautiem pārvaldības sistēmā, un tieši šeit ISO/IEC 27001:2022 nodrošina mugurkaulu.
Nostipriniet reaģēšanu uz incidentiem ISO/IEC 27001:2022 ietvaros
NIST nodrošina praktisku incidentu apstrādes valodu. ISO/IEC 27001:2022 nodrošina darbības disciplīnu, ko sagaida auditori. IDPS pārvērš reaģēšanu uz incidentiem no rokasgrāmatu kopuma par pārvaldītu procesu ar piemērošanas jomu, īpašumtiesībām, riska apstrādi, veiktspējas izvērtēšanu un uzlabošanu.
Būtiskākā A pielikuma kontroles pasākumu grupa ir:
| ISO/IEC 27001:2022 A pielikuma kontroles pasākums | Kontroles pasākuma nosaukums | Reaģēšanas uz incidentiem mērķis |
|---|---|---|
| A.5.24 | Informācijas drošības incidentu pārvaldības plānošana un sagatavošana | Izveido plānu, lomas, eskalācijas un komunikācijas modeli |
| A.5.25 | Informācijas drošības notikumu izvērtēšana un lēmuma pieņemšana | Definē sākotnējo izvērtēšanu, klasifikāciju un lēmumu kritērijus |
| A.5.26 | Reaģēšana uz informācijas drošības incidentiem | Nodrošina ierobežošanu, izskaušanu, atjaunošanu un komunikāciju |
| A.5.27 | Mācīšanās no informācijas drošības incidentiem | Pārvērš gūtās mācības korektīvās darbībās un uzlabojumos |
| A.5.28 | Pierādījumu vākšana | Saglabā pierādījumu uzticamību, izcelsmi un juridisko izmantojamību |
Clarysec Zenith Controls ceļvedis kartē šīs ISO/IEC 27002:2022 kontroles atsauces ar citiem standartiem, audita gaidām un saistītiem atbilstības pienākumiem. Tas nav atsevišķs kontroles pasākumu ietvars. Tas ir starpatbilstības ceļvedis, kas palīdz organizācijām saprast, kā tās pašas kontroles darbības atbalsta vairākas apliecinājuma vajadzības.
Zenith Blueprint, Controls in Action fāzes 23. solis, padara reaģēšanas uz incidentiem mugurkaulu operatīvu:
Nodrošiniet, ka jums ir aktuāls reaģēšanas uz incidentiem plāns (5.24), kas aptver sagatavošanos, eskalāciju, reaģēšanu un komunikāciju. Definējiet, kas ir ziņojams drošības notikums (5.25), un kā tiek aktivizēts un dokumentēts lēmumu pieņemšanas process. Izvēlieties nesenu notikumu vai veiciet galda mācības, lai validētu plānu. Fiksējiet un reģistrējiet visus lēmumus, lomas un komunikāciju (5.26), kā arī atjauniniet plānu ar gūtajām mācībām (5.27). Apstipriniet, ka ir ieviestas procedūras digitālās kriminālistikas pierādījumu saglabāšanai (5.28), tostarp žurnālu momentuzņēmumi, rezerves kopijas un ietekmēto sistēmu droša izolācija.
Šī rindkopa ir praktisks tilts no NIST incidentu apstrādes uz audita pierādījumiem. Sagatavojiet spēju, klasificējiet notikumu, reaģējiet kontrolētā veidā, mācieties no rezultāta un saglabājiet pierādījumus.
Iebūvējiet ziņojamību pirmajā stundā
Reaģēšanas uz incidentiem programmas pirmajā stundā bieži neizdodas nevis tāpēc, ka analītiķiem trūktu prasmju, bet tāpēc, ka organizācija nav definējusi, kurš pieņem lēmumu, kad tiek piešķirta smaguma pakāpe, kādi pierādījumi tiek saglabāti un kad tiek pārbaudīti juridiskie trigeri.
SME vajadzībām Clarysec Incident Response Policy-sme nosaka skaidru pārvaldības prasību:
Ģenerāldirektoram, saņemot IT pakalpojumu sniedzēja informāciju, visi incidenti jāklasificē pēc smaguma pakāpes vienas stundas laikā pēc paziņojuma saņemšanas.
Tā ir spēcīga prasība. Tā nenozīmē, ka vienas stundas laikā ir zināmi visi fakti. Tā nozīmē, ka organizācijai jādokumentē sākotnējā smaguma pakāpe, jāreģistrē nenoteiktība un jāaktivizē eskalācija, kamēr fakti vēl tiek noskaidroti.
Tā pati politika prasa arī juridiskos termiņus iestrādāt procesā:
Reaģēšanas termiņiem, tostarp datu atjaunošanas un paziņošanas pienākumiem, jābūt dokumentētiem un saskaņotiem ar juridiskajām prasībām, piemēram, GDPR 72 stundu personas datu aizsardzības pārkāpuma paziņošanas prasību.
Uzņēmuma vidēm Clarysec Incident Response Policy nostiprina formālāku reaģēšanas modeli:
Organizācijai jāuztur centralizēts, līmeņots reaģēšanas uz incidentiem ietvars, kas saskaņots ar ISO/IEC 27035 un sastāv no šādām definētām reaģēšanas fāzēm:
Uzņēmuma politika arī 6.4.1 punktā iekļauj starpregulatīvas termiņu atsauces:
GDPR Article 33 (72 stundu paziņošana uzraudzības iestādei)
NIS2 Article 23 (paziņošana 24 stundu laikā no brīža, kad organizācija uzzina par incidentu)
DORA Article 17 (ziņošana par smagiem ar IKT saistītiem incidentiem)
Tā ir atšķirība starp tehnisku rokasgrāmatu un pārvaldībai gatavu reaģēšanas uz incidentiem ietvaru. Juridiskie un regulatīvie ziņošanas ceļi krīzes laikā netiek improvizēti. Tos aktivizē iepriekš definēti klasifikācijas un lēmumu punkti.
Iekļaujiet NIS2 ziņošanu incidenta darbplūsmā
NIS2 prasa būtiskām un svarīgām vienībām bez nepamatotas kavēšanās informēt CSIRT vai kompetento iestādi par būtiskiem incidentiem, kas ietekmē pakalpojumu sniegšanu. Būtisks incidents ietver incidentu, kas izraisīja vai var izraisīt smagus darbības traucējumus vai finansiālus zaudējumus, vai incidentu, kas ietekmēja vai var ietekmēt citas personas, radot ievērojamu materiālu vai nemateriālu kaitējumu.
Ziņošanas modelis ir pakāpenisks.
| NIS2 posms | Termiņš | Pierādījumi, kas jāizveido jūsu procesam |
|---|---|---|
| Agrīnais brīdinājums | 24 stundu laikā pēc uzzināšanas par incidentu | Incidenta deklarēšana, aizdomas par ļaunprātīgām darbībām, pārrobežu ietekmes pārbaude, sākotnējais skatījums uz ietekmēto pakalpojumu |
| Incidenta paziņojums | 72 stundu laikā | Smaguma pakāpes izvērtējums, ietekmes analīze, kompromitācijas indikatori, ja pieejami, nenoteiktības žurnāls |
| Starpposma ziņojumi | Pēc pieprasījuma | Statusa atjauninājumi, ierobežošanas darbības, atjaunošanas statuss, komunikācija ar regulatoru |
| Galīgais ziņojums | Viena mēneša laikā pēc incidenta paziņojuma | Smagums un ietekme, iespējamais apdraudējums vai pamatcēlonis, mazināšanas pasākumi, pārrobežu ietekme |
| Notiekoša incidenta progresa ziņojums | Ja galīgā ziņojuma termiņā incidents vēl turpinās | Progresa ziņojums, pēc tam galīgais ziņojums viena mēneša laikā pēc apstrādes |
NIS2 Article 21 prasa arī atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus. Nepieciešamais pamatlīmenis ietver risku analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu izstrādi, ievainojamību apstrādi, efektivitātes izvērtēšanu, kiberdrošības higiēnu un apmācību, kriptogrāfiju, personālvadības drošību, piekļuves kontroli, aktīvu pārvaldību un, attiecīgā gadījumā, daudzfaktoru autentifikāciju un drošu saziņu.
NIS2 Article 20 iesaista vadības struktūras pārskatatbildības ķēdē. Tām jāapstiprina kiberdrošības riska pārvaldības pasākumi un jāpārrauga to ieviešana. Reaģēšanas uz incidentiem kontekstā tas nozīmē, ka valdes protokoli, vadības apstiprinājumi, apmācību ieraksti un eskalācijas pierādījumi nav izvēles administratīvi artefakti. Tie ir daļa no regulatīvā pamatojuma.
Sodi palielina steidzamību. Par Article 21 vai Article 23 pārkāpumiem būtiskām vienībām jāpiemēro maksimālie naudas sodi vismaz EUR 10 miljonu apmērā vai 2 procentu apmērā no kopējā pasaules gada apgrozījuma, izvēloties lielāko summu. Svarīgām vienībām jāpiemēro maksimālie naudas sodi vismaz EUR 7 miljonu apmērā vai 1,4 procentu apmērā no kopējā pasaules gada apgrozījuma, izvēloties lielāko summu.
Praktiskā mācība ir vienkārša: ja uzzināšanas laiks, smaguma kritēriji, eskalācija un ziņošanas lēmumi netiek reģistrēti, jautājums vairs nav tikai reaģēšanas uz incidentiem briedums. Tas kļūst par regulatīvo pierādījumu problēmu.
Uztveriet DORA incidentu pārvaldību kā darbības noturību
DORA maina diskusiju finanšu vienībām, jo incidentu pārvaldība ir daļa no digitālās darbības noturības, nevis tikai drošības operācijām.
Article 5 prasa, lai vadības struktūra definētu, apstiprinātu un pārraudzītu IKT risku pārvaldības ietvaru un saglabātu atbildību par to. Article 6 paplašina šo ietvaru par strukturētu IKT risku pārvaldības sistēmu. Article 17 prasa finanšu vienībām definēt, izveidot un ieviest ar IKT saistītu incidentu pārvaldības procesu, lai atklātu, pārvaldītu un paziņotu ar IKT saistītus incidentus. Procesam jāreģistrē ar IKT saistīti incidenti un būtiski kiberdraudi, jāidentificē un jānovērš pamatcēloņi, jāizmanto agrīnā brīdinājuma indikatori, jāklasificē incidenti pēc prioritātes, smaguma pakāpes un ietekmēto pakalpojumu kritiskuma, jāpiešķir lomas un pienākumi, jāizveido komunikācija un eskalācija, jāinformē klienti un plašsaziņas līdzekļi, kur tas nepieciešams, vismaz par būtiskiem incidentiem jāziņo augstākajai vadībai, jāinformē vadības struktūra un jāuztur reaģēšanas procedūras ietekmes mazināšanai un drošu operāciju atjaunošanai.
Article 18 prasa klasifikāciju, balstoties uz tādiem kritērijiem kā ietekmētie klienti vai darījumu partneri, darījumi, reputācijas ietekme, ilgums un dīkstāve, ģeogrāfiskais izplatījums, datu zudumi, kas ietekmē pieejamību, autentiskumu, integritāti vai konfidencialitāti, ietekmēto pakalpojumu kritiskums un ekonomiskā ietekme. Article 19 prasa ziņot kompetentajai iestādei par būtiskiem ar IKT saistītiem incidentiem, ļauj brīvprātīgi paziņot par būtiskiem kiberdraudiem un prasa bez nepamatotas kavēšanās informēt klientus, ja būtisks ar IKT saistīts incidents ietekmē klientu finansiālās intereses.
Anjas finanšu tehnoloģiju uzņēmumam tas nozīmē, ka incidenta ierakstam vajag vairāk nekā SOC laika skalu. Tam ir vajadzīgi:
- Ietekmētais pakalpojums un kritiskums.
- Ietekmētie klienti, darījumu partneri vai darījumi.
- Dīkstāves ilgums un ģeogrāfiskais izplatījums.
- Datu zuduma vai integritātes ietekme.
- Ekonomiskā ietekme.
- Vadības struktūras redzamība.
- Klientu paziņošanas lēmums.
- Pamatcēloņa slēgšana.
- Drošu operāciju atjaunošana.
- Piegādātāja iesaiste un līgumiskie pierādījumi.
DORA paplašina incidenta stāstu arī piegādātāju pārvaldībā. Articles 28 līdz 30 prasa finanšu vienībām pārvaldīt IKT trešo pušu risku, uzturēt IKT pakalpojumu līgumisko vienošanos reģistru, izvērtēt koncentrācijas risku, veikt sākotnējo izpēti, nodrošināt līgumiskos drošības pasākumus, definēt audita un pārbaudes tiesības, uzturēt izbeigšanas tiesības un testēt izstāšanās stratēģijas kritiskām vai svarīgām funkcijām. Ja incidents ietver mākoņpakalpojumu sniedzēju, pārvaldīto pakalpojumu sniedzēju vai SaaS integrāciju, DORA pierādījumiem jāparāda piegādātāja lomas, žurnālu saglabāšanas pienākumi, incidentu atbalsts, atjaunošanas pienākumi un sadarbība ar uzraudzības iestādi.
Savlaicīgi integrējiet GDPR personas datu aizsardzības pārkāpumu pārskatatbildību
GDPR attiecas uz automatizētu personas datu apstrādi un neautomatizētu apstrādi, kas ir daļa no kartotēkas sistēmas. Tas var attiekties uz ES reģistrētām organizācijām un ārpus ES esošiem pārziņiem vai apstrādātājiem, kas piedāvā preces vai pakalpojumus personām Savienībā vai uzrauga viņu uzvedību.
Reaģēšanas uz incidentiem laikā GDPR analīzei jāsākas, tiklīdz personas dati varētu būt iesaistīti. Gaidīt tehnisko pamatcēloni ir par vēlu, ja 72 stundu termiņš jau rit.
Reaģēšanas komandai jāatbild uz šādiem jautājumiem:
- Kādas personas datu kategorijas var būt iesaistītas?
- Kuras sistēmas, lietojumprogrammas un apstrādes darbības ir ietekmētas?
- Vai organizācija darbojas kā pārzinis, apstrādātājs vai abi?
- Vai personas datiem tika piekļūts, tie tika mainīti, iznīcināti, zaudēti vai izpausti?
- Vai šifrēšanas, tokenizācijas vai pseidonimizācijas drošības pasākumi bija efektīvi?
- Kāds ir iespējamais risks fiziskām personām?
- Kurš un kad pieņēma paziņošanas lēmumu?
- Kāda komunikācija tika nosūtīta pārziņiem, apstrādātājiem, uzraudzības iestādēm vai datu subjektiem?
- Ja paziņošana netika veikta, kāds bija dokumentētais pamatojums?
GDPR Article 5 pārskatatbildība ir galvenais elements. Pārzinim jāspēj pierādīt atbilstību tādiem principiem kā likumība, godprātība, pārredzamība, nolūka ierobežošana, datu minimizēšana, glabāšanas ierobežošana, integritāte un konfidencialitāte. Tas nozīmē, ka pārkāpumu reģistrs, lēmumu žurnāls, tehniskie pierādījumi un komunikācijas vēsture ir daļa no privātuma kontroles sistēmas, nevis piezīmes pēc trūkumu novēršanas.
Saglabājiet pierādījumus, pirms atjaunošana tos iznīcina
Atkārtota reaģēšanas uz incidentiem kļūme ir atjaunošana, kas iznīcina pierādījumus. Sistēmas tiek restartētas. Ļaunprogrammatūra tiek dzēsta. Žurnāli tiek pārrakstīti. Konti tiek mainīti, pirms tiek uzņemti momentuzņēmumi. No pieejamības skatpunkta komanda var justies veiksmīga. No audita, regulatora, apdrošinātāja vai juridiskā skatpunkta organizācija var būt zaudējusi spēju pierādīt, kas notika.
Clarysec Evidence Collection and Forensics Policy nosaka:
Pierādījumu glabāšanas ķēdes žurnālam jāpavada visi fiziskie vai digitālie pierādījumi no iegūšanas brīža līdz arhivēšanai vai nodošanai, un tajā jādokumentē:
SME vajadzībām Evidence Collection and Forensics Policy-sme pierādījumu žurnāla prasību formulē tieši:
Katrs digitālo pierādījumu vienums jāreģistrē ar:
Zenith Blueprint, Controls in Action fāzes 23. solis, skaidro principu aiz ISO/IEC 27002:2022 5.28 kontroles pasākuma:
Kad notiek informācijas drošības incidents, viens no kritiskākajiem, taču bieži nepietiekami novērtētajiem reaģēšanas elementiem ir pierādījumi. Nevis žurnāli, nevis ekrānuzņēmumi, nevis brīvi apraksti, bet pienācīgi saglabāti, pierādījumu glabāšanas ķēdi ievērojoši, pret manipulācijām aizsargāti pierādījumi. 5.28 kontroles pasākums atzīst, ka pēc incidenta tas, ko varat pierādīt, ir tikpat svarīgi kā tas, kas faktiski notika.
Regulatoram sagatavotā pierādījumu pakotnē Anjas incidentam jāiekļauj:
| Pierādījumu vienums | Kāpēc tas ir svarīgi | Īpašnieks |
|---|---|---|
| Incidenta deklarēšanas ieraksts | Parāda uzzināšanas laiku un sāk termiņu analīzi | Incidenta vadītājs |
| Smaguma pakāpes klasifikācija | Atbalsta eskalācijas, prioritizācijas un ziņošanas lēmumus | Drošības vadītājs vai IT pakalpojumu sniedzējs |
| Aktīvu un datu uzskaites izraksts | Identificē ietekmētos pakalpojumus, sistēmas, datus un kritiskumu | IT īpašnieks un privātuma vadītājs |
| Žurnālu eksporti ar laikspiedoliem | Atbalsta atklāšanu, laika skalu un pamatcēloņa analīzi | SOC vai IT pakalpojumu sniedzējs |
| Mākoņvides audita pierakstu momentuzņēmums | Parāda API darbību, identitātes darbību un glabāšanas darbības | Mākoņplatformas administrators |
| Pierādījumu glabāšanas ķēdes žurnāls | Saglabā pierādījumu uzticamību un izsekojamību | Digitālās kriminālistikas vadītājs |
| Vadības paziņojums | Parāda eskalāciju un pārvaldības redzamību | Galvenais informācijas drošības vadītājs vai ģenerāldirektors |
| Regulatora lēmumu žurnāls | Parāda, kāpēc paziņošana bija vai nebija nepieciešama | Juridiskais dienests, DPO un galvenais informācijas drošības vadītājs |
| Piegādātāja komunikācijas ieraksts | Parāda trešās puses sadarbību un līgumisko reaģēšanu | Piegādātāju pārvaldnieks |
| Klientu komunikācijas ieraksts | Atbalsta NIS2, DORA, GDPR un līgumiskos pienākumus | Komunikācijas vadītājs |
| Gūto mācību ieraksts | Atbalsta ISO/IEC 27001:2022 nepārtrauktu uzlabošanu | IDPS vadītājs |
Žurnālu glabāšanai jābūt skaidri noteiktai. Clarysec Logging and Monitoring Policy-sme nosaka:
Ar incidentiem saistītie drošības žurnāli jāsaglabā vismaz 3 gadus no incidenta datuma
Zenith Blueprint, Controls in Action fāzes 19. solis, pievieno darbības patiesību:
Žurnālfiksēšana ir jebkuras drošas IT vides dzīvības līnija. Bez tās incidenti paliek neredzami, pārskatatbildība izzūd, un cēloņsakarības pazūd kā nebijušas.
Tāpēc reaģēšana uz incidentiem, žurnālfiksēšana, pierādījumu vākšana un ziņošana jāveido kā viena savienota kontroles sistēma.
Izpildiet pirmās 72 stundas kā pierādījumu sprintu
Praktisks 72 stundu pierādījumu sprints palīdz komandām reaģēt, nezaudējot auditējamību.
0. līdz 1. stunda: deklarēt, klasificēt un saglabāt
Atveriet incidenta pieteikumu, izmantojot Incident Response Policy. Piešķiriet incidenta vadītāju, tehnisko vadītāju, komunikācijas vadītāju, juridisko vai privātuma vadītāju, piegādātāju koordinatoru un pierādījumu īpašnieku.
Izmantojiet Incident Response Policy-sme vienas stundas klasifikācijas prasību kā kontrolpunktu arī lielākās organizācijās. Piemērojiet līmeņoto ietvaru uzņēmuma reaģēšanai un reģistrējiet nenoteiktību, ja fakti ir nepilnīgi.
Nekavējoties saglabājiet gaistošos pierādījumus: identitātes žurnālus, EDR brīdinājumus, mākoņvides audita pierakstus, priviliģētas piekļuves ierakstus, ietekmēto sistēmu žurnālus, rezerves kopiju statusu, konfigurācijas izmaiņas un attiecīgo pieteikumu vēsturi. Sāciet pierādījumu glabāšanas ķēdes žurnālu, izmantojot Evidence Collection and Forensics Policy.
Lēmumu rezultāti:
- Incidenta deklarēšanas laiks.
- Sākotnējā smaguma pakāpe.
- Iespējami ietekmētie pakalpojumi.
- Iespējami ietekmētie dati.
- Sākotnējais regulatīvais novērošanas saraksts, tostarp GDPR, NIS2, DORA un līgumiskie pienākumi.
- Pierādījumu trūkumi un piešķirtie īpašnieki.
1. līdz 24. stunda: ietekmes un agrīnā brīdinājuma analīze
Izveidojiet pirmo ietekmes skatījumu. Nosakiet, vai notikums ietekmēja pakalpojumu sniegšanu, izraisīja vai varēja izraisīt darbības traucējumus vai finansiālus zaudējumus, ietekmēja citas personas vai radīja materiālu vai nemateriālu kaitējumu. Tas atbalsta NIS2 būtiska incidenta analīzi.
Finanšu vienībām klasificējiet pret DORA kritērijiem: ietekmētie klienti, darījumi, reputācija, dīkstāve, ģeogrāfiskais izplatījums, datu zudums, kritiskums un ekonomiskā ietekme.
GDPR vajadzībām nosakiet, vai bija iesaistīti personas dati un vai pastāv iespējamais risks fiziskām personām.
Lēmumu rezultāti:
- NIS2 agrīnā brīdinājuma lēmums.
- DORA būtiska incidenta novērošanas statuss.
- GDPR personas datu aizsardzības pārkāpuma izvērtēšanas statuss.
- Klienta, klienta-pasūtītāja vai pārziņa paziņošanas novērošana.
- Vadības struktūras atjauninājums.
- Piegādātāju pierādījumu pieprasījumi.
24. līdz 72. stunda: sagatavot regulatora līmeņa paziņošanas pierādījumus
Ja piemērojama NIS2, sagatavojiet 72 stundu incidenta paziņojuma atjauninājumu ar sākotnējo smaguma pakāpi, ietekmi un kompromitācijas indikatoriem, ja tie ir pieejami. Ja nepieciešama GDPR paziņošana, nodrošiniet, ka uzraudzības iestādes pakotne atspoguļo zināmo, vēl nezināmo, iespējamās sekas un veiktos vai ierosinātos pasākumus. Ja piemērojama DORA, sagatavojiet nepieciešamo sākotnējo vai starpposma ziņojumu, izmantojot kompetentās iestādes procesu.
Lēmumu rezultāti:
- Atjaunināta incidenta laika skala.
- Pamatcēloņa hipotēze.
- Ierobežošanas un izskaušanas darbības.
- Pakalpojuma atjaunošanas pierādījumi.
- Regulatora paziņojuma pakotne.
- Klienta vai klienta-pasūtītāja komunikācija.
- Atjaunināta pierādījumu uzskaite.
Šis sprints nav dokumentēšana dokumentēšanas dēļ. Tas neļauj reaģēšanas komandai upurēt pierādījumus, kamēr tiek atjaunotas operācijas.
Starpietvaru kartēšana: viena darbplūsma, daudzi pierādījumu patērētāji
Nobriedusi reaģēšanas uz incidentiem programma izveido pierādījumus vienreiz un atkārtoti izmanto tos dažādos ietvaros.
| Incidenta darbplūsmas elements | CSF 2.0 | ISO/IEC 27001:2022 un A pielikums | NIS2 | DORA | GDPR |
|---|---|---|---|---|---|
| Pārvaldība un īpašumtiesības | GV.RR, GV.OV, GV.PO | 5.1 līdz 5.3 punkti, A.5.24 | Article 20 vadības pārraudzība | Articles 5 un 6 vadības struktūras atbildība | Article 5 pārskatatbildība |
| Piemērošanas joma un pienākumi | GV.OC | 4.1 līdz 4.4 punkti | Būtiskas un svarīgas vienības piemērošanas joma | Finanšu vienības piemērošanas joma un samērīgums | Materiālā un teritoriālā piemērošanas joma |
| Riska un smaguma kritēriji | GV.RM, ID.RA, RS.MA-03 | 6.1.1 līdz 6.1.3 punkti, A.5.25 | Būtiska incidenta kritēriji | Article 18 klasifikācija | Risks fiziskām personām |
| Atklāšana un uzraudzība | DE.CM, DE.AE | A.8.15 žurnālfiksēšana, A.8.16 uzraudzība, A.5.25 | Incidentu apstrāde un efektivitātes izvērtēšana | Agrīnā brīdinājuma indikatori un incidentu ieraksti | Pārkāpuma atklāšana un izvērtēšana |
| Reaģēšanas izpilde | RS.MA, RS.AN, RS.MI | A.5.26, A.5.28 | Article 23 ziņošanas ceļš | Articles 17 un 19 incidentu process un ziņošana | Article 33 un Article 34 izvērtēšana |
| Atjaunošana | RC.RP, RC.CO | A.5.29 IKT gatavība darbības nepārtrauktībai, A.8.13 informācijas rezerves kopēšana | Pakalpojuma ietekmes mazināšana | Drošu operāciju atjaunošana | Mazināšana un komunikācija |
| Gūtās mācības | GV.OV, RS.IM | A.5.27 un Clause 10 uzlabošana | Korektīvā darbība bez nepamatotas kavēšanās | Pamatcēloņa slēgšana un korektīvās darbības | Pārskatatbildības ieraksti |
ISO un NIST reaģēšanas kartējums auditoriem ir īpaši noderīgs.
| ISO/IEC 27002:2022 darbība | NIST CSF 2.0 apakškategorija |
|---|---|
| Reaģēšanas uz incidentiem plāna izpilde kopā ar trešajām pusēm | RS.MA-01 |
| Incidentu ziņojumu sākotnējā izvērtēšana un validācija | RS.MA-02 |
| Kategorizēšana un prioritizēšana | RS.MA-03 |
| Eskalācija pēc vajadzības | RS.MA-04 |
| Analīze un pamatcēloņa noteikšana | RS.AN-03 |
| Izmeklēšanas darbību reģistrēšana un izcelsmes saglabāšana | RS.AN-06 |
| Incidenta datu vākšana un integritātes saglabāšana | RS.AN-07 |
| Incidenta apmēra novērtēšana un validēšana | RS.AN-08 |
| Iekšējo un ārējo ieinteresēto pušu informēšana | RS.CO-02 |
| Ierobežošana un izskaušana | RS.MI-01 un RS.MI-02 |
| Atjaunošanas plāna izpilde un rezerves kopiju integritātes pārbaude | RC.RP-01 un RC.RP-03 |
Jāiekļauj arī piegādes ķēdes pārvaldība. NIST CSF 2.0 GV.SC risina piegādes ķēdes riska procesus, piegādātāju lomas, kritiskuma prioritizēšanu, līgumiskās prasības, sākotnējo izpēti, pastāvīgu uzraudzību, piegādātāju iekļaušanu incidentu plānošanā un attiecību izbeigšanas darbības. Tas tieši saskan ar NIS2 piegādes ķēdes drošību, DORA IKT trešo pušu risku pārvaldību un ISO/IEC 27001:2022 piegādātāju kontroles pasākumiem.
Kā dažādi auditori pārbaudīs vienu un to pašu incidentu
ISO/IEC 27001:2022 auditors sāks ar IDPS. Viņš jautās, vai incidentu pārvaldība ir iekļauta piemērošanas jomā, vai ieinteresēto pušu pienākumi ir dokumentēti, vai incidentu riski ir izvērtēti, vai A.5.24 līdz A.5.28 ir iekļauti Piemērojamības paziņojumā, vai process tika izpildīts, kā plānots, un vai incidents radīja gūtās mācības, korektīvās darbības un nepārtrauktu uzlabošanu.
Uz NIST orientēts izvērtētājs koncentrēsies uz CSF 2.0 rezultātiem. Viņš pārbaudīs pārvaldību, aktīvu redzamību, uzraudzību, incidenta deklarēšanu, sākotnējo izvērtēšanu, eskalāciju, pierādījumu integritāti, ieinteresēto pušu komunikāciju, ierobežošanu, izskaušanu, atjaunošanu un profilu atjauninājumus.
NIS2 uzraudzības pārbaude koncentrēsies uz vadības pārskatatbildību, Article 21 riska pārvaldības pasākumiem un Article 23 ziņošanu. Centrāli būs pierādījumi par 24 stundu agrīnā brīdinājuma lēmumu, 72 stundu paziņojuma saturu, starpposma ziņojumiem un galīgo ziņojumu. Pārskatītājs var pārbaudīt arī darbības nepārtrauktību, piegādes ķēdes drošību, piekļuves kontroli, apmācību, kriptogrāfiju un efektivitātes izvērtēšanu.
DORA regulators koncentrēsies uz darbības noturību. Tas sagaidīs incidentu klasifikācijas kritērijus, ar IKT saistītu incidentu un būtisku kiberdraudu ierakstus, agrīnā brīdinājuma indikatorus, eskalāciju augstākajai vadībai, vadības struktūras redzamību, klientu paziņošanu, ja tiek ietekmētas finansiālās intereses, pamatcēloņa slēgšanu, drošu operāciju atjaunošanu un piegādātāju pierādījumus.
GDPR uzraudzības iestāde koncentrēsies uz personas datu aizsardzības pārkāpuma pārskatatbildību. Tā jautās, kad organizācija uzzināja par incidentu, kādi personas dati tika ietekmēti, vai organizācija bija pārzinis vai apstrādātājs, kāds risks pastāvēja fiziskām personām, kādi pasākumi tika veikti, kāpēc paziņošana tika vai netika veikta un vai iekšējais pārkāpumu reģistrs ir pilnīgs.
COBIT vai ISACA stila auditors pārbaudīs pārvaldības mērķus, vadības prakses, īpašumtiesības, rādītājus un apliecinājuma pierādījumus. Viņam būs svarīgi, vai reaģēšana uz incidentiem tiek pārvaldīta, mērīta, uzlabota un saskaņota ar uzņēmuma mērķiem.
Tas pats incidents var apmierināt visas šīs pārbaudes, ja darbplūsma ir veidota ap kopīgiem pierādījumiem, nevis izolētām atbilstības mapēm.
Pārbaudiet kartējumu ar termiņu vadītām galda mācībām
Ātrākais veids, kā noskaidrot, vai kartējums darbojas, ir galda mācības, kas veidotas ap ziņošanas termiņiem.
Izmantojiet šādu scenāriju: tiek kompromitēts priviliģēts inženiera konts. Uzbrucējs piekļūst ražošanas datubāzei, eksportē nezināmu ierakstu apjomu, maina konfigurācijas iestatījumu, kas izraisa daļēju dīkstāvi ES klientiem, un izmanto API marķieri, kas izsniegts caur trešās puses integrāciju.
Veiciet mācības četrās kārtās.
Pirmā kārta — atklāšana un deklarēšana. Vai komanda var identificēt brīdinājuma avotu, deklarēt incidentu, klasificēt smaguma pakāpi vienas stundas laikā, saglabāt žurnālus un piešķirt lomas?
Otrā kārta — ietekme. Vai komanda var identificēt ietekmētos pakalpojumus, ietekmētos datus, ietekmētos klientus, piegādātāja iesaisti, dīkstāvi, ģeogrāfisko izplatījumu un to, vai incidents ietekmē finansiālās intereses vai personas datus?
Trešā kārta — ziņošana. Vai tiek aktivizēts NIS2 agrīnais brīdinājums, NIS2 72 stundu paziņojums, DORA ziņošana, GDPR paziņošana un līgumiskie klientu paziņojumi? Vai komanda var dokumentēt gan paziņošanas, gan nepaziņošanas lēmumus?
Ceturtā kārta — atjaunošana un slēgšana. Vai ierobežošana, izskaušana, atjaunošana, rezerves kopiju validācija, komunikācija, gūtās mācības un korektīvās darbības ir dokumentētas?
Rezultāts nedrīkst būt slaidu komplekts. Tam jābūt pierādījumu pakotnei: aizpildīts incidenta pieteikums, laika skala, lēmumu žurnāls, komunikācijas žurnāls, saglabāto pierādījumu saraksts, regulatora lēmumu matrica, piegādātāja komunikācijas ieraksts, atjaunošanas validācijas ieraksts un korektīvo darbību plāns.
Mācības nav pabeigtas, kad cilvēki paskaidro, ko viņi darītu. Tās ir pabeigtas, kad viņi sagatavo ierakstus, ko pieprasītu auditors.
Izplatītākie kļūmju modeļi, kas jānovērš pirms nākamā brīdinājuma
Pirmais kļūmju modelis ir nedefinēts uzzināšanas laiks. Ja neviens nereģistrē, kad organizācija uzzināja par incidentu, NIS2, DORA un GDPR termiņu analīze kļūst riskanta.
Otrais ir smaguma pakāpe bez kritērijiem. Tādi marķējumi kā vidējs vai augsts ir vāji, ja tie nav sasaistīti ar pakalpojuma ietekmi, datu ietekmi, finansiālo ietekmi, klientu ietekmi vai regulatīvajiem sliekšņiem.
Trešais ir pārāk vēla privātuma iesaiste. GDPR izvērtēšana jāsāk, kad personas dati varētu būt iesaistīti, nevis pēc pamatcēloņa noteikšanas.
Ceturtais ir piegādātāju neskaidrība. Ja iesaistīts mākoņpakalpojumu sniedzējs, pārvaldīto pakalpojumu sniedzējs vai SaaS integrācija, līgumiem un rokasgrāmatām jādefinē, kurš saglabā žurnālus, kurš komunicē, kurš atbalsta digitālo kriminālistiku un kurš palīdz ar regulatora pieprasījumiem.
Piektais ir pierādījumu iznīcināšana atjaunošanas laikā. Restartēšana, dzēšana un konfigurācijas izmaiņas var būt nepieciešamas, taču, kad vien iespējams, tās jāsaskaņo ar pierādījumu saglabāšanu.
Sestais ir gūtās mācības bez riska apstrādes. ISO/IEC 27001:2022 sagaida uzlabojumus, kur tie ir nepieciešami. Gūto mācību sanāksme bez kontroles pasākuma izmaiņas, īpašnieka, noteiktā termiņa vai riska atkārtotas izvērtēšanas ir vājš pierādījums.
Pārvērtiet reaģēšanu uz incidentiem par starpatbilstības pierādījumu sistēmu
Gatavošanās NIST SP 800-61 reaģēšanas uz incidentiem gaidām un 2026. gada auditiem nedrīkst sākties ar vēl vienu atsevišķu rokasgrāmatu. Tai jāsākas ar lēmumu kartēšanu.
Clarysec var palīdzēt jūsu komandai:
- Izveidot NIST CSF 2.0 reaģēšanas uz incidentiem pašreizējo profilu un mērķa profilu.
- Saskaņot reaģēšanu uz incidentiem ar ISO/IEC 27001:2022 punktiem, riska apstrādi un A pielikuma kontroles pasākumiem.
- Iestrādāt NIS2 24 stundu, 72 stundu un viena mēneša pierādījumu prasības darbplūsmās.
- Kartēt DORA incidentu klasifikāciju, vadības struktūras ziņošanu, klientu paziņošanu un IKT piegādātāju pierādījumus.
- Integrēt GDPR personas datu aizsardzības pārkāpumu analīzi un pārskatatbildības ierakstus.
- Ieviest Clarysec Incident Response Policy, Incident Response Policy-sme, Evidence Collection and Forensics Policy, Evidence Collection and Forensics Policy-sme, Logging and Monitoring Policy-sme, Zenith Blueprint un Zenith Controls galda mācībās pārbaudītā darbības modelī.
- gada jautājums nav, vai jūsu komanda spēj ierobežot uzbrukumu. Jautājums ir, vai jūsu komanda spēj klasificēt, eskalēt, ziņot, atjaunot un pierādīt reaģēšanu NIST, ISO/IEC 27001:2022, NIS2, DORA un GDPR kontekstā.
Clarysec 30 soļu ieviešanas modelis un starpatbilstības rīkkopa ir veidota, lai tas būtu iespējams pirms nākamā otrdienas rīta brīdinājuma. Lejupielādējiet attiecīgās Clarysec politikas, veiciet termiņu vadītas galda mācības un pieprasiet Clarysec izvērtējumu, lai pārvērstu reaģēšanas uz incidentiem plānu par auditam gatavu pierādījumu sistēmu.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


