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

Artikkel 21 krever en risikovurdering av hele virksomheten, inkludert OT-miljøet. Lær hva kravene betyr i praksis, hvor hullene typisk oppstår, og hvordan du dokumenterer det riktig.

Mange OT-virksomheter forholder seg til NIS2 som om det primært gjelder IT. Det er en misforståelse som kan bli kostbar.

Et sentralt element i NIS2 er artikkel 21, risikovurderingen, som krever at du kartlegger og håndterer risiko knyttet til alle virksomhetens aktiva – inkludert leverandører, lokasjoner og systemer som styrer produksjonslinjer, energianlegg og kritisk infrastruktur.

Hvis OT-miljøene ikke er tatt med i dette arbeidet, sitter dere potensielt med ukjente sårbarheter. I ytterste konsekvens kan mangelen på innsats lamme kritiske samfunnsfunksjoner – og i neste omgang koste dere betydelige bøter når tilsynsmyndighetene kommer på besøk.

Utfordringen er at selv om artikkel 21 er forsøkt skrevet teknologinøytralt, er den i praksis utformet med en IT-logikk i bunnen. OT-miljøer spiller etter helt andre regler.

I denne artikkelen får du derfor en gjennomgang av hva artikkel 21 faktisk krever, hvorfor risikovurderingen er særlig krevende i en OT-kontekst, og hva du konkret kan gjøre med det.

Gjør dere nok ift. NIS2? Les mer her:
NIS2 og OT-sikkerhet: Hvor langt er du kommet – og er det godt nok?

Hva er NIS2 artikkel 21?

Artikkel 21 er direktivets sentrale bestemmelse om cybersikkerhet. Den krever at både vesentlige og viktige enheter iverksetter egnede og forholdsmessige tekniske, operasjonelle og organisatoriske tiltak for å styre risiko – og begrense konsekvensene hvis noe går galt.

Det avgjørende ordet er forholdsmessige. Det betyr at de konkrete tiltakene som kreves for å oppfylle artikkel 21, ikke ser like ut for alle. Hva som er tilstrekkelig, avhenger av:

Virksomhetens grad av risikoeksponering
Virksomhetens størrelse
Sannsynlighet for og alvorlighetsgrad av hendelser, herunder samfunnsmessige og økonomiske konsekvenser

Tiltakene skal dessuten baseres på en all-hazards-tilnærming. Det holder ikke å forholde seg bare til de åpenbare cybertruslene. Alle relevante trusler mot systemenes sikkerhet og fysiske omgivelser må inkluderes.

Og så er det styringskravet: ledelsen skal godkjenne risikovurderingene og sikkerhetstiltakene og bære ansvaret for dem. NIS2-etterlevelse er et ledelsesansvar og kan ikke parkeres i IT-avdelingen.

De 10 minimumskravene – oversatt til OT-virkelighet

I artikkel 21 nr. 2 finner du 10 minimumskrav. På papiret virker de fornuftige nok. Men for en OT-virksomhet er det ofte et stort sprang fra kravets ordlyd til det som faktisk er mulig i praksis.

