Incidentų valdymo planas: kodėl jis svarbus

Kibernetinė ataka įvyko. Darbuotojas paspaudė kenksmingą nuorodą. Serveris nereaguoja. Arba banko paskyroje rodoma neįprasta veikla. Ir tada kyla klausimas, į kurį atsakymo niekas nežino: ką dabar daryti? Dauguma įmonių šioje situacijoje improvizuoja. Skambina IT specialistui. Laukia. Bando suprasti, kas įvyko. Praranda brangias valandas. Kartais – ir duomenis, reputaciją, pinigus.

Incidentų valdymo planas – tai dokumentas, kuris panaikina improvizaciją. Jame parengtas detalus planas, kas ką ir kada turi daryti  – dar prieš tai, kai ataka įvyksta.

 

Kodėl tai ne tik gera praktika, bet ir teisinis įpareigojimas

Pagal TIS2 direktyvą, kuri Lietuvoje įsigaliojo 2024 m. spalio 18 d., reguliuojamų sektorių organizacijos privalo turėti incidentų valdymo procedūras. Tai – ne rekomendacija, o organizacinis reikalavimas.

Konkrečiai tai reiškia:

• Per 24 valandas nuo reikšmingo incidento aptikimo reikia pranešti NKSC: https://www.nksc.lt/pranesti.html
• Per 72 valandas – pateikti detalesnę informaciją.
• Po mėnesio – galutinę incidento ataskaitą.

Jei neturite plano, šių terminų laikytis praktiškai neįmanoma. Chaotiška situacija, neaiškūs procesai ir ilgos paieškos, kas atsakingas – terminas jau praleistas. O tai – potencialios baudos ir asmeninė vadovybės atsakomybė.

 

Kas yra incidentų valdymo planas ir kas jame turi būti

Incidentų valdymo planas (IVP) – tai dokumentas, nustatantis, kaip organizacija aptinka, reaguoja, suvaldo ir dokumentuoja kibernetinius incidentus.

Jis nėra šimtų puslapių techninė specifikacija. Geras IVP gali tilpti į 5–10 puslapius ir būti suprantamas ne tik IT specialistams.

Esmiai punktai:

1. Incidentų klasifikacija.
   Ne visi incidentai vienodi. Prarastas slaptažodis ir užšifruoti įmonės duomenys reikalauja skirtingų atsakų. Plane turi būti aiškiai apibrėžti incidentų tipai ir rimtumo lygiai – žemas, vidutinis, kritinis – su konkrečiais pavyzdžiais.
   
   
2. Atsakomybių matrica.
   Kokios incidento atveju atsakomybės konkrečių žmonių bei skyrių. IT specialistas izoliuoja sistemą. Vadovas informuoja valdybą. Teisininkas įvertina pranešimo prievolę. HR koordinuoja darbuotojų komunikaciją. Kiekvienas turi žinoti savo vaidmenį.
   
   
3. Pranešimo grandinė ir kontaktai.
   Sąrašas, kas turi būti informuotas ir kokia tvarka: vidaus komanda, NKSC (tel. 1843), Valstybinė duomenų apsaugos inspekcija (jei paveikti asmens duomenys), bankas, partneriai, klientai. Su aiškiais kontaktais ir terminais.
   
   
4. Techniniai reagavimo žingsniai.
   Kaip izoliuoti paveiktą sistemą? Kaip patikrinti, ar ataka plinta? Kur yra atsarginės kopijos ir kaip jas atstatyti? Šie žingsniai turi būti aprašyti pakankamai detaliai, kad juos galėtų atlikti ir IT komandos narys, kuris nedalyvavo incidente.
   
   
5. Komunikacijos protokolas.
   Ką sakyti klientams? Kada ir kaip informuoti partnerius? Kas kalba su žiniasklaida jei to reikia? Panikuojanti ar prieštaringa komunikacija po incidento gali padaryti žalos tiek pat, kiek pati ataka.
   
   
6. Dokumentavimas ir mokymasis.
   Kaip fiksuojamas incidentas? Kokia forma surašoma ataskaita? Kaip po incidento peržiūrimi procesai, kad panaši situacija nepasikartotų?

 

Dažniausios klaidos, kuriant incidentų valdymo planą

1. Planas parašytas, bet niekas nežino, kur jis yra.
   Dokumentas seife arba IT vadovo stalčiuje – ne planas. Jis turi būti lengvai pasiekiamas kritiniu momentu.
   
   
2. Atsakingas „IT specialistas”, kuris atostogauja.
   Planas turi numatyti pakaitinį atsakingą asmenį. Incidentai nepasitaiko patogiu laiku.
   
   
3. Nėra ryšio su teisiniais aspektais.
   Daugelis organizacijų mano, kad incidentų valdymas – tik IT klausimas. Tačiau pranešimo prievolės, klientų informavimas ir atsakomybė – tai teisiniai klausimai, kurie turi būti integruoti į planą.
   
   
4. Planas niekada netestuotas.
   Planas, kuris egzistuoja tik popieriuje, bet niekada nebuvo testuotas pagal tam tikrą scenarijų – tai tikrovės iliuzija. Bent kartą per metus reikia peržiūrėti ir patikrinti, ar jis vis dar aktualus ir veikiantis.
   
   
5. Komunikacija numatyta „kai bus aišku”.
   Incidento metu aiškumo niekada nėra pakankamai. Komunikacijos šablonai ir sprendimų grandinė turi būti numatyti iš anksto.
   
   

Kaip žinoti, ar jūsų planas yra pakankamai geras?

Keletas praktinių klausimų:

• Ar visi atsakingi asmenys žino savo vaidmenį ir turi reikiamus kontaktus?
• Ar esate tikri, kad per 24 valandas galėtumėte informuoti NKSC apie reikšmingą incidentą?
• Ar žinote, kur yra jūsų atsarginės duomenų kopijos ir kiek laiko prireiktų jas atstatyti?
• Ar yra paruošti komunikacijos šablonai klientams ir partneriams?
• Ar planas buvo peržiūrėtas per paskutinius 12 mėnesių?

Jei bent į vieną atsakymas – „nežinau” arba „ne” – tai ženklas, kad planas nėra realiai veikiantis ir jį reikia koreguoti.

 

Išvada

Incidentų valdymo planas nėra dokumentas, skirtas auditoriams. Tai – jūsų organizacijos instrukcija, kaip išgyventi krizę, neprarandant kontrolės, laiko ir reputacijos. TIS2 reikalavimai padarė jį privalomu daugeliui organizacijų. Tačiau geriausia priežastis jį turėti – ne bauda. O tai, kad incidentas gali įvykti bet kada, ir tada kiekviena minutė bus neįkainuojama.

Jei nesate tikri, nuo ko pradėti, arba norite įsivertinti, ar jūsų esami procesai atitinka TIS2 organizacinius reikalavimus – kreipkitės dėl nemokamos konsultacijos: cyberspektras.lt/kontaktai/