Heute teilen wir einen praktischen Leitfaden zur Kombination der beiden weltweit maßgeblichsten OT-Sicherheitsrahmenwerke in ein Programm, das sich tatsächlich in der Praxis bewährt.  

Bevor wir weitermachen, vergessen Sie nicht, unseren vorherigen Blogbeitrag über den neuen EU-IKT-Lieferkettensicherheits-Toolbox, hier, anzusehen.  

Warum zwei Rahmenwerke haben und warum sie zusammen verwenden?

Ein häufiger und verständlicher Fehler ist es, ein einziges Rahmenwerk auszuwählen und ein Programm ausschließlich darum herum aufzubauen. Programmleiter fragen oft: Ist IEC 62443 allein ausreichend? Ist NIST SP 800-82 genug? Die Antwort auf beide Fragen lautet: nicht ganz, und hier ist der Grund.

IEC 62443 ist ein Ingenieurstandard, entwickelt von der ISA und von der IEC übernommen, mit tiefem Engagement von Ingenieuren für Steuerungssysteme, Fachleuten für Prozesssicherheit und OT-Anbietern. Sein zentrales Erbgut liegt im Bereich der Fabrikhalle über Zonen und Leitungen, Sicherheitsniveaus, Komponentenanforderungen und der Lieferkette des Dienstleisters. Es legt fest, welche Sicherheitseigenschaften Ihre Systeme haben sollten und vor allem in welchem Umfang.

NIST SP 800-82 mit seiner neuesten Überarbeitung 3 (veröffentlicht im September 2023) ist im Wesentlichen ein Leitfadendokument. Es ist eher beschreibend als vorschreibend und sagt Ihnen, was Sie berücksichtigen sollten und wie Sie über ICS/OT-Sicherheit nachdenken sollten. Es passt zum NIST Cybersecurity Framework (CSF 2.0) und bietet Implementierungsstufen, Profile und eine umfassende Taxonomie von Bedrohungen, Schwachstellen und Architekturen für OT.

02  Jedes Rahmenwerk im Detail verstehen

IEC 62443: Die Standardserie, die Sie genau kennen müssen

IEC 62443 ist kein einzelner Standard – es ist eine Familie von Standards, die in vier Serien organisiert sind. Praktiker, die es als ein einziges Dokument behandeln, machen kritische Implementierungsfehler. Hier ist, was jede Serie abdeckt und warum es betrieblich wichtig ist:

Das Sicherheitsniveaumodell (SL) ist IEC 62443's entscheidender Beitrag. SL1 bis SL4 sind nicht nur Schweregradbewertungen – sie definieren die Bedrohungsakteur Fähigkeiten, denen Ihre Kontrollmaßnahmen standhalten müssen:

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

Die Überarbeitung 3, veröffentlicht im September 2023, stellt ein erhebliches Upgrade gegenüber Rev.2 (2015) dar. Die wichtigsten Änderungen für Praktiker:

•  Vollständige Ausrichtung auf NIST CSF 2.0, einschließlich der neuen Governance-Funktion. Dies erhebt die OT-Cybersicherheits-Governance formell auf die Organisationsebene, nicht nur auf die technische Ebene.

•  Erweiterte Abdeckung von cloudverbundenem OT, IIoT und Edge-Computing-Architekturen, die in Rev.2 nicht behandelt wurden – entscheidend für moderne Ö&G- und fortgeschrittene Fertigungsumgebungen.

•  Aktualisierte Bedrohungslandschaft unter Einbeziehung von post-2015 ICS-spezifischer Malware: TRITON/TRISIS (SIS-Angriff), INDUSTROYER2 (Energieversorgungsnetz), PIPEDREAM/INCONTROLLER (multi-plattform ICS-Angriffs-Framework).

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

