Hero BG

IEC 62443 - Praktischer Leitfaden für OT/ICS- und IIoT-Sicherheit

Inhaltsverzeichnis

Was ist IEC 62443 - auf einen Blick

Warum IEC 62443 für OT, ICS und IIoT entscheidend ist

Struktur: die vier Teile der 62443-Familie

Sicherheitsstufen und grundlegende Anforderungen – wie man darüber nachdenkt

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

Aktuelle und wichtige Updates, die Sie kennen müssen (2023-2025)

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

Praktischer Fahrplan: Wie man 62443 implementiert

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

Typische Fallstricke, Fehlinterpretationen und wie Sie diese vermeiden können

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

Shieldworkz IEC 62443 Dienstleistungsportfolio - auf die Normteile abgebildet

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

Ergebnisse, kommerzieller Wert und KPIs

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

Checkliste: ein taktischer „Erste 90 Tage“-Plan für Anlagenbesitzer

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

Nächste Schritte - Vereinbaren Sie ein kostenloses Beratungsgespräch / eine Demo mit Shieldworkz

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

FAQ, kurze Antworten auf häufig gestellte Fragen

Wer fällt in den Anwendungsbereich (wesentliche vs. wichtige Einheiten, Größenbeschränkung, grenzüberschreitende Reichweite)

1. Was ist IEC 62443 - im Überblick

IEC 62443 (häufig als ISA/IEC 62443 bezeichnet) ist eine modulare, lebenszyklusorientierte Familie internationaler Normen, die entwickelt wurde, um industrielle Automatisierungs- und Steuerungssysteme (IACS) abzusichern. Sie umfasst Governance (Sicherheitsprogramme), Systemdesign auf Systemebene (Zonen & Verbindungen, risikobasierte SL-Ziele), Produkt-/Komponentenanforderungen (sichere Entwicklung) sowie Verifikation und Konformität. Anstatt eine einzelne Technologie vorzuschreiben, bietet 62443 Teams ein wiederholbares Engineering- und Managementmodell zur Reduzierung operationeller Risiken und zum Schutz von Sicherheit, Verfügbarkeit und Integrität in OT-Umgebungen.

OT-Sicherheit oder Sicherheit von Betriebstechnologien ist die Praxis, kritische Infrastrukturen und industrielle Systeme vor Cyberbedrohungen zu schützen. Zu diesen Systemen gehören alles von Stromnetzen und Wasseraufbereitungsanlagen bis hin zu Produktionsstätten und Verkehrsinfrastrukturen, die das Rückgrat der modernen Gesellschaft bilden. Im Gegensatz zu traditionellen IT-Systemen sind OT-Systeme darauf ausgelegt, physische Prozesse zu steuern, und operieren oft in Echtzeit, was sie sowohl einzigartig als auch äußerst anfällig für Cyberangriffe macht.

2. Warum IEC 62443 für OT, ICS und IIoT wichtig ist – Risiken und geschäftliche Treiber

Industrielle Umgebungen sind keine „IT-Netzwerke mit schicken PLCs“ – sie sind sicherheitskritische, langlebige Ingenieurökosysteme mit Einschränkungen (legacy Controllers, deterministische Kommunikation, strenge Betriebszeit und Änderungssteuerung). Angriffe auf industrielle Systeme führen zu physischen Konsequenzen: Produktionsverluste, Umweltschäden, behördliche Bußgelder und Sicherheitsvorfälle.

Betriebliche Widerstandsfähigkeit: Reduzieren Sie ungeplante Ausfallzeiten und schützen Sie Sicherheitssysteme.

Regulatorische & Kundenvertrauen: Viele Regulierungsbehörden, Eigentümer und Lieferketten erwarten eine 62443-Ausrichtung.

Beschaffung & Lieferantensicherung: Nutzen Sie ein einziges Framework zur Bewertung von OT-Produkten und Integratoren.

Risiko-basierte Investition: 62443 ordnet Risiken spezifischen technischen Anforderungen zu und hilft, Ausgaben zu priorisieren.

IEC 62443 matters to OT/ICS

