Većina organizacija zna za sustave koji moraju biti javno dostupni. Web stranica, VPN, korisnički portal ili drugi poslovni servis imaju jasan razlog zašto im se može pristupiti s interneta. Veći problem mogu biti sustavi za koje se više nitko ne sjeća da su dostupni.

Infrastruktura se s vremenom mijenja. Postavi se novi server, dobavljaču se omogući udaljeni pristup, otvori testno okruženje ili se privremeno omogući administracija izvana. Aplikacija se kasnije preseli, dobavljač se promijeni ili projekt završi, ali dio stare konfiguracije ostane. Nakon nekoliko godina ono što organizacija misli da ima izloženo internetu i ono što je stvarno dostupno više ne mora biti isto.

Privremeni pristup lako postane trajan

Ne mora se raditi o serveru koji je netko zaboravio prije deset godina. Dovoljno je administracijsko sučelje mrežnog uređaja, stara VPN usluga, testna aplikacija ili udaljeni pristup koji je trebao biti privremen. Takvi sustavi često nisu dio svakodnevnog rada pa mogu dugo ostati izvan fokusa. Produkcijsku aplikaciju netko koristi svaki dan, dok stari servis može ostati dostupan bez da ga itko primijeti. Sama dostupnost s interneta nije sigurnosni propust. Mnogi servisi moraju biti javno dostupni da bi poslovanje funkcioniralo. Bitno je treba li određeni servis biti dostupan, koristi li se još uvijek i je li sigurno konfiguriran. VPN koji organizacija svakodnevno koristi ima opravdan razlog biti izložen. Administracijsko sučelje uređaja koje je ostalo otvoreno nakon intervencije dobavljača vjerojatno nema.

Dokumentacija i stvarno stanje nisu uvijek isti

Slično vrijedi za testna okruženja. Produkcijska aplikacija može se redovito održavati, dok stara testna instanca ostane dostupna na poddomeni nakon završetka projekta. Organizacija može uredno ažurirati servere, a previdjeti mrežni uređaj koji godinama radi bez većih promjena. Iz perspektive nekoga tko sustave traži izvana, nije važno nalazi li se nešto na službenom popisu IT imovine. Važno je može li mu se pristupiti. Zato ni uredan inventar ne mora uvijek odgovarati stvarnom stanju. Dokumentacija može zaostati za promjenama, privremena konfiguracija može ostati aktivna, a sustav koji se više ne koristi može nastaviti raditi. Takve razlike između dokumentiranog i stvarnog stanja lako se previde dok nema razloga detaljnije ih provjeravati.

Popis ranjivosti nije dovoljan

Sigurnosna procjena ranjivosti ne bi trebala završiti popisom verzija softvera i pronađenih CVE oznaka. Nalaz treba promatrati zajedno s njegovom izloženošću i ulogom sustava na kojem je pronađen. Ista ranjivost na javno dostupnom sustavu i na sustavu kojem se može pristupiti samo iz ograničenog dijela interne mreže nema nužno isti prioritet za organizaciju. Isto vrijedi za rezultate automatiziranih alata. Scanner može prijaviti velik broj potencijalnih ranjivosti, ali to ne znači da se svaki nalaz stvarno odnosi na konkretan sustav ili da je svaki jednako važan. Rezultat može ovisiti o detektiranoj verziji, konfiguraciji ili pretpostavkama koje alat sam ne može potvrditi. Dio nalaza zato zahtijeva dodatnu provjeru prije nego što se može zaključiti postoji li ranjivost i koliki rizik predstavlja.

Bez takve analize lako je upasti u ciklus u kojem se rezultat scannera tretira kao gotov plan rada. Organizacija popravi ono što je prijavljeno, ponovno pokrene skeniranje i dobije novu listu. Zatim ponovno kreće isti proces. Nova lista sama po sebi ne govori je li sustav sada bitno sigurniji niti jesu li prvo riješeni problemi koji predstavljaju najveći rizik. Vulnerability management nije pokušaj da rezultat svakog skeniranja bude potpuno prazan, nego proces u kojem treba razlikovati stvarne i primjenjive nalaze od tehničkog šuma te odrediti što treba riješiti prvo.

Sustav pritom ne mora sadržavati poznatu kritičnu ranjivost da bi predstavljao problem. Nepotrebno izložen servis, pogrešna konfiguracija ili pristup koji je odavno trebao biti uklonjen mogu biti jednako važni za stvarnu sigurnost okruženja. Zato neovisna sigurnosna analiza treba odgovoriti na više od pitanja što je scanner pronašao. Treba provjeriti što je stvarno izloženo, potvrditi relevantne nalaze i procijeniti njihov značaj u konkretnom okruženju.

AresISEC kroz Sigurnosnu procjenu ranjivosti provjerava sustave, aplikacije i infrastrukturu kako bi identificirao sigurnosne slabosti i procijenio ih u kontekstu stvarnog okruženja. Cilj nije dobiti što dulji popis nalaza, nego utvrditi što predstavlja relevantan rizik i što ima smisla prvo riješiti.

