NIS2 OT-säkerhet: mappning mot ISO 27001 och IEC 62443

Klockan 02:17 en måndag får en operatör vid ett vattenreningsverk ett larm från ett doseringssystem. Kemikaliedoseringen ligger fortfarande inom säkerhetsgränserna, men en PLC rapporterar oregelbundna kommandon, teknikerarbetsstationen visar misslyckade inloggningar från ett VPN-konto hos en leverantör och den tjänstgörande SOC-analytikern ställer en fråga som ingen vill behöva besvara under press.

Är detta en IT-incident, en OT-incident, en säkerhetshändelse eller en betydande incident som ska rapporteras enligt NIS2?

Anläggningen har brandväggar. Den har ISO-dokumentation. Den har ett leverantörsregister. Den har till och med en incidenthanteringsplan. Men planen skrevs för komprometterad e-post och molnavbrott, inte för en äldre styrenhet som inte kan patchas under produktion, en leverantör som behöver fjärråtkomst för att återställa tjänsten och en tillsynsmyndighet som förväntar sig underlag inom NIS2:s rapporteringsfrister.

Samma problem uppstår i styrelserum. En informationssäkerhetschef hos en regional energileverantör kan ha ett ISO/IEC 27001:2022-certifierat ledningssystem för informationssäkerhet för organisationens IT, samtidigt som OT-miljön består av en komplex blandning av PLC:er, RTU:er, HMI:er, historikdatabaser, teknikerarbetsstationer, industriella switchar och leverantörers åtkomstvägar. VD:ns fråga är enkel: ”Omfattas vi? Kan du bevisa det?”

För många väsentliga och viktiga entiteter är det ärliga svaret obekvämt. De omfattas delvis. De kan delvis bevisa det. Men NIS2 OT-säkerhet kräver mer än generell IT-efterlevnad.

Det kräver en enhetlig operativ modell som kopplar samman styrning enligt ISO/IEC 27001:2022, kontrollspråket i ISO/IEC 27002:2022, industriell ingenjörspraxis enligt IEC 62443, NIS2 Article 21 om åtgärder för hantering av cybersäkerhetsrisker och NIS2 Article 23 om underlag för incidentrapportering.

Det är den bron denna vägledning bygger.

Varför NIS2 OT-säkerhet skiljer sig från vanlig IT-efterlevnad

NIS2 gäller många offentliga och privata entiteter som tillhandahåller tjänster inom tillämpningsområdet i EU, inklusive väsentliga och viktiga entiteter inom sektorer som energi, transport, bank, infrastruktur för finansmarknaden, hälsa, dricksvatten, avloppsvatten, digital infrastruktur, hantering av IKT-tjänster, offentlig förvaltning, rymd, posttjänster, avfallshantering, tillverkning, kemikalier, livsmedel, digitala leverantörer och forskning.

Direktivet kräver lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder för att hantera cyberrisker, förebygga eller minimera incidentpåverkan och skydda tjänsternas kontinuitet. Article 21 omfattar ett allriskperspektiv med riskanalys, säkerhetspolicyer, incidenthantering, verksamhetskontinuitet, krishantering, säkerhet i leveranskedjan, säker anskaffning och säkert underhåll, sårbarhetshantering och sårbarhetsrapportering, bedömning av effektivitet, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering, MFA eller kontinuerlig autentisering, säker kommunikation och nödkommunikation där det är relevant.

Dessa krav känns bekanta för en organisation som arbetar med ISO/IEC 27001:2022. I OT beter sig vart och ett av dem annorlunda.

En sårbarhet i en webbserver kan ofta patchas inom några dagar. En sårbarhet i en turbinstyrenhet kan kräva leverantörsvalidering, ett underhållsfönster, en personsäkerhetsbedömning och reservrutiner för drift. En bärbar dator kan byggas om. En produktions-HMI kan vara beroende av ett äldre operativsystem eftersom den industriella applikationen inte har certifierats för en nyare plattform. En incidentrutin för SOC kan säga ”isolera värden”, medan OT-ingenjören svarar: ”inte förrän vi vet om isoleringen påverkar tryckregleringen”.

