NIS2 OT-beveiliging: mapping van ISO 27001 en IEC 62443

Om 02:17 op een maandag ontvangt een operator van een waterzuiveringsinstallatie een alarm van een doseersysteem. De chemische dosering blijft binnen de veiligheidsgrenzen, maar één PLC rapporteert onregelmatige commando’s, het engineeringwerkstation toont mislukte aanmeldingen vanuit een leveranciers-VPN-account en de dienstdoende SOC-analist stelt een vraag die niemand onder druk wil beantwoorden.

Is dit een IT-incident, een OT-incident, een veiligheidsgebeurtenis of een significant incident dat onder NIS2 moet worden gemeld?

De installatie heeft firewalls. Er is ISO-documentatie. Er is een leveranciersspreadsheet. Er is zelfs een incidentresponsplan. Maar dat plan is geschreven voor compromittering van e-mail en uitval van clouddiensten, niet voor een legacy-controller die tijdens productie niet kan worden gepatcht, een leverancier die toegang op afstand nodig heeft om de dienstverlening te herstellen en een toezichthouder die binnen de NIS2-meldtermijn bewijsmateriaal verwacht.

Hetzelfde probleem speelt in bestuurskamers. Een CISO bij een regionale energieleverancier kan beschikken over een ISO/IEC 27001:2022-gecertificeerd managementsysteem voor informatiebeveiliging voor bedrijfs-IT, terwijl het OT-landschap een wirwar blijft van PLC’s, RTU’s, HMI’s, historians, engineeringwerkstations, industriële switches en toegangspaden voor leveranciers. De vraag van de CEO is eenvoudig: “Zijn we afgedekt? Kun je dat aantonen?”

Voor veel essentiële en belangrijke entiteiten is het eerlijke antwoord ongemakkelijk. Ze zijn gedeeltelijk afgedekt. Ze kunnen het gedeeltelijk aantonen. Maar NIS2 OT-beveiliging vereist meer dan generieke IT-naleving.

Er is een uniform operationeel model nodig dat ISO/IEC 27001:2022-governance, de beheersmaatregelentaal van ISO/IEC 27002:2022, industriële engineeringpraktijken uit IEC 62443, de cyberbeveiligingsrisicobeheermaatregelen van NIS2 Article 21 en het bewijsmateriaal voor incidentmelding volgens NIS2 Article 23 met elkaar verbindt.

Dat is de brug die deze gids bouwt.

Waarom NIS2 OT-beveiliging verschilt van gewone IT-naleving

NIS2 is van toepassing op veel publieke en private entiteiten die binnen de reikwijdte vallende diensten in de EU leveren, waaronder essentiële en belangrijke entiteiten in sectoren zoals energie, transport, bankwezen, infrastructuur voor financiële markten, gezondheidszorg, drinkwater, afvalwater, digitale infrastructuur, beheer van ICT-diensten, openbaar bestuur, ruimtevaart, postdiensten, afvalbeheer, productie, chemie, voeding, digitale aanbieders en onderzoek.

De richtlijn vereist passende en evenredige technische, operationele en organisatorische maatregelen om cyberrisico’s te beheersen, de impact van incidenten te voorkomen of te beperken en de continuïteit van diensten te beschermen. Article 21 omvat een all-hazards-benadering voor risicoanalyse, beveiligingsbeleid, incidentafhandeling, bedrijfscontinuïteit, crisismanagement, beveiliging van de toeleveringsketen, veilige verwerving en onderhoud, behandeling en openbaarmaking van kwetsbaarheden, beoordeling van doeltreffendheid, cyberhygiëne, training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen, MFA of continue authenticatie, beveiligde communicatie en, waar passend, noodcommunicatie.

Die vereisten klinken bekend voor een ISO/IEC 27001:2022-team. In OT gedragen ze zich allemaal anders.

Een kwetsbaarheid in een webserver kan vaak binnen enkele dagen worden gepatcht. Een kwetsbaarheid in een turbinecontroller kan leveranciersvalidatie, een onderhoudsvenster, een veiligheidsbeoordeling en terugvalprocedures voor de operatie vereisen. Een laptop kan opnieuw worden opgebouwd. Een productie-HMI kan afhankelijk zijn van een legacy-besturingssysteem omdat de industriële applicatie niet is gecertificeerd voor een nieuwer platform. Een SOC-draaiboek kan zeggen: “isoleer de host”, terwijl de OT-ingenieur antwoordt: “niet voordat we weten of isolatie de drukregeling beïnvloedt.”

