Pravi odgovor na pitanje kada prijaviti cyber incident rijetko je „kad IT tim utvrdi sve činjenice”. Kod ozbiljnog napada potpuna slika često se ne može dobiti danima, a propisani rokovi počinju teći već kada organizacija stekne razumnu osnovu sumnjati da je nastupio značajan incident. Zato prijava nije završni administrativni korak nakon istrage. Ona je dio upravljanja incidentom, uz zaustavljanje napada, očuvanje dokaza i procjenu poslovnog učinka.
Za subjekte obuhvaćene Zakonom o kibernetičkoj sigurnosti i NIS2 okvirom, zakašnjela ili nedovoljno obrazložena prijava može otvoriti regulatorni problem i povećati operativnu štetu. Uprava, CISO, IT, pravna služba i voditelj usklađenosti moraju unaprijed znati tko procjenjuje incident, tko donosi odluku o prijavi i kako se dokazuje da je odluka bila razumna.
Kada prijaviti cyber incident prema ZKS-u i NIS2?
Incident treba prijaviti kada je, na temelju dostupnih činjenica, vjerojatno da može imati značajan učinak na pružanje usluga, primatelje usluga, povezane subjekte ili širu sigurnost mrežnih i informacijskih sustava. Ne čeka se potpuna forenzička analiza, potvrda svih kompromitiranih računa ni konačni izračun štete.
U praksi, procjena značajnosti ovisi o kombinaciji nekoliko okolnosti: broju pogođenih korisnika ili sustava, trajanju prekida, opsegu gubitka dostupnosti, integriteta ili povjerljivosti podataka, financijskom učinku, utjecaju na kritičnu uslugu te mogućnosti da se incident proširi na druge organizacije. Incident u izoliranom testnom sustavu bez poslovnog učinka neće imati istu regulatornu težinu kao ransomware u bolničkom informacijskom sustavu, kompromitacija udaljenog pristupa dobavljača ili nedostupnost sustava za obračun plaćanja.
NIS2 predviđa postupno izvješćivanje o značajnim incidentima: rano upozorenje bez nepotrebne odgode, u pravilu unutar 24 sata od saznanja, zatim obavijest o incidentu u pravilu unutar 72 sata te završno izvješće najkasnije mjesec dana nakon obavijesti. Nacionalna pravila, upute nadležnih tijela i status organizacije određuju konkretnu primjenu i kanal prijave. Zato interne procedure ne smiju biti napisane samo općenito, nego moraju biti usklađene s obvezama koje vrijede baš za vaš sektor i organizaciju.
Ključna je razlika između trenutka otkrivanja tehničke anomalije i trenutka kada organizacija ima dovoljno razloga smatrati da se radi o incidentu. Primjerice, jedan neuspješan pokušaj prijave nije nužno incident koji se prijavljuje. Međutim, neuobičajeno korištenje administratorskog računa iz strane lokacije, nakon kojeg slijedi izvoz većeg volumena podataka, zahtijeva trenutačnu eskalaciju – čak i prije potvrde je li prijenos bio zlonamjeran.
Ne čekajte odgovor na svako tehničko pitanje
Tijekom prvih sati incidenta često nedostaju odgovori na najvažnija pitanja: je li napadač još prisutan, jesu li podaci izneseni, koji je početni vektor napada i koliko je sustava zahvaćeno. To nije razlog za propuštanje roka. Rano upozorenje služi upravo tome da nadležna tijela dobiju početnu informaciju o mogućem značajnom događaju, njegovoj procijenjenoj ozbiljnosti i eventualnim prekograničnim posljedicama.
Prva prijava treba biti činjenična i jasno označiti što je potvrđeno, a što je tek radna pretpostavka. Nije korisno iznositi kategoričke zaključke koje ćete morati povući nekoliko sati poslije. Umjesto tvrdnje da je „došlo do krađe svih podataka”, prikladnije je navesti da je uočen neovlašten pristup određenom poslužitelju, da se analizira opseg mogućeg pristupa te koje su mjere ograničavanja već poduzete.
Dobra prijava u ovoj fazi obično obuhvaća vrijeme otkrivanja, pogođene usluge i sustave, preliminarnu procjenu utjecaja, indikatore mogućeg širenja, poduzete mjere te kontakt osobu dostupnu za daljnju komunikaciju. Ako dio podataka nije poznat, treba navesti kada se očekuje ažuriranje. Regulatorno zrela organizacija ne skriva neizvjesnost – njome upravlja i dokumentira je.
Koji događaji zahtijevaju hitnu procjenu prijave?
Nisu sve sigurnosne obavijesti prijavljivi incidenti, ali određeni obrasci zahtijevaju procjenu bez odgode. To su osobito:
- ransomware, ucjena ili enkripcija sustava koja ugrožava kontinuitet poslovanja
- nedostupnost ključne digitalne usluge, osobito u zdravstvu, energetici, financijama, prometu i telekomunikacijama
- potvrđen ili ozbiljno sumnjiv neovlašten pristup privilegiranim računima, produkcijskim sustavima ili sigurnosnim alatima
- krađa, gubitak ili neovlašteno otkrivanje osjetljivih, osobnih ili poslovno kritičnih podataka
- kompromitacija dobavljača, cloud usluge ili integracije koja može zahvatiti više korisnika ili povezanih subjekata.
Važno je ne poistovjetiti volumen tehničkih alarma s ozbiljnošću incidenta. Tisuće blokiranih pokušaja napada mogu značiti da zaštitne kontrole rade očekivano. Jedan uspješan phishing napad na financijskog direktora može imati daleko veći učinak. Procjena mora povezati tehnički signal s poslovnom funkcijom, klasifikacijom podataka i stvarnim rizikom za korisnike i organizaciju.
Cyber incident i povreda osobnih podataka nisu ista obveza
Jedan događaj može aktivirati više režima izvješćivanja. Ako cyber incident uključuje povredu osobnih podataka, organizacija mora zasebno procijeniti obveze prema Općoj uredbi o zaštiti podataka. Ako je vjerojatno da povreda predstavlja rizik za prava i slobode pojedinaca, prijava nadzornom tijelu podnosi se bez nepotrebnog odgađanja, prema potrebi unutar 72 sata od saznanja. Kod visokog rizika može biti potrebna i komunikacija pogođenim osobama.
Ta procjena ne zamjenjuje obveze iz kibernetičke sigurnosti, kao što ni prijava cyber incidenta ne zamjenjuje procjenu povrede osobnih podataka. U praksi se radi o istom operativnom događaju, ali s različitim kriterijima, primateljima, rokovima i dokazima. Zato je potrebno uspostaviti zajednički tijek rada između sigurnosnog tima, službenika za zaštitu podataka, pravne funkcije i poslovnog vlasnika usluge.
Odluka o prijavi mora biti dokaziva
Nakon incidenta nije dovoljno reći da je organizacija postupala „prema najboljoj procjeni”. Mora biti moguće pokazati tko je incident evidentirao, koje su činjenice bile dostupne u određenom trenutku, na temelju kojih kriterija je ocijenjena značajnost i tko je odobrio prijavu ili odluku da prijava nije potrebna.
Zapis odluke treba sadržavati vremensku crtu, izvor upozorenja, zahvaćenu imovinu, procijenjeni utjecaj, klasifikaciju incidenta, poduzete mjere, komunikaciju s nadležnim tijelima i naknadne korekcije procjene. Očuvajte logove, snimke relevantnih konfiguracija, zapise iz sustava za nadzor, komunikaciju s dobavljačima i forenzičke artefakte. Pri tome treba paziti da se dokazni materijal ne mijenja nepotrebnim intervencijama i da je pristup ograničen na ovlaštene osobe.
Ovdje se najčešće vidi razlika između formalne politike i stvarne spremnosti. Organizacija može imati proceduru od dvadeset stranica, ali će zakazati ako ne zna gdje se nalaze dokazi, tko ima ovlast za regulatornu komunikaciju ili kako pratiti rokove tijekom noći, vikenda i godišnjih odmora.
Uspostavite pragove prije nego što se incident dogodi
Najbolji trenutak za definiranje prijavljivosti nije tijekom ransomware napada. U internom planu odgovora na incidente unaprijed odredite klasifikacijske razine, poslovne vlasnike kritičnih usluga, dežurne kontakte, zamjene i put eskalacije prema upravi. Za svaku razinu potrebno je navesti očekivano vrijeme reakcije, obvezu procjene regulatorne prijave i osobe koje sudjeluju u odluci.
Pragovi ne smiju biti samo tehnički. Uz broj zahvaćenih uređaja, uključite maksimalno dopušteno trajanje prekida usluge, vrstu podataka, učinak na ugovorne obveze, ovisnost o dobavljačima i mogući utjecaj na druge subjekte. Time se sprječava da IT tim sam procjenjuje poslovnu značajnost bez informacija koje ima samo poslovno vodstvo.
Platforma poput ITrevizija.hr može objediniti procjenu usklađenosti, evidenciju dokaza, upravljanje neusklađenostima i plan korektivnih aktivnosti. Takav pristup ne odlučuje umjesto odgovorne osobe, ali osigurava da su kriteriji, dokumentacija i provedene mjere dostupni kada ih trebaju uprava, interni revizor ili nadležno tijelo.
Prijavljivanje cyber incidenta nije test savršenog znanja pod pritiskom. To je test pripremljenosti organizacije da rano prepozna rizik, donese obrazloženu odluku i nastavi ažurirati činjenice bez gubitka kontrole nad poslovanjem.