Wenn Sie eine industrielle Umgebung sichern, haben Sie diese Frage wahrscheinlich in zwei verschiedenen Konferenzräumen gehört: "Sind wir 800-82-konform?" und "Wo stehen wir bei der 62443-Konformität?" Viele Unternehmen behandeln diese als parallele Stränge, indem sie separate Arbeitsstränge aufbauen, die Aufwand verdoppeln, das Personal vor Ort verwirren und Aufmerksamkeit sowie Budget verbrennen. Es muss nicht so sein. 

Das NIST SP 800-82 Rev. 3, das der endgültige Leitfaden der US-Regierung für die OT-Sicherheit darstellt, verweist ausdrücklich auf ISA-62443-2-1 als geeigneten Standard für Cybersicherheitsprogramme in der industriellen Automatisierung und Steuerungssystemen (IACS). Die beiden Rahmenwerke sind so konzipiert, dass sie sich ergänzen und nicht konkurrieren. 800-82 stärkt Ihre Risikomanagement-Architektur und Kontrolle, während IEC 62443 Ihr operatives Sicherheitsprogramm, die Systemdesign-Methodik, gemessene Risikominimierung und technische Anforderungshierarchie bietet. Gemeinsam bilden diese beiden das vertretbarste und auditierbarste OT-Sicherheitsprofil, das Sie aufbauen können.

Der heutige Blogbeitrag bietet Ihnen eine praktische Anleitung zur Kartierung, Sequenzierung und Implementierung, um sie als Teil eines einheitlichen Programms zu nutzen, das auf Ihre einzigartigen Sicherheits- und Konformitätsanforderungen abgestimmt ist.

Bevor wir weitermachen, vergessen Sie nicht, unseren vorherigen Blogbeitrag über den Cybervorfall bei Adidas hier zu überprüfen.

NIST SP 800-82 Rev. 3: Das Handbuch

Veröffentlicht im September 2023, stellt Rev. 3 eine umfassende Überarbeitung der Ausgabe von 2015 dar. Wichtige Änderungen umfassen die erweiterte Abdeckung von IIoT und Cloud-verbundenen OT, engere Ausrichtung an NIST CSF und SP 800-53 Rev. 5, Leitlinien zur Lieferkettensicherheit und einen stärkeren Fokus auf kontinuierliches Monitoring, das auf OT-Einschränkungen abgestimmt ist. Es ist strukturiert um:

• Kategorisierung von OT-Systemen (z.B. Auswirkungen: Niedrig, Moderat, Hoch) basierend auf Vertraulichkeit, Integrität und Verfügbarkeit

• Kontrollüberlagerungen, die SP 800-53 Rev. 5-Kontrollen an OT-Realitäten anpassen, während sie anerkennen, dass Sie einen laufenden Reaktor nicht patchen oder ein sicherheitsinstrumentiertes System mitten im Schichtwechsel neu starten können

• Risikomanagement mit einem dreistufigen Ansatz: Organisationsebene, Missions-/Geschäftsprozessebene und Informations-/OT-Systemebene zur Bereitstellung eines abgestuften Kontrollrahmenwerks

• Architekturleitfäden einschließlich Verteidigung-in-Tiefe und Netzwerkssegmentierung, die vollständig mit dem Purdue-Modell abgestimmt sind und DMZ-Design

Es ist im Wesentlichen ein Leitdokument, das Ihnen sagt, was Sie erreichen sollen. IEC 62443 hingegen sagt Ihnen, wie Sie Ihr Programm strukturieren, um dorthin zu gelangen.

IEC 62443: Die Programmarchitektur

Die IEC 62443-Serie (gemeinsam mit ISA als ANSI/ISA-62443 verwaltet) ist der globale Standard für IACS-Sicherheit. Sie ist in vier Gruppen organisiert:

Die grundlegenden Konzepte des Rahmenwerks sind Sicherheitsstufen (Security Levels, SL) und das Zonen- und Kanäle-Modell.

Sicherheitsstufen reichen von SL 1 bis SL 4:

• SL 1: Schutz gegen zufällige oder versehentliche Fehlanwendung

• SL 2: Schutz gegen absichtlichen Angriff mit einfachen Mitteln, niedriger Motivation

• SL 3: Schutz gegen absichtlichen Angriff mit komplexen Mitteln, moderaten Ressourcen, spezifischem Automatisierungswissen

• SL 4: Schutz gegen staatliche oder gut finanzierte Angreifer mit tiefem spezifischem Automatisierungswissen.

Zonen gruppieren Assets mit ähnlichen Sicherheitsanforderungen und Kritikalität, während Kanäle die kontrollierten Kommunikationswege zwischen Zonen sind. Dieses Modell ist das architektonische Rückgrat von allem in der 62443-Serie und bietet eine differenziertere Kontrolle über Ihre Sicherheitsmaßnahmen.

Eine wichtige Aktualisierung: IEC 62443-2-1:2024 (veröffentlicht im August 2024) hat die Anforderungen der Asset-Eigner in Sicherheitsprogrammelementen (SPEs) umstrukturiert und ein Reifegradmodell eingeführt. Es geht auch explizit auf Altsysteme ein und erkennt an, dass die Lebensdauern von IACS über zwanzig Jahre überschreiten können und dass kompensierende Kontrollen, nicht nur native technische Fähigkeiten, akzeptabel sind, wenn zugrunde liegende Systeme moderne Sicherheitsanforderungen nicht unterstützen können.

Strukturierte Abbildung: Wie IEC 62443 die 800-82-Konformität unterstützt

Die Beziehung besteht nicht auf einer eins-zu-eins-Ebene. Stattdessen ist sie architektonisch. Denken Sie an 800-82 als die Definition der Konformitätsanforderungen und IEC 62443 als das Programm und die technische Maschinerie, um sie zu erfüllen.

800-82 Abschnitt 4: OT-Risikomanagement → IEC 62443-3-2 + 62443-2-1

NIST SP 800-82 Rev. 3 Abschnitt 4 definiert das OT-Risikomanagement mit einem gestuften Ansatz. IEC 62443-3-2 ist das operationalisierte Äquivalent: Es definiert den Prozess zur Sicherheitsrisikobewertung und Systemdesign, erzeugt ein Zonen- und Kanäle-Modell und dokumentierte Ziel-Sicherheitsstufen (TSL) als Outputs, die in eine Cybersicherheitsanforderungsspezifikation (CRS) verpackt werden.

Wie dies in der Praxis auszuführen:

• Nutzen Sie das Risikogerüst von 800-82 (Identifizierung der OT-Systeme, Kategorisierung nach Auswirkungen) als Ausgangspunkt. Dies gibt Ihnen den geschäftlichen und missionsspezifischen Kontext.

• Nutzen Sie 62443-3-2, um die System-spezifische Risikobewertung durchzuführen. Arbeiten Sie mit Ihren Prozesssicherheitsingenieuren zusammen — HAZOP-Dokumentation ist eine Fundgrube für das Verständnis der Konsequenzschwere. Zuordnen von Prozessgefahren zu Cyber-Bedrohungsszenarien (Verlust der Kontrolle, Dienstverweigerung einer Sicherheitsfunktion, unerlaubte Befehlseinspeisung).

• Weisen Sie den Zonen Ziel-Sicherheitsstufen zu, basierend auf den Bedrohungsszenarien und der Konsequenzanalyse. Eine sicherheitsinstrumentierte Systemzone, die einen hochgefährlichen Prozess schützt, sollte SL 2 oder SL 3 anstreben. Ein Unternehmenshistoriker kann SL 1 mit einer Einweg-Daten-Diode als Kanal sein.

