# IEC 62443

IEC 62443 ist eine internationale Normenreihe über „Industrielle Kommunikationsnetze - IT-Sicherheit für Netze und Systeme“. Die relevanten Systeme, in denen die Kommunikation stattfindet, werden auch als IACS - Industrielle automatisierte Steuerungssysteme sowie ICS - Industrielle Steuerungssysteme in der Norm bezeichnet. Die Normenreihe ist in verschiedene Bereiche unterteilt und beschreibt sowohl technische als auch prozessuale Aspekte der Industriellen Cybersecurity. Sie unterteilt die Industrie in verschiedene Rollen: den Betreiber, die Integratoren (Dienstleister für Integration und Wartung) sowie die Hersteller. Die verschiedenen Rollen verfolgen jeweils einen risikobasierten Ansatz zur Vermeidung und Behandlung von Sicherheitsrisiken bei ihren Tätigkeiten.

## IEC 62443 Übersicht

Die Normenreihe IEC 62443 Industrial communication networks – Network and system security besteht aus mehreren Teilen, die in vier Bereiche eingeteilt werden:
* General: Hier werden die grundsätzlichen Begriffe, Konzepte und Modelle beschrieben.
* Policies and Procedures: Hier wird vor allem ein System zum Management industrieller IT-Sicherheit beschrieben.
* System: Hier werden verschiedene Vorgaben für Sicherheitsfunktionen von Steuerungs- und Automatisierungssystemen beschrieben.
* Components and Requirements: Hier werden die Anforderungen an Prozesse der Produktentwicklung von Komponenten einer Automatisierungslösung beschrieben.
Die folgende Aufstellung führt die bis jetzt veröffentlichten Teile der Normenreihe IEC 62443 mit dem Stand und dem Titel auf.
* 1-1 Technical Specification, Edition 1.0, Juli 2009;Terminology, concepts and models
* 1-5 Technical Specification, Edition 1, September 2023; Scheme for IEC 62443 security profiles
* 2-1 Edition 2.0, August 2024; Security program requirements for IACS asset owners. Dieser Teil richtet sich an Betreiber von Automatisierungslösungen und definiert Anforderungen, wie Sicherheit während des Betriebs von Anlagen zu berücksichtigen ist (vgl. ISO/IEC 27001).
* 2-3 Technical Report, Edition 1.0, Juni 2015; Patch management in the IACS environment
* 2-4 Edition 1.1, August 2017 Edition 2, Dezember 2023; Requirements for IACS service providers. Dieser Teil legt Anforderungen („Capabilities“) für Integratoren fest. Diese Anforderungen sind in 12 Themengebiete unterteilt: Assurance, Architektur, Wireless, Sicherheitstechnische Systeme, Konfigurationsmanagement, Fernzugriff, Ereignisverwaltung und -protokollierung, Benutzerverwaltung, Malware-Schutz, Patch-Management, Backups & Wiederherstellung sowie Besetzung von Projekten.
* 3-1 Technical Report, Edition 1.0, Juli 2009; Security technologies for industrial automation and control systems (IAC)
* 3-2 Edition 1.0, Juni 2020; Security risk assessment and system design
* 3-3 Edition 1.0, August 2013; System security requirements and security levels. Dieser Teil beschreibt technische Anforderungen an Systeme sowie Security Levels.
* 4-1 Edition 1.0, Januar 2018; Secure product development lifecycle requirements. Dieser Teil legt fest, wie ein sicherer Entwicklungsprozess für Produkte auszusehen hat. Er ist unterteilt in acht Bereiche („Practices“): dem Management der Entwicklung, der Definition von Security-Anforderungen, dem Design von Security-Lösungen, der sicheren Entwicklung, dem Testen von Sicherheitseigenschaften, dem Umgang mit Sicherheitslücken, dem Erstellen und Veröffentlichen von Updates sowie der Dokumentation der Security-Eigenschaften.
* 4-2 Edition 1.0, Februar 2019; Technical security requirements for IACS components. Dieser Teil legt technische Anforderungen an Produkte bzw. Komponenten fest. Die Anforderungen sind wie die Anforderungen an Systeme (Teil 3-3) in 12 Themengebiete unterteilt und beziehen sich auf diese. Zusätzlich zu den technischen Anforderungen werden allgemeine Sicherheitsanforderungen („Common component security constraints“, CCSC) definiert, die von Komponenten eingehalten werden müssen, um mit der IEC 62443-4-2 konform zu sein:
** CCSC 1 beschreibt, dass Komponenten die allgemeinen Sicherheitseigenschaften des Systems, in dem sie eingesetzt werden, berücksichtigen müssen.
** CCSC 2 legt fest, dass die technischen Anforderungen, die die Komponente nicht selbst erfüllen kann, durch kompensierende Gegenmaßnahmen („Compensating countermeasures“) auf Systemebene (vgl. IEC 62443-3-3) erfüllt werden können. Hierfür müssen die Gegenmaßnahmen in der Dokumentation der Komponente beschrieben werden.
** CCSC 3 verlangt, dass in der Komponente das „Least Privilege“-Prinzip angewendet wird.
** CCSC 4 verlangt, dass die Komponente durch IEC 62443-4-1 konforme Entwicklungsprozesse entwickelt und supportet wird.
* Teil 5: Dieser Abschnitt soll branchenspezifische Cybersicherheitsanforderungen definieren und einen strukturierten Ansatz zur Umsetzung von Maßnahmen bieten, basierend auf den in IEC 62443-1-5 beschriebenen Cybersecurity-Profilen.
* 6-1 Technical Specification, Edition 1.0, March 2024; Security for industrial automation and control systems – Part 6-1: Security evaluation methodology for IEC 62443-2-4. Dieser Teil stellt eine Bewertungsmethodik vor, die sicherstellt, dass Bewertungsergebnisse im Hinblick auf die Anforderungen der IEC 62443-2-4 konsistent und reproduzierbar sind.