Skillnaden är inte bara teknisk. IT prioriterar normalt konfidentialitet, riktighet och tillgänglighet. OT prioriterar tillgänglighet, processriktighet och personsäkerhet. En säkerhetskontroll som introducerar latens, kräver omstart eller avbryter en fysisk process kan vara oacceptabel utan godkännande från teknikfunktionen.

NIS2 undantar inte OT från cybersäkerhetsriskhantering. Direktivet förväntar sig att organisationen kan visa att kontrollerna är lämpliga för risken och proportionerliga i förhållande till den operativa verkligheten.

Kontrollstacken: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 och IEC 62443

Ett försvarbart NIS2-program för OT-säkerhet börjar med en lagerindelad kontrollstack.

ISO/IEC 27001:2022 tillhandahåller ledningssystemet. Standarden kräver att organisationen definierar kontext, intressenter, regulatoriska skyldigheter, ISMS-omfattning, gränssnitt och beroenden. Den kräver även ledningens ägarskap, en informationssäkerhetspolicy, riskbedömning, riskbehandling, en Statement of Applicability, dokumenterad information, internrevision, ledningens genomgång och ständig förbättring.

ISO/IEC 27002:2022 tillhandahåller kontrollvokabulären. För OT omfattar de viktigaste kontrollerna ofta leverantörssäkerhet, IKT-riskhantering i leveranskedjan, incidentplanering, beredskap för verksamhetskontinuitet, rättsliga och avtalsmässiga krav, tillgångshantering, åtkomstkontroll, hantering av sårbarheter, säkerhetskopiering, loggning, övervakning, nätverkssäkerhet och nätverkssegmentering.

IEC 62443 tillhandahåller den industriella modellen för säkerhetsteknik. Den hjälper till att översätta ledningssystemets krav till OT-praxis, såsom zoner, conduits, säkerhetsnivåer, ansvar för tillgångsägare, ansvar för systemintegratörer, förväntningar på produktleverantörer, begränsningar för fjärråtkomst, principen om minsta funktionalitet, kontohantering, härdning och livscykelkontroller.

Clarysec använder denna stack eftersom den undviker två vanliga misslyckanden. För det första förhindrar den att ISO-införandet blir för generiskt för OT. För det andra förhindrar den att ingenjörsarbetet enligt IEC 62443 frikopplas från styrelsens ansvar, NIS2-rapporteringsskyldigheter och revisionsbevis.

Clarysecs policy för säkerhet i IoT-/OT-miljöer uttrycker bryggan direkt:

Säkerställa att alla driftsättningar är anpassade till ISO/IEC 27001-kontroller och tillämplig sektorsspecifik vägledning (t.ex. IEC 62443, ISO 27019, NIST SP 800-82).

Den meningen är viktig. Policyn är inte bara en checklista för enhetshärdning. Den kopplar samman ISO-styrning, sektorsvägledning för OT och operativ säkerhet.

Börja med omfattningen: vilken OT-tjänst ska skyddas?

Innan kontroller mappas ska OT-tjänsten definieras i verksamhetsmässiga och regulatoriska termer.

En anläggningschef kan säga: ”Vi driver förpackningslinjen.” En NIS2-bedömning bör säga: ”Denna produktionsprocess stödjer en väsentlig eller viktig tjänst och är beroende av PLC:er, HMI:er, teknikerarbetsstationer, historikdatabaser, industriella switchar, fjärråtkomst för leverantörer, en underhållsentreprenör, ett analysflöde i molnet och en identitetstjänst för organisationen.”

ISO/IEC 27001:2022 klausulerna 4.1 till 4.4 är användbara eftersom de tvingar organisationen att identifiera interna och externa frågor, intressenter, rättsliga och avtalsmässiga krav, ISMS-gränser, gränssnitt och beroenden. För NIS2 OT-säkerhet innebär det att inte bara huvudkontorets nätverk ska kartläggas, utan även de industriella system och tjänsteberoenden som påverkar kontinuitet, personsäkerhet och reglerad leverans.