Het verschil is niet alleen technisch. IT geeft doorgaans prioriteit aan vertrouwelijkheid, integriteit en beschikbaarheid. OT geeft prioriteit aan beschikbaarheid, procesintegriteit en veiligheid. Een beveiligingsmaatregel die latency introduceert, een herstart vereist of een fysiek proces onderbreekt, kan onaanvaardbaar zijn zonder goedkeuring vanuit engineering.

NIS2 stelt OT niet vrij van cyberbeveiligingsrisicobeheer. De organisatie moet aantonen dat beheersmaatregelen passend zijn voor het risico en evenredig zijn aan de operationele werkelijkheid.

De beheersingsstack: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 en IEC 62443

Een verdedigbaar NIS2 OT-beveiligingsprogramma begint met een gelaagde beheersingsstack.

ISO/IEC 27001:2022 biedt het managementsysteem. De norm vereist dat de organisatie context, belanghebbenden, wettelijke verplichtingen, ISMS-toepassingsgebied, interfaces en afhankelijkheden definieert. Daarnaast vereist de norm eigenaarschap door leiderschap, een informatiebeveiligingsbeleid, risicobeoordeling, risicobehandeling, een Verklaring van toepasselijkheid, gedocumenteerde informatie, interne audit, directiebeoordeling en continue verbetering.

ISO/IEC 27002:2022 biedt de terminologie voor beheersmaatregelen. Voor OT omvatten de belangrijkste beheersmaatregelen vaak leveranciersbeveiliging, ICT-risicobeheer in de toeleveringsketen, incidentplanning, gereedheid voor bedrijfscontinuïteit, wettelijke en contractuele eisen, beheer van bedrijfsmiddelen, toegangscontrole, kwetsbaarhedenbeheer, back-ups, logging, monitoring, netwerkbeveiliging en scheiding van netwerken.

IEC 62443 biedt het industriële model voor beveiligingsengineering. Het helpt vereisten uit het managementsysteem te vertalen naar OT-praktijken zoals zones, conduits, beveiligingsniveaus, verantwoordelijkheden van asset-eigenaren, verantwoordelijkheden van systeemintegratoren, verwachtingen aan productleveranciers, beperkingen op toegang op afstand, het principe van de minste functionaliteit, accountbeheer, hardening en levenscyclusbeheersmaatregelen.

Clarysec gebruikt deze stack omdat deze twee veelvoorkomende tekortkomingen voorkomt. Ten eerste voorkomt hij dat ISO-implementatie te generiek wordt voor OT. Ten tweede voorkomt hij dat engineeringwerk op basis van IEC 62443 losraakt van bestuursverantwoordelijkheid, NIS2-meldplichten en auditbewijsmateriaal.

Clarysec’s Beleid inzake IoT-/OT-beveiliging benoemt die brug rechtstreeks:

Om te waarborgen dat alle implementaties zijn afgestemd op ISO/IEC 27001-beheersmaatregelen en toepasselijke sectorspecifieke richtsnoeren (bijv. IEC 62443, ISO 27019, NIST SP 800-82).

Die zin doet ertoe. Het beleid is niet alleen een checklist voor apparaathardening. Het verbindt ISO-governance, sectorspecifieke OT-richtsnoeren en operationele beveiliging.

Begin met de scope: welke OT-dienst moet worden beschermd?

Definieer vóór het mappen van beheersmaatregelen de OT-dienst in bedrijfs- en regelgevende termen.

Een plantmanager kan zeggen: “Wij exploiteren de verpakkingslijn.” Een NIS2-beoordeling moet zeggen: “Dit productieproces ondersteunt een essentiële of belangrijke dienst en is afhankelijk van PLC’s, HMI’s, engineeringwerkstations, historians, industriële switches, externe leverancierstoegang, een onderhoudscontractant, een cloudgebaseerde analysefeed en een bedrijfsbrede identiteitsdienst.”

ISO/IEC 27001:2022 clausules 4.1 tot en met 4.4 zijn nuttig omdat ze de organisatie dwingen interne en externe kwesties, belanghebbenden, wettelijke en contractuele eisen, ISMS-grenzen, interfaces en afhankelijkheden te identificeren. Voor NIS2 OT-beveiliging betekent dit dat niet alleen het hoofdkantoornetwerk wordt gemapt, maar ook de industriële systemen en dienstafhankelijkheden die invloed hebben op continuïteit, veiligheid en gereguleerde dienstverlening.

