NIS2 v praksi: kaj mora podjetje dejansko urediti

Kdo je zajet z NIS2 in kaj se spremeni za vodstvo#

NIS2 uvaja obveznost obvladovanja kibernetskih tveganj za podjetja v širokem naboru sektorjev, pri čemer velikost podjetja in panoga določata, ali je zavezanec neposredno ali posredno, prek pogodbenih zahtev naročnika. V praksi to pomeni, da mora vodstvo podjetja prevzeti osebno odgovornost za odločitve o varnosti informacijskih sistemov, ne le IT oddelek. Uprava ali direktor mora znati utemeljiti, da so bili ukrepi izbrani na podlagi ocene tveganja in ne naključno.

Prva naloga vodstva je ugotoviti, ali podjetje sploh spada med zavezance, in če ne, ali je del dobavne verige podjetja, ki je zavezanec. Veliko srednje velikih dobaviteljev opreme, storitev in programske opreme namreč čuti posledice NIS2 posredno, ker jim naročniki v pogodbah nalagajo enake varnostne zahteve, kot jih morajo izpolnjevati sami. Zato se je smiselno vprašati, kdo so ključni naročniki podjetja in kakšne varnostne klavzule že vključujejo v pogodbe.

Ko je jasno, da podjetje sodi v obseg zakonodaje, sledi odločitev, kdo znotraj organizacije nosi odgovornost za skladnost. To ni vprašanje, ki ga je mogoče rešiti z enim internim dopisom - potrebna je jasna razdelitev vlog med vodstvom, IT oddelkom, pravno službo in po potrebi zunanjim izvajalcem. Brez te razdelitve se zgodi, da nihče ne spremlja rokov za poročanje incidentov ali izvajanje ocene tveganja.

Za organizacije, ki so del skupine ali imajo več poslovnih enot, je treba določiti tudi, ali se zahteve nanašajo na celotno skupino ali na posamezen pravni subjekt. Odločitev vpliva na to, kako se organizira upravljanje tveganj, kdo pripravlja poročila in kdo je kontaktna oseba za pristojni organ. Nejasna razmejitev odgovornosti med matičnim podjetjem in odvisnimi družbami je ena pogostejših težav pri uvajanju zahtev v prakso.

Popis sistemov in ocena tveganja kot temelj#

Preden podjetje določi konkretne varnostne ukrepe, mora vedeti, kateri sistemi, podatki in procesi so kritični za delovanje in kje so med seboj povezani. Popis informacijskih sistemov, vključno z ERP, CRM, proizvodnimi sistemi in dokumentnimi rešitvami, je prvi konkreten korak, ki ga NIS2 zahteva v praksi. Brez tega popisa ocena tveganja ostane splošna in ne pokaže, kje je podjetje dejansko izpostavljeno.

Ocena tveganja mora zajeti tako tehnične ranljivosti kot organizacijske, na primer, kaj se zgodi, če ključni dobavitelj storitve odpove ali če zaposleni z visokimi dostopnimi pravicami zapusti podjetje brez urejenega prenosa dostopov. Rezultat ocene ni dokument za predal, temveč podlaga, na kateri vodstvo odloča, kam usmeriti sredstva za varnost v naslednjem obdobju. Podjetja, ki oceno obravnavajo kot enkratno nalogo, hitro ugotovijo, da postane neuporabna, ker se sistemi in dobavitelji spreminjajo hitreje kot dokument.

Pri povezovanju obstoječih sistemov, kot so ERP, CRM in dokumentni sistemi, je treba oceniti tudi, kje API-integracije odpirajo dodatne poti do podatkov. Vsaka nova povezava med sistemi je hkrati nova točka, ki jo je treba vključiti v popis in oceno tveganja. Podjetja, ki povezave dodajajo brez pregleda nad celotno arhitekturo, težko kasneje dokažejo, da imajo nadzor nad tokom podatkov.

Ocena tveganja se ne konča z enim poročilom - ponoviti jo je treba ob vsaki pomembnejši spremembi sistema, novi integraciji ali menjavi ključnega dobavitelja. Podjetja, ki nimajo notranjega procesa za redno posodabljanje ocene, se pogosto odločijo za zunanjega izvajalca, ki prevzame pregled arhitekture, infrastrukture in podatkov ter oceno vzdržuje skupaj z internim IT oddelkom.

• Seznam vseh poslovno kritičnih aplikacij in njihovih lastnikov
• Povezave med sistemi prek API-jev in izmenjav podatkov
• Lokacije podatkov in način hrambe
• Seznam zunanjih dobaviteljev, ki imajo dostop do sistemov
• Ocena posledic izpada za vsak sistem posebej