•  Explizite Kreuzreferenzierungstabellen zwischen SP 800-82-Kontrollen und IEC 62443, NERC CIP und anderen OT-Rahmenwerken – ermöglicht die Ausrichtung an mehreren Rahmenwerken in Bezug auf die Einhaltung.

 03  Die Integrationsarchitektur: Beide Rahmenwerke zusammenarbeiten lassen

Der Schlüssel zur erfolgreichen Integration liegt in folgendem Einblick: Verwenden Sie NIST SP 800-82 / CSF als Ihr Programmmanagement-Skelett und IEC 62443 als Ihre technische Implementierungsspezifikation. Die sechs Funktionen des CSF (Governance, Identifizieren, Schützen, Erkennen, Reagieren, Wiederherstellen) bieten die Lebenszyklusstruktur. IEC 62443 füllt jede Funktion mit OT-spezifischem ingenieurtechnischen Inhalt.

 04  Anlageninventar & Risikobewertung: Die unverhandelbare Grundlage

Jedes OT-Sicherheitsprogramm, das gescheitert ist (und viele sind es), scheiterte bereits beim grundlegenden Schritt. Sie können nicht schützen, was Sie nicht wissen, dass es existiert. Und in OT-Umgebungen ist die Kluft zwischen dem dokumentierten Anlagenregister und dem, was tatsächlich an das Netzwerk angeschlossen ist, fast immer größer, als es das Management glaubt.

Schritt 1: OT-Anlagenerkennung — richtig machen

Verwenden Sie niemals aktive Scantools auf Live-OT-Netzwerken. Dies ist keine Präferenz. Stattdessen ist es ein Sicherheits- und Betriebsanforderung. Aktive Scanner senden Sonden, die die begrenzte Verarbeitungskapazität älterer PLCs überwältigen, den Speicher auf einigen alten RTUs beschädigen und unerwartetes Verhalten bei sicherheitskritischen Systemen auslösen können. Dies ist in realen Umgebungen schon passiert. NIST SP 800-82 Rev.3 §6.2.1 warnt ausdrücklich vor aktivem Scannen in Live-ICS-Umgebungen ohne Validierung des Anbieters.

Der korrekte Ansatz ist die passive Anlagenerkennung: Platzieren Sie einen passiven Netzwerktap oder SPAN-Port an OT-Netzwerk-Switches und verwenden Sie ein protokollbewusstes OT-Sichtbarkeitstool, um Geräte aus beobachtetem Verkehr zu identifizieren. Dieser Ansatz, wie er in IEC 62443-3-2 §4.2 definiert ist, ermöglicht es Ihnen, ein Anlageninventar zu erstellen, das den Gerätetyp, den Anbieter, das Modell, die Firmware-Version, die verwendeten Protokolle und die Kommunikationsmuster erfasst – ohne ein einziges Datenpaket ins OT-Netzwerk zu injizieren.

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

Sobald Sie ein vollständiges Anlagenbild haben, gruppieren Sie die Anlagen in Sicherheitszonen basierend auf: gemeinsamen Sicherheitsanforderungen, der Konsequenz des Kompromisses und der betrieblichen Funktion. Eine Zone ist eine logische Gruppierung von Anlagen, die dasselbe Sicherheitsniveau teilen. Eine Leitung ist jeder Kommunikationsweg zwischen Zonen – und jede Leitung muss dokumentiert, kontrolliert und geschützt werden.

Im Öl- und Gaskontext sieht eine typische Zonenstruktur so aus: Die Sicherheitsschicht (SIS/ESD-Systeme, mindestens SL3) ist vollständig isoliert und kommuniziert nur über eine Hardware-Daten-Diode mit der Basisprozesssteuerungsschicht (DCS, typischerweise SL2) in Ausgangsrichtung. Die Basisprozesssteuerungsschicht kommuniziert mit der Überwachungsschicht (SCADA/Historien, SL2) durch ein Firewall-Leitweg. Die Überwachungsschicht kommuniziert mit der Unternehmens-/IT-Schicht durch eine vollständig isolierte DMZ mit Inspektion der Anwendungsschicht. Keine Zone hat eine direkte Verbindung, die eine Schicht überspringt. Dies ist keine architektonische Eleganz – so verhindern Sie, dass ein Ransomware-Infektion auf einem Windows-Firmenlaptop ein Rockwell ControlLogix erreicht.