NIST CSF 2.0 förstärker samma logik. Funktionen GOVERN kräver förståelse för uppdrag, intressenter, beroenden, rättsliga och regulatoriska skyldigheter, kritiska tjänster och tjänster som organisationen är beroende av. Organisationsprofiler ger en praktisk metod för att avgränsa nuläge, definiera målbild, analysera gap och ta fram en prioriterad åtgärdsplan.

För en OT-miljö börjar Clarysec normalt med fem frågor:

1. Vilken reglerad eller kritisk tjänst stödjer denna OT-miljö?
2. Vilka OT-tillgångar, nätverk, dataflöden och tredje parter krävs för den tjänsten?
3. Vilka begränsningar avseende personsäkerhet, tillgänglighet och drift påverkar säkerhetskontrollerna?
4. Vilka rättsliga, avtalsmässiga och sektorsspecifika skyldigheter gäller, inklusive NIS2, GDPR, DORA där det är relevant, kundavtal och nationella regler?
5. Vilka delar av miljön ingår i ISMS, och vilka är externa beroenden som kräver leverantörskontroller?

Många NIS2-program misslyckas här. De avgränsar kring organisationens IT eftersom den är enklare att inventera. Revisorer och tillsynsmyndigheter kommer inte att imponeras om det mest kritiska tjänsteberoendet endast förekommer som en vag radpost kallad ”fabriksnätverk”.

En praktisk kontrollmappning för NIS2 OT

Tabellen nedan visar hur teman i NIS2 Article 21 kan omsättas till underlag enligt ISO/IEC 27001:2022, ISO/IEC 27002:2022 och IEC 62443. Den ersätter inte en formell riskbedömning, men ger informationssäkerhetschefer, OT-chefer och regelefterlevnadsfunktioner en praktisk startpunkt.

Denna mappning är avsiktligt inriktad på underlag. Enligt NIS2 räcker det inte att säga ”vi har segmentering”. Ni behöver visa varför segmenteringen är lämplig, hur den är införd, hur undantag godkänns och hur utformningen minskar påverkan på den reglerade tjänsten.

Segmentering: den första OT-kontroll som revisorer testar

Om incidenten klockan 02:17 innebar att en angripare rörde sig från en kontorsdator till en teknikerarbetsstation skulle den första revisionsfrågan vara självklar: varför kunde den vägen finnas?

Policy för säkerhet i IoT-/OT-miljöer är tydlig:

OT-system ska driftas i dedikerade nätverk som är isolerade från organisationens IT och internetexponerade system.

För mindre miljöer ger Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME en praktisk baslinje:

Alla Internet of Things (IoT)- och Operational Technology (OT)-enheter ska placeras i ett separat Wi-Fi- eller VLAN-nätverk

För en mogen operatör av kritisk infrastruktur bör segmentering utformas utifrån OT-zoner och conduits. Verksamhetsanvändare ska inte ha direkt åtkomst till PLC-nätverk. Leverantörsanslutningar ska avslutas i kontrollerade åtkomstzoner. Replikering från historikdatabaser ska använda godkända vägar. Säkerhetssystem ska isoleras enligt risk- och ingenjörskrav. Trådlösa OT-nätverk ska motiveras, härdas och övervakas.

Zenith Blueprint: en revisors 30-stegs färdplan, i fasen Controls in Action, Step 20, förklarar principen bakom nätverkssäkerhet enligt ISO/IEC 27002:2022:

Industriella styrsystem bör isoleras från kontorstrafik.

Den varnar också för att nätverkssäkerhet kräver säker arkitektur, segmentering, åtkomstkontroll, kryptering under överföring, övervakning och försvar på djupet.

