Heute teilen wir einen Praxisleitfaden, der zeigt, wie Sie die beiden weltweit maßgeblichen OT-Sicherheitsframeworks zu einem Programm verbinden, das in der Praxis tatsächlich Bestand hat.  

Bevor wir fortfahren, vergessen Sie nicht, unseren vorherigen Blogbeitrag über das neue EU ICT Supply Chain Security Toolbox zu lesen, hier. 

Warum zwei Frameworks und warum sie gemeinsam verwenden?

Ein häufiger und nachvollziehbarer Fehler besteht darin, nur ein Framework auszuwählen und das Programm ausschließlich darauf aufzubauen. Programmverantwortliche fragen oft: Reicht IEC 62443 allein aus? Ist NIST SP 800-82 genug? Die Antwort auf beide Fragen lautet: nicht ganz, und hier ist der Grund.

IEC 62443 ist ein von ISA entwickelter und von IEC übernommener Engineering-Standard mit tiefer Beteiligung von Steuerungssystem-Ingenieuren, Fachleuten für Prozesssicherheit und OT-Herstellern. Seine DNA liegt auf dem Werksgelände, über Zonen und Conduits, Sicherheitslevel, Komponentenanforderungen und die Supply Chain von Service Providern. Er sagt Ihnen, welche Sicherheitseigenschaften Ihre Systeme haben sollen und, noch wichtiger, in welchem Ausmaß.

NIST SP 800-82 mit der neuesten Revision 3 (veröffentlicht im September 2023) ist im Wesentlichen ein Leitfaden. Er ist deskriptiv statt präskriptiv und zeigt Ihnen, was Sie berücksichtigen sollten und wie Sie über ICS-/OT-Sicherheit nachdenken sollten. Er ist an das NIST Cybersecurity Framework (CSF 2.0) angebunden und bietet Implementierungsstufen, Profile sowie eine umfassende Taxonomie von OT-Bedrohungen, Schwachstellen und Architekturen.

02  Jedes Framework im Detail verstehen

IEC 62443: Die Standardreihe, die Sie aus dem Effeff kennen sollten

IEC 62443 ist kein einzelner Standard, sondern eine Familie von Standards, die in vier Serien organisiert ist. Praktiker, die sie als ein einzelnes Dokument behandeln, machen kritische Implementierungsfehler. Hier ist, was jede Serie abdeckt und warum das im Betrieb wichtig ist:

Das Sicherheitslevel-(SL)-Modell ist der prägende Beitrag von IEC 62443. SL1 bis SL4 sind nicht nur Schweregrade — sie definieren die Fähigkeiten des Bedrohungsakteurs, denen Ihre Kontrollen standhalten müssen:

NIST SP 800-82 Rev.3: Was sich geändert hat und warum es wichtig ist

Revision 3, veröffentlicht im September 2023, ist ein erhebliches Update gegenüber Rev.2 (2015). Die wichtigsten Änderungen für Praktiker:

•  Vollständige Ausrichtung an NIST CSF 2.0, einschließlich der neuen Govern-Funktion. Dadurch wird OT-Cybersicherheits-Governance formal auf die organisatorische Ebene gehoben, nicht nur auf die technische.

•  Erweiterte Abdeckung von cloud-verbundenem OT, IIoT und Edge-Computing-Architekturen, die in Rev.2 nicht behandelt wurden – entscheidend für moderne O&G- und Advanced-Manufacturing-Umgebungen.

•  Aktualisierte Bedrohungslage unter Einbeziehung von ICS-spezifischer Malware nach 2015: TRITON/TRISIS (SIS-Angriff), INDUSTROYER2 (Energieversorgung), PIPEDREAM/INCONTROLLER (Multi-Plattform-ICS-Angriffsframework).

• Referenzarchitekturen wurden mit modernen DMZ-Designs, Defense in Depth für OT-Netze und Leitlinien zur Integration von OT SOC aktualisiert.

•  Explizite Querverweis-Mappings zwischen den Kontrollen von SP 800-82 und IEC 62443, NERC CIP und anderen OT-Frameworks ermöglichen eine Compliance-Ausrichtung über mehrere Frameworks hinweg.

 03  Die Integrationsarchitektur: Beide Frameworks gemeinsam wirksam machen

