NIS2-OT-Sicherheit: Zuordnung von ISO 27001 und IEC 62443

Um 02:17 Uhr an einem Montag erhält ein Bediener einer Wasseraufbereitungsanlage einen Alarm aus einem Dosiersystem. Die Chemikalienzufuhr liegt weiterhin innerhalb der Sicherheitsgrenzen, aber eine SPS meldet unregelmäßige Befehle, die Engineering-Workstation zeigt fehlgeschlagene Anmeldungen über ein Lieferanten-VPN-Konto, und der diensthabende SOC-Analyst stellt eine Frage, die unter Zeitdruck niemand beantworten möchte.

Handelt es sich um einen IT-Vorfall, einen OT-Vorfall, ein Ereignis mit Auswirkungen auf die Betriebssicherheit oder einen nach NIS2 meldepflichtigen erheblichen Vorfall?

Die Anlage verfügt über Firewalls. Sie verfügt über ISO-Dokumentation. Sie hat eine Lieferantenübersicht. Sie hat sogar einen Incident-Response-Plan. Dieser Plan wurde jedoch für kompromittierte E-Mail-Konten und Cloud-Ausfälle geschrieben, nicht für eine Legacy-Steuerung, die während der Produktion nicht gepatcht werden kann, einen Lieferanten, der Fernzugriff benötigt, um die Leistungserbringung wiederherzustellen, und eine Aufsichtsbehörde, die Nachweise innerhalb der NIS2-Meldefristen erwartet.

Dasselbe Problem zeigt sich in Vorstandsräumen. Ein CISO eines regionalen Energieversorgers verfügt möglicherweise über ein nach ISO/IEC 27001:2022 zertifiziertes Informationssicherheitsmanagementsystem für die Unternehmens-IT, während die Operational-Technology-Landschaft aus einem schwer überschaubaren Geflecht von SPS, RTUs, HMIs, Historian-Systemen, Engineering-Workstations, industriellen Switches und Lieferantenzugangswegen besteht. Die Frage des CEO ist einfach: „Sind wir abgedeckt? Können Sie es nachweisen?“

Für viele wesentliche und wichtige Einrichtungen ist die ehrliche Antwort unbequem. Sie sind teilweise abgedeckt. Sie können es teilweise nachweisen. Aber NIS2-OT-Sicherheit verlangt mehr als generische IT-Compliance.

Erforderlich ist ein einheitliches Betriebsmodell, das ISO/IEC 27001:2022-Governance, die Kontrollsprache von ISO/IEC 27002:2022, industrielle Engineering-Praktiken nach IEC 62443, Cybersicherheitsrisikomanagementmaßnahmen nach NIS2 Article 21 und Nachweise zur Vorfallmeldung nach NIS2 Article 23 miteinander verbindet.

Diese Brücke stellt dieser Leitfaden her.

Warum sich NIS2-OT-Sicherheit von gewöhnlicher IT-Compliance unterscheidet

NIS2 gilt für viele öffentliche und private Einrichtungen, die in der EU Dienste im Anwendungsbereich erbringen. Dazu gehören wesentliche und wichtige Einrichtungen in Sektoren wie Energie, Verkehr, Bankwesen, Finanzmarktinfrastruktur, Gesundheitswesen, Trinkwasser, Abwasser, digitale Infrastruktur, IKT-Service-Management, öffentliche Verwaltung, Weltraum, Postdienste, Abfallwirtschaft, verarbeitendes Gewerbe, Chemie, Lebensmittel, digitale Anbieter und Forschung.

Die Richtlinie verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen zur Steuerung von Cyberrisiken, zur Verhinderung oder Minimierung von Auswirkungen von Vorfällen und zum Schutz der Dienstkontinuität. Article 21 umfasst einen All-Gefahren-Ansatz mit Risikoanalyse, Sicherheitsrichtlinien, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Betriebskontinuität, Krisenmanagement, Sicherheit der Lieferkette, sicherer Beschaffung und Wartung, Schwachstellenbehandlung und -offenlegung, Bewertung der Wirksamkeit, Cyberhygiene, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management, MFA oder kontinuierlicher Authentifizierung, sicherer Kommunikation sowie, soweit angemessen, Notfallkommunikation.

Diese Anforderungen klingen für ein ISO/IEC 27001:2022-Team vertraut. In OT verhalten sie sich jedoch jeweils anders.

Eine Schwachstelle in einem Webserver kann häufig innerhalb weniger Tage gepatcht werden. Eine Schwachstelle in einer Turbinensteuerung kann eine Herstellerfreigabe, ein Wartungsfenster, eine sicherheitstechnische Prüfung und Rückfallbetriebsverfahren erfordern. Ein Laptop kann neu aufgesetzt werden. Ein Produktions-HMI kann von einem Legacy-Betriebssystem abhängen, weil die industrielle Anwendung für eine neuere Plattform nicht zertifiziert wurde. Ein SOC-Playbook kann vorsehen: „Host isolieren“, während der OT-Ingenieur antwortet: „Nicht, bevor wir wissen, ob die Isolation die Druckregelung beeinflusst.“

