Kibernetički incident može pogoditi bilo koju organizaciju, od multinacionalne korporacije do male hrvatske tvrtke. Razlika između katastrofe i kontrolirane situacije leži u pripremljenosti. Organizacije s jasnim planom odgovora oporave se brže, s manjom štetom i nižim troškovima. Ovaj vodič objašnjava kako pripremiti plan, kako reagirati na incident i kako ispuniti zakonske obveze prema NIS2 i GDPR-u.
Sažetak i ključne točke
- NIS2 zahtijeva prijavu incidenta u 24 sata (rano upozorenje) i 72 sata (detaljna obavijest).
- GDPR zahtijeva prijavu povrede podataka AZOP-u u 72 sata.
- Organizacije s planom odgovora smanjuju troškove incidenta za 60 % (IBM, 2025.).
- NIST SP 800-61 definira 4 faze upravljanja incidentom: priprema, otkrivanje i analiza, zaustavljanje/uklanjanje/oporavak, aktivnosti nakon incidenta.
- Svaka organizacija treba tim za odgovor (IRT/CSIRT), makar i neformalni.
- Dokumentacija incidenta obvezna je i prema NIS2 i prema GDPR-u.
Sadržaj
- Što je kibernetički incident?
- Zašto svaka organizacija treba plan odgovora
- Faze upravljanja incidentom
- Priprema: Tim za odgovor
- Otkrivanje i analiza
- Obveze prijave prema NIS2
- Obveze prijave prema GDPR-u
- Zaustavljanje i uklanjanje prijetnje
- Oporavak i naučene lekcije
- Plan odgovora: što mora sadržavati
- Najčešće pogreške
- FAQ
- Zaključak
Što je kibernetički incident?
Kibernetički incident je događaj koji ugrožava ili narušava povjerljivost, cjelovitost ili dostupnost informacijskih sustava, mreža ili podataka.
| Vrsta incidenta | Primjeri |
|---|---|
| Ransomware | Šifriranje podataka i zahtjev za otkupninom |
| Povreda podataka | Neovlašteni pristup ili krađa osobnih podataka |
| DDoS napad | Preplavljanje sustava zahtjevima, nedostupnost usluge |
| Kompromitacija računa | Krađa pristupnih podataka zaposlenika |
| Malware infekcija | Zaraza sustavima zlonamjernim softverom |
| Phishing | Uspješan phishing koji rezultira kompromitacijom |
| Unutarnja prijetnja | Zlouporaba pristupa od strane zaposlenika |
| Napad na opskrbni lanac | Kompromitacija putem softvera dobavljača |
Klasifikacija prema ozbiljnosti
| Razina | Kriterij | Primjer | Odgovor |
|---|---|---|---|
| Kritična | Potpuni prestanak poslovanja ili masivna povreda podataka | Ransomware koji zahvati sve sustave | Aktivacija cijelog IRT-a, prijava CERT-u/AZOP-u |
| Visoka | Značajan utjecaj na poslovanje ili osjetljive podatke | Kompromitacija baze klijenata | Aktivacija IRT-a, moguća prijava |
| Srednja | Ograničeni utjecaj, zahvaćeni pojedinačni sustavi | Malware na jednom računalu | IT tim, praćenje |
| Niska | Minimalan utjecaj, sumnja na incident | Neuspjeli pokušaj phishinga | Dokumentiranje, praćenje |
Zašto trebate plan odgovora
Financijski argumenti
| S planom odgovora | Bez plana odgovora |
|---|---|
| Troškovi incidenta 60 % niži | Prosječni trošak: 4,88 mil. USD |
| Vrijeme otkrivanja: 100 dana | Vrijeme otkrivanja: 194 dana |
| Vrijeme zaustavljanja: 54 dana | Vrijeme zaustavljanja: 73 dana |
| Kontrolirano upravljanje krizom | Kaotična reakcija, veća šteta |
Izvor: IBM Cost of a Data Breach Report 2025.
Regulatorni argumenti
| Propis | Zahtjev |
|---|---|
| NIS2 | Obveza upravljanja incidentima i prijave za ključne/važne subjekte |
| GDPR | Obveza prijave povreda osobnih podataka AZOP-u |
| ISO 27001 | Kontrole A.5.24 do A.5.28: upravljanje incidentima |
| DORA | Upravljanje ICT incidentima za financijski sektor |
Faze upravljanja incidentom
NIST SP 800-61 (Computer Security Incident Handling Guide) definira ciklički proces s četiri glavne faze:
┌─────────────┐ ┌──────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ PRIPREMA │ → │ OTKRIVANJE I │ → │ ZAUSTAVLJANJE, │ → │ AKTIVNOSTI NAKON │
│ │ │ ANALIZA │ │ UKLANJANJE, OPORAVAK│ │ INCIDENTA │
└─────────────┘ └──────────────────┘ └──────────────────────┘ └──────────────────────┘
↑ │
└─────────────────── Naučene lekcije ─────────────────────────────────────┘
Detaljan pregled faza
| Faza | Aktivnosti | Cilj |
|---|---|---|
| 1. Priprema | Plan odgovora, tim, alati, edukacija, vježbe | Biti spreman prije nego incident nastane |
| 2. Otkrivanje | Praćenje sustava, analiza upozorenja, klasifikacija | Brzo otkriti i potvrditi incident |
| 3. Analiza | Određivanje opsega, utjecaja i uzroka | Razumjeti što se događa |
| 4. Zaustavljanje | Izolacija pogođenih sustava | Spriječiti daljnje širenje |
| 5. Uklanjanje | Uklanjanje prijetnje iz sustava | Očistiti sustave od napadača |
| 6. Oporavak | Vraćanje sustava u normalu | Nastavak poslovanja |
| 7. Naučene lekcije | Analiza, dokumentacija, poboljšanja | Spriječiti ponavljanje |
Priprema: Tim za odgovor
Struktura tima za odgovor na incidente (IRT/CSIRT)
| Uloga | Odgovornost | Tko |
|---|---|---|
| Voditelj IRT-a | Koordinacija odgovora, donošenje odluka | Voditelj IT sigurnosti ili CTO |
| IT stručnjak | Tehnička analiza, zaustavljanje, oporavak | IT administrator, sigurnosni inženjer |
| DPO | Procjena utjecaja na osobne podatke, prijava AZOP-u | Službenik za zaštitu podataka |
| Pravnik | Zakonske obveze, komunikacija s regulatorima | Interni ili vanjski pravnik |
| Komunikator | Komunikacija s medijima, klijentima, zaposlenicima | PR ili direktor |
| Uprava | Strateške odluke, odobrenje resursa | Direktor ili član uprave |
| Vanjski stručnjaci | Forenzika, specijalistička pomoć | Prema potrebi |
Za manje organizacije
Manja tvrtka ne treba formalni CSIRT. Dovoljno je:
- Odrediti odgovornu osobu za koordinaciju u slučaju incidenta
- Imati kontakte vanjskih stručnjaka (IT sigurnost, pravnik, forenzika)
- Definirati tko koga obavještava i u kojem roku
- Imati ažurirane kontaktne podatke CERT-a i AZOP-a
Otkrivanje i analiza
Kako otkrivati incidente
| Izvor | Primjeri |
|---|---|
| SIEM sustav | Centralizirano praćenje sigurnosnih logova i korelacija događaja |
| EDR/XDR | Upozorenja o sumnjivom ponašanju na krajnjim točkama |
| IDS/IPS | Otkrivanje upada na mrežnoj razini |
| Prijave zaposlenika | Sumnjivi e-mailovi, neobično ponašanje sustava |
| Vanjska obavijest | CERT, partner, klijent ili istraživač prijavljuje incident |
| Nadzor dark weba | Otkrivanje ukradenih podataka ili pristupnih podataka na prodaji |
Indikatori kompromitacije (IoC)
| Indikator | Primjer |
|---|---|
| Neobična mrežna aktivnost | Veliki izlazni promet u neuobičajeno vrijeme |
| Sumnjivi procesi | Nepoznati procesi s visokom aktivnošću |
| Promjene datoteka | Masovno preimenovanje ili šifriranje datoteka |
| Neuspješne prijave | Veliki broj neuspješnih pokušaja prijave |
| Promjena konfiguracije | Neovlaštene promjene vatrozida ili politika |
| Novi korisnički računi | Kreiranje neovlaštenih korisničkih računa |
Trijažni postupak
- Potvrda: je li ovo stvarni incident ili lažna uzbuna?
- Klasifikacija: koja je vrsta i ozbiljnost incidenta?
- Prioritizacija: koliko je hitno reagirati?
- Eskalacija: koga treba obavijestiti?
Obveze prijave prema NIS2
Organizacije obuhvaćene NIS2 direktivom (Zakon o kibernetičkoj sigurnosti, NN 14/24) imaju stroge rokove prijave:
| Faza | Rok | Što prijaviti | Kome |
|---|---|---|---|
| Rano upozorenje | 24 sata od saznanja | Osnovna informacija: vrsta incidenta, potencijalni utjecaj | CERT.hr |
| Obavijest o incidentu | 72 sata od saznanja | Detaljnije: opseg, ozbiljnost, indikatori kompromitacije | CERT.hr |
| Međuizvješće | Na zahtjev CERT-a | Ažurirani podaci o tijeku | CERT.hr |
| Završno izvješće | 1 mjesec nakon incidenta | Potpuna analiza: uzrok, mjere, naučene lekcije | CERT.hr |
Kada je prijava obvezna
Incident se mora prijaviti ako:
- Može uzrokovati značajan poremećaj u pružanju usluge
- Može uzrokovati financijsku štetu iznad praga
- Može utjecati na druge organizacije (opskrbni lanac)
- Uključuje osobne podatke (tada i AZOP, prema GDPR-u)
CERT.hr kontakt: cert@cert.hr, +385 1 6164 519. Prijava se može podnijeti i putem web obrasca na cert.hr.
Obveze prijave prema GDPR-u
Ako incident uključuje osobne podatke, primjenjuju se GDPR obveze:
| Obveza | Rok | Uvjet | Kome |
|---|---|---|---|
| Prijava AZOP-u | 72 sata | Ako postoji rizik za prava i slobode ispitanika | azop@azop.hr |
| Obavijest ispitanicima | Bez nepotrebnog odgađanja | Ako je visok rizik za prava ispitanika | Pogođene osobe |
| Interna dokumentacija | Odmah | Svaka povreda, bez obzira na prijavu | Interna evidencija |
Što prijava AZOP-u mora sadržavati (čl. 33. GDPR-a)
| Element | Opis |
|---|---|
| Priroda povrede | Vrsta incidenta, kategorije i broj pogođenih osoba/zapisa |
| Kontakt DPO-a | Ime i kontakt službenika za zaštitu podataka |
| Moguće posljedice | Procjena utjecaja na ispitanike |
| Poduzete mjere | Mjere za ublažavanje i sprečavanje daljnje štete |
NIS2 + GDPR: Ako incident uključuje i povredu podataka i poremećaj usluge, obje prijave su potrebne, CERT-u i AZOP-u, u različitim rokovima. Više: GDPR vodič za Hrvatsku.
Zaustavljanje i uklanjanje
Strategije zaustavljanja
| Strategija | Kada koristiti | Primjer |
|---|---|---|
| Izolacija na razini mreže | Ransomware, lateralno kretanje | Odspojiti pogođeni segment od mreže |
| Izolacija na razini uređaja | Malware na jednom uređaju | Isključiti računalo iz mreže (ali ne gasiti) |
| Blokiranje računa | Kompromitacija korisničkih podataka | Onemogućiti pogođene korisničke račune |
| DNS sinkholing | C2 komunikacija | Preusmjeriti promet prema C2 na siguran poslužitelj |
| Blokiranje IP adresa | Poznati napadačevi IP-jevi | Ažurirati vatrozid |
Očuvanje dokaza
| Aktivnost | Zašto je važno |
|---|---|
| Ne gasiti sustave | Sadržaj memorije (RAM) važan je za forenziku |
| Snimiti memoriju | Alati: FTK Imager, Volatility |
| Kopirati logove | Sačuvati logove prije rotacije ili brisanja |
| Dokumentirati sve | Tko je što učinio, kada, s kojim rezultatom |
| Održavati lanac čuvanja | Dokazi moraju biti neizmijenjeni za pravni postupak |
Uklanjanje prijetnje
- Identificirati sve kompromitiranje sustave (ne samo prvi otkriveni)
- Ukloniti malware, backdoor i alate napadača
- Promijeniti sve pristupne podatke (lozinke, ključevi, tokeni)
- Zakrpati ranjivosti koje je napadač iskoristio
- Provjeriti integritet sustava i podataka
Oporavak i naučene lekcije
Oporavak
| Korak | Aktivnost |
|---|---|
| 1 | Oporavak sustava iz čistih sigurnosnih kopija |
| 2 | Provjera integriteta obnovljenih podataka |
| 3 | Postupno vraćanje: počnite s najkritičnijim sustavima |
| 4 | Pojačano praćenje: napadač može pokušati ponovo |
| 5 | Testiranje: provjerite da sustavi rade ispravno |
| 6 | Obavijest korisnicima i partnerima o ponovnoj dostupnosti |
Naučene lekcije (Post-Incident Review)
| Pitanje | Svrha |
|---|---|
| Što se točno dogodilo? | Razumijevanje uzroka |
| Kada je otkriveno i koliko je trajalo? | Procjena vremena reakcije |
| Jesu li postojeće mjere funkcionirale? | Evaluacija zaštite |
| Što je funkcioniralo u odgovoru? | Identificiranje dobrih praksi |
| Što nije funkcioniralo? | Identificiranje slabosti |
| Koje su konkretne mjere poboljšanja? | Sprečavanje ponavljanja |
Naučene lekcije su najvažniji dio upravljanja incidentom. Incident koji se ne analizira ponovit će se.
Plan odgovora
Elementi plana odgovora na incidente (IRP)
| Element | Opis |
|---|---|
| Opseg i svrha | Koje vrste incidenata pokriva, ciljevi |
| Tim za odgovor | Uloge, odgovornosti, kontakti (interni + vanjski) |
| Klasifikacija incidenata | Kriteriji za razine ozbiljnosti |
| Postupci otkrivanja | Kako prepoznati incident, tko može prijaviti |
| Postupci zaustavljanja | Korak po korak za svaku vrstu incidenta |
| Komunikacijski plan | Tko komunicira s kime (CERT, AZOP, mediji, klijenti) |
| Postupci oporavka | Kako obnoviti sustave i nastaviti poslovanje |
| Rokovi prijave | NIS2 (24/72h), GDPR (72h), interni rokovi |
| Kontakti | Ažurirani kontakti svih relevantnih osoba i tijela |
| Vježbe i testiranje | Redovite vježbe za provjeru plana |
Kontrolna lista za prvi sat
| # | Aktivnost | Odgovorna osoba |
|---|---|---|
| 1 | Potvrda incidenta | IT/sigurnost |
| 2 | Klasifikacija i prioritizacija | Voditelj IRT-a |
| 3 | Aktivacija IRT-a | Voditelj IRT-a |
| 4 | Izolacija pogođenih sustava | IT tim |
| 5 | Početak dokumentacije | Svi sudionici |
| 6 | Obavijest upravi | Voditelj IRT-a |
| 7 | Procjena utjecaja na podatke (DPO) | DPO |
| 8 | Kontakt vanjskih stručnjaka (po potrebi) | Voditelj IRT-a |
Redovite vježbe
| Vrsta vježbe | Učestalost | Sudionici |
|---|---|---|
| Tabletop vježba | Kvartalno | IRT + uprava |
| Simulacija incidenta | Polugodišnje | IRT + IT tim |
| Potpuna vježba oporavka | Godišnje | Cijela organizacija |
| Testiranje sigurnosnih kopija | Mjesečno | IT tim |
Najčešće pogreške
1. Nema plana: reagira se ad hoc
Bez plana svaki incident postaje kriza. Plan osigurava strukturiran i brz odgovor.
2. Plan postoji, ali ga nitko ne poznaje
Plan koji leži u ladici ne vrijedi. Zaposlenici moraju znati svoju ulogu i postupke.
3. Gašenje računala umjesto izolacije
Gašenje uništava dokaze u memoriji. Odspojite iz mreže, ali ne gasiti.
4. Propuštanje rokova prijave
24 sata za NIS2, 72 sata za GDPR. Propuštanje rokova povećava kaznu.
5. Nedokumentiranje incidenta
Bez dokumentacije ne možete dokazati usklađenost ni naučiti za budućnost.
6. Fokus samo na tehničko rješavanje
Incident zahtijeva i pravni, komunikacijski i poslovni odgovor, ne samo IT.
7. Nema naučenih lekcija
Incident koji se ne analizira ponovit će se. Post-incident review je obvezan korak.
FAQ
Trebam li plan odgovora ako sam mala tvrtka?
Da. Čak i jednostavan dokument od 2 do 3 stranice s kontaktima, postupcima i rokovima prijave može značajno smanjiti kaos u slučaju incidenta.
Tko u tvrtki treba znati za plan?
Svi relevantni zaposlenici: IT tim, uprava, DPO, komunikacije. Ne moraju svi znati sve detalje, ali moraju znati svoju ulogu i koga kontaktirati.
Koliko košta upravljanje incidentom?
Ovisi o vrsti i opsegu. Za manje incidente: 5.000 do 20.000 EUR (IT rad, forenzika). Za ransomware: 50.000 do 500.000+ EUR (zastoj, oporavak, forenzika, pravni savjeti, kazne). Plan odgovora drastično smanjuje ove troškove.
Moram li prijaviti svaki incident CERT-u?
Prema NIS2, organizacije moraju prijaviti značajne incidente. U praksi, bolje je prijaviti i pitati nego propustiti rok. CERT.hr savjetodavno pomaže i u slučajevima koji ne zahtijevaju formalnu prijavu.
Što ako ne znam je li incident značajan?
Kad ste u nedoumici, prijavite. I NIS2 i GDPR predviđaju preliminarnu prijavu koju možete naknadno ažurirati. Propuštanje roka je veći rizik od nepotrebne prijave.
Zaključak
Upravljanje kibernetičkim incidentima nije luxuz za velike korporacije. To je nužnost za svaku organizaciju u digitalnom okruženju. S NIS2 i GDPR obvezama, plan odgovora na incidente više nije neobvezan, on je regulatorni zahtjev.
Ključne poruke: (1) Pripremite se prije incidenta: plan, tim, kontakti, vježbe. (2) Otkrijte brzo: SIEM, EDR, obuka zaposlenika. (3) Prijavite na vrijeme: 24h CERT, 72h AZOP. (4) Dokumentirajte sve, od početka do kraja. (5) Naučite iz svakog incidenta: poboljšajte zaštitu i plan.
Trebate pomoć? Vision Compliance nudi kibernetičku sigurnost, uključujući izradu planova odgovora na incidente, vježbe i usklađivanje s NIS2. Zakažite besplatnu konzultaciju.
Povezani članci
- Kibernetički napadi: Vrste, primjeri i zaštita. Pregled prijetnji koje zahtijevaju plan odgovora
- NIS2 direktiva: Kompletni vodič za hrvatska poduzeća. Obveze prijave incidenata prema NIS2
- Ransomware napad: Kako zaštititi tvrtku. Prevencija i postupanje kod ransomware napada
Izvori: NIST SP 800-61 rev. 3 (2024.), ENISA, CERT.hr, NIS2 direktiva (EU 2022/2555), GDPR (Uredba EU 2016/679)
Robert Lozo, mag. iur., partner je u Vision Complianceu specijaliziran za usklađenost s EU regulativom. Savjetuje organizacije o GDPR-u, NIS2, AI Actu i financijskoj regulativi te izrađuje dokumentaciju spremnu za reviziju i planove usklađenosti u reguliranim industrijama.