#	Krav	Hva det betyr i OT-praksis
2a	Retningslinjer for risikoanalyse og informasjonssystemsikkerhet	Risikoanalysen må dekke ICS/SCADA/PLC-systemer – ikke bare IT-infrastruktur. Det krever en metode tilpasset OT-driftslogikk, ikke én som er hentet direkte fra IT-verdenen
2b	Håndtering av hendelser	Beredskapsplaner for hendelser må gjenspeile OT-virkeligheten. Nedetid på en produksjonslinje er ikke det samme som et IT-system som er nede – konsekvensene er umiddelbare og kan ha direkte samfunns- og sikkerhetsmessige følger
2c	Driftskontinuitet, sikkerhetskopiering og krisehåndtering	Sikkerhetskopiering av PLC-konfigurasjoner og SCADA-prosjekter er noe helt annet enn filbackup. Standard IT-løsninger fungerer ikke på eldre OT-systemer, og mange løsepengevirus-angrep retter seg spesifikt mot å eliminere muligheten for gjenoppretting
2d	Forsyningskjedesikkerhet	De største risikoene i OT-forsyningskjeden kommer typisk fra PLC/SCADA-produsenter, systemintegratorer og leverandører av fjerntilgang. Sikkerhetskrav må fremgå av kontrakten og følges opp løpende, ikke bare ved avtaleinngåelse
2e	Sikkerhet ved anskaffelse, utvikling og vedlikehold av systemer, inkl. sårbarhetshåndtering	Mange OT-systemer kan ikke patches uten produksjonsstans. Sårbarhetshåndtering handler her om å ha kompenserende tiltak som holder frem til en oppdatering realistisk kan gjennomføres
2f	Vurdering av effektiviteten av risikotiltakene	Du kan ikke måle effekten av noe du ikke kan se. Passiv nettverksovervåking og anomalideteksjon tilpasset industrielle protokoller er en forutsetning for å oppfylle dette kravet
2g	Cyberhygiene og cybersikkerhetsopplæring	OT-operatører og ingeniører må trenes i cybersikkerhet med utgangspunkt i OT-scenarier. Generiske IT-kurs treffer ikke riktig, og phishing er en reell inngangsvei til industrielle nettverk
2h	Kryptografi og kryptering	Mange eldre OT-enheter støtter ikke moderne krypteringsprotokoller. Det må tas stilling til hva som er teknisk mulig nå, og hva som krever oppgradering eller kompenserende løsninger
2i	Personellsikkerhet, tilgangskontroll og aktivaforvaltning	Mange OT-virksomheter vet ikke nøyaktig hvilke enheter som er på nettverket. Det er et problem som må løses før man i det hele tatt kan snakke om tilgangskontroll
2j	MFA, sikret kommunikasjon og nødkommunikasjonssystemer	Fjerntilgang til OT-systemer er en av de hyppigste angrepsveiene. Den må beskyttes med sterk autentisering – og det gjelder også serviceteknikerens tilgang til PLC-en

Hva er de vanligste hullene i OT-miljøer?

Når OT-virksomheter gjennomfører en gapanalyse opp mot artikkel 21, er det de samme hullene som går igjen. Ikke fordi virksomhetene er uansvarlige, men fordi OT-miljøer er bygget for drift – ikke for dokumentert risikostyring. De fleste manglene handler derfor ikke om vilje, men om strukturelle utfordringer som krever en annen tilnærming enn den IT-verdenen er bygget på.

Les også: 5 grunner til at NIS2 er vanskeligere for OT-virksomheter enn for alle andre

Ingen komplett aktivaoversikt. Du kan ikke lage en risikovurdering av aktiva du ikke vet eksisterer. Mange OT-miljøer har vokst organisk over tiår, og det mangler et samlet overblikk over PLC-er, HMI-er, feltenheter og kommunikasjonsflyter. Dette er ikke bare et teknisk problem – det er et grunnlagsproblem. Resten av risikovurderingen hviler på aktivaoversikten.

Risikovurderingen er bygget på IT-logikk. Tradisjonell informasjonssikkerhetsrisiko handler om konfidensialitet, integritet og tilgjengelighet. I OT er tilgjengelighet og funksjonell sikkerhet alltid førsteprioritet. En risikovurdering som anbefaler å ta ned et system for å patche det, er teknisk korrekt, men operasjonelt uakseptabelt. Metoden må gjenspeile OT-miljøets faktiske prioriteringer.

Eldre systemer kan ikke skannes. Aktiv sårbarhetsskanning kan destabilisere eldre PLC-er og SCADA-systemer eller direkte utløse produksjonsstans. Standardverktøy for risikokartlegging er derfor enten ubrukelige eller farlige. I stedet må man bruke passive overvåkingsmetoder og leverandørdokumentasjon.

Vedlikeholdsvinduene er for snevre. Planlagte nedstenginger i produksjonsmiljøer kan ligge flere måneder frem i tid. NIS2 forutsetter en dynamisk og løpende sårbarhetshåndteringsprosess, og det er en grunnleggende motsetning til OT-miljøets designmål om forutsigbarhet og stabilitet.

IT og OT snakker ikke samme språk. Risikovurderingen krever et felles risikobilde på tvers av to verdener som historisk har operert i siloer. OT-ingeniørene kjenner systemene, men ikke NIS2-kravene. IT-sikkerhetsfolkene kjenner kravene, men ikke systemene. Ledelsen må eie begge deler – og det krever et felles rammeverk.

