Procjena ranjivosti traži i prioritizira slabosti; penetracijski test kontrolirano pokušava potvrditi može li ih napadač iskoristiti i do kakvog učinka. Organizaciji su često potrebna oba pristupa, ali niti jedan nije potvrda da sustav „nema ranjivosti”. Vrijednost testa ovisi o opsegu, ovlaštenju, kvaliteti izvedbe i zatvaranju nalaza.
Ključne činjenice
- Automatsko skeniranje daje širinu, a penetracijski test dodaje ručnu provjeru, poslovni kontekst i lančano povezivanje slabosti.
- Članak 21. stavak 2. točka (f) NIS2-a traži politike i postupke za procjenu učinkovitosti mjera; ne propisuje da svaka organizacija mora provesti jedan godišnji pentest.
- Hrvatska Uredba o kibernetičkoj sigurnosti traži periodične ili redovite provjere ranjivosti, dok se potreba, vrsta i učestalost penetracijskog, red-team ili sličnog testiranja određuju prema procjeni rizika.
- Test mora imati pisano ovlaštenje, točan opseg, pravila izvođenja, kontakt za zaustavljanje i dogovoreno postupanje s podacima.
- Nalaz nije zatvoren primjenom popravka, nego provjerom da je rizik uklonjen ili svjesno prihvaćen uz dokumentirano obrazloženje.
Procjena ranjivosti i penetracijski test nisu isto
| Element | Procjena ranjivosti | Penetracijski test |
|---|---|---|
| Primarni cilj | Otkriti poznate slabosti, nedostajuće zakrpe i pogrešne konfiguracije | Potvrditi ostvariv put napada i njegov mogući učinak |
| Način rada | Automatizirano skeniranje uz provjeru i kontekst analitičara | Pretežno ručno, ciljano i kontrolirano testiranje uz pomoć alata |
| Pokrivenost | Šira i pogodna za češće ponavljanje | Dublja, ali ograničena dogovorenim ciljem i vremenom |
| Rezultat | Popis potvrđenih i mogućih ranjivosti s prioritetima | Dokaziv scenarij napada, pogođeni resursi i preporuke |
| Glavno ograničenje | Lažno pozitivni nalazi i slabiji uvid u kombinirani učinak | Točkasti prikaz stanja; ne pokriva ono što nije u opsegu ili nije bilo moguće testirati |
Skeniranje ranjivosti nije isto što i samo pokretanje alata. Rezultate treba provjeriti, povezati s konkretnom imovinom i odvojiti stvarni rizik od nerelevantnih ili lažno pozitivnih nalaza. Pentest, s druge strane, nije dopuštenje za neograničeno „hakiranje”. Izvodi se prema unaprijed dogovorenim pravilima.
Koje testiranje odabrati
Vanjska infrastruktura
Test obuhvaća internetom dostupne adrese, domene, VPN, pristupna sučelja i druge izložene usluge. Cilj je provjeriti stvarnu napadačku površinu, autentikaciju, konfiguraciju i mogućnost dolaska do važnijih sustava.
Interna mreža i identiteti
Scenarij pretpostavlja kompromitirani uređaj ili korisnički račun. Provjerava segmentaciju, izloženost vjerodajnica, bočno kretanje i mogućnost povećanja ovlasti. Za produkciju se moraju posebno dogovoriti ograničenja aktivnosti koje bi mogle zaustaviti sustav ili promijeniti podatke.
Web-aplikacije i API-ji
Test prati poslovnu logiku, provjeru identiteta, autorizaciju, upravljanje sesijom, ulazne podatke i konfiguraciju. OWASP Web Security Testing Guide koristan je okvir, ali popis testova treba prilagoditi tehnologiji, ulozi korisnika i riziku aplikacije.
Mobilne, cloud i OT/industrijske okoline
Svaka traži poseban pristup. Cloud test mora poštovati pravila pružatelja i model podijeljene odgovornosti. Aktivno testiranje OT-a ili medicinskih uređaja u produkciji može imati sigurnosne i operativne posljedice pa se često prvo izvodi u reprezentativnom laboratoriju ili uz strogo ograničene tehnike.
Red team nije „veći pentest”
Pentest tipično provjerava dogovoreni opseg i tehničke ciljeve. Red team testira sposobnost organizacije da otkrije i zaustavi realističan cilj napada kroz više kanala; blue team brani, a purple team strukturirano povezuje napadačke i obrambene aktivnosti. Takva vježba ima smisla tek kada su osnovni nadzor, odgovor i pravila eskalacije dovoljno zreli.
Opseg i pravila izvođenja
Prije bilo kakvog aktivnog testa dokumentirajte:
- poslovni cilj i odluku koju će rezultat poduprijeti;
- točne IP raspone, domene, aplikacije, API-je, račune i okruženja u opsegu;
- vlasništvo sustava i ovlaštenje svih relevantnih strana;
- dopuštene i zabranjene tehnike, uključujući socijalni inženjering i uskraćivanje usluge;
- vrijeme izvođenja, očekivanu razinu opterećenja i prozor za hitne promjene;
- kontakt dostupan tijekom testa, kriterij trenutačnog zaustavljanja i postupak eskalacije;
- način korištenja stvarnih ili testnih podataka, mjesto pohrane dokaza i rok brisanja;
- ograničenja za dobavljače, cloud usluge i sustave izvan izravne kontrole naručitelja;
- oblik izvještaja, rokove odgovora na kritične nalaze i opseg ponovnog testa.
Bez pisanog ovlaštenja test može biti pravno i operativno rizičan. Popis IP adresa sam po sebi nije dovoljan dokaz da naručitelj smije odobriti test svakog sustava na tim adresama.
Postupak kvalitetnog testa
NIST SP 800-115 grupira aktivnosti u planiranje, izvođenje i aktivnosti nakon testa. U praksi ih je korisno razraditi ovako:
- Cilj i model prijetnje. Odredite kritičnu uslugu, vjerojatnog napadača i učinak koji želite provjeriti.
- Inventar i opseg. Potvrdite resurse, vlasnike, ovisnosti i isključenja. Ne pretpostavljajte da je evidencija imovine potpuna.
- Pravila izvođenja. Dogovorite ovlasti, sigurnosne granice, komunikaciju i čuvanje dokaza.
- Otkrivanje i analiza. Mapirajte napadačku površinu i provjerite ranjivosti uz kontrolu utjecaja na sustav.
- Kontrolirana potvrda. Eksploataciju izvedite samo do razine potrebne za dokaz cilja; izbjegnite nepotrebno preuzimanje podataka ili trajno zadržavanje pristupa.
- Čišćenje i potvrda stanja. Uklonite testne račune, datoteke i promjene te vlasniku prijavite sve što se ne može pouzdano vratiti.
- Izvještaj i sanacija. Povežite tehnički dokaz s poslovnim učinkom, vlasnikom i preporučenom radnjom.
- Ponovna provjera. Potvrdite popravak i provjerite nije li promjena otvorila novi problem.
Kako prioritizirati nalaze
CVSS može pomoći opisati tehničku ozbiljnost ranjivosti, ali nije cijela procjena rizika. Prioritet treba uključiti najmanje:
- dostupnost sustava s interneta ili iz kompromitiranog segmenta;
- postoje li javni dokazi aktivnog iskorištavanja;
- potrebne ovlasti i složenost napada;
- osjetljivost podataka i važnost poslovne usluge;
- mogućnost lančanog povezivanja s drugim nalazima;
- djelotvornost postojećih kompenzacijskih kontrola;
- sigurnosni i operativni rizik samog popravka.
Univerzalni rok poput „svaki kritični nalaz u 48 sati” nije zadan NIS2-om. Organizacija može postaviti interne ciljeve, ali iznimka mora imati vlasnika, privremenu mjeru, rok ponovne procjene i svjesno prihvaćanje preostalog rizika.
Izvještaj koji se može koristiti
Dobar izvještaj ima dvije povezane razine.
Sažetak za upravu objašnjava cilj, granice testa, potvrđene scenarije, moguće posljedice, sustavne uzroke i odluke koje zahtijevaju resurse ili prihvaćanje rizika. Ne svodi se na broj „kritičnih” stavki.
Tehnički dio za svaki nalaz navodi pogođeni resurs, preduvjete, reproducibilni dokaz u primjerenoj mjeri, učinak, ocjenu i obrazloženje rizika, preporučeni popravak, vlasnika i status ponovne provjere. Taj dokument sadrži osjetljive informacije i treba imati ograničen pristup, primjereno šifriranje i rok čuvanja.
Za NIS2 dokazni trag čuvajte odobreni opseg, pravila izvođenja, izvještaj, odluke o prioritetima, plan sanacije, prihvaćene iznimke i rezultate ponovnog testa. Sam certifikat izvođača ne dokazuje učinkovitost vaših mjera.
Učestalost prema riziku, ne kalendaru
Procjena rizika treba odrediti ritam za svaki dio imovine. Razlozi za novo ili ranije testiranje uključuju:
| Okidač | Primjeren odgovor |
|---|---|
| Nova javna aplikacija ili velika promjena autentikacije | Test prije puštanja ili prije širenja na sve korisnike |
| Kritična nova ranjivost na korištenoj i izloženoj tehnologiji | Ciljana provjera izloženosti i popravka |
| Akvizicija, migracija u oblak ili promjena mrežne arhitekture | Ponovna procjena napadačke površine i granica povjerenja |
| Sigurnosni incident | Test hipoteze o temeljnom uzroku nakon stabilizacije i prije zatvaranja korektivnih mjera |
| Istek prethodno prihvaćene iznimke | Ponovna procjena rizika i kontrola |
| Redoviti ciklus za stabilnu kritičnu uslugu | Opseg i interval određeni rizikom, promjenama i prethodnim nalazima |
Mjesečno skeniranje i godišnji pentest mogu biti razuman interni raspored za određenu okolinu, ali nisu univerzalni minimum. Visoko promjenjiva javna aplikacija može trebati češće automatizirane provjere i testove vezane uz izdanje, dok stabilan izolirani sustav zahtijeva drukčiji pristup.
NIS2 i hrvatska pravila
NIS2 članak 21. stavak 2. točka (f) navodi politike i postupke za procjenu učinkovitosti mjera upravljanja kibernetičkim rizicima. Pentest je jedan mogući dokaz, ali nije jedini: koriste se i provjere konfiguracije, skeniranje, siguran razvoj, vježbe, revizije, testovi oporavka i praćenje operativnih pokazatelja.
Hrvatska Uredba o kibernetičkoj sigurnosti konkretnije traži mehanizme periodične ili redovite provjere ranjivosti. Prema mjeri 5.8., subjekt na temelju procjene rizika utvrđuje potrebu, učestalost i vrstu sigurnosnog testiranja, uključujući penetracijske, red-team ili purple-team aktivnosti. Mjera 5.7. za vlastito razvijena rješenja navodi više mogućih mehanizama, poput SAST-a, DAST-a, provjere komponenti i internog ili vanjskog pentesta.
Propis, dakle, ne podupire tvrdnju da samo vanjski godišnji pentest „ispunjava NIS2”. Potrebno je pokazati cjelovit, razmjeran i ponovljiv proces. Za određivanje opsega i dokumentiranje tog procesa pogledajte usluge kibernetičke sigurnosti.
Kako odabrati izvođača
Tražite relevantno iskustvo za tehnologiju u opsegu, imenovane testere, jasnu metodologiju, osiguranje odgovornosti, sigurno postupanje s podacima, kvalitetan primjer anonimiziranog izvještaja i uključen ponovni test. Certifikati mogu biti koristan signal znanja, ali nisu zamjena za reference, kvalitetu opsega i sposobnost jasnog objašnjenja nalaza.
Neovisnost je posebno važna kada rezultat služi formalnom uvjerenju ili nadzoru. Interni tim ipak može vrijedno i često testirati sustave, pod uvjetom da su sukobi interesa i ovlasti jasno uređeni. Potreba za vanjskom stranom ovisi o svrsi, riziku i primjenjivim zahtjevima.
Česta pitanja
Može li pentest zaustaviti produkciju?
Može, osobito kod nestabilnih ili osjetljivih sustava. Zato se utjecaj ne smije obećati kao „nula”. Rizik se smanjuje pravilima izvođenja, sigurnim prozorom, prethodnim kopijama, nadzorom i jasnim prekidnim kriterijem.
Znači li čist izvještaj da smo sigurni?
Ne. Rezultat vrijedi za testirani opseg, vrijeme, identitete, tehnike i dostupne informacije. Nepokrivena imovina, nova ranjivost ili promjena konfiguracije može promijeniti zaključak.
Treba li testirati nakon popravka?
Da, za nalaze čije zatvaranje ovisi o tehničkoj promjeni. Ponovni test treba potvrditi izvorni problem i provjeriti relevantne nuspojave, a ne samo prihvatiti snimku zaslona kao dokaz.
Koliko košta penetracijski test?
Cijena bez opsega nije usporediva. Ovisi o broju i vrsti ciljeva, ulogama, dubini, produkcijskim ograničenjima, socijalnom inženjeringu, putovanju, izvještaju i ponovnom testu. Ponude treba uspoređivati prema jednako definiranom opsegu.
Povezani vodiči
Izvori i pregled
Sadržaj je stručno pregledan 8. kolovoza 2026. prema sljedećim primarnim i službenim izvorima:
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
- OWASP Web Security Testing Guide
- Uredba o kibernetičkoj sigurnosti, NN 135/2024 — osobito mjere 5.7. i 5.8.
- Direktiva (EU) 2022/2555 — članak 21.
- FIRST — CVSS v4.0 Specification
Ovaj vodič ne daje ovlaštenje za testiranje tuđih sustava. Svaki aktivni test mora imati valjanu suglasnost i pravila prilagođena konkretnom okruženju.
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.