PSIRT
IEC 62443-4-1: der sichere Entwicklungslebenszyklus für Industrieprodukte
IEC 62443-4-1 legt die Prozessanforderungen fest, nach denen ein Zulieferer sichere Produkte für industrielle Automatisierungs- und Steuerungssysteme entwickelt und pflegt. Zwei der acht Praktiken, der Umgang mit Sicherheitsproblemen und die Bereitstellung von Sicherheitsupdates, sind die Arbeit eines PSIRT.
Aktualisiert am
Was ist IEC 62443-4-1?
IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, wurde im Januar 2018 veröffentlicht. Laut ihrem eigenen Anwendungsbereich legt die Norm Prozessanforderungen an die sichere Entwicklung von Produkten fest, die in industriellen Automatisierungs- und Steuerungssystemen eingesetzt werden. Der darin festgelegte Lebenszyklus umfasst die Definition von Sicherheitsanforderungen, sicheres Design, sichere Implementierung, Verifizierung und Validierung, Fehlermanagement, Patch-Management und das Lebensende des Produkts.
Sie gilt für den, der ein Produkt entwickelt und pflegt: den Produktzulieferer, der Steuerungen, Embedded-Geräte, Netzwerkausrüstung, Host-Software oder Anwendungen herstellt. Sie gilt nicht für den Integrator oder den Nutzer des Produkts, für die es eigene Teile der Reihe gibt. ISA veröffentlicht die Reihe als ISA/IEC 62443.
Die Norm beschreibt Prozessanforderungen, Richtlinien und Verfahren, nicht technische Sicherheitsfunktionen. Die technischen Anforderungen an Komponenten stehen in IEC 62443-4-2.
Die acht Praktiken von IEC 62443-4-1
Die Anforderungen sind in acht Praktiken gegliedert, jede mit einer kurzen Abkürzung, die ihren Anforderungs-IDs vorangestellt ist. Die ISA Global Cybersecurity Alliance nennt insgesamt 47 Anforderungen:
| Praktik | Anforderungen | Was sie abdeckt |
|---|---|---|
| 1. Sicherheitsmanagement (SM) | SM-1 bis SM-13 | Planung und Betrieb des Sicherheitsprozesses: Verantwortlichkeiten, Fachwissen, Sicherheit der Entwicklungsumgebung, private Schlüssel, extern bereitgestellte Komponenten und Drittkomponenten, Prozessverifizierung, kontinuierliche Verbesserung |
| 2. Spezifikation von Sicherheitsanforderungen (SR) | SR-1 bis SR-5 | Sicherheitskontext des Produkts, Bedrohungsmodell, Sicherheitsanforderungen an das Produkt und deren Prüfung |
| 3. Secure by Design (SD) | SD-1 bis SD-4 | Prinzipien sicheren Designs, Design für Defense in Depth, Design-Review, Best Practices für das Design |
| 4. Sichere Implementierung (SI) | SI-1 bis SI-2 | Prüfung der Sicherheitsimplementierung und Standards für sicheres Programmieren |
| 5. Tests zur Verifizierung und Validierung der Sicherheit (SVV) | SVV-1 bis SVV-5 | Anforderungstests, Tests der Bedrohungsabwehr, Schwachstellentests, Penetrationstests, Unabhängigkeit der Tester |
| 6. Management sicherheitsrelevanter Probleme (DM) | DM-1 bis DM-6 | Entgegennahme, Prüfung, Bewertung, Bearbeitung und Offenlegung von Sicherheitsproblemen im Produkt |
| 7. Management von Sicherheitsupdates (SUM) | SUM-1 bis SUM-5 | Qualifizierung, Dokumentation und rechtzeitige Bereitstellung von Sicherheitsupdates |
| 8. Sicherheitsrichtlinien (SG) | SG-1 bis SG-7 | Nutzerdokumentation zu Defense in Depth, Härtung, sicherem Betrieb, Kontoverwaltung und Entsorgung |
Praktik 6: Management sicherheitsrelevanter Probleme (DM)
DM ist die Praktik, die ein PSIRT als seine eigene erkennt. Laut der ISAGCA dienen ihre Prozesse dazu, sicherheitsrelevante Probleme eines Produkts zu bearbeiten, das gemäß seiner Defense-in-Depth-Strategie konfiguriert ist. Ihre sechs Anforderungen begleiten ein Problem von der Meldung bis zum Abschluss:
- DM-1: Entgegennahme von Meldungen sicherheitsrelevanter Probleme
- DM-2: Prüfung sicherheitsrelevanter Probleme
- DM-3: Bewertung sicherheitsrelevanter Probleme
- DM-4: Bearbeitung sicherheitsrelevanter Probleme
- DM-5: Offenlegung sicherheitsrelevanter Probleme
- DM-6: Regelmäßige Überprüfung der Praxis des Sicherheitsfehlermanagements
Einfach gesagt: Meldungen annehmen, prüfen, bewerten, beheben, Nutzer informieren und den Prozess selbst überprüfen.
Diese Abfolge ist der Lebenszyklus des Schwachstellenmanagements unter anderem Namen, und bei DM-1 und DM-5 kommt die koordinierte Offenlegung von Schwachstellen ins Spiel. Die Offenlegung kann als CSAF-Advisory erfolgen, mit einer VEX-Aussage für die nicht betroffenen Versionen.
Praktik 7: Management von Sicherheitsupdates (SUM)
SUM setzt dort an, wo DM über einen Fix entscheidet. Seine Prozesse stellen, in der Zusammenfassung der ISAGCA, sicher, dass Sicherheitsupdates für Hardware, Software oder Firmware des Produkts auf Regressionen getestet und den Nutzern rechtzeitig bereitgestellt werden. Die fünf Anforderungen sind:
- SUM-1: Qualifizierung von Sicherheitsupdates
- SUM-2: Dokumentation von Sicherheitsupdates
- SUM-3: Dokumentation von Sicherheitsupdates für abhängige Komponenten oder Betriebssysteme
- SUM-4: Bereitstellung von Sicherheitsupdates
- SUM-5: Rechtzeitige Bereitstellung von Sicherheitspatches
SUM-3 ist die Anforderung, die in Ihre Lieferkette hineinreicht: Updates für Komponenten und Betriebssysteme, von denen Ihr Produkt abhängt. Bei einem Embedded-Produkt auf Basis einer Linux-Distribution können das die meisten Patches sein, die Sie ausliefern.
Reifegrade
IEC 62443-4-1 fragt nicht, ob ein Prozess existiert, sondern wie ausgereift er ist. Die Norm verwendet vier Reifegrade auf Basis von CMMI for Development:
| Stufe | Bedeutung |
|---|---|
| ML1 Initial | Prozesse werden ad hoc oder undokumentiert ausgeführt |
| ML2 Managed | Prozesse sind dokumentiert und beschreiben, wie die Tätigkeit erbracht und gesteuert wird |
| ML3 Defined (Practiced) | Prozesse sind dokumentiert, werden ausgeführt und sind wiederholbar |
| ML4 Improving | Prozesse werden im Lauf der Zeit anhand von Kennzahlen zu Leistung und Wirksamkeit verbessert |
Der Unterschied zwischen ML2 und ML3 ist die Praxis. Ein schriftlicher DM-Prozess kann ML2 sein. ML3 bedeutet, dass der Prozess ausgeführt und wiederholt wurde: Probleme wurden entgegengenommen, bewertet und abgeschlossen, Updates bereitgestellt, mit den Aufzeichnungen, die das belegen.
Zertifizierung
- ISASecure SDLA. Das Programm Security Development Lifecycle Assurance zertifiziert den Lebenszyklusprozess einer Entwicklungsorganisation nach IEC 62443-4-1. Die Bewertungen führen zugelassene SDLA-Labore durch, die als Konformitätsbewertungsstellen akkreditiert sind.
- Zertifizierungsstellen und das IECEE CB Scheme. Prüf- und Zertifizierungsstellen wie Applus+ und TÜV Rheinland bewerten Zulieferer nach 62443-4-1 und geben den erreichten Reifegrad an, auch im Rahmen des IECEE CB Scheme, das in mehr als 50 Ländern gilt.
Ein Zertifikat nach 62443-4-1 gilt für den Entwicklungsprozess des Zulieferers, nicht für ein einzelnes Produkt. Produkte werden separat nach 62443-4-2 bewertet.
Wie sich 62443-4-1 zum Rest der Reihe verhält
- IEC 62443-4-2, technische Sicherheitsanforderungen an IACS-Komponenten: was das Produkt können muss. 4-1 beschreibt, wie Sie es bauen und pflegen.
- IEC 62443-3-3, Systemsicherheitsanforderungen und Security Levels: die entsprechenden technischen Anforderungen auf Systemebene.
- IEC 62443-2-4, Anforderungen an Sicherheitsprogramme für IACS-Dienstleister: die Integratoren und Wartungsdienstleister, die Ihr Produkt beim Anlagenbetreiber installieren und warten und die auf Ihre Sicherheitsupdates und Richtlinien angewiesen sind.
IEC 62443-4-1 und die PSIRT-Arbeit
| PSIRT-Tätigkeit | Wo sie in 62443-4-1 verortet ist |
|---|---|
| Annahme von Schwachstellenmeldungen | DM-1 |
| Triage und Analyse | DM-2, DM-3 |
| Behebung | DM-4, SUM-1 |
| Advisories und Offenlegung | DM-5, SUM-2 |
| Patches für Drittkomponenten | SUM-3, mit SM-9 und SM-10 zu extern bereitgestellten Komponenten und Drittkomponenten |
| Release des Fixes | SUM-4, SUM-5 |
| Kennzahlen und Prozessprüfung | DM-6, SM-13 |
Diese Zuordnung stammt von uns und orientiert sich an den Titeln der Anforderungen. Die Norm erwähnt PSIRTs nicht namentlich; dieselbe Arbeit beschreiben das PSIRT Services Framework von FIRST und ISO/IEC 30111.
SBOMs als Nachweis für DM und SUM
Die Titel der Anforderungen von 2018 erwähnen SBOMs nicht. Viele Sicherheitsprobleme in einem Industrieprodukt stecken jedoch in Komponenten, die sein Zulieferer nicht geschrieben hat: dem Linux-Kernel, OpenSSL, BusyBox, einem Protokollstack. Um DM-2 und DM-3 für ein neues Advisory zu erfüllen, müssen Sie wissen, welche Produkte und Versionen die betroffene Komponente enthalten. Um SUM-3-Updates zu dokumentieren, müssen Sie wissen, mit welchen Komponentenversionen jedes Release ausgeliefert wurde. Auf ML3 müssen hinter diesen Antworten Aufzeichnungen stehen.
Eine von Hand geschriebene Komponentenliste oder ein Scan des Quellbaums veraltet. Eine SBOM aus dem Build, der das Release erzeugt hat, veraltet nicht, solange der Build selbst aufgezeichnet wird.
Wo CRACI ins Spiel kommt
CRACI zertifiziert nichts nach IEC 62443 und führt Ihren Entwicklungsprozess nicht aus. Seine Aufzeichnungen können als Nachweis für Teile davon dienen: das Inventar der Komponenten in jedem Release und die Überwachung ausgelieferter Builds auf neue Schwachstellen.
CRACI führt GitHub-Actions-Builds, einschließlich Yocto-Builds, auf eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus Caches wiederhergestellter Pakete und Abhängigkeiten, die in keinem Lockfile stehen. Jede SBOM trägt einen Vollständigkeitsstatus und lässt sich als CycloneDX oder SPDX exportieren. Überwachte SBOMs werden laufend neu bewertet, die Build-Historie zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, und die Inventaransicht zeigt, welche Versionen auf welchen Produkten im Einsatz sind. Hersteller-SBOMs für zugekaufte Komponenten werden zusammen mit Ihren eigenen Builds überwacht. Siehe Schwachstellenverfolgung und CRACI für PSIRTs.
IEC 62443-4-1: häufig gestellte Fragen
Was ist IEC 62443-4-1?
IEC 62443-4-1:2018, Secure product development lifecycle requirements, ist der Teil der Reihe IEC 62443, der Prozessanforderungen für Zulieferer festlegt, die Produkte für industrielle Automatisierungs- und Steuerungssysteme entwickeln. Er umfasst Sicherheitsanforderungen, sicheres Design, Implementierung, Verifizierung und Validierung, Fehlermanagement, Patch-Management und das Lebensende des Produkts.
Welche acht Praktiken umfasst IEC 62443-4-1?
Sicherheitsmanagement (SM), Spezifikation von Sicherheitsanforderungen (SR), Secure by Design (SD), sichere Implementierung (SI), Tests zur Verifizierung und Validierung der Sicherheit (SVV), Management sicherheitsrelevanter Probleme (DM), Management von Sicherheitsupdates (SUM) und Sicherheitsrichtlinien (SG). Zusammen enthalten sie 47 Anforderungen.
Was ist der Unterschied zwischen IEC 62443-4-1 und 62443-4-2?
4-1 betrifft den Prozess, mit dem ein Zulieferer Produkte entwickelt und pflegt. 4-2 legt technische Sicherheitsanforderungen an die Komponenten selbst fest, etwa an Embedded-Geräte, Netzwerkgeräte, Host-Geräte und Softwareanwendungen. Ein Zulieferer wird typischerweise für seinen Entwicklungsprozess nach 4-1 und für ein bestimmtes Produkt nach 4-2 bewertet.
Welche Praktiken von IEC 62443-4-1 decken das Schwachstellenmanagement ab?
Vor allem Praktik 6, das Management sicherheitsrelevanter Probleme (DM-1 bis DM-6), das die Entgegennahme, Prüfung, Bewertung, Bearbeitung und Offenlegung von Sicherheitsproblemen abdeckt, und Praktik 7, das Management von Sicherheitsupdates (SUM-1 bis SUM-5), das die Qualifizierung, Dokumentation und rechtzeitige Bereitstellung von Sicherheitsupdates abdeckt. Das ist die Arbeit eines PSIRT.
Welche Reifegrade hat IEC 62443-4-1?
Vier Stufen auf Basis von CMMI for Development: ML1 Initial (ad hoc oder undokumentiert), ML2 Managed (dokumentierte Prozesse), ML3 Defined oder Practiced (dokumentiert, ausgeführt und wiederholbar) und ML4 Improving (Prozesse werden im Lauf der Zeit anhand von Leistungskennzahlen verbessert).
Wie wird man nach IEC 62443-4-1 zertifiziert?
Über eine akkreditierte Zertifizierungsstelle. Das SDLA-Programm von ISASecure zertifiziert Entwicklungsorganisationen über zugelassene Labore nach IEC 62443-4-1, und Zertifizierungsstellen wie TÜV Rheinland und Applus+ stellen Zertifikate nach 62443-4-1 aus, die den erreichten Reifegrad angeben, auch im Rahmen des IECEE CB Scheme.
Verlangt IEC 62443-4-1 eine SBOM?
Die Titel der Anforderungen von 2018 erwähnen SBOMs nicht. Mehrere Anforderungen befassen sich mit extern bereitgestellten Komponenten und mit Updates für abhängige Komponenten und Betriebssysteme, und eine verlässliche Liste der Komponenten in jedem Release ist der praktische Weg, um zu zeigen, wie Sie damit umgehen.
Wissen, welche ausgelieferten Builds eine verwundbare Komponente enthalten
Der Umgang mit Sicherheitsproblemen beginnt mit dem Wissen, was in jedem Release steckt. Buchen Sie eine Demo und sehen Sie es anhand einer Aufzeichnung dessen, was jeder Build geladen hat, auch Yocto-Builds.
Demo buchen