Schritt 3: Risikobewertung — Konsequenzzuerst für OT

IEC 62443-3-2 definiert eine Risikobewertungsmethodik, die spezifisch für IACS ist. Der wesentliche Unterschied zur IT-Risikobewertung besteht darin, dass die Konsequenz in betrieblichen und sicherheitstechnischen Begriffen bewertet werden muss, nicht nur in finanziellen Begriffen. Ein Verstoß, der in einem IT-Kontext 50.000 US-Dollar kostet, um behoben zu werden, könnte in einem OT-Kontext ein katastrophales Risiko darstellen, wenn er Verlust des Einschlusses, Umweltfreisetzung oder die Umgehung einer Sicherheitsfunktion beinhaltet.

NIST SP 800-82 Rev.3 stimmt damit überein, indem es Konsequenzkategorien für ICS definiert: Sicherheit (Verletzung/Tod des Personals), Umweltfreisetzung, Produktionsauswirkung und Geräteschaden. Verwenden Sie die Konsequenzdefinitionen beider Rahmenwerke, um eine Konsequenzmatrix zu erstellen, die Ihr Prozesssicherheitsteam validieren kann — denn sie sind die Experten darin, was die Manipulation eines DCS-Setzpunkts tatsächlich für die Prozessintegrität bedeutet.

05  Schutzmaßnahmen: Wo IEC 62443-3-3 FR1–FR7 die Arbeit übernimmt

IEC 62443-3-3 definiert sieben Grundanforderungen (FRs) und 51 Systemanforderungen (SRs), die die spezifischen Sicherheitsfähigkeiten beschreiben, die ein System auf jedem Sicherheitsniveau nachweisen muss. NIST SP 800-82 Rev.3 ordnet seine Kontrollkategorien diesen gleichen FRs zu. So implementieren Sie sie betrieblich:

FR1: Identifikation und Authentifizierungssteuerung

Jeder Benutzer und jedes Gerät, das OT-Systeme zugreift, muss identifiziert und authentifiziert werden. Praktisch bedeutet das: Beseitigung von freigegebenen Konten auf HMI- und EWS-Systemen; Durchsetzung einzigartiger Anmeldeinformationen für Ingenieure, Bediener und Anbieter; Einsatz von Multi-Faktor-Authentifizierung auf allen Zugangswegen aus der Ferne. Für Geräteauthentifizierung auf SL2+, verwenden Sie zertifikatbasierte Authentifizierung, wo dies von der OT-Komponente unterstützt wird – OPC-UA unterstützt zertifikatbasierte gegenseitige Authentifizierung und sollte gegenüber dem veralteten OPC-DA mit DCOM-Authentifizierung bevorzugt werden. Auf SL3 (SIS-Systeme), fordern Sie Hardware-Token oder gleichwertige starke Authentifizierung für jeden Zugriff auf Ingenieur-Arbeitsplätze, die SIS-Logik ändern können.

FR2: Nutzungssteuerung

Authentifizierung ist nicht ausreichend — Autorisierung muss durchgesetzt werden. Trennen Sie Rollen in: Nur-Lesen (Bediener, die den Prozess überwachen), Steuerung (Bediener, die Befehle ausführen), Engineering (Logikmodifikation), Verwaltung (Systemkonfiguration) und Anbeiter (zeitlich begrenzter, sitzungsbasierter Zugang). Der häufigste FR2-Fehler in OT-Umgebungen ist, dass jeder das Administratorkonto benutzt, weil sich niemand die Zeit genommen hat, eine ordnungsmäßige Rollentabelle zu erstellen. Dies bedeutet, dass ein Auftragnehmer, der einen Diagnoselesewert überprüfen muss, vollen Schreibzugriff auf die DCS-Konfiguration hat — ein unnötiges und gefährliches Vorrecht.