Shieldworkz IEC 62443

OT Systems is Critical

3. Struktur - die vier Teile der 62443-Familie

62443 ist absichtlich modular aufgebaut, damit verschiedene Interessengruppen parallel arbeiten können.

Teil 1 - Allgemeines (Konzepte & Modelle)
Definiert Terminologie, die sieben grundlegenden Anforderungen (FRs) und die übergeordneten Modelle, die in der Reihe verwendet werden (z. B. Zonen & Kanäle). Hier lernen Sie die Sprache von 62443, damit Teams auf die gleiche Weise sprechen.

Teil 2 - Richtlinien & Verfahren (CSMS für Asset-Eigentümer und Dienstleister)
Konzentriert sich auf die Governance. Es schreibt das Cybersecurity Management System (CSMS) für Asset-Eigentümer und die Prozessanforderungen für Dienstleister vor. Teil 2-1 (Sicherheitsprogramm des Asset-Eigentümers) und Teil 2-4 (Anforderungen an Dienstleister) sind Eckpfeiler für die programmatische Compliance. Neueste Ausgaben der Teil 2-Dokumente haben die Erwartungen an Governance, Lieferkette und Lebenszyklusaktivitäten verschärft.

Teil 3 - Systemanforderungen (Risikoanalyse, Zonen-/Kanaldesign, SL-Ziele)
Teil 3-2 definiert, wie eine Risikoanalyse durchzuführen ist, Systeme in Zonen/Kanäle zu unterteilen und für jede Zone Sicherheitsstufen (SL-T) festzulegen. Teil 3-3 bietet detaillierte Systemanforderungen an die Sicherheit, die zu den sieben grundlegenden Anforderungen passen.

Teil 4 - Komponenten- & Produktanforderungen (Secure SDLC & technische Kontrollen)
Teil 4-1 definiert sichere Entwicklungslebenszyklus (SDL)-Praktiken für Produktanbieter; 4-2 legt die technischen Sicherheitsanforderungen für Komponenten (Gerät/Firmware/Software) fest. Drittanbieter-Konformitätsprogramme (z. B. ISASecure CSA) bieten praktische und prüfbare Wege, um nachzuweisen, dass ein Produkt die 4-2-Anforderungen erfüllt.

OT Systems is Critical

4. Sicherheitsstufen & Grundlegende Anforderungen - wie man darüber nachdenkt

Die IEC 62443 führt das Konzept der Security Levels (SL) ein, die Ihnen helfen, Risiken in technische Ziele umzusetzen. 

Sicherheitsstufen (SL 0 → SL 4)

Es gibt fünf definierte SLs (SL-0 bis SL-4). Jeder SL gibt die Fähigkeit des Gegners an, gegen den das System verteidigen muss - ausgedrückt durch Mittel, Ressourcen, Fähigkeiten und Motivation. Praktisch fungieren SLs als Allokationsziele: Je höher der SL, desto stärker sind die erforderlichen technischen Kontrollen. Bei korrekter Anwendung ist die Auswahl des SLs eine entscheidungsgetriebene Entscheidung basierend auf Konsequenzen und Auswirkungen, nicht nur eine „Wer ist der Angreifer“-Übung.

Die sieben grundlegenden Anforderungen (FRs)
Im gesamten Standard 62443 fasst die technische Kontrollen in sieben grundlegende Anforderungen zusammen:

Identifikations- & Authentifizierungskontrolle

Verwenden Sie Kontrolle (Authorization)

Systemintegrität

Datenvertraulichkeit

Eingeschränkte Datenfluss (Segmentierung)

Zeitnahe Reaktion auf Ereignisse (Überwachung & IR)

Ressourcenverfügbarkeit (Widerstandsfähigkeit & Redundanz)

Diese FRs sind die Bausteine für technische Anforderungen auf Komponenten- und Systemebene. Ihr Ziel-SL bestimmt, wie jedes FR in Steuerungen, Überprüfungs- und Betriebsprozessen umgesetzt wird.

OT Systems is Critical

5. Aktuelle und wichtige Updates, die Sie kennen müssen

