5 grunde til NIS2 er sværere for OT-virksomheder end for alle andre

NIS2 stiller særlige krav til OT-virksomheder. Vi gennemgår de 5 største udfordringer inden for NIS2 OT compliance – og hvad I konkret kan gøre ved dem.

Forholdet mellem NIS2 og OT kan føles som at skulle presse en trekantet klods gennem et firkantet hul. Udfordringerne skyldes, at NIS2 er skabt ud fra forholdene i it-miljøer, som er væsensforskellige fra OT, idet informationssikkerheden kommer først i it, mens driften kommer først i OT.

OT-systemer er designet til at køre og blive ved med at køre. Når NIS2 nu kræver dokumenteret risikostyring, hurtig hændelsesrapportering og ledelsesansvar, opstår der konflikter, som it-verdenen aldrig har oplevet på samme måde.

Med de rigtige strukturer og procedurer kan en implementering imidlertid sagtens lykkes – når blot man forstår, hvori udfordringerne reelt består.

Derfor gennemgår vi i denne artikel de fem største NIS2-udfordringer for OT-virksomheder, hvad de konkret betyder i praksis, og hvad I kan gøre ved dem.

1. Uden dokumentation af dine aktiver, ingen reel risikovurdering

NIS2 kræver en risikovurdering, der dækker alle systemer og dataflows. Det lyder håndgribeligt, indtil man stiller spørgsmålet: Har I faktisk dokumenteret, hvad der kører på jeres OT-netværk?

For mange virksomheder er svaret ærligt talt nej. PLC'er installeret for 15 år siden, HMI-systemer der aldrig er blevet registreret centralt, kommunikationsprotokoller ingen har dokumenteret siden anlægget blev bygget. Det er ikke udtryk for sløseri, det er arven fra årtier, hvor driftsstabilitet trumfede dokumentation.

Under NIS2 er konsekvensen imidlertid klar: du kan ikke vurdere risikoen ved systemer, du ikke har dokumenteret, du kan ikke overvåge trafik fra enheder, du ikke kender, og du kan ikke dokumentere compliance for aktiver, du ikke har registreret.

Læs også: Hvad kræver risikovurderingen – og hvad betyder det for OT?

Cybersikkerhedsfirmaet Dragos fokuserer på OT-branchen og i deres OT Cybersecurity Year in Review (2023) dokumenterer de, at 80 % af deres kunder manglede tilstrækkelig synlighed på tværs af OT-netværket, og at det i høj grad vanskeliggjorde både detektion af hændelser og effektiv hændelseshåndtering.

Hvad kan I gøre?

• Etabler en struktureret aktivregistrering specifikt for OT-miljøet med passiv netværksovervågning, som kun “lytter” til den eksisterende trafik og derfor ikke forstyrrer sårbare OT-protokoller.
• Suplér passiv overvågning med en manuel gennemgang af anlægget. Træk desuden på eventuelt eksisterende teknisk dokumentation, tegninger og servicelogs.
• Prioritér kritiske systemer og processer først. Et komplet overblik over aktiver er ikke påkrævet i første omgang, men det er vigtigt at komme i gang, fordi alt andet i NIS2-compliance bygger på viden om jeres aktiver.

2. NIS2 kræver sikkerhedstiltag, der i OT-verdenen kan stoppe produktionen

Driftsstabilitet, det er alfa og omega i OT, hvorfor tilgængelighed og sikkerhed (safety) trumfer alt. Det betyder, at de klassiske sikkerhedsværktøjer fra it-verdenen, opdateringer, konfigurationsændringer og tofaktor autentifikation, er enten teknisk umulige eller forbundet med produktionsstop, der kan koste hundredtusindvis af kroner pr. time.

I OT-miljøer med sikkerhedskritiske funktioner kan en forkert konfigurationsændring desuden udgøre en reel fysisk risiko. NIS2 sætter ikke parentes om den virkelighed, men stiller alligevel krav om passende sikkerhedsforanstaltninger. Det kræver en OT-specifik tilgang.

Hvad kan I gøre?