• Dokumentieren Sie alles in der CRS. Dies wird Ihr primäres Prüfungsartefakt für die 800-82 Abschnitt 4-Konformität.

Häufiger Fehler: Das Zonen- und Kanäle-Modell als Netzwerkdiagrammübung zu betrachten. Das ist es nicht. Es ist eine Risikoklassifizierungsübung, die die Kontrollauswahl antreibt. Beginnen Sie mit der Konsequenzanalyse, zeichnen Sie dann die Zonen.

800-82 Abschnitt 5: Empfohlene Sicherheitskontrollen: IEC 62443-3-3 + 62443-4-2

800-82 Abschnitt 5 verweist auf die SP 800-53 Rev. 5-Kontrollfamilien und bietet OT-spezifische Überlagerungen. IEC 62443-3-3 bietet 110 grundlegende Anforderungen (FRs), organisiert in sieben Kategorien — Zugriffskontrolle (IAC), Nutzungskontrolle (UC), Systemintegrität (SI), Datenvertraulichkeit (DC), eingeschränkter Datenfluss (RDF), zeitnahe Reaktion auf Ereignisse (TRE) und Ressourcenverfügbarkeit (RA) — jede verbunden mit spezifischen Sicherheitsstufenanforderungen.

Die Abbildung zwischen diesen beiden ist eines der nützlichsten Werkzeuge, die einem OT-Sicherheitspraktiker zur Verfügung stehen. Zum Beispiel:

Zugriffskontrolle (800-82/800-53 AC-Familie). IEC 62443-3-3 IAC/UC-Anforderungen:

• 800-82 erfordert Zugriffsberechtigung mit minimalen Privilegien und Mehrfaktorauthentifizierung für Remotezugriff. 62443-3-3 bei SL 2 erfordert die Identifikation und Authentifizierung menschlicher Benutzer und bei SL 3 Mehrfaktor für alle Konten — was Ihnen eine testbare technische Schwelle gibt.

• Wenn Ihr OT-Anbieter argumentiert, dass MFA "nicht gemacht werden kann" auf einem Legacy-HMI, erlaubt IEC 62443-2-1:2024 ausdrücklich kompensierende Kontrollen. Dokumentieren Sie die kompensierende Kontrolle, das akzeptierte Restrisiko und die kompensierenden Maßnahmen (separates Sprung-Host mit MFA, Sitzungsaufzeichnung, zeitlich begrenzte Zugriffsfenster). Das ist Ihre Prüfungsverteidigung.

Systemintegrität (800-82 SI-Familie): IEC 62443-3-3 SI-Anforderungen:

• 800-82 erfordert Malware-Schutz, Software-Integritätsprüfung und Sicherheitswarnungen. 62443-3-3 SI-Anforderungen bei SL 2 umfassen Schutz gegen bösartigen Code, Verhinderung nicht autorisierter Änderungen und Berichterstattung über Integritätsverletzungen.

• Implementierung: Whitelist-basierter Endpunktschutz (nicht traditionelle AV) auf HMIs und Ingenieursarbeitsplätzen; Nur-Lese-Medienkontrollen; Firmware-Prüfung, sofern vom Controller-Hersteller unterstützt.

Prüfung und Rechenschaftspflicht (800-82 AU-Familie) und IEC 62443-3-3 TRE-Anforderungen:

• Beide Rahmenwerke erfordern Protokollierung, Prüfpfade und die Fähigkeit zur Erkennung von Sicherheitsereignissen. In OT bedeutet dies die Bereitstellung passiver Netzwerküberwachung, die ICS-Protokolle wie Modbus, DNP3, EtherNet/IP, PROFINET, IEC 61850 versteht, ohne aktiven Verkehr zu injizieren, der deterministische Kontrollschleifen stören kann. Jedes Monitoring-Tool, das aktiv OT-Geräte abfragt, hat keinen Platz innerhalb Ihrer Kontrollzone.