Kompetansen sitter i hodene, ikke i systemene. Mange virksomheter har en intuitiv forståelse av hva som er risikabelt, men det holder ikke. Artikkel 21 krever dokumenterte retningslinjer og prosedyrer. Den uformelle kunnskapen som den erfarne OT-ingeniøren har med seg, må ut av hodet og inn i dokumentasjonen.

Slik dokumenterer du risikovurderingen din

Artikkel 21 krever ikke bare at du gjennomfører en risikovurdering. Den må dokumenteres, slik at ledelsen kan godkjenne den og tilsynsmyndighetene kan kontrollere den. Her er det du som et minimum må ha på plass.

Aktivaoversikt som fundament. Start med en komplett liste over alle OT-aktiva: PLC-er, HMI-er, SCADA-servere, engineering workstations, feltenheter og kommunikasjonsinfrastruktur. Bruk passiv nettverksovervåking til å avdekke det du ikke visste eksisterte. Oversikten er ikke et engangsprosjekt – den må vedlikeholdes løpende.
Risikovurdering med OT-metode. Ta utgangspunkt i OT-trusler som målrettede angrep mot industrielle systemer, løsepengevirus og sabotasje, samt OT-konsekvenser: produksjonsstans, sikkerhetshendelser og miljøskader. Bruk en metode som kombinerer sannsynlighet og konsekvens, og gjør det tydelig at tilgjengelighet og sikkerhet er det som veier tyngst.
Risikohåndteringsplan med kompenserende tiltak. For aktiva som ikke kan patcheres, må du dokumentere hvilke kompenserende tiltak som er på plass – herunder nettverkssegmentering, anomalideteksjon og tilgangsbegrensning – samt når en permanent løsning forventes.
Dokumentasjon for de 10 minimumskravene. Hvert av de 10 kravene i nr. 2 skal understøttes av en dokumentert kontroll, retningslinje eller prosedyre. Det trenger ikke være 10 separate dokumenter, men det må fremgå hvem som er ansvarlig, hva som gjøres, og når det revideres.
Ledelsens godkjennelse og løpende evaluering. Risikovurderingen skal godkjennes av ledelsen og gjentas regelmessig, eller når det skjer vesentlige endringer i systemer, trusselbilde eller organisasjon. Artikkel 21 nr. 2 (f) krever eksplisitt at det finnes prosedyrer for å vurdere om tiltakene faktisk virker.
Leverandørdokumentasjon. Dokumenter hvilke sikkerhetskrav du stiller til kritiske leverandører, og hvordan du følger opp. Kontraktuelle minimumskrav er utgangspunktet, men det er oppfølgingen som avgjør om det holder i praksis.

Listen ser kanskje lang ut, men de fleste virksomheter starter ikke fra null. De har bare ikke formalisert det som allerede skjer. Derfor handler det om å få oversikt over hvor dere er, og hva som mangler.

Hvordan kommer du i mål med risikovurderingen?

Artikkel 21 er komplisert nok i seg selv, og OT gjør det enda mer komplisert. Men tar du det systematisk og én oppgave om gangen, kommer du i mål.

Og du trenger ikke gjøre det alene.

NorthGRCs OT-workbench er bygget for å håndtere NIS2 med OT-briller. Den samler etterlevelse, risikostyring, leverandørstyring, hendelseshåndtering og dokumentasjon i ett overblikk – tilpasset industrielle miljøer.

Din risikovurdering, dine kompenserende tiltak og din dokumentasjon lever i samme plattform og kan fremvises for både ledelse og tilsyn når det er nødvendig.

Trenger du hjelp underveis, har vi konsulenter med erfaring fra NIS2-implementering i OT-miljøer. Vi kan hjelpe med alt fra den første gap-analysen til løpende vedlikehold – eller ta hele oppgaven hvis det gir mest mening.

Og er du usikker på hvor langt du egentlig har kommet med NIS2-implementeringen som helhet, kan du lese vår artikkel «NIS2: Hvor langt er du, og når er det nok?», som gir et konkret overblikk over modenhetsnivåer og hva som skal til for å nå i mål.