Für Fernzugriff, erzwingen Sie sitzungsbasierte Autorisierung: jeder Anbieter- oder Ferningenieur-Zugriffssitzung erfordert explizite Genehmigung durch einen definierten Workflow, hat eine maximale Sitzungsdauer, wird über einen Jump-Server mit Sitzungsaufzeichnung durchgeführt und wird beendet und protokolliert. Keine dauerhaften VPN-Tunnel in OT-Netzwerke. Keine Ausnahmen.

FR3 und FR4: Datenintegrität und Vertraulichkeit

Veraltete OT-Protokolle – Modbus TCP, DNP3 (ohne sichere Authentifizierung), klassisches OPC-DA – wurden für Zuverlässigkeit konzipiert, nicht für Sicherheit. Sie haben keine eingebauten Integritäts- oder Vertraulichkeitsmechanismen. Dies bedeutet, dass ein Angreifer mit Netzwerkzugriff alle Prozessdaten lesen, falsche Befehle einfügen und erfasste legitime Befehle wiedergeben kann. NIST SP 800-82 Rev.3 §6.2.4 und IEC 62443-3-3 FR3/FR4 behandeln diese Realität mit derselben pragmatischen Anleitung: Wo Sie das Protokoll nicht ersetzen können, kompensieren Sie mit Netzwerkkontrollen (strikte Zonentransparenz, anwendungsbewusste Firewalls, Anomalieerkennung); und wo Sie das Protokoll ersetzen oder ergänzen können (OPC-UA, DNP3-SA, IPsec-Tunnel), tun Sie dies.

FR5: Eingeschränkter Datenfluss

Dies ist das Zonen- und Leitungsmodell in der Praxis. Jeder Kommunikationspfad zwischen Zonen muss ausdrücklich erlaubt sein – nicht umgekehrt. Die Standardhaltung ist ablehnen. Firewall-Regeln zwischen OT-Zonen sollten so spezifisch wie möglich sein: Quell-IP, Ziel-IP, Port und Protokoll. Jede "von-zu-jeder" Regel in einer OT-Firewall ist ein kritischer Befund. Für die Wege mit den höchsten Konsequenzen (SIS zu DCS, beispielsweise), implementieren Sie unidirektionale Sicherheits-Gateways (Hardware-Daten-Dioden), die physisch verhindern, dass Verkehr in der Hochsicherheitsrichtung fließt. Software-Only-Firewalls, egal wie gut konfiguriert, können falsch konfiguriert oder ausgenutzt werden – Hardware-Daten-Dioden können keine Daten in die falsche Richtung leiten, da die Physik dies nicht zulässt.

FR6: Rechtzeitige Reaktion auf Ereignisse

Sie können nicht auf Ereignisse reagieren, die Sie nicht sehen können. Dies erfordert OT-spezifische Sicherheitsüberwachung. IT-SIEM-Tools ohne OT-Protokollerkenntnis erzeugen enormen Lärm auf OT-Netzwerken und übersehen die tatsächlich bedeutungsvollen Kompromissindikatoren. Die ideale Architektur ist eine OT-Sichtbarkeitsplattform, die passiv eingesetzt wird, ICS-Protokolle versteht und normalisierte Alarme an eine zentrale Überwachungsfunktion (OT SOC) weiterleitet und Ereignisse über Zonen hinweg korreliert. NIST SP 800-82 Rev.3 §6.2.8 bietet Architekturleitlinien für OT-Monitoring, die den FR6-Anforderungen von IEC 62443 entsprechen.

FR7: Ressourcenverfügbarkeit

