Security Blog

Kako jedan kompromitirani korisnički račun postaje ulaz u sustav

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

Znate li što jedan korisnički račun u vašem sustavu zapravo može dohvatiti i koliko daleko taj pristup ide?

Zašto penetration test nije isto što i vulnerability scan?

Mnogi klijenti i dalje misle da su napravili penetration test jer su dobili sigurnosni izvještaj s popisom nalaza. U većini slučajeva radi se o vulnerability scanu. Na prvi pogled oba pristupa izgledaju slično. Oba imaju izvještaj, nalaze i preporuke. No ne odgovaraju na isto pitanje.

Vulnerability scan traži poznate tehničke slabosti. Detektira zastarjele verzije softvera, poznate CVE-ove i loše konfiguracije. Rezultat je lista nalaza. To je korisno kao početna slika, ali ne govori što ti nalazi znače u stvarnosti.

Penetration test ide dalje. Ne staje na identifikaciji slabosti, nego pokušava razumjeti što se s njima može napraviti. Nalazi se ne gledaju izolirano nego se povezuju, testiraju i procjenjuje se koliko daleko napadač može doći. Tu nastaje stvarna vrijednost. U praksi često vidimo okruženja gdje scan ne pokazuje kritične probleme, ali penetration test otkriva stvarni vektor napada. Ne zbog jedne velike ranjivosti, nego zbog kombinacije više manjih slabosti. Uzmimo situaciju sličnu onima koje se mogu vidjeti tijekom testiranja. Unutar web aplikacije ili izloženog direktorija pronađe se javno dostupan dokument. Sam dokument ne sadrži ništa što bi alat odmah označio kao kritično. Nema exploita, nema očite injekcije i nema visokorizičnog CVE-a. Iz perspektive scana to može djelovati nebitno.

Iz perspektive penetration testa to postaje početna točka. Ako dokument sadrži nazive internih servera, oznake okruženja, reference na shareove, backup putanje, domensku strukturu ili interne URL-ove, tada više ne gledamo samo dokument. Gledamo što se iz njega može saznati o arhitekturi sustava.

Ako je vidljiva naming konvencija servera, često se može pretpostaviti njihova uloga, primjerice domain controller, aplikacijski server ili storage sustav. Ako se vidi format korisničkih imena, to može pomoći u username enumerationu. Ako dokument otkriva interne URL-ove, mogu se tražiti dodatni endpointi koji nisu bili odmah vidljivi. Ako spominje domensku strukturu ili service accounte, dobiva se bolji uvid u način autentikacije.

Nakon toga testiranje ide dalje. Traže se vanjski dostupni servisi koji prate iste obrasce, ispituju se login mehanizmi i traže dodatne ulazne točke. Ono što je na početku izgledalo kao bezazlen dokument postaje koristan oslonac za daljnje kretanje kroz okruženje. Vulnerability scan takav kontekst ne razumije. Možda će evidentirati izloženu datoteku, a možda je neće ni označiti. Ono što sigurno neće napraviti jest povezati informacije i izgraditi scenarij kako bi ih stvarni napadač iskoristio. Penetration test upravo to radi.

Isto vrijedi za nalaze koji se često označavaju kao low ili medium. Jedan endpoint vraća previše informacija, drugi nema rate limit, a treći otkriva postoji li korisnik. Pojedinačno to ne mora izgledati kritično. Zajedno to može dovesti do kompromitacije računa ili eskalacije privilegija.

Tu je ključna razlika. Vulnerability scan pokazuje što bi moglo biti problem. Penetration test pokazuje što se stvarno može dogoditi.

A za poslovanje je to ono što je važno. Upravu ne zanima samo lista CVE-ova. Zanima ih može li netko doći do podataka, prekinuti uslugu ili kompromitirati račune. Bez tog konteksta izvještaj ostaje tehnički, ali ne i stvarno upotrebljiv.

Vulnerability scan ima svoju vrijednost i koristan je za tehničku higijenu i rano otkrivanje poznatih problema. Ali ne može zamijeniti penetration test. Kada se rezultat scana tumači kao potpuna sigurnosna procjena, često se stvara lažan osjećaj sigurnosti dok stvarni napadni putevi ostaju neotkriveni.

Ako želite ići dalje od rezultata scana, AresISEC penetration test može pomoći otkriti slabosti koje su stvarno važne u praksi.

Izvori:

OWASP – Web Security Testing Guide
NIST – Technical Guide to Information Security Testing and Assessment (SP 800-115)
SANS Institute – Penetration Testing vs. Vulnerability Assessment

Želite jasnu sliku stvarnog sigurnosnog rizika u vašem sustavu?