Die zentrale Erkenntnis für eine erfolgreiche Integration lautet: Verwenden Sie NIST SP 800-82 / CSF als Ihr Skelett für das Programmmanagement und IEC 62443 als Ihre technische Implementierungsspezifikation. Die sechs Funktionen des CSF (Govern, Identify, Protect, Detect, Respond, Recover) liefern die Lebenszyklusstruktur. IEC 62443 füllt jede Funktion mit OT-spezifischem Engineering-Inhalt.

 04  Asset-Inventar & Risikobewertung: Die unverzichtbare Grundlage

Jedes OT-Sicherheitsprogramm, das gescheitert ist (und viele sind es), ist bereits bei der Basisstufe selbst gescheitert. Sie können nicht schützen, was Sie nicht kennen. Und in OT-Umgebungen ist die Lücke zwischen dem dokumentierten Asset-Register und dem, was tatsächlich mit dem Netzwerk verbunden ist, fast immer größer, als irgendjemand im Management glaubt.

Schritt 1: OT-Asset-Discovery – Machen Sie es richtig

Führen Sie niemals aktive Scan-Tools auf produktiven OT-Netzen aus. Das ist keine Präferenz. Es ist eine Sicherheits- und Betriebsanforderung. Aktive Scanner senden Probes, die die begrenzte Rechenleistung älterer PLCs überlasten, Speicher auf manchen Legacy-RTUs beschädigen und unerwartetes Verhalten auf sicherheitskritischen Systemen auslösen können. Das ist in realen Umgebungen bereits passiert. NIST SP 800-82 Rev.3 §6.2.1 warnt ausdrücklich vor aktivem Scannen in produktiven ICS-Umgebungen ohne Validierung durch den Hersteller.

Der korrekte Ansatz ist passive Asset-Discovery: Setzen Sie einen passiven Network-Tap oder einen SPAN-Port an OT-Netzwerkswitches ein und verwenden Sie ein OT-Visibility-Tool mit Protokollverständnis, um Geräte anhand des beobachteten Traffics zu identifizieren. Dieser Ansatz, wie in IEC 62443-3-2 §4.2 definiert, ermöglicht es Ihnen, ein Asset-Inventar aufzubauen, das Gerätetyp, Hersteller, Modell, Firmware-Version, verwendete Protokolle und Kommunikationsmuster erfasst — ohne ein einziges Paket in das OT-Netz einzuspeisen.

Schritt 2: Definition von Zonen und Conduits (IEC 62443-3-2 §4.3)

Sobald Sie ein vollständiges Asset-Bild haben, gruppieren Sie Assets in Sicherheitszonen auf Basis von: gemeinsamen Sicherheitsanforderungen, Schadensausmaß bei Kompromittierung und Betriebsfunktion. Eine Zone ist eine logische Gruppierung von Assets, die das gleiche Sicherheitslevel teilen. Ein Conduit ist jeder Kommunikationsweg zwischen Zonen — und jeder Conduit muss dokumentiert, kontrolliert und geschützt sein.

Im Öl- und Gasumfeld sieht eine typische Zonenstruktur so aus: Die Safety-Ebene (SIS/ESD-Systeme, mindestens SL3) ist vollständig isoliert und kommuniziert mit der Basic-Process-Control-Ebene (DCS, typischerweise SL2) nur über eine Hardware-Daten-Diode in ausgehender Richtung. Die Basic-Process-Control-Ebene kommuniziert mit der Supervisory-Ebene (SCADA/Historian, SL2) über einen Firewall-Conduit. Die Supervisory-Ebene kommuniziert mit der Enterprise-/IT-Ebene über eine vollständig isolierte DMZ mit Anwendungsschichtprüfung. Keine Zone hat eine Direktverbindung, die eine Ebene überspringt. Das ist keine architektonische Eleganz — so verhindern Sie, dass eine Ransomware-Infektion auf einem Windows-Firmenlaptop einen Rockwell ControlLogix erreicht.

