NIS2 OT-sikkerhed: kortlægning til ISO 27001 og IEC 62443

Kl. 02:17 en mandag modtager en operatør på et vandbehandlingsanlæg en alarm fra et doseringssystem. Kemikalietilførslen er stadig inden for sikkerhedsgrænserne, men én PLC rapporterer uregelmæssige kommandoer, en engineering workstation viser mislykkede loginforsøg fra en leverandørs VPN-konto, og den vagthavende SOC-analytiker stiller et spørgsmål, ingen ønsker at besvare under pres.

Er dette en IT-hændelse, en OT-hændelse, en safety-hændelse eller en væsentlig hændelse, der skal rapporteres efter NIS2?

Anlægget har firewalls. Det har ISO-dokumentation. Det har et leverandørregneark. Det har endda en hændelseshåndteringsplan. Men planen blev skrevet til kompromitterede e-mailkonti og cloudnedbrud, ikke til en ældre controller, der ikke kan patches under produktion, en leverandør, der har brug for fjernadgang for at genetablere tjenesten, og en tilsynsmyndighed, der forventer bevismateriale inden for NIS2-rapporteringsfristerne.

Det samme problem viser sig i bestyrelseslokalet. En CISO hos en regional energileverandør kan have et ISO/IEC 27001:2022-certificeret ledelsessystem for informationssikkerhed for virksomhedens IT, mens OT-landskabet stadig er et virvar af PLC’er, RTU’er, HMI’er, historian-systemer, engineering workstations, industrielle switche og leverandørers adgangsveje. Den administrerende direktørs spørgsmål er enkelt: “Er vi dækket? Kan du dokumentere det?”

For mange væsentlige og vigtige enheder er det ærlige svar ubehageligt. De er delvist dækket. De kan delvist dokumentere det. Men NIS2 OT-sikkerhed kræver mere end generisk IT-compliance.

Det kræver en samlet driftsmodel, der forbinder governance i ISO/IEC 27001:2022, kontrolsproget i ISO/IEC 27002:2022, industrielle engineering-praksisser i IEC 62443, cybersikkerhedsrisikostyringstiltag i NIS2 Article 21 og bevismateriale til hændelsesrapportering efter NIS2 Article 23.

Det er den bro, denne vejledning bygger.

Hvorfor NIS2 OT-sikkerhed adskiller sig fra almindelig IT-compliance

NIS2 gælder for mange offentlige og private enheder, der leverer omfattede tjenester i EU, herunder væsentlige og vigtige enheder på tværs af sektorer såsom energi, transport, bankvirksomhed, finansiel markedsinfrastruktur, sundhed, drikkevand, spildevand, digital infrastruktur, IKT-tjenestestyring, offentlig forvaltning, rumfart, posttjenester, affaldshåndtering, fremstilling, kemikalier, fødevarer, digitale udbydere og forskning.

Direktivet kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger til at styre cyberrisici, forebygge eller minimere hændelsers påvirkning og beskytte tjenesternes kontinuitet. Article 21 omfatter en all hazards-tilgang, der dækker risikoanalyse, sikkerhedspolitikker, hændelseshåndtering, forretningskontinuitet, krisestyring, sikkerhed i forsyningskæden, sikker anskaffelse og vedligeholdelse, håndtering og offentliggørelse af sårbarheder, effektivitetsvurdering, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring, aktivstyring, MFA eller løbende autentifikation, sikker kommunikation og nødkommunikation, hvor det er relevant.

Disse krav lyder velkendte for et ISO/IEC 27001:2022-team. I OT opfører hvert krav sig anderledes.

En sårbarhed i en webserver kan ofte patches inden for få dage. En sårbarhed i en turbinecontroller kan kræve leverandørvalidering, et vedligeholdelsesvindue, en safety-gennemgang og fallback-driftsprocedurer. En bærbar computer kan geninstalleres. En produktions-HMI kan være afhængig af et ældre operativsystem, fordi den industrielle applikation ikke er certificeret til en nyere platform. En SOC-playbook kan sige “isoler værten”, mens OT-ingeniøren svarer: “Ikke før vi ved, om isolering påvirker trykstyringen.”