Der Unterschied ist nicht nur technischer Natur. IT priorisiert üblicherweise Vertraulichkeit, Integrität und Verfügbarkeit. OT priorisiert Verfügbarkeit, Prozessintegrität und Betriebssicherheit. Eine Sicherheitskontrolle, die Latenz verursacht, einen Neustart erfordert oder einen physischen Prozess unterbricht, kann ohne Freigabe durch das Engineering unzulässig sein.

NIS2 nimmt OT nicht vom Cybersicherheitsrisikomanagement aus. Die Organisation muss nachweisen, dass Kontrollen dem Risiko angemessen sind und im Verhältnis zur betrieblichen Realität stehen.

Der Kontroll-Stack: NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022 und IEC 62443

Ein belastbares Programm zur NIS2-OT-Sicherheit beginnt mit einem mehrschichtigen Kontroll-Stack.

ISO/IEC 27001:2022 stellt das Managementsystem bereit. Die Norm verlangt, dass die Organisation Kontext, interessierte Parteien, regulatorische Verpflichtungen, ISMS-Geltungsbereich, Schnittstellen und Abhängigkeiten definiert. Sie verlangt außerdem Verantwortung der Leitung, eine Informationssicherheitsleitlinie, Risikobeurteilung, Risikobehandlung, eine Anwendbarkeitserklärung, dokumentierte Informationen, internes Audit, Managementbewertung und kontinuierliche Verbesserung.

ISO/IEC 27002:2022 stellt das Kontrollvokabular bereit. Für OT gehören zu den wichtigsten Kontrollen häufig Lieferantensicherheit, Management von IKT-Lieferkettenrisiken, Vorfallplanung, Bereitschaft zur Betriebskontinuität, rechtliche und vertragliche Anforderungen, Asset-Management, Zugriffskontrolle, Schwachstellenmanagement, Backups, Protokollierung, Überwachung, Netzwerksicherheit und Netzwerksegmentierung.

IEC 62443 stellt das industrielle Security-Engineering-Modell bereit. Es hilft, Anforderungen des Managementsystems in OT-Praktiken wie Zonen, Conduits, Sicherheitsstufen, Verantwortlichkeiten von Asset-Verantwortlichen, Verantwortlichkeiten von Systemintegratoren, Erwartungen an Produktlieferanten, Beschränkungen für Fernzugriff, Prinzip der minimalen Funktionalität, Kontenmanagement, Härtung und Lebenszykluskontrollen zu übersetzen.

Clarysec nutzt diesen Stack, weil er zwei häufige Fehler vermeidet. Erstens verhindert er, dass eine ISO-Umsetzung für OT zu generisch bleibt. Zweitens verhindert er, dass Engineering-Arbeiten nach IEC 62443 von der Verantwortung des Leitungsorgans, NIS2-Meldepflichten und Auditnachweisen entkoppelt werden.

Clarysecs IoT-/OT-Sicherheitsrichtlinie benennt diese Brücke direkt:

Um sicherzustellen, dass alle Bereitstellungen an ISO/IEC 27001-Kontrollen und an anwendbaren branchenspezifischen Leitlinien ausgerichtet sind (z. B. IEC 62443, ISO 27019, NIST SP 800-82).

Dieser Satz ist wichtig. Die Richtlinie ist nicht nur eine Checkliste zur Gerätehärtung. Sie verbindet ISO-Governance, OT-Branchenguidance und operative Sicherheit.

Mit dem Geltungsbereich beginnen: Welcher OT-Dienst muss geschützt werden?

Bevor Kontrollen zugeordnet werden, muss der OT-Dienst in geschäftlicher und regulatorischer Sprache definiert werden.

Ein Anlagenleiter sagt möglicherweise: „Wir betreiben die Verpackungslinie.“ Eine NIS2-Bewertung sollte formulieren: „Dieser Produktionsprozess unterstützt einen wesentlichen oder wichtigen Dienst und hängt von SPS, HMIs, Engineering-Workstations, Historian-Systemen, industriellen Switches, Fernzugriff durch Lieferanten, einem Wartungsdienstleister, einem Cloud-Analyse-Feed und einem unternehmensweiten Identitätsdienst ab.“