800-82 Abschnitt 6: Netzwerkarchitektur und Verteidigung-in-Tiefe: IEC 62443 Zonen/Kanäle-Modell

NIST 800-82 Rev. 3 befürwortet eine Architektur der Verteidigung-in-Tiefe, basierend auf dem Purdue-Modell und erkennt moderne Anpassungen für Cloud-Konnektivität und IIoT an. IEC 62443's Zonen- und Kanäle-Modell ist das Implementierungsrahmenwerk.

Lassen Sie uns dies nun in eine konkrete Architektur umsetzen:

• Level 0-1 (Feldgeräte wie Sensoren, Aktuatoren, PLCs): Keine routbaren IP-Protokolle, wenn vermeidbar. Anwenden von Hersteller-Härtungsrichtlinien, alle Standardanmeldeinformationen ändern, deaktivieren nicht genutzter Kommunikationsports und -dienste. Diese Geräte können typischerweise nicht in einem normalen Zyklus gepatcht werden; berücksichtigen Sie dies in Ihrem Risikoregister und kompensierenden Kontrollen.

• Level 2 (Kontrolle/HMI): Mikrosegmentierung nach Prozesslinie oder Zelle, wo möglich. Anwendung von Applikations-Whitelist. Ingenieursarbeitsplätze sollten niemals Internetzugang haben. Abnehmbare Medienkontrollen sind unerlässlich. Viele von uns erinnern sich vielleicht daran, dass der Stuxnet-Angriff im Jahr 2010 über USB verbreitet wurde.

• Level 3 (Standortoperationen/MES): Aggressive Filterung des Nord-Süd-Verkehrs. Historiker sollten Daten nach oben durch einseitige Durchsetzung schieben, wo möglich; niemals ein Ziehen von Level 4 in Level 3 erlauben. Dies ist eine Entwurfsentscheidung eines Kanals, nicht nur eine Firewall-Regel.

• DMZ (IT/OT-Grenze): Verkehr, der die IT/OT-Grenze überschreitet, muss die DMZ durchqueren. Sprung-Hosts für Fernzugriff, Patch-Bereitstellungsserver, AV-Update-Server und Datenaggregationsdienste befinden sich hier. Direkte Verbindungen zwischen Level 4 IT und Level 2 Kontrollsystemen niemals zulassen.

• Level 4/5 (Unternehmens-IT, Cloud): SIEM, SOAR, Identitätsprovider und Datenlakes sind hier untergebracht. OT-Identitäten sollten erstklassige Bürger in Ihrer Identitätsinfrastruktur sein und nicht ein nachträglicher Gedanke, der durch ein gemeinsam genutztes lokales Admin-Konto verwaltet wird.

800-82 Management von Lieferkettenrisiken: IEC 62443-2-4

800-82 Rev. 3 widmet erhebliche Aufmerksamkeit der Sicherheit der Lieferkette — eine bedeutende Verbesserung gegenüber Rev. 2. IEC 62443-2-4 (Sicherheitsprogrammanforderungen für IACS-Dienstanbieter) ist das entsprechende Instrument. Nutzen Sie es, um:

• Definieren vertragliche Sicherheitsanforderungen für Systemintegratoren, OEM-Remotezugriff-Anbieter und IACS-Dienstanbieter

• Erfordernis eines Nachweises der 62443-2-4-Konformität in Anbieter-Verträgen

• Verpflichten Anbieter zur Nutzung dedizierter Sprung-Hosts anstelle direkter Verbindungen zum Kontrollsystem

• Anforderung der Sitzungserfassung für alle Drittanbieter-Fernzugriffe — dies ist Ihre Lebensader für die Vorfalluntersuchung, wenn eine Anbieter-Verbindung zu einem Bedrohungsvektor wird