NIST CSF 2.0 versterkt dezelfde logica. De GOVERN-functie vraagt om inzicht in missie, belanghebbenden, afhankelijkheden, wettelijke en regelgevende verplichtingen, kritieke diensten en diensten waarvan de organisatie afhankelijk is. Organizational Profiles bieden een praktische methode om de huidige situatie af te bakenen, een doelsituatie te definiëren, hiaten te analyseren en een geprioriteerd actieplan op te stellen.

Voor een OT-omgeving start Clarysec doorgaans met vijf vragen:

1. Welke gereguleerde of kritieke dienst ondersteunt deze OT-omgeving?
2. Welke OT-bedrijfsmiddelen, netwerken, gegevensstromen en derde partijen zijn voor die dienst vereist?
3. Welke veiligheids-, beschikbaarheids- en operationele beperkingen beïnvloeden beveiligingsmaatregelen?
4. Welke wettelijke, contractuele en sectorale verplichtingen zijn van toepassing, waaronder NIS2, GDPR, DORA waar relevant, klantcontracten en nationale regels?
5. Welke onderdelen van de omgeving vallen binnen het ISMS en welke zijn externe afhankelijkheden waarvoor leveranciersbeheersmaatregelen vereist zijn?

Veel NIS2-programma’s falen hier. Ze bakenen de scope af rond bedrijfs-IT omdat die gemakkelijker te inventariseren is. Auditors en toezichthouders zullen niet onder de indruk zijn als de meest kritieke dienstafhankelijkheid slechts voorkomt als een vage regel met de naam “fabrieksnetwerk”.

Een praktische NIS2 OT-beheersmaatregelenkaart

De onderstaande tabel laat zien hoe thema’s uit NIS2 Article 21 kunnen worden omgezet naar bewijsmateriaal voor ISO/IEC 27001:2022, ISO/IEC 27002:2022 en IEC 62443. Dit vervangt geen formele risicobeoordeling, maar biedt CISO’s, OT-managers en complianceteams een praktisch startpunt.

Deze kaart is bewust gericht op bewijsmateriaal. Onder NIS2 is zeggen “we hebben segmentatie” niet genoeg. U moet laten zien waarom segmentatie passend is, hoe die is geïmplementeerd, hoe uitzonderingen worden goedgekeurd en hoe het ontwerp de impact op de gereguleerde dienst beperkt.

Segmentatie: de eerste OT-beheersmaatregel die auditors zullen toetsen

Als bij het incident van 02:17 een aanvaller zich vanaf een kantoorlaptop naar een engineeringwerkstation had verplaatst, zou de eerste auditvraag voor de hand liggen: waarom kon dat pad bestaan?

Het Beleid inzake IoT-/OT-beveiliging is expliciet:

OT-systemen moeten functioneren binnen eigen netwerken die zijn geïsoleerd van bedrijfs-IT en systemen die vanaf internet bereikbaar zijn.

Voor kleinere omgevingen biedt het Beleid inzake Internet of Things (IoT) / operationele technologie (OT)-beveiliging - mkb een praktische baseline:

Alle Internet of Things (IoT)- en operationele technologie (OT)-apparaten moeten op een afzonderlijk wifi- of VLAN-netwerk worden geplaatst

Voor een volwassen exploitant van kritieke infrastructuur moet segmentatie worden ontworpen rond OT-zones en conduits. Bedrijfsgebruikers mogen geen directe toegang hebben tot PLC-netwerken. Leveranciersverbindingen moeten eindigen in gecontroleerde toegangszones. Historian-replicatie moet goedgekeurde paden gebruiken. Veiligheidssystemen moeten worden geïsoleerd op basis van risico- en engineeringvereisten. Draadloze OT-netwerken moeten worden gerechtvaardigd, gehard en gemonitord.

Zenith Blueprint: een 30-stappenroadmap voor auditors licht in de fase Beheersmaatregelen in de praktijk, stap 20, het principe achter ISO/IEC 27002:2022-netwerkbeveiliging toe:

Industriële besturingssystemen moeten worden geïsoleerd van kantoorverkeer.

