Artikel 21 kræver en risikovurdering af hele virksomheden, også OT-miljøet. Lær hvad kravene betyder i praksis, hvor hullerne typisk er, og hvordan du dokumenterer det rigtigt.
Mange OT-virksomheder behandler NIS2, som om det primært handler om it. Det er imidlertid en misforståelse, der kan blive dyr.
Et centralt element i NIS2 er artikel 21, risikovurderingen, som kræver, at du kortlægger og håndterer risici for alle de aktiver, virksomheden bruger – inklusive leverandører, lokationer og systemer, der styrer produktionslinjer, energianlæg og kritisk infrastruktur.
Hvis OT-miljøerne ikke er tænkt med i det arbejde, bærer I potentielt rundt på ukendte sårbarheder. I sidste ende kan den manglende indsats først og fremmest lamme kritiske samfundsfunktioner – og dernæst koste jer tunge bøder, når tilsynsmyndighederne kommer forbi.
Udfordringen er bare, at selv om artikel 21 er forsøgt skrevet teknologineutralt, er den reelt designet med it-logik, og OT-miljøer spiller efter helt andre regler.
I denne artikel kan du derfor blive klogere på, hvad artikel 21 faktisk kræver, hvorfor risikovurderingen er særlig svær i en OT-kontekst, og hvad du konkret kan gøre ved det.
Gør I nok ift. NIS2? Bliv klogere her:
NIS2 og OT-sikkerhed: Hvor langt er du med implementeringen – og er det nok?
Artikel 21 er direktivets centrale bestemmelse om cybersikkerhed. Den kræver, at både væsentlige og vigtige enheder træffer passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger for at styre risici – og begrænse konsekvenserne, hvis noget går galt.
Det afgørende ord er forholdsmæssige. Det betyder nemlig, at de konkrete tiltag, der skal til for at imødekomme artikel 21, ikke ser ens ud for alle. Hvad der er tilstrækkeligt, afhænger af:
Foranstaltningerne skal desuden baseres på en all-hazards-tilgang. Det betyder, at det ikke er nok at forholde sig til de oplagte cybertrusler. Alle relevante trusler mod systemernes sikkerhed og fysiske omgivelser skal medtages.
Og så er der governance-kravet: ledelsen skal godkende risikovurderingerne og sikkerhedsforanstaltningerne og bære ansvaret for dem. NIS2-compliance er et ledelsesanliggende og dermed ikke noget, der kan parkeres hos it-afdelingen.
Artikel 21, stk. 2, opstiller 10 minimumskrav. De lyder rimelige nok på papiret. Men for en OT-virksomhed er der ofte et stykke vej fra kravets ordlyd til det, der faktisk er muligt i praksis.
|
# |
Krav |
Hvad det betyder i OT-praksis |
|
2a |
Politikker for risikoanalyse og informationssystemsikkerhed |
Risikoanalysen skal dække ICS/SCADA/PLC-systemer – ikke kun it-infrastruktur. Det kræver en metode, der er tilpasset OT's driftslogik, ikke én der er løftet direkte fra it |
|
2b |
Håndtering af hændelser |
Incident response-planer skal afspejle OT-virkeligheden. En nedetid på en produktionslinje er ikke det samme som et it-system, der er nede, idet konsekvenserne er øjeblikkelige og kan have direkte samfunds- og sikkerhedsmæssige følger |
|
2c |
Driftskontinuitet, backup og krisestyring |
Backup af PLC-konfigurationer og SCADA-projekter er noget helt andet end backup af filer. Standard it-løsninger virker ikke på legacy OT-systemer og mange ransomware-angreb sigter specifikt efter at fjerne muligheden for gendannelse |
|
2d |
Forsyningskædesikkerhed |
De største risici i OT-forsyningskæden kommer typisk fra PLC/SCADA-producenter, systemintegratorer og udbydere af fjernadgang. Sikkerhedskrav skal stå i kontrakten og følges op på løbende, ikke kun ved aftalens indgåelse |
|
2e |
Sikkerhed ift. erhvervelse, udvikling og vedligeholdelse af systemer, inkl. sårbarhedshåndtering |
Mange OT-systemer kan ikke patches uden produktionsstop. Sårbarhedshåndtering handler her om at have kompenserende kontroller, der holder, indtil en opdatering realistisk kan gennemføres |
|
2f |
Vurdering af effektiviteten af risikoforanstaltningerne |
Du kan ikke måle effekten af noget, du ikke kan se. Passiv netværksovervågning og anomalidetektion tilpasset industrielle protokoller er en forudsætning for at opfylde dette krav |
|
2g |
Cyberhygiejne og cybersikkerhedsuddannelse |
OT-operatører og ingeniører skal trænes i cybersikkerhed med afsæt i OT-scenarier. Generiske it-kurser rammer forbi og phishing er en reel indgangsvektor til industrielle netværk |
|
2h |
Kryptografi og kryptering |
Mange ældre OT-enheder understøtter ikke moderne krypteringsprotokoller. Der skal tages stilling til, hvad der er teknisk muligt nu, og hvad der kræver opgradering eller kompenserende løsninger |
|
2i |
Personalesikkerhed, adgangskontrol og aktivstyring |
Mange OT-virksomheder ved ikke præcis, hvilke enheder der er på netværket. Det er et problem, der skal løses, inden man overhovedet kan tale om adgangskontrol |
|
2j |
MFA, sikret kommunikation og nødkommunikationssystemer |
Fjernadgang til OT-systemer er en af de hyppigste angrebsvektorer. Den skal beskyttes med stærk autentificering, og det gælder også serviceteknikerens adgang til PLC'en |
Når OT-virksomheder laver en gap-analyse op imod artikel 21, er det de samme huller, der går igen. Ikke fordi virksomhederne er uansvarlige, men fordi OT-miljøer er bygget til drift, ikke til dokumenteret risikostyring. De fleste gaps handler derfor ikke om manglende vilje, men om strukturelle udfordringer, der kræver en anden tilgang end den, som it-verdenen er formet af.
Læs også: 5 grunde til NIS2 er sværere for OT-virksomheder end for alle andre
Ingen komplet aktivoversigt. Du kan ikke lave en risikovurdering af aktiver, du ikke har dokumenteret eller ved eksisterer. Mange OT-miljøer er vokset organisk over årtier, og der mangler et samlet overblik over PLC'er, HMI'er, feltenheder og kommunikationsflows. Det er ikke kun et teknisk problem, det er et forudsætningsproblem. Resten af risikovurderingen hviler på aktivoversigten.
Risikovurderingen er bygget på it-logik. Traditionel informationssikkerhedsrisiko drejer sig om fortrolighed, integritet og tilgængelighed. I OT er tilgængelighed og funktionel sikkerhed altid førsteprioritet. En risikovurdering, der anbefaler at lukke et system ned for at patche det, er teknisk korrekt, men operationelt uacceptabel. Metoden skal afspejle OT's virkelige prioriteter.
Legacy-systemer kan ikke scannes. Aktiv sårbarhedsscanning kan destabilisere ældre PLC'er og SCADA-systemer eller direkte udløse produktionsstop. Standardværktøjer til risikokortlægning er derfor enten ubrugelige eller farlige. I stedet skal man anvende passive overvågningsmetoder og leverandørdokumentation.
Vedligeholdelsesvinduerne er for snævre. Planlagte nedlukninger i produktionsmiljøer kan ligge måneder ude i fremtiden. NIS2 forudsætter en dynamisk og løbende sårbarhedshåndteringsproces, og det er en grundlæggende modsætning til OT's designmål om forudsigelighed og stabilitet.
It og OT taler ikke samme sprog. Risikovurderingen kræver et fælles risikobillede på tværs af to verdener, der historisk har opereret i siloer. OT-ingeniørerne kender systemerne, men ikke NIS2-kravene. It-sikkerhedsfolkene kender kravene, men ikke systemerne. Ledelsen skal eje begge dele, og det kræver en fælles ramme.
Viden sidder i hovederne, ikke i systemerne. Mange virksomheder har en intuitiv forståelse af, hvad der er risikabelt, men det er ikke nok. Artikel 21 kræver dokumenterede politikker og procedurer. Den uformelle viden hos den erfarne OT-ingeniør skal ud af hans hoved og ned i dokumentationen.
Artikel 21 kræver ikke blot, at du gennemfører en risikovurdering. Den skal dokumenteres, så ledelsen kan godkende den, og tilsynsmyndighederne kan kontrollere den. Her er det, du som minimum skal have styr på.
Listen ser måske lang ud, men de fleste virksomheder starter ikke på nul. De har bare ikke fået formaliseret det, der allerede sker. Derfor handler det om at få styr på, hvor du er, og hvad der mangler.
Artikel 21 er kompliceret nok i sig selv, og OT gør det endnu mere kompliceret, men hvis du griber det systematisk an og tager opgaverne én ad gangen, så skal du nok komme i mål.
Og du behøver ikke gøre det alene.
NorthGRC's OT-workbench er bygget til at håndtere NIS2 med OT-briller. Den samler compliance, risikostyring, leverandørstyring, hændelseshåndtering og dokumentation i ét overblik, tilpasset industrielle miljøer.
Din risikovurdering, dine kompenserende kontroller og din dokumentation lever i samme platform og kan vises frem for både ledelse og tilsyn, når det er nødvendigt.
Har du brug for hjælp undervejs, har vi konsulenter med erfaring i NIS2-implementering i OT-miljøer. Vi kan hjælpe med alt fra den første gap-analyse til den løbende vedligeholdelse, eller tage hele opgaven, hvis det giver mest mening.
Og er du i tvivl om, hvor langt du egentlig er kommet med NIS2-implementeringen som helhed, kan du læse vores artikel "NIS2: Hvor langt er du og hvornår er det nok?", der giver et konkret overblik over modenhedsniveauer og hvad der skal til for at nå i mål.