Sadržaj vodiča
- Ukratko
- Provjera ranjivosti i penetracijski test
- Što traže hrvatski propisi i DORA
- Vrste penetracijskih testova
- Metodologije
- Opseg i pravila izvođenja
- Faze penetracijskog testa
- Provjera ranjivosti: postupak
- Kako ocijeniti i prioritizirati nalaze
- Izvještaj koji se može koristiti
- Učestalost prema riziku
- Unutarnji tim ili vanjski izvođač
- Što određuje opseg i cijenu
- Česta pitanja
- Sljedeći korak
- Izvori i pregled
Provjera ranjivosti (procjena ranjivosti) automatski i ručno traži poznate slabosti u sustavima i razvrstava ih prema ozbiljnosti, a penetracijski test kontrolirano pokušava te slabosti iskoristiti i pokazati do čega napadač stvarno može doći. Prva odgovara na pitanje „koje slabosti imamo”, druga na pitanje „što napadač s njima može učiniti”. Tvrtki su najčešće potrebne obje, a nijedna ne dokazuje da sustav nema ranjivosti.
Vodič objašnjava razlike, vrste testova, metodologije i faze, kako se ocjenjuju i rješavaju nalazi i što traže Zakon o kibernetičkoj sigurnosti, Uredba i DORA. Stanje je na 4. studenoga 2026.
Ukratko
- Uredba o kibernetičkoj sigurnosti obvezuje ključne i važne subjekte na svim razinama na redovitu provjeru ranjivosti svih sustava. Potrebu i učestalost penetracijskih testova, red teaminga i purple teaminga subjekt određuje prema procjeni rizika (mjera 5.8.).
- Revizija: ključni subjekti provode reviziju kibernetičke sigurnosti najmanje jednom u dvije godine, a važni subjekti samoprocjenu (čl. 34. i 35. Zakona). Nalazi testova važan su dokaz u oba postupka.
- DORA: financijski subjekti koji nisu mikropoduzeća najmanje jednom godišnje testiraju sve sustave koji podupiru ključne ili važne funkcije. Subjekti koje odredi nadležno tijelo provode TLPT najmanje svake tri godine.
- Ocjena nalaza: CVSS v4.0 dijeli ranjivosti na nisku (0,1 do 3,9), srednju (4,0 do 6,9), visoku (7,0 do 8,9) i kritičnu (9,0 do 10,0) ozbiljnost. Prioritet ipak određuju i izloženost, aktivno iskorištavanje i poslovni učinak.
- Pisano ovlaštenje je nužno: pristup tuđem sustavu bez ovlaštenja kazneno je djelo (čl. 266. Kaznenog zakona).
Provjera ranjivosti i penetracijski test
| Provjera ranjivosti | Penetracijski test | |
|---|---|---|
| Pitanje | Koje poznate slabosti postoje? | Što napadač može postići? |
| Način | Alati za skeniranje i ručna provjera nalaza | Ručno iskorištavanje i povezivanje slabosti, uz alate |
| Dubina | Široko, mnogo sustava | Dublje, odabrani opseg |
| Lažno pozitivni nalazi | Mogući, treba ih provjeriti | Rijetki, jer se nalaz dokazuje |
| Učestalost | Redovito, često automatski | Periodično i nakon većih promjena |
| Rezultat | Popis ranjivosti s ocjenom | Scenariji napada, dokazi i učinak |
Provjera ranjivosti otkriva nedostajuće zakrpe i pogrešne konfiguracije. Penetracijski test pokazuje može li se, primjerice, iz ranjive web aplikacije doći do baze klijenata ili administratorskog računa. Red team ide dalje: dulje vrijeme i bez najave simulira stvarnog napadača kako bi provjerio otkrivanje i odgovor organizacije. Purple team je zajednička vježba napadačkog i obrambenog tima.
Što traže hrvatski propisi i DORA
Zakon i Uredba o kibernetičkoj sigurnosti
Zakon među obveznim mjerama navodi sigurnost u nabavi, razvoju i održavanju sustava, uključujući otkrivanje i otklanjanje ranjivosti, te postupke za procjenu djelotvornosti mjera (čl. 30.). Uredba to razrađuje:
| Mjera | Sadržaj | Osnovna | Srednja | Napredna |
|---|---|---|---|---|
| 5.5. | Pravovremena primjena sigurnosnih zakrpa ili dokumentiran proces upravljanja ranjivostima | A | A | A |
| 5.7. | Upravljanje ranjivostima sustava koje subjekt sam razvija: SAST, DAST, provjera komponenti, penetracijski testovi, bug bounty | C | B | B |
| 5.8. | Redovita provjera ranjivosti svih sustava; potreba i učestalost penetracijskih testova, red teaminga i purple teaminga prema procjeni rizika; praćenje nalaza do rješavanja | A | A | A |
A znači obvezno, B obvezno pod uvjetom (ovdje kada subjekt sam razvija ili održava sustave), a C dobrovoljno. Mjera 5.8. može se ograničiti na kritičnu imovinu iz popisa imovine (mjera 2.1.). Razinu mjera subjekt dobiva pri kategorizaciji, a opisuje je vodič NIS2 kategorizacija.
Revizija i samoprocjena. Ključni subjekti reviziju provode najmanje jednom u dvije godine, a izvješće dostavljaju nadležnom tijelu u osam dana (čl. 34.). Važni subjekti najmanje jednom u dvije godine provode samoprocjenu i dostavljaju izjavu o sukladnosti ili plan ispravljanja (čl. 35.). Reviziju provode revizori s nacionalnim sigurnosnim certifikatom ili odgovarajućim europskim certifikatom (čl. 32.). Dokumentirani testovi i zatvoreni nalazi pokazuju da mjera 5.8. stvarno djeluje.
Dobavljači. Ugovori s dobavljačima trebaju uključiti obvezu upravljanja ranjivostima i obavještavanja o ranjivostima koje mogu utjecati na subjekt, te pravo na reviziju ili dokaz o njoj (mjera 8.3.).
DORA za financijski sektor
| Obveza | Sadržaj |
|---|---|
| Program testiranja (čl. 24.) | Financijski subjekti koji nisu mikropoduzeća imaju program testiranja digitalne operativne otpornosti temeljen na riziku |
| Neovisnost (čl. 24. st. 4.) | Testove provode neovisne unutarnje ili vanjske strane, bez sukoba interesa |
| Godišnji testovi (čl. 24. st. 6.) | Najmanje jednom godišnje primjereni testovi svih IKT sustava i aplikacija koji podupiru ključne ili važne funkcije |
| Vrste testova (čl. 25.) | Procjene i skeniranja ranjivosti, procjene mrežne sigurnosti, pregled koda, testovi na temelju scenarija, penetracijski testovi i drugi |
| TLPT (čl. 26.) | Penetracijski test vođen prijetnjama na produkcijskim sustavima, najmanje svake tri godine, za subjekte koje odredi nadležno tijelo |
| Provoditelji TLPT-a (čl. 27.) | Stručnost u obavještajnim podacima o prijetnjama, penetracijskom testiranju i red teamingu, osiguranje od odgovornosti, akreditacija ili kodeks ponašanja |
Detalje TLPT-a uređuje Delegirana uredba (EU) 2025/1190. ECB-ov okvir TIBER-EU usklađen je 2024. s tim pravilima. Ostale obveze DORA-e opisuje vodič DORA uredba.
Vrste penetracijskih testova
Prema količini informacija
| Vrsta | Tester zna | Kada koristiti |
|---|---|---|
| Black box | Ništa osim cilja | Simulacija vanjskog napadača bez znanja o sustavu |
| Grey box | Korisnički račun, osnovnu dokumentaciju | Simulacija kompromitiranog korisnika ili dobavljača; najčešći izbor |
| White box | Dokumentaciju, arhitekturu, izvorni kod | Najtemeljitija provjera u ograničenom vremenu |
Prema cilju
| Cilj | Što se provjerava |
|---|---|
| Vanjska infrastruktura | Usluge dostupne s interneta, VPN, vatrozid, poslužitelji e-pošte |
| Interna mreža i identiteti | Bočno kretanje, preuzimanje ovlasti, Active Directory i Entra ID |
| Web aplikacije i API-ji | Autentikacija, autorizacija, poslovna logika, ubacivanje koda, izloženi podaci |
| Mobilne aplikacije | Pohrana podataka na uređaju, komunikacija s poslužiteljem |
| Oblak | Konfiguracija računa, ovlasti, izloženi spremnici i tajne |
| OT i industrijski sustavi | Odvojenost od uredske mreže, uz poseban oprez zbog sigurnosti ljudi i procesa |
| Socijalni inženjering | Phishing, telefonske prijevare, fizički ulaz u prostor |
| Red team | Cjelovita, dugotrajna simulacija napadača i provjera otkrivanja i odgovora |
Metodologije
| Metodologija | Izdavač | Područje |
|---|---|---|
| OWASP Web Security Testing Guide | OWASP | Web aplikacije i API-ji |
| PTES | Zajednica stručnjaka | Opći tijek penetracijskog testa |
| OSSTMM | ISECOM | Mjerenje operativne sigurnosti |
| NIST SP 800-115 | NIST, rujan 2008. | Tehničko testiranje i procjena sigurnosti |
| TIBER-EU | ECB | Testovi vođeni prijetnjama u financijskom sektoru |
Metodologija određuje što se provjerava i kako se dokumentira. Pitajte izvođača kojom se metodologijom koristi i kako je primjenjuje na vaš opseg.
Opseg i pravila izvođenja
Prije testa potpisuje se dokument s pravilima izvođenja. Bez pisanog ovlaštenja test je neovlašteni pristup računalnom sustavu. Dokument sadrži:
- sustave, adrese, aplikacije i račune u opsegu, i ono što je izričito izvan opsega;
- dopuštene tehnike i zabrane, primjerice DDoS, brisanje podataka ili socijalni inženjering;
- vremenske prozore i kontakte za hitne slučajeve s obje strane;
- postupanje s osobnim i povjerljivim podacima pronađenima tijekom testa;
- uvjete za sustave trećih strana: pružatelj oblaka ili SaaS-a mora dopuštati test ili ga treba odobriti;
- način zaustavljanja testa ako dođe do poremećaja.
Faze penetracijskog testa
- Priprema i opseg: ciljevi, pravila izvođenja, pristupni podaci za grey box test.
- Izviđanje: javni podaci, domene, izložene usluge, tehnologije.
- Skeniranje i analiza: otkrivanje ranjivosti i pogrešnih konfiguracija.
- Iskorištavanje: kontrolirani pokušaj iskorištavanja odabranih slabosti, uz najmanji mogući utjecaj na produkciju.
- Nakon iskorištavanja: koliko daleko napadač može doći, koje podatke vidi, može li preuzeti ovlasti. Svi alati i računi napravljeni tijekom testa uklanjaju se.
- Izvještaj i prezentacija: nalazi s dokazima, ocjenom i preporukama, zasebno za upravu i tehnički tim.
- Ponovni test: provjera da su nalazi stvarno zatvoreni.
Trajanje ovisi o opsegu: test jedne web aplikacije razlikuje se od testa cijele interne mreže ili red team vježbe.
Provjera ranjivosti: postupak
- Popis imovine i određivanje kritičnih sustava.
- Skeniranje izvana i iznutra, s autentikacijom gdje je moguće, jer se tada vide i nedostajuće zakrpe.
- Provjera nalaza i uklanjanje lažno pozitivnih.
- Ocjena i određivanje prioriteta.
- Dodjela nalaza vlasnicima sustava s rokovima.
- Ponovno skeniranje i praćenje do zatvaranja.
Vrste alata
| Vrsta alata | Namjena | Primjeri otvorenog koda |
|---|---|---|
| Mrežni skeneri | Otvoreni portovi, usluge i poznate ranjivosti | Nmap, OpenVAS (Greenbone) |
| Skeneri web aplikacija | Ranjivosti web aplikacija i API-ja | OWASP ZAP |
| Skeneri kontejnera i infrastrukture kao koda | Ranjive komponente i pogrešne postavke | Trivy |
| Komercijalne platforme | Upravljanje ranjivostima na većem broju sustava, izvještaji | Više proizvođača |
Alat pronalazi kandidate za nalaze. Provjera, procjena utjecaja i povezivanje nalaza u scenarij napada ostaju posao stručnjaka.
Kako ocijeniti i prioritizirati nalaze
CVSS v4.0, sustav ocjenjivanja organizacije FIRST, dodjeljuje ranjivosti ocjenu od 0 do 10:
| Ocjena | Ozbiljnost | Primjer |
|---|---|---|
| 9,0 do 10,0 | Kritična | Udaljeno izvršavanje koda bez autentikacije na sustavu dostupnom s interneta |
| 7,0 do 8,9 | Visoka | Preuzimanje administratorskih ovlasti, ubacivanje SQL koda |
| 4,0 do 6,9 | Srednja | Cross-site scripting, curenje osjetljivih informacija |
| 0,1 do 3,9 | Niska | Informativni nalazi, manje pogrešne konfiguracije |
Sama ocjena nije dovoljna za redoslijed rada. Prioritet povećavaju:
- aktivno iskorištavanje: CISA vodi popis aktivno iskorištavanih ranjivosti (KEV);
- izloženost: sustav dostupan s interneta ili s mnogo korisnika;
- poslovni učinak: kritični sustav ili osjetljivi podaci;
- lanac napada: nalaz koji zajedno s drugim vodi do potpune kompromitacije.
Za orijentaciju o rokovima: CISA saveznim agencijama propisuje uklanjanje ranjivosti s KEV popisa u dva tjedna, a za ranjivosti s CVE oznakom iz razdoblja prije 2021. u šest mjeseci (BOD 22-01). Tvrtka interne rokove određuje prema riziku i dokumentira iznimke.
Izvještaj koji se može koristiti
- Sažetak za upravu: najvažniji rizici, mogući poslovni učinak i preporučeni prioriteti, bez tehničkog žargona.
- Tehnički nalazi: opis, dokaz, pogođeni sustavi, ocjena, koraci za ponavljanje i preporuka za ispravak.
- Opseg i ograničenja: što je testirano, u kojem razdoblju i što nije bilo moguće provjeriti.
- Plan otklanjanja: vlasnik, rok i način provjere za svaki nalaz.
- Ponovni test: status svakog nalaza nakon popravka.
Za dokaze prema revizoru ili nadležnom tijelu važni su opseg, datum, neovisnost izvođača i dokaz da su nalazi zatvoreni. Izvještaj sadrži osjetljive informacije i treba ga čuvati uz ograničen pristup.
Učestalost prema riziku
| Aktivnost | Okvirna učestalost |
|---|---|
| Automatsko skeniranje sustava dostupnih s interneta | Kontinuirano ili tjedno |
| Provjera ranjivosti internih sustava | Mjesečno ili tromjesečno |
| Penetracijski test kritičnih sustava | Najmanje godišnje, i obavezno godišnje za financijske subjekte prema DORA-i |
| Test nakon veće promjene | Nova aplikacija, migracija u oblak, nova mreža ili spajanje tvrtki |
| Red team ili TLPT | Prema riziku; prema DORA-i najmanje svake tri godine za određene subjekte |
Učestalost se određuje prema procjeni rizika, kako traži mjera 5.8. Uredbe. Tvrtka s jednom statičnom web stranicom ne treba isti ritam kao banka s mobilnom aplikacijom.
Unutarnji tim ili vanjski izvođač
| Unutarnji tim | Vanjski izvođač | |
|---|---|---|
| Prednost | Stalna dostupnost, poznavanje sustava | Neovisnost i svjež pogled |
| Rizik | Sukob interesa i slijepe točke | Ograničeno vrijeme i poznavanje okoline |
| Najbolja uporaba | Kontinuirana provjera ranjivosti | Periodični penetracijski testovi i red team |
Česta kombinacija je unutarnja provjera ranjivosti i vanjski penetracijski test. DORA traži neovisnost i kod unutarnjih testova (čl. 24. st. 4.).
Kako odabrati izvođača
- iskustvo s vašom vrstom sustava: web aplikacije, oblak, OT;
- priznata metodologija i primjer anonimiziranog izvještaja;
- stručne certifikacije testera i, za TLPT, ispunjavanje uvjeta iz čl. 27. DORA-e;
- jasna pravila izvođenja i postupak za hitne slučajeve;
- osiguranje od profesionalne odgovornosti;
- uključen ponovni test nakon popravka;
- postupanje s podacima pronađenima tijekom testa i ugovor o obradi podataka kada je potreban.
Što određuje opseg i cijenu
Cijena ovisi o broju i vrsti sustava, dubini testa (black, grey ili white box), broju korisničkih uloga u aplikaciji, uključenom ponovnom testu i zahtjevima za izvještaj. Usporediti ponude ima smisla tek kada je opseg isti. Prenizak opseg za kritičan sustav daje izvještaj koji ne pokazuje stvaran rizik.
Česta pitanja
Koja je razlika između penetracijskog testa i provjere ranjivosti?
Provjera ranjivosti pronalazi i ocjenjuje poznate slabosti, uglavnom alatima. Penetracijski test ručno pokušava iskoristiti slabosti i pokazati do kojih podataka ili ovlasti napadač može doći. Provjera je šira i češća, test dublji i rjeđi.
Je li penetracijski test obvezan prema NIS2?
Zakon i Uredba ne propisuju godišnji penetracijski test za sve. Redovita provjera ranjivosti svih sustava obvezna je na svim razinama, a potrebu i učestalost penetracijskih testova subjekt određuje prema procjeni rizika i mora je moći obrazložiti (mjera 5.8.). Za financijske subjekte DORA traži godišnje testove sustava za ključne funkcije.
Koliko često treba raditi penetracijski test?
Za kritične sustave razumno je najmanje godišnje i nakon svake veće promjene. Provjera ranjivosti treba biti znatno češća, a sustavi dostupni s interneta skeniraju se kontinuirano.
Može li penetracijski test oštetiti sustave?
Postoji mali rizik poremećaja, osobito kod starih ili osjetljivih sustava. Smanjuje se pravilima izvođenja, testiranjem izvan radnog vremena, isključivanjem rizičnih tehnika i kontaktom za hitno zaustavljanje. OT sustavi traže poseban oprez.
Mora li test provesti certificirani stručnjak?
Propisi ne traže određeni certifikat za obične penetracijske testove. Reviziju prema Zakonu provode revizori s nacionalnim sigurnosnim certifikatom ili odgovarajućim europskim certifikatom, a provoditelji TLPT-a moraju ispuniti uvjete iz čl. 27. DORA-e.
Znači li izvještaj bez kritičnih nalaza da smo sigurni?
Ne. Izvještaj vrijedi za opseg, metode i razdoblje testa. Nove ranjivosti, promjene sustava i neprovjerena područja ostaju izvan njega.
Smijemo li testirati sustave u oblaku?
Ovisi o pravilima pružatelja. Većina velikih pružatelja dopušta testiranje vlastitih resursa uz određena ograničenja, ali ne i napade na njihovu infrastrukturu. Provjerite pravila prije testa i navedite ih u pravilima izvođenja.
Što ako test otkrije kritičnu ranjivost?
Dobar izvođač kritičan nalaz javlja odmah, a ne tek u završnom izvještaju. Tvrtka procjenjuje je li ranjivost već iskorištena, primjenjuje privremenu zaštitu ili zakrpu i nakon popravka traži ponovni test.
Sljedeći korak
Penetracijsko testiranje web aplikacija, mreže i oblaka, s pravilima izvođenja, izvještajem i ponovnim testom, provodimo kroz uslugu penetracijskog testiranja. Program provjere ranjivosti i dokaze za reviziju i samoprocjenu postavljamo u sklopu usluga kibernetičke sigurnosti. Kako napadači iskorištavaju ranjivosti pokazuje vodič Ransomware.
Izvori i pregled
Pregledano 4. studenoga 2026. prema sljedećim izvorima:
- Zakon o kibernetičkoj sigurnosti, NN 14/2024, čl. 30. do 35.
- Uredba o kibernetičkoj sigurnosti, NN 135/2024, Prilog II.
- Uredba (EU) 2022/2554 (DORA), čl. 24. do 27.
- Delegirana uredba (EU) 2025/1190 o TLPT-u
- ECB: TIBER-EU
- FIRST: CVSS v4.0 Specification
- CISA: BOD 22-01 i popis aktivno iskorištavanih ranjivosti
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- Kazneni zakon, NN 125/2011, čl. 266.
Vodič daje opće informacije. Opseg i učestalost testiranja određuju se prema procjeni rizika, kategoriji subjekta i kritičnosti sustava.
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.