Die unbequeme Wahrheit über den Zugriff von Anbietern: Die Mehrheit der OT-Sicherheitsvorfälle beinhaltet eine Drittanbieter-Verbindung wie direkte VPN zu einem PLC, ungesicherte Mobilfunkmodems, die von einem Kühllieferanten installiert wurden, oder der Laptop eines Integrators mit veralteten Anmeldedaten. IEC 62443-2-4 gibt Ihnen die vertragliche und programmatische Autorität, dies zu adressieren.

800-82 Vorfallreaktion und -wiederherstellung: IEC 62443-2-3 + 62443-2-4

800-82 Abschnitt 4.5 behandelt die OT-Vorfallreaktion mit wichtigen OT-spezifischen Überlegungen: Priorität von Sicherheit, Aufrechterhaltung der physischen Prozesskontinuität und die Realität, dass Sie fortfahren müssen, ein teilweise kompromittiertes System zu betreiben, weil die Alternative — das Herunterfahren — schlimmere Sicherheitsfolgen als ein eingrenzendes Cyberereignis hat.

IEC 62443-2-3 (Patch-Management in der IACS-Umgebung) und die Vorfallmanagement-Elemente von 62443-2-4 bieten das operative Verfahrenrahmenwerk.

Praktische Umsetzung:

• Ihr OT-Vorfallreaktionsplan ist nicht Ihr IT-Bereitschaftsplan mit "OT" oben eingefügt. Schreiben Sie separate Handbücher für jede wichtige Assetklasse: PLC-Kompromittierung, Historiker-Ransomware, HMI-Malware, unerlaubter Zugang zu Ingenieursarbeitsplätzen.

• Definieren Sie Ihren Eskalationspfad, der Prozesssicherheitsingenieure einbezieht, nicht nur IT-Sicherheit. Das OT-Sicherheitsteam nimmt niemals ein laufendes System einseitig offline — das ist eine gemeinsame Entscheidung mit den Betriebsleitern und Sicherheitstechnikern.

• Führen Sie Planspiele mit Personal auf der Werksetage durch, nicht nur mit IT-Mitarbeitern. Ihre Wartungstechniker sind Ihre Ersthelfer bei einem echten Zwischenfall.

• Dokumentieren Sie manuelle Fallback-Prozeduren. Wenn Ihr OT-Netzwerk aufgrund eines Vorfalls isoliert wird, können Ihre Bediener den Prozess manuell betreiben? Wenn nicht, ist das eine Resilienzlücke, die adressiert werden muss, bevor ein Vorfall die Frage erzwingt.

 Implementierungssequenzierung: Wo zu beginnen?

Die meisten Organisationen versuchen, alles auf einmal zu machen und erreichen nichts gründlich. Hier ist eine Sequenzierung, die wiedergibt, wie Risikominderung tatsächlich zusammenkommt:

Phase 1: Wissen, was Sie haben (Monate 1-3)

Durchführen passiver Asset-Erkennung über Ihr OT-Netzwerk. Keine aktiven Scantools in einer Produktions-OT-Umgebung ohne Anbieter-spezifische Genehmigung und Tests in einer Replikumgebung einsetzen. Tools wie Claroty, Dragos, Nozomi Networks und Microsoft Defender für IoT sind für passive OT-Erkennung konzipiert. Ausgabe: Eine Asset-Inventarliste, die nach Zonen, Kritikalität und Unterstützung (unterstützt vs. abgelaufen vs. unsupported) markiert ist. Dies speist sowohl 800-82 Abschnitt 4 (Systeminventar) als auch 62443-3-2 (Input für Zonendesign und Risikobewertung).

Phase 2: Segmentieren und schützen, was am meisten zählt (Monate 2-6)

Basierend auf Ihrer Risikobewertung und dem Zonen-/Kanäle-Modell implementieren Sie Ihre Netzwerkssegmentierung. Beginnen Sie mit der IT/OT-Grenze — der DMZ, wenn Sie keine haben, oder stärkern die, die Sie haben. Flat-OT-Netzwerke beseitigen. Anwenden der Kanalsteuerungen zwischen Ihren Zonen mit den höchsten Konsequenzen zuerst. Dadurch wird die größte Angriffsfeldreduzierung am schnellsten erreicht.

