5 grunner til at NIS2 er vanskeligere for OT-virksomheter enn for alle andre

NIS2 stiller særskilte krav til OT-virksomheter. Vi går gjennom de 5 største utfordringene innen NIS2 OT-compliance – og hva dere konkret kan gjøre med dem.

Forholdet mellom NIS2 og OT kan føles som å presse en trekantet kloss gjennom et firkantet hull. Problemet er at NIS2 tar utgangspunkt i IT-miljøer, der informasjonssikkerhet styrer alt – mens OT er bygget rundt én ufravikelig prioritet: å holde driften i gang.

OT-systemer er laget for å kjøre – og å fortsette å kjøre. Når NIS2 nå krever dokumentert risikostyring, rask hendelsesrapportering og lederansvar, oppstår det spenninger som IT-verdenen aldri har møtt på samme måte.

Med de rette strukturene og prosedyrene på plass er det likevel fullt mulig å lykkes med implementeringen – når man først forstår hva utfordringene faktisk består av.

Derfor går vi i denne artikkelen gjennom de fem største NIS2-utfordringene for OT-virksomheter: hva de betyr i praksis, og hva dere kan gjøre med dem.

1. Uten dokumentasjon av eiendelene dine – ingen reell risikovurdering

NIS2 krever en risikovurdering som dekker alle systemer og dataflyter. Det høres overkommelig ut – helt til man stiller det avgjørende spørsmålet: Har dere faktisk dokumentert hva som kjører på OT-nettverket deres?

For mange virksomheter er svaret ærlig talt nei. PLS-er installert for 15 år siden, HMI-systemer som aldri har blitt sentralt registrert, kommunikasjonsprotokoller ingen har dokumentert siden anlegget ble satt opp. Det er ikke et uttrykk for slendrian – det er arven fra tiår der driftsstabilitet alltid veide tyngre enn dokumentasjon.

Under NIS2 er konsekvensen likevel klar: dere kan ikke vurdere risikoen ved systemer dere ikke har dokumentert, dere kan ikke overvåke trafikk fra enheter dere ikke kjenner, og dere kan ikke dokumentere compliance for eiendeler dere ikke har registrert.

Les også: NIS2 artikkel 21: Hva krever risikovurderingen – og hva betyr det for OT?

Cybersikkerhetsselskapet Dragos, som er spesialisert på OT-bransjen, dokumenterer i sin OT Cybersecurity Year in Review (2023) at 80 % av kundene deres manglet tilstrekkelig oversikt på tvers av OT-nettverket – noe som i stor grad vanskeliggjorde både hendelsesdeteksjon og effektiv håndtering.

Hva kan dere gjøre?

• Etabler en strukturert eiendelsregistrering spesifikt for OT-miljøet, basert på passiv nettverksovervåking som bare «lytter» til eksisterende trafikk og dermed ikke forstyrrer sårbare OT-protokoller.
• Suppler passiv overvåking med en manuell gjennomgang av anlegget. Trekk også på eventuelt eksisterende teknisk dokumentasjon, tegninger og servicelogs.
• Prioriter kritiske systemer og prosesser først. En komplett eiendelsoversikt er ikke påkrevd fra dag én, men det er viktig å komme i gang – fordi alt annet i NIS2-compliance bygger på kunnskap om eiendelene deres.

2. NIS2 krever sikkerhetstiltak som i OT-verdenen kan stoppe produksjonen

Driftsstabilitet er alfa og omega i OT, og tilgjengelighet og funksjonssikkerhet trumfer alt annet. Det innebærer at de klassiske sikkerhetsverktøyene fra IT-verdenen – oppdateringer, konfigurasjonsendringer og tofaktorautentisering – enten er teknisk umulige eller medfører produksjonsstopp som kan koste hundretusener av kroner i timen.

I OT-miljøer med sikkerhetskritiske funksjoner kan en feil konfigurasjonsendring dessuten utgjøre en reell fysisk risiko. NIS2 tar ikke hensyn til den faktiske virkeligheten, men stiller likevel krav til egnede sikkerhetstiltak. Det krever en OT-spesifikk tilnærming.

Hva kan dere gjøre?

