Kibernetinis incidentas įvyko. Ką daryti per pirmą valandą, parą ir mėnesį

Praktinis veiksmų planas įmonėms. Dauguma incidentų valdymo vadovų parašyti taip, kad jų neįmanoma naudoti tada, kai jų prireikia.

Kai realiai skambina telefonas trečią valandą nakties ir kažkas sako „mūsų sistemoje kažkas ne taip", niekas neskaito 80 puslapių metodikos.

Šis tekstas skirtas jums, jei turite interneto svetainę, e-parduotuvę, platformą arba vidines sistemas, kuriose yra klientų ar darbuotojų duomenys, ir pastebėjote kažką įtartino arba jau turite patvirtintą įsilaužimą.

Prieš viską yra vienas sprendimas, kurį reikia priimti iškart

Yra tik du keliai, ir jie nesuderinami:

• Kelias A – greitas atkūrimas. Išvalote, atnaujinate, atkuriate iš backup'o (kopijos), grįžtate į darbą per kelias valandas. Kaina: niekada nesužinosite, kaip ir kodėl tai įvyko, ar užpuolikas vis dar viduje ir kokie duomenys realiai išėjo.
• Kelias B – įrodymų išsaugojimas. Užfiksuojate būseną, tada tvarkotės. Kaina: kelios papildomos valandos prastovos.

Praktinis kompromisas: snapshot dabar, tvarkymasis po 30 minučių. Virtualios mašinos snapshot arba disko kopija užtrunka mažiau laiko, nei diskusija apie tai, ar jos reikia.

Pirmos 60 minučių: stabilizavimas ir fiksavimas

Tikslas šioje fazėje nėra sutvarkyti. Tikslas yra nepadaryti blogiau ir užfiksuoti, kas vyksta.

Veiksmai

1. Užrašykite tikslų laiką, kas ir kaip pastebėjo incidentą.
2. Atidarykite incidento žurnalą – dokumentą, kuriame fiksuojamas kiekvienas veiksmas: laikas, kas atliko, ką darė, kodėl. Šis žurnalas vėliau bus ataskaitos pagrindas ir įrodymas, kad reagavote tinkamai.
3. Paskirkite vieną koordinatorių – vieną žmogų, kuris priima sprendimus ir kuriam visi atsiskaito.
4. Pereikite į atskirą komunikacijos kanalą – Signal, asmeniniai telefonai ar kitų programėlių grupės. Jei užpuolikas turi prieigą prie el. pašto arba Teams/Slack, jis skaito jūsų reagavimo planą realiu laiku.
5. Informuokite vadovą, DPO (jei yra) ir IT vadovą (jei dar nežino).
6. Patikrinkite, ar tai apskritai incidentas – klaidingi pranešimai dažni. Bet jei abejojate, laikykite incidentu.
7. Padarykite pirminį snapshot'ą (kopiją) arba bent jau sustabdykite automatinius procesus, kurie perrašo logus.

Pirminis apimties vertinimas – mini auditavimas

• Kokios sistemos paveiktos?
• Ar jose yra asmens duomenų? Kokių kategorijų? Kiek įrašų?
• Ar yra požymių, kad duomenys buvo išeksportuoti, ar tik pasiekti?
• Ar užpuolikas vis dar viduje?

Ko nedaryti

Neperkraukite ir neišjunkite serverių, netrinkite failų, neatkurkite iš backup'o. Neatnaujinkite platformos ar plugin'ų, nesiųskite pranešimų klientams, nekomentuokite viešai.

Kiekvienas iš šių veiksmų yra negrįžtamas ir kiekvienas naikina informaciją, kurios vėliau prireiks.

1–4 valandos: izoliavimas ir pirminis vertinimas

Izoliavimas

• Atjunkite paveiktą sistemą nuo viešos prieigos arba apribokite IP adresais, bet palikite ją įjungtą.
• Alternatyva viešam puslapiui: maintenance režimas plius prieigos apribojimas IP lygiu.
• Atšaukite visas aktyvias sesijas.
• Pakeiskite administratorių slaptažodžius, API raktus, SSH raktus, webhook secrets.
• Patikrinkite, ar tie patys credentials nenaudojami kitose sistemose.

Paraleliai

• Susisiekite su hostingo tiekėju ir paprašykite išsaugoti logus bei neatlikti jokių automatinių valymų.
• Informuokite draudiką, jei turite kibernetinio draudimo polisą.
• Susisiekite su teisininku arba DPO dėl pranešimo institucijoms.

4–24 valandos: įrodymų surinkimas

Ši fazė yra pagrindinė. Jei ji atlikta gerai – tyrimas įmanomas. Jei ne – toliau eina spėlionės.

Techniniai įrodymai