• Brug kompenserende kontroller, når direkte patching ikke er mulig. Isolér sårbare systemer med netværkssegmentering, begræns adgangen til dem og øg overvågningen af den trafik, der går til og fra dem. Det er en accepteret tilgang i standarder som IEC 62443 og NIST SP 800-82.
• Kortlæg jeres eksisterende servicevindue og planlagte produktionsstop. Planlæg desuden sikkerhedsopdateringer i de perioder, hvor omkostningen ved nedetid er lavest.
• Undgå at kopiere it-sikkerhedspraksis direkte over i produktionsmiljøet. Sikkerhed i OT handler om risikobaserede valg tilpasset den operationelle virkelighed.

Læs også: NIS2 og OT-sikkerhed: Hvor langt er du med implementeringen – og er det nok?

3. Leverandøren med fjernadgang er også en sikkerhedsrisiko

OT-virksomheder er afhængige af et komplekst netværk af leverandører: OEM-producenter, systemintegratorer, serviceteknikere, der har fjernadgang til kritiske anlæg, og softwareleverandører, hvis opdateringscyklus måles i år, ikke måneder. NIS2 kræver, at I håndterer sikkerhedsrisici hos dem alle.

Problemet er, at I sjældent kan vælge frit.

Mange OT-systemer kræver højt specialiserede leverandører, hvor der måske kun er én eller to kvalificerede aktører på markedet. Det begrænser forhandlingspositionen og gør det sværere at stille sikkerhedskrav uden at risikere samarbejdet.

Fjernadgang er en af de mest undervurderede angrebsvektorer i OT-miljøer. Mange virksomheder har givet et tocifret antal leverandører adgang til kritiske systemer, ofte via løsninger, der aldrig er blevet gennemgået sikkerhedsmæssigt.

Kaseya-angrebet i 2021 illustrerede præcis, hvad forsyningskædesårbarheder kan betyde i praksis: en enkelt kompromitteret leverandør ramte op til 1.500 virksomheder globalt på én gang, herunder 14 danske virksomheder. I OT-verdenen er potentialet for fysiske konsekvenser derudover langt større end i et rent it-scenarie.

Hvad kan I gøre?

• Kortlæg jeres kritiske leverandører og rangér dem efter den adgang og indflydelse, de har på jeres OT-miljø. NIS2 kræver ikke, at alle leverandører behandles ens, men at I arbejder risikobaseret.
• Indfør kontraktuelle sikkerhedskrav til kritiske leverandører. Ved stærk leverandørafhængighed handler det mindre om at vælge en anden leverandør og mere om at dokumentere risikoen og kompensere for den teknisk.
• Styr fjernadgang stramt: logning, tidsafgrænsning og krav om MFA som minimum.
• Hav en plan for, hvad I gør, hvis en kritisk leverandør kompromitteres – herunder om I reelt kan skifte leverandør, eller om I skal have en nødprocedure klar i stedet.

4. Hvornår er en hændelse egentlig en hændelse? I OT er svaret ikke ligetil

NIS2 indfører klare rapporteringsfrister: 24 timer til første notifikation til myndighederne ved en "væsentlig hændelse", 72 timer til en opdateret rapport og én måned til en samlet slutrapport. Men før man kan rapportere, skal man have opdaget, at noget er galt. Og her opstår OT-virksomheders første reelle problem.

I it-miljøer er et ransomware-angreb som regel svært at overse. I OT-miljøer kan et kompromitteret system manifestere sig som mindre afvigelser, en produktionsmaskine der kører lidt uden for tolerancen, en sensor der leverer data med minimal forsinkelse. Uden specifik OT-overvågning kan en hændelse forblive uopdaget i uger.

Det andet problem er selve vurderingen. NIS2's artikel 23 definerer en "væsentlig hændelse" som én, der har forårsaget eller er i stand til at forårsage alvorlig driftsforstyrrelse eller betydelige tab.

For OT-virksomheder er den vurdering særlig vanskelig, fordi selv en kortvarig hændelse kan have enorme konsekvenser. Et kort produktionsstop kan udløse leveringsbrud i en hel forsyningskæde. Et kompromitteret styresystem kan true personsikkerheden.