Forskellen er ikke kun teknisk. IT prioriterer typisk fortrolighed, integritet og tilgængelighed. OT prioriterer tilgængelighed, procesintegritet og safety. En sikkerhedskontrol, der introducerer latenstid, kræver genstart eller afbryder en fysisk proces, kan være uacceptabel uden engineering-godkendelse.

NIS2 fritager ikke OT fra cybersikkerhedsrisikostyring. Direktivet forventer, at organisationen dokumenterer, at kontrollerne er passende i forhold til risikoen og proportionale med den operationelle virkelighed.

Kontrolstakken: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 og IEC 62443

Et forsvarligt NIS2 OT-sikkerhedsprogram starter med en lagdelt kontrolstak.

ISO/IEC 27001:2022 leverer ledelsessystemet. Standarden kræver, at organisationen definerer kontekst, interessenter, regulatoriske forpligtelser, ISMS-omfang, grænseflader og afhængigheder. Den kræver også ledelsesmæssigt ejerskab, en informationssikkerhedspolitik, risikovurdering, risikobehandling, en anvendelighedserklæring, dokumenteret information, intern revision, ledelsens gennemgang og løbende forbedring.

ISO/IEC 27002:2022 leverer kontrolterminologien. For OT omfatter de vigtigste kontroller ofte leverandørsikkerhed, styring af IKT-forsyningskæderisiko, hændelsesplanlægning, IKT-beredskab for forretningskontinuitet, juridiske og kontraktlige krav, aktivstyring, adgangsstyring, sårbarhedsstyring, backups, logning, overvågning, netværkssikkerhed og funktionsadskillelse af netværk.

IEC 62443 leverer den industrielle security engineering-model. Den hjælper med at omsætte krav til ledelsessystemet til OT-praksisser såsom zoner, conduits, sikkerhedsniveauer, aktivejeransvar, systemintegratoransvar, forventninger til produktleverandører, begrænsninger for fjernadgang, mindste funktionalitet, kontostyring, hærdning og livscykluskontroller.

Clarysec bruger denne stak, fordi den undgår to almindelige fejl. For det første forhindrer den, at ISO-implementeringen bliver for generisk til OT. For det andet forhindrer den, at IEC 62443-engineeringarbejde bliver afkoblet fra bestyrelsesansvar, NIS2-rapporteringsforpligtelser og revisionsbevismateriale.

Clarysecs IoT / OT Security Policy beskriver broen direkte:

For at sikre, at alle implementeringer er tilpasset ISO/IEC 27001-kontroller og relevant sektorspecifik vejledning (f.eks. IEC 62443, ISO 27019, NIST SP 800-82).

Den sætning er vigtig. Politikken er ikke kun en tjekliste for enhedshærdning. Den forbinder ISO-governance, sektorspecifik OT-vejledning og operationel sikkerhed.

Start med omfanget: hvilken OT-tjeneste skal beskyttes?

Før kontroller kortlægges, skal OT-tjenesten defineres i forretningsmæssigt og regulatorisk sprog.

En anlægsleder kan sige: “Vi driver pakkelinjen.” En NIS2-vurdering bør sige: “Denne produktionsproces understøtter en væsentlig eller vigtig tjeneste og afhænger af PLC’er, HMI’er, engineering workstations, historian-systemer, industrielle switche, fjernadgang for leverandører, en vedligeholdelsesleverandør, et cloudbaseret analysefeed og en fælles identitetstjeneste for organisationen.”

ISO/IEC 27001:2022 clauses 4.1 til 4.4 er nyttige, fordi de tvinger organisationen til at identificere interne og eksterne forhold, interessenter, juridiske og kontraktlige krav, ISMS-grænser, grænseflader og afhængigheder. For NIS2 OT-sikkerhed betyder det kortlægning af ikke kun hovedkontorets netværk, men også de industrielle systemer og tjenesteafhængigheder, der påvirker kontinuitet, safety og reguleret levering.