ISO/IEC 27001:2022-Klauseln 4.1 bis 4.4 sind hilfreich, weil sie die Organisation zwingen, interne und externe Themen, interessierte Parteien, rechtliche und vertragliche Anforderungen, ISMS-Grenzen, Schnittstellen und Abhängigkeiten zu identifizieren. Für NIS2-OT-Sicherheit bedeutet das, nicht nur das Netzwerk der Zentrale abzubilden, sondern auch die industriellen Systeme und Serviceabhängigkeiten, die Kontinuität, Betriebssicherheit und regulierte Leistungserbringung beeinflussen.

NIST CSF 2.0 verstärkt dieselbe Logik. Die Funktion GOVERN verlangt ein Verständnis von Mission, Stakeholdern, Abhängigkeiten, rechtlichen und regulatorischen Verpflichtungen, kritischen Services sowie von Services, von denen die Organisation abhängt. Organisationsprofile bieten eine praktische Methode, um einen Ist-Zustand abzugrenzen, einen Zielzustand zu definieren, Lücken zu analysieren und einen priorisierten Maßnahmenplan zu erstellen.

Für eine OT-Umgebung beginnt Clarysec typischerweise mit fünf Fragen:

1. Welchen regulierten oder kritischen Dienst unterstützt diese OT-Umgebung?
2. Welche OT-Assets, Netzwerke, Datenflüsse und Dritten sind für diesen Dienst erforderlich?
3. Welche Sicherheits-, Verfügbarkeits- und Betriebsbeschränkungen beeinflussen Sicherheitskontrollen?
4. Welche rechtlichen, vertraglichen und branchenspezifischen Verpflichtungen gelten, einschließlich NIS2, GDPR, DORA soweit relevant, Kundenverträgen und nationalen Vorschriften?
5. Welche Teile der Umgebung liegen innerhalb des ISMS, und welche sind externe Abhängigkeiten, die Lieferantenkontrollen erfordern?

Viele NIS2-Programme scheitern genau hier. Sie grenzen den Geltungsbereich um die Unternehmens-IT herum ab, weil diese einfacher zu inventarisieren ist. Auditoren und Aufsichtsbehörden werden nicht überzeugt sein, wenn die kritischste Serviceabhängigkeit nur als unscharfe Zeile „Fabriknetzwerk“ erscheint.

Eine praktische NIS2-OT-Kontrollzuordnung

Die folgende Tabelle zeigt, wie Themen aus NIS2 Article 21 in Nachweise nach ISO/IEC 27001:2022, ISO/IEC 27002:2022 und IEC 62443 überführt werden können. Sie ersetzt keine formale Risikobeurteilung, bietet CISOs, OT-Managern und Compliance-Teams aber einen praktischen Ausgangspunkt.

Diese Zuordnung ist bewusst nachweisorientiert. Unter NIS2 reicht die Aussage „wir haben Segmentierung“ nicht aus. Sie müssen zeigen, warum die Segmentierung angemessen ist, wie sie umgesetzt wurde, wie Ausnahmen genehmigt werden und wie das Design die Auswirkungen auf den regulierten Dienst reduziert.

Segmentierung: die erste OT-Kontrolle, die Auditoren prüfen werden

Wenn der Vorfall um 02:17 Uhr einen Angreifer umfasst hätte, der sich von einem Büro-Laptop zu einer Engineering-Workstation bewegt, wäre die erste Auditfrage offensichtlich: Warum konnte dieser Pfad überhaupt existieren?

Die IoT-/OT-Sicherheitsrichtlinie ist eindeutig:

OT-Systeme müssen in dedizierten Netzwerken betrieben werden, die von Unternehmens-IT und internetseitig erreichbaren Systemen isoliert sind.

Für kleinere Umgebungen liefert die Sicherheitsrichtlinie für Internet of Things (IoT) / Operational Technology (OT) - SME eine praktikable Baseline:

Alle Internet of Things (IoT)- und Operational Technology (OT)-Geräte müssen in einem separaten Wi-Fi- oder VLAN-Netzwerk platziert werden

Für einen ausgereiften Betreiber kritischer Infrastrukturen sollte Segmentierung um OT-Zonen und Conduits herum gestaltet werden. Unternehmensbenutzer sollten keinen direkten Zugriff auf SPS-Netzwerke haben. Lieferantenverbindungen sollten in kontrollierten Zugriffszonen enden. Historian-Replikation sollte genehmigte Pfade nutzen. Sicherheitssysteme sollten nach Risiko- und Engineering-Anforderungen isoliert sein. Drahtlose OT-Netzwerke sollten begründet, gehärtet und überwacht werden.

Zenith Blueprint: 30-Schritte-Roadmap für Auditoren erläutert in der Phase „Kontrollen in Aktion“, Schritt 20, das Prinzip hinter der Netzwerksicherheit nach ISO/IEC 27002:2022:

Industrielle Steuerungssysteme sollten vom Büroverkehr isoliert werden.