I Zenith Controls: vägledning för korsvis regelefterlevnad behandlas ISO/IEC 27002:2022 kontroll 8.22, Segregation of Networks, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, är anpassad till cybersäkerhetsfunktionen Protect, har system- och nätverkssäkerhet som operativ förmåga och Protection som säkerhetsdomän.

Den klassificeringen är användbar för NIS2-underlag eftersom segmentering inte är ett dekorativt diagram. Det är en förebyggande kontroll utformad för att minska spridningsradien och bevara kontinuiteten i väsentliga tjänster.

Sårbarhetshantering när OT-system inte bara kan patchas

NIS2 kräver säker anskaffning, utveckling och underhåll av nätverks- och informationssystem, inklusive sårbarhetshantering och sårbarhetsrapportering. Inom IT betyder sårbarhetshantering ofta att skanna, prioritera, patcha och verifiera. OT tillför begränsningar.

En kritisk HMI kanske bara kan patchas under ett planerat avbrott. En firmwareuppdatering för en PLC kan kräva leverantörsmedverkan. Ett säkerhetscertifierat system kan förlora certifieringen om det ändras felaktigt. Vissa äldre enheter kan helt sakna leverantörssupport.

Zenith Blueprint, fasen Controls in Action, Step 19, ger rätt revisionslogik för tekniska sårbarheter:

För system som inte kan patchas omedelbart, kanske på grund av äldre programvara eller begränsningar kopplade till driftstopp, ska kompenserande kontroller införas. Det kan omfatta att isolera systemet bakom en brandvägg, begränsa åtkomst eller öka övervakningen. I samtliga fall ska detta registreras och den kvarstående risken accepteras formellt, så att det framgår att frågan inte har glömts bort.

SME-policyns baslinje är lika praktisk:

Inventariet ska granskas kvartalsvis för att identifiera föråldrade, ej supporterade eller opatchade enheter

I Zenith Controls mappas ISO/IEC 27002:2022 kontroll 8.8, Management of Technical Vulnerabilities, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, är anpassad till Identify och Protect, med hantering av hot och sårbarheter som operativ förmåga över domänerna Governance, Ecosystem, Protection och Defense.

En stark OT-sårbarhetsakt bör omfatta:

• Tillgångsidentifierare, ägare, zon och kritikalitet
• Sårbarhetskälla, till exempel leverantörsmeddelande, skanner, integratörsnotis eller hotinformation
• Begränsningar kopplade till personsäkerhet och tillgänglighet
• Möjlighet att patcha och planerat underhållsfönster
• Kompenserande kontroller, såsom isolering, åtkomstkontrollistor, inaktiverade tjänster eller ökad övervakning
• Riskägarens godkännande och acceptans av kvarstående risk
• Verifieringsunderlag efter åtgärdande eller införande av kompenserande kontroll

Detta omvandlar ”vi kan inte patcha” från en ursäkt till revisionsbar riskbehandling.

Fjärråtkomst för leverantörer: skärningspunkten mellan NIS2 och IEC 62443

De flesta OT-incidenter har någon form av tredjepartsdimension. Ett leverantörskonto. En integratörsdator. Ett verktyg för fjärrunderhåll. Delade inloggningsuppgifter. Ett brandväggsundantag som var tillfälligt för tre år sedan.

NIS2 Article 21 omfattar uttryckligen säkerhet i leveranskedjan, leverantörsspecifika sårbarheter, leverantörers cybersäkerhetspraxis och rutiner för säker utveckling. NIST CSF 2.0 är också detaljerad på denna punkt genom leverantörskritikalitet, avtalskrav, leverantörsgranskning, löpande övervakning, incidentsamordning och exitbestämmelser.

Clarysecs policy för leverantörssäkerhet och tredjepartssäkerhet - SME anger principen på tydligt språk:

Leverantörer ska endast ges åtkomst till de minsta system och data som krävs för att utföra sin funktion.

För OT betyder minsta åtkomst mer än rollbaserad åtkomst i en applikation. Leverantörsåtkomst bör vara:

• Förhandsgodkänd för ett definierat underhållssyfte
• Tidsbegränsad och inaktiverad som standard
• Skyddad med MFA eller kontinuerlig autentisering där det är lämpligt
• Dirigerad via en säker hoppvärd eller kontrollerad plattform för fjärråtkomst
• Begränsad till relevant OT-zon eller tillgång
• Loggad, övervakad och, för högriskåtkomst, inspelad per session
• Granskad efter slutförande
• Omfattad av avtalsmässiga säkerhets- och incidentaviseringsskyldigheter

Organisationens policy för säkerhet i IoT-/OT-miljöer innehåller ett särskilt krav för fjärråtkomst:

Fjärråtkomst (för administration eller leverantörsservice) ska:

Den klausulen förankrar styrningspunkten, medan de detaljerade kraven ska genomföras i åtkomstrutiner, leverantörsavtal, teknisk konfiguration och arbetsflöden för övervakning.

I Zenith Controls klassificeras ISO/IEC 27002:2022 kontroll 5.21, Managing information security in the ICT supply chain, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, är anpassad till Identify, med säkerhet i leverantörsrelationer som operativ förmåga och Governance, Ecosystem och Protection som domäner.

För OT hjälper den mappningen till att förklara varför underlag för fjärråtkomst samtidigt hör hemma i filer för leverantörsrisk, identitetsstyrning, nätverkssäkerhet, incidenthantering och kontinuitet.

Incidenthantering: NIS2-klockan möter kontrollrummet

Tillbaka till larmet klockan 02:17. Organisationen måste avgöra om händelsen är betydande enligt NIS2. Article 23 kräver underrättelse utan onödigt dröjsmål om betydande incidenter som påverkar tillhandahållandet av tjänster. Sekvensen omfattar en tidig varning inom 24 timmar från kännedom, en incidentanmälan inom 72 timmar, mellanliggande uppdateringar om sådana begärs och en slutrapport senast en månad efter incidentanmälan, eller en lägesrapport om incidenten fortfarande pågår.

I OT måste incidenthantering besvara frågor som IT-rutiner ofta bortser från:

• Kan den berörda enheten isoleras utan att skapa personsäkerhetsrisk?
• Vem har befogenhet att stoppa produktion eller växla till manuellt läge?
• Vilka loggar är flyktiga och måste bevaras omedelbart?
• Vilken leverantör eller integratör måste kontaktas?
• Är händelsen avsiktlig, oavsiktlig, miljörelaterad eller orsakad av felkonfiguration?
• Kan det finnas gränsöverskridande påverkan eller påverkan på tjänstemottagare?
• Berörs personuppgifter, till exempel passerkortsloggar, CCTV, anställdas uppgifter eller kundtjänstregister?

SME-policyn för OT ger en enkel regel för eskalering av avvikelser:

Alla avvikelser ska omedelbart rapporteras till verkställande chef för vidare åtgärd

Den innehåller också en säkerhetsmedveten princip för begränsning:

Enheten ska omedelbart kopplas bort från nätverket, där det är säkert att göra det

De sista fem orden är avgörande. OT-respons kan inte blint kopiera IT-åtgärder för begränsning. ”Där det är säkert att göra det” bör återspeglas i återställningsanvisningar, eskaleringsmatriser, utbildning och skrivbordsövningar.

NIST CSF 2.0 passar väl här. Dess utfall för Respond och Recover omfattar triage, kategorisering, eskalering, rotorsaksanalys, bevisintegritet, underrättelse till intressenter, begränsning, eliminering, återställning, integritetskontroller av säkerhetskopior och återställningskommunikation.

Bygg en underlagskedja från risk till kontroll

Ett praktiskt sätt att undvika fragmenterad efterlevnad är att bygga en sammanhängande underlagskedja från risk till reglering, kontroll och bevis.