Najčešće greške koje organizacije rade pri pripremi za NIS2

Kada organizacije počnu razmišljati o NIS2 direktivi, prvi korak je često pokušaj razumijevanja samog pravnog teksta. Timovi otvaraju dokument, čitaju članke i pokušavaju protumačiti što točno svaka odredba znači za njihovu organizaciju. Takav pristup rijetko donosi jasnoću jer NIS2 prije svega nije pravni projekt. Ona predstavlja okvir upravljanja rizikom i sigurnošću koji organizacije potiče na razumijevanje vlastite izloženost, izgradnju otpornost sustava i uključivanje vodstva tvrtke u donošenju sigurnosnih odluka. U praksi organizacije rijetko imaju problem samo zato što ignoriraju NIS2. Problem nastaje zato što joj pristupaju na način koji ne odražava stvarnu svrhu direktive.

Postoji nekoliko obrazaca koji se redovito pojavljuju kada organizacije započnu pripreme:

1. Pretvaranje NIS2 u dokumentacijski projekt

Jedna od najčešćih grešaka je tretiranje NIS2 kao projekt stvaranja dokumentacije. Napišu se politike, dodijele se odgovornosti i napravi se dokument procjene rizika. Nakon toga se pretpostavlja da je zahtjev ispunjen jer dokumentacija postoji. Direktiva ipak očekuje nešto drugo. NIS2 stavlja naglasak na operativnu sigurnost i kontinuirano upravljanje rizikom. Sustavi se mijenjaju, infrastruktura se nadograđuje, dobavljači se mijenjaju, a napadači stalno prilagođavaju svoje metode. Dokument napisan jednom ne može odražavati okruženje koje se stalno mijenja. Regulatorna tijela neće gledati samo postoji li politika. Tražit će dokaz da su sigurnosne mjere stvarno implementirane i da funkcioniraju u praksi.

2. Ostajanje na razini općih dokumenata

Drugi čest problem je zadržavanje na apstraktnoj razini. Organizacije često imaju strateške dokumente koji izgledaju dobro na papiru, ali su slabo povezani s tehničkom stvarnošću. Plan odgovora na incident postoji, ali nikada nije testiran. Plan kontinuiteta poslovanja je formalno odobren, ali oporavak sustava nikada nije simuliran. Politika sigurnosti dobavljača postoji, ali dobavljače se u praksi ne procjenjuje. NIS2 jasno naglašava implementaciju. Kontrole moraju postojati u operativnom radu, a ne samo u dokumentaciji. Organizacije koje ostanu na razini politike često tek kasnije shvate koliko je teško dokazati da te politike stvarno funkcioniraju.

3. Pokušaj tumačenja svake pravne odredbe

Neke organizacije provode tjedne pokušavajući detaljno protumačiti svaku odredbu direktive. Takav pristup često stvara više konfuzije nego koristi. NIS2 definira ciljeve i odgovornosti, ali ne propisuje točne tehničke konfiguracije niti daje detaljan vodič za implementaciju. Mnogo je korisnije krenuti od operativne slike vlastitog sustava. Organizacija mora znati koja imovina postoji, koje su usluge kritične, kako su sustavi povezani i koji dobavljači imaju pristup infrastrukturi. Bez te osnovne slike svaka rasprava o NIS2 usklađenosti ostaje teorijska.

4. Nejasnoća oko početne točke

Jedno od najčešćih pitanja koje organizacije postavljaju je jednostavno: odakle početi. Odgovor gotovo nikada nije alat ili politika. Početna točka je vidljivost. Nemoguće je upravljati rizikom u sustavima koji nisu identificirani. Nemoguće je upravljati sigurnošću dobavljača koji nisu klasificirani. Nemoguće je prijaviti incident koji se ne može detektirati. Pouzdan inventar imovine, razumijevanje mrežne strukture i identifikacija ključnih usluga stvaraju temelj za sve daljnje sigurnosne aktivnosti.

5. Podcjenjivanje odgovornosti uprave

Jedna od najvažnijih promjena koje NIS2 donosi je odgovornost uprave. Kibernetička sigurnost više nije isključivo tehnička funkcija. Uprava mora odobravati sigurnosne mjere, nadzirati njihovu implementaciju i razumjeti razinu izloženosti organizacije. To znači da se sigurnost mora komunicirati na poslovnoj razini. Rizik treba biti razumljiv upravi, a ne samo IT timu. Organizacije u kojima je sigurnost potpuno izolirana u tehničkom odjelu teško će zadovoljiti ovaj zahtjev.

6. Zanemarivanje rizika dobavljača