NIST CSF 2.0 forstærker samme logik. Dets GOVERN-funktion kræver forståelse af mission, interessenter, afhængigheder, juridiske og regulatoriske forpligtelser, kritiske tjenester og tjenester, som organisationen afhænger af. Organisatoriske profiler giver en praktisk metode til at afgrænse en nuværende tilstand, definere en ønsket tilstand, analysere huller og udarbejde en prioriteret handlingsplan.

For et OT-miljø starter Clarysec typisk med fem spørgsmål:

1. Hvilken reguleret eller kritisk tjeneste understøtter dette OT-miljø?
2. Hvilke OT-aktiver, netværk, dataflows og tredjeparter er nødvendige for denne tjeneste?
3. Hvilke safety-, tilgængeligheds- og driftsmæssige begrænsninger påvirker sikkerhedskontrollerne?
4. Hvilke juridiske, kontraktlige og sektorspecifikke forpligtelser gælder, herunder NIS2, GDPR, DORA hvor relevant, kundekontrakter og nationale regler?
5. Hvilke dele af miljøet er inden for ISMS, og hvilke er eksterne afhængigheder, der kræver leverandørkontroller?

Mange NIS2-programmer fejler her. De afgrænser omkring virksomhedens IT, fordi det er lettere at føre fortegnelse over. Revisorer og tilsynsmyndigheder vil ikke blive imponerede, hvis den mest kritiske tjenesteafhængighed kun fremgår som en vag post kaldet “fabriksnetværk”.

En praktisk NIS2 OT-kontrolkortlægning

Tabellen nedenfor viser, hvordan NIS2 Article 21-temaer kan omsættes til bevismateriale for ISO/IEC 27001:2022, ISO/IEC 27002:2022 og IEC 62443. Den erstatter ikke en formel risikovurdering, men giver CISO’er, OT-ledere og compliance-teams et praktisk udgangspunkt.

Denne kortlægning er bevidst fokuseret på bevismateriale. Under NIS2 er det ikke nok at sige “vi har segmentering”. Man skal dokumentere, hvorfor segmenteringen er passende, hvordan den er implementeret, hvordan undtagelser godkendes, og hvordan designet reducerer påvirkningen af den regulerede tjeneste.

Segmentering: den første OT-kontrol revisorer vil teste

Hvis hændelsen kl. 02:17 involverede en angriber, der bevægede sig fra en kontor-pc til en engineering workstation, ville det første revisionsspørgsmål være oplagt: Hvorfor kunne den vej eksistere?

IoT / OT Security Policy er eksplicit:

OT-systemer skal køre i særskilte netværk, der er isoleret fra virksomhedens IT og internetvendte systemer.

For mindre miljøer giver Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME en praktisk baseline:

Alle Internet of Things (IoT)- og Operational Technology (OT)-enheder skal placeres på et separat Wi‑Fi- eller VLAN-netværk

For en moden operatør af kritisk infrastruktur bør segmentering designes omkring OT-zoner og conduits. Virksomhedsbrugere bør ikke have direkte adgang til PLC-netværk. Leverandørforbindelser bør terminere i kontrollerede adgangszoner. Historian-replikering bør bruge godkendte stier. Safety-systemer bør isoleres efter risiko og engineering-krav. Trådløse OT-netværk bør begrundes, hærdes og overvåges.

Zenith Blueprint: An Auditor’s 30-Step Roadmap forklarer i fasen Controls in Action, Step 20, princippet bag ISO/IEC 27002:2022-netværkssikkerhed:

Industrielle kontrolsystemer bør isoleres fra kontortrafik.

Den advarer også om, at netværkssikkerhed kræver sikker arkitektur, segmentering, adgangsstyring, kryptering under overførsel, overvågning og defense in depth.