Außerdem wird darauf hingewiesen, dass Netzwerksicherheit eine sichere Architektur, Segmentierung, Zugriffskontrolle, Verschlüsselung bei der Übertragung, Überwachung und Defense in Depth erfordert.

In Zenith Controls: Der Cross-Compliance-Leitfaden wird ISO/IEC 27002:2022 Control 8.22, Segregation of Networks, als präventive Kontrolle behandelt, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt, am Cybersicherheitskonzept Protect ausgerichtet ist, System- und Netzwerksicherheit als operative Fähigkeit hat und Protection als Sicherheitsdomäne verwendet.

Diese Klassifizierung ist für NIS2-Nachweise hilfreich, weil Segmentierung kein dekoratives Diagramm ist. Sie ist eine präventive Kontrolle, die den Wirkungsradius reduziert und die Kontinuität wesentlicher Dienste erhält.

Schwachstellenmanagement, wenn OT-Systeme nicht einfach gepatcht werden können

NIS2 verlangt sichere Beschaffung, Entwicklung und Wartung von Netzwerk- und Informationssystemen einschließlich Schwachstellenbehandlung und -offenlegung. In der IT bedeutet Schwachstellenmanagement häufig: scannen, priorisieren, patchen und verifizieren. OT bringt zusätzliche Einschränkungen mit sich.

Ein kritisches HMI ist möglicherweise nur während eines geplanten Stillstands patchbar. Ein Firmware-Update für eine SPS kann die Beteiligung des Herstellers erfordern. Ein sicherheitszertifiziertes System kann seine Zertifizierung verlieren, wenn es unsachgemäß geändert wird. Manche Legacy-Geräte haben überhaupt keinen Herstellersupport mehr.

Zenith Blueprint, Phase „Kontrollen in Aktion“, Schritt 19, liefert die richtige Auditlogik für technische Schwachstellen:

Für Systeme, die nicht sofort gepatcht werden können, etwa wegen Legacy-Software oder Einschränkungen durch Ausfallzeiten, sind kompensierende Kontrollen umzusetzen. Dazu kann gehören, das System hinter einer Firewall zu isolieren, den Zugriff zu begrenzen oder die Überwachung zu erhöhen. In jedem Fall ist das Restrisiko zu dokumentieren und formal zu akzeptieren, damit erkennbar ist, dass das Problem nicht vergessen wurde.

Die SME-Richtlinien-Baseline ist ähnlich praxisnah:

Das Inventar muss vierteljährlich überprüft werden, um veraltete, nicht unterstützte oder ungepatchte Geräte zu identifizieren

In Zenith Controls wird ISO/IEC 27002:2022 Control 8.8, Management of Technical Vulnerabilities, als präventive Kontrolle abgebildet, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt, an Identify und Protect ausgerichtet ist und Bedrohungs- und Schwachstellenmanagement als operative Fähigkeit über die Domänen Governance, Ecosystem, Protection und Defense hinweg nutzt.

Eine belastbare OT-Schwachstellendatei sollte Folgendes enthalten:

• Asset-Kennung, Verantwortlicher, Zone und Kritikalität
• Quelle der Schwachstelle, z. B. Herstellerhinweis, Scanner, Integratorenmeldung oder Bedrohungsinformationen
• Sicherheits- und Verfügbarkeitsbeschränkungen
• Patch-Machbarkeit und geplantes Wartungsfenster
• Kompensierende Kontrollen, z. B. Isolation, Zugriffskontrolllisten, deaktivierte Dienste oder erhöhte Überwachung
• Genehmigung durch den Risikoverantwortlichen und Restrisikoakzeptanz
• Verifikationsnachweise nach Behebung oder Umsetzung kompensierender Kontrollen

So wird aus „wir können nicht patchen“ keine Ausrede, sondern auditierbare Risikobehandlung.

Fernzugriff durch Lieferanten: der Brennpunkt zwischen NIS2 und IEC 62443

Die meisten OT-Vorfälle haben irgendwo eine Drittparteidimension. Ein Lieferantenkonto. Ein Integrator-Laptop. Ein Fernwartungswerkzeug. Gemeinsam genutzte Zugangsdaten. Eine Firewall-Ausnahme, die vor drei Jahren nur vorübergehend sein sollte.

NIS2 Article 21 umfasst ausdrücklich Sicherheit der Lieferkette, lieferantenspezifische Schwachstellen, Cybersicherheitspraktiken von Lieferanten und sichere Entwicklungsverfahren. NIST CSF 2.0 ist in diesem Punkt ebenfalls detailliert und behandelt Lieferantenkritikalität, vertragliche Anforderungen, Due Diligence, laufende Überwachung, Vorfallskoordination und Exit-Regelungen.

Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit - SME formuliert das Prinzip klar:

Lieferanten dürfen nur Zugriff auf die minimal erforderlichen Systeme und Daten erhalten, die zur Erfüllung ihrer Funktion notwendig sind.