Mnogi veliki sigurnosni incidenti započeli su kompromitacijom dobavljača. NIS2 prepoznaje taj obrazac i zato posebno naglašava sigurnost lanca opskrbe. Organizacije moraju razumjeti ulogu koju dobavljači imaju u njihovim sustavima i procijeniti rizik koji proizlazi iz tih odnosa. To podrazumijeva identifikaciju ključnih dobavljača, razumijevanje njihovog pristupa sustavima i definiranje sigurnosnih zahtjeva koje moraju ispuniti. Ako se taj dio zanemari, organizacija može ostati izložena i uz snažne interne kontrole.

7. Obveze prijave incidenata bez mogućnosti detekcije

NIS2 uvodi jasne rokove za prijavu incidenata. Organizacije moraju poslati početno upozorenje unutar 24 sata od detekcije značajnog incidenta te detaljniju prijavu unutar 72 sata. Takvi rokovi pretpostavljaju da organizacija ima funkcionalne mehanizme detekcije. U mnogim sustavima incidenti se otkriju tek nakon nekoliko tjedana. Logovi su nepotpuni, nadzor je fragmentiran, a proces eskalacije nije definiran. Bez operativne detekcije teško je ispuniti zahtjeve direktive. Upravo zato NIS2 potiče organizacije na jačanje nadzora i odgovora na incidente.

8. Gledanje na NIS2 samo kroz prizmu kazni

Kazne predviđene direktivom često se spominju u raspravama o NIS2 a i u ponudama NIS2 savjetodavnih tvrtki. Iako su financijski iznosi značajni, fokusiranje isključivo na kazne često vodi minimalnom pristupu usklađenosti. Šira slika pokazuje da NIS2 može biti prilika za jačanje sigurnosnog upravljanja.

Organizacije koje ozbiljno pristupe upravljanju rizikom obično dobiju bolju vidljivost vlastite infrastrukture, jasniju odgovornost unutar organizacije, učinkovitiji odgovor na incidente i veću otpornost na operativne poremećaje. Direktiva tada postaje alat za razvoj sigurnosne zrelosti. NIS2 ne traži da organizacije znaju pravne članke napamet. Ona traži dokaz da organizacija razumije svoje digitalno okruženje, upravlja rizikom i ima jasnu odgovornost za sigurnost. Regulatorna tijela očekuju vidjeti da organizacije poznaju svoje sustave, prate sigurnosne događaje, procjenjuju rizik dobavljača i uključuju upravu u sigurnosne odluke. Organizacije koje NIS2 tretiraju kao administrativni projekt teško će to dokazati. One koje je shvate kao okvir za upravljanje kibernetičkom sigurnošću bit će dugoročno otpornije, bez obzira na regulatorni pritisak.

Izvori:

European Union – Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS2 Directive)

ENISA – ENISA Threat Landscape 2023

World Economic Forum – Global Risks Report 2024

Želite jasnu sliku sigurnosnog stanja vaše organizacije u odnosu na NIS2 zahtjeve?

Što penetracijsko testiranje stvarno otkriva i zašto dobar rezultat ponekad nije dobra vijest

Penetracijsko testiranje se u mnogim organizacijama doživljava kao potvrda postojećeg stanja. Test se naruči, odradi i na kraju se traži jedna stvar – je li sve u redu. Kada izvješće ne sadrži ozbiljne nalaze, osjećaj je uglavnom pozitivan. Međutim, u stvarnoj praksi takav ishod često ne znači da je okruženje sigurno, nego da je test bio ograničen na ono što je već poznato i kontrolirano.

Stvarni napadi rijetko počinju na mjestima koja su unaprijed označena kao rizična. Napadači traže rubne slučajeve, prijelaze između sustava i točke gdje se tehničke i organizacijske pretpostavke ne poklapaju. Upravo na tim mjestima penetracijsko testiranje ima smisla, ali samo ako mu se dopusti da izađe iz okvira formalne provjere.

Automatizirani alati dobro rade ono za što su namijenjeni, ali njihovi rezultati su uvijek ograničeni onim što već znamo tražiti. U stvarnim testiranjima problemi se rijetko pojavljuju kao izolirane ranjivosti. Češće se radi o kombinacijama manjih slabosti koje same po sebi ne izgledaju opasno, ali zajedno omogućuju napredovanje kroz sustav. Takvi scenariji zahtijevaju razumijevanje konteksta, načina rada aplikacija i realnog ponašanja korisnika.