Schritt 3: Risikobewertung – für OT konsequenzorientiert

IEC 62443-3-2 definiert eine für IACS spezifische Methodik zur Risikobewertung. Der entscheidende Unterschied zur IT-Risikobewertung besteht darin, dass Konsequenzen in operativen und sicherheitstechnischen Begriffen bewertet werden müssen, nicht nur in finanziellen. Ein Vorfall, dessen Behebung im IT-Kontext 50.000 US-Dollar kostet, kann im OT-Kontext ein katastrophales Risiko darstellen, wenn er den Verlust der Eindämmung, eine Umweltfreisetzung oder die Umgehung einer Sicherheitsfunktion betrifft.

NIST SP 800-82 Rev.3 stimmt damit überein, indem es Konsequenzkategorien für ICS definiert: Sicherheit (Verletzung/Tod von Personen), Umweltfreisetzung, Produktionsauswirkung und Geräteschäden. Verwenden Sie die Konsequenzdefinitionen beider Frameworks, um eine Konsequenzmatrix aufzubauen, die Ihr Prozesssicherheitsteam validieren kann, denn diese Fachleute wissen am besten, was die Manipulation eines DCS-Sollwerts für die Prozessintegrität tatsächlich bedeutet.

05  Schutzmaßnahmen: Wo IEC 62443-3-3 FR1–FR7 die Hauptarbeit leistet

IEC 62443-3-3 definiert sieben Foundational Requirements (FRs) und 51 Systemanforderungen (SRs), die die spezifischen Sicherheitsfähigkeiten beschreiben, die ein System auf jedem Sicherheitslevel nachweisen muss. NIST SP 800-82 Rev.3 ordnet seine Kontrollkategorien denselben FRs zu. So setzen Sie diese im Betrieb um:

FR1: Identifikations- und Authentisierungssteuerung

Jeder Benutzer und jedes Gerät, das auf OT-Systeme zugreift, muss identifiziert und authentisiert werden. In der Praxis bedeutet das: gemeinsam genutzte Konten auf HMI- und EWS-Systemen eliminieren; eindeutige Anmeldedaten pro Ingenieur, Bediener und Vendor erzwingen; Multi-Faktor-Authentisierung für alle Remote-Zugangswege einführen. Für die Geräteauthentisierung ab SL2+ verwenden Sie, sofern die OT-Komponente dies unterstützt, zertifikatsbasierte Authentisierung. OPC-UA unterstützt zertifikatsbasierte gegenseitige Authentisierung und sollte gegenüber dem älteren OPC-DA mit DCOM-Authentisierung bevorzugt werden. Bei SL3 (SIS-Systeme) sind Hardware-Tokens oder eine gleichwertig starke Authentisierung für jeden Zugriff auf Engineering-Workstations zu verlangen, die SIS-Logik ändern können.

FR2: Verwendungskontrolle

Authentisierung allein reicht nicht — Autorisierung muss durchgesetzt werden. Trennen Sie Rollen in: Read-Only (Bediener, die den Prozess überwachen), Control (Bediener, die Befehle ausführen), Engineering (Logikänderung), Administration (Systemkonfiguration) und Vendor (zeitlich begrenzter, sitzungsbasierter Zugriff). Der häufigste FR2-Fehler in OT-Umgebungen ist, dass alle das Administrator-Konto verwenden, weil niemand die Zeit investiert hat, eine saubere Rollenmatrix aufzubauen. Das bedeutet, dass ein Auftragnehmer, der nur einen Diagnosewert prüfen soll, vollen Schreibzugriff auf die DCS-Konfiguration hat — ein unnötiges und gefährliches Privileg.

Für Remote-Zugriffe erzwingen Sie eine sitzungsbasierte Autorisierung: Jede Zugriffssitzung eines Vendors oder entfernten Ingenieurs erfordert eine explizite Freigabe über einen definierten Workflow, hat eine maximale Sitzungsdauer, erfolgt über einen Jump Server mit Sitzungsaufzeichnung und wird beendet und protokolliert. Keine dauerhaft aktiven VPN-Tunnel in OT-Netze. Keine Ausnahmen.