Upravljanje dostopov in identitet#

Eden od najpogosteje spregledanih delov NIS2 v praksi je nadzor nad tem, kdo ima dostop do katerega sistema in zakaj. Podjetja z več oddelki in leti nakopičenih uporabniških pravic pogosto ne vedo natančno, kdo lahko dostopa do finančnih, kadrovskih ali proizvodnih podatkov. Urejeno upravljanje dostopov je eden redkih ukrepov, ki hkrati zmanjša tveganje in olajša vsakodnevno delo IT oddelka.

V praksi to pomeni uvedbo jasnih pravil za dodeljevanje, spreminjanje in odvzem dostopov, še posebej ob zamenjavi zaposlenega ali zunanjega sodelavca. Dostop, ki ostane aktiven po odhodu osebe iz podjetja, je eden najpogostejših vzrokov za incident, ki bi ga bilo mogoče preprečiti brez dodatne tehnologije, zgolj z urejenim procesom. Zato je smiselno dostope vezati na vlogo v podjetju in ne na posameznika, saj se s tem postopek prenosa ali odvzema pravic poenostavi in postane ponovljiv.

Za sisteme, ki upravljajo občutljive ali poslovno kritične podatke, je smiselno uvesti dodatno raven preverjanja identitete in ločiti razvojno, testno in produkcijsko okolje, tako da dostop do pravih podatkov nima vsak, ki testira novo funkcionalnost. Ta ločitev je tudi eden od pogojev, da lahko podjetje dokaže nadzor nad tem, kje se nahajajo pravi podatki strank ali zaposlenih.

Upravljanje dostopov je področje, kjer se pogosto pokaže razlika med podjetjem, ki NIS2 razume kot papirologijo, in podjetjem, ki ga razume kot spremembo delovnih navad. Prvo pripravi politiko dostopov, ki je nihče ne upošteva, drugo vzpostavi proces, ki ga IT oddelek dejansko izvaja ob vsaki kadrovski spremembi. Slednje zahteva sodelovanje kadrovske službe in IT oddelka, saj informacija o odhodu zaposlenega mora priti do tistih, ki upravljajo dostope, še isti dan.

Zaznavanje incidentov in poročanje pristojnim organom#

NIS2 od podjetja zahteva, da zna incident najprej zaznati, nato pa o njem obvestiti pristojni organ v več stopnjah - najprej kratko zgodnje opozorilo, nato podrobnejše poročilo in na koncu končno poročilo z analizo vzroka. V praksi to pomeni, da mora imeti podjetje določeno osebo ali ekipo, ki odloči, ali dogodek sploh dosega prag za obvezno poročanje.

Brez sistema za zaznavanje neobičajnega dogajanja v omrežju podjetje pogosto ugotovi, da se je incident zgodil, šele ko se posledice že pokažejo navzven, na primer v obliki izpada storitve ali pritožb strank. Zato je zaznavanje incidentov tesno povezano z nadzorom nad infrastrukturo in beleženjem dogodkov, ki jih je mogoče pregledati za nazaj. Podjetja, ki nimajo lastnega varnostnega centra, to nalogo pogosto prenesejo na zunanjega partnerja, ki spremlja dogajanje in po dogovorjenih merilih sproži notranji postopek obveščanja.

Poleg tehničnega zaznavanja je enako pomemben notranji postopek: kdo mora biti obveščen v prvi uri, kdo pripravi vsebino poročila za pristojni organ in kdo komunicira z naročniki, če je incident vplival nanje. Ta postopek je treba zapisati vnaprej in ga preizkusiti, saj se med dejanskim incidentom izkaže, da improvizacija stane največ časa prav takrat, ko ga je najmanj.

Podjetja, ki so del dobavne verige večjih naročnikov, morajo poleg obveščanja pristojnega organa pogosto obvestiti tudi naročnika samega, saj imajo z njim sklenjeno pogodbo z varnostnimi klavzulami. Zato je smiselno v internem postopku vnaprej določiti, kateri incidenti sprožijo obveznost do naročnika in kateri le do regulatorja, da se izognemo nepotrebnemu razkrivanju ali, nasprotno, zamudi pri obveščanju.

• Jasno določena oseba ali ekipa, ki odloča o resnosti dogodka
• Postopek zbiranja dokazov in beleženja poteka incidenta
• Seznam kontaktov: pristojni organ, ključni naročniki, vodstvo
• Predloga za zgodnje opozorilo in za podrobnejše poročilo
• Način komunikacije z zaposlenimi in strankami med incidentom
• Pregled incidenta po zaključku in popravek postopkov