I Zenith Controls: The Cross-Compliance Guide behandles ISO/IEC 27002:2022 control 8.22, Segregation of Networks, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset Protect-cybersikkerhedskonceptet, har system- og netværkssikkerhed som operationel kapacitet og Protection som sikkerhedsdomæne.

Denne klassificering er nyttig som NIS2-bevismateriale, fordi segmentering ikke er et dekorativt diagram. Det er en forebyggende kontrol, der er designet til at reducere blast radius og bevare kontinuiteten i væsentlige tjenester.

Sårbarhedsstyring, når OT-systemer ikke bare kan patches

NIS2 kræver sikker anskaffelse, udvikling og vedligeholdelse af net- og informationssystemer, herunder håndtering og offentliggørelse af sårbarheder. I IT betyder sårbarhedsstyring ofte scan, prioriter, patch og verificer. OT tilføjer begrænsninger.

En kritisk HMI kan måske kun patches under et planlagt driftsstop. En PLC-firmwareopdatering kan kræve leverandørinvolvering. Et safety-certificeret system kan miste certificeringen, hvis det ændres forkert. Nogle ældre enheder har slet ingen leverandørsupport.

Zenith Blueprint, fasen Controls in Action, Step 19, giver den rette revisionslogik for tekniske sårbarheder:

For systemer, der ikke kan patches med det samme, måske på grund af ældre software eller begrænsninger vedrørende nedetid, skal der implementeres kompenserende kontroller. Det kan omfatte isolering af systemet bag en firewall, begrænsning af adgang eller øget overvågning. I alle tilfælde skal forholdet registreres, og restrisikoen accepteres formelt, så det dokumenteres, at problemet ikke er glemt.

SME-politikkens baseline er tilsvarende praktisk:

Aktivfortegnelsen skal gennemgås kvartalsvist for at identificere forældede, ikke-understøttede eller upatchede enheder

I Zenith Controls kortlægges ISO/IEC 27002:2022 control 8.8, Management of Technical Vulnerabilities, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset Identify og Protect, med trussel- og sårbarhedsstyring som operationel kapacitet på tværs af Governance-, Ecosystem-, Protection- og Defense-domænerne.

En stærk OT-sårbarhedsfil bør omfatte:

• Aktividentifikator, ejer, zone og kritikalitet
• Sårbarhedskilde, såsom leverandørmeddelelse, scanner, integratormeddelelse eller trusselsintelligens
• Safety- og tilgængelighedsbegrænsninger
• Mulighed for patching og planlagt vedligeholdelsesvindue
• Kompenserende kontroller, såsom isolering, adgangskontrollister, deaktiverede tjenester eller øget overvågning
• Godkendelse fra risikoejer og accept af restrisiko
• Verifikationsbevismateriale efter afhjælpning eller implementering af kompenserende kontrol

Det gør “vi kan ikke patche” fra en undskyldning til revisionsbar risikobehandling.

Fjernadgang for leverandører: brændpunktet mellem NIS2 og IEC 62443

De fleste OT-hændelser har et tredjepartselement et sted. En leverandørkonto. En integrator-laptop. Et værktøj til fjernvedligeholdelse. Delte legitimationsoplysninger. En firewallundtagelse, der var midlertidig for tre år siden.

NIS2 Article 21 omfatter eksplicit sikkerhed i forsyningskæden, leverandørspecifikke sårbarheder, leverandørers cybersikkerhedspraksis og procedurer for sikker udvikling. NIST CSF 2.0 er også detaljeret på dette punkt gennem leverandørkritikalitet, kontraktkrav, due diligence, løbende overvågning, hændelseskoordinering og bestemmelser om leverandørafslutning.

Clarysecs Third-Party and Supplier Security Policy - SME angiver princippet i klart sprog:

Leverandører må kun tildeles adgang til de minimale systemer og data, der er nødvendige for at udføre deres funktion.

For OT betyder minimal adgang mere end rollebaseret adgang i en applikation. Leverandøradgang bør være:

• Forhåndsgodkendt til et defineret vedligeholdelsesformål
• Tidsbegrænset og som standard deaktiveret
• Beskyttet med MFA eller løbende autentifikation, hvor det er relevant
• Dirigeret gennem en sikker jump host eller kontrolleret fjernadgangsplatform
• Begrænset til den relevante OT-zone eller det relevante aktiv
• Logget, overvåget og, ved højrisikoadgang, sessionsregistreret
• Gennemgået efter afslutning
• Dækket af kontraktlige forpligtelser om sikkerhed og hændelsesunderretning

Virksomhedens IoT / OT Security Policy indeholder et særskilt krav til fjernadgang:

Fjernadgang (til administration eller leverandørservice) skal:

Denne klausul forankrer styringspunktet, mens de detaljerede krav bør implementeres i adgangsprocedurer, leverandøraftaler, teknisk konfiguration og arbejdsgange for overvågning.

I Zenith Controls klassificeres ISO/IEC 27002:2022 control 5.21, Managing information security in the ICT supply chain, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed, er tilpasset Identify-konceptet, har sikkerhed i leverandørrelationer som operationel kapacitet og Governance, Ecosystem og Protection som domæner.

For OT hjælper denne kortlægning med at forklare, hvorfor bevismateriale for fjernadgang hører til i leverandørrisiko, identitetsgovernance, netværkssikkerhed, hændelseshåndtering og kontinuitetsfiler på samme tid.

Hændelseshåndtering: NIS2-uret møder kontrolrummet

Tilbage til alarmen kl. 02:17. Organisationen skal afgøre, om hændelsen er væsentlig efter NIS2. Article 23 kræver underretning uden unødig forsinkelse om væsentlige hændelser, der påvirker levering af tjenester. Sekvensen omfatter en tidlig varsling inden for 24 timer efter kendskab, en hændelsesunderretning inden for 72 timer, mellemliggende opdateringer, hvis de anmodes om, og en endelig rapport senest én måned efter hændelsesunderretningen eller en statusrapport, hvis hændelsen stadig er i gang.

I OT skal hændelseshåndtering besvare spørgsmål, som IT-playbooks ofte overser:

• Kan den berørte enhed isoleres uden at skabe en safety-risiko?
• Hvem har bemyndigelse til at stoppe produktion eller skifte til manuel tilstand?
• Hvilke logfiler er flygtige og skal bevares straks?
• Hvilken leverandør eller integrator skal kontaktes?
• Er hændelsen ondsindet, utilsigtet, miljøbetinget eller forårsaget af fejlkonfiguration?
• Kan der være grænseoverskridende påvirkning eller påvirkning af tjenestemodtagere?
• Er personoplysninger involveret, såsom adgangskortlogfiler, CCTV, medarbejderdata eller kundeserviceregistre?

SME OT-politikken giver en enkel regel for eskalering af anomalier:

Alle anomalier skal straks rapporteres til direktøren med henblik på yderligere handling

Den indeholder også et safety-bevidst inddæmningsprincip:

Enheden skal straks frakobles netværket, hvor det er sikkert at gøre det

De sidste fem ord er afgørende. OT-respons kan ikke blindt kopiere IT-inddæmningshandlinger. “Hvor det er sikkert at gøre det” bør afspejles i runbooks, eskalationsmatricer, træning og tabletop-øvelser.

NIST CSF 2.0 passer godt her. Dets Respond- og Recover-resultater dækker triage, kategorisering, eskalering, rodårsagsanalyse, bevismaterialets integritet, underretning af interessenter, inddæmning, fjernelse, genetablering, integritetskontrol af backups og genopretningskommunikation.

Byg en sammenhængende linje fra risiko til kontrol og bevismateriale

En praktisk måde at undgå fragmenteret compliance på er at opbygge én sammenhængende linje fra risiko til regulering, kontrol og dokumentation.