FR3 und FR4: Datenintegrität und Vertraulichkeit

Legacy-OT-Protokolle Modbus TCP, DNP3 (ohne Secure Authentication), klassisches OPC-DA wurden für Zuverlässigkeit, nicht für Sicherheit entwickelt. Sie haben keine integrierten Integritäts- oder Vertraulichkeitsmechanismen. Das bedeutet, dass ein Angreifer mit Netzwerkzugang alle Prozessdaten lesen, falsche Befehle einschleusen und aufgezeichnete legitime Befehle erneut abspielen kann. NIST SP 800-82 Rev.3 §6.2.4 und IEC 62443-3-3 FR3/FR4 adressieren diese Realität mit derselben pragmatischen Leitlinie: Wo Sie das Protokoll nicht ersetzen können, kompensieren Sie mit Netzwerkkontrollen (strikte Zonenisolation, anwendungsbewusste Firewalls, Anomalieerkennung); und wo Sie das Protokoll ersetzen oder ergänzen können (OPC-UA, DNP3-SA, IPsec-Tunnel), tun Sie es.

FR5: Eingeschränkter Datenfluss

Das ist das Zonen-/Conduit-Modell in der Praxis. Jeder Kommunikationsweg zwischen Zonen muss explizit erlaubt werden — nicht umgekehrt. Die Standardhaltung ist verweigern. Firewall-Regeln zwischen OT-Zonen sollten so spezifisch wie möglich sein: Quell-IP, Ziel-IP, Port und Protokoll. Jede "any-to-any"-Regel in einer OT-Firewall ist ein kritischer Befund. Für die Pfade mit höchster Konsequenz (zum Beispiel SIS zu DCS) setzen Sie unidirektionale Security-Gateways (Hardware-Daten-Diodes) ein, die physisch verhindern, dass Verkehr in die Hochsicherheitsrichtung fließt. Nur softwarebasierte Firewalls können, unabhängig davon wie gut sie konfiguriert sind, falsch konfiguriert oder ausgenutzt werden — Hardware-Daten-Diodes können aus physikalischen Gründen keinen Verkehr in die falsche Richtung passieren lassen.

FR6: Zeitnahe Reaktion auf Ereignisse

Sie können nicht auf Ereignisse reagieren, die Sie nicht sehen. Dafür ist OT-spezifisches Sicherheitsmonitoring erforderlich. IT-SIEM-Tools ohne OT-Protokollverständnis erzeugen auf OT-Netzen enorme Störgeräusche und übersehen die tatsächlich relevanten Indikatoren für eine Kompromittierung. Die ideale Architektur ist eine passiv betriebene OT-Visibility-Plattform, die ICS-Protokolle versteht, normalisierte Alarme an eine zentrale Monitoring-Funktion (OT SOC) weiterleitet und Ereignisse zonenübergreifend korreliert. NIST SP 800-82 Rev.3 §6.2.8 bietet Architekturleitlinien für OT-Monitoring, die mit den FR6-Anforderungen von IEC 62443 übereinstimmen.

FR7: Verfügbarkeit von Ressourcen

OT-Systeme müssen verfügbar bleiben — oft noch kritischer als vertraulich. Das bedeutet: Resilienz und Redundanz sind Sicherheitskontrollen, nicht nur technische Designentscheidungen. Prüfen Sie für kritische OT-Systeme: Controller-Redundanz (Hot Standby), Redundanz des Netzwerkpfads (HSR, PRP oder RSTP mit schnellem Failover), Redundanz der Stromversorgung (USV mit Generator-Backup) und die Integrität von Konfigurations-Backups. Entscheidend ist, die Wiederherstellung zu testen — ein Backup, das nie wiederhergestellt wurde, ist eine Annahme, keine Fähigkeit. NIST SP 800-82 Rev.3 §6.2.7 und IEC 62443-3-3 FR7 verlangen beide getestete Wiederherstellungsfähigkeit, nicht nur dokumentierte Verfahren.

6  Erkennung, Reaktion und Wiederherstellung: Den Kreis schließen