62443 wird aktiv gepflegt - der Ausschuss veröffentlicht Aktualisierungen und neue Ausgaben, die programmatische und technische Erwartungen ändern. Einige praktische, aktuelle Highlights:

IEC/ISA 62443 als „horizontaler“ Standard eingestuft (Nov 2021): Diese formale IEC-Einstufung erweiterte die Rolle von 62443 als zentrale, technologieunabhängige Referenz für Cybersicherheit in verschiedenen Branchen. Diese Entscheidung machte 62443 zu einer bevorzugten Grundlage für viele sektorspezifische Standards und Regulierungsbehörden.

Teil 2-1 aktualisiert in 2024 (IEC 62443-2-1:2024): Die Sicherheitsprogramm-Anforderungen des Asset-Besitzers wurden überarbeitet und neu herausgegeben, um die Erwartungen an das Cyber-Sicherheitsmanagementsystem (CSMS) besser an moderne Lieferketten- und Organisationskontrollen anzupassen. Die Ausgabe von 2024 ist die aktuelle Grundlage für Asset-Besitzer, die ein CSMS entwerfen.

Teil 2 (Dienstleister) konsolidiert/aktualisiert (2023): IEC 62443-2:2023 konsolidiert und klärt die Sicherheitsprogramm-Anforderungen, die für Dienstleister gelten - ein wichtiges Update, das die Erwartungen an Auftragnehmer, Integratoren und Support-Anbieter erhöht.

Produktsicherheit und Drittanbieterprüfung (ISASecure & CSA): Zertifizierungspfade auf Produktebene wie die Common Security Assessment (CSA) von ISASecure entsprechen direkt den 4-2 Anforderungen - was es den Beschaffungsteams ermöglicht, zertifizierte Produkte anzufordern und Verifizierungszyklen zu verkürzen.

Was das für Sie bedeutet: Die Standards entwickeln sich weiter und erfordern eine stärkere Governance und Lieferantenzusicherung. Wenn Sie vor fünf Jahren die Norm 62443 umgesetzt haben, müssen Sie heute Governance, Lieferantenverträge und Produktbeschaffungs-Checklisten neu abgleichen.

OT Systems is Critical

6. Praktischer Fahrplan - Wie man IEC 62443 implementiert

Nachstehend finden Sie ein pragmatisches, ausführbares Programm für Anlagenbesitzer und -betreiber. Jede Phase hat klare Ergebnisse, die sowohl für die Beschaffung als auch für einen Drittpartner wie Shieldworkz nützlich sind.

Phase 0 - Managementsynchronisation (0-2 Wochen)
Ziel: Sponsoring sichern, Rollen zuweisen, Umfang definieren.
Ergebnisse: Managementzusammenfassung, Charta, Projekt-Sponsoren, anfängliche Risikotoleranzerklärung, priorisierte Vermögensliste.

Phase 1 - Entdeckung & Lückenbewertung (2-6 Wochen)
Ziel: Grundlinie der Reife gegenüber 62443 (Steuerungen, Richtlinien, Netzwerkpläne).
Ergebnisse: Anlageninventar, Netzwerk-/Segmentplan (logisch + physisch), Kontrollreife-Matrix (schnelle Scorecard), priorisiertes Lückenregister, das den Teilen und SLs von 62443 zugeordnet ist.

Phase 2 - CSMS-Entwurf & Richtlinien (4-8 Wochen)
Ziel: Das Programm entwickeln, das über Jahre hinweg Bestand haben wird; Zuordnung zu 62443-2-1.
Ergebnisse: CSMS-Blaupause, Governance & Rollen, Lieferanten-sicherheitsrichtlinie, Richtlinie für sicheren Fernzugriff, Patch-Management-Richtlinie (abgestimmt auf 62443-2-3-Leitlinie).

Phase 3 - Risikoanalyse, Zonierung & Zuweisung von SL-Zielen (3-8 Wochen)
Ziel: Ihr System in Zonen und Leitungen unterteilen und SL-T-Ziele zuweisen.
Ergebnisse: Schema der Zonen & Leitungen, SL-T-Matrix pro Zone/Leitung, priorisierter Migrationsplan, verbunden mit den geschäftlichen Konsequenzen.