Het waarschuwt ook dat netwerkbeveiliging veilige architectuur, segmentatie, toegangscontrole, encryptie van gegevens tijdens transport, monitoring en verdediging in de diepte vereist.

In Zenith Controls: de cross-compliancegids wordt ISO/IEC 27002:2022 control 8.22, Segregation of Networks, behandeld als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, afgestemd op het Protect-cyberbeveiligingsconcept, met systeem- en netwerkbeveiliging als operationele capaciteit en Protection als beveiligingsdomein.

Die classificatie is nuttig voor NIS2-bewijsmateriaal omdat segmentatie geen decoratief diagram is. Het is een preventieve beheersmaatregel die is bedoeld om de blast radius te beperken en de continuïteit van essentiële diensten te behouden.

Kwetsbaarhedenbeheer wanneer OT-systemen niet zomaar kunnen worden gepatcht

NIS2 vereist veilige verwerving, ontwikkeling en onderhoud van netwerk- en informatiesystemen, inclusief behandeling en openbaarmaking van kwetsbaarheden. In IT betekent kwetsbaarhedenbeheer vaak scannen, prioriteren, patchen en verifiëren. OT voegt beperkingen toe.

Een kritieke HMI kan mogelijk alleen tijdens een geplande uitval worden gepatcht. Een firmware-update van een PLC kan betrokkenheid van de leverancier vereisen. Een veiligheidscertificering van een systeem kan vervallen als het onjuist wordt aangepast. Sommige legacy-apparaten hebben mogelijk helemaal geen leverancierssupport meer.

Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 19, biedt de juiste auditlogica voor technische kwetsbaarheden:

Voor systemen die niet onmiddellijk kunnen worden gepatcht, bijvoorbeeld vanwege legacy-software of beperkingen door downtime, moeten compenserende beheersmaatregelen worden geïmplementeerd. Dit kan inhouden dat het systeem achter een firewall wordt geïsoleerd, toegang wordt beperkt of de monitoring wordt verhoogd. In alle gevallen moet het restrisico formeel worden geaccepteerd en geregistreerd, zodat duidelijk is dat het probleem niet is vergeten.

De baseline voor het mkb-beleid is even praktisch:

De inventaris moet elk kwartaal worden beoordeeld om verouderde, niet-ondersteunde of niet-gepatchte apparaten te identificeren

In Zenith Controls wordt ISO/IEC 27002:2022 control 8.8, Management of Technical Vulnerabilities, gemapt als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, afgestemd op Identify en Protect, met dreigings- en kwetsbaarhedenbeheer als operationele capaciteit binnen de domeinen Governance, Ecosystem, Protection en Defense.

Een sterk OT-kwetsbaarheidsdossier moet het volgende bevatten:

• Identificatie van het bedrijfsmiddel, eigenaar, zone en criticaliteit
• Bron van de kwetsbaarheid, zoals leveranciersadvies, scanner, melding van integrator of dreigingsinformatie
• Veiligheids- en beschikbaarheidsbeperkingen
• Haalbaarheid van patching en gepland onderhoudsvenster
• Compenserende beheersmaatregelen, zoals isolatie, toegangscontrolelijsten (ACL’s), uitgeschakelde diensten of verhoogde monitoring
• Goedkeuring door de risico-eigenaar en acceptatie van restrisico
• Verificatiebewijsmateriaal na remediatie of implementatie van compenserende beheersmaatregelen

Zo verandert “we kunnen niet patchen” van een excuus in auditeerbare risicobehandeling.

Externe leverancierstoegang: het brandpunt van NIS2 en IEC 62443

De meeste OT-incidenten hebben ergens een derde-partijcomponent. Een leveranciersaccount. Een laptop van een integrator. Een tool voor onderhoud op afstand. Gedeelde inloggegevens. Een firewalluitzondering die drie jaar geleden tijdelijk was.

NIS2 Article 21 omvat expliciet beveiliging van de toeleveringsketen, leveranciersspecifieke kwetsbaarheden, cyberbeveiligingspraktijken van leveranciers en procedures voor veilige ontwikkeling. NIST CSF 2.0 is op dit punt eveneens gedetailleerd via leverancierscriticaliteit, contractuele eisen, due diligence, doorlopende monitoring, incidentcoördinatie en exitbepalingen.

Clarysec’s Beleid inzake beveiliging van derden en leveranciers - mkb formuleert het principe in duidelijke taal:

Leveranciers mogen alleen toegang krijgen tot de minimale systemen en gegevens die nodig zijn om hun functie uit te voeren.

Voor OT betekent minimale toegang meer dan rolgebaseerde toegang binnen een applicatie. Leverancierstoegang moet:

• vooraf zijn goedgekeurd voor een bepaald onderhoudsdoel;
• tijdgebonden zijn en standaard uitgeschakeld zijn;
• worden beschermd met MFA of continue authenticatie waar passend;
• via een beveiligde jumpserver of een gecontroleerd platform voor toegang op afstand lopen;
• beperkt zijn tot de relevante OT-zone of het relevante bedrijfsmiddel;
• worden gelogd, gemonitord en, bij toegang met hoog risico, als sessie worden opgenomen;
• na voltooiing worden beoordeeld;
• zijn afgedekt door contractuele beveiligings- en incidentmeldingsverplichtingen.

Het enterprise-Beleid inzake IoT-/OT-beveiliging bevat een afzonderlijke eis voor toegang op afstand:

Toegang op afstand (voor beheer of leveranciersservice) moet:

Die clausule verankert het governancepunt, terwijl de gedetailleerde vereisten moeten worden geïmplementeerd in toegangsprocedures, leveranciersovereenkomsten, technische configuratie en monitoringworkflows.

In Zenith Controls wordt ISO/IEC 27002:2022 control 5.21, Managing information security in the ICT supply chain, geclassificeerd als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, afgestemd op het Identify-concept, met beveiliging van leveranciersrelaties als operationele capaciteit en Governance, Ecosystem en Protection als domeinen.

Voor OT helpt die mapping uit te leggen waarom bewijsmateriaal voor toegang op afstand tegelijk thuishoort in dossiers voor leveranciersrisico, identiteitsgovernance, netwerkbeveiliging, incidentrespons en continuïteit.

Incidentrespons: de NIS2-klok ontmoet de controlekamer

Terug naar het alarm van 02:17. De organisatie moet bepalen of de gebeurtenis onder NIS2 significant is. Article 23 vereist melding zonder onnodige vertraging van significante incidenten die de dienstverlening beïnvloeden. De volgorde omvat een vroege waarschuwing binnen 24 uur na kennisname, een incidentmelding binnen 72 uur, tussentijdse updates indien gevraagd en een eindrapport uiterlijk één maand na de incidentmelding, of een voortgangsrapport als het incident nog loopt.

In OT moet incidentrespons vragen beantwoorden die IT-draaiboeken vaak negeren:

• Kan het getroffen apparaat worden geïsoleerd zonder een veiligheidsrisico te creëren?
• Wie heeft de bevoegdheid om productie te stoppen of naar handmatige modus over te schakelen?
• Welke logboeken zijn vluchtig en moeten onmiddellijk worden veiliggesteld?
• Welke leverancier of integrator moet worden benaderd?
• Is de gebeurtenis kwaadwillig, accidenteel, omgevingsgerelateerd of veroorzaakt door een foutieve configuratie?
• Kan er grensoverschrijdende impact zijn of impact op afnemers van de dienst?
• Zijn er persoonsgegevens betrokken, zoals toegangsbadgelogboeken, CCTV, werknemersgegevens of klantregistraties?

Het mkb-OT-beleid geeft een eenvoudige escalatieregel voor afwijkingen:

Afwijkingen moeten onmiddellijk aan de algemeen directeur worden gemeld voor verdere actie

Het bevat ook een veiligheidsbewust indammingsprincipe:

Het apparaat moet onmiddellijk van het netwerk worden losgekoppeld, voor zover dit veilig kan

Die laatste vijf woorden zijn cruciaal. OT-respons kan IT-indammingsacties niet blind kopiëren. “Voor zover dit veilig kan” moet terugkomen in hersteldraaiboeken, escalatiematrices, trainingen en tabletop-oefeningen.

NIST CSF 2.0 sluit hier goed op aan. De RESPOND- en RECOVER-uitkomsten behandelen triage, categorisering, escalatie, oorzaakanalyse, integriteit van het bewijsmateriaal, kennisgeving aan belanghebbenden, indamming, uitroeiing, herstel, integriteitscontroles van back-ups en herstelcommunicatie.

Bouw een bewijslijn van risico naar beheersmaatregel

Een praktische manier om versnipperde naleving te voorkomen is één bewijslijn te bouwen van risico naar regelgeving, naar beheersmaatregel en naar onderbouwing.