Für OT bedeutet minimaler Zugriff mehr als rollenbasierter Zugriff in einer Anwendung. Lieferantenzugriff muss:

• für einen definierten Wartungszweck vorab genehmigt sein,
• zeitlich begrenzt und standardmäßig deaktiviert sein,
• soweit angemessen durch MFA oder kontinuierliche Authentifizierung geschützt sein,
• über einen sicheren Jump Host oder eine kontrollierte Fernzugriffsplattform geleitet werden,
• auf die relevante OT-Zone oder das relevante Asset beschränkt sein,
• protokolliert, überwacht und bei Hochrisikozugriffen sitzungsaufgezeichnet werden,
• nach Abschluss überprüft werden,
• durch vertragliche Sicherheits- und Vorfallmeldepflichten abgedeckt sein.

Die unternehmensweite IoT-/OT-Sicherheitsrichtlinie enthält eine dedizierte Anforderung an Fernzugriff:

Fernzugriff (für Management oder Lieferantenwartung) muss:

Diese Klausel verankert den Governance-Punkt, während die Detailanforderungen in Zugriffsverfahren, Lieferantenvereinbarungen, technischer Konfiguration und Überwachungs-Workflows umgesetzt werden sollten.

In Zenith Controls wird ISO/IEC 27002:2022 Control 5.21, Managing information security in the ICT supply chain, als präventive Kontrolle klassifiziert, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt, am Identify-Konzept ausgerichtet ist und Sicherheit in Lieferantenbeziehungen als operative Fähigkeit sowie Governance, Ecosystem und Protection als Domänen nutzt.

Für OT erklärt diese Zuordnung, warum Nachweise zum Fernzugriff gleichzeitig in Dateien zu Lieferantenrisiko, Identitätsgovernance, Netzwerksicherheit, Incident Response und Kontinuität gehören.

Incident Response: Die NIS2-Uhr trifft auf den Leitstand

Zurück zum Alarm um 02:17 Uhr. Die Organisation muss entscheiden, ob das Ereignis unter NIS2 erheblich ist. Article 23 verlangt die unverzügliche Meldung erheblicher Vorfälle, die die Erbringung des Dienstes beeinträchtigen. Die Abfolge umfasst eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, eine Vorfallmeldung innerhalb von 72 Stunden, Zwischenaktualisierungen auf Anforderung und einen Abschlussbericht spätestens einen Monat nach der Vorfallmeldung oder einen Fortschrittsbericht, wenn der Vorfall noch andauert.

In OT muss Incident Response Fragen beantworten, die IT-Playbooks häufig ausblenden:

• Kann das betroffene Gerät isoliert werden, ohne ein Sicherheitsrisiko zu erzeugen?
• Wer ist befugt, die Produktion zu stoppen oder in den manuellen Modus zu wechseln?
• Welche Protokolle sind flüchtig und müssen sofort gesichert werden?
• Welcher Lieferant oder Integrator muss kontaktiert werden?
• Ist das Ereignis böswillig, versehentlich, umweltbedingt oder durch Fehlkonfiguration verursacht?
• Könnte es grenzüberschreitende Auswirkungen oder Auswirkungen auf Dienstempfänger geben?
• Sind personenbezogene Daten betroffen, z. B. Ausweisprotokolle, CCTV, Beschäftigtendaten oder Kundendienstaufzeichnungen?

Die SME-OT-Richtlinie gibt eine einfache Eskalationsregel für Anomalien vor:

Jede Anomalie muss dem General Manager unverzüglich zur weiteren Bearbeitung gemeldet werden

Sie enthält außerdem ein sicherheitsbewusstes Eindämmungsprinzip:

Das Gerät muss unverzüglich vom Netzwerk getrennt werden, sofern dies sicher möglich ist

Diese letzten fünf Wörter sind entscheidend. OT-Reaktionen dürfen IT-Eindämmungsmaßnahmen nicht blind kopieren. „Sofern dies sicher möglich ist“ muss sich in Runbooks, Eskalationsmatrizen, Schulungen und Tabletop-Übungen wiederfinden.

NIST CSF 2.0 lässt sich hier gut zuordnen. Seine Respond- und Recover-Ergebnisse umfassen Triage, Kategorisierung, Eskalation, Ursachenanalyse, Integrität der Beweismittel, Benachrichtigung von Interessenträgern, Eindämmung, Beseitigung, Wiederherstellung, Integritätsprüfungen von Backups und Wiederherstellungskommunikation.

Eine Nachweiskette von Risiko zu Kontrolle aufbauen

Ein praktischer Weg, fragmentierte Compliance zu vermeiden, besteht darin, eine durchgängige Nachweiskette vom Risiko über die Regulierung und Kontrolle bis zum Nachweis aufzubauen.