Aufbau einer OT-Detection-Fähigkeit

Die OT-Bedrohungslandschaft hat sich seit 2017 grundlegend verändert. Der TRITON/TRISIS-Angriff zeigte, dass hochentwickelte Angreifer gezielt Safety Instrumented Systems angreifen — die letzte Verteidigungslinie, bevor ein physischer Prozess gefährlich wird. PIPEDREAM/INCONTROLLER, 2022 veröffentlicht, zeigte ein modulares Angriffsframework, das Schneider Electric, OMRON und andere große OT-Plattformen über native ICS-Protokolle anvisieren kann. Das sind keine theoretischen Bedrohungen — es sind dokumentierte, reale Fähigkeiten, die gegen kritische Infrastrukturen eingesetzt wurden.

Detection in diesem Umfeld erfordert OT-spezifische Fähigkeiten, die IT-Sicherheitstools nicht haben. Ein Network Intrusion Detection System, das keine Modbus-Function-Codes, keinen Inhalt der DNP3-Application Layer oder OPC-UA-Service-Operationen versteht, kann keine bösartige Manipulation von OT-Protokollen erkennen, weil für es sämtlicher OT-Verkehr wie Rauschen aussieht. Protokollbewusste Deep Packet Inspection, speziell für OT-Umgebungen abgestimmt, ist für SL2+-Umgebungen nicht optional.

OT Incident Response: Die Schnittstelle zur Prozesssicherheit

Der am meisten unterschätzte Aspekt von OT Incident Response ist die Schnittstelle zwischen einem Cyberereignis und einem Prozesssicherheitsereignis. Ein Cyberangriff auf ein DCS präsentiert sich nicht wie ein IT-Sicherheitsvorfall — er kann sich zunächst als unerklärliche Prozessabweichungen, Abweichungen der Ventilposition oder als Instrumentenwerte zeigen, die anomal erscheinen. Der TRITON-Angriff wurde zuerst von einem Prozessleittechniker bemerkt, der ungewöhnliches SIS-Verhalten sah, nicht von einem Security Analyst.

Ihr OT Incident Response Plan muss daher enthalten: explizite Auslöser für die Eskalation an das Notfallteam der Prozesssicherheit; definierte Rollen für das PSSR-Team (Pre-Startup Safety Review), falls das OT-System nach einem Cybervorfall wieder in Betrieb genommen werden muss; und die Befugnis für den Betrieb, ein kompromittiertes System vom Prozessleitsystem zu trennen, ohne auf die Freigabe von IT/Cybersicherheit zu warten, wenn die Sicherheit unmittelbar gefährdet ist. NIST SP 800-82 Rev.3 §6.2.9 und IEC 62443-2-1 §4.3.6 behandeln beide Incident Response, aber keiner adressiert die Safety-Cyber-Schnittstelle im erforderlichen Detail — diese Lücke muss Ihr Programm mit standortspezifischen HAZOP- und Risikobewertungsinputs schließen.

Wiederherstellung: Die vergessene Funktion

IEC 62443-3-3 FR7 und die Recover-Funktion des NIST CSF verlangen beide getestete, dokumentierte Wiederherstellungsfähigkeit. In OT-Kontexten ist Recovery deutlich komplexer als IT-Recovery, weil: OT-Systeme herstellerspezifische Wiederherstellungsverfahren erfordern können; Logik-Downloads auf PLCs und DCS-Controller definierten Sequenzen folgen müssen; der Wiederanlauf nach längerer Unterbrechung Prozesssicherheitsaspekte umfasst (Spülen, Druckprüfungen, Instrumentenverifikation), die Tage oder Wochen dauern können; und für Cybervorfälle, die Prozesssicherheitssysteme betreffen, regulatorische Meldepflichten gelten können.