Scenario: een leverancier van compressoren op afstand heeft toegang nodig tot een engineeringwerkstation in het OT-netwerk. Het werkstation kan PLC-logica wijzigen. Het leveranciersaccount staat altijd aan, wordt gedeeld door meerdere engineers van de leverancier en is alleen met een wachtwoord beveiligd. Op het werkstation draait software die pas tijdens de volgende onderhoudsstop kan worden geüpgraded.

Leg het risicoscenario vast in het risicoregister:

“Ongeautoriseerde of gecompromitteerde externe leverancierstoegang tot een OT-engineeringwerkstation kan leiden tot ongeautoriseerde wijzigingen in PLC-logica, productieverstoring, veiligheidsimpact en een NIS2-meldingsplichtige onderbreking van dienstverlening.”

Map vervolgens de beheersmaatregelen en verplichtingen.

Het behandelplan moet permanente leverancierstoegang uitschakelen, persoonlijke leveranciersidentiteiten op naam vereisen, MFA afdwingen, toegang via een gecontroleerde jumpserver routeren, toegang beperken tot het engineeringwerkstation, goedkeuring via een onderhoudsticket vereisen, geprivilegieerde sessies registreren, commando’s en afwijkend verkeer monitoren, het niet-gepatchte werkstation als kwetsbaarheidsuitzondering documenteren en incidentrespons bij verdachte leveranciersactiviteit testen.

Zenith Blueprint, fase Risicomanagement, stap 13, geeft de traceerbaarheidslogica voor de SoA:

Kruisverwijzing naar regelgeving: als bepaalde beheersmaatregelen specifiek zijn geïmplementeerd om te voldoen aan GDPR, NIS2 of DORA, kunt u dat opnemen in het risicoregister (als onderdeel van de onderbouwing van de risico-impact) of in de SoA-notities.

De praktische les is eenvoudig. Bewaar NIS2-, ISO- en OT-engineeringbewijsmateriaal niet in afzonderlijke silo’s. Voeg kolommen toe aan het risicoregister en de SoA voor het NIS2 Article 21-thema, de ISO/IEC 27002:2022-beheersmaatregel, de IEC 62443-vereistenfamilie, de eigenaar van het bewijsmateriaal en de auditstatus.

Waar GDPR en DORA passen binnen OT-beveiliging

OT-beveiliging gaat niet altijd alleen over machines. Omgevingen voor kritieke infrastructuur verwerken vaak persoonsgegevens via CCTV, toegangscontrolesystemen, toegangsbadgelogboeken, veiligheidssystemen voor personeel, onderhoudstickets, voertuigtracking, bezoekerssystemen en klantplatforms.

GDPR vereist dat persoonsgegevens rechtmatig, behoorlijk en transparant worden verwerkt, voor specifieke doeleinden worden verzameld, worden beperkt tot wat noodzakelijk is, juist worden gehouden, niet langer worden bewaard dan nodig en worden beschermd met passende technische en organisatorische maatregelen. GDPR vereist ook verantwoordingsplicht, wat betekent dat de verwerkingsverantwoordelijke naleving moet kunnen aantonen.

Voor OT betekent dit dat toegangslogboeken en monitoringregistraties geen ongecontroleerde gegevensopslagplaatsen voor surveillance mogen worden. Bewaartermijnen, toegangsrechten, doelbinding en beoordeling van inbreuken moeten worden ingebouwd in logging en monitoring.

DORA kan van toepassing zijn wanneer financiële entiteiten betrokken zijn, of wanneer een ICT-dienstverlener van derden de operationele weerbaarheid van de financiële sector ondersteunt. DORA omvat ICT-risicobeheer, incidentmelding, weerbaarheidstesten en ICT-risico’s van derden. Voor financiële entiteiten die onder nationale omzettingsregels van NIS2 ook essentiële of belangrijke entiteiten zijn, kan DORA fungeren als sectorspecifiek regime voor overlappende verplichtingen, terwijl coördinatie met NIS2-autoriteiten relevant kan blijven.

Dezelfde bewijsdiscipline geldt: identificatie van bedrijfsmiddelen, bescherming, detectie, continuïteit, back-up, risico’s van derden, testen, training en toezicht door het management.

De auditbril: één beheersmaatregel, meerdere assuranceperspectieven