Szenario: Ein externer Kompressorlieferant benötigt Zugriff auf eine Engineering-Workstation im OT-Netzwerk. Die Workstation kann SPS-Logik ändern. Das Lieferantenkonto ist dauerhaft aktiviert, wird von mehreren Lieferanteningenieuren gemeinsam genutzt und ist nur durch ein Passwort geschützt. Auf der Workstation läuft Software, die erst beim nächsten Wartungsstillstand aktualisiert werden kann.

Formulieren Sie das Risikoszenario im Risikoregister:

„Nicht autorisierter oder kompromittierter Fernzugriff eines Lieferanten auf eine OT-Engineering-Workstation könnte zu nicht autorisierten Änderungen an der SPS-Logik, Produktionsunterbrechung, Auswirkungen auf die Betriebssicherheit und einer nach NIS2 meldepflichtigen Dienstunterbrechung führen.“

Ordnen Sie anschließend Kontrollen und Verpflichtungen zu.

Der Behandlungsplan sollte dauerhaften Lieferantenzugriff deaktivieren, personenbezogene Lieferantenidentitäten verlangen, MFA durchsetzen, den Zugriff über einen kontrollierten Jump-Server leiten, den Zugriff auf die Engineering-Workstation begrenzen, eine Genehmigung über Wartungstickets verlangen, privilegierte Sitzungen aufzeichnen, Befehle und anormalen Datenverkehr überwachen, die ungepatchte Workstation als Schwachstellenausnahme dokumentieren und Incident Response für verdächtige Lieferantenaktivitäten testen.

Zenith Blueprint, Phase Risikomanagement, Schritt 13, liefert die Rückverfolgbarkeitslogik für die SoA:

Vorschriften querverweisen: Wenn bestimmte Kontrollen ausdrücklich umgesetzt werden, um GDPR, NIS2 oder DORA einzuhalten, können Sie dies entweder im Risikoregister (als Teil der Begründung der Risikoauswirkungen) oder in den SoA-Anmerkungen dokumentieren.

Die praktische Lehre ist einfach. Halten Sie NIS2-, ISO- und OT-Engineering-Nachweise nicht in getrennten Silos. Ergänzen Sie Risikoregister und SoA um Spalten für das Thema aus NIS2 Article 21, die Kontrolle nach ISO/IEC 27002:2022, die Anforderungsfamilie nach IEC 62443, den Nachweisverantwortlichen und den Auditstatus.

Wo GDPR und DORA in der OT-Sicherheit einzuordnen sind

OT-Sicherheit betrifft nicht immer nur Maschinen. Umgebungen kritischer Infrastrukturen verarbeiten häufig personenbezogene Daten über CCTV, Zutrittskontrollsysteme, Ausweisprotokolle, Arbeitssicherheitssysteme, Wartungstickets, Fahrzeugortung, Besuchersysteme und Kundendienstplattformen.

GDPR verlangt, dass personenbezogene Daten rechtmäßig, fair und transparent verarbeitet, für festgelegte Zwecke erhoben, auf das Erforderliche begrenzt, sachlich richtig gehalten, nur so lange wie nötig aufbewahrt und durch angemessene technische und organisatorische Maßnahmen geschützt werden. Außerdem verlangt GDPR Rechenschaftspflicht, d. h. der Verantwortliche muss die Einhaltung nachweisen können.

Für OT bedeutet dies, dass Zugriffsprotokolle und Überwachungsaufzeichnungen nicht zu unkontrollierten Überwachungsdatenspeichern werden dürfen. Aufbewahrung, Zugriffsrechte, Zweckbindung und Bewertung von Verstößen müssen in Protokollierung und Überwachung eingebaut werden.

DORA kann gelten, wenn Finanzunternehmen beteiligt sind oder wenn ein IKT-Drittdienstleister die operative Resilienz des Finanzsektors unterstützt. DORA behandelt IKT-Risikomanagement, Vorfallmeldung, Resilienztests und IKT-Drittparteienrisiko. Für Finanzunternehmen, die nach den nationalen NIS2-Umsetzungsvorschriften zugleich wesentliche oder wichtige Einrichtungen sind, kann DORA als sektorspezifisches Regime für überschneidende Verpflichtungen wirken, während die Koordination mit NIS2-Behörden weiterhin relevant bleiben kann.

Es gelten dieselben Nachweisdisziplinen: Asset-Identifizierung, Schutz, Erkennung, Kontinuität, Backup, Drittparteienrisiko, Tests, Schulung und Managementaufsicht.

Die Auditperspektive: eine Kontrolle, mehrere Assurance-Sichtweisen

Eine starke Umsetzung der NIS2-OT-Sicherheit sollte mehreren Auditperspektiven standhalten.