Razlika između prosječnog i kvalitetnog penetracijskog testa ne vidi se u broju nalaza, nego u tome što se s tim nalazima može učiniti. Popis tehničkih problema bez jasnog konteksta ne govori puno. S druge strane, opis realnog puta napada odmah pokazuje koje pretpostavke ne drže i gdje bi organizacija stvarno imala problem u slučaju incidenta.

Upravo zato „čist” rezultat često zaslužuje dodatnu pažnju. Kada test ne pronađe ništa značajno, ključno je razumjeti što je točno testirano, a što nije. Ako su iz opsega izostavljeni kritični sustavi, identiteti s visokim privilegijama ili scenariji u kojima se polazi od kompromitiranog korisnika, rezultat može izgledati dobar, ali ne govori puno o stvarnoj otpornosti okruženja.

Jedan od češćih nalaza u praksi nije potpuni izostanak sigurnosnih mjera, nego njihova djelomična ili formalna primjena. Kontrole postoje, ali nisu dosljedno provedene. Sustavi se nadziru, ali se na signale ne reagira. Pravila su definirana, ali su s vremenom postala iznimke. Takvi problemi rijetko izlaze na vidjelo kroz standardne provjere usklađenosti, ali postaju očiti kada se okruženje promatra iz perspektive napadača.

Penetracijsko testiranje u tom smislu služi kao alat za razliku između teorijskog i stvarnog rizika. Ono pokazuje koje slabosti su zaista iskoristive, koje su samo tehnički zanimljive i gdje bi potencijalni napad imao stvarni poslovni utjecaj. Time se sigurnosne rasprave pomiču s apstraktnih procjena na konkretne scenarije.

Najvrjedniji rezultati često nisu ugodni. Oni dovode u pitanje postojeće odluke, otkrivaju zanemarene sustave i pokazuju gdje su kompromisi napravljeni bez jasne svijesti o posljedicama. Upravo zato imaju najveću vrijednost. Ako penetracijsko testiranje ne mijenja način na koji organizacija razmišlja o riziku, ono ne ispunjava svoju svrhu.

U konačnici, svrha penetracijskog testiranja nije dokazati da je sve sigurno, nego omogućiti donošenje odluka na temelju stvarne slike. Najopasniji rezultat nije loš nalaz, nego izvješće koje stvara osjećaj sigurnosti tamo gdje ona zapravo ne postoji.

Izvori:

OWASP – Web Security Testing Guide

NIST – SP 800-115: Technical Guide to Information Security Testing

SANS Institute – Penetration Testing (Glossary)

Želite realnu sliku sigurnosti svog okruženja, bez uljepšavanja i formalnih „checklista”? Zatražite AresISEC penetracijsko testiranje usmjereno na stvarni rizik i stvarne scenarije napada.

Zašto su blagdani najrizičnije razdoblje za sigurnost

Razdoblje između Božića i Nove godine za većinu organizacija znači usporavanje poslovnih aktivnosti, manji broj zaposlenika i fokus na održavanje osnovnih procesa. Za napadače to znači idealan trenutak za djelovanje. Sigurnosni incidenti koji započnu tijekom blagdana često se ne primijete odmah, a njihove stvarne posljedice postaju vidljive tek nakon povratka u redovni radni ritam. Iskustvo iz stvarnih incidenata pokazuje da blagdani nisu iznimka, već jedno od najrizičnijih razdoblja u godini. Ne zbog novih prijetnji, nego zbog kombinacije postojećih slabosti i smanjene razine nadzora.

Zašto napadači ciljaju razdoblje Božića i Nove godine

Napadači vrlo svjesno biraju vrijeme svojih aktivnosti. Blagdani im nude predvidljivo okruženje u kojem organizacije rade s ograničenim kapacitetima. Unaprijed je poznato kada su ključni zaposlenici na godišnjem odmoru, kada su IT i sigurnosni timovi reducirani i kada se odluke odgađaju. U takvim uvjetima napadači dobivaju više vremena unutar sustava prije nego što budu primijećeni.

Dodatni problem je sporija eskalacija. Čak i kada se sumnjiva aktivnost uoči, reakcija se često odgađa jer nema jasne odgovornosti ili su ključne osobe nedostupne. To napadačima omogućuje kretanje kroz sustav, prikupljanje podataka i pripremu ozbiljnijih faza napada.

Manje osoblja, sporije reakcije i opuštene kontrole

Tijekom blagdana sigurnost rijetko nestaje namjerno. Ona jednostavno prestaje biti prioritet. IT i sigurnosni timovi često rade u smanjenom sastavu, a u manjim organizacijama sigurnost se svodi na povremene provjere. Upozorenja ostaju neanalizirana, logovi se prikupljaju bez aktivnog nadzora, a pojedinačni incidenti se ne povezuju u širu sliku.