OT-Systeme müssen verfügbar bleiben – oft entscheidender als sie vertraulich bleiben müssen. Das bedeutet, Resilienz und Redundanz sind Sicherheitskontrollen und nicht nur ingenieurtechnische Designentscheidungen. Für kritische OT-Systeme, verifizieren Sie: Controller-Redundanz (Hot Standby), Netzwerkpfad-Redundanz (HSR, PRP oder RSTP mit schneller Umschaltung), Stromversorgung-Redundanz (USV mit Generator-Backup) und die Integrität der Konfigurationssicherung. Kritisch: Testen Sie die Wiederherstellung – eine Sicherung, die nie wiederhergestellt wurde, ist eine Annahme, keine Fähigkeit. NIST SP 800-82 Rev.3 §6.2.7 und IEC 62443-3-3 FR7 erfordern beide getestete Wiederherstellungsfähigkeiten, nicht nur dokumentierte Verfahren.

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

Aufbau einer OT-Erkennungsfähigkeit

Die OT-Bedrohungslandschaft hat sich seit 2017 grundlegend geändert. Der TRITON/TRISIS-Angriff zeigte, dass hochentwickelte Gegner speziell auf sicherheitsinstrumentierte Systeme abzielen — die letzte Linie der Verteidigung, bevor ein physischer Prozess gefährlich wird. PIPEDREAM/INCONTROLLER, offengelegt im Jahr 2022, zeigte ein modulares Angriffs-Framework, das Schneider Electric, OMRON und andere große OT-Plattformen mit nativen ICS-Protokollen ins Visier nimmt. Diese sind keine theoretischen Bedrohungen — sie sind dokumentierte, reale Fähigkeiten, die gegen kritische Infrastrukturen eingesetzt werden.

Die Erkennung in dieser Umgebung erfordert OT-spezifische Fähigkeiten, die IT-Sicherheitstools nicht besitzen. Ein Netzwerk-Eindringungserkennungssystem, das Modbus-Funktionscodes, DNP3-Anwendungsebeneninhalte oder OPC-UA-Dienstoperationen nicht versteht, kann keine böswillige Manipulation von OT-Protokollen erkennen — denn für es sieht der gesamte OT-Verkehr wie Rauschen aus. Protokollbewusste Tiefenpaketinspektion, spezifisch abgestimmt für OT-Umgebungen, ist keine Option für SL2+ Umgebungen.

OT-Vorfallreaktion: Die Schnittstelle zur Prozesssicherheit

Der am meisten unterschätzte Aspekt der OT-Vorfallreaktion ist die Schnittstelle zwischen einem Cyberereignis und einem Prozesssicherheitsereignis. Ein Cyberangriff auf eine DCS zeigt sich nicht wie ein IT-Sicherheitsvorfall — es kann zunächst als unerklärliche Prozessabweichungen, Ventilpositionsdifferenzen oder Instrumentenlesungen erscheinen, die seltsam aussehen. Der TRITON-Angriff wurde erstmals von einem Prozesssteuerungsingenieur bemerkt, der ungewöhnliches SIS-Verhalten sah, nicht von einem Sicherheitsanalysten.

Ihr OT-Vorfallreaktionsplan muss daher enthalten: explizite Auslöser für die Eskalation zum Prozesssicherheits-Notfallreaktionsteam; definierte Rollen für das PSSR (Pre-Startup Safety Review)-Team, wenn das OT-System nach einem Cybervorfall wieder in Betrieb genommen werden muss; und die Befugnis für den Betrieb, ein kompromittiertes System vom Prozesskontrollnetzwerk zu trennen, ohne auf IT/IT-Sicherheitsgenehmigung 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 die Reaktion auf Vorfälle, aber keiner von beiden behandelt detailliert genug die Sicherheits-Cyber-Schnittstelle — Ihr Programm muss diese Lücke durch standortspezifische HAZOP- und Risikobewertungsinputs schließen.

Wiederherstellung: Die vergessene Funktion