Phase 3: Identität und Zugangs-Hygiene (Monate 3-6)

Gemeinsame Konten eliminieren, insbesondere auf HMIs und Ingenieursarbeitsplätzen. Implementierung rollenbasierter Zugriffskontrolle. Bereitstellung einer sicheren Remotezugangslösung (Sprung-Host + MFA + Sitzungsaufzeichnung) und Schließen direkten VPN-Zugriffs auf OT-Geräte. Erfordernis der Verwendung durch Ihre Anbieter. Implementieren des privilegierten Zugangsmanagements für Ingenieursanmeldedaten.

Phase 4: Sichtbarkeit und Erkennung (Monate 5-9)

Bereitstellung OT-bewusster passiver Überwachung. Baseline normales industrielles Protokollverhalten und alarmieren bei Abweichungen wie unerwarteten Funktionscodes, neuen Geräten, die im Netzwerk erscheinen, anomalen Traffic zu Level 3/4. Ereignisse an Ihr SIEM weiterleiten. Erstellen Sie OT-spezifische Erkennungsregeln; IT-Sicherheitsexperten werden nicht wissen, dass ein Modbus-Schreibvorgang an eine unerwartete Registeradresse anormal ist, ohne Anleitung.

Phase 5: Programmreife (Fortlaufend)

Patch-Management gemäß 62443-2-3 (risikobasiert, getestet in einer Staging-Umgebung, koordiniert mit dem Betriebsplan), kontinuierliches Monitoring, Bereitstellungsübungen für Vorfallreaktionen, Vollstreckung von Anbieterkonformität und jährliche Aktualisierungen der Risikobewertung unter Verwendung von 62443-3-2 als Methodik.

Compliance-Demonstration: Der Prüfungsbeweisstapel

Wenn ein Regulierer, Kunde oder eine interne Prüfung Sie auffordert, 800-82-Konformität zu demonstrieren, ist hier, was Sie produzieren — und welches 62443-Artefakt es erzeugt:

Wo Organisationen oft scheitern

In über einem Jahrzehnt OT-Sicherheitspraxis erscheinen die gleichen Versagensmodi wiederholt. Seien Sie sich dieser bewusst:

IT-Sicherheitstermine auf OT-Patch-Management anwenden. Ein kritisches Patch auf einem Windows-basierten HMI wird nicht in 30 Tagen angewendet, wenn der HMI-Anbieter das Patch nicht validiert hat, Sie einen 24/7-Produktionsplan haben und das nächste geplante Wartungsfenster in sechs Monaten ist. IEC 62443-2-3 adressiert dies explizit mit einem risikobasierten Patch-Management-Ansatz — die Exploitierbarkeit und Auswirkungen der ungepatchten Schwachstelle bewerten, kompensierende Kontrollen implementieren (Netzwerkisolierung, Monitoring, temporäre Zugangsbeschränkungen) und das akzeptierte Risiko dokumentieren, bis das Patch sicher angewendet werden kann.

Segmentierung nur auf dem Papier. Ein Zonen- und Kanäle-Diagramm, das nicht der tatsächlichen Netzwerk-Konfiguration entspricht, ist schlimmer als kein Diagramm — es schafft falsche Sicherheit. Überprüfen Sie Ihre Segmentierung mit periodischen Netzwerkbewertungen und passiver Verkehrsanalyse. Ihr Überwachungstool wird Ihnen sagen, ob dieser Historiker tatsächlich nur mit Level 3 spricht oder ob jemand letzten Monat eine direkte Verbindung zu einem Ingenieursarbeitsplatz geöffnet hat.