Scenarie: En fjernleverandør af kompressorer har brug for adgang til en engineering workstation i OT-netværket. Arbejdsstationen kan ændre PLC-logik. Leverandørkontoen er altid aktiveret, deles af flere leverandøringeniører og er kun beskyttet med en adgangskode. Arbejdsstationen kører software, der ikke kan opgraderes før næste vedligeholdelsesstop.

Skriv risikoscenariet i risikoregisteret:

“Uautoriseret eller kompromitteret fjernadgang for leverandør til OT-engineering workstation kan føre til uautoriserede ændringer i PLC-logik, produktionsafbrydelse, safety-påvirkning og NIS2-rapporteringspligtig tjenesteafbrydelse.”

Kortlæg derefter kontrollerne og forpligtelserne.

Behandlingsplanen bør deaktivere stående leverandøradgang, kræve navngivne leverandøridentiteter, håndhæve MFA, dirigere adgang gennem en kontrolleret jumpserver, begrænse adgang til engineering workstation, kræve godkendelse af vedligeholdelsessag, registrere privilegerede sessioner, overvåge kommandoer og unormal trafik, dokumentere den upatchede arbejdsstation som en sårbarhedsundtagelse og teste hændelseshåndtering for mistænkelig leverandøraktivitet.

Zenith Blueprint, fasen Risk Management, Step 13, giver SoA-logikken for sporbarhed:

Krydsreferér reguleringer: Hvis visse kontroller implementeres specifikt for at overholde GDPR, NIS2 eller DORA, kan du anføre det enten i risikoregisteret (som en del af begrundelsen for risikokonsekvensen) eller i SoA-noterne.

Den praktiske læring er enkel. Hold ikke NIS2-, ISO- og OT-engineeringbevismateriale i adskilte siloer. Tilføj kolonner i risikoregisteret og SoA for NIS2 Article 21-tema, ISO/IEC 27002:2022-kontrol, IEC 62443-kravfamilie, ejer af bevismateriale og revisionsstatus.

Hvor GDPR og DORA passer ind i OT-sikkerhed

OT-sikkerhed handler ikke altid kun om maskiner. Kritiske infrastrukturer behandler ofte personoplysninger gennem CCTV, adgangsstyringssystemer, adgangskortlogfiler, medarbejdersikkerhedssystemer, vedligeholdelsessager, køretøjssporing, besøgsstyringssystemer og kundeserviceplatforme.

GDPR kræver, at personoplysninger behandles lovligt, rimeligt og gennemsigtigt, indsamles til specificerede formål, begrænses til det nødvendige, holdes korrekte, kun opbevares så længe som nødvendigt og beskyttes med passende tekniske og organisatoriske foranstaltninger. GDPR kræver også ansvarlighed, hvilket betyder, at den dataansvarlige skal kunne dokumentere compliance.

For OT betyder det, at adgangslogfiler og overvågningsregistreringer ikke må blive ukontrollerede datalagre til overvågning. Opbevaring, adgangsrettigheder, formålsbegrænsning og vurdering af brud skal indbygges i logning og overvågning.

DORA kan finde anvendelse, hvor finansielle enheder er involveret, eller hvor en IKT-tredjepartsleverandør understøtter den operationelle robusthed i den finansielle sektor. DORA dækker styring af IKT-risiko, hændelsesrapportering, robusthedstest og IKT-tredjepartsrisiko. For finansielle enheder, der også er væsentlige eller vigtige enheder efter NIS2-gennemførelsesregler, kan DORA fungere som den sektorspecifikke ordning for overlappende forpligtelser, mens koordinering med NIS2-myndigheder fortsat kan være relevant.

De samme discipliner for bevismateriale gælder: identifikation af aktiver, beskyttelse, detektion, kontinuitet, backup, tredjepartsrisiko, test, træning og ledelsesmæssigt tilsyn.

Revisionsperspektivet: én kontrol, flere assurance-perspektiver

En stærk implementering af NIS2 OT-sikkerhed bør kunne modstå flere revisionsperspektiver.