Neprekinjeno poslovanje in okrevanje po incidentih#

Poleg preprečevanja incidentov NIS2 zahteva tudi, da podjetje zna nadaljevati poslovanje, če se incident kljub vsemu zgodi. To pomeni, da mora imeti pripravljen načrt, kako obnoviti ključne sisteme, kdo prevzame odločanje, če je vodstvo nedosegljivo, in kako komunicirati navzven, dokler sistemi niso obnovljeni. Načrt neprekinjenega poslovanja ni isto kot varnostna kopija podatkov, čeprav je ta del njegovega izhodišča.

V praksi se izkaže, da imajo mnoga podjetja varnostne kopije, nimajo pa preizkušenega postopka obnovitve - kopija obstaja, nihče pa ni nikoli poskusil iz nje dejansko obnoviti sistema pod časovnim pritiskom. Zato je vaja obnovitve, izvedena vnaprej in ne šele med resničnim izpadom, eden bolj oprijemljivih dokazov, da podjetje načrt jemlje resno. Taka vaja pogosto razkrije ozka grla, ki jih na papirju ni mogoče videti, na primer, da je za obnovitev enega sistema potreben dostop, ki ga ima le ena oseba.

Za podjetja z več lokacijami ali proizvodnimi obrati je treba določiti tudi, kateri procesi lahko začasno tečejo ročno, dokler informacijski sistem ni obnovljen, in kdo o tem odloča. Ta odločitev spada v pristojnost vodstva posameznega oddelka, ne le IT oddelka, saj poznajo posledice izpada za proizvodnjo ali nabavo bolje kot kdorkoli drug. Vključitev vodij oddelkov v pripravo načrta hkrati poveča verjetnost, da bo načrt v resničnem dogodku dejansko uporabljen, ne le arhiviran.

Načrt neprekinjenega poslovanja je smiselno uskladiti tudi z zahtevami naročnikov in partnerjev, saj mnogi v pogodbah že zahtevajo dokazilo, da ima dobavitelj tak načrt pripravljen. Podjetje, ki načrt vzdržuje redno in ga preizkuša, ga lahko uporabi tudi kot argument pri pridobivanju novih poslov v panogah, kjer je varnost dobavne verige pogoj za sodelovanje. V nasprotnem primeru se podjetje znajde v položaju, da mora načrt na hitro sestaviti šele, ko ga naročnik izrecno zahteva pred podpisom pogodbe.

Varnost dobavne verige in pogodbenih partnerjev#

NIS2 podjetja ne obravnava kot izolirano celoto, temveč kot del verige dobaviteljev in partnerjev, zato mora podjetje oceniti tudi tveganje, ki ga prinašajo zunanji izvajalci s dostopom do njegovih sistemov ali podatkov. V praksi to pomeni pregled obstoječih pogodb in vprašanje, kateri dobavitelji dejansko dostopajo do katerih sistemov in ali imajo sami urejeno varnost. Presenetljivo pogosto se izkaže, da ima dostop do internih sistemov več zunanjih partnerjev, kot jih vodstvo pričakuje, ker so bili dodani postopoma in nikoli pregledani skupaj.

Za nove pogodbe je smiselno vnaprej določiti varnostne klavzule, ki opredeljujejo, kako partner ravna s podatki, kako hitro mora javiti incident na svoji strani in kdo je odgovoren, če pride do izgube podatkov zaradi njegove napake. Te klavzule je lažje vključiti pri sklepanju nove pogodbe kot naknadno dodajati v obstoječe razmerje. Podjetja, ki klavzule dodajo šele po incidentu, pogosto ugotovijo, da stara pogodba odgovornosti ne razmejuje jasno, kar podaljša reševanje spora.

Poseben izziv predstavljajo dobavitelji programske opreme in strojne opreme, ki jih podjetje ne razvija samo, saj mora zaupati njihovim lastnim varnostnim praksam. Tu pomaga zahteva po dokumentaciji, dostopih in geslih kot delu vsake primopredaje, saj podjetje s tem ohrani pregled nad tem, kaj je bilo dejansko dobavljeno in kdo ima nadzor nad izvorno kodo in infrastrukturo. Brez te dokumentacije podjetje ob menjavi izvajalca izgubi pregled nad sistemom in ne more zanesljivo oceniti tveganja, ki ga prinaša.