Provjerite ono što mislite da znate

Dobar prvi korak može biti jednostavna interna provjera. Usporedite popis sustava za koje vjerujete da su dostupni s interneta sa stvarnim stanjem. Provjerite postoje li testna okruženja, stari sustavi, pristupi vanjskih dobavljača ili konfiguracije koje su prvotno trebale biti privremene. Ako ne možete sa sigurnošću objasniti zašto je neki sustav ili servis dostupan s interneta, vrijedi provjeriti treba li još uvijek biti.

Problem nije servis koji s razlogom mora biti dostupan s interneta. Problem je onaj za koji više nitko ne zna zašto je još uvijek tamo.

• CISA – Internet Exposure Reduction Guidance
• NCSC – Carry out assessments by triaging and prioritising
• NCSC – Vulnerability management

Kad organizacija počne provjeravati koliko je stvarno spremna za NIS2, početna slika često izgleda sasvim dobro. Postoji firewall, backup se radi redovito, MFA je uključen, zaposlenici prolaze sigurnosne edukacije, a za incidente se zna koga treba nazvati. Većina tih stvari nije uvedena zbog NIS2, nego zato što su tijekom godina postale dio normalnog rada. I to je dobra početna pozicija.

Problem nastaje kada se s pitanja “imate li to?” prijeđe na “kako je to kod vas stvarno provedeno?”. NIS2 ne svodi upravljanje kibernetičkim rizicima na posjedovanje određenih sigurnosnih proizvoda ili nekoliko napisanih procedura. Među područjima koja obuhvaća nalaze se upravljanje incidentima, kontinuitet poslovanja i oporavak, sigurnost dobavljačkog lanca, upravljanje ranjivostima, kontrola pristupa, edukacija te provjera učinkovitosti uvedenih mjera. Zato dvije organizacije koje na osnovnoj checklisti imaju gotovo sve označeno mogu u praksi biti na vrlo različitoj razini spremnosti.

Uzmimo MFA. Tvrtka ga koristi za Microsoft 365 i VPN pa će sasvim opravdano reći da ima višefaktorsku autentikaciju. Ali što je s administratorskim računima? Postoje li stari sustavi koji je ne podržavaju? Ima li iznimaka i zna li se zašto postoje? Ako kompromitirani administratorski račun i dalje može otvoriti put prema važnom dijelu infrastrukture bez dodatne provjere, sama činjenica da organizacija “ima MFA” ne govori dovoljno o stvarnom riziku.

S ranjivostima se događa nešto slično. Organizacija može svaki mjesec pokrenuti vulnerability scanner i uredno spremiti izvještaj. Puno je važnije što se događa poslije. Ako se isti ozbiljan nalaz pojavljuje šest mjeseci zaredom jer nitko nije odredio vlasnika, rok ili način sanacije, skeniranje postoji, ali proces upravljanja ranjivostima očito ima rupu. Ponekad se problem ne može odmah ukloniti i to je realnost svakog IT okruženja. Tada treba znati koliki rizik ostaje, može li se privremeno smanjiti i tko je donio odluku da se s njim nastavi živjeti.

Dobavljači su područje u kojem se stvarno stanje također lako izgubi iz vida. Organizacija zna tko joj održava infrastrukturu, gdje joj je hosting i koje cloud ili SaaS usluge koristi, ali to ne znači da ima dobar pregled njihovih pristupa i ovisnosti koje su se s vremenom stvorile. Vanjski IT možda ima administratorske račune, dobavljač aplikacije udaljeni pristup produkciji, a poslovno važan sustav može ovisiti o usluzi nad kojom organizacija nema izravnu kontrolu. Ako takav dobavljač ima sigurnosni incident, pitanje više nije samo koliko je siguran on, nego što njegov incident može napraviti vašem poslovanju.

Kod incidenata se razlika između pretpostavljene i stvarne spremnosti obično vidi još brže. U manjoj organizaciji često svi znaju koga treba nazvati ako nešto pođe po zlu. Takav način rada može sasvim dobro funkcionirati kod manjih problema. Kod ozbiljnog incidenta odjednom treba odlučiti što izolirati, koje sustave ostaviti dostupnima, koje podatke sačuvati, tko vodi tehnički dio odgovora, tko komunicira prema upravi i postoji li obveza prijave incidenta. Ako se sve oslanja na jednu osobu koja “zna kako stvari rade”, plan zapravo postoji samo dok je ta osoba dostupna.

Ni backup sam po sebi ne daje odgovor na pitanje koliko je organizacija spremna za oporavak. Može se izvršavati svake noći i mjesecima prolaziti bez greške, a da nitko ne zna koliko bi stvarni povrat sustava trajao. Možda se baza može vratiti, ali aplikacija ovisi o drugom servisu koji nije uključen u plan. Možda su svi podaci dostupni, ali nije određeno što se vraća prvo. Tek kada se takve stvari provjere, može se govoriti o stvarnoj sposobnosti oporavka, a ne samo o postojanju backupa.