Die menschliche Ebene ignorieren. IEC 62443-2-1:2024 umfasst Sicherheitspromotionselemente für Sicherheitsbewusstsein, Schulung und organisatorische Rollen. 800-82 Abschnitt 4 behandelt ebenfalls Sicherheitsbewusstsein. Ihre Wartungstechniker, die unerlaubte USB-Laufwerke anschließen, Ihre Bediener, die Remote-Desktop-Zugriff an Anbieter ohne Protokollierung geben, Ihr Ingenieurteam, das dasselbe Passwort für alle PLCs verwendet — dies sind keine technischen Ausfälle. Sie sind Programmausfälle. Sicherheitsbewusstsein und Durchsetzung von Verfahren sind Kontrollen, nicht nur nette Zusatzoptionen.

Altsysteme als Konformitätsausnahmen behandeln, die ignoriert werden sollen. Legacy-IACS werden ausdrücklich in 62443-2-1:2024 adressiert — sie erfordern kompensierende Kontrollen, dokumentiertes Restrisiko und einen Fahrplan. Ein undokumentierter Legacy-PLC, der auf einem nicht unterstützten Betriebssystem läuft ohne kompensierende Kontrollen, ist eine offene Feststellung. Ein Legacy-PLC mit Netzwerkisolierung, Protokollfilterung bei der Leitung, 24/7 passiver Überwachung und einer geplanten Ersetzung im Kapitalbudget ist ein verwaltetes Risiko. Die Dokumentation macht den Unterschied.

Ein strategischer Fall: Warum Programme mit doppeltem Rahmenwerk gewinnen

Regulierte Sektoren wie Energie (NERC CIP-Adjunkt), Verteidigungsindustrie (CMMC), Chemie (CISA Chemiefabrik-Anforderungen), Wasser (America's Water Infrastructure Act) beziehen zunehmend sowohl NIST SP 800-82 als auch IEC 62443 in regulatorische Leitlinien und kundenbezogene Sicherheitsanforderungen ein. Ihr Programm gleichzeitig auf beiden Rahmenwerken aufbauen ist kein Konformitätsaufwand, sondern Versicherung gegen zukünftige regulatorische Verschiebungen, ein Wettbewerbsvorteil in Kunden Sicherheitsbewertungen und eine technisch fundiertere Sicherheitsarchitektur als die, die entweder Rahmenwerk allein bietet.

Die praktische Formel ist: Verwenden Sie IEC 62443 zur Programmstruktur und Governance, verwenden Sie NIST 800-82 zur Kontrollenwahl und Überlagerung und verwenden Sie NIST CSF 2.0's Governance-Funktion, um unternehmerische Sichtbarkeit und Verantwortung über das gesamte Programm zu schaffen.

Organisationen, die sich auf dieser integrierten Grundlage aufgebaut haben, übertreffen konsequent ihre Kollegen sowohl bei Prüfungsergebnissen als auch bei tatsächlichen Vorfallreaktionsmetriken, weil ihr Sicherheitsprogramm wiedergibt, wie industrielle Systeme tatsächlich funktionieren, nicht wie IT-Systeme funktionieren mit OT-Terminologie ergänzt.

Kontaktieren Sie uns, um mehr über die Compliance mit IEC 62443 und NIST SP 800-82 durch einen einheitlichen Ansatz zu erfahren.

Wichtige Ressourcen

• NIST SP 800-82 Rev. 3, Leitfaden für Operational Technology (OT) Sicherheit — September 2023

• ISA/IEC 62443 Schnellstart-Leitfaden — ISA

• CISA-Katalog der bekannten ausgenutzten Schwachstellen — zur Priorisierung von Patch-Aufgaben gemäß NIST SP 800-40 Rev. 4-Leitlinien

• Strategische Umsetzung von ISA/IEC 62443-3-2 

• NIST SP 800-82 Rev. 3: Strategische Prüfungs-Checkliste