## Reifegrade

Die IEC 62443 beschreibt verschiedene Reifegrade für Prozesse und technische Anforderungen. Die Reifegrade für Prozesse orientieren sich dabei an den Reifegraden aus dem CMMI-Framework.

### Maturity Level

Angelehnt an CMMI beschreibt die IEC 62443 verschiedene Reifegrade für Prozesse durch sogenannte „Maturity Level“. Für die Erfüllung einer bestimmten Stufe eines Reifegrades müssen immer alle prozessualen Anforderungen bei der Produktentwicklung bzw. Integration praktiziert werden, d. h. die Auswahl von nur einzelnen Kriterien („Cherry Picking“) ist nicht standardkonform.
Die Reifegrade sind dabei wie folgt beschrieben:
* Maturity Level 1 - Initial: Produktlieferanten führen die Produktentwicklung in der Regel ad hoc und oft undokumentiert (oder nicht vollständig dokumentiert) durch.
* Maturity Level 2 - Managed: Der Produktlieferant ist in der Lage, die Entwicklung eines Produkts gemäß schriftlicher Richtlinien zu verwalten. Es muss nachgewiesen werden, dass das Personal, das den Prozess durchführt, über das entsprechende Fachwissen verfügt, geschult ist und/oder schriftliche Verfahren befolgt. Die Prozesse sind wiederholbar.
* Maturity Level 3 - Defined (practiced): Der Prozess ist in der gesamten Organisation des Lieferanten wiederholbar. Die Prozesse sind praktiziert worden, und es gibt Belege dafür, dass dies geschehen ist.
* Maturity Level 4 - Improving: Anhand geeigneter Prozessmetriken kontrollieren die Produktlieferanten die Wirksamkeit und Leistung des Prozesses und weisen eine kontinuierliche Verbesserung in diesen Bereichen nach.

### Security Level

Technische Anforderungen an Systeme (IEC 62443-3-3) und Produkte (IEC 62443-4-2) werden in der Norm durch vier sogenannte Security Level (SL) bewertet. Die verschiedenen Level geben dabei die Widerstandsfähigkeit gegenüber verschiedener Angreiferklassen an. Der Standard betont, dass dabei die Level pro technischer Anforderung gewertet werden sollen (vgl. IEC 62443-1-1) und nicht für die allgemeine Klassifizierung von Produkten geeignet sind.
Die Level sind:
* Security Level 0: Keine besondere Anforderung oder Schutz erforderlich.
* Security Level 1: Schutz vor unbeabsichtigtem oder zufälligem Missbrauch.
* Security Level 2: Schutz vor vorsätzlichem Missbrauch mit einfachen Mitteln mit geringen Ressourcen, allgemeinen Fähigkeiten und geringer Motivation.
* Security Level 3: Schutz vor vorsätzlichem Missbrauch mit anspruchsvollen Mitteln mit moderaten Ressourcen, IACS-spezifischen Kenntnissen und moderater Motivation.
* Security Level 4: Schutz vor vorsätzlichem Missbrauch unter Einsatz anspruchsvoller Mittel mit umfangreichen Ressourcen, IACS-spezifischen Kenntnissen und hoher Motivation.

## Grundprinzipien

Die Norm erläutert verschiedene Grundprinzipien, die für alle Rollen bei allen Tätigkeiten berücksichtigt werden sollen.

### Defense in Depth

Defense in Depth („Verteidigung in der Tiefe“) ist ein Konzept, bei dem mehrere Ebenen von Sicherheitsvorkehrungen (Verteidigung) über das gesamte System verteilt sind. Das Ziel ist hierbei, Redundanz für den Fall zu schaffen, dass eine Sicherheitsmaßnahme ausfällt oder eine Schwachstelle ausgenutzt wird.

### Zones & Conduits

Zones unterteilen ein System in homogene Zonen durch Gruppierung der (logischen oder physischen) Anlagen mit gemeinsamen Sicherheitsanforderungen. Die Sicherheitsanforderungen werden über Security Level (SL) definiert. Das für eine Zone erforderliche Niveau wird durch die Risikoanalyse ermittelt.
Zonen haben Grenzen, die die Elemente innerhalb der Zone von denen außerhalb trennen. Informationen bewegen sich innerhalb und zwischen den Zonen. Zonen können in Unterzonen unterteilt werden, die unterschiedliche Sicherheitsebenen (Security Level) definieren und damit Defense-in-Depth ermöglichen.
Conduits gruppieren die Elemente, die die Kommunikation zwischen zwei Zonen erlauben. Sie stellen Sicherheitsfunktionen bereit, die eine sichere Kommunikation ermöglichen und die Koexistenz von Zonen unterschiedlicher Sicherheitsstufen erlauben.