Upravo zato kod NIS2 spremnosti dokazi nisu zanimljivi samo zbog buduće provjere ili samoprocjene. Oni organizaciji daju puno praktičniji odgovor na pitanje funkcioniraju li njezine sigurnosne mjere onako kako pretpostavlja. Rezultat recovery testa govori više od same tvrdnje da postoji backup. Evidencija pregleda privilegiranih računa pokazuje da se pristupi zaista pregledavaju. Zatvoreni nalazi pokazuju da vulnerability scanning završava sanacijom, a ne PDF izvještajem koji će netko spremiti u mapu. Za to nije potrebno izmišljati novu NIS2 dokumentaciju ako odgovarajući trag već nastaje kroz svakodnevni rad.

Hrvatski okvir za NIS2 također razlikuje dokumentiranost sigurnosnih mjera od njihove implementacije. To je važna razlika jer organizacija može imati vrlo urednu proceduru koju u praksi nitko ne slijedi, ali može postojati i obrnuta situacija. Neka sigurnosna praksa možda već godinama dobro funkcionira, samo nije dovoljno uređena ili dokumentirana. GAP analiza treba razlikovati te situacije, a ne ih sve svesti na istu oznaku “nedostaje”.

Kod AresISEC NIS2 GAP analize spremnosti zato ne gledamo samo postoji li određena politika, procedura ili sigurnosna tehnologija. Provjeravamo kako je mjera stvarno provedena i što se može potvrditi iz dostupnih informacija i dokaza. Cilj nije izdati certifikat niti pravno mišljenje da je organizacija “NIS2 compliant”, nego dobiti realnu sliku postojećeg stanja i utvrditi gdje postoji razlika između onoga što organizacija smatra riješenim i onoga što je stvarno uspostavljeno.

Takvu provjeru ima smisla napraviti prije formalne samoprocjene ili druge provjere, dok još postoji vrijeme za rješavanje pronađenih nedostataka. Ne mora rezultat biti deset novih politika i još jedan sigurnosni alat. Nekad treba urediti proces koji već postoji, zatvoriti tehnički nedostatak, jasno odrediti odgovornost ili konačno provjeriti radi li nešto što se godinama uzimalo zdravo za gotovo.

Zato je kod pripreme za NIS2 korisnije krenuti od stvarnog okruženja nego od checkliste. Pitanje nije samo imate li neku sigurnosnu mjeru. Pitanje je možete li pokazati kako je provedena i radi li kada je stvarno potrebna.

Izvori:

European Union – Directive (EU) 2022/2555 (NIS2 Directive)

Narodne novine – Zakon o kibernetičkoj sigurnosti, NN 14/2024

Narodne novine – Uredba o kibernetičkoj sigurnosti, NN 135/2024

Jedno od prvih pitanja tijekom ISO 27001 GAP analize često je postoji li određena politika ili procedura. Dokument postoji, odobren je, ima vlasnika, verziju i datum posljednje izmjene. U njemu piše da se korisnički pristupi redovito pregledavaju, da se sigurnosni incidenti evidentiraju, da se backup testira i da se pristupi ukidaju kada zaposlenik napusti organizaciju. Na papiru sve izgleda dobro. Problem nastaje kada se postavi sljedeće pitanje: kada je posljednji put napravljen pregled korisničkih prava? Ako organizacija ne može pokazati kada je pregled proveden, tko ga je napravio i što je nakon njega promijenjeno, postojanje politike ne govori nam provodi li se proces koji ona opisuje.

To je jedna od važnijih razlika između ISO 27001 dokumentacije i ISMS-a koji stvarno funkcionira. Dokumentacija određuje pravila, ali provedba tih pravila mora biti vidljiva u stvarnom radu organizacije. Organizacija, primjerice, može imati dobro napisanu politiku prema kojoj se prava korisnika periodički pregledavaju, ali tijekom provjere otkrije se da je posljednji formalni pregled napravljen prije dvije godine. U međuvremenu su zaposlenici mijenjali radna mjesta, projekti su završavali, uvedene su nove aplikacije, a prava koja više nisu bila potrebna ostala su aktivna. Politika u tom slučaju nije nužno problem. Problem je razlika između onoga što je organizacija propisala i onoga što stvarno radi.