Hinweis: Wählen Sie SL-Ziele basierend auf den Konsequenzen (Sicherheit, Produktion, langanhaltende Ressourcen), nicht nur auf der Raffinesse der Angreifer.

Phase 4 - Technisches Design & Behebung (variabel)
Ziel: Implementierung von Kontrollen zur Erreichung von SL-T (Netzwerksegmentierung, Gerätehärtung, Authentifizierung, Überwachung).
Ergebnisse: Segmentierungsregeln, Firewall-Richtlinien, Implementierung von Identität und Zugriff, sichere Konfigurationsbasis für Geräte, sichere Netzwerkarchitektur.

Phase 5 - Verifikation, Produktsicherung & sicherer SDLC (laufend)
Ziel: Sicherstellen, dass die Kontrollen die technischen Anforderungen (3-3 / 4-2) durch Tests und Lieferantennachweise erfüllen.
Ergebnisse: Testpläne, Nachweise für die Einhaltung, Berichte zur Produktsicherung von Anbietern (z. B. ISASecure CSA), sicherheitsgerechte Entwicklungsnachweise von Lieferanten (4-1).

Phase 6 - Betrieb, Überwachung & kontinuierliche Verbesserung (kontinuierlich)
Ziel: CSMS betreiben, auf Abweichungen überwachen, regelmäßige Bewertungen durchführen und bei Bedarf SLs neu zuweisen.
Ergebnisse: kontinuierliche Überwachung, Incident-Response-Playbooks, jährliche CSMS-Überprüfung, Lieferanten-Neubewertungen.

Shieldworkz IEC 62443

OT Systems is Critical

3. Struktur - die vier Teile der 62443-Familie

62443 ist absichtlich modular aufgebaut, damit verschiedene Interessengruppen parallel arbeiten können.

Teil 1 - Allgemeines (Konzepte & Modelle)
Definiert Terminologie, die sieben grundlegenden Anforderungen (FRs) und die übergeordneten Modelle, die in der Reihe verwendet werden (z. B. Zonen & Kanäle). Hier lernen Sie die Sprache von 62443, damit Teams auf die gleiche Weise sprechen.

Teil 2 - Richtlinien & Verfahren (CSMS für Asset-Eigentümer und Dienstleister)
Konzentriert sich auf die Governance. Es schreibt das Cybersecurity Management System (CSMS) für Asset-Eigentümer und die Prozessanforderungen für Dienstleister vor. Teil 2-1 (Sicherheitsprogramm des Asset-Eigentümers) und Teil 2-4 (Anforderungen an Dienstleister) sind Eckpfeiler für die programmatische Compliance. Neueste Ausgaben der Teil 2-Dokumente haben die Erwartungen an Governance, Lieferkette und Lebenszyklusaktivitäten verschärft.

Teil 3 - Systemanforderungen (Risikoanalyse, Zonen-/Kanaldesign, SL-Ziele)
Teil 3-2 definiert, wie eine Risikoanalyse durchzuführen ist, Systeme in Zonen/Kanäle zu unterteilen und für jede Zone Sicherheitsstufen (SL-T) festzulegen. Teil 3-3 bietet detaillierte Systemanforderungen an die Sicherheit, die zu den sieben grundlegenden Anforderungen passen.

Teil 4 - Komponenten- & Produktanforderungen (Secure SDLC & technische Kontrollen)
Teil 4-1 definiert sichere Entwicklungslebenszyklus (SDL)-Praktiken für Produktanbieter; 4-2 legt die technischen Sicherheitsanforderungen für Komponenten (Gerät/Firmware/Software) fest. Drittanbieter-Konformitätsprogramme (z. B. ISASecure CSA) bieten praktische und prüfbare Wege, um nachzuweisen, dass ein Produkt die 4-2-Anforderungen erfüllt.

OT Systems is Critical

4. Sicherheitsstufen & Grundlegende Anforderungen - wie man darüber nachdenkt