IEC 62443-3-3 FR7 und NIST CSF-Wiederherstellungsfunktion erfordern beide getestete, dokumentierte Wiederherstellungsfähigkeit. In OT-Kontexten ist die Wiederherstellung erheblich komplexer als IT-Wiederherstellung, da: OT-Systeme möglicherweise anbieter-spezifische Wiederherstellungsverfahren erfordern; Logikdownloads auf PLCs und DCS-Controllern spezifischen Sequenzen folgen müssen; Prozessneustart nach einem längeren Ausfall sicherheitstechnische Überlegungen (Spülen, Druckprüfungen, Instrumentenüberprüfung) erfordert, die Tage oder Wochen dauern können; und regulatorische Meldepflichten sich auf Cybervorfälle auswirken können, die Prozesssicherheitssysteme betreffen.

Definieren Sie Wiederherstellunsgziele (RTOs) für jede OT-Zone basierend auf der operationellen Toleranz — nicht basierend auf IT-Standards. Eine IT-RTO von 24 Stunden für ein unkritisches System ist in Ordnung; eine OT-RTO von 24 Stunden für ein Pipeline-SCADA-System bedeutet einen Tag blinden Betriebs eines unter Druck stehenden Transportsystems, was nicht akzeptabel ist. Diese RTOs müssen vom Betrieb und der Prozessplanung validiert, nicht von der IT bestimmt werden.

07  Implementierungsplan: Ein realistisches 24-monatiges Programmprojekt

Der Aufbau eines OT-Cybersicherheitsprogramms ist eine mehrjährige Aufgabe. Der folgende Roadmap basiert auf dem Dual-Rahmenansatz und ist um die Realität der OT-Betriebsbeschränkungen strukturiert: Sie können den Betrieb nicht stören, Sie können nicht die Änderungsaufnahmefähigkeit Ihrer Organisation überfordern und Sie können den Wartungfenster-Zyklus nicht ignorieren.

MONATE 1–3 · PHASE 1: GRUNDLAGE

Governance etablieren und Basis-Sichtbarkeit schaffen

Bevor technische Kontrollen eingerichtet werden, benötigen Sie organisatorische Zustimmung, definierte Rollen und ein wirkliches Anlagenbild. Ohne diese ist jede nachfolgende Aktivität auf Sand gebaut.

•  OT-Cybersicherheitsrichtlinie entwerfen und ratifizieren, im Einklang mit IEC 62443-2-1 CSMS-Anforderungen

•  OT-Sicherheitsrollen definieren (OT-Sicherheitsverantwortlicher, Standort-OT-Sicherheitsvertreter, Anbieter-Überwachungsfunktion) und formal in Stellenbeschreibungen oder RACI verankern

• Passive OT-Anlagenerkennung über alle Standorte hinweg einsetzen — das definitive Anlagenregister aufbauen

•  Erste Zonen- und Leitweg-Zuordnung gemäß IEC 62443-3-2 §4.3 durchführen

•  OT-spezifisches Risikoregister-Template im Einklang mit den Konsequenzkategorien von IEC 62443-3-2 und NIST SP 800-82 einrichten

• Aktuelles Erreichtes Sicherheitsniveau (SL-A) gegen IEC 62443-3-3 FR1–FR7 basieren

MONATE 3–6 · PHASE 2: RISIKOBEWERTUNG

Risiko Bewertung abschließen und Zielzustand definieren

Mit geschaffener Sichtbarkeit die formelle Risikobewertung abschließen. Dies ist das wichtigste Ergebnis im gesamten Programm — alles andere folgt daraus.

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

•       Alle SL-Lücken identifizieren und priorisieren (SL-T minus SL-A) — diese werden zu Ihrem Abhilfe-Rückstand

•       NIST SP 800-82 Rev.3 ausgerichtetes Threat Modeling einschließlich ICS-spezifischer Bedrohungsakteure und TTPs durchführen

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

•       Risikoregister in übergeordnetes Risikomanagementframework integrieren; dem höheren Management präsentieren

•       Anbieter-Sicherheitsanforderungen aktualisieren oder entwerfen, im Einklang mit IEC 62443-2-4