Isto vrijedi za druge dijelove ISMS-a. Procedura za upravljanje sigurnosnim incidentima može detaljno opisivati prijavu, klasifikaciju i eskalaciju incidenta, ali ako se sigurnosni događaji rješavaju kroz telefonske pozive i poruke bez ikakve evidencije, kasnije je teško pokazati kako je incident obrađen, koje su odluke donesene i jesu li iz njega proizašle neke promjene. Backup može biti uredno definiran internom procedurom i izvršavati se svake noći, a izvještaji mogu mjesecima pokazivati uspješno izvršavanje. To još uvijek nije isto što i dokaz da organizacija može vratiti sustav kada joj stvarno zatreba. Ako je posljednji restore test napravljen prije nekoliko godina ili nitko ne zna koliko bi trajao oporavak ključnog sustava, postoji razlika između dokaza da se backup izrađuje i dokaza da proces oporavka funkcionira. Kod dobavljača se isti problem pojavljuje na drugi način. Organizacija može imati proceduru prema kojoj se prije angažiranja dobavljača procjenjuju sigurnosni zahtjevi. Ako postoji samo popis dobavljača, ali nema traga o tome tko je procijenjen, prema kojim kriterijima i što je napravljeno kada je pronađen rizik, teško je zaključiti da se definirani proces stvarno provodi.

Zbog toga tijekom ISO 27001 GAP analize nije dovoljno pitati samo “imate li ovo?”. Treba pogledati što se iza toga stvarno događa. AresISEC kod takve analize ne promatra samo postoji li politika, procedura ili drugi dokument. Važno je utvrditi postoji li proces koji dokument opisuje i postoji li odgovarajući trag njegove provedbe. Taj trag ne mora uvijek biti novi dokument napravljen posebno zbog ISO 27001. Ako se pregled pristupa već provodi kroz postojeći IT sustav, dokaz može biti zapis tog pregleda i promjena koje su nakon njega napravljene. Ako se testira oporavak, to mogu biti rezultati testa. Ako se održava sigurnosna obuka, postojeći zapisi mogu pokazati kada je održana i tko je sudjelovao. Ako se dobavljači već procjenjuju u sklopu nabave, nema smisla stvarati paralelan proces samo kako bi postojao “ISO dokaz”.

To je posebno važno u organizacijama koje već imaju razvijene sigurnosne prakse. ISO 27001 implementacija ne bi trebala značiti da se postojeći način rada odbacuje i zamjenjuje hrpom novih Word i Excel dokumenata. Ako proces već postoji i funkcionira, prvo treba utvrditi zadovoljava li potrebe ISMS-a i može li se njegova provedba dokazati. Tek tada ima smisla određivati što treba promijeniti. Postoji i druga strana problema. Ako tijekom GAP analize određeni dokaz nije dostupan, to ne znači automatski da se aktivnost nikada nije provodila. Možda se provodi, ali se rezultati ne evidentiraju. Možda dokaz postoji u sustavu kojem osoba uključena u analizu nema pristup. Možda je proces neformalan i ovisi o jednoj osobi koja ga provodi godinama, ali nikada nije definiran na način koji bi organizaciji omogućio da ga pouzdano ponovi. Zato je važno razlikovati situaciju u kojoj kontrola nije implementirana od situacije u kojoj njezinu provedbu nije moguće potvrditi dostupnim dokazima.

Ta razlika nije važna samo zbog audita. Važna je samoj organizaciji. Ako sigurnosni proces funkcionira samo zato što jedna osoba zna što treba napraviti, organizacija ima problem čak i ako je ta osoba svaki put napravila sve ispravno. Ako nitko ne može utvrditi kada je posljednji put napravljen pregled pristupa, teško je znati je li sljedeći pregled zakasnio. Ako se incidenti ne evidentiraju, teško je kasnije prepoznati ponavljaju li se isti uzroci. Dokazi zato nisu administracija koju treba proizvoditi samo zbog certifikacijskog audita. Oni organizaciji omogućuju da zna provode li se vlastita pravila i daju li sigurnosne kontrole rezultat koji se od njih očekuje.

ISO/IEC 27001 upravo zato ne završava pisanjem politika. ISMS treba uspostaviti, provoditi, održavati i kontinuirano poboljšavati. Kada se ISO 27001 projekt previše usmjeri na izradu dokumentacije, vrlo je lako izgubiti tu razliku. Na kraju možete imati urednu mapu politika, procedura i registara, ali pitanje koje vrijedi postaviti ostaje vrlo jednostavno: možete li pokazati da ono što u njima piše stvarno radite?

Izvori:
ISO – ISO/IEC 27001:2022 Information security management systems

ISO – ISO/IEC TS 27008:2019 Guidelines for the assessment of information security controls

ISO – How to measure the effectiveness of information security

Ako danas pitate većinu organizacija kako se štite od ransomwarea, vrlo često ćete dobiti isti odgovor.

“Imamo backup.”

Prije nekoliko godina to je u velikom broju slučajeva bilo dovoljno. Napadač bi šifrirao poslužitelje, organizacija bi vratila podatke iz backupa i nastavila raditi.

