Poslovanje ne staje zato što je donesena sigurnosna politika, nego onda kada zaposlenik otvori zlonamjernu poruku, administrator izgubi pristup ključnom sustavu ili backup ne može vratiti podatke u potrebnom roku. Zato uspješna NIS2 usklađenost nije dokument koji se pripremi jednom, već način upravljanja IT rizicima kroz svakodnevne operativne postupke.
Za uprave i direktore glavno pitanje nije samo pripada li organizacija obuhvatu propisa. Puno važnije je mogu li odgovorne osobe dokazati da razumiju ključne poslovne rizike, da su za njih odredile vlasnike te da mogu reagirati bez improvizacije. Tehnička zaštita pritom ima smisla samo ako je povezana s ljudima, procesima i poslovnim prioritetima.
NIS2 počinje odgovornošću uprave
NIS2 Direktiva stavlja naglasak na upravljanje kibernetičkim rizicima na razini organizacije. U praksi to znači da sigurnost ne može ostati isključivo zadatak vanjskog pružatelja IT podrške ili jednog internog administratora. Uprava mora odlučiti koji su sustavi, podaci i poslovni procesi kritični, koliko prekida poslovanje može podnijeti i tko donosi odluke u incidentu.
Prvi korak je utvrditi primjenjuju li se konkretne obveze na organizaciju. To ovisi o djelatnosti, veličini organizacije i nacionalnom okviru provedbe Direktive. Takvu procjenu treba provesti uz odgovarajuće pravne i regulatorne stručnjake. IT partner može pritom dati tehničku sliku sustava, ovisnosti i postojećih kontrola, ali ne bi trebao zamjenjivati pravni savjet.
Čak i kada tvrtka nije izravno obuhvaćena, zahtjevi kupaca, partnera, osiguravatelja i većih dobavljačkih lanaca često traže sličnu razinu kontrole. Organizacija koja može jasno pokazati kako štiti pristupe, podatke i kontinuitet rada lakše odgovara na takve zahtjeve.
Uspješna NIS2 usklađenost traži stvarno stanje, ne pretpostavke
Mnoge srednje velike tvrtke imaju kombinaciju lokalnih servera, Microsoft 365 okruženja, udaljenog pristupa, računovodstvenih ili proizvodnih aplikacija te opreme koju održavaju različiti dobavljači. Problem nastaje kada nitko nema cjelovitu sliku: ne zna se koji su sustavi povezani, tko ima administratorske ovlasti, gdje se čuvaju sigurnosne kopije ni koji bi prekid najviše pogodio poslovanje.
Procjena početnog stanja treba krenuti od poslovnih procesa, a ne od popisa alata. Ako ispad mreže zaustavlja izdavanje računa, skladište ili komunikaciju s kupcima, mrežna infrastruktura nije samo tehnička komponenta. Ona je dio procesa koji izravno utječe na prihod i ugled tvrtke.
Dobar pregled obično obuhvaća inventar uređaja, servera, cloud usluga i aplikacija; pregled korisničkih i administratorskih računa; mapu mreže i udaljenih pristupa; status ažuriranja; način izrade backupa; te postojeće ugovore i odgovornosti dobavljača. Cilj nije proizvesti opsežnu dokumentaciju koja će ostati nepročitana, nego dobiti pouzdan temelj za odluke.
Posebnu pozornost zaslužuju tzv. skrivene ovisnosti. Primjerice, poslovna aplikacija može raditi na serveru koji je redovito održavan, ali njezin oporavak ovisi o administratorskoj lozinci koju zna samo jedna osoba, staroj mrežnoj opremi ili backupu koji se nikada nije testirao. Takve slabosti često nisu vidljive dok se ne dogodi prekid.
Kontrole koje imaju najveći operativni učinak
Ne postoji jedna mjera koja rješava kibernetičku sigurnost. Učinkovitost dolazi iz slojeva zaštite i njihove redovite provjere. Prioritete ipak treba postaviti prema riziku, a ne prema tome koji je alat trenutačno popularan.
U poslovnim okruženjima prvi prioritet često su identiteti i pristupi. Višefaktorska autentifikacija za e-poštu, udaljeni pristup, administrativne račune i cloud servise može znatno smanjiti rizik zlouporabe ukradenih zaporki. Jednako je važno da zaposlenici imaju samo ovlasti koje trebaju za svoj posao. Administratorski račun ne smije se koristiti za svakodnevno čitanje e-pošte ili rad u uredskim aplikacijama.
Sljedeće područje su ažuriranja i upravljanje ranjivostima. Nije dovoljno povremeno provjeriti jesu li računala ažurirana. Potrebno je znati koji uređaji i aplikacije postoje, tko ih održava, kako se procjenjuje hitnost zakrpa i što se radi sa sustavima koji se ne mogu odmah nadograditi zbog kompatibilnosti. Ponekad je opravdano odgoditi ažuriranje poslovne aplikacije, ali tada treba uvesti kompenzacijske mjere, primjerice ograničiti pristup mreži, pojačati nadzor ili odvojiti sustav od ostalih segmenata.
Mrežna segmentacija također ima praktičnu vrijednost. Uređaji za goste, posjetitelje, nadzorne sustave, proizvodnu opremu i serversku infrastrukturu ne bi trebali bez potrebe dijeliti isti mrežni prostor. Kada se incident dogodi, segmentacija ograničava njegovo širenje i olakšava istragu.
Za većinu organizacija smislen redoslijed ulaganja izgleda ovako:
- zaštititi identitete, administrativne pristupe i e-poštu
- održavati operativne sustave, aplikacije i mrežnu opremu
- osigurati provjerene sigurnosne kopije ključnih podataka i konfiguracija
- nadzirati događaje koji mogu upućivati na incident
- uvježbati postupak prijave, odlučivanja i oporavka
Ovaj redoslijed nije jednak za svaku tvrtku. Organizacija koja radi s osjetljivim podacima može prioritet dati kontroli pristupa i evidentiranju aktivnosti, dok će tvrtka čiji rad ovisi o lokalnoj proizvodnoj ili logističkoj aplikaciji prvo morati riješiti oporavak servera i mrežne infrastrukture.
Backup nije plan oporavka
Sigurnosne kopije često se smatraju riješenim problemom čim se postavi automatizirano kopiranje podataka. Međutim, backup koji nije provjeren može stvoriti lažan osjećaj sigurnosti. Potrebno je znati obuhvaća li kopija sve što je potrebno za nastavak rada: podatke, virtualne strojeve, konfiguracije, licence, mrežne postavke i dokumentirane korake vraćanja sustava.
Važno je razlikovati ciljano vrijeme oporavka od prihvatljivog gubitka podataka. Ako poslovanje može prihvatiti gubitak najviše nekoliko sati podataka, backup jednom dnevno možda nije dovoljan. Ako se ključni sustav mora vratiti unutar četiri sata, nije dovoljno znati da kopija postoji – treba testirati može li se taj rok doista postići s raspoloživim ljudima, opremom i pristupima.
Test oporavka ne mora uvijek značiti potpuni prekid poslovanja. Može se započeti vraćanjem uzorka podataka, pokretanjem virtualnog servera u izoliranom okruženju ili provjerom postupka za prioritetnu aplikaciju. Bitno je evidentirati rezultat, pronađene nedostatke i dogovorene korekcije.
Upravljanje incidentom mora biti unaprijed dogovoreno
Tijekom sigurnosnog incidenta vrijeme se najčešće gubi na osnovna pitanja: tko smije isključiti sustav, tko kontaktira dobavljača, gdje se nalaze pristupni podaci, treba li obavijestiti upravu i kako se zaposlenicima daje uputa. Plan reagiranja zato treba biti kratak, razumljiv i dostupan osobama koje ga trebaju.
Plan ne treba sadržavati desetke stranica općih definicija. Treba jasno odrediti uloge, kontakte, način eskalacije, postupak čuvanja dokaza i kriterije za uključivanje vanjskih stručnjaka. Treba obuhvatiti i komunikaciju s poslovnim partnerima kada prekid utječe na isporuku usluge ili razmjenu podataka.
Nakon incidenta, čak i manjeg, organizacija treba provesti pregled. Je li detekcija bila dovoljno brza? Jesu li pristupi bili pravilno postavljeni? Je li backup radio? Jesu li zaposlenici znali komu prijaviti sumnjivu aktivnost? Upravo se kroz takve provjere sigurnost pretvara u proces poboljšanja, a ne u jednokratnu reakciju.
Dobavljači su dio sigurnosne slike
Mala i srednja poduzeća često ovise o vanjskim pružateljima za održavanje aplikacija, računovodstvene sustave, internet vezu, cloud platforme i IT podršku. To nije slabost samo po sebi, ali odgovornosti moraju biti jasne. Vanjski partner može održavati server, no tvrtka i dalje mora znati tko odobrava pristupe, gdje se nalaze sigurnosne kopije, kako se prijavljuje incident i koji je očekivani rok reakcije.
Ugovori i operativni dogovori trebaju obuhvatiti barem način dodjele i ukidanja pristupa, kontaktne osobe, postupak prijave incidenata, održavanje sustava i obvezu čuvanja dokumentacije. Poseban rizik predstavljaju stari računi bivših zaposlenika i dobavljača te zajedničke administratorske lozinke. Takve se prakse moraju uklanjati postupno, ali dosljedno.
CarPen Rebuild u ovakvim projektima može preuzeti tehnički dio procjene, urediti nadzor i održavanje infrastrukture te pomoći internom timu da dokumentira postupke koji se mogu provesti pod pritiskom stvarnog incidenta.
Mjerite napredak kroz dokaze
Usklađenost se ne dokazuje tvrdnjom da je sigurnost riješena, nego zapisima i provjerljivim rezultatima. To mogu biti evidencije ažuriranja, izvještaji o testiranju backupa, zapisi o pregledima korisničkih ovlasti, dokumentirane vježbe reagiranja i odluke uprave o prioritetima rizika.
Takvi dokazi imaju i operativnu korist. Kada dođe do promjene zaposlenika, dobavljača ili infrastrukture, dokumentiran proces smanjuje ovisnost o pojedincu. Kada uprava mora odobriti ulaganje, može vidjeti konkretan rizik i očekivani učinak, umjesto da odlučuje na temelju nejasnih tehničkih zahtjeva.
Uspješna NIS2 usklađenost gradi se korak po korak: najprije se utvrdi stvarno stanje, zatim se rješavaju najveći rizici, a nakon toga se kontrole redovito testiraju i prilagođavaju poslovanju. Tvrtka koja može nastaviti rad i kada jedan dio sustava zakaže ima mnogo čvršći temelj od tvrtke koja se oslanja na pretpostavku da se incident neće dogoditi.