Istovremeno se toleriraju privremena rješenja. Privremeni korisnički računi ostaju aktivni, udaljeni pristupi se ne revidiraju, a sigurnosne kontrole se ublažavaju kako bi se olakšao rad zaposlenicima koji rade udaljeno. Sve to povećava napadnu površinu upravo u trenutku kada je sposobnost reakcije najmanja.

Najčešći napadi tijekom blagdanskog razdoblja

Napadi koji se događaju krajem godine rijetko su tehnički složeni. Njihova učinkovitost proizlazi iz pravog trenutka i iskorištavanja ljudskog faktora. Phishing je najčešći oblik napada. Poruke se predstavljaju kao obavijesti o dostavi paketa, božićne čestitke, promjene radnog rasporeda ili hitni financijski zahtjevi prije zatvaranja godine. Zaposlenici koji rade udaljeno često nemaju mogućnost brze provjere, što povećava vjerojatnost pogreške.

Ransomware napadi često započinju kompromitiranim korisničkim računima ili phishing porukama, ali se aktiviraju kada napadači procijene da je reakcija organizacije usporena. Svaki izgubljeni sat tijekom blagdana povećava pritisak i potencijalnu štetu.

Kompromitirani VPN i drugi udaljeni pristupi također su česti. Slabe lozinke, nedostatak višefaktorske autentikacije i zastarjele konfiguracije omogućuju napadačima neprimjetan pristup sustavu. Takvi upadi često ostaju neotkriveni sve do siječnja, kada se pojave neobične aktivnosti ili ozbiljni incidenti.

Važno je naglasiti da se u većini slučajeva ne radi o novim ranjivostima. Radi se o poznatim tehničkim slabostima koje su postojale i ranije, ali tijekom blagdana postaju kritične jer nema aktivnog nadzora.

Što organizacije realno mogu učiniti i bez stalnog nadzora

Nemaju sve organizacije mogućnost stalnog sigurnosnog nadzora ili dežurnih timova. To ipak ne znači da su prepuštene slučaju. Prvi korak je razumijevanje stvarne izloženosti. Bez jasnog uvida u tehničke ranjivosti teško je znati koje su slabosti doista kritične. Upravo tu vulnerability assessment ima ključnu ulogu. Vulnerability assessment omogućuje sustavno otkrivanje slabosti u sustavima, aplikacijama i mrežnoj infrastrukturi. Umjesto pretpostavki, organizacija dobiva jasnu sliku gdje postoje tehnički propusti koji se mogu iskoristiti upravo u razdobljima smanjene pažnje.

Drugi važan element je prioritetizacija. Nisu sve ranjivosti jednako opasne. Procjena stvarnog rizika omogućuje fokus na one slabosti koje imaju najveći potencijal za ozbiljan incident.

Treći element je priprema. Organizacije koje razumiju svoje slabosti mogu unaprijed ukloniti najkritičnije propuste i ući u blagdansko razdoblje s manjim rizikom i više kontrole.

Blagdani ne stvaraju probleme, oni ih razotkrivaju

Blagdansko razdoblje samo po sebi ne uzrokuje sigurnosne incidente. Ono pokazuje koliko su postojeće sigurnosne mjere zaista učinkovite kada nestane svakodnevna rutina i stalni nadzor. Organizacije koje imaju jasan uvid u svoje tehničke slabosti i razumiju stvarne rizike ulaze u blagdane s manje neizvjesnosti. One koje se oslanjaju na pretpostavke često u novu godinu ulaze rješavajući incidente koji su se mogli spriječiti.

Izvori:

FBI & CISA – Ransomware Awareness for Holidays and Weekends (AA21-243A)
Palo Alto Networks Unit 42 – Incident Response Report

Ako želite ući u blagdansko razdoblje s jasnim uvidom u tehničke slabosti svojih sustava, AresISEC procjena sigurnosne ranjivosti omogućuje da ranjivosti otkrijete prije nego što ih netko iskoristi u trenutku kada je reakcija najsporija.

Umjesto općih pretpostavki, dobivate konkretne nalaze, procjenu stvarnog rizika i jasne preporuke za uklanjanje ranjivosti, prilagođene vašem okruženju. Otkrijte ranjivosti prije nego što blagdani postanu prilika za napadače.

Najčešće tehničke pogreške u pripremi za NIS2

Najčešće tehničke pogreške u pripremi za NIS2