• Bruk kompenserende kontroller når direkte patching ikke er mulig. Isoler sårbare systemer med nettverkssegmentering, begrens tilgangen til dem og øk overvåkingen av trafikken som går til og fra dem. Dette er en akseptert tilnærming i standarder som IEC 62443 og NIST SP 800-82.
• Kartlegg eksisterende servicevinduer og planlagte produksjonsstopp. Planlegg sikkerhetsoppdateringer i periodene der kostnadene ved nedetid er lavest.
• Unngå å kopiere IT-sikkerhetspraksis direkte over i produksjonsmiljøet. Sikkerhet i OT handler om risikobaserte valg tilpasset den operative virkeligheten.

Les også: NIS2 og OT-sikkerhet: Hvor langt er dere kommet med implementeringen – og er det nok?

3. Leverandøren med fjerntilgang er også en sikkerhetsrisiko

OT-virksomheter er avhengige av et sammensatt nettverk av leverandører: OEM-produsenter, systemintegratorer, serviceteknikere med fjerntilgang til kritiske anlegg, og programvareleverandører der oppdateringssyklusene måles i år – ikke måneder. NIS2 krever at dere håndterer sikkerhetsrisikoen hos dem alle.

Problemet er at dere sjelden kan velge fritt.

Mange OT-systemer forutsetter høyt spesialiserte leverandører der det kanskje bare finnes én eller to kvalifiserte aktører i markedet. Det begrenser forhandlingsposisjonen og gjør det vanskeligere å stille sikkerhetskrav uten å risikere samarbeidet.

Fjerntilgang er en av de mest undervurderte angrepsvektorene i OT-miljøer. Mange virksomheter har gitt et tosifret antall leverandører tilgang til kritiske systemer – ofte via løsninger som aldri har blitt gjennomgått sikkerhetsmessig.

Kaseya-angrepet i 2021 illustrerte presist hva forsyningskjedesårbarheter kan bety i praksis: én enkelt kompromittert leverandør rammet opptil 1 500 virksomheter globalt på én gang, inkludert 14 norske virksomheter. I OT-verdenen er potensialet for fysiske konsekvenser dessuten langt større enn i et rent IT-scenario.

Hva kan dere gjøre?

Kartlegg de kritiske leverandørene og ranger dem etter hvilken tilgang og påvirkning de har på OT-miljøet deres. NIS2 krever ikke at alle leverandører behandles likt – men at dere arbeider risikobasert.

• Innfør kontraktuelle sikkerhetskrav overfor kritiske leverandører. Ved sterk leverandøravhengighet handler det mindre om å bytte leverandør og mer om å dokumentere risikoen og kompensere for den teknisk.
• Hold fjerntilgangen under stram kontroll: logging, tidsbegrensning og krav om MFA som et minimum.
• Ha en plan for hva dere gjør dersom en kritisk leverandør kompromitteres – inkludert om dere reelt sett kan bytte leverandør, eller om dere trenger en nødprosedyre klar i stedet.

4. Når er en hendelse egentlig en hendelse? I OT er svaret ikke rett frem

NIS2 innfører klare rapporteringsfrister: 24 timer til første varsling til myndighetene ved en «vesentlig hendelse», 72 timer til en oppdatert rapport og én måned til en samlet sluttrapport. Men før man kan rapportere, må man ha oppdaget at noe er galt. Og det er her OT-virksomhetenes første reelle problem oppstår.

I IT-miljøer er et løsepengevirusangrep som regel vanskelig å overse. I OT-miljøer kan et kompromittert system manifestere seg som færre avvik – en produksjonsmaskin som kjører litt utenfor toleransen, eller en sensor som leverer data med minimal forsinkelse. Uten spesifikk OT-overvåking kan en hendelse forbli uoppdaget i flere uker.

Det andre problemet er selve vurderingen. NIS2s artikkel 23 definerer en «vesentlig hendelse» som én som har forårsaket, eller er i stand til å forårsake, alvorlig driftsforstyrrelse eller betydelige tap.

For OT-virksomheter er den vurderingen særlig krevende, fordi selv kortvarige hendelser kan få store konsekvenser. Et kort produksjonsstopp kan utløse leveringsbrudd gjennom hele forsyningskjeden. Et kompromittert styresystem kan true personsikkerheten.

