Erreichung der NIS-2-Konformität durch die IEC 62443: Ein praktischer Leitfaden
Team Shieldworkz
Die NIS2-Richtlinie der Europäischen Union, die im Oktober 2024 in den Mitgliedstaaten in Kraft getreten ist, stellt den folgenreichsten regulatorischen Eingriff in die Cybersicherheit kritischer Infrastrukturen seit einer Generation dar. Im Gegensatz zu ihrer Vorgängerin greift NIS2 direkt in Operational-Technology-Umgebungen (OT) ein: die Prozessleitsysteme, speicherprogrammierbaren Steuerungen (SPS/PLC), verteilten Steuerungssysteme und industriellen Netzwerke, die Fertigungsanlagen, Energienetze, Wasseraufbereitungsanlagen, Transportnetze sowie Öl- und Gasleitungen in der gesamten EU und darüber hinaus stützen.
Für OT-Sicherheitsverantwortliche ist die Compliance-Herausforderung akut. Die Anforderungen an das Risikomanagement der NIS2 – verankert in Artikel 21 – verlangen Praktiken, die IT-zentrierte Frameworks nur oberflächlich behandeln: passives Netzwerk-Monitoring ohne Beeinträchtigung der Produktionsprozesse, Schwachstellenmanagement für jahrzehntealte PLCs, die nicht gepatched werden können, Lieferkettensicherheit für proprietäre Engineering-Umgebungen und Fristen für die Vorfallsmeldung, die mit den Sperrverfahren von Sicherheitssystemen kollidieren können.
Die Normenreihe IEC 62443 – das international anerkannte Rahmenwerk für die Sicherheit von industriellen Automatisierungs- und Steuerungssystemen (IACS) – bietet einen strukturierten, OT-nativen Pfad zur NIS2-Compliance. Wo Artikel 21 Maßnahmen zum Cybersicherheits-Risikomanagement vorschreibt, definiert die IEC 62443, wie diese Maßnahmen in industriellen Umgebungen umgesetzt werden: von der Zuweisung von Sicherheitsstufen (Security Levels) und der Zone-and-Conduit-Netzwerkarchitektur bis hin zu Richtlinien für den sicheren Fernzugriff und Sicherheitsanforderungen für Lieferanten.
Wesentliche Erkenntnis: Das Shieldworkz-Lagebild zur OT-Bedrohungslage für das 1. Halbjahr 2026 dokumentiert einen Anstieg der OT-Vorfälle um 77 % im Jahresvergleich, wobei 33 % der Angriffe direkte physische Störungen verursachten. NIS2-Compliance ist keine reine Formalität zur Pflichterfüllung. Dies ist der regulatorische Ausdruck einer realen und eskalierenden Bedrohungslage. |
Dieser Leitfaden bietet OT-Sicherheitsverantwortlichen einen maßgeblichen, praxisnahen Fahrplan: eine detaillierte Zuordnung von NIS2-Anforderungen zur IEC 62443, ein phasenbasiertes Implementierungsprogramm, sektorspezifische Beispiele, eine Checkliste für die Audit-Bereitschaft sowie strategische Empfehlungen für den Aufbau einer langfristigen OT-Cybersecurity-Governance. Er richtet sich an diejenigen, die unter dem neuen Regulierungsregime rechtlich und operativ für die Absicherung industrieller Umgebungen verantwortlich sind.
2. NIS2 aus der OT-Perspektive verstehen
2.1 Hauptziele von NIS2
Die NIS2-Richtlinie (Richtlinie EU 2022/2555) hebt die grundlegenden Cybersicherheitsverpflichtungen von Einrichtungen, die kritische Infrastrukturen betreiben, durch die Verfolgung von vier Hauptzielen an:
• Harmonisierung: Etablierung eines einheitlichen Mindestsicherheitsniveaus in allen EU-Mitgliedstaaten, wodurch die fragmentierten nationalen Umsetzungen, die NIS1 geschwächt haben, beseitigt werden.
• Erweiterung des Anwendungsbereichs: Ausweitung der Regulierung auf zusätzliche Sektoren (u. a. verarbeitendes Gewerbe/Herstellung, Weltraum, Postdienste, Lebensmittelsektor) und Auferlegung von Verpflichtungen für wichtige Einrichtungen (Important Entities) sowie wesentliche Einrichtungen (Essential Entities).
• Verantwortung der Leitungsorgane: Persönliche Haftung des Top-Managements – einschließlich der Geschäftsführung und des Vorstands – für Versäumnisse im Bereich der Cybersicherheit.
• Verhältnismäßigkeit: Forderung risikobasierter Sicherheitsmaßnahmen, die der Größe, der Kritikalität und der Bedrohungsexposition der jeweiligen Einrichtung angemessen sind.
Artikel 21 bildet den operativen Kern: Er schreibt vor, dass betroffene Einrichtungen Maßnahmen zum Cybersicherheits-Risikomanagement in zehn Bereichen umsetzen müssen, darunter Risikoanalyse, Bewältigung von Sicherheitsvorfällen, Sicherheit der Lieferkette, Zugriffskontrolle, Kryptografie und Aufrechterhaltung des Betriebs (Business Continuity). Dies sind genau die Bereiche, die in OT-Umgebungen die größten Herausforderungen darstellen.
2.2 Wesentliche und wichtige Einrichtungen im OT-Kontext
Einrichtungskategorie | Betroffene OT-Sektoren | Wesentliche Unterschiede bei den Pflichten |
Wesentliche Einrichtung (Essential Entity) | Energie (Elektrizität, Erdöl, Gas, Fernwärme) Trinkwasser & Abwasser Transport (Luftverkehr, Schienenverkehr, Straßenverkehr, Schifffahrt) Digitale Infrastruktur Gesundheitswesen Weltraum | Proaktive Aufsicht durch die zuständige Behörde 72-Stunden-Frist für die Meldung von Vorfällen Haftung des Top-Managements Regelmäßige Sicherheitsaudits erforderlich |
Wichtige Einrichtung (Important Entity) | Herstellung/Produktion (Medizinprodukte, Pharma, Chemie) Lebensmittelproduktion & -vertrieb Post- & Kurierdienste Digitale Diensteanbieter Abfallwirtschaft | Reaktive Aufsicht (Ex-post, nach einem Vorfall) Gleiche 72-Stunden-Meldepflicht Gleiche Pflichten zum Risikomanagement Audits werden durch Vorfälle ausgelöst |
2.3 OT-spezifische Compliance-Herausforderungen
Die Anwendung der NIS2-Anforderungen auf OT-Umgebungen bringt Herausforderungen mit sich, denen IT-Sicherheitskräfte selten begegnen:
• Primat der Verfügbarkeit: OT-Systeme priorisieren die Betriebszeit über alles andere. Patch-Zyklen, die in Monaten oder Jahren statt in Tagen gemessen werden, sind üblich. Sicherheitssysteme (Safety Instrumented Systems – SIS) werden oft bewusst von allen Wartungsschnittstellen isoliert.
• Legacy-Technologie: Ein Großteil der kritischen Infrastruktur läuft auf Embedded-Systemen, proprietären Protokollen (Modbus, DNP3, IEC 60870-5-104, OPC-UA) und Hardware mit starrer Firmware – oft ohne Authentifizierungs- oder Verschlüsselungsfunktionen.
• Konflikte zwischen Safety und Security: Sicherheitsmaßnahmen wie agentenbasiertes Endpoint-Monitoring oder Netzwerkzugriffskontrolle können Latenzen oder Fehlermodi einführen, die in sicherheitskritischen Umgebungen untragbar sind.
• Intransparenz der Lieferkette: Engineering-Workstations, SCADA-Plattformen und industrielle Netzwerkkomponenten durchlaufen komplexe, mehrstufige Lieferketten, in die Betreiber selten vollen Einblick haben.
• Fachkräftemangel: In den meisten OT-Umgebungen fehlt es an dediziertem Cybersicherheitspersonal. Die Verantwortung wird häufig zwischen IT-Sicherheitsteams (denen die Kenntnis industrieller Protokolle fehlt) und OT-Ingenieuren (denen die Erfahrung mit Bedrohungsmodellierung fehlt) aufgeteilt.
2.4 Häufige Compliance-Fallstricke
Unternehmen, die eine NIS2-Compliance in OT-Umgebungen anstreben, begehen häufig folgende Fehler:
Direkte Übertragung von IT-Sicherheits-Frameworks: Der Einsatz von Endpoint-Detection-Agenten auf PLCs, das Ausführen aktiver Schwachstellenscanner in Prozessnetzwerken oder das Aufzwingen von IT-Patch-Fristen für OT-Systeme kann zu Anlagenstillständen und sicherheitskritischen Vorfällen führen.
2. Behandlung von Compliance als einmaliges Projekt: NIS2 erfordert kontinuierliches Risikomanagement, keine jährlichen punktuellen Bewertungen. Die zuständigen Behörden erwarten zunehmend den Nachweis eines gelebten Sicherheitsbetriebs.
3. Unterschätzung der Lieferkettentiefe: NIS2 Artikel 21 Abs. 2 lit. d fordert von Einrichtungen explizit die Berücksichtigung der Sicherheit der Lieferkette. Dies umfasst den Fernzugriff von Originalgeräteherstellern (OEM), die Herkunft der Firmware sowie Drittintegratoren.
Vernachlässigung von Übungen zur Vorfallsmeldung: Das Zeitfenster von 72 Stunden für die Meldung erheblicher Vorfälle ist extrem eng. Vielen Organisationen fehlt die Erkennungsfähigkeit sowie die internen Eskalationsprozesse, um diese Frist einzuhalten.
3. Warum die IEC 62443 das bevorzugte Framework für OT-Sicherheit ist
3.1 Überblick über die IEC 62443
Die IEC 62443 ist eine mehrteilige internationale Normenreihe, die gemeinsam vom IEC Technical Committee 65 und der ISA (International Society of Automation) herausgegeben wird. Sie befasst sich mit der Cybersicherheit industrieller Automatisierungs- und Steuerungssysteme über den gesamten Lebenszyklus hinweg – von Entwurf und Beschaffung über den Betrieb bis hin zur Außerbetriebnahme – und teilt die Verantwortlichkeiten auf drei Rollen auf: Betreiber (Asset Owner), Systemintegrator und Produkthersteller.
Standard | Bereich | Relevanz für NIS2 |
IEC 62443-1-1 | Terminologie, Konzepte und Modelle | Etabliert das IACS-Sicherheitsvokabular und das allen Kontrollen zugrunde liegende Zones- &-Conduits-Modell |
IEC 62443-2-1 | Sicherheitsmanagementsystem für IACS (CSMS) | Lässt sich direkt auf die NIS2-Governance, das Risikomanagement und die Richtlinienanforderungen übertragen |
IEC 62443-2-2 | Leitfaden für die CSMS-Implementierung | Operative Verfahren zur Durchführung eines IACS-Sicherheitsprogramms |
IEC 62443-2-3 | Patch-Management in der IACS-Umgebung | Adressiert die NIS2-Pflichten zum Patch- und Schwachstellenmanagement für Legacy-OT |
IEC 62443-2-4 | Sicherheitsanforderungen für IACS-Dienstleister | Lieferketten- und Drittanbieterrisiken (NIS2 Artikel 21 Abs. 2 lit. d) |
IEC 62443-3-2 | Sicherheitsrisikoanalyse für das Systemdesign | Risikobasierte Zuweisung von Sicherheitsstufen – das Fundament der NIS2-Risikoanalyse |
IEC 62443-3-3 | System-Sicherheitsanforderungen und Sicherheitsstufen | Technische Sicherheitskontrollen für das IACS-System (SL-T 1–4) |
IEC 62443-4-1 | Sicherer Produktlebenszyklus (SDLC) | Sichere Entwicklung und Nachweis der Herkunft in der Lieferkette |
IEC 62443-4-2 | Technische Sicherheitsanforderungen an Komponenten | Kontrollen auf Komponentenebene für PLCs, HMIs, Historians und Engineering-Workstations |
3.2 Vorteile der Einführung der IEC 62443 für NIS2
• OT-natives Design: Die IEC 62443 wurde speziell für industrielle Umgebungen entwickelt. Ihr Sicherheitsstufenmodell (Security Level – SL 1 bis SL 4) berücksichtigt die Verfügbarkeitsbeschränkungen und Legacy-Technologien der OT, ohne von patchbaren, internetgebundenen IT-Endpunkten auszugehen.
• Strukturierte Risikomethodik: Das Zone-and-Conduit-Modell (IEC 62443-3-2) bietet eine dokumentierte, auditierbare Basis für die Risikoanalyseanforderungen der NIS2, die von Regulierungsbehörden und Auditoren überprüft werden kann.
• Abdeckung der Lieferkette: Die Teile IEC 62443-2-4 und 4-1 behandeln direkt die Sicherheitsanforderungen für Lieferanten – eine NIS2-Pflicht, die in den meisten IT-Frameworks nur am Rande erwähnt wird.
• Regulatorische Anerkennung: Die Agentur der Europäischen Union für Cybersicherheit (ENISA) verweist explizit auf die IEC 62443 als geeignetes Rahmenwerk für die OT-Compliance. Mehrere zuständige Behörden der EU-Mitgliedstaaten haben Anforderungen der IEC 62443 in ihre sektorspezifischen NIS2-Leitlinien integriert.
• Zertifizierungspfad: Eine Zertifizierung nach IEC 62443 (insbesondere 2-1 und 4-2) liefert konkrete Audit-Nachweise, die gegenüber Regulierungsbehörden, Kunden und Versicherern vorgelegt werden können.
3.3 IEC 62443 vs. IT-zentrierte Frameworks im OT-Kontext
Dimension | IEC 62443 | NIST CSF / ISO 27001 (in der OT) |
Unterstützung von Altsystemen | Explizite Bestimmungen für Systeme, die nicht gepatched oder aktualisiert werden können (kompensierende Maßnahmen, SL-Zuweisung) | Geht von patchbaren Systemen aus; kompensierende Maßnahmen werden erwähnt, sind aber unzureichend spezifiziert |
Sicherheitsintegration (Safety) | Koordiniert IT-Sicherheitsmaßnahmen (Security) mit der funktionalen Sicherheit (Safety – IEC 61511) | Sicherheitsaspekte (Safety) fehlen oder sind oberflächlich |
Kenntnis industrieller Protokolle | Deckt Modbus, DNP3, OPC-UA und PROFINET nativ ab | Protokolle werden wie generischer TCP/IP-Traffic behandelt |
Modell für die Lieferkette | Drei-Rollen-Modell (Betreiber / Integrator / Hersteller) mit spezifischen Anforderungen für jede Rolle | Generisches Risikomanagement für Lieferanten |
OT-Verfügbarkeitsvorgaben | Das Security-Level-Modell berücksichtigt die Verfügbarkeit; Leitlinien zum Patch-Management sind OT-spezifisch | Standard-Patch-Management setzt planmäßige Ausfallzeiten voraus |
Regulatorische Akzeptanz | Explizit von der ENISA und den Behörden der EU-Mitgliedstaaten für NIS2 empfohlen | Als ergänzendes, nicht als primäres OT-Framework akzeptabel |
4. Detaillierte Zuordnung: NIS2 zu IEC 62443
Die folgende Tabelle ordnet die Anforderungen an das Cybersicherheits-Risikomanagement gemäß NIS2 Artikel 21 den relevantesten Standards der IEC 62443 zu, bietet Leitlinien zur Implementierung in der OT und spezifiziert die für Audits und behördliche Nachweise erforderlichen Artefakte.
NIS2 Art. 21 Bereich | Zusammenfassung der NIS2-Anforderung | IEC 62443-Standard(s) | Leitfaden zur OT-Implementierung | Audit-Nachweise |
Risikomanagement | Konzepte für die Risikoanalyse und für die Sicherheit der Informationssysteme | 62443-2-1 §4.2.2 62443-3-2 §5 | Führen Sie eine IACS-spezifische Risikoanalyse unter Verwendung des Zone-and-Conduit-Modells durch. Weisen Sie jeder Zone basierend auf Bedrohungsszenarien (Sabotage, Spionage, Betriebsunterbrechung) Sicherheitsstufen (SL-T) zu. Dokumentieren Sie ein Restrisikoregister. | Risikoanalysebericht Zone-and-Conduit-Diagramme Begründungsdokumentation für die Security Levels |
Governance und Haftung | Billigung durch die Geschäftsleitung; Verantwortungsstrukturen | 62443-2-1 §4.2.1 62443-2-1 §4.3.1 | Etablieren Sie ein IACS-Sicherheitsmanagementsystem (CSMS) mit dokumentiertem Geltungsbereich, Richtlinien und Freigabe durch die Geschäftsführung. Übertragen Sie die NIS2-Pflichten der Leitungsorgane auf eine OT-Verantwortlichkeitsmatrix. | CSMS-Richtliniendokument Nachweis der Freigabe durch die Geschäftsleitung Verantwortlichkeitsmatrix für OT-Sicherheitsrollen |
Inventarisierung von Assets | Identifizierung und Klassifizierung von Informations-Assets | 62443-2-1 §4.2.3.4 62443-3-2 §5.3.1 | Nutzen Sie passive OT-Asset-Discovery (Shieldworkz) – niemals aktive Scans in Prozessnetzwerken. Klassifizieren Sie Assets nach ihrer Kritikalität für die Prozesssicherheit (Safety) und Verfügbarkeit. Erfassen Sie Firmware-Versionen und End-of-Life-Status. | OT-Asset-Register (inkl. Firmware-Versionen) Ausgabeberichte der passiven Asset-Erkennung Bericht zu End-of-Life-Assets |
Netzwerksegmentierung | Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen | 62443-3-3 SR 5.1, 5.2 62443-3-2 §5.4 | Implementieren Sie eine Zones-and-Conduits-Architektur. Richten Sie eine IT/OT-DMZ ein. Setzen Sie Firewall-Regeln durch, die den zonenübergreifenden Datenverkehr auf die dokumentierte, erforderliche Kommunikation beschränken. Nutzen Sie das Purdue-Modell oder die ISA-95-Referenzarchitektur. | Netzwerkarchitekturpläne Dokumentation des Firewall-Regelwerks Definition von Zonen- und Conduit-Grenzen |
Zugriffskontrolle | Identitäts- und Zugriffsmanagement; MFA | 62443-3-3 SR 1.1–1.13 62443-4-2 §3.1 | Rollenbasierte Zugriffskontrolle (RBAC) auf HMIs, Engineering-Workstations und SCADA-Servern. MFA für jeglichen Fernzugriff. Privileged Access Management (PAM) für administrative Konten. Entfernen Sie standardmäßige und gemeinsam genutzte Anmeldedaten auf allen OT-Assets. | Dokumentation der IAM-Richtlinien Überprüfungen von Benutzerzugriffen Nachweis des MFA-Rollouts Audit-Logs des PAM-Tools |
Schwachstellenmanagement | Handhabung und Offenlegung von Schwachstellen | 62443-2-3 (vollständig) 62443-4-2 §3.2 | Etablieren Sie einen OT-spezifischen Prozess für das Schwachstellenmanagement. Abonnieren Sie ICS-CERT, Hersteller-Advisories und Threat Intelligence von Shieldworkz. Bewerten Sie Schwachstellen nach ihrer Ausnutzbarkeit im OT-Kontext – nicht allein nach dem CVSS-Score. Führen Sie ein Register kompensierender Maßnahmen für nicht patchbare Assets. | Schwachstellenregister Nachweis über ICS-CERT-Abonnements Dokumentation kompensierender Maßnahmen Risikoanalysen zu anstehenden Patches |
Patch-Management | System-Updates und Patch-Einspielung | 62443-2-3 §6.2–6.4 | Implementieren Sie ein OT-kompatibles Patching: Testen Sie Patches zuerst in einer replizierten Test- oder Staging-Umgebung; koordinieren Sie die Einspielung mit der Produktion für freigegebene Wartungsfenster; halten Sie Rollback-Verfahren bereit. Für SIS und sicherheitskritische Systeme dürfen nur vom Hersteller validierte Patches verwendet werden. | Richtlinie zum Patch-Management Nachweis über eine Staging-/Laborumgebung Protokolle zur Patch-Einspielung Validierungsnachweise der SIS-Hersteller |
Sicherer Fernzugriff | Zugriffsrichtlinien; Nutzung sicherer Kommunikation | 62443-3-3 SR 1.13 62443-2-4 SP.03.01 | Sämtlicher Fernzugriff von Herstellern oder Dritten muss über einen Jump-Server in der DMZ mit Sitzungsaufzeichnung erfolgen. Zugriff nur zeitlich begrenzt und auf Anfrage. MFA ist zwingend erforderlich. Keine dauerhaften Fernzugriffsverbindungen in die OT-Zone. Alle Sitzungen müssen auditiert werden. | Architekturdiagramm des Fernzugriffs Protokolle der Sitzungsaufzeichnungen Aufzeichnungen des Prozesses für Zugriffsanfragen und Freigaben |
Sicherheit der Lieferkette | Sicherheit bei der Beschaffung von Netzwerk- und Informationssystemen | 62443-2-4 (vollständig) 62443-4-1 §5 | Fordern Sie die Konformität nach IEC 62443-2-4 von allen IACS-Dienstleistern ein. Integrieren Sie Sicherheitsanforderungen in Beschaffungsverträge. Bewerten Sie die SDLC-Praktiken der Hersteller (IEC 62443-4-1). Überprüfen Sie Herkunftsnachweise der Firmware und Software-Stücklisten (SBOM). | Ergebnisse von Sicherheitsfragebögen für Lieferanten Sicherheitsklauseln in Verträgen SBOM-Dokumentation Auditberichte der Hersteller |
Drittanbieterrisiko | Risikomanagementmaßnahmen für die Lieferkette | 62443-2-4 SP.02 62443-2-1 §4.2.6 | Führen Sie ein Register der OT-Lieferanten. Führen Sie jährliche Sicherheitsbewertungen von Drittanbietern durch. Definieren und erzwingen Sie Mindestsicherheitsanforderungen für Systemintegratoren, die auf OT-Umgebungen zugreifen. Nehmen Sie Audit-Rechte in Verträge auf. | Risikoregister für Drittanbieter Bewertungsberichte Vertragsklauseln Zugriffsprotokolle für Drittanbieter |
Überwachung und Erkennung | Konzepte und Verfahren für die Sicherheitsüberwachung | 62443-3-3 SR 6.1, 6.2 62443-2-1 §4.4 | Setzen Sie passives OT NDR (Network Detection & Response) – z. B. von Shieldworkz – zur Asset-Sichtbarkeit und Anomalieerkennung ein. Überwachen Sie Modbus-Funktionscodes, zonenübergreifenden Verkehr und Aktivitäten auf Engineering-Workstations. Integrieren Sie diese in ein OT SOC oder einen MSSP. | Nachweis der Implementierung des NDR-Tools Dokumentation der Erkennungsregeln Protokolle der Alarmüberprüfungen Dienstleistungsvereinbarung mit dem SOC (SLA) |
Reaktion auf Vorfälle | Bewältigung von Sicherheitsvorfällen; Meldepflichten | 62443-2-1 §4.3.6 62443-3-3 SR 6.1 | Entwickeln Sie einen OT-spezifischen Notfallplan (Incident Response Plan). Definieren Sie Eskalationspfade von der lokalen OT zum CSIRT. Trainieren Sie den Prozess für die 72-Stunden-Meldung. Integrieren Sie OT-sichere Schadensminderungsmaßnahmen (Prozessisolierung ohne Beeinträchtigung der Safety). Führen Sie jährliche Tabletop-Übungen durch. | OT-Incident-Response-Plan Dokumentation von Tabletop-Übungen Meldeverfahren für das nationale CSIRT Runbooks zur Schadensbegrenzung |
Aufrechterhaltung des Betriebs | Aufrechterhaltung des Betriebs und Krisenmanagement | 62443-2-1 §4.3.5 62443-3-3 SR 7.1 | Dokumentieren Sie Betriebsfortführungspläne (BCP) für die OT, einschließlich Rückfalloptionen auf manuellen Betrieb bei Ausfall der Prozesssteuerung. Definieren Sie Wiederherstellungszeiten (RTO) für OT-Systeme. Testen Sie diese Verfahren jährlich. | OT-BCP-Dokumentation RTO/RPO-Definitionen Verfahrensweisungen für den manuellen Betrieb Nachweise der BCP-Tests |
Wiederherstellung im Katastrophenfall | Backup, Wiederherstellung und Krisenmanagement | 62443-3-3 SR 7.3, 7.4 62443-2-3 | Erstellen Sie Offline-Backups von OT-Konfigurationen (PLC-Logik, HMI-Visualisierungen, Historian-Daten, Projektdateien der Engineering-Software). Testen Sie die Wiederherstellung mindestens einmal jährlich in einer subsystemnahen Testumgebung außerhalb der Produktion. Dokumentieren Sie Wiederherstellungs-Playbooks. | Backup-Richtlinie und Zeitplan Inventar der Offline-Backups Protokolle der Wiederherstellungstests Playbooks zur Wiederherstellung |
Sicherheitstests | Überprüfung und Bewertung von Sicherheitsmaßnahmen | 62443-3-2 §5.7 62443-2-1 §4.4 | Führen Sie OT-spezifische Penetrationstests durch (passive Aufklärung, Tests der IT/OT-Grenzen – vermeiden Sie aktive Tests in produktiven Prozessnetzwerken). Führen Sie jährliche Schwachstellenanalysen durch. Setzen Sie ausschließlich Prüfer mit nachgewiesener OT-Erfahrung ein. | Umfangs- und Methodikbeschreibung der Penetrationstests Berichte der Penetrationstests Nachweis der Nachverfolgung von Behebungsmaßnahmen |
Sicherheitsbewusstsein | Grundlegende Cyberhygiene und Schulung des Personals | 62443-2-1 §4.3.2 62443-2-4 SP.01 | Bieten Sie OT-spezifische Security-Awareness-Schulungen für alle Mitarbeiter mit OT-Zugriff an. Die Inhalte sollten Phishing-Prävention, Richtlinien für Wechselmedien, sicheren Fernzugriff und die physische Sicherheit von OT-Assets abdecken. | Schulungsnachweise der Mitarbeiter OT-spezifische Schulungsunterlagen Dokumentation von Sensibilisierungskampagnen |
Protokollierung & Überwachung | Audit-Protokollierung, Ereignisüberwachung | 62443-3-3 SR 6.1–6.3 62443-4-2 §3.6 | Aktivieren Sie die Protokollierung auf allen OT-Assets, die dies unterstützen. Zentralisieren Sie OT-Syslog- und Ereignisdaten in einem SIEM oder einem OT-spezifischen Log-Aggregator (wenn möglich getrennt vom IT-SIEM). Bewahren Sie Protokolle entsprechend den NIS2-Erwartungen für mindestens 12 Monate auf. | Richtlinie zur Aufbewahrung von Protokollen Konfiguration des SIEM/Log-Aggregators Integritätskontrollen für Logfiles Nachweis des gesicherten Log-Zugriffs |
Kryptografie | Einsatz von Kryptografie und Verschlüsselung | 62443-3-3 SR 4.3 62443-4-2 §3.4 | Verschlüsseln Sie Fernzugriffskanäle (TLS 1.2/1.3, SSH). Verschlüsseln Sie OT-Daten bei der Übertragung, sofern die industriellen Protokolle dies unterstützen. Hinweis: Viele Legacy-Feldprotokolle (Modbus, DNP3) unterstützen keine native Verschlüsselung – kompensieren Sie dies durch verschlüsselte Tunnel ab der DMZ. | Richtlinie zum Einsatz von Kryptografie Konfigurationsnachweise von TLS/SSH Konfiguration von VPN/verschlüsselten Tunneln Risikoakzeptanzbelege für unverschlüsselte Legacy-Protokolle |
5. OT-spezifischer NIS2-/IEC-62443-Implementierungsfahrplan
Der folgende phasenbasierte Fahrplan bietet ein praktisches Vorgehen für Industrieunternehmen, die ihre NIS2-Compliance über die IEC 62443 realisieren möchten. Jede Phase ist so sequenziert, dass operative Störungen minimiert und der Reifegrad der Cybersicherheit sukzessive erhöht wird.
Phase 1: Bestandsaufnahme und Gap-Analyse (Monat 1–3)
Element | Details |
Ziele | Ermittlung des aktuellen IACS-Sicherheitsniveaus. Quantifizierung der Abweichungen zu NIS2 und IEC 62443. Priorisierung der Behebungsmaßnahmen. |
Wesentliche Aktivitäten | • Initiierung einer passiven OT-Asset-Erkennung in allen Prozessnetzwerken • Durchführung einer Gap-Analyse zum CSMS nach IEC 62443-2-1 im Vergleich zu aktuellen Governance-Praktiken • Zuordnung der OT-Netzwerkarchitektur zum Zone-and-Conduit-Modell; Dokumentation von Ist- versus Soll-Zustand • Interviews mit OT-Betriebsleitern, Engineering- und IT-Sicherheitsteams • Überprüfung bestehender Incident-Response-Prozesse auf ihre Anwendbarkeit in der OT • Bewertung der aktuellen Fernzugriffsregelungen für Lieferanten und Dritte |
Ergebnisse / Artefakte | • OT-Asset-Register (Entwurf) • Bericht zur NIS2-/IEC-62443-Gap-Analyse inklusive Heatmap • Zone-and-Conduit-Diagramm (Ist-Zustand) • Risikoregister (Erstversion) |
Einzubeziehende Akteure | OT-Sicherheitsverantwortliche, Betriebsleiter/Werksleiter, CISO, IT-Sicherheit, Engineering, Einkauf |
Erfolgsmessung | 100 % der Prozessnetzwerksegmente erfasst; Gap-Analyse-Bericht durch CISO freigegeben; erstes Risikoregister erstellt |
Phase 2: Risikopriorisierung und Zuweisung von Sicherheitsstufen (Monat 2–4)
Element | Details |
Ziele | Zuweisung von Sicherheits-Soll-Stufen (Security Level Target – SL-T) für alle OT-Zonen. Priorisierung von Kontrollen basierend auf Risikoauswirkung und Ausnutzbarkeit. |
Wesentliche Aktivitäten | • Durchführung einer Risikoanalyse nach IEC 62443-3-2 für jede Zone: Identifizierung von Bedrohungsszenarien, Schadensausmaß und Eintrittswahrscheinlichkeit • Zuweisung der Soll-Stufen SL-T 1–4 für jede Zone (Priorität: SL-T 3 für Sicherheitssysteme, SL-T 2 für die Prozesssteuerung) • Abgleich von Shieldworkz-Lagebildern (z. B. VOLTZITE, BAUXITE, FrostyGoop, DynoWiper) mit standortspezifischen Risikoszenarien • Festlegung kompensierender Maßnahmen für Altsysteme, die das angestrebte SL-T nicht direkt erreichen können • Erstellung eines Risikobehandlungsplans mit Zuständigkeiten und Fristen |
Ergebnisse / Artefakte | • Risikoanalysebericht nach IEC 62443-3-2 • Matrix zur Sicherheitsstufen-Zuweisung der Zonen • Risikobehandlungsplan mit priorisiertem Maßnahmenkatalog |
Einzubeziehende Akteure | OT-Sicherheitsverantwortliche, Sicherheitsingenieure (Safety), CISO, Werkleitung, Engineering |
Erfolgsmessung | Allen Zonen ist ein SL-T zugewiesen; Risikobehandlungsplan ist durch den CISO und die Geschäftsführung freigegeben |
Phase 3: Implementierung von Basiskontrollen (Monat 3–12)
Element | Details |
Ziele | Umsetzung hochprioritärer IEC-62443-Kontrollen, welche die kritischsten Anforderungen der NIS2 abdecken. |
Wesentliche Aktivitäten | • Aufbau einer IT/OT-DMZ und Durchsetzung von Firewall-Regeln (IEC 62443-3-3 SR 5.1/5.2) • Bereitstellung eines sicheren Fernzugriffs über Jump-Server mit Sitzungsaufzeichnung • Einführung einer passiven OT-NDR-Lösung zur Asset-Sichtbarkeit und Anomalieerkennung • Etablierung von Prozessen und Werkzeugen zur kontinuierlichen OT-Asset-Inventarisierung • Identifizierung und Deaktivierung über das Internet erreichbarer OT-Assets sowie Entfernung von Standard-Logins • Einführung eines OT-spezifischen Patch-Management-Prozesses mit Testumgebung • Erstellung des OT-Incident-Response-Plans und Durchführung der ersten Trockenübung (Tabletop) • Implementierung von Offline-Backups für alle OT-Systemkonfigurationen |
Ergebnisse / Artefakte | • IT/OT-DMZ-Architektur (produktiv umgesetzt) • NDR-Einführung und erste Optimierung der Alarmierungsregeln • Betrieb der Plattform für sicheren Fernzugriff • OT-Incident-Response-Plan • Bericht zur ersten Tabletop-Übung • Verzeichnis der OT-Backup-Konfigurationen |
Einzubeziehende Akteure | OT-Sicherheitsverantwortliche, Netzwerkingenieure, Betriebsleiter, IT-Sicherheit, Einkauf |
Erfolgsmessung | Keine direkt über das Internet erreichbaren OT-Systeme; NDR im Betrieb; sicherer Fernzugriff erzwungen; Notfallplan getestet |
Phase 4: Erweiterte Erkennung, Reaktion und Lieferkettensicherheit (Monat 9–18)
Element | Details |
Ziele | Weiterentwicklung der Erkennungs- und Reaktionsfähigkeiten. Ausweitung der Sicherheitskontrollen auf die Lieferkette (Supply Chain). |
Wesentliche Aktivitäten | • Integration des OT NDR in das SIEM und ein OT SOC oder einen Managed Security Service Provider (MSSP) • Erstellung von Playbooks für die Bedrohungssuche in der OT (Threat Hunting) auf Basis von Shieldworkz-Erkenntnissen (z. B. Überwachung auf Living-off-the-Land (LOTL)-Aktivitäten oder Modbus FC6/16) • Integration der Anforderungen nach IEC 62443-2-4 für alle IACS-Dienstleister; Anpassung von Verträgen • Durchführung eines OT-spezifischen Penetrationstests (Fokus auf IT/OT-Übergänge) • Etablierung des SBOM-Trackings für kritische OT-Komponenten • Einführung einer Risiko-Klassifizierung für Zulieferer und eines jährlichen Audit-Programms • Durchführung eines kontinuierlichen OT-Sicherheits-Sensibilisierungsprogramms für das Personal |
Ergebnisse / Artefakte | • Dokumentation der OT-SOC-Integration • Bibliothek der Playbooks für das OT Threat Hunting • Aktualisierte Lieferantenverträge mit IEC-62443-2-4-Klauseln • Bericht des Penetrationstests und Nachverfolgung der Mängelbehebung • SBOM-Verzeichnis (für kritische Vermögenswerte) • Klassifiziertes Risikoregister der Lieferanten |
Einzubeziehende Akteure | CISO, OT-Sicherheitsverantwortliche, Einkauf, Rechtsabteilung, SOC/MSSP, Partnermanagement |
Erfolgsmessung | 100 % der strategischen Zulieferer (Tier-1) bewertet; OT-Penetrationstest abgeschlossen und Maßnahmen nachverfolgt; SOC-Anbindung vollständig |
Phase 5: Governance, Kennzahlen und kontinuierliche Verbesserung (kontinuierlich ab Monat 12)
Element | Details |
Ziele | Verankerung der NIS2-/IEC-62443-Compliance in der laufenden Unternehmensorganisation. Nachweis der kontinuierlichen Verbesserung gegenüber Aufsichtsbehörden. |
Wesentliche Aktivitäten | • Einrichtung von OT-Sicherheits-KPIs und vierteljährliche Berichterstattung an die Geschäftsleitung • Implementierung einer kontinuierlichen Schwachstellenüberwachung unter Nutzung von Shieldworkz Threat Intelligence Feeds • Jährliche Überprüfung des CSMS nach IEC 62443-2-1 sowie Vorbereitung auf eine Re-Zertifizierung • Integration des NIS2-Compliance-Status in das übergeordnete Unternehmensrisikomanagement • Jährliche Durchführung von Notfall- und Wiederherstellungstests (BCP/DR) in der OT; Aktualisierung der Playbooks • Briefing der Leitungsorgane bezüglich ihrer persönlichen Haftungsverpflichtungen gemäß NIS2 • Etablierung eines Prozesses zur Überwachung von NIS2-Durchführungsrechtsakten und nationalen Spezifikationen (z. B. BSIG, KRITIS-Verordnungen) |
Ergebnisse / Artefakte | • Dashboard für OT-Sicherheits-KPIs • Jährlicher Cybersicherheitsbericht für den Vorstand/die Geschäftsführung • Jährlicher Auditbericht zum CSMS • Aktualisierte Protokolle der BCP-/DR-Tests • Briefing-Unterlagen für die Geschäftsleitung |
Einzubeziehende Akteure | CISO, Vorstand/Geschäftsführung/Prüfungsausschuss, OT-Sicherheitsverantwortliche, Compliance, Rechtsabteilung, Betrieb |
Erfolgsmessung | Vorstand erhält vierteljährlichen OT-Sicherheitsbericht; CSMS wird jährlich überprüft; keine überfälligen kritischen Korrekturmaßnahmen |
6. NIS2-Audit-Bereitschaft für OT-Umgebungen
6.1 Anforderungen an die Dokumentation
Zuständige Aufsichtsbehörden und deren Auditoren erwarten einen lückenlosen Dokumentationspfad, der nachweist, dass das Unternehmen angemessene und verhältnismäßige Sicherheitsmaßnahmen im Sinne des Risikomanagements implementiert hat und kontinuierlich lebt. Für OT-Umgebungen muss diese Dokumentation weit über Standard-IT-Richtlinien hinausgehen und industriespezifische Aspekte abdecken.
• Dokumentation von Richtlinien, Geltungsbereich und Verfahren des IACS-Sicherheitsmanagementsystems (CSMS) gemäß IEC 62443-2-1
• Dokumentation der OT-Netzwerkarchitektur: Zone-and-Conduit-Diagramme, Begründung von Firewall-Regeln, Konzept der IT/OT-DMZ
• OT-Asset-Register: Liste aller IACS-Komponenten, Firmware-Versionen, End-of-Life-Daten und zugeordneten Sicherheitsstufen (SL)
• Risikoanalyseberichte: Methodik nach IEC 62443-3-2, dokumentierte Bedrohungsszenarien, SL-T-Zuweisungen und Entscheidungen zum Umgang mit Restrisiken
• Sicherheitsdokumentation für Partner und Lieferanten: Verträge, Assessments, Freigabe- und Zugriffsprotokolle, Nachweise zur Konformität nach IEC 62443-2-4
• Incident-Response-Pläne für die OT sowie Protokolle der durchgeführten Tabletop-Übungen
• Betriebsfortführungs- und Wiederherstellungskonzepte (BCP/DR) inklusive dokumentierter Testnachweise
• Schulungsnachweise der Mitarbeiter und Unterlagen zum Sensibilisierungsprogramm
6.2 Technische Nachweisdokumente
• Nachweise über den Betrieb von NDR/IDS: Werkzeugkonfiguration, Netzabdeckungsplan, Protokolle zur Regeloptimierung
• Identitäts- und Zugriffsnachweise: IAM-Richtlinien, MFA-Konfiguration, Berichte über privilegierte Konten, Bereinigungsprotokolle für Standard-Logins
• Patch-Management-Protokolle: Patch-Verzeichnis, OT-spezifische Risikobewertung für jeden Patch, Protokolle der Wartungsfenster, Register kompensierender Maßnahmen
• Nachweis der Protokollaufbewahrung: SIEM-/Log-Aggregator-Konfigurationen, welche die Einspielung und die Aufbewahrungsdauer von OT-Ereignisdaten belegen
• Penetrationstestberichte und System zur Mängelverfolgung
6.3 Bereitschaft für die Vorfallsmeldung
NIS2 Artikel 23 verpflichtet Einrichtungen, innerhalb von 24 Stunden nach Kenntnisnahme eines erheblichen Sicherheitsvorfalls eine Frühwarnung an das nationale CSIRT (in Deutschland z. B. das BSI) zu übermitteln, gefolgt von einer detaillierten Meldung innerhalb von 72 Stunden und einem Abschlussbericht nach einem Monat. In OT-Umgebungen erfordert diese Frist eine gezielte Vorbereitung:
• Konkrete Definition eines „erheblichen Sicherheitsvorfalls“ im OT-Kontext: z. B. Beeinträchtigung der Prozessverfügbarkeit, begründeter Verdacht auf Living-off-the-Land (LOTL)-Aktivitäten, Fehlverhalten von Sicherheitssteuerungen (SIS) oder Ransomware-Befall in OT-nahen Segmenten
• Etablierung eines dokumentierten Eskalationspfades vom OT-Standort über den CISO bis hin zur Meldung an die zuständige Behörde innerhalb des 24-stündigen Zeitfensters
• Registrierung des Unternehmens bei der zuständigen nationalen Meldestelle (z. B. BSI-Meldeportal) und Einrichtung sicherer Kommunikationskanäle
• Erstellung vorbereiteter Meldevorlagen, um die Reaktionszeit unter Krisenbedingungen zu minimieren
• Durchführung mindestens einer jährlichen Simulationsübung für das 72-Stunden-Szenario
6.4 Verantwortung des Top-Managements
NIS2 Artikel 20 nimmt die Leitungsorgane von Einrichtungen persönlich für Versäumnisse bei der Umsetzung von Sicherheitsmaßnahmen in die Pflicht. Für OT-geprägte Organisationen bedeutet dies, dass Vorstände und Geschäftsführer Folgendes nachweisen können müssen:
• Nachweis einer aktiven Überwachung von Cybersicherheitsrisiken: z. B. Protokolle von Aufsichtsrats- oder Geschäftsführungssitzungen, in denen OT-Sicherheitsberichte diskutiert wurden, eine definierte Risikobereitschaft für den OT-Betrieb und eine dokumentierte Berichtslinie des CISO
• Offizielle Freigabe des Geltungsbereichs und der Richtlinien des CSMS durch die Unternehmensleitung
• Formelle Dokumentation, dass die Geschäftsführung über die persönlichen Haftungsrisiken unter NIS2 aufgeklärt wurde (z. B. durch juristische Stellungnahmen)
• Regelmäßige Vorlagen an die Geschäftsführung bezüglich der OT-Sicherheitslage, aufgetretener Vorfälle und des NIS2-Compliance-Status
7. Praktische OT-Sicherheitskontrollen entsprechend der IEC 62443
7.1 Asset-Erkennung in Industrieumgebungen
Nutzen Sie ausschließlich passive OT-Asset-Discovery-Tools (Shieldworkz), die den Netzwerkverkehr analysieren, ohne aktive Abfragepakete in das Netz einzubringen. Aktive Scanner können SPS-Fehlerzustände und Notabschaltungen auslösen. Verknüpfen Sie die Daten der automatischen Erkennung mit der Configuration Management Database (CMDB), um ein dynamisches Asset-Register zu pflegen. Planen Sie einen vierteljährlichen Abgleich zwischen erkannten Systemen und der dokumentierten Bestandsliste.
7.2 OT-Netzwerküberwachung und NDR
Implementieren Sie passive Network Detection and Response (NDR) an SPAN-Ports oder Netzwerk-TAPs industrieller Switches. Erstellen Sie während des Normalbetriebs Verhaltensprofile (Baselines) für jede Zone. Zu den Regeln mit hoher Alarmierungspriorität sollten gehören:
• Modbus-Funktionscodes 6 (Write Single Register) und 16 (Write Multiple Registers) von nicht autorisierten Quellbefehrshabern – Indikatoren für Manipulationen im Stil von FrostyGoop
• Externe Verbindungen zu Standard-OT-Ports (502, 102, 20000, 44818, 4840) – potenzielle Aktivitäten im Stil von PIPEDREAM/INCONTROLLER
• Erscheinen neuer Geräte in Prozessnetzwerken – Hinweis auf unbefugten physischen Zugriff oder Vortests für LOTL-Angriffe
• Verbindungen von Engineering-Workstations ins Internet oder in IT-Netzwerke – Indikatoren für Datenabfluss (TTPs von AZURITE/Flax Typhoon)
7.3 Sicherer Fernzugriff für Partner und Hersteller
Der Fernzugriff von Wartungspartnern, Systemintegratoren und OEMs ist einer der häufigsten Angriffsvektoren in der OT. Implementieren Sie eine gesicherte Fernzugriffsplattform (VRAP) mit folgenden Mindestanforderungen:
• Zentraler Jump-Server in der IT/OT-DMZ – IT-Sicherheitsrichtlinien müssen direkte Verbindungen in das Prozessnetzwerk strikt untersagen
• Multi-Faktor-Authentifizierung (MFA) für alle externen Verbindungssitzungen
• Vollständige Aufzeichnung der Fernwartungssitzungen (Video und Tastaturanschläge)
• Zeitlich begrenzte Zugriffsfreigaben nach dem Vier-Augen-Prinzip – keine dauerhaft offenen VPN-Tunnel
7.4 Industrielles Schwachstellenmanagement
Schwachstellenmanagement in der OT unterscheidet sich fundamental von IT-Praktiken. Die folgenden Praxisbeispiele verdeutlichen das notwendige Vorgehen:
Beispiel Fertigungsindustrie: Ein Automobilzulieferer betreibt 15 Jahre alte Siemens S7-300 Steuerungen, für die keine Sicherheits-Patches existieren. Kompensierende Maßnahmen – wie strikte Netzwerksegmentierung, Applikations-Allowlisting auf den zugehörigen Engineering-Workstations und die passive Überwachung auf unübliche Modbus-Sitzungen – ersetzen das Patching als Risikominderungsmaßnahme. |
Beispiel Energiesektor: Ein Verteilnetzbetreiber verwaltet Schutzgeräte-Firmware an 40 Umspannwerken. Firmware-Updates erfordern koordinierte Abschaltfenster mit dem Übertragungsnetzbetreiber. Der Schwachstellenprozess sieht ein 6-monatiges Patch-Fenster, herstellerseitige Validierungsprüfungen sowie eine formelle Risikoakzeptanz der Geschäftsführung für verzögerte Updates vor. |
Beispiel Wasserwirtschaft: Ein Wasserwerk identifiziert eine kritische Schwachstelle (CVE) in seiner SCADA-Historian-Datenbank, die aktiv ausgenutzt wird. Innerhalb von 48 Stunden wird eine kompensierende Maßnahme umgesetzt: Der externe Zugriff auf die Datenbank wird per Firewall blockiert, eine dedizierte Überwachungsregel im NDR eingerichtet und eine formelle Risikoakzeptanz bis zum nächsten regulären Wartungsfenster dokumentiert. |
7.5 Integration in das OT SOC
Die Einbindung der OT-Sicherheitsüberwachung in ein Security Operations Centre (SOC) erfordert OT-spezifische Playbooks und geschulte Analysten. Wesentliche Integrationspunkte:
• Weiterleitung von OT-NDR-Alarmen an das SIEM, angereichert mit Kontextinformationen zum betroffenen Asset (Kritikalität, verfahrenstechnische Funktion, Zonenklassifizierung)
7.6 Sicherheit von Engineering-Workstations
Engineering-Workstations (EWS), die zur Programmierung von PLCs, Konfiguration von RTUs und Administration von SCADA-Systemen genutzt werden, stellen Brückensysteme zwischen IT und OT dar und sind hochgradig kritisch. Sicherheitskontrollen entsprechend IEC 62443-4-2 umfangen:
8. Typische Herausforderungen und Lösungsansätze
Herausforderung | Auswirkung in der Praxis | Empfohlenes Vorgehen (Shieldworkz) |
Legacy-Systeme | Steuerungen/DCS aus den 2000er-Jahren; keine Verschlüsselung, keine Authentifizierung, kein Patch-Support; Hersteller existiert nicht mehr | Etablierung kompensierender Maßnahmen: Netzwerkisolierung, Applikations-Allowlisting auf verbundenen EWS, passive Überwachung. Formelle Dokumentation der Risikoakzeptanz. Einplanung von Budgets für den Austausch im Rahmen des Lebenszyklus (3–5 Jahre). |
Konflikte zwischen Safety und Security | Anforderungen der funktionalen Sicherheit (IEC 61511) können mit Sicherheitsmaßnahmen (IEC 62443) kollidieren; SIS-Änderungen erfordern aufwendige MOC-Prozesse | Frühzeitige Einbindung des Sicherheitsingenieurs (Safety Manager) in das Zonen-Design nach IEC 62443. Sicherheitskontrollen (Security) dürfen keinesfalls neue Fehlerszenarien für die funktionale Sicherheit (Safety) einführen. Dokumentation der Abstimmung zwischen CSMS und Safety-Management-System. |
Eingeschränkte Zeitfenster für Wartung (Downtime) | Viele OT-Systeme können nicht ohne geplante Stillstände neu gestartet, gepatched oder umkonfiguriert werden; Stillstände werden oft Monate im Voraus geplant | Integration von Firmware- und Patch-Updates in reguläre, geplante Stillstandszeiten (z. B. Jahreshauptrevisionen). Nutzung kompensierender Maßnahmen für die Übergangszeit. Dokumentation aufgeschobener Updates mitsamt formaler Risikoabwägung. |
Abhängigkeiten von Dritten | OEM-Hersteller fordern dauerhafte Wartungszugänge; Integratoren nutzen lokal gespeicherte Administrator-Credentials; Subunternehmer sind dem Betreiber unbekannt | Sofortige Einführung einer sicheren Fernzugriffsplattform (VRAP). Abschaffung permanenter Verbindungen. Verpflichtung zur Einhaltung der IEC 62443-2-4 in allen neuen Verträgen. Durchführung jährlicher Sicherheitsbewertungen von Dienstleistern. |
Budgetbeschränkungen | OT-Sicherheitsinvestitionen konkurrieren mit Investitionen in die Modernisierung von Produktionsanlagen; Security wird oft zugunsten von Produktionszielen verschoben | Argumentation der NIS2-Anforderungen als existenzielles Unternehmensrisiko: Die persönliche Haftung der Geschäftsleitung nach Artikel 20 ist ein wirksames Argument im Aufsichtsrat. Priorisierung von Kontrollen mit der höchsten Relevanz für NIS2-Audits: Asset-Inventar, Netzwerksegmentierung, Notfallfallplanung und Fernzugriff. |
Fachkräftemangel | Spezialisten, die sowohl OT-Protokolle als auch Cybersicherheit beherrschen, sind rar; OT-Ingenieure betrachten IT-Sicherheit oft als reines IT-Thema | Nutzung eines spezialisierten OT-MSSP für die Implementierung und den laufenden Sicherheitsbetrieb. Fortbildung von OT-Ingenieuren durch spezifische Security-Schulungen (z. B. Zertifizierung zum IEC 62443 Practitioner). Einbindung von Shieldworkz-Experten zur strategischen Begleitung. |
9. NIS2-Audit-Checkliste für den OT-CISO
Die folgende Checkliste mit 60 Prüfpunkten dient OT-Sicherheitsverantwortlichen zur schnellen Selbsteinschätzung. Die Punkte sind nach den Bereichen von NIS2 Artikel 21 strukturiert und an den Anforderungen der IEC 62443 ausgerichtet.
Governance und Risikomanagement
☐ Das CSMS-Sicherheitskonzept ist dokumentiert, für alle OT-Bereiche definiert und von der Geschäftsführung freigegeben.
☐ Eine spezifische Cybersicherheits-Risikoanalyse für die OT wurde gemäß der Methodik der IEC 62443-3-2 durchgeführt.
☐ Für alle OT-Zonen und -Verbindungen (Conduits) wurden Soll-Sicherheitsstufen (SL-T) definiert.
Asset-Inventar und Netzwerkarchitektur
Zugriffskontrolle
Schwachstellen- und Patch-Management
Wöchentlich erhalten
Ressourcen & Nachrichten
Erfahren Sie, wie unsere branchenführenden OT-Security-Lösungen kritische Sicherheitsherausforderungen gemäß KRITIS-Anforderungen bewältigen
Dies könnte Ihnen auch gefallen.
How Zero Trust Protects SCADA Systems from Cyberattacks
Team Shieldworkz
IEC 62443 Compliance Requirements Explained
Team Shieldworkz
A technical analysis of the fairlife cyber incident
Prayukth K V
Critical analysis of frontier AI (Mythos) capabilities in enterprise and OT security
Prayukth K V
CPS Security Monitoring: Gain Continuous Visibility Into Operational Risk
Team Shieldworkz
NERC CIP-015-1 Vulnerability Management Strategies for OT Networks
Team Shieldworkz