Die IEC 62443 führt das Konzept der Security Levels (SL) ein, die Ihnen helfen, Risiken in technische Ziele umzusetzen. 

Sicherheitsstufen (SL 0 → SL 4)

Es gibt fünf definierte SLs (SL-0 bis SL-4). Jeder SL gibt die Fähigkeit des Gegners an, gegen den das System verteidigen muss - ausgedrückt durch Mittel, Ressourcen, Fähigkeiten und Motivation. Praktisch fungieren SLs als Allokationsziele: Je höher der SL, desto stärker sind die erforderlichen technischen Kontrollen. Bei korrekter Anwendung ist die Auswahl des SLs eine entscheidungsgetriebene Entscheidung basierend auf Konsequenzen und Auswirkungen, nicht nur eine „Wer ist der Angreifer“-Übung.

Die sieben grundlegenden Anforderungen (FRs)
Im gesamten Standard 62443 fasst die technische Kontrollen in sieben grundlegende Anforderungen zusammen:

Identifikations- & Authentifizierungskontrolle

Verwenden Sie Kontrolle (Authorization)

Systemintegrität

Datenvertraulichkeit

Eingeschränkte Datenfluss (Segmentierung)

Zeitnahe Reaktion auf Ereignisse (Überwachung & IR)

Ressourcenverfügbarkeit (Widerstandsfähigkeit & Redundanz)

Diese FRs sind die Bausteine für technische Anforderungen auf Komponenten- und Systemebene. Ihr Ziel-SL bestimmt, wie jedes FR in Steuerungen, Überprüfungs- und Betriebsprozessen umgesetzt wird.

OT Systems is Critical

5. Aktuelle und wichtige Updates, die Sie kennen müssen

62443 wird aktiv gepflegt - der Ausschuss veröffentlicht Aktualisierungen und neue Ausgaben, die programmatische und technische Erwartungen ändern. Einige praktische, aktuelle Highlights:

IEC/ISA 62443 als „horizontaler“ Standard eingestuft (Nov 2021): Diese formale IEC-Einstufung erweiterte die Rolle von 62443 als zentrale, technologieunabhängige Referenz für Cybersicherheit in verschiedenen Branchen. Diese Entscheidung machte 62443 zu einer bevorzugten Grundlage für viele sektorspezifische Standards und Regulierungsbehörden.

Teil 2-1 aktualisiert in 2024 (IEC 62443-2-1:2024): Die Sicherheitsprogramm-Anforderungen des Asset-Besitzers wurden überarbeitet und neu herausgegeben, um die Erwartungen an das Cyber-Sicherheitsmanagementsystem (CSMS) besser an moderne Lieferketten- und Organisationskontrollen anzupassen. Die Ausgabe von 2024 ist die aktuelle Grundlage für Asset-Besitzer, die ein CSMS entwerfen.

Teil 2 (Dienstleister) konsolidiert/aktualisiert (2023): IEC 62443-2:2023 konsolidiert und klärt die Sicherheitsprogramm-Anforderungen, die für Dienstleister gelten - ein wichtiges Update, das die Erwartungen an Auftragnehmer, Integratoren und Support-Anbieter erhöht.

Produktsicherheit und Drittanbieterprüfung (ISASecure & CSA): Zertifizierungspfade auf Produktebene wie die Common Security Assessment (CSA) von ISASecure entsprechen direkt den 4-2 Anforderungen - was es den Beschaffungsteams ermöglicht, zertifizierte Produkte anzufordern und Verifizierungszyklen zu verkürzen.

Was das für Sie bedeutet: Die Standards entwickeln sich weiter und erfordern eine stärkere Governance und Lieferantenzusicherung. Wenn Sie vor fünf Jahren die Norm 62443 umgesetzt haben, müssen Sie heute Governance, Lieferantenverträge und Produktbeschaffungs-Checklisten neu abgleichen.

OT Systems is Critical

6. Praktischer Fahrplan - Wie man IEC 62443 implementiert