Scenario: en fjärrleverantör för en kompressor behöver åtkomst till en teknikerarbetsstation i OT-nätverket. Arbetsstationen kan ändra PLC-logik. Leverantörskontot är alltid aktiverat, delas av flera leverantörsingenjörer och skyddas endast med lösenord. Arbetsstationen kör programvara som inte kan uppgraderas förrän vid nästa underhållsstopp.

Skriv riskscenariot i riskregistret:

”Obehörig eller komprometterad fjärråtkomst från leverantör till OT-teknikerarbetsstation kan leda till obehöriga ändringar av PLC-logik, produktionsstörning, påverkan på personsäkerhet och tjänsteavbrott som ska rapporteras enligt NIS2.”

Mappa därefter kontrollerna och skyldigheterna.

Behandlingsplanen bör inaktivera stående leverantörsåtkomst, kräva namngivna leverantörsidentiteter, kräva MFA, dirigera åtkomst via en kontrollerad hoppserver, begränsa åtkomst till teknikerarbetsstationen, kräva godkännande via underhållsärende, spela in privilegierade sessioner, övervaka kommandon och avvikande trafik, dokumentera den opatchade arbetsstationen som ett sårbarhetsundantag och testa incidenthantering vid misstänkt leverantörsaktivitet.

Zenith Blueprint, fasen Risk Management, Step 13, ger logiken för SoA-spårbarhet:

Korshänvisa regelverk: Om vissa kontroller införs särskilt för att uppfylla GDPR, NIS2 eller DORA kan du notera detta antingen i Riskregistret (som en del av motiveringen av riskpåverkan) eller i SoA-noteringarna.

Den praktiska lärdomen är enkel. Håll inte NIS2-, ISO- och OT-teknikunderlag i separata silor. Lägg till kolumner i riskregistret och SoA för tema i NIS2 Article 21, ISO/IEC 27002:2022-kontroll, IEC 62443-kravfamilj, underlagsägare och revisionsstatus.

Var GDPR och DORA passar in i OT-säkerhet

OT-säkerhet handlar inte alltid bara om maskiner. Miljöer inom kritisk infrastruktur behandlar ofta personuppgifter via CCTV, åtkomstkontrollsystem, passerkortsloggar, säkerhetssystem för arbetsstyrkan, underhållsärenden, fordonspositionering, besökssystem och kundtjänstplattformar.

GDPR kräver att personuppgifter behandlas lagligt, korrekt och transparent, samlas in för specificerade ändamål, begränsas till vad som är nödvändigt, hålls korrekta, bevaras endast så länge som behövs och skyddas med lämpliga tekniska och organisatoriska åtgärder. GDPR kräver även ansvarsskyldighet, vilket innebär att den personuppgiftsansvarige måste kunna visa efterlevnad.

För OT innebär detta att åtkomstloggar och övervakningsposter inte får bli okontrollerade datalager för övervakning. Bevarande, åtkomsträttigheter, ändamålsbegränsning och bedömning av personuppgiftsincidenter måste byggas in i loggning och övervakning.

DORA kan vara tillämpligt där finansiella entiteter är involverade, eller där en IKT-tredjepartstjänsteleverantör stödjer operativ resiliens i finanssektorn. DORA omfattar IKT-riskhantering, incidentrapportering, resiliensprovning och IKT-tredjepartsrisk. För finansiella entiteter som också är väsentliga eller viktiga entiteter enligt reglerna för införlivande av NIS2 kan DORA fungera som det sektorsspecifika regelverket för överlappande skyldigheter, samtidigt som samordning med NIS2-myndigheter kan förbli relevant.

Samma underlagsdiscipliner gäller: identifiering av tillgångar, skydd, detektering, kontinuitet, säkerhetskopiering, tredjepartsrisk, testning, utbildning och ledningens tillsyn.

Revisionsperspektivet: en kontroll, flera säkerställandeperspektiv

Ett starkt genomförande av NIS2 OT-säkerhet bör klara flera revisionsperspektiv.