MONATE 6–12 · PHASE 3: KERNSCHUTZMASSNAHMEN

Implementierung vorrangiger Schutzmaßnahmen

Kritische und hoch priorisierte Lücken adressieren. Konzentrieren Sie sich zuerst auf die Netzwerkarchitektur (die meisten Effekte im OT-Sicherheit) und auf Zugangskontrolle.

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

• Daten-Dioden auf SIS-zu-DCS-Datenwegen einsetzen, wo SL3 angestrebt wird

• Standardanmeldeinformationen auf allen OT-Geräten eliminieren; rollenbasierte Zugangskontrolle gemäß FR1–FR2 implementieren

• Jump-Server mit Sitzungsaufzeichnung für jeden Fernzugriff auf OT-Zonen einsetzen; MFA beim Fernzugriff durchsetzen

• Medien-Scanning (Shieldworkz Media Scanning Solution oder Ähnliches) für alle Wechselmedien, die in OT-Umgebungen eingeführt werden, implementieren

• OT-Sichtbarkeitsplattform im passiven Überwachungsmodus einsetzen; Triage-Verfahren für Warnalarme einrichten

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

MONATE 12–18 · PHASE 4: DETEKTION & ANTWORTEN REIFEN

Dauerhafte Detektions- und Reaktionsfähigkeit aufbauen

Vom Reaktions- zum Proaktiven bewegen: kontinuierliche Überwachung, Bedrohungsjäger-Fähigkeit und getestete Antwortverfahren.

• OT-SOC-Funktion (intern oder verwaltet) mit OT-spezifischen Erkennungsanwendungsfällen und -playbooks einrichten

• OT-Sichtbarkeitsplattform-Warnungen in das Unternehmens-SIEM mit OT-gerechten Korrelationsregeln integrieren

• OT-Patch-Management-Prozess gemäß IEC 62443-2-3 implementieren: Anbieterkoordinierung, Staging-Umgebungstests, Wartungfensterplanung

• OT-Schwachstellenbewertung über alle kritischen Systeme mit passiven/geringwirkungsvollen Methoden durchführen

•  OT-Business-Continuity- und Disaster-Recovery-Planung abschließen; Wiederherstellung der Konfigurationssicherung testen

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

MONATE 18–24 · PHASE 5: KONTINUIERLICHE VERBESSERUNG

Institutionalisieren, messen und verbessern

Ein Cybersicherheitsprogramm, das sich nicht kontinuierlich verbessert, wird verfallen. Bedrohungen entwickeln sich weiter, Systeme ändern sich, Menschen wechseln. Bauen Sie die Mechanismen auf, die das Programm über den anfänglichen Aufbau hinaus aufrechterhalten.

•       Etablierung eines Quartalsberichts über die OT-Sicherheitsleistung an das höhere Management: KPIs einschließlich Patch-Compliance-Rate, offene Risiko-Positionen, Vorfallmetriken, Schulungsabschluss

•       Integration der OT-Cybersicherheitsprüfung in alle OT-Management-Änderungsprozesse (MOC)

•       Jährliches IEC 62443-3-2-Risikobewertungs-Update; SL-T und Risiko-Register aktualisieren

•       Jährliche OT-Incident-Response-Übung (von Übung zur Ernstprobe eskalieren, wo sicher möglich)

•       Beschaffungsstandard aktualisieren: Alle neuen OT-Beschaffungen erfordern IEC 62443-4-2-Komponenten-SL-Zertifizierung oder gleichwertige Anbieter-SDL-Nachweise

•       Bewertung der Lieferkettensicherheit: Bewertung der wichtigsten OT-Anbieter gegen IEC 62443-2-4-Anforderungen

08  Governance: Der Unterschied zwischen einem Programm und einem Projekt