Deshalb behandelt Clarysec Zenith Controls als Cross-Compliance-Kompass. Seine Kontrollattribute helfen, den Zweck offizieller ISO/IEC 27002:2022-Kontrollen zu erklären, während der Zuordnungsansatz diese Kontrollen mit NIS2, NIST CSF, Lieferanten-Governance, Kontinuität und Auditnachweisen verbindet.

Häufige Fallstricke bei der Umsetzung von NIS2 in OT

Die häufigsten OT-Sicherheitsmängel entstehen selten aus einem Mangel an Dokumenten. Sie entstehen aus Dokumenten, die nicht zur Anlage passen.

Fallstrick 1: Die IT verantwortet das NIS2-Programm, aber OT trägt das Risiko. Betrieb, Engineering, Betriebssicherheit und Wartung müssen eingebunden werden.

Fallstrick 2: Das Asset-Inventar endet bei Servern. Ein OT-Inventar muss SPS, RTUs, HMIs, Historian-Systeme, Engineering-Workstations, industrielle Switches, Sensoren, Gateways, Fernzugriffs-Appliances und lieferantenverwaltete Komponenten umfassen.

Fallstrick 3: Segmentierung existiert im Diagramm, aber nicht in Firewall-Regeln. Auditoren werden Nachweise zur Durchsetzung, Änderungskontrolle und Überwachung anfordern.

Fallstrick 4: Schwachstellenausnahmen sind informell. Legacy-Einschränkungen sind nur akzeptabel, wenn sie dokumentiert, genehmigt, überwacht und erneut bewertet werden.

Fallstrick 5: Lieferantenzugriff wird nur als Lieferantenthema behandelt. Er ist zugleich ein Thema für Zugriffskontrolle, Protokollierung, Überwachung, Netzwerksicherheit, Incident Response und Kontinuität.

Fallstrick 6: Incident Response ignoriert Betriebssicherheit. OT-Playbooks müssen definieren, wer Geräte isolieren, Prozesse stoppen, Modi wechseln oder Aufsichtsbehörden kontaktieren darf.

Fallstrick 7: NIS2-Meldung wird nicht geübt. Der Entscheidungsprozess für 24-Stunden- und 72-Stunden-Fristen sollte vor einem echten Ereignis getestet werden.

Clarysecs Umsetzungspfad von der Verantwortung des Leitungsorgans zu OT-Nachweisen

Eine praktische Umsetzung der NIS2-OT-Sicherheit kann dieser Abfolge folgen:

1. NIS2-Geltungsbereich, Einstufung der Einrichtung und Servicekritikalität bestätigen.
2. OT-Geltungsbereich innerhalb des ISMS einschließlich Schnittstellen und Abhängigkeiten definieren.
3. OT-Asset- und Datenflussinventar aufbauen.
4. Rechtliche, vertragliche, sicherheitsbezogene, datenschutzbezogene und branchenspezifische Verpflichtungen identifizieren.
5. OT-spezifische Workshops zur Risikobeurteilung mit Engineering, Betrieb, IT, SOC, Beschaffung und Management durchführen.
6. Risikobehandlung den Kontrollen nach ISO/IEC 27002:2022, NIS2-Themen und Umsetzungsmustern nach IEC 62443 zuordnen.
7. Anwendbarkeitserklärung mit OT-Begründung und Nachweisverantwortlichen aktualisieren.
8. Priorisierte Kontrollen umsetzen: Segmentierung, Lieferantenzugriff, Schwachstellenbehandlung, Überwachung, Backups und Incident Response.
9. Richtlinien und Verfahren aktualisieren, einschließlich OT-Sicherheit, Lieferantensicherheit, Fernzugriff, Incident Response und Betriebskontinuität.
10. Tabletop- und technische Validierungsübungen durchführen.
11. Auditpakete für NIS2, ISO/IEC 27001:2022, Kunden-Assurance und interne Governance vorbereiten.
12. Feststellungen in Managementbewertung und kontinuierliche Verbesserung einspeisen.

Dies spiegelt das Betriebsmodell in Zenith Blueprint wider, insbesondere Schritt 13 für Risikobehandlung und SoA-Rückverfolgbarkeit, Schritt 14 für Richtlinienentwicklung und regulatorische Querverweise, Schritt 19 für Schwachstellenmanagement und Schritt 20 für Netzwerksicherheit.

Derselbe Ansatz nutzt Clarysec-Richtlinien, um Framework-Sprache in operative Regeln zu übersetzen. Die unternehmensweite IoT-/OT-Sicherheitsrichtlinie verlangt eine Sicherheitsarchitekturprüfung vor der Bereitstellung:

Alle neuen IoT/OT-Geräte müssen vor der Bereitstellung eine Sicherheitsarchitekturprüfung durchlaufen. Diese Prüfung muss validieren:

Außerdem heißt es:

Der gesamte Datenverkehr innerhalb und zwischen IoT/OT-Netzwerken muss kontinuierlich überwacht werden durch:

Diese Klauseln schaffen Governance-Anker. Umsetzungsnachweise können OT-IDS-Warnmeldungen, Firewall-Protokolle, SIEM-Korrelation, Baseline-Profile des Datenverkehrs, Anomalietickets und Reaktionsaufzeichnungen umfassen.

Wie gute NIS2-OT-Nachweise aussehen

Ein NIS2-OT-Nachweispaket sollte für Ingenieure praktisch genug und für Auditoren strukturiert genug sein.

Für Segmentierung: genehmigte Architektur, Zonen- und Conduit-Diagramme, Exporte von Firewall-Regeln, Änderungsaufzeichnungen, regelmäßige Regelüberprüfungen, Ausnahmeaufzeichnungen und Überwachungswarnmeldungen aufnehmen.

Für Lieferantenzugriff: Bewertung der Lieferantenkritikalität, Vertragsklauseln, genehmigtes Zugriffsverfahren, personenbezogene Konten, MFA-Nachweise, Zugriffsprotokolle, Sitzungsaufzeichnungen, regelmäßige Berechtigungsüberprüfung und Offboarding-Aufzeichnungen aufnehmen.

Für Schwachstellenmanagement: Inventar, Hinweisquellen, Ergebnisse passiver Erkennung, Schwachstellentickets, Patch-Pläne, kompensierende Kontrollen, Risikoakzeptanz und Abschlussnachweise aufnehmen.

Für Incident Response: Playbooks, Eskalationskontakte, Entscheidungsbaum für NIS2-Meldungen, Tabletop-Ergebnisse, Vorfalltickets, Entwürfe für Behördenmeldungen, Regeln zum Umgang mit Beweismitteln und Lessons Learned aufnehmen.

Für Kontinuität: OT-Backup-Strategie, Offline- oder geschützte Backups, Ergebnisse von Wiederherstellungstests, Liste kritischer Ersatzteile, manuelle Betriebsverfahren, Wiederherstellungsprioritäten und Krisenkommunikationspläne aufnehmen.

Für Governance: Genehmigung durch Leitungsorgan oder Management, Rollenzuweisungen, Schulungsnachweise, Ergebnisse interner Audits, KPIs, Protokolle von Risikoüberprüfungen und Entscheidungen der Managementbewertung aufnehmen.

Dieses Nachweismodell ist an ISO/IEC 27001:2022 ausgerichtet, weil es Risikobehandlung, dokumentierte Informationen, Leistungsbewertung und kontinuierliche Verbesserung unterstützt. Es ist an NIS2 ausgerichtet, weil es angemessene und verhältnismäßige Maßnahmen nachweist. Es ist an IEC 62443 ausgerichtet, weil es auf OT-Architektur und Engineering-Kontrollen zurückgeführt werden kann.

Ihr OT-Sicherheitsprogramm in auditierbare NIS2-Bereitschaft überführen

Wenn Ihre OT-Umgebung einen kritischen oder regulierten Dienst unterstützt, ist es die falsche Strategie, auf eine Aufsichtsbehörde, einen Kunden oder einen Vorfall zu warten, der die Lücken offenlegt.

Beginnen Sie mit einem Anwendungsfall mit hoher Wirkung: Fernzugriff durch Lieferanten auf eine kritische OT-Zone, Schwachstellenbehandlung für nicht unterstützte industrielle Assets oder Segmentierung zwischen Unternehmens-IT und OT. Erstellen Sie das Risikoszenario, ordnen Sie es NIS2 Article 21 zu, wählen Sie Kontrollen nach ISO/IEC 27002:2022 aus, übersetzen Sie diese in Umsetzungsmuster nach IEC 62443 und sammeln Sie die Nachweise.

Clarysec kann Sie dabei mit Zenith Blueprint, Zenith Controls, der IoT-/OT-Sicherheitsrichtlinie, der Sicherheitsrichtlinie für Internet of Things (IoT) / Operational Technology (OT) - SME und der Richtlinie zur Lieferanten- und Drittparteiensicherheit - SME unterstützen und die Umsetzung beschleunigen.

Ihre nächste Maßnahme: Wählen Sie einen OT-Dienst aus, bilden Sie dessen Assets und Abhängigkeiten ab und erstellen Sie noch in dieser Woche eine Nachweiskette von Risiko zu Kontrolle. Wenn Sie einen strukturierten Umsetzungspfad wünschen, können Clarysecs 30-Schritte-Roadmap und das Cross-Compliance-Toolkit diese erste Linie in ein vollständiges Programm zur NIS2-OT-Sicherheit überführen.