Det betyder i praksis, at tærsklen for, hvornår en hændelse er væsentlig for mange OT-virksomheder, er meget lavere end man måske umiddelbart forestiller sig. Og det øger risikoen for enten at overrapportere eller at underrapportere i god tro.

Hvad kan I gøre?

• Implementér overvågning designet til OT-miljøer, der forstår industrielle protokoller. Generiske it-sikkerhedsværktøjer opdager ikke OT-specifikke angrebsmønstre.
• Definer på forhånd, hvad en "væsentlig hændelse" konkret betyder i jeres OT-kontekst, og hvilke scenarier der udløser rapporteringspligten. Det er en ledelsesopgave, ikke en teknisk øvelse.
• Udarbejd klare planer for, hvem der eskalerer, hvem der vurderer, og hvem der notificerer myndighederne.
• Øv det. En skrivebordsøvelse én gang om året, hvor I gennemspiller et scenarie fra detektion til rapportering, afslører hullerne, inden en reel hændelse gør det.

5. NIS2 begynder i bestyrelseslokalet – og det er et skift, mange ikke er klar til

NIS2 er det første EU-direktiv, der eksplicit placerer ansvar for cybersikkerhed hos den øverste ledelse. Bestyrelsesmedlemmer og direktører kan holdes personligt ansvarlige for manglende overholdelse, og i grove tilfælde kan de midlertidigt fratages retten til at varetage ledelsesopgaver.

For mange OT-virksomheder er det et fundamentalt skift. Cybersikkerhed har traditionelt været en teknisk driftsopgave, typisk forankret i it-afdelingen og langt fra topledelsens daglige radar.

Det ender ofte med et velkendt dobbeltproblem: ledelsen forstår ikke OT-risici godt nok til at prioritere dem, og OT-folkene mangler sprog og værktøjer til at kommunikere risici på en måde, der resonerer i et bestyrelseslokale.

ECSO's undersøgelser viser, at manglende ledelsesengagement og utilstrækkelige budgetter er blandt de hyppigst nævnte barrierer for NIS2-compliance i europæiske virksomheder.

Hvad kan I gøre?

• Brug NIS2's ledelsesansvar som løftestang til at flytte cybersikkerhed fra it-budgettet til en strategisk dagsorden med dedikerede midler.
• Giv ledelsen regelmæssige, forståelige risikobriefings, der oversætter OT-risici til forretningsmæssige konsekvenser: nedetid, produktionstab, omdømme og bøder.
• Overvej en ekstern gap-analyse som udgangspunkt. Den giver ledelsen et faktabaseret grundlag for at træffe prioriterede beslutninger uden at kræve teknisk ekspertise på direktørniveau.
• Husk, at NIS2 ikke kun er en risiko. Det er også en mulighed for at få den opbakning og de ressourcer, som sikkerhedsarbejdet i OT-miljøet har manglet.

OT’s 5 udfordringer med NIS2 hænger sammen

Det er fristende at behandle de fem udfordringer som separate projekter, men de hænger uløseligt sammen. Det betyder også, at et skridt fremad ét sted sjældent kun løser ét problem. I takt med at I får styr på aktivoverblikket, bliver både risikovurdering, leverandørstyring, og hændelseshåndtering nemmere på samme tid.

Udfordringerne hænger sammen, men det gør succeserne således også. Med NIS2-compliance følger desuden øget beskyttelse mod driftsforstyrrelser i tilfælde af cyberangreb og andre kriser.

Det er også vigtigt at huske, at NIS2 ikke er et alt-eller-intet-projekt. NIS2 kræver ikke perfektion fra dag ét, men at I kan dokumentere, at I arbejder systematisk og risikobaseret, og det begynder med et klart billede af, hvor I er i dag.

Vil I have hjælp til at kortlægge jeres nuværende NIS2-modenhed inden for OT? NorthGRC tilbyder strukturerede gap-analyser til produktions- og forsyningsvirksomheder.

Vi har også en dedikeret OT-workbench, der samler compliance, risikostyring og hændelseshåndtering i ét overblik. På den måde ved I præcis, hvor I er, og I kan samle dokumentationen ét sted.