Technische Kontrollen ohne Governance verfallen. Das OT-Cybersicherheitsprogramm muss durch organisatorische Mechanismen aufrechterhalten werden, die über einzelne Mitarbeiter, Budgetzyklen und Aufmerksamkeitsspannen des Managements hinausgehen. IEC 62443-2-1 definiert das Cyber-Security-Management-System (CSMS) – das organisatorische System, das sicherstellt, dass Cybersicherheit eine kontinuierliche Managementfunktion ist und kein einmaliges Projekt.

Das CSMS sollte OT-spezifisch sein

Einer der häufigsten Governance-Fehler besteht darin, das IT-Sicherheitsrichtliniendokument der Organisation – oder sogar das IT-ISMS (ISO 27001) – direkt auf OT anzuwenden, ohne es anzupassen. IT und OT haben grundlegend unterschiedliche Prioritäten, Risikotoleranzen und betriebliche Einschränkungen. Eine IT-Richtlinie, die MFA für alle Systemzugänge erfordert, ist korrekt und angemessen für IT. Naiv auf OT angewendet, würde sie MFA für einen Bediener vorschreiben, der innerhalb von zwei Sekunden einen Hochprioritätsalarm bestätigen muss, um einen Prozessstörfall zu verhindern – weshalb das OT-CSMS OT-spezifische Kontrollen mit Betriebsbezug definieren muss.

Änderungsmanagement ist eine Sicherheitskontrolle

Jede Änderung an OT-Hardware, Software, Netzwerk-Konfiguration oder Prozess ist ein potenzielles Sicherheitsereignis. Der Management-of-Change (MOC)-Prozess muss einen obligatorischen OT-Cybersicherheitsüberprüfungsschritt beinhalten. Dies bedeutet: bevor eine Änderung in der OT-Umgebung ausgeführt wird, überprüft die OT-Sicherheitsfunktion sie auf Cybersicherheits-Auswirkungen. Neue Anbieteranschlüsse, Firmware-Updates, Netzwerkkonfigurationen, neue Geräte, die dem OT-Netzwerk hinzugefügt werden — alle müssen diesen Schritt passieren. NIST SP 800-82 Rev.3 §6.2.3 und IEC 62443-2-1 §4.2.3 definieren beide das Änderungsmanagement als zentrale Sicherheitsmanagement-Anforderung.

Lieferanten- und Lieferkettensicherheit

In OT-Umgebungen ist die Lieferkette die Angriffsoberfläche. OT-Anbieter, Systemintegratoren und Dienstleister haben routinemäßig Fernzugriff auf die Kunden-OT-Systeme für Fernfehlerdiagnosen, Notfallunterstützung und geplante Wartung. Der SolarWinds-Angriff zeigte im großen Maßstab, was OT-Sicherheitsexperten seit Jahren verstanden haben: Vertraute Anbieteranschlüsse sind vertraute Angriffspfade, wenn die Sicherheitslage des Anbieters unzureichend ist.

IEC 62443-2-4 definiert Sicherheitsanforderungen, die Sie vertraglich an OT-Dienstleister stellen können. Die Mindestanforderungen für jeden Anbieter mit Zugriff auf das OT-Netzwerk: Dokumentierte Sicherheitspraktiken; Verwendung von dedizierter, malwaregescannter Ausrüstung für OT-Arbeiten; nur sitzungsbasierter Zugang (keine dauerhaften Verbindungen); Akzeptanz der Sitzungsaufzeichnung; und Verpflichtungen zur Vorfallmitteilung. Überprüfen Sie diese Anforderungen — sammeln Sie nicht nur unterzeichnete Erklärungen.

Metriken, die einen Sinn ergeben

Die meisten an das Management berichteten OT-Sicherheitsmetriken sind Aktivitätsmetriken: Anzahl geschriebener Richtlinien, Anzahl abgeschlossener Schulungen, Anzahl gescannter Anlagen. Dies messen den Aufwand, nicht die Sicherheit. Die Metriken, die wichtig sind, sind Ergebnismetriken, die sich an Ihrem Risikoregister orientieren:

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

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

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