Nachstehend finden Sie ein pragmatisches, ausführbares Programm für Anlagenbesitzer und -betreiber. Jede Phase hat klare Ergebnisse, die sowohl für die Beschaffung als auch für einen Drittpartner wie Shieldworkz nützlich sind.

Phase 0 - Managementsynchronisation (0-2 Wochen)
Ziel: Sponsoring sichern, Rollen zuweisen, Umfang definieren.
Ergebnisse: Managementzusammenfassung, Charta, Projekt-Sponsoren, anfängliche Risikotoleranzerklärung, priorisierte Vermögensliste.

Phase 1 - Entdeckung & Lückenbewertung (2-6 Wochen)
Ziel: Grundlinie der Reife gegenüber 62443 (Steuerungen, Richtlinien, Netzwerkpläne).
Ergebnisse: Anlageninventar, Netzwerk-/Segmentplan (logisch + physisch), Kontrollreife-Matrix (schnelle Scorecard), priorisiertes Lückenregister, das den Teilen und SLs von 62443 zugeordnet ist.

Phase 2 - CSMS-Entwurf & Richtlinien (4-8 Wochen)
Ziel: Das Programm entwickeln, das über Jahre hinweg Bestand haben wird; Zuordnung zu 62443-2-1.
Ergebnisse: CSMS-Blaupause, Governance & Rollen, Lieferanten-sicherheitsrichtlinie, Richtlinie für sicheren Fernzugriff, Patch-Management-Richtlinie (abgestimmt auf 62443-2-3-Leitlinie).

Phase 3 - Risikoanalyse, Zonierung & Zuweisung von SL-Zielen (3-8 Wochen)
Ziel: Ihr System in Zonen und Leitungen unterteilen und SL-T-Ziele zuweisen.
Ergebnisse: Schema der Zonen & Leitungen, SL-T-Matrix pro Zone/Leitung, priorisierter Migrationsplan, verbunden mit den geschäftlichen Konsequenzen.

Hinweis: Wählen Sie SL-Ziele basierend auf den Konsequenzen (Sicherheit, Produktion, langanhaltende Ressourcen), nicht nur auf der Raffinesse der Angreifer.

Phase 4 - Technisches Design & Behebung (variabel)
Ziel: Implementierung von Kontrollen zur Erreichung von SL-T (Netzwerksegmentierung, Gerätehärtung, Authentifizierung, Überwachung).
Ergebnisse: Segmentierungsregeln, Firewall-Richtlinien, Implementierung von Identität und Zugriff, sichere Konfigurationsbasis für Geräte, sichere Netzwerkarchitektur.

Phase 5 - Verifikation, Produktsicherung & sicherer SDLC (laufend)
Ziel: Sicherstellen, dass die Kontrollen die technischen Anforderungen (3-3 / 4-2) durch Tests und Lieferantennachweise erfüllen.
Ergebnisse: Testpläne, Nachweise für die Einhaltung, Berichte zur Produktsicherung von Anbietern (z. B. ISASecure CSA), sicherheitsgerechte Entwicklungsnachweise von Lieferanten (4-1).

Phase 6 - Betrieb, Überwachung & kontinuierliche Verbesserung (kontinuierlich)
Ziel: CSMS betreiben, auf Abweichungen überwachen, regelmäßige Bewertungen durchführen und bei Bedarf SLs neu zuweisen.
Ergebnisse: kontinuierliche Überwachung, Incident-Response-Playbooks, jährliche CSMS-Überprüfung, Lieferanten-Neubewertungen.

7. Typische Fallstricke, Missverständnisse & wie Shieldworkz diese vermeidet

Auswahl von SLs nur nach Angreiferprofil.

Problem: Teams wählen SL basierend auf „wer könnte angreifen“ und vergessen, die Konsequenzen zu evaluieren.

Korrektur: Shieldworkz verwendet eine Folgen-zuerst-Bewertung und ordnet Kontrollen nach Geschäftsauswirkungen zu.

Behandlung von 62443 nur als technische Checkliste.

Problem: Das Überspringen des CSMS-Designs führt zu einer schlechten Nachhaltigkeit.