Definieren Sie Recovery Time Objectives (RTOs) für jede OT-Zone auf Basis der betrieblichen Toleranz — nicht auf Basis von IT-Standards. Ein IT-RTO von 24 Stunden für ein nicht kritisches System mag akzeptabel sein; ein OT-RTO von 24 Stunden für ein Pipeline-SCADA-System bedeutet einen Tag Blindbetrieb eines druckbeaufschlagten Transportsystems, und das ist nicht akzeptabel. Diese RTOs müssen von Betrieb und Verfahrenstechnik validiert werden, nicht von IT festgelegt.

07  Implementierungsfahrplan: Ein realistischer 24-Monats-Programmaufbau

Der Aufbau eines OT-Cybersecurity-Programms ist eine mehrjährige Aufgabe. Der folgende Fahrplan basiert auf dem Dual-Framework-Ansatz und ist an die Realität der betrieblichen OT-Einschränkungen angepasst: Sie dürfen den Betrieb nicht stören, Sie dürfen die Aufnahmefähigkeit Ihrer Organisation für Veränderungen nicht überholen, und Sie dürfen den Wartungsfenster-Zyklus nicht ignorieren.

MONATE 1–3 · PHASE 1: GRUNDLAGEN

Governance und Basis-Sichtbarkeit etablieren

Vor jeder technischen Kontrolle benötigen Sie organisatorische Unterstützung, definierte Rollen und ein reales Asset-Bild. Ohne diese Grundlagen baut jede weitere Aktivität auf Sand.

•  OT-Cybersecurity-Policy erstellen und verabschieden, ausgerichtet an den Anforderungen des IEC 62443-2-1 CSMS

•  OT-Sicherheitsrollen definieren (OT Security Lead, standortbezogene OT-Sicherheitsvertretungen, Vendor-Überwachungsfunktion) und in Stellenbeschreibungen oder RACI formalisieren

•  Passive OT-Asset-Discovery an allen Standorten bereitstellen — das belastbare Asset-Register aufbauen

•  Erste Zonen-/Conduit-Mapping-Übung gemäß IEC 62443-3-2 §4.3 durchführen

•  OT-spezifische Risiko-Register-Vorlage etablieren, ausgerichtet an IEC 62443-3-2 und den Konsequenzkategorien von NIST SP 800-82

• Den aktuellen erreichten Sicherheitslevel (SL-A) anhand von IEC 62443-3-3 FR1–FR7 baseline-erfassen

MONATE 3–6 · PHASE 2: RISIKOBEWERTUNG

Risikobewertung abschließen und Zielzustand definieren

Mit etablierter Sichtbarkeit schließen Sie die formale Risikobewertung ab. Das ist das wichtigste Ergebnis im gesamten Programm — alles Weitere leitet sich daraus ab.

•       IEC 62443-3-2-Risikobewertung für alle Zonen abschließen; SL-T für jede Zone festlegen

•       Alle SL-Lücken (SL-T minus SL-A) identifizieren und priorisieren – daraus wird Ihr Remediation-Backlog

•       An NIST SP 800-82 Rev.3 ausgerichtete Threat-Modeling-Aktivitäten durchführen, einschließlich ICS-spezifischer Bedrohungsakteure und TTPs

•       Alle unmittelbaren/kritischen Findings identifizieren, die unabhängig von geplanten Programmphasen behandelt werden müssen

•       Risiko-Register in das Enterprise Risk Management Framework integrieren; der Geschäftsleitung vorlegen

•       Vendor-Sicherheitsanforderungen aktualisieren oder entwerfen, ausgerichtet an IEC 62443-2-4

MONATE 6–12 · PHASE 3: KERNKONTROLLEN

Priorisierte Schutzmaßnahmen umsetzen

Beheben Sie kritische und hoch priorisierte Lücken. Konzentrieren Sie sich zuerst auf die Netzwerkarchitektur (der größte Hebel in der OT-Sicherheit) und auf Access Control.

• Netzwerksegmentierung implementieren oder nachbessern: DMZ-Architektur zwischen OT und IT; Zonengrenzen mit OT-geeigneten Firewalls durchsetzen

• Data Diodes auf SIS-zu-DCS-Datenpfaden einsetzen, wo SL3 angestrebt wird

• Default-Credentials auf allen OT-Geräten entfernen; rollenbasierte Zugriffskontrolle gemäß FR1–FR2 implementieren