NIS2 donosi znatno širi obuhvat i strože zahtjeve od prethodne direktive te predstavlja najveću promjenu u području kibernetičke sigurnosti za europske organizacije u posljednjem desetljeću. Uključuje strože tehničke mjere, jasnu odgovornost uprave, detaljna pravila izvještavanja i snažne nadzorne ovlasti. Subjekti iz sektora definiranih u Annex I (Essential) i Annex II (Important) moraju uskladiti svoje procese i sustave, uz mogućnost visokih kazni koje dosežu do 10 milijuna eura ili 2 posto ukupnog globalnog prometa, ovisno o tome što je veće.

Uz rok od samo 24 sata za početno izvještavanje o značajnom incidentu i potrebu za dokazivanjem stvarnih tehničkih kontrola, postaje jasno da se usklađivanje ne može svesti na administrativno ispunjavanje zahtjeva. Organizacije koje odgađaju pripremu najčešće zapnu upravo na tehničkim i operativnim dijelovima, a ne na formalnoj dokumentaciji. Priprema za NIS2 vrlo brzo otkriva stvarne slabosti infrastrukture: nedostatak vidljivosti, loše konfigurirane sustave i nepostojanje integriranih sigurnosnih mehanizama.

Nedovoljna razina tehničkih kontrola

Članak 21 NIS2 direktive navodi obvezne tehničke i organizacijske mjere koje uključuju upravljanje ranjivostima, zaštitu podataka, sigurnost nabavnog lanca, upravljanje identitetima i pristupima, sigurnosne konfiguracije sustava, nadzor mreže i redovitu provjeru učinkovitosti mjera. U praksi mnoge organizacije imaju samo osnovne kontrole poput antivirusnog rješenja, firewalla i višefaktorske autentikacije, dok elementi poput kontinuiranog nadzora, segmentacije i naprednog logiranja izostaju.

Tehnički dug koji se godinama nakupljao često se pokušava nadoknaditi pisanjem politika i procedura, ali direktiva traži stvarnu operativnu sigurnost. Bez konkretnih tehničkih kontrola koje zaista rade u produkciji, organizacija formalno može izgledati usklađeno, ali ostaje ranjiva na napade i ne može dokazati usklađenost pred nadzornim tijelom.

Nepotpun inventar sustava i podataka

Točan inventar imovine jedan je od temelja svake sigurnosne priče, a NIS2 to neizravno očekuje kroz zahtjeve iz članaka 20 i 21. Organizacije često nemaju jasnu sliku o svim poslužiteljima, servisima, aplikacijama, API pozivima, mrežnoj opremi i ključnim podatkovnim tokovima. Poseban problem predstavljaju neregistrirane ili povijesne aplikacije i servisi izloženi internetu o kojima se više ne vodi evidencija.

Bez pravilno izrađene karte imovine i podataka nije moguće odrediti što je zaista kritično, što spada u opseg NIS2 obveza, niti gdje treba uvesti najstrože kontrole. Rezultat su procjene rizika koje su preopćenite i mjere koje se primjenjuju na kriva mjesta ili u pogrešnom redoslijedu.

Loše konfigurirano ili nepotpuno logiranje

Jedan od najvažnijih zahtjeva NIS2 odnosi se na brzu identifikaciju, analizu i izvještavanje o incidentima. Članak 23 propisuje obvezu inicijalne prijave značajnog incidenta u roku od 24 sata, dopunjenu izvješćem u roku od 72 sata. Bez cjelovitog, sinkroniziranog i pravilno konfiguriranog logiranja organizacija praktično ne može ispuniti ovaj zahtjev.

U praksi nedostaju logovi administrativnih aktivnosti, sigurnosnih promjena, kritičnih aplikacijskih događaja i aktivnosti na backup sustavima. Često se SIEM sustavi koriste samo za osnovne zapisnike, dok ključni događaji uopće nisu uključeni. Posljedica je nemogućnost preciznog razumijevanja incidenta, sporija reakcija i poteškoće pri izradi kvalitetnog izvješća prema nadležnim tijelima.

Nedostatak mrežne segmentacije

Ravna mreža i široki pristupi još su uvijek standard u mnogim okruženjima, iako direktiva kroz načela smanjenja površine napada i kontrole lateralnog kretanja jasno očekuje pametnije dizajniranu arhitekturu. U praksi se i dalje događa da se kritični sustavi, korisničke radne stanice i backup okruženja nalaze u istim mrežnim segmentima, što napadaču omogućava brzo širenje nakon inicijalne kompromitacije.

Mikrosegmentacija virtualnih okruženja, strogo odvajanje administrativnih zona, izolacija backupa i kritičnih servisa traže dodatni rad i promjene u dizajnu mreže, ali predstavljaju jednu od najvažnijih tehničkih mjera za ispunjavanje stvarnih očekivanja NIS2 direktive. Bez segmentacije, svaki incident potencijalno postaje incident cijele organizacije.

