Ransomware koji zaustavi proizvodnju, kompromitirani korisnički račun dobavljača ili pogrešno poslan dokument s osobnim podacima ne ostavljaju prostor za nejasne odluke. U takvim trenucima vodič za upravljanje cyber incidentima nije dokument koji se otvara radi formalnosti, nego operativni okvir koji određuje tko odlučuje, što se prvo izolira, kako se čuvaju dokazi i kada se aktiviraju obveze prijavljivanja.
Za organizacije obuhvaćene Zakonom o kibernetičkoj sigurnosti, Uredbom o kibernetičkoj sigurnosti i NIS2 zahtjevima, incident nije samo tehnički problem IT odjela. Može biti poslovni prekid, regulatorni događaj, ugovorni rizik i pitanje odgovornosti uprave. Kvaliteta odgovora ne mjeri se količinom dokumentacije nakon događaja, već sposobnošću da se tijekom prvih sati djeluje kontrolirano i dokazivo.
Što upravljanje incidentom mora riješiti
Plan reagiranja često zapne na jednoj od dvije krajnosti. Ili je preopćen – s uputom da se incident “odmah prijavi IT-u” – ili je toliko detaljan da ga nitko ne može koristiti pod pritiskom. Upotrebljiv proces mora povezati tehnički odgovor, poslovni kontinuitet, pravne obveze i komunikaciju prema upravi.
Prvo je potrebno jasno odrediti što organizacija smatra sigurnosnim događajem, a što incidentom. Veći broj neuspjelih prijava, neuobičajeno mrežno ponašanje ili upozorenje EDR alata mogu biti događaji koji zahtijevaju provjeru. Incident nastaje kada postoji potvrđen ili opravdano sumnjiv utjecaj na povjerljivost, cjelovitost ili dostupnost sustava, podataka i usluga.
Ta razlika nije semantička. Ako se svaki alarm proglasi incidentom, tim će se brzo preopteretiti i izgubit će fokus. Ako se ozbiljna odstupanja predugo tretiraju kao beznačajna upozorenja, organizacija kasni s ograničavanjem štete i procjenom regulatornih obveza. Zato kriteriji klasifikacije moraju biti unaprijed dogovoreni, dokumentirani i razumljivi osobama koje dežuraju.
Vodič za upravljanje cyber incidentima počinje ulogama
U prvim satima incidenta najveći rizik često nije nedostatak alata, nego paralelno i neusuglašeno odlučivanje. Tehnički tim izolira sustav, poslovna jedinica pokušava ga vratiti u rad, komunikacije pripremaju izjavu, a uprava saznaje za događaj iz neformalnog kanala. Takav pristup može dodatno ugroziti dokaze, produžiti prekid i stvoriti pogrešne informacije prema nadležnim tijelima ili korisnicima.
Svaki plan treba imenovati vlasnika incidenta s jasnom ovlasti koordinacije. To ne mora uvijek biti CISO. U manjim organizacijama tu ulogu može preuzeti voditelj IT-a uz podršku uprave i vanjskih stručnjaka. Ključno je da postoji jedna osoba koja vodi evidenciju odluka, određuje ritam sastanaka i osigurava da tehničke, pravne i poslovne aktivnosti imaju zajednički prioritet.
Uz voditelja incidenta, potrebno je unaprijed odrediti tehnički tim za istragu i oporavak, osobu odgovornu za usklađenost i regulatornu komunikaciju, predstavnika pravne funkcije, vlasnika poslovnog procesa te osobu ovlaštenu za vanjsku komunikaciju. U reguliranim sustavima uprava mora znati kada se uključuje i koje odluke zadržava, primjerice kod prihvaćanja prekida usluge, aktiviranja krizne komunikacije ili angažiranja vanjske forenzike.
Kontaktni podaci, zamjene i kanali komunikacije moraju biti dostupni i izvan primarne mreže. Nema koristi od popisa kontakata pohranjenog u sustavu za suradnju koji je nedostupan upravo zbog incidenta. Praktično rješenje uključuje zaštićen alternativni komunikacijski kanal, ažuriran popis dežurnih osoba i testiranu proceduru pozivanja.
Prvih 60 minuta: potvrditi, ograničiti, evidentirati
Prvi cilj nije odmah pronaći uzrok svega što se dogodilo. Prioritet je potvrditi osnovne činjenice, spriječiti širenje i sačuvati tragove potrebne za daljnju analizu. Brisanje zapisa, ponovno pokretanje poslužitelja ili nekontrolirana promjena konfiguracije mogu otežati forenziku i umanjiti sposobnost organizacije da dokaže što se dogodilo.
Tim treba evidentirati vrijeme otkrivanja, izvor dojave, zahvaćene sustave, prve provedene radnje i osobu koja ih je odobrila. Istodobno se prikupljaju dostupni zapisi, upozorenja sigurnosnih alata, snimke konfiguracije, informacije o korisničkim računima i mrežnim vezama. Evidencija ne mora biti administrativno opterećenje – mora biti dovoljno jasna da kasnije pokaže slijed događaja i opravdanost odluka.
Ograničavanje incidenta ovisi o njegovoj prirodi. Kod sumnje na kompromitirani račun to može značiti blokadu računa, opoziv aktivnih sesija i provjeru privilegija. Kod širenja zlonamjernog koda može biti nužna segmentacija dijela mreže ili izolacija uređaja. Potpuno gašenje sustava ponekad je opravdano, ali nije automatski najbolji potez: može prekinuti kritičnu uslugu, ukloniti volatilne dokaze ili poremetiti sustave koji nisu zahvaćeni.
Odluke o izolaciji trebaju se donositi prema unaprijed određenim razinama utjecaja. Za zdravstvenu ustanovu dostupnost određenog sustava može imati izravan utjecaj na sigurnost pacijenata. U financijskoj instituciji prioritet može biti sprječavanje neovlaštenih transakcija. Energetski i telekomunikacijski subjekti moraju procijeniti i širi učinak na kontinuitet ključnih usluga. Jedan obrazac ne odgovara svim poslovnim modelima.
Procjena utjecaja određuje sljedeći potez
Nakon početnog ograničavanja slijedi procjena opsega. Potrebno je utvrditi jesu li ugroženi osobni podaci, poslovne tajne, korisnički računi, sigurnosne kopije, povezani dobavljači ili ključne usluge. Treba procijeniti i trajanje prekida, broj pogođenih korisnika, mogućnost ponavljanja incidenta te postoje li pokazatelji da je napadač zadržao pristup.
Ovdje se često pojavljuje opasna pretpostavka: ako nema dokaza o krađi podataka, krađe nije bilo. Ispravniji pristup je razlikovati potvrđene činjenice, opravdane sumnje i trenutno nepoznate elemente. Takva podjela omogućuje upravi i odgovornim osobama da odlučuju na temelju stvarnog stupnja sigurnosti, bez preuranjenog umanjivanja ili dramatiziranja događaja.
Procjena utjecaja mora biti povezana s registrom imovine, klasifikacijom podataka, analizom rizika i vlasnicima procesa. Ako organizacija ne zna koji sustav podržava koju ključnu uslugu, tko je vlasnik podataka i gdje se čuvaju dokazi o kontrolama, odgovor će se svesti na improvizaciju. Upravo zato upravljanje incidentima počinje mnogo prije samog incidenta.
Prijavljivanje mora biti pravodobno i dokazivo
Zakonske i ugovorne obveze prijavljivanja ovise o statusu organizacije, vrsti incidenta, pogođenim uslugama i primjenjivom regulatornom okviru. Zakon o kibernetičkoj sigurnosti i povezani zahtjevi traže od obveznika da imaju uređene postupke za prepoznavanje, procjenu i prijavu značajnih incidenata. Kada su pogođeni osobni podaci, mogu se aktivirati i zasebne obveze prema propisima o zaštiti podataka.
Najveća pogreška je čekati potpunu tehničku sliku prije pokretanja regulatorne procjene. U ranoj fazi često nisu poznate sve činjenice, no organizacija može i mora procijeniti postoji li prag za obavijest te započeti pripremu prijave. Naknadne dopune su dio urednog procesa, pod uvjetom da se uredno evidentiraju nove informacije, odluke i poduzete mjere.
Prijava mora biti usklađena s činjenicama koje su u tom trenutku potvrđene. Treba opisati prirodu događaja, preliminarni utjecaj, pogođene usluge, mjere ograničavanja, kontakt osobu i plan daljnjeg postupanja. Neprovjerene pretpostavke ne treba predstavljati kao činjenice, ali ih ne treba ni prešutjeti ako su relevantne za procjenu rizika.
Oporavak bez ponavljanja istog propusta
Vraćanje sustava u rad nije završetak incidenta. Prije povratka potrebno je potvrditi da je uzrok uklonjen, da kompromitirani pristupi više nisu aktivni i da su sigurnosne kopije vjerodostojne. Kod ransomwarea, primjerice, samo vraćanje podataka bez promjene kompromitiranih vjerodajnica ili zatvaranja početnog vektora može otvoriti put ponovnom napadu.
Nakon stabilizacije slijedi strukturirana analiza. Treba utvrditi što je otkriveno na vrijeme, gdje je proces zapeo, jesu li uloge bile jasne, jesu li zapisi bili dostupni i jesu li postojeće kontrole djelovale kako je zamišljeno. Rezultat ne bi smio biti samo izvještaj o incidentu, nego akcijski plan s vlasnicima aktivnosti, rokovima, prioritetima i dokazima provedbe.
Kontinuirana spremnost za nadzor traži da se incidenti, rizici, neusklađenosti i korektivne mjere vode na jednom mjestu. Platforma ITrevizija.hr može pomoći povezati revizijske dokaze, procjenu usklađenosti i aktivnosti otklanjanja nedostataka, tako da organizacija ne mora ponovno sastavljati sliku stanja kada se dogodi ozbiljan događaj ili regulatorni nadzor.
Najkorisniji test plana nije rasprava u dokumentu, nego vježba na realnom scenariju. Provedite simulaciju kompromitiranog računa, prekida ključne usluge ili sumnje na curenje podataka. Kada tim mora donijeti odluku u ograničenom vremenu, brzo postaje vidljivo nedostaje li kontakt, ovlast, dokaz ili jasna procedura. Tada se plan još može popraviti mirno, prije nego što ga stvarni incident stavi na kušnju.