• Jump Server mit Sitzungsaufzeichnung für alle Remote-Zugriffe auf OT-Zonen bereitstellen; MFA für Remote-Zugriffe erzwingen

• Media Scanning (Shieldworkz Media Scanning Solution oder gleichwertig) für alle Wechseldatenträger, die OT-Umgebungen betreten, implementieren

• OT-Visibility-Plattform im passiven Monitoring-Modus bereitstellen; Alarm-Triage-Verfahren etablieren

• Erstes OT-Incident-Response-Tabletop entwickeln und durchführen, einschließlich Eskalation von Cyber zu Prozesssicherheit

MONATE 12–18 · PHASE 4: REIFE VON DETECTION & RESPONSE

Nachhaltige Erkennungs- und Reaktionsfähigkeit aufbauen

Wechseln Sie von reaktiv zu proaktiv: kontinuierliches Monitoring, Threat-Hunting-Fähigkeit und getestete Reaktionsverfahren.

• OT-SOC-Funktion etablieren (intern oder gemanagt) mit OT-spezifischen Detection-Use-Cases und Playbooks

• OT-Visibility-Plattform-Alarme in ein Enterprise-SIEM mit OT-geeigneten Korrelationsregeln integrieren

• OT-Patch-Management-Prozess gemäß IEC 62443-2-3 implementieren: Vendor-Abstimmung, Tests in Staging-Umgebung, Planung von Wartungsfenstern

• OT-Vulnerability-Assessments über alle kritischen Systeme hinweg mit passiven/gering belastenden Methoden durchführen

• OT Business Continuity und Disaster Recovery vollständig planen; Wiederherstellung von Konfigurations-Backups testen

•  Schulungsprogramm zur OT-Sicherheitsawareness für Bediener, Ingenieure und Auftragnehmer starten

MONATE 18–24 · PHASE 5: KONTINUIERLICHE VERBESSERUNG

Institutionalisieren, messen und verbessern

Ein Cybersecurity-Programm, das sich nicht kontinuierlich verbessert, wird erodieren. Bedrohungen entwickeln sich weiter, Systeme ändern sich, Personal wechselt. Bauen Sie Mechanismen auf, die das Programm über den Erstaufbau hinaus tragen.

•       Vierteljährliches OT-Sicherheitsreporting an die Geschäftsleitung etablieren: KPIs einschließlich Patch-Compliance-Quote, offener Risikopunkte, Incident-Kennzahlen und Trainingsabschluss

•       OT-Cybersicherheitsprüfung in alle OT-Change-Management-(MOC)-Prozesse integrieren

•       Jährliche Aktualisierung der IEC 62443-3-2-Risikobewertung; SL-T und Risiko-Register aktualisieren

•       Jährliche OT-Incident-Response-Übung (bei sicherem Rahmen von Tabletop zu Live-Drill ausbauen)

•       Beschaffungsstandard aktualisieren: Für alle neuen OT-Beschaffungen ist eine IEC 62443-4-2-Komponenten-Zertifizierung auf SL-Basis oder ein gleichwertiger Nachweis des Vendor-SDL erforderlich

•       Bewertung der Supply Chain Security: wichtige OT-Vendoren anhand der IEC 62443-2-4-Anforderungen bewerten

08  Governance: Der Unterschied zwischen einem Programm und einem Projekt

Technische Kontrollen ohne Governance erodieren. Das OT-Cybersecurity-Programm muss durch organisatorische Mechanismen getragen werden, die einzelne Mitarbeitende, Budgetzyklen und die Aufmerksamkeit des Managements überdauern. IEC 62443-2-1 definiert das Cyber Security Management System (CSMS) – das organisatorische System, das sicherstellt, dass Cybersicherheit eine kontinuierliche Managementfunktion und kein einmaliges Projekt ist.

Das CSMS sollte OT-spezifisch sein