Nadzor nad dobavno verigo ni enkratno dejanje, temveč se ponavlja ob vsakem novem partnerstvu in ob vsaki pomembnejši spremembi pri obstoječem dobavitelju. Podjetja, ki imajo urejen postopek za oceno novih dobaviteljev, preden jim dodelijo dostop do sistemov, se izognejo situaciji, v kateri se varnostna vprašanja postavijo šele, ko je sodelovanje že v polnem teku. Tak postopek je smiselno voditi skupaj z nabavno službo, saj ta prva pride v stik z novim dobaviteljem.

• Kateri sistemi in podatki so dobavitelju dostopni
• Ali ima dobavitelj lastno politiko obveščanja o incidentih
• Kdo je odgovoren za škodo ob napaki na strani dobavitelja
• Ali pogodba določa vračilo ali izbris podatkov ob prenehanju sodelovanja
• Ali je dokumentacija sistema del pogodbene obveznosti dobavitelja

Tehnične in organizacijske varnostne posodobitve#

Poleg procesov NIS2 zahteva tudi konkretne tehnične ukrepe, med njimi redno posodabljanje sistemov, nadzor nad ranljivostmi in šifriranje občutljivih podatkov. V praksi to pomeni, da mora podjetje vedeti, kateri sistemi tečejo na zastareli programski opremi, in imeti načrt, kdaj in kako jih bo posodobilo, ne da bi ob tem ustavilo poslovanje. Sistemi, ki jih ni mogoče takoj posodobiti zaradi povezanosti s starejšo proizvodno opremo, zahtevajo dodatne kompenzacijske ukrepe, na primer strožji nadzor dostopa ali ločitev v posebej varovan del omrežja.

Organizacijski del posodobitev pomeni, da spremembe ne gredo neposredno v uporabo, temveč skozi pregled in testiranje, preden pristanejo v produkcijskem okolju. Ta korak, ki je za razvojne ekipe že ustaljena praksa, postane pod NIS2 tudi dokazljiva obveznost - podjetje mora znati pokazati, da sprememba ni bila uvedena mimo dogovorjenega postopka. V praksi to pomeni ločena razvojna, testna in produkcijska okolja ter jasno sled o tem, kdo je spremembo odobril in kdaj.

Za podjetja, ki imajo starejše ali nedokončane sisteme, prevzete od prejšnjega izvajalca, je prvi korak pregled izvorne kode, arhitekture, infrastrukture in podatkov, preden je sploh mogoče oceniti, kateri varnostni ukrepi manjkajo. Šele na podlagi tega pregleda je mogoče določiti, ali je sistem mogoče nadgraditi ali ga je treba v določenem delu zgraditi na novo. Tak pregled pogosto pokaže razliko med tem, kar je vodstvo mislilo, da sistem podpira, in tem, kar dejansko podpira.

Tehnični ukrepi brez organizacijskega okvira ne zadostujejo, saj orodje samo po sebi ne prepreči napake, če ga nihče ne vzdržuje ali spremlja. Zato je smiselno tehnične posodobitve povezati z rednim pregledom delovanja, odpravo napak in nadaljnjim razvojem, ki jih lahko podjetje izvaja samo ali jih po uvedbi prenese na zunanjega izvajalca. Odločitev, kdo po uvedbi skrbi za varnostne posodobitve, je ena tistih, ki jih je bolje sprejeti pred zaključkom projekta kot po prvem incidentu.

Usposabljanje zaposlenih in odgovornost vodstva#

Tehnologija ne reši tveganja, ki ga povzroči zaposleni, ki ne prepozna lažnega elektronskega sporočila ali deli geslo s sodelavcem zaradi udobja. Zato NIS2 v praksi zahteva tudi usposabljanje zaposlenih, prilagojeno njihovi vlogi - drugačno za osebo, ki upravlja proizvodni sistem, kot za osebo v finančnem ali kadrovskem oddelku. Splošno usposabljanje, ki ga vsi zaposleni opravijo enkrat na leto brez povezave z njihovim dejanskim delom, redko spremeni vedenje, ki povzroča največ incidentov.

Vodstvo je pod NIS2 osebno odgovorno za to, da so ukrepi vzpostavljeni in vzdrževani, kar pomeni, da se mora tudi samo redno seznanjati z osnovami kibernetske varnosti, ne le podpisovati poročil, ki jih pripravi IT oddelek. To ne pomeni, da mora direktor razumeti tehnične podrobnosti, pomeni pa, da mora znati postaviti prava vprašanja o tveganjih. Uprava, ki teh vprašanj ne postavlja, se v primeru incidenta težko sklicuje na to, da je bila varnost prepuščena strokovnjakom.