Een sterke implementatie van NIS2 OT-beveiliging moet standhouden vanuit meerdere auditperspectieven.

Daarom behandelt Clarysec Zenith Controls als een kompas voor cross-compliance. De control attributes helpen het doel van officiële ISO/IEC 27002:2022-beheersmaatregelen uit te leggen, terwijl de mappingaanpak deze beheersmaatregelen verbindt met NIS2, NIST CSF, leveranciersgovernance, continuïteit en auditbewijsmateriaal.

Veelvoorkomende valkuilen bij NIS2 OT-implementatie

De meest voorkomende tekortkomingen in OT-beveiliging worden zelden veroorzaakt door een gebrek aan documenten. Ze ontstaan doordat documenten niet aansluiten op de installatie.

Valkuil 1: IT is eigenaar van het NIS2-programma, maar OT is eigenaar van het risico. Operations, engineering, veiligheid en onderhoud moeten worden betrokken.

Valkuil 2: De inventaris van bedrijfsmiddelen stopt bij servers. Een OT-inventaris moet PLC’s, RTU’s, HMI’s, historians, engineeringwerkstations, industriële switches, sensoren, gateways, appliances voor toegang op afstand en door leveranciers beheerde componenten omvatten.

Valkuil 3: Segmentatie bestaat op een diagram, maar niet in firewallregels. Auditors zullen vragen naar afdwinging, wijzigingsbeheer en monitoringbewijsmateriaal.

Valkuil 4: Kwetsbaarheidsuitzonderingen zijn informeel. Legacy-beperkingen zijn alleen aanvaardbaar wanneer ze zijn gedocumenteerd, goedgekeurd, gemonitord en opnieuw beoordeeld.

Valkuil 5: Leverancierstoegang wordt alleen als leverancierskwestie behandeld. Het is ook een kwestie van toegangscontrole, logging, monitoring, netwerkbeveiliging, incidentrespons en continuïteit.

Valkuil 6: Incidentrespons negeert veiligheid. OT-draaiboeken moeten vastleggen wie apparaten mag isoleren, processen mag stoppen, modi mag wijzigen of toezichthouders mag benaderen.

Valkuil 7: NIS2-melding wordt niet geoefend. Het besluitvormingsproces voor de 24- en 72-uursmijlpalen moet vóór een echt incident worden getest.

Clarysec’s implementatiepad van bestuursverantwoordelijkheid naar OT-bewijsmateriaal

Een praktische implementatie van NIS2 OT-beveiliging kan deze volgorde volgen:

1. Bevestig de NIS2-scope, entiteitsclassificatie en servicecriticaliteit.
2. Definieer de OT-scope binnen het ISMS, inclusief interfaces en afhankelijkheden.
3. Bouw een OT-inventaris van bedrijfsmiddelen en gegevensstromen op.
4. Identificeer wettelijke, contractuele, veiligheids-, privacy- en sectorverplichtingen.
5. Voer OT-specifieke risicobeoordelingsworkshops uit met engineering, operations, IT, SOC, inkoop en management.
6. Map risicobehandeling naar ISO/IEC 27002:2022-beheersmaatregelen, NIS2-thema’s en IEC 62443-implementatiepatronen.
7. Actualiseer de Verklaring van toepasselijkheid met OT-onderbouwing en eigenaren van bewijsmateriaal.
8. Implementeer prioritaire beheersmaatregelen: segmentatie, leverancierstoegang, kwetsbaarheidsbehandeling, monitoring, back-ups en incidentrespons.
9. Actualiseer beleid en procedures, waaronder OT-beveiliging, leveranciersbeveiliging, toegang op afstand, incidentrespons en bedrijfscontinuïteit.
10. Voer tabletop-oefeningen en technische validatieoefeningen uit.
11. Bereid auditdossiers voor NIS2, ISO/IEC 27001:2022, assurance richting klanten en interne governance voor.
12. Verwerk bevindingen in directiebeoordeling en continue verbetering.

Dit weerspiegelt het operationele model in Zenith Blueprint, met name stap 13 voor risicobehandeling en SoA-traceerbaarheid, stap 14 voor beleidsontwikkeling en kruisverwijzingen naar regelgeving, stap 19 voor kwetsbaarhedenbeheer en stap 20 voor netwerkbeveiliging.