• Atminties dump'as iš veikiančios sistemos – darykite tai pirmiau nei diską.
• Disko kopija arba virtualios mašinos snapshot. Apskaičiuokite SHA-256 hash.
• Eksportuokite visus logus į atskirą saugią vietą:
  • web serverio access ir error logai;
  • aplikacijos ir PHP-FPM logai;
  • duomenų bazės logai;
  • CMS / platformos audito logai;
  • ugniasienės, VPN ir tapatybės tiekėjo (IdP) logai.
• Išsaugokite backup'us iš kelių skirtingų datų – jie reikalingi palyginimui.

Sprendimas dėl pranešimo

• Nuspręskite, ar tai yra asmens duomenų saugumo pažeidimas pagal BDAR.
• Jei taip – pradėkite ruošti pranešimą VDAI. Laikrodis tiksi nuo sužinojimo momento, ne nuo tyrimo pabaigos.
• Jei patenkate į NIS2 apimtį – ankstyvas įspėjimas NKSC turi būti pateiktas per 24 valandas.

2–7 dienos: tyrimas ir pašalinimas

• Nustatomas pradinis įsilaužimo vektorius ir patvirtinamas įrodymais.
• Pašalinamos visos užnugario durys – ne tik tos, kurias radote pirmiausia.
• Uždaroma spraga ir patikrinama, ar ji uždaryta realiai.
• Atkuriama veikla su padidintu stebėjimu.
• Tikslinamas apimties vertinimas – dažnai pirminis skaičius keičiasi.

Kada kviesti tyrėją

Tai klausimas, į kurį dauguma įmonių atsako per vėlai.

Kvieskite nedelsiant, jei

• paliesti asmens duomenys ir reikės pranešti VDAI;
• yra požymių, kad duomenys išeksportuoti;
• ransomware arba šifravimas;
• įsilaužimas į vidines sistemas, ne tik į viešą svetainę;
• nežinote, kaip užpuolikas pateko;
• nežinote, ar jis vis dar viduje;
• incidentas gali baigtis teisminiu ginču arba draudimo išmoka;
• jūsų komanda neturi forensikos patirties.

Galite tvarkytis patys, jei

• defacement be prieigos prie duomenų bazės;
• aiškiai identifikuotas ir izoliuotas incidentas be asmens duomenų;
• turite vidinę SOC / IR komandą.

Ką paruošti prieš tyrėjui atvykstant

• Sistemos architektūros ir tinklo schema.
• Duomenų inventorius: kur kas saugoma, kokios kategorijos, kiek įrašų.
• Naudotojų ir teisių sąrašas.
• Paskutinių pakeitimų istorija: deploy'ai, atnaujinimai, konfigūracijos.
• Logai nuo bent 90 dienų prieš incidentą.
• Švari platformos versija palyginimui.
• Backup'ai iš kelių datų.
• Read-only prieiga prie hostingo ir log sistemos.
• Kontaktas hostingo pusėje, kuris atsako tą pačią dieną.
• Rašytinė autorizacija tirti ir BDAR 28 str. duomenų tvarkymo sutartis.

Daugiau apie tai, kaip atrodo pats tyrimas – skaitmeninės kriminalistikos (forensikos) paslaugos.

Ką padaryti šiandien, kol nieko neįvyko

Beveik visa, kas lemia tyrimo sėkmę, sprendžiama iš anksto:

1. Logų retencija bent 90 dienų, rekomenduotina 6–12 mėn.
2. Logai siunčiami į atskirą sistemą, kurios web serveris negali perrašyti.
3. Laikas sinchronizuotas per NTP visose sistemose.
4. Bent viena immutable atsarginė kopija plius reguliarus atkūrimo testas.
5. MFA visiems administratoriams, be išimčių.
6. Turto ir duomenų inventorius, atnaujinamas kas ketvirtį.
7. Vieno puslapio incidento planas su kontaktais, prieinamas ir tada, kai sistemos neveikia.
8. Sutartyje su hostingu numatyta pareiga pateikti logus ir leisti snapshot'us.
9. Retainer su forensikos tiekėju – derėtis dėl sutarties incidento metu reiškia prarastas dienas.
10. Monitoringas bent bazinėms anomalijoms: naujas admin, failo pakeitimas web šakninėje, neįprastas duomenų eksportas.
11. Kartą per metus – stalo pratybos (tabletop): 90 minučių, be technikos, tiesiog pereinate scenarijų.

Pabaigai

Vidutinis laikas nuo įsilaužimo iki aptikimo skaičiuojamas savaitėmis. Tai reiškia, kad kai jūs sužinote apie incidentą, užpuolikas jūsų sistemoje jau seniai.

Ir tai reiškia, kad klausimas nėra „ar reikia pasiruošti". Klausimas – ar pasiruošimas įvyks prieš incidentą, ar po jo.

Jei norite pasiruošti iš anksto – incidentų valdymo (incident response) mokymai, skaitmeninė kriminalistika ir visos paslaugos. Susiję straipsniai: kas laužia įmonių saugumą 2026-ais ir ko Revolut duomenų nutekėjimas išmokė mus ir sukčius.