Danas više nije tako. Ransomware grupe odavno su shvatile da je backup najveća prepreka ucjeni. Ako organizacija može vratiti podatke u nekoliko sati, razlog za plaćanje otkupnine gotovo nestaje. Zato suvremeni napadi više nisu usmjereni samo na produkcijske sustave. Sve češće ciljaju i backup infrastrukturu. Napadač ne želi samo šifrirati vaše podatke. Želi vam oduzeti mogućnost da ih vratite. Zato pitanje više nije imate li backup. Pitanje je može li backup preživjeti napad. Tu razliku mnoge organizacije otkriju tek kada bude prekasno.

Jedan od najčešćih scenarija izgleda sasvim uobičajeno. Napadač kompromitira korisnički račun, proširi pristup unutar mreže i dođe do administratorskih privilegija. Nakon toga više ga ne zanimaju korisnička računala. Traži Active Directory, virtualizacijsku infrastrukturu, backup servere i repozitorije. Ako backup koristi istu domenu, iste administratorske račune ili se nalazi u istoj mreži kao produkcijski sustavi, vrlo je vjerojatno da će postati dio istog incidenta.

U tom trenutku backup još uvijek postoji. Samo više nije dostupan. U praksi upravo to čini razliku između incidenta od nekoliko sati i incidenta koji traje danima ili tjednima. Nije neuobičajeno da napadači prije pokretanja ransomwarea danima istražuju infrastrukturu. Zanima ih kako je mreža organizirana, gdje se nalaze backup sustavi, koriste li administratori iste vjerodajnice i mogu li obrisati ili šifrirati backup kopije. Ako to otkriju prije nego što pokrenu ransomware, organizacija vrlo brzo ostaje bez mogućnosti brzog oporavka.

Zbog toga se sve više govori o izolaciji backup infrastrukture. To ne znači samo imati backup na drugom uređaju ili drugoj lokaciji. Izolacija znači da kompromitacija produkcijskog okruženja ne smije automatski značiti i kompromitaciju backupa. To podrazumijeva odvojene administratorske račune, ograničenu mrežnu komunikaciju, zasebne privilegije i, gdje god je moguće, immutable backup kopije koje nije moguće jednostavno izmijeniti ili obrisati. Cilj nije zakomplicirati administraciju, nego osigurati posljednju liniju obrane kada sve ostalo zakaže.

AresISEC u praksi često vidi organizacije koje ulažu značajna sredstva u kvalitetna backup rješenja, ali vrlo malo pažnje posvećuju njihovoj zaštiti. Backup radi, redovito se izvršava i izvještaji izgledaju uredno. Problem nastaje kada se pokaže da napadač do backup infrastrukture može doći gotovo jednako lako kao i administrator. To nije problem backup softvera. To je problem dizajna infrastrukture.

Dobar početak nisu novi alati ni nova licenca. Dobar početak su jednostavna pitanja.

Može li kompromitirani administratorski račun obrisati backup?

Koristi li backup ista pravila autentikacije kao produkcija?

Može li korisnik kompromitiran phishingom, uz dovoljno vremena, doći do backup infrastrukture?

Kada je posljednji put testiran potpuni oporavak cijelog sustava, a ne samo pojedinačne datoteke?

I možda najvažnije: koliko ste sigurni da će backup ostati netaknut ako ostatak infrastrukture bude kompromitiran?

Odgovori na ta pitanja često govore više o stvarnoj otpornosti organizacije nego popis tehnologija koje koristi. Takav pristup više nije samo preporuka sigurnosne struke. ISO 27001 zahtijeva odgovarajuće kontrole za backup, mogućnost oporavka i redovito testiranje kako bi organizacija mogla održati kontinuitet poslovanja. NIS2 dodatno naglašava važnost upravljanja backupovima, disaster recoveryja i operativne otpornosti kao dijela upravljanja kibernetičkim rizicima. Sve veću važnost ovom području daje i Cyber Resilience Act. Iako se najčešće spominje u kontekstu razvoja softvera, njegova je poruka šira. Organizacije koje razvijaju proizvode s digitalnim elementima morat će dokazati da je sigurnost ugrađena tijekom cijelog životnog ciklusa proizvoda. To uključuje upravljanje ranjivostima, sigurnosna ažuriranja i sposobnost pouzdanog oporavka nakon sigurnosnog incidenta. Većina odredbi CRA-a počet će se primjenjivati krajem 2027. godine, dok određene obveze, poput prijave aktivno iskorištenih ranjivosti i incidenata, dolaze ranije. Za dio organizacija to znači da backup i recovery više neće biti samo operativna odgovornost IT odjela, nego i regulatorni zahtjev.

Ransomware na kraju ne testira kvalitetu vašeg backup softvera. Testira način na koji je projektirana cijela infrastruktura. Backup koji napadač može jednako lako kompromitirati kao i produkciju nije posljednja linija obrane. On je samo još jedan sustav u istoj mreži.

Izvori:
CISA – Stop Ransomware Guide

ISO – ISO/IEC 27001 Information Security Management