Dezelfde aanpak gebruikt Clarysec-beleid om frameworktaal om te zetten in operationele regels. Het enterprise-Beleid inzake IoT-/OT-beveiliging vereist een beveiligingsarchitectuurbeoordeling vóór uitrol:

Alle nieuwe IoT/OT-apparaten moeten vóór uitrol een Beveiligingsarchitectuurbeoordeling ondergaan. Deze beoordeling moet valideren:

Het beleid stelt ook:

Alle verkeer binnen en tussen IoT/OT-netwerken moet continu worden gemonitord met behulp van:

Die clausules creëren governanceankers. Implementatiebewijsmateriaal kan bestaan uit OT IDS-waarschuwingen, firewalllogboeken, SIEM-correlatie, baselineprofielen van verkeer, anomalietickets en responsregistraties.

Hoe goed NIS2 OT-bewijsmateriaal eruitziet

Een NIS2 OT-bewijsdossier moet praktisch genoeg zijn voor engineers en gestructureerd genoeg voor auditors.

Neem voor segmentatie goedgekeurde architectuur, zone- en conduitdiagrammen, exports van firewallregels, wijzigingsregistraties, periodieke regelbeoordelingen, uitzonderingsregistraties en monitoringwaarschuwingen op.

Neem voor leverancierstoegang beoordeling van leverancierscriticaliteit, contractclausules, goedgekeurde toegangsprocedure, persoonlijke accounts op naam, MFA-bewijsmateriaal, toegangslogboeken, sessieopnamen, periodieke toegangsbeoordelingen en offboardingregistraties op.

Neem voor kwetsbaarhedenbeheer inventaris, adviesbronnen, outputs van passieve detectie, kwetsbaarheidstickets, patchplannen, compenserende beheersmaatregelen, risicoacceptatie en afsluitingsbewijsmateriaal op.

Neem voor incidentrespons draaiboeken, escalatiecontacten, NIS2-beslisboom voor meldingen, resultaten van tabletop-oefeningen, incidenttickets, conceptmeldingen aan autoriteiten, regels voor bewijsbehandeling en geleerde lessen op.

Neem voor continuïteit OT-back-upstrategie, offline of beschermde back-ups, resultaten van hersteltests, lijst met kritieke reserveonderdelen, handmatige operationele procedures, herstelprioriteiten en crisiscommunicatieplannen op.

Neem voor governance goedkeuring door bestuur of management, roltoewijzingen, trainingsregistraties, resultaten van interne audits, KPI’s, notulen van risicobeoordelingen en besluiten uit directiebeoordelingen op.

Dit bewijsmodel sluit aan op ISO/IEC 27001:2022 omdat het risicobehandeling, gedocumenteerde informatie, prestatie-evaluatie en continue verbetering ondersteunt. Het sluit aan op NIS2 omdat het passende en evenredige maatregelen aantoont. Het sluit aan op IEC 62443 omdat het kan worden herleid naar OT-architectuur en technische beheersmaatregelen.

Zet uw OT-beveiligingsprogramma om in aantoonbare NIS2-gereedheid

Als uw OT-omgeving een kritieke of gereguleerde dienst ondersteunt, is wachten tot een toezichthouder, klant of incident de hiaten blootlegt de verkeerde strategie.

Begin met één use case met hoge impact: externe leverancierstoegang tot een kritieke OT-zone, kwetsbaarheidsbehandeling voor niet-ondersteunde industriële bedrijfsmiddelen, of segmentatie tussen bedrijfs-IT en OT. Bouw het risicoscenario, map het naar NIS2 Article 21, selecteer ISO/IEC 27002:2022-beheersmaatregelen, vertaal deze naar IEC 62443-implementatiepatronen en verzamel het bewijsmateriaal.

Clarysec kan u helpen dit werk te versnellen met Zenith Blueprint, Zenith Controls, het Beleid inzake IoT-/OT-beveiliging, het Beleid inzake Internet of Things (IoT) / operationele technologie (OT)-beveiliging - mkb en het Beleid inzake beveiliging van derden en leveranciers - mkb.

Uw volgende actie: kies deze week één OT-dienst, map de bijbehorende bedrijfsmiddelen en afhankelijkheden en creëer een bewijslijn van risico naar beheersmaatregel. Als u een gestructureerd implementatiepad wilt, kunnen Clarysec’s 30-stappenroadmap en cross-compliancetoolkit die eerste lijn omzetten in een volledig NIS2 OT-beveiligingsprogramma.