Behebung: Wir bauen stets die Governance- und Nachweisstruktur, um die Kontrollen über Jahre hinweg wirksam zu halten.

Übersegmentierung oder Untersegmentierung.

Problem: entweder führt es zu betrieblichen Schmerzen oder lässt seitliche Wege für Angreifer offen.

Lösung: Zone/Leitungs-Design-Workshops mit dem Betrieb, um Sicherheit und Security auszubalancieren.

Blindes Vertrauen auf die Angaben des Anbieters.

Problem: Anbieter-Marketing ≠ überprüfbare Konformität.

Abhilfe: Fordern Sie Testnachweise (ISASecure, Prüfberichte von Drittanbietern) an und führen Sie eine unabhängige Verifikation durch.

Der Versuch, moderne Sicherheitsmaßnahmen an ältere PLCs „anzuflicken“.

Problem: spröde Lösungen führen zu Ausfällen

Behebung: defensive kompensierende Kontrollen, Mikro-Segmentierung und Änderungssteuerung, die die Sicherheit priorisiert.

OT Systems is Critical

8. Shieldworkz IEC 62443-Dienstleistungen - zu den Standardteilen zugeordnet

Shieldworkz bietet einen modularen, lieferbereiten Servicekatalog, der direkt auf IEC 62443 ausgerichtet ist, sodass Sie genau das auswählen können, was Sie benötigen, oder sich für die vollständige Programmlieferung entscheiden können.

Governance & Strategie (Teil 2 - CSMS)

62443-2-1 Lückenbewertung und CSMS-Erstellung (Richtlinie, Rollen, KPIs).

Vorlagen für Sicherheitsprogramme für Anbieter und Dritte (Beschaffungsklauseln gemäß 62443-2-4 abgebildet).

Risiko & Architektur (Teil 3 - Systemdesign)

Zone- und Leitungsworkshop + SL-T-Zuweisung.

Risikobewertung / Bedrohungsmodellierung gemäß 62443-3-2 und 3-3.

Netzwerksegmentierungstechnik und Erstellen von Firewall-Regeln.

Produkt- und Entwicklungsabsicherung (Teil 4 - Komponenten)

Übernahme des Secure Development Lifecycle (SDL) Prozesses für interne Geräte (4-1).

Produktevaluation und ISASecure-Mapping / -Bereitschaft (Unterstützung bei der Erlangung von 4-2-Evidenz oder CSA).

Verifizierung & Betrieb

Technische Verifizierungstests (verwundbarkeitsspezifisches Scannen, angepasst an ICS, Protokollprüfungen).

Kontinuierliches Monitoring (OT-aware EDR/NDR Feinabstimmung), Erkennungsregeln, SIEM/OT-Integration.

Maßnahmenpläne für die Reaktion auf Sicherheitsvorfälle und Planspiele konzentrieren sich auf Sicherheit und Prozess.

Managed Services & Laufende Compliance

Managed Detection & Response für OT mit SL-basierten Playbooks.

Kontinuierliches Compliance-Reporting: Liefern Sie Nachweispakete, die mit 62443-Audits und Beschaffungsanfragen abgestimmt sind.

OT Systems is Critical

9. Ergebnisse, geschäftlicher Wert und KPIs - wie man Erfolg misst

Wenn ein 62443-Programm korrekt ausgeführt wird, sind die messbaren Vorteile real und greifbar.

Betriebliche KPIs

Mittlere Zeit zur Erkennung (Mean Time to Detect, MTTD) von OT-Vorfällen - Ziel: Reduzierung um 50 % im ersten Jahr.

Mittlere Eindämmungszeit (MTTC) - messbare Reduzierung durch Playbooks und Segmentierung.

Anzahl der erfolgreichen Patch-Implementierungen für kritische IACS-Komponenten - Erhöhung %.

Geschäfts-KPIs

Reduzierung der ungeplanten Ausfallminuten - umgerechnet in gesparte $ pro Vorfall.

Beschaffungszykluszeit – kürzer, wenn der Lieferantennachweis (z. B. ISASecure) vorliegt.