European Union – NIS2 Directive

European Union – Cyber Resilience Act (Regulation (EU) 2024/2847)

Mnoge organizacije vjeruju da su zaštićene od ransomwarea jer imaju backup. To na prvi pogled zvuči logično. Backup poslovi se izvršavaju, storage postoji, retention je postavljen i svakog jutra netko vidi zelenu oznaku da je sve prošlo uspješno. To obično stvara osjećaj sigurnosti. Sve dok se nešto stvarno ne dogodi.

Problem je u tome što backup i recovery nisu ista stvar, iako ih mnogi tako doživljavaju. Backup odgovara na jedno pitanje: jesmo li spremili podatke? Ali ne odgovara na ono teže: možemo li sve vratiti kada cijelo okruženje bude pod pritiskom? Ta razlika postaje vrlo jasna tijekom ozbiljnog incidenta. U mnogim okruženjima backup se promatra kao tehnička stavka koja mora postojati. Sustav pokazuje da su backupovi uspješni, administratori vide da sve prolazi, a management pretpostavlja da je oporavak pokriven. No pravi problemi najčešće počinju tek kada treba vratiti sustav.

Jedan od scenarija koji se često viđa nakon ransomware incidenta jest da backup postoji, ali mu se više ne može vjerovati. Ne zato što backup nije radio, nego zato što ga je napadač dosegao. Ako je backup infrastruktura preblizu produkcijskom okruženju, koristi iste pristupne putanje ili ovisi o istim privilegiranim računima, vrlo lako postaje dio istog incidenta. Tada backup tehnički postoji. Ali više ne pomaže. Drugi problem nastaje kada restore prođe, ali sustav i dalje ne radi. Podaci se vrate, aplikacija se pokrene, ali nešto oko nje više ne odgovara. Certifikat je istekao. DNS zapis nedostaje. Integracija pokazuje na staru adresu. Verzija baze nije ista. Na papiru restore je uspješan. U stvarnosti poslovanje i dalje stoji. To je dio koji mnoge organizacije podcjenjuju. Recovery vrlo rijetko znači samo “vrati podatke”. Potrebno je vratiti i sve oko njih.

Vrijeme je još jedan problem o kojem se rijetko razmišlja dok ne postane stvaran. Vratiti nekoliko terabajta podataka zvuči jednostavno dok to ne trebaš napraviti pod pritiskom. Ono što na papiru izgleda kao šest sati, vrlo lako postane dva dana. A kada se radi o kritičnim sustavima, dva dana nisu samo downtime. To je izgubljeni prihod, izgubljeno povjerenje i dodatni pritisak. Tu često nastaje kaos. Što vraćate prvo? Mail? Domain controller? File server? ERP? Većina organizacija nema jasan odgovor dok ih incident ne prisili da ga donesu. Upravo tada gubi se najviše vremena.

U praksi AresISEC često vidi organizacije koje imaju tehnički ispravan backup, ali nemaju realnu sliku kako bi oporavak izgledao pod stvarnim pritiskom. Backup sam po sebi najčešće nije problem. Problem su pristupi, ovisnosti, vrijeme oporavka i redoslijed vraćanja sustava. Tu se najčešće vidi stvarni gap. Dobar početak nije kupnja novog backup rješenja. Dobar početak su jednostavna pitanja. Koliko je backup izoliran od produkcijskog okruženja? Tko ima pristup backup infrastrukturi? Koliko često testirate puni restore, a ne samo povrat pojedinačne datoteke?Koliko vam stvarno treba da vratite najkritičnije sustave? I ako više sustava padne odjednom, zna li tim što ide prvo? To nisu komplicirana pitanja, ali vrlo brzo pokažu postoji li stvaran recovery plan ili samo pretpostavka.

U mnogim slučajevima upravo male promjene rade najveću razliku. Odvajanje backup pristupa od glavnog okruženja, smanjenje privilegija, definiranje prioriteta oporavka i testiranje restore procesa u realnim uvjetima često donose više otpornosti nego dodavanje još jednog alata. Ovo je izravno povezano i sa širim sigurnosnim i regulatornim zahtjevima. U okviru ISO 27001, backup i oporavak nisu samo operativni zadaci. Oni su dio kontinuiteta poslovanja, dostupnosti sustava i otpornosti organizacije.  Kontrole vezane uz zaštitu backupova, mogućnost povrata podataka i redovito testiranje dio su održavanja funkcionalnog sustava upravljanja informacijskom sigurnošću. NIS2 ide korak dalje. Direktno traži mjere vezane uz upravljanje backupovima, disaster recovery i krizno upravljanje kao dio operativne otpornosti. To znači da oporavak više nije samo tehnička preporuka. Za mnoge organizacije postaje regulatorno očekivanje. U oba slučaja nije dovoljno samo imati backup. Očekivanje je da oporavak bude realan, testiran i sposoban podržati kontinuitet poslovanja kada sustavi zakažu.