Det betyr i praksis at terskelen for når en hendelse er vesentlig, for mange OT-virksomheter er langt lavere enn man kanskje umiddelbart forestiller seg. Og det øker risikoen for enten å overrapportere eller å underrapportere i god tro.

Hva kan dere gjøre?

• Implementer overvåkingsverktøy utviklet for OT-miljøer, som forstår industrielle protokoller. Generiske IT-sikkerhetsverktøy fanger ikke opp OT-spesifikke angrepsmønstre.
• Definer på forhånd hva en «vesentlig hendelse» konkret betyr i deres OT-kontekst, og hvilke scenarioer som utløser rapporteringsplikten. Det er en lederoppgave – ikke en teknisk øvelse.
• Utarbeid klare planer for hvem som eskalerer, hvem som vurderer, og hvem som varsler myndighetene.
• Øv det. En bordøvelse én gang i året, der dere gjennomspiller et scenario fra deteksjon til rapportering, avslører hullene før en reell hendelse gjør det.

5. NIS2 begynner i styrerommet – og det er et skifte mange ikke er forberedt på

NIS2 er det første EU-direktivet som eksplisitt plasserer ansvar for cybersikkerhet hos den øverste ledelsen. Styremedlemmer og direktører kan holdes personlig ansvarlige for manglende etterlevelse, og i alvorlige tilfeller kan de midlertidig fratas retten til å ivareta lederoppgaver.

For mange OT-virksomheter er dette et fundamentalt skifte. Cybersikkerhet har tradisjonelt vært en teknisk driftsoppgave, typisk forankret i IT-avdelingen og langt fra toppledelsens daglige horisont.

Det ender ofte med et velkjent dobbeltproblem: Ledelsen forstår ikke OT-risikoene godt nok til å prioritere dem, og OT-fagfolkene mangler språk og verktøy for å kommunisere risiko på en måte som resonerer i et styrerom.

ECSOs undersøkelser viser at manglende lederengasjement og utilstrekkelige budsjetter er blant de hyppigst nevnte barrierene for NIS2-compliance i europeiske virksomheter.

Hva kan dere gjøre?

• Bruk NIS2s lederansvar som løftestang for å flytte cybersikkerhet fra IT-budsjettet til en strategisk agenda med dedikerte midler.
• Gi ledelsen regelmessige, forståelige risikoorienteringer som oversetter OT-risikoer til forretningsmessige konsekvenser: nedetid, produksjonstap, omdømme og bøter.
• Vurder en ekstern gap-analyse som startpunkt. Den gir ledelsen et faktabasert grunnlag for å ta prioriterte beslutninger – uten å kreve teknisk ekspertise på direktørnivå.
• Husk at NIS2 ikke bare er en risiko. Det er også en mulighet til å få den oppbakingen og de ressursene som sikkerhetsarbeidet i OT-miljøet lenge har manglet.

OTs 5 NIS2-utfordringer henger sammen

Det er fristende å behandle de fem utfordringene som separate prosjekter – men de henger uløselig sammen. Det betyr også at ett skritt fremover sjelden bare løser ett problem. Etter hvert som dere får kontroll på eiendelsbildet, blir både risikovurdering, leverandørstyring og hendelseshåndtering lettere.

Utfordringene henger sammen – og det gjør suksessene også.

Med NIS2-compliance følger dessuten økt beskyttelse mot driftsforstyrrelser ved cyberangrep og andre kriser.

Det er også viktig å huske at NIS2 ikke er et alt-eller-ingenting-prosjekt. NIS2 krever ikke perfeksjon fra dag én, men at dere kan dokumentere at dere arbeider systematisk og risikobasert – og det begynner med et klart bilde av hvor dere står i dag.

Ønsker dere hjelp til å kartlegge den nåværende NIS2-modenheten innen OT? NorthGRC tilbyr strukturerte gapanalyser til produksjons- og forsyningsvirksomheter.

Vi har også en dedikert OT-workbench som samler compliance, risikostyring og hendelseshåndtering i én og samme oversikt. På den måten vet dere nøyaktig hvor dere er – og dere kan samle all dokumentasjonen på ett sted.