Einer der häufigsten Governance-Fehler besteht darin, die IT-Sicherheitsrichtlinie der Organisation oder sogar das IT-ISMS (ISO 27001) ohne Anpassung direkt auf OT anzuwenden. IT und OT haben grundlegend unterschiedliche Prioritäten, Risikotoleranzen und operative Einschränkungen. Eine IT-Richtlinie, die MFA für jeden Systemzugriff fordert, ist für IT korrekt und angemessen. Naiv auf OT angewendet, würde sie MFA für einen Bediener verlangen, der eine priorisierte Alarmmeldung innerhalb von zwei Sekunden bestätigen muss, sonst droht eine Prozessstörung — genau deshalb muss das OT-CSMS OT-spezifische Kontrollen mit operativem Kontext definieren.

Change Management ist eine Sicherheitskontrolle

Jede Änderung an OT-Hardware, Software, Netzwerkkonfiguration oder am Prozess ist ein potenzielles Sicherheitsereignis. Der Management-of-Change-(MOC)-Prozess muss einen obligatorischen OT-Cybersicherheitsprüfschritt enthalten. Das bedeutet: Bevor irgendeine Änderung in der OT-Umgebung umgesetzt wird, prüft die OT-Sicherheitsfunktion die Cybersecurity-Auswirkungen. Neue Vendor-Anbindungen, Firmware-Updates, Netzwerkkonfigurationen, neue Geräte im OT-Netz – alles muss durch diesen Prüfpunkt laufen. NIST SP 800-82 Rev.3 §6.2.3 und IEC 62443-2-1 §4.2.3 definieren Change Management beide als zentrale Sicherheitsmanagementanforderung.

Vendor- und Supply-Chain-Risiko

In OT-Umgebungen ist die Supply Chain die Angriffsfläche. OT-Vendoren, Systemintegratoren und Service Provider haben regelmäßig Remote-Zugriff auf Kunden-OT-Systeme für Ferndiagnose, Notfallunterstützung und geplante Wartung. Der SolarWinds-Angriff zeigte in großem Maßstab, was OT-Sicherheitspraktiker seit Jahren wissen: Vertrauenswürdige Vendor-Verbindungen sind vertrauenswürdige Angriffsvektoren, wenn das Sicherheitsniveau des Vendors unzureichend ist.

IEC 62443-2-4 definiert Sicherheitsanforderungen, die Sie vertraglich an OT-Service-Provider stellen können. Mindestanforderungen für jeden Vendor mit OT-Netzwerkzugang: dokumentierte Sicherheitspraktiken; Verwendung dedizierter, auf Malware geprüfter Geräte für OT-Arbeiten; nur sitzungsbasierter Zugriff (keine dauerhaften Verbindungen); Zustimmung zur Sitzungsaufzeichnung; und Meldepflichten bei Vorfällen. Prüfen Sie diese Anforderungen — sammeln Sie nicht nur unterschriebene Bestätigungen.

Kennzahlen, die wirklich etwas aussagen

Die meisten OT-Sicherheitskennzahlen, die an das Management berichtet werden, sind Aktivitätskennzahlen: Anzahl geschriebener Richtlinien, Anzahl abgeschlossener Schulungen, Anzahl gescannter Assets. Diese messen Aufwand, nicht Sicherheit. Entscheidend sind Ergebniskennzahlen, die an Ihrem Risiko-Register ausgerichtet sind:

Dieser Artikel spiegelt die technischen Positionen und die operative Erfahrung der Autoren wider. Er richtet sich an Cybersicherheits- und Betriebsfachleute in industriellen Umgebungen. Nichts in diesem Dokument stellt eine rechtliche, regulatorische oder sicherheitstechnische Beratung dar. Alle Verweise auf Frameworks beziehen sich auf öffentlich verfügbare Standards; Leser sollten die aktuell veröffentlichten Versionen für verbindliche Anforderungen konsultieren. IEC 62443 ist eine aktive Standardreihe, und einzelne Teile können überarbeitet werden.

Mit uns verbinden, um mehr darüber zu erfahren, wie Sie IEC 62443 und NIST SP 100-82 nutzen können, um ein Cybersecurity-Programm aufzubauen.

Laden Sie unsere Checkliste zur Integration von IEC 62443 und NIST SP 100-82 herunter, hier