Derfor behandler Clarysec Zenith Controls som et kompas for tværgående compliance. Kontrolattributterne hjælper med at forklare formålet med officielle ISO/IEC 27002:2022-kontroller, mens kortlægningstilgangen forbinder disse kontroller med NIS2, NIST CSF, leverandørstyring, kontinuitet og revisionsbevismateriale.

Almindelige faldgruber ved implementering af NIS2 OT

De mest almindelige OT-sikkerhedssvigt skyldes sjældent mangel på dokumenter. De skyldes dokumenter, der ikke passer til anlægget.

Faldgrube 1: IT ejer NIS2-programmet, men OT ejer risikoen. Drift, engineering, safety og vedligeholdelse skal involveres.

Faldgrube 2: Aktivfortegnelsen stopper ved servere. En OT-fortegnelse skal omfatte PLC’er, RTU’er, HMI’er, historian-systemer, engineering workstations, industrielle switche, sensorer, gateways, fjernadgangsudstyr og komponenter, der administreres af leverandører.

Faldgrube 3: Segmentering findes på et diagram, men ikke i firewallregler. Revisorer vil bede om bevismateriale for håndhævelse, ændringsstyring og overvågning.

Faldgrube 4: Sårbarhedsundtagelser er uformelle. Begrænsninger ved ældre systemer er kun acceptable, når de er dokumenteret, godkendt, overvåget og genbesøgt.

Faldgrube 5: Leverandøradgang behandles kun som et leverandørforhold. Det er også et spørgsmål om adgangsstyring, logning, overvågning, netværkssikkerhed, hændelseshåndtering og kontinuitet.

Faldgrube 6: Hændelseshåndtering ignorerer safety. OT-playbooks skal definere, hvem der kan isolere enheder, stoppe processer, skifte tilstande eller kontakte tilsynsmyndigheder.

Faldgrube 7: NIS2-rapportering er ikke øvet. Beslutningsprocessen for 24 timer og 72 timer bør testes før en reel hændelse.

Clarysecs implementeringsvej fra bestyrelsesansvar til OT-bevismateriale

En praktisk implementering af NIS2 OT-sikkerhed kan følge denne rækkefølge:

1. Bekræft NIS2-omfang, enhedsklassificering og tjenestekritikalitet.
2. Definér OT-omfanget inden for ISMS, herunder grænseflader og afhængigheder.
3. Opbyg en OT-aktivfortegnelse og dataflowfortegnelse.
4. Identificér juridiske, kontraktlige, safety-mæssige, privatlivsrelaterede og sektorspecifikke forpligtelser.
5. Gennemfør OT-specifikke workshops om risikovurdering med engineering, drift, IT, SOC, indkøb og ledelse.
6. Kortlæg risikobehandling til ISO/IEC 27002:2022-kontroller, NIS2-temaer og IEC 62443-implementeringsmønstre.
7. Opdater anvendelighedserklæringen med OT-begrundelse og ejere af bevismateriale.
8. Implementér prioriterede kontroller: segmentering, leverandøradgang, sårbarhedshåndtering, overvågning, backups og hændelseshåndtering.
9. Opdater politikker og procedurer, herunder OT-sikkerhed, leverandørsikkerhed, fjernadgang, hændelseshåndtering og forretningskontinuitet.
10. Gennemfør tabletop-øvelser og tekniske valideringsøvelser.
11. Forbered revisionspakker til NIS2, ISO/IEC 27001:2022, kundedokumentation og intern styring.
12. Indarbejd konstateringer i ledelsens gennemgang og løbende forbedring.

Dette afspejler driftsmodellen i Zenith Blueprint, især Step 13 for risikobehandling og SoA-sporbarhed, Step 14 for politikudvikling og regulatoriske krydshenvisninger, Step 19 for sårbarhedsstyring og Step 20 for netværkssikkerhed.

Samme tilgang bruger Clarysec-politikker til at omsætte frameworksprog til operationelle regler. Virksomhedens IoT / OT Security Policy kræver gennemgang af sikkerhedsarkitekturen før udrulning:

Alle nye IoT/OT-enheder skal gennemgå en gennemgang af sikkerhedsarkitekturen før udrulning. Denne gennemgang skal validere:

Den angiver også:

Al trafik inden for og mellem IoT/OT-netværk skal overvåges løbende ved brug af:

Disse klausuler skaber styringsankre. Implementeringsbevismateriale kan omfatte OT IDS-alarmer, firewall-logfiler, SIEM-korrelation, baselineprofiler for trafik, sager om anomalier og responsregistreringer.

Hvordan godt NIS2 OT-bevismateriale ser ud

En NIS2 OT-bevispakke bør være praktisk nok til ingeniører og struktureret nok til revisorer.

For segmentering skal den omfatte godkendt arkitektur, zone- og conduit-diagrammer, eksport af firewallregler, ændringsregistreringer, periodiske regelgennemgange, undtagelsesregistreringer og overvågningsalarmer.

For leverandøradgang skal den omfatte vurdering af leverandørkritikalitet, kontraktklausuler, godkendt adgangsprocedure, navngivne konti, MFA-bevismateriale, adgangslogfiler, sessionsoptagelser, periodisk gennemgang af adgangsrettigheder og registreringer fra offboarding.

For sårbarhedsstyring skal den omfatte fortegnelse, kilder til sikkerhedsmeddelelser, passive discovery-resultater, sårbarhedssager, patchplaner, kompenserende kontroller, risikoaccept og bevismateriale for lukning.

For hændelseshåndtering skal den omfatte playbooks, eskalationskontakter, beslutningstræ for NIS2-rapportering, tabletop-resultater, hændelsessager, udkast til myndighedsunderretninger, regler for håndtering af bevismateriale og læringspunkter.

For kontinuitet skal den omfatte OT-backupstrategi, offline eller beskyttede backups, resultater af gendannelsestest, liste over kritiske reservedele, manuelle driftsprocedurer, genopretningsprioriteter og planer for krisekommunikation.

For styring skal den omfatte godkendelse fra bestyrelse eller ledelse, rolletildelinger, registreringer af gennemført træning, resultater fra intern revision, KPI’er, referater fra risikogennemgange og beslutninger fra ledelsens gennemgang.

Denne model for bevismateriale er i overensstemmelse med ISO/IEC 27001:2022, fordi den understøtter risikobehandling, dokumenteret information, evaluering af performance og løbende forbedring. Den er i overensstemmelse med NIS2, fordi den dokumenterer passende og forholdsmæssige foranstaltninger. Den er i overensstemmelse med IEC 62443, fordi den kan spores til OT-arkitektur og engineering-kontroller.

Gør dit OT-sikkerhedsprogram til revisionsbart NIS2-beredskab

Hvis dit OT-miljø understøtter en kritisk eller reguleret tjeneste, er det en forkert strategi at vente på, at en tilsynsmyndighed, en kunde eller en hændelse afdækker hullerne.

Start med ét anvendelsesscenarie med stor effekt: fjernadgang for leverandører til en kritisk OT-zone, sårbarhedshåndtering for industrielle aktiver uden support eller segmentering mellem virksomhedens IT og OT. Opbyg risikoscenariet, kortlæg det til NIS2 Article 21, vælg ISO/IEC 27002:2022-kontroller, omsæt dem til IEC 62443-implementeringsmønstre, og indsaml bevismaterialet.

Clarysec kan hjælpe dig med at accelerere arbejdet med Zenith Blueprint, Zenith Controls, IoT / OT Security Policy, Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME og Third-Party and Supplier Security Policy - SME.

Din næste handling: Vælg én OT-tjeneste, kortlæg dens aktiver og afhængigheder, og opret en sammenhængende linje fra risiko til kontrol og bevismateriale i denne uge. Hvis du ønsker en struktureret implementeringsvej, kan Clarysecs 30-trins køreplan og værktøjssæt til tværgående compliance gøre den første linje til et komplet NIS2 OT-sikkerhedsprogram.