Slaba priprema za incidente

NIS2 očekuje da organizacije imaju pripremljene planove odgovora na incidente, forenzičke postupke, mehanizme za ranu detekciju prijetnji i testirane procese oporavka. U stvarnosti često postoji plan na papiru, ali bez odgovarajućih tehničkih kapaciteta za njegovu provedbu. Nedostaje centralizirani pregled događaja, ne postoje playbookovi za različite vrste incidenata, backupovi nisu redovito testirani, a integritet podataka se ne provjerava sustavno.

Kada se incident dogodi, organizacija tek tada otkrije da nema dovoljno podataka za rekonstrukciju događaja ili da je oporavak iz backupa spor, neizvjestan ili nepotpun. To otežava ispunjavanje obveza iz članka 23, ali i produžuje vrijeme oporavka i vraćanja u normalan rad.

Povremena, umjesto kontinuirane procjene ranjivosti

Ranjivosti u sustavima ne pojavljuju se u ritmu godišnjih ili polugodišnjih revizija, ali većina organizacija skeniranja provodi upravo u takvim intervalima. NIS2 u članku 21 izričito naglašava obvezu upravljanja ranjivostima kao kontinuirani proces, a ne jednokratnu aktivnost. Povremena skeniranja ostavljaju dug vremenski prozor u kojem organizacija ostaje otvorena za poznate ranjivosti.

U praksi često izostaju autentikacijska skeniranja, validacija nakon zakrpa i sustavno praćenje novih ranjivosti koje pogađaju ključne tehnologije. Bez jasnog procesa prioritetizacije i praćenja rezultata, izvješća o ranjivostima ostaju nerealizirana lista problema umjesto konkretnog plana rada.

Prevelik fokus na korisnike, premalo na tehničku jezgru

Edukacija korisnika važan je dio svakog sigurnosnog programa, ali ne može nadomjestiti loše konfigurirane sustave, nepostojanje nadzora ili izostanak segmentacije. U nekim okruženjima većina resursa odlazi upravo na edukaciju, dok jezgra infrastrukture ostaje u stanju u kojem jedan incident može dovesti do širokog prekida usluge.

Ako arhitektura, administracija i nadzor nisu kvalitetno implementirani, niti najsvjesniji korisnici ne mogu spriječiti ozbiljne posljedice kompromitacije. NIS2 kroz svoje zahtjeve jasno upućuje na to da je odgovornost uprave šira od organiziranja povremenih edukacija i da uključuje brigu o tehničkim temeljima sigurnosti.


NIS2 ne predstavlja samo dodatnu regulativu, nego i priliku da organizacije podignu svoju zrelost i uvedu red u tehničke procese sigurnosti. Pravilno postavljena infrastruktura olakšava svakodnevni rad, smanjuje operativne rizike i omogućuje bržu reakciju na incidente. Tvrtke koje se na vrijeme pripreme mogu usklađivanje provesti bez stresa i bez pritiska na zadnji trenutak, dok one koje odgađaju kasnije moraju istovremeno rješavati i tehničke i organizacijske izazove.

Ako trebate tih i strukturiran pristup procjeni stanja ili planiranju sljedećih koraka, AresISEC vam može pomoći u pripremi. NIS2 za mnoge subjekte predstavlja izazov, ali je ujedno i prilika da se sigurnost konačno podigne na razinu koja odgovara stvarnim rizicima.

Izvori:
EUR-Lex – NIS2 Directive (EU) 2022/2555
European Commission – NIS2 Directive Overview
ENISA – NIS Investigation and Guidance
ENISA – Security Measures Under NIS2
European Commission – Digital Strategy: Cybersecurity

Ako trebate podršku u procjeni NIS2 spremnosti ili definiranju sljedećih koraka, AresISEC vam može pomoći kroz strukturiran, jasan i praktičan pristup.

Zero Trust u malim tvrtkama

Zero Trust u malim poduzećima

Model „Zero Trust“ često se povezuje s velikim korporacijama, složenim mrežnim sustavima i visokim proračunima. No u stvarnosti, Zero Trust nije luksuz – to je nužnost i za mala poduzeća.
U današnjem okruženju, u kojem zaposlenici pristupaju poslovnim resursima s udaljenih lokacija i osobnih uređaja, stara pretpostavka da je „sve unutar mreže sigurno“ više ne vrijedi.
Zero Trust znači da se nikome ne vjeruje unaprijed – svaki zahtjev za pristup mora biti provjeren, bez obzira odakle dolazi.

Osnovni principi Zero Trusta

Zero Trust se temelji na tri osnovna načela:

  • Provjeri svaki zahtjev– Autentikacija i autorizacija moraju se provoditi pri svakom pristupu, za svakog korisnika i uređaj.
  • Primijeni najmanje privilegije – Korisnicima i sustavima dodjeljuju se samo minimalne dozvole potrebne za njihov rad.
  • Pretpostavi proboj – Sustavi se dizajniraju s mišlju da napadač možda već ima pristup mreži.

Nijedan korisnik, uređaj ili mrežni segment ne smatra se automatski sigurnim. Odluke o pristupu trebaju biti kontekstualne i dinamične, temeljene na identitetu korisnika, stanju uređaja, lokaciji i ponašanju. Kontinuirano praćenje i zapisivanje aktivnosti omogućuju brzu detekciju prijetnji.

Kako započeti u postojećoj infrastrukturi

Uvođenje Zero Trust pristupa ne zahtijeva potpunu rekonstrukciju IT sustava. Mala i srednja poduzeća mogu krenuti postupno:

  1. Mapirajte podatke i pristupe. Identificirajte ključne sustave, korisnike i tokove podataka.
  2. Uvedite višefaktorsku autentikaciju (MFA). Jednostavan i isplativ prvi korak prema Zero Trustu.
  3. Segmentirajte mrežu. Odvojite administrativne, korisničke i produkcijske sustave kako biste ograničili lateralno kretanje napadača.
  4. Koristite kontrolu pristupa prema ulozi (RBAC). Ograničite privilegije i redovito ih revidirajte.
  5. Pratite i bilježite aktivnosti. Transparentnost omogućuje rano otkrivanje nepravilnosti i brzu reakciju.
  6. Iskoristite postojeće alate. Platforme poput Microsoft 365 ili Google Workspace već imaju ugrađene Zero Trust značajke.
  7. Krenite s malim koracima. Fokusirajte se na najkritičnija područja i postepeno proširujte primjenu.

Tipične prepreke i kako ih izbjeći

Uvođenje Zero Trust modela često donosi i izazove, osobito za manje organizacije:

  • „To je prekomplicirano za nas.“ Počnite s osnovnim mjerama – MFA i segmentacija već znatno smanjuju rizik.
  • Ograničeni resursi ili stručnost. Koristite alate koje već imate ili surađujte s vanjskim stručnjacima za sigurnost.
  • Otpor zaposlenika. Objasnite zašto se uvode nove provjere i provedite kratke edukacije o važnosti zaštite podataka.
  • Stari sustavi. Izolirajte uređaje i aplikacije koji ne podržavaju moderne sigurnosne standarde i planirajte njihovu zamjenu.
  • Oslanjanje na mrežni perimetar. Napustite staru logiku da je „unutarnja mreža sigurna“ – svaki pristup treba biti provjeren.

Primjeri jednostavne implementacije

  • Malo računovodstveno poduzeće: Uvodi MFA i ograničava pristup knjigovodstvenim aplikacijama samo s poslovnih uređaja.
  • Marketinška agencija: Koristi VPN ili Zero Trust Network Access (ZTNA) i uvodi pravila uvjetovanog pristupa za udaljene korisnike.
  • IT servisni obrt: Svi udaljeni pristupi klijentskim sustavima moraju biti autentificirani i evidentirani, uz ograničene privilegije.
  • Maloprodajno poduzeće: Koristi cloud identitetskog pružatelja i ograničava pristup POS sustava samo na potrebne podatke.

Zero Trust nije rezerviran za velike – on je za svaku organizaciju koja želi zaštititi svoje podatke i poslovanje u digitalnom okruženju.
Krenite od zaštite identiteta, kontrole pristupa i segmentacije, te korak po korak izgradite otporniji i sigurniji sustav.
Primjenom načela „provjeri eksplicitno“, „ograniči pristup“ i „pretpostavi proboj“, stvarate temelj koji će rasti zajedno s vašim poslovanjem.


Izvori:
NIST – Zero Trust Architecture
Microsoft – Zero Trust Overview
Cloud Security Alliance – Zero Trust for SMBs
CrowdStrike – Što je Zero Trust sigurnost?
Akamai – Objašnjenje Zero Trust koncepta
JumpCloud – Prednosti Zero Trusta za mala i srednja poduzeća

Želite uvesti Zero Trust pristup u svoje poslovanje? AresISEC može vam pomoći u dizajnu i implementaciji sigurnosne infrastrukture prilagođene vašim potrebama.

Scroll to top