Usposabljanje je smiselno ponoviti ob vsaki večji spremembi sistema ali procesa, saj novo orodje pogosto prinese nova tveganja, ki jih star postopek usposabljanja ne pokriva. Prav tako je koristno usposabljanje dopolniti s kratkimi, ponavljajočimi se opomniki, ne le z enkratnim obsežnim izobraževanjem, ki ga zaposleni po nekaj tednih pozabijo. Kratke in pogoste vaje, na primer preverjanje, kako zaposleni prepoznajo sumljivo sporočilo, dajejo boljšo sliko o dejanskem stanju kot enkraten test znanja.

Dokumentacija in dokazovanje skladnosti#

NIS2 v praksi pomeni tudi, da mora podjetje znati dokazati, ne le trditi, da izpolnjuje zahteve - z zapisano oceno tveganja, sledjo sprememb v sistemih, zapisniki usposabljanj in dokazili o testiranju varnostnih ukrepov. Dokumentacija, ki nastane šele na zahtevo nadzornega organa, praviloma ne prepriča, ker manjka datumska sled skozi čas. Zato je smiselno dokumentacijo graditi sproti, kot stranski produkt vsakodnevnega dela, ne kot ločen projekt tik pred nadzorom.

Del dokumentacije je tudi jasna razmejitev lastništva - izvorna koda in podatki ostanejo last naročnika, dokumentacija, dostopi in gesla pa so del vsake primopredaje, ne glede na to, ali sistem razvija interna ekipa ali zunanji izvajalec. Brez te razmejitve podjetje ob menjavi izvajalca tvega, da izgubi dostop do lastnega sistema ali podatkov. Jasna pogodbena določila o lastništvu so zato enako pomembna kot tehnični ukrepi sami.

Revizijska sled je koristna tudi neodvisno od zakonodaje, saj pomaga pri odpravljanju napak - če je jasno, kdaj je bila sprememba uvedena in kdo jo je odobril, je lažje najti vzrok, ko nekaj ne deluje pričakovano. Podjetja, ki dokumentacijo vodijo dosledno, zato pogosto opazijo, da se jim skrajša tudi čas reševanja vsakodnevnih tehničnih težav, ne le čas priprave na nadzor. To je stranski učinek reda, ne njegov glavni namen.

Kako izbrati izvajalca za uvedbo zahtev#

Ker NIS2 zahteva sočasno urejanje procesov, tehnologije in odgovornosti, redko obstaja en sam oddelek, ki lahko nalogo izpelje sam. V praksi se podjetja odločajo med krepitvijo internega IT oddelka in vključitvijo zunanjega izvajalca, ki prevzame posamezen sklop - od popisa sistemov do vzpostavitve postopka za obravnavo incidentov - ali celoten projekt. Odločitev je odvisna od tega, koliko notranjega znanja podjetje že ima in koliko časa lahko nameni projektu poleg rednega dela.

Pri izbiri izvajalca je smiselno preveriti, ali zna prevzeti tudi obstoječ ali nedokončan sistem po pregledu izvorne kode, arhitekture, infrastrukture in podatkov, ne le graditi na novo. Prav tako je vredno vprašati, kako izvajalec loči razvojno, testno in produkcijsko okolje ter kako ravna s podatki v testnem okolju, saj to neposredno vpliva na varnost med samim razvojem. Izvajalec, ki teh vprašanj ne zna jasno odgovoriti, verjetno tudi v praksi ne loči okolij dovolj strogo.

Enako pomembno je dogovoriti, kaj se zgodi po uvedbi - kdo prevzame nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj, in po kakšnih razredih se obravnavajo napake, od izpada do manjše zahteve za spremembo. Jasna razdelitev razredov napak vnaprej prepreči spor o tem, kaj je nujno in kaj lahko počaka. Podjetje, ki te razrede določi šele med prvim resnim izpadom, pogosto ugotovi, da se pričakovanja naročnika in izvajalca razhajajo.

Ker cena projekta uvedbe NIS2 zahtev ni odvisna od ene same številke, temveč od obsega funkcionalnosti, števila povezanih sistemov, zahtev po testiranju in ravni podpore po uvedbi, je smiselno začeti s krajšo analizo, ki obseg razdeli na obvladljive sklope. Tak pristop omogoča, da se vsak sklop oceni in izvede ločeno, namesto da podjetje čaka na eno samo veliko oceno za celoten projekt.

• Ali lahko prevzame obstoječ sistem po pregledu kode in infrastrukture
• Kako loči razvojno, testno in produkcijsko okolje
• Kdo je odgovoren za podporo in odpravo napak po uvedbi
• Po katerih razredih obravnava napake in kako določa prednost
• Kako poteka primopredaja dokumentacije, dostopov in gesel