Det är därför Clarysec behandlar Zenith Controls som en kompass för korsvis regelefterlevnad. Dess kontrollattribut hjälper till att förklara syftet med officiella ISO/IEC 27002:2022-kontroller, samtidigt som mappningsmetoden kopplar dessa kontroller till NIS2, NIST CSF, leverantörsstyrning, kontinuitet och revisionsbevis.

Vanliga fallgropar vid införande av NIS2 OT

De vanligaste bristerna inom OT-säkerhet orsakas sällan av brist på dokument. De orsakas av dokument som inte stämmer med anläggningen.

Fallgrop 1: IT äger NIS2-programmet, men OT äger risken. Drift, teknik, säkerhet och underhåll måste involveras.

Fallgrop 2: Tillgångsförteckningen slutar vid servrar. En OT-förteckning måste omfatta PLC:er, RTU:er, HMI:er, historikdatabaser, teknikerarbetsstationer, industriella switchar, sensorer, gateways, utrustning för fjärråtkomst och komponenter som hanteras av leverantörer.

Fallgrop 3: Segmentering finns i ett diagram men inte i brandväggsregler. Revisorer kommer att begära underlag för tillämpning, ändringsstyrning och övervakning.

Fallgrop 4: Sårbarhetsundantag är informella. Begränsningar i äldre system är acceptabla endast när de dokumenteras, godkänns, övervakas och omprövas.

Fallgrop 5: Leverantörsåtkomst behandlas endast som en leverantörsfråga. Det är också en fråga om åtkomstkontroll, loggning, övervakning, nätverkssäkerhet, incidenthantering och kontinuitet.

Fallgrop 6: Incidenthantering bortser från personsäkerhet. OT-rutiner måste definiera vem som får isolera enheter, stoppa processer, byta driftläge eller kontakta tillsynsmyndigheter.

Fallgrop 7: NIS2-rapportering har inte övats. Beslutsprocessen för 24 timmar och 72 timmar bör testas innan en verklig händelse inträffar.

Clarysecs genomförandeväg från styrelseansvar till OT-underlag

Ett praktiskt genomförande av NIS2 OT-säkerhet kan följa denna sekvens:

1. Bekräfta NIS2-omfattning, entitetsklassificering och tjänstekritikalitet.
2. Definiera OT-omfattningen inom ISMS, inklusive gränssnitt och beroenden.
3. Bygg en förteckning över OT-tillgångar och dataflöden.
4. Identifiera rättsliga, avtalsmässiga, säkerhetsrelaterade, integritetsrelaterade och sektorsspecifika skyldigheter.
5. Genomför OT-specifika riskbedömningsworkshoppar med teknik, drift, IT, SOC, upphandling och ledning.
6. Mappa riskbehandling till ISO/IEC 27002:2022-kontroller, NIS2-teman och genomförandemönster enligt IEC 62443.
7. Uppdatera Statement of Applicability med OT-motivering och underlagsägare.
8. Inför prioriterade kontroller: segmentering, leverantörsåtkomst, sårbarhetshantering, övervakning, säkerhetskopiering och incidenthantering.
9. Uppdatera policyer och rutiner, inklusive OT-säkerhet, leverantörssäkerhet, fjärråtkomst, incidenthantering och verksamhetskontinuitet.
10. Genomför skrivbordsövningar och tekniska valideringsövningar.
11. Förbered revisionspaket för NIS2, ISO/IEC 27001:2022, kundförsäkran och intern styrning.
12. För in iakttagelser i ledningens genomgång och ständig förbättring.

Detta återspeglar den operativa modellen i Zenith Blueprint, särskilt Step 13 för riskbehandling och SoA-spårbarhet, Step 14 för policyutveckling och regulatoriska korshänvisningar, Step 19 för hantering av sårbarheter och Step 20 för nätverkssäkerhet.

Samma metod använder Clarysecs policyer för att omvandla ramverksspråk till operativa regler. Organisationens policy för säkerhet i IoT-/OT-miljöer kräver säkerhetsarkitekturgranskning före driftsättning:

Alla nya IoT/OT-enheter ska genomgå en säkerhetsarkitekturgranskning före driftsättning. Denna granskning ska validera:

Den anger också:

All trafik inom och mellan IoT/OT-nätverk ska övervakas kontinuerligt med hjälp av:

Dessa klausuler skapar styrningsankare. Underlag för genomförandet kan omfatta OT IDS-larm, brandväggsloggar, SIEM-korrelation, baslinjeprofiler för trafik, avvikelseärenden och responsposter.

Hur bra NIS2 OT-underlag ser ut

Ett underlagspaket för NIS2 OT bör vara tillräckligt praktiskt för ingenjörer och tillräckligt strukturerat för revisorer.

För segmentering, inkludera godkänd arkitektur, zon- och conduit-diagram, exporter av brandväggsregler, ändringsposter, periodiska regelgranskningar, undantagsposter och övervakningslarm.

För leverantörsåtkomst, inkludera bedömning av leverantörskritikalitet, avtalsklausuler, godkänd åtkomstrutin, namngivna konton, MFA-underlag, åtkomstloggar, sessionsinspelningar, periodisk åtkomstgranskning och offboarding-poster.

För hantering av sårbarheter, inkludera inventarium, källor till säkerhetsmeddelanden, utdata från passiv upptäckt, sårbarhetsärenden, patchplaner, kompenserande kontroller, riskacceptans och stängningsunderlag.

För incidenthantering, inkludera rutiner, eskaleringskontakter, beslutsträd för NIS2-rapportering, resultat från skrivbordsövningar, incidentärenden, utkast till myndighetsanmälningar, regler för hantering av bevismaterial och erfarenhetsåterföring.

För kontinuitet, inkludera strategi för OT-säkerhetskopiering, offline- eller skyddade säkerhetskopior, resultat från återställningstester, lista över kritiska reservdelar, manuella driftrutiner, återställningsprioriteringar och planer för kriskommunikation.

För styrning, inkludera styrelsens eller ledningens godkännande, rolltilldelningar, utbildningsregister, internrevisionsresultat, KPI:er, protokoll från riskgranskningar och beslut från ledningens genomgång.

Denna underlagsmodell är anpassad till ISO/IEC 27001:2022 eftersom den stödjer riskbehandling, dokumenterad information, prestationsutvärdering och ständig förbättring. Den är anpassad till NIS2 eftersom den visar lämpliga och proportionella åtgärder. Den är anpassad till IEC 62443 eftersom den kan spåras till OT-arkitektur och tekniska kontroller.

Omvandla ert OT-säkerhetsprogram till revisionsbar NIS2-beredskap

Om er OT-miljö stödjer en kritisk eller reglerad tjänst är det fel strategi att vänta på att en tillsynsmyndighet, kund eller incident ska avslöja luckorna.

Börja med ett användningsfall med hög påverkan: fjärråtkomst för leverantörer till en kritisk OT-zon, sårbarhetshantering för industriella tillgångar utan support, eller segmentering mellan verksamhets-IT och OT. Bygg riskscenariot, mappa det till NIS2 Article 21, välj ISO/IEC 27002:2022-kontroller, översätt dem till genomförandemönster enligt IEC 62443 och samla in underlaget.

Clarysec kan hjälpa er att påskynda arbetet med Zenith Blueprint, Zenith Controls, policy för säkerhet i IoT-/OT-miljöer, Internet of Things (IoT) / Operational Technology (OT) Security Policy - SME och policy för leverantörssäkerhet och tredjepartssäkerhet - SME.

Nästa steg: välj en OT-tjänst, kartlägg dess tillgångar och beroenden och skapa en underlagskedja från risk till kontroll den här veckan. Om ni vill ha en strukturerad genomförandeväg kan Clarysecs 30-stegs färdplan och verktygslåda för korsvis regelefterlevnad omvandla den första kedjan till ett komplett NIS2-program för OT-säkerhet.