Compliance-KPIs

Prozentsatz der Zonen mit zugewiesenem SL-T und umgesetzten Steuerungen.

Anzahl der im internen 62443 Audit festgestellten Nichtkonformitäten (Trend abwärts).

OT Systems is Critical

10. Taktische Checkliste - die ersten 90 Tage (für Asset-Besitzer)

Woche 0-2

Ernennen Sie einen CSMS-Sponsor und klären Sie das Budget.

Bestimmen Sie den anfänglichen Umfang (eine Anlage, eine Region) für ein Pilotprojekt.

Woche 2-6

Führen Sie eine schnelle Erkennung durch: Bestandsaufnahme von Vermögenswerten, Netzwerkübersicht, Liste der Eigentümer von Steuerungen.

Führen Sie eine leichte 62443-Lückenbewertung (Vorläufige Scorecard) durch.

Woche 6-10

Führen Sie einen Workshop zur SL-Zielsetzung für Hochrisikozonen durch (sicherheits- und produktionskritisch).

Erstellen Sie eine priorisierte Maßnahmenliste für die Behebung mit schnellen Erfolgen (Authentifizierung, Segmentierung, Fernzugriffskontrollen).

Woche 10-12

Implementieren Sie die Überwachung für die Pilotzone und führen Sie eine Tabletop-Incident-Übung durch.

Bereiten Sie die Einkaufsunterlagen für Anbieter vor: Fordern Sie Nachweise über eine sichere SDLC und Produktprüfberichte an.

OT Systems is Critical

11. Warum Shieldworkz - was unseren Ansatz unterscheidet

Shieldworkz bietet OT-native Cybersicherheit, die Operationen schützt, ohne die PLC-Timing oder Sicherheit zu stören. Wir kombinieren OT-Engineering und Sicherheitsexpertise mit standardbasierten, risikogesteuerten Praktiken sowie Unterstützung bei Compliance und Widerstandsfähigkeit. Unsere Lösungen sind auf die Anforderungen des deutschen B2B-Marktes zugeschnitten und bieten präzise und zuverlässige Sicherheit gemäß KRITIS-Standards.

Schneller 62443-Bereitschaftsbewertung (2-4 Wochen): Entdeckung, Scorecard, Sanierungsplan.

Pilot - Zone & Conduit-Verstärkung (8-12 Wochen): Segmentierung, Authentifizierung, Überwachung.

CSMS Aufbau & Governance (12-20 Wochen): Dokumentation, Lieferantenrichtlinie, Verifizierung.

Produktgarantie & Beschaffung (laufend): Anbieter-Audits und ISASecure-Bereitschaft.

Eine Demo anfordern

Wenn Sie für OT/ICS-Sicherheit, Compliance oder Beschaffung in den Bereichen Energie, Öl & Gas, Fertigung, Pharma, Transport oder Wasser verantwortlich sind - buchen Sie eine kostenlose Demo mit Shieldworkz. Wir bieten Ihnen einen präzisen, maßgeschneiderten 90-Tage-Fahrplan, der direkt auf die IEC 62443-Anforderungen und Ihre Geschäftsprioritäten abgestimmt ist.

Eine Beratung anfordern

CTA section

Nehmen Sie Kontakt mit Shieldworkz auf

Reichen Sie Ihre Anfrage über unser sicheres Online-Formular ein, und ein Mitglied unseres Teams wird innerhalb von 24 Stunden antworten.

Faq Background

Pattern BG

Häufig gestellte Fragen

F: Wie lange dauert ein typisches 62443-Programm?

Ein fokussiertes Pilotprojekt (einzelne Anlage) kann innerhalb von 3-6 Monaten messbare Verbesserungen zeigen; die Reife eines unternehmensweiten CSMS ist ein 12- bis 24-monatiges Programm, abhängig vom Umfang und der Komplexität der bestehenden Systeme.

F: Sind 62443 und ISO 27001 kompatibel?

F: Müssen meine Anbieter „62443 zertifiziert“ sein?

Frage: Sollten wir SL-3 oder SL-4 anstreben?