Upravo tu mnoge organizacije otkrivaju razliku između onoga što postoji na papiru i onoga što stvarno funkcionira. Jer kada stvari krenu po zlu, vrijednost backupa ne mjeri se time postoji li, vec time koliko brzo vas vraća u redovno poslovanje.

Izvori:
CISA – Stop Ransomware Guide

ISO – ISO/IEC 27001 Information Security Management

European Union – NIS2 Directive

Moderne aplikacije i digitalni proizvodi danas prolaze kroz više razina provjere nego ikada prije. Code review je standardni dio razvoja, automatizirane sigurnosne provjere često su uključene u pipeline, a funkcionalno i sigurnosno testiranje postali su normalan dio release procesa.

Ipak, proizvodi koji prolaze takve provjere i dalje završavaju kompromitirani.

Razlog nije nužno u tome da sigurnosno testiranje ne postoji ili da razvojni timovi ignoriraju sigurnost. Problem je puno češće u tome što se sigurnost i dalje promatra preusko. Fokus ostaje na aplikaciji ili pojedinoj funkcionalnosti, dok stvarni napadni put često nastaje tek kada se promatra cijelo okruženje zajedno.

Aplikacija može imati siguran authentication flow, ali istovremeno otkrivati previše informacija kroz API odgovore. Može prolaziti interne sigurnosne provjere, a istovremeno imati deployment konfiguraciju koja izlaže debug informacije ili interne putanje. Može imati kvalitetnu validaciju unosa, ali uz to koristiti servise i integracije koje stvaraju neočekivani napadni put.

Upravo tu nastaje razlika između sigurnosti koda i sigurnosti proizvoda.

Jedan od obrazaca koji se redovito pojavljuje tijekom testiranja uključuje API-je koji tehnički rade ispravno, ali vraćaju više podataka nego što je potrebno. Endpoint vraća legitimne podatke za zahtjev, ali uz njih otkriva interne identifikatore, strukturu objekata ili način na koji su servisi povezani. Iz razvojne perspektive odgovor je ispravan. Iz perspektive napadača, to postaje alat za mapiranje sustava.

Slična situacija pojavljuje se kod autentikacije. Lozinke se validiraju, tokeni se ispravno obrađuju, sesije rade očekivano. No kada se više endpointa koristi zajedno, pojavljuje se mogućnost zaobilaženja ograničenja. Jedan endpoint potvrđuje postoji li korisnik, drugi dopušta previše pokušaja autentikacije, treći otkriva dodatni kontekst o računu. Svaki dio pojedinačno djeluje prihvatljivo. Zajedno stvaraju stvaran napadni put.

Konfiguracija i infrastruktura dodatno kompliciraju situaciju. Tijekom testiranja često se vidi da aplikacija sama po sebi nema ozbiljan problem, ali deployment okruženje otkriva interne informacije, environment varijable, reference na druge servise ili nepotrebno izložene administrativne funkcionalnosti.

Takve stvari često nisu problem razvoja aplikacije. Problem je što sigurnost proizvoda ne završava kodom.

U praksi AresISEC često vidi aplikacije koje prolaze interne sigurnosne provjere, ali i dalje imaju napadne putove koji postaju vidljivi tek kada se aplikacija, konfiguracija, infrastruktura i način korištenja promatraju zajedno.

Upravo zato sigurnost proizvoda danas postaje puno šira tema od samog testiranja aplikacije. To se sve više vidi i kroz regulatorne zahtjeve.

Cyber Resilience Act postupno uvodi obveze za proizvođače softvera i proizvoda s digitalnim elementima na razini cijele Europske unije. Većina zahtjeva počet će se primjenjivati krajem 2027. godine, dok obveze vezane uz prijavu aktivno iskorištenih ranjivosti i incidenata dolaze ranije. Regulativa će zahtijevati sustavan pristup sigurnosti proizvoda kroz cijeli životni ciklus, uključujući upravljanje ranjivostima, sigurnosna ažuriranja, dokumentaciju i procjenu rizika. Za organizacije koje razvijaju ili održavaju digitalne proizvode to znači da sigurnost više neće biti samo tehničko ili razvojno pitanje, nego i regulatorna obveza s potencijalno značajnim financijskim kaznama.

Cyber Resilience Act dodatno pomiče fokus sa same aplikacije na sigurnost proizvoda kroz cijeli životni ciklus. Za organizacije koje razvijaju softver ili proizvode s digitalnim elementima pitanje više neće biti samo prolazi li funkcionalnost testiranje, nego postoji li sustavan pristup sigurnosti tijekom dizajna, razvoja, implementacije, održavanja i upravljanja ranjivostima.

To mijenja način na koji se promatra sigurnost razvoja. Sigurnost više nije samo provjera pojedinog dijela sustava. Postaje pitanje načina na koji se cijeli proizvod ponaša u stvarnom okruženju i pod stvarnim uvjetima.

Ključna poanta nije da razvojni timovi ne rade sigurnosno testiranje. Većina ozbiljnih timova ga radi. Problem je u tome što nijedna pojedinačna provjera sama ne može pokriti sve perspektive.

Stvarna sigurnost proizvoda počinje tek kada se sustav promatra kao cjelina.

Izvori:
European Union – Cyber Resilience Act (Regulation (EU) 2024/2847)

OWASP – Web Security Testing Guide

OWASP – Top 10 Web Application Security Risks

NIST – Technical Guide to Information Security Testing and Assessment (SP 800-115)

U većini slučajeva napad ne počinje s tehničkim iskorištavanjem sustava. Ne počinje s exploitom niti s kompleksnim alatima. Počinje s pristupom. Najčešće kroz korisnički račun koji izgleda potpuno legitimno. Razlog je jednostavan. Korisnički računi su i dalje najlakša ulazna točka. Jedna lozinka korištena na više mjesta, jedan phishing mail ili jedan kompromitirani vanjski servis mogu biti dovoljni. Kada napadač dobije pristup računu, prvi korak ne izgleda kao napad. Login ide kroz standardni kanal. VPN, web aplikaciju, cloud servis. Nema očitog alarma. Aktivnost izgleda kao normalan korisnik. U tom trenutku ključno pitanje nije kako je račun kompromitiran, nego što taj račun može.

U praksi to vrlo brzo postane problem. Pristup mailu omogućuje reset drugih računa. Pristup SharePointu ili Driveu daje uvid u dokumente s internim informacijama. VPN pristup znači ulaz u internu mrežu. Pristup ticketing sustavu otkriva kako je IT organiziran i gdje se nalaze kritične točke. To nije ranjivost. To je normalno poslovno okruženje. Problem nastaje kada se takav pristup počne koristiti iz perspektive napadača.

Jedan od scenarija koji redovito vidimo tijekom testiranja počinje vrlo jednostavno. Korisnički račun ima pristup internom dokumentu. Dokument sadrži naming konvenciju servera, interne URL-ove i reference na servise. Iz toga se može prepoznati struktura sustava i identificirati ključni dijelovi okruženja, uključujući domensku infrastrukturu. Nakon toga testiranje postaje ciljano. Ako naming otkriva obrasce, traže se sustavi koji odgovaraju tim obrascima. Ako postoje reference na interne servise, ispituje se njihova dostupnost i konfiguracija. Ono što je na početku bio običan dokument postaje osnova za daljnje kretanje kroz sustav. Drugi čest scenarij uključuje file share. Korisnik ima pristup direktoriju u kojem se nalaze konfiguracijske datoteke. Jedna od njih sadrži connection string ili reference na drugi sustav. Time se otvara put prema dodatnom pristupu koji nije bio vidljiv izvan tog konteksta. Treći scenarij, koji je u praksi često najproblematičniji, uključuje lateralno kretanje unutar interne mreže. Kompromitirani korisnički račun ima VPN pristup. Nakon spajanja, napadač vidi interne servise koji nisu izloženi javno. Ako je segmentacija mreže/sustava slaba, moguće je pristupiti dodatnim sustavima bez posebnih ograničenja.

U takvim situacijama često se pokaže da jedan korisnički račun ima pristup na više servisa nego što bi trebao. Ponekad to uključuje i sustave povezane s autentikacijom ili upravljanjem korisnicima. Ne zato što je to planirano, nego zato što se pristupi kroz vrijeme šire, a rijetko se revidiraju. To je trenutak kada kompromitirani račun prestaje biti samo korisnički račun i postaje ulazna točka za širi napad. Važno je naglasiti da u svim tim scenarijima ništa nije “probijeno” na klasičan način. Pristup postoji, aktivnosti izgledaju legitimno i sustav se ponaša kako je dizajniran. Problem nije u jednoj grešci, nego u načinu na koji su pristupi i informacije raspoređeni.

Upravo u takvim situacijama AresISEC u praksi najčešće otkriva stvarnu izloženost. Ne kroz jednu kritičnu ranjivost, nego kroz povezivanje više manjih slabosti koje zajedno čine stvaran napadni put. Ključna stvar koju organizacije često podcjenjuju je da lozinka sama po sebi rijetko predstavlja problem. Problem je što ta lozinka otključava. Ako jedan korisnički račun omogućava pristup dokumentima, konfiguracijama i internim servisima bez jasnih ograničenja, tada njegova kompromitacija postaje početak puno većeg problema. Zato se sigurnost ne može svesti samo na jačinu lozinke ili MFA. To su važni elementi, ali ne rješavaju pitanje strukture sustava i stvarne izloženosti.

Stvarna sigurnost počinje razumijevanjem kako se sustav može koristiti na način koji nije bio planiran.

Izvori:
MITRE ATT&CK – Enterprise Matrix
Verizon – Data Breach Investigations Report