Petak je poslijepodne, nadzorni sustav bilježi neuobičajeno izdvajanje podataka, a IT tim još utvrđuje je li riječ o stvarnom proboju, pogrešnoj konfiguraciji ili lažnom alarmu. U takvoj situaciji rok prijave incidenta ne počinje kada organizacija dovrši forenzičku analizu, nego kada sazna za značajan incident. Razlika je operativno i regulatorno presudna: čekanje na potpunu sliku može značiti propuštanje prvog zakonskog roka.
Za subjekte obuhvaćene Zakonom o kibernetičkoj sigurnosti i obvezama proizašlima iz NIS2 regulative, prijava nije administrativna radnja koja se rješava nakon sanacije. Ona je dio upravljanja incidentom. Organizacija mora istodobno ograničavati štetu, prikupljati dokaze, donositi odluke i nadležnom tijelu dostavljati informacije koje su u tom trenutku dostupne.
Rok prijave incidenta: 24 sata, 72 sata i mjesec dana
Kod značajnog incidenta primjenjuju se tri vremenska okvira. Oni nisu zamjena jedan za drugi, nego slijed obveza koji prati razvoj incidenta i sazrijevanje informacija.
Prvi korak je rano upozorenje, koje se dostavlja bez nepotrebnog odgađanja, a najkasnije u roku od 24 sata od saznanja za značajan incident. Njegova je svrha omogućiti nadležnim institucijama rano razumijevanje mogućeg prekograničnog, sektorskog ili šireg operativnog rizika. U ovoj fazi nije realno očekivati potpunu tehničku analizu. Potrebno je navesti da je incident uočen, postoji li sumnja na zlonamjerno djelovanje te može li imati utjecaj na pružanje usluga.
Slijedi prijava incidenta u roku od 72 sata od saznanja. Ona treba sadržavati konkretniju početnu procjenu značaja i utjecaja, poznate pokazatelje kompromitacije, procjenu trajanja, zahvaćene sustave ili usluge te, kada je moguće, opis uzroka. Ako postoji sumnja da je riječ o nezakonitom ili zlonamjernom postupanju, to također treba jasno naznačiti.
Završno izvješće dostavlja se najkasnije u roku od mjesec dana od prijave incidenta. Ono daje cjelovitu sliku: opis incidenta, njegov tijek, procjenu posljedica, vjerojatni uzrok ili vrstu prijetnje te mjere poduzete za ograničavanje štete i sprječavanje ponavljanja. Ako incident još traje, organizacija ne smije čekati njegovo potpuno zatvaranje bez komunikacije. Ovisno o okolnostima i zahtjevu nadležnog tijela, dostavlja se izvješće o napretku, a završno izvješće nakon završetka postupanja.
Točan kanal, obrazac i primatelj ovise o kategoriji subjekta, sektoru i nadležnom tijelu odnosno CSIRT-u. Zato interna procedura ne smije sadržavati samo općenitu uputu da se incident „prijavi nadležnima”. Mora unaprijed definirati kome se prijava šalje, tko je ovlašten za slanje i kako se dokazuje vrijeme dostave.
Kada incident postaje značajan?
Nije svaki sigurnosni događaj prijavljiv incident. Neuspjela prijava korisnika, izolirani malware koji je blokiran prije izvršavanja ili kratkotrajna smetnja bez utjecaja na uslugu mogu zahtijevati internu obradu, ali ne nužno i regulatornu prijavu. Problem nastaje kada organizacija procjenjuje značaj isključivo prema trenutačno poznatoj šteti.
Incident može biti značajan ako je prouzročio ili može prouzročiti ozbiljan poremećaj u pružanju usluge, financijski gubitak, kompromitaciju osjetljivih podataka ili značajnu štetu drugim fizičkim ili pravnim osobama. Procjena zato mora obuhvatiti opseg zahvaćenih sustava, trajanje prekida, broj korisnika ili klijenata, ovisnost kritičnih poslovnih procesa o pogođenoj usluzi i mogućnost daljnjeg širenja.
U prvim satima ne postoji uvijek potpuna sigurnost. Upravo zato postupak treba biti postavljen na načelu razumne početne procjene. Ako postoje pokazatelji da incident može dosegnuti prag značajnosti, sigurnije je aktivirati postupak eskalacije i pripremiti rano upozorenje nego čekati konačnu potvrdu. Naknadna dopuna prijave normalan je dio upravljanja incidentom. Propušten rok puno je teže objasniti.
Najčešća pogreška: sat počinje prekasno
Organizacije često računaju rok od trenutka kada njihov vanjski pružatelj usluge potvrdi uzrok, kada se zaključi krizni sastanak ili kada uprava odobri tekst prijave. Takav pristup stvara nepotreban regulatorni rizik.
Ključno je dokumentirati trenutak saznanja. To je trenutak kada organizacija ima dovoljno informacija da razumno zaključi kako se dogodio, ili se vjerojatno dogodio, značajan incident. U praksi to može biti alarm sigurnosnog operativnog centra, potvrda nedostupnosti ključne usluge, nalaz analize zapisa ili obavijest dobavljača koji upravlja dijelom infrastrukture.
Nakon toga sat ne staje zato što se čeka odgovor proizvođača, vanjskog SOC-a, cloud pružatelja ili poslovnog partnera. Ugovori s dobavljačima zato trebaju sadržavati jasne obveze promptne obavijesti, dostupnosti kontaktnih osoba i dostave tehničkih podataka potrebnih za regulatorno izvješćivanje. Odgovornost subjekta obveznika ne može se učinkovito prenijeti na treću stranu samo zato što ona upravlja dijelom IT okruženja.
Što pripremiti prije incidenta
Rokovi od 24 i 72 sata ne ostavljaju prostor za traženje vlasnika procesa, popisa kontakata ili posljednje verzije obrasca. Učinkovita priprema znači da uprava, IT, sigurnost, pravna funkcija, zaštita podataka, komunikacije i vlasnici poslovnih usluga znaju svoju ulogu prije krizne situacije.
Minimalni operativni okvir treba urediti najmanje sljedeće:
- kriterije za eskalaciju događaja u mogući značajan incident
- odgovorne osobe i zamjene za procjenu, odobrenje i slanje prijave
- kontaktne podatke nadležnih tijela, CSIRT-ova, dobavljača i članova kriznog tima
- predloške za rano upozorenje, prijavu u 72 sata, izvješće o napretku i završno izvješće
- način evidentiranja odluka, vremena saznanja, verzija prijava i tehničkih dokaza.
Posebno je važno razdvojiti tehničku istragu od regulatornog izvješćivanja, ali ih čvrsto povezati. Forenzičari trebaju istraživati bez pritiska da u prvim satima daju konačne zaključke. Osoba odgovorna za usklađenost mora istodobno znati koje su činjenice dovoljno pouzdane za prijavu, što je procjena, a što još nije potvrđeno. Jasno označavanje razine sigurnosti informacije smanjuje rizik pogrešnog izvješćivanja.
Dokazi nisu dodatak prijavi
U nadzoru nije dovoljno tvrditi da je prijava poslana na vrijeme. Organizacija mora moći dokazati kada je incident otkriven, tko je donio odluku o značajnosti, koje su informacije tada bile dostupne i kada je pojedina prijava dostavljena. Zato se dokazi ne prikupljaju naknadno samo za potrebe revizije.
Zapisi iz nadzornih sustava, tiket sustava, zapisnici kriznih sastanaka, komunikacija s dobavljačima, verzije izvješća i potvrde slanja čine povezani dokazni trag. Kada su ti elementi raspršeni po poštanskim sandučićima, tablicama i privatnim porukama, organizacija teško stvara pouzdanu kronologiju. Osim regulatornog rizika, to usporava i samu sanaciju.
Strukturirana platforma za upravljanje usklađenošću može povezati obvezu, odgovornu osobu, rok, dokaz i korektivnu aktivnost u jednom kontroliranom procesu. ITrevizija.hr pritom omogućuje organiziranje revizijskih dokaza, praćenje neusklađenosti i izradu plana aktivnosti bez dugotrajne implementacije klasičnog GRC sustava. Takav pristup ne zamjenjuje stručnu procjenu incidenta, ali uklanja administrativnu neizvjesnost kada su sati ključni.
Prijava incidenta i zaštita podataka nisu isti postupak
Kibernetički incident može istodobno aktivirati obveze prema Zakonu o kibernetičkoj sigurnosti i obveze zaštite osobnih podataka. Ako incident uključuje povredu osobnih podataka, potrebno je zasebno procijeniti rizik za prava i slobode ispitanika te postupati prema pravilima koja uređuju prijavu povrede osobnih podataka.
Rokovi, primatelji i sadržaj tih prijava nisu nužno isti. Ne treba pretpostaviti da prijava jednog tijela automatski ispunjava obvezu prema drugome. S druge strane, paralelni postupci moraju koristiti usklađenu činjeničnu osnovu. Različiti podaci o vremenu otkrivanja, opsegu incidenta ili zahvaćenim sustavima stvaraju dodatna pitanja u nadzoru.
Najbolje rješenje nije izrada jednog univerzalnog obrasca za sve vrste prijava. Rješenje je jedinstven registar činjenica i dokaza, iz kojeg odgovorne funkcije izrađuju regulatorno prilagođena izvješća. Tako sigurnosni, pravni i poslovni tim rade na istoj provjerljivoj kronologiji.
Rok se može ispuniti samo uvježbanim procesom
Incident response plan koji nije testiran često sadrži ispravne nazive uloga, ali ne odgovara na praktična pitanja: tko odlučuje ako CISO nije dostupan, tko kontaktira dobavljača izvan radnog vremena, tko procjenjuje poslovni utjecaj i tko ima ovlast poslati preliminarnu prijavu prije sastanka uprave?
Stolne vježbe i simulacije trebaju uključivati upravo te prepreke. Korisno je simulirati ransomware u ključnom poslovnom sustavu, kompromitaciju računa dobavljača ili prekid cloud usluge, a zatim mjeriti vrijeme do eskalacije, donošenja odluke i pripreme ranog upozorenja. Cilj nije savršeno predvidjeti svaki napad. Cilj je potvrditi da organizacija može djelovati pod pritiskom, uz dovoljno kontrole i dokazivosti.
Pravi pokazatelj spremnosti nije broj napisan u proceduri, nego sposobnost organizacije da u prvih 24 sata jasno utvrdi što zna, što još provjerava, tko je odgovoran i koji dokaz podupire svaku odluku.