NIS2 ne traži od organizacije samo nabavu sigurnosnog alata ili pisanje jedne politike. Traži dokaziv način upravljanja kibernetičkim rizicima: tko odlučuje, koje sustave organizacija štiti, kako prepoznaje incident i može li nastaviti rad kada ključni sustav nije dostupan. Ovaj vodič za usklađivanje s NIS2 namijenjen je upravi i IT odgovornim osobama koje žele uspostaviti redoslijed rada prije nego što rokovi, upitnici partnera ili sigurnosni incident otkriju nedostatke.
Za mala i srednja poduzeća najveći je problem obično raspodjela odgovornosti. IT podršku može voditi jedna osoba, dio sustava može održavati vanjski partner, a poslovni procesi ovise o Microsoft 365 okruženju, poslovnoj aplikaciji, poslužitelju ili mrežnoj opremi. U takvom okruženju usklađivanje nije zaseban projekt za pravnu službu ili IT. Potrebna je koordinacija uprave, vlasnika procesa, IT-a i dobavljača.
Što usklađivanje s NIS2 stvarno znači
NIS2 je europski okvir za višu razinu kibernetičke sigurnosti organizacija u određenim sektorima i kategorijama subjekata. Njegova konkretna primjena ovisi o hrvatskim propisima, djelatnosti, veličini organizacije i njezinoj ulozi u lancu opskrbe. Zato prvi korak nije pretpostaviti da se propis odnosi ili ne odnosi na vašu tvrtku, nego provjeriti status s pravnim i regulatornim stručnjacima.
S tehničke i operativne strane, zahtjevi se svode na razumno upravljanje rizikom. Organizacija mora znati koju imovinu ima, koje su joj ključne usluge, gdje se nalaze podaci, tko ima pristup te što radi kada dođe do prekida rada ili sumnje na napad. Dokument koji nije povezan sa stvarnim sustavima, korisničkim računima i postupcima oporavka neće pomoći ni u nadzoru ni tijekom incidenta.
Odgovornost uprave pritom nije formalna. Uprava treba odobriti sigurnosne mjere, osigurati resurse, razumjeti preostale rizike i redovito dobivati izvještaje o stanju. IT tim provodi mjere, ali ne može sam odlučiti, primjerice, koliko dugo poslovanje smije biti bez ERP sustava ili koliki je prihvatljiv trošak oporavka.
Počnite procjenom stvarnog stanja
Najčešća pogreška je krenuti od popisa sigurnosnih proizvoda. Firewall, antivirusni sustav, MFA i backup mogu biti nužni, ali sami po sebi ne dokazuju da organizacija upravlja rizikom. Prvo treba snimiti stanje i povezati ga s poslovnim posljedicama.
Popis imovine treba obuhvatiti poslužitelje, mrežnu opremu, radne stanice, virtualne sustave, cloud usluge, poslovne aplikacije, administrativne račune, sigurnosne kopije i vanjske dobavljače koji imaju pristup sustavima. Posebnu pozornost zaslužuju sustavi koji su dugo u uporabi i održavaju se samo povremeno. Upravo se na njima često nalaze kritične funkcije, a dokumentacija i ovlasti nisu ažurirane.
Nakon popisa odredite važnost svakog sustava. Pitanje nije samo sadrži li osjetljive podatke, nego što se događa ako nije dostupan četiri sata, jedan radni dan ili tjedan dana. Primjerice, nedostupnost sustava za izdavanje računa, skladišnog sustava ili e-pošte može zaustaviti isporuku i komunikaciju s kupcima. Ta procjena daje osnovu za prioritete zaštite, rezervne kapacitete i plan oporavka.
Dobro je evidentirati i ovisnosti. Aplikacija može biti instalirana na lokalnom poslužitelju, ali prijava korisnika ovisiti o Microsoft 365 identitetu, internetskoj vezi, DNS-u i dobavljaču poslovnog softvera. Bez tog pregleda oporavak se često planira samo za poslužitelj, dok se zanemari nekoliko povezanih usluga bez kojih aplikacija ne može raditi.
Vodič za usklađivanje s NIS2 kroz šest radnih područja
Upravljanje pristupima i identitetima
Napadač ne mora provaliti kroz mrežni zid ako dođe do važeće korisničke lozinke. Zato pristupima treba upravljati prema ulozi zaposlenika, a ne prema navici ili hitnom zahtjevu. Administrativni računi trebaju biti odvojeni od svakodnevnih korisničkih računa, a višefaktorska autentifikacija mora biti uključena ondje gdje je dostupna i opravdana rizikom.
Posebno provjerite račune bivših zaposlenika, vanjskih suradnika i dobavljača. U praksi se često pronađu aktivni računi koji više nemaju poslovnu svrhu. Potreban je jasan postupak za otvaranje, promjenu i ukidanje pristupa, uz redovitu provjeru privilegiranih ovlasti.
Upravljanje ranjivostima i promjenama
Ažuriranja operativnih sustava, aplikacija, mrežne opreme i sigurnosnih rješenja ne smiju ovisiti samo o tome kada se IT administrator stigne njima baviti. Potrebni su inventar, odgovorna osoba, raspored provjere i postupak za hitne zakrpe. Za kritične sustave promjene treba prethodno procijeniti i, kada je moguće, testirati kako bi sigurnosna mjera ne bi izazvala prekid poslovanja.
Nisu sve ranjivosti jednako hitne. Prioritet imaju one koje su javno iskorištavane, dostupne s interneta ili zahvaćaju sustave s visokim poslovnim utjecajem. Međutim, odluku o odgodi ažuriranja treba evidentirati zajedno s privremenom zaštitom, primjerice ograničavanjem pristupa ili segmentacijom mreže.
Mrežna sigurnost i nadzor
Mreža bez jasne segmentacije povećava posljedice jednog kompromitiranog računala. Radne stanice, poslužitelji, sigurnosne kopije, bežična mreža za goste i industrijski ili specijalizirani uređaji ne trebaju imati slobodan međusobni pristup. Segmentacija mora pratiti poslovnu potrebu, a pravila na vatrozidu trebaju biti pregledana i dokumentirana.
Nadzor nije isto što i čuvanje velikog broja zapisa koje nitko ne pregledava. Organizacija treba odrediti koji događaji zahtijevaju reakciju: prijave administratora iz neuobičajenih lokacija, višestruki neuspjeli pokušaji prijave, gašenje zaštite, promjene ovlasti, neuobičajeno šifriranje datoteka ili prekidi sigurnosnih kopija. Za manje interne timove smisleno je dio nadzora i reakcije ugovoriti s vanjskim IT partnerom, uz jasno definirane kontakte i razine eskalacije.
Backup, oporavak i kontinuitet poslovanja
Sigurnosna kopija koja nije testirana predstavlja pretpostavku, a ne plan oporavka. Treba provjeriti obuhvaća li backup poslovne aplikacije, baze podataka, datoteke, konfiguracije mrežne opreme i podatke u cloud servisima. Kopije trebaju biti zaštićene od neovlaštene izmjene ili brisanja, a pristup sustavu za backup ne smije biti jednak uobičajenom korisničkom pristupu.
Test oporavka treba pokazati koliko je vremena potrebno da se vrati konkretna usluga i jesu li podaci upotrebljivi. Vraćanje jedne datoteke nije isto što i oporavak cijelog poslovnog sustava. Uprava treba definirati prihvatljivo vrijeme prekida rada i prihvatljiv gubitak podataka za ključne procese. Te odluke izravno utječu na arhitekturu backupa, trošak i potrebne rezervne resurse.
Reagiranje na incidente i obavještavanje
Tijekom incidenta nije vrijeme za traženje telefonskog broja dobavljača, provjeru tko smije ugasiti poslužitelj ili raspravu o tome je li događaj dovoljno ozbiljan. Plan reagiranja treba sadržavati uloge, kontakte, postupak očuvanja dokaza, tehničke korake izolacije i pravila interne komunikacije.
NIS2 predviđa obveze prijavljivanja značajnih incidenata u propisanim rokovima. Točni rokovi, kanali i kriteriji ovise o primjenjivim nacionalnim pravilima, pa ih treba potvrditi s nadležnim i pravnim stručnjacima. IT dio pripreme je ipak vrlo konkretan: sustavi moraju omogućiti brzo prikupljanje podataka o opsegu incidenta, zahvaćenim uslugama, poduzetim mjerama i mogućim posljedicama.
Sigurnost dobavljača
Vanjski pružatelj hostinga, računovodstvenog sustava, cloud usluge, održavanja aplikacije ili udaljene IT podrške dio je vašeg sigurnosnog lanca. Nije realno od svakog dobavljača tražiti jednaku razinu provjere, ali je nužno procijeniti one koji imaju pristup kritičnim podacima ili sustavima.
Ugovorni odnos treba jasno urediti pristupe, obavještavanje o incidentima, odgovornost za ažuriranja, postupak prestanka suradnje i povrat ili brisanje podataka. Kod vanjskog IT partnera posebno je važno znati kako se kontroliraju udaljene administrativne ovlasti i tko ih može odobriti.
Dokumentacija mora pratiti operativni rad
Politike i procedure imaju vrijednost kada zaposlenici znaju gdje se nalaze i kada ih primijeniti. Nema potrebe za opsežnim dokumentima koji se ne čitaju. Za početak su korisniji kratki, održavani dokumenti: popis kritične imovine, matrica ovlasti, plan reagiranja na incident, plan oporavka, evidencija rizika i zapisnici testiranja.
Edukacija zaposlenika također mora biti povezana s njihovim stvarnim radom. Financije trebaju znati prepoznati sumnjivu promjenu podataka za plaćanje, korisnička služba postupati s neobičnim zahtjevima za podatke, a IT tim prijaviti neuobičajene događaje bez odgađanja. Jedna godišnja prezentacija nije dovoljna ako nema kratkih ponavljanja i provjere postupaka.
Za organizacije s ograničenim internim resursima praktičan je fazni pristup. Prvo se rješavaju javno izloženi sustavi, administrativni pristupi, backup i postupak za incident. Zatim slijede segmentacija, detaljniji nadzor, upravljanje dobavljačima i redovita testiranja. CarPen Rebuild u takvom procesu može pomoći snimanjem infrastrukture, provedbom prioritetnih tehničkih mjera i održavanjem sustava, dok uprava zadržava odluke o poslovnim rizicima i prioritetima.
Najkorisniji prvi korak nije kupnja novog alata, nego sastanak uprave i IT-a na kojem će se imenovati vlasnici ključnih sustava, potvrditi najveći rizici i dogovoriti datum prvog testa oporavka. Tada usklađivanje prestaje biti apstraktna obveza i postaje konkretna sposobnost organizacije da nastavi raditi pod pritiskom.