IEC 62443-4-1: IT-Sicherheit als Teil das Produktlebenszyklus

Die IEC 62443-4-1 ist Teil einer Normenfamilie zur „IT-Sicherheit für industrielle Automatisierungssysteme“.

Dieser Artikel stellt Ihnen den Teil 4-1 vor, der Anforderungen an den Lebenszyklus (Entwicklung, Wartung) von sicheren Produkten stellt. Er untersucht auch, ob diese Norm für Hersteller von Medizinprodukten sinnvoll anwendbar ist.

1. Die Normenfamilie IEC 62443

a) Übersicht

Die IEC 62443 ist eine ganze Familie an Normen zur IT-Sicherheit von industriellen Automatisierungssystemen:

• Anforderungen an den Lebenszyklus für eine sichere Produktentwicklung: DIN EN IEC 62443-4-1
• Sicherheitsrisikobeurteilung und Systemgestaltung: DIN EN 62443-3-2
• Anforderungen an Komponenten industrieller Automatisierungssysteme: DIN EN 62443-4-2
• Anforderungen an das IT-Sicherheitsprogramm von Dienstleistern für industrielle Automatisierungssysteme: DIN IEC 62443-2-4
• Systemanforderungen zur IT-Sicherheit und Security-Level: DIN IEC 62443-3-3

Ein Teil dieser Normen befindet sich noch in der Entwicklung.

Dabei wendet sich die Serie 4 v.a. an die Entwickler bzw. Lieferanten, die Serie 3 an die Integratoren und die Serie 2 an die Betreiber.

b) Anwendungsbereich

Bereits der Titel der Normenfamilie macht deren Anwendungsbereich klar: Industrielle Automatisierungs- und Steuerungssysteme. Allerdings enthält die Norm nur Anforderungen, die für andere Produktklassen als ebenso sinnvoll erscheinen.

2. IEC 62443-4-1

a) Anwendungsbereich

Der Teil 4-1 möchte Anforderungen an den kompletten Lebenszyklus stellen einschließlich Entwicklung und Wartung. Diese Anforderungen betreffen:

• Anforderungsspezifikation
• Entwurf, Architektur
• Implementierung einschließlich Kodierrichtlinien
• Verifizierung
• Validierung
• Management von Fehlern und Patches
• Außerbetriebnahme

Hingegen fühlt sich die IEC 62443-4-1 nicht für die Integration und die Anwendung des Produkts zuständig. Diese finden sich in den Serien 2 und 3 dieser Normenfamilie.

b) Aufbau

Die Norm besteht im Wesentlichen aus acht „Ansätzen“ (wie das die Deutsche Norm den Begriff „Practices“ übersetzt).

Jeder dieser Ansätze umfasst zwischen zwei und 13 Aspekten. Für jeden Aspekt formuliert die IEC 62443-4-1 jeweils ein oder mehrere Anforderungen und gibt eine Begründung dafür.

c) Anforderungen

Die acht „Ansätze“ (Themengebiete) adressieren den Lebenszyklus von IT-Systemen einschließlich der Wartung und der Dokumentation, die bei Medizinprodukten dem „Labeling“ entspricht.

„Ansatz“	Beispiele für Anforderungen
1. Verwaltung der IT Sicherheit	Es muss einen Entwicklungsprozess geben. Verantwortlichkeiten sind festzulegen. Kompetenzen müssen sichergestellt sein. Das Produkt muss bereits während der Entwicklung geschützt sein. Risiken durch zugelieferte Komponenten (OTS?) müssen beherrscht sein.
2. Spezifikation der IT-Sicherheitsanforderungen	Der Anwendungskontext (z.B. Netzwerk) muss dokumentiert sein. Der Hersteller muss ein Threat Modelling durchführen. Die Anforderungen an die IT-Sicherheit (z.B. an Passwörter) müssen spezifiziert werden.
3. IT-Sicherheit durch Entwurf	Alle externen Schnittstellen müssen spezifiziert sein inklusive Daten und Datenflussrichtungen. Alle OTS muss dokumentiert und auf IT-Sicherheit bewertet sein. Es muss mehrere Schichten an Abwehrmechanismen geben. Best Practices wie eine „Attack Surface Reduction” müssen angewendet werden.
4. Gesicherte Implementierung	Eine statische Code-Analyse ist verpflichtend ebenso Code-Reviews. Kodier-Richtlinien müssen festgelegt und überwacht werden.
5. Verifikatons- und Validierungsprüfungen der IT-Sicherheit	Alle Anforderungen bezüglich der IT-Sicherheit müssen überprüft werden. Die Überprüfung muss u.a. umfassen ein „Vulnerability Scanning“, den Missbrauch z.B. durch Fuzz Testing und Überlast. Penetrationstests sind verlangt. Die Tester müssen unabhängig sein.
6. Behandlung sicherheitsbezogener Probleme	Es muss ein Prozess existieren, um IT-Sicherheitsprobleme zu erhalten und verfolgen. Diese Probleme müssen bewertet werden. Der Prozess muss festlegen, wann welche Handlungsoptionen (z.B. Fix) ergriffen werden. Ein Prozess muss etabliert sein, wie diese Probleme kommuniziert und gelöst werden.
7. Verwaltung von IT-Sicherheits-Updates	Es ist ein Prozess zum Beheben von Schwachstellen verlangt. Der Hersteller muss die Informationen über Update dokumentieren. Der Prozess muss auch mit Schwachstellen in OTS umgehen können. Der Prozess muss die Auslieferung von Patches innerhalb einer Zeit gewährleisten, die der Hersteller abhängig von mehreren Faktoren bestimmen muss.
8. IT-Sicherheitsrichtlinien	Es muss ein Prozess existieren, der regelt, wie die Dokumentation erzeugt wird. Diese Dokumentation muss den Anwendern Handlungsleitung geben, um das Produkt sicher zu betreiben und zu entsorgen.

Vergleich und Zusammenspiel mit anderen Normen

Die IEC 62443-4-1 basiert auf weiteren Normen und Dokumenten wie der IEC 15408-3, der IEC 61508 und dem RTCA DO-178B. Sie verweist zudem auf den „The Security Development Life-cycle” von Michael Howard und Steve Lipner, den auch Microsoft nutzt bzw. referenziert.

Die Normen der Familie UL 2900 finden keine Erwähnung, obwohl der Scope teilweise vergleichbar ist.

Bewertung, Fazit

a) Eine verständliche und systematische Norm

Die IEC 62443-4-1 ist (im Gegensatz zum UL 2900) eine klar formulierte und strukturierte Norm. Sie macht deutlich, dass IT-Sicherheit nur erreicht werden kann (falls überhaupt), wenn sie über den kompletten Lebenszyklus eines Produkts beachtet wird.

Die Anforderungen sind in gewisser Weise „common sense“. Die Verwundbarkeit der meisten Produkte und Systeme liegt aber darin begründet, dass die Hersteller genau diese Anforderungen nicht berücksichtigen. Diese Anforderungen zusammengetragen zu haben, macht den Wert dieser Norm aus.

Die Übersetzung ins Deutsche ist hingegen etwas holperig geraten.

b) Etwas high-level

Die Anforderungen der Norm sind etwas „high level“. Sie gibt beispielsweise nicht vor, über welche Kompetenzen die Verantwortlichen verfügen müssen, sie erklärt nicht, was getan werden muss, um das Produkt während seiner Entwicklung zu schützen. Die Norm spricht von Kodierrichtlinien, ohne konkrete Beispiele dafür zu formulieren.

Konkrete Hinweise zur Umsetzung finden sich (leider nur und auch dort nur teilweise) bei den Begründungen und weiteren Hinweisen. Damit eignet sich die Norm eher für Prozessmanager als für Entwickler.

Das ist jedoch keine Kritik. Denn die Norm formuliert zumindest die Aspekte, welche die Hersteller bei der Entwicklung und Wartung von Produkten bezüglich der IT Security beachten müssen.

c) Hilfreich aber nicht ausreichend für Medizinproduktehersteller

Die IEC 62443-4-1 sieht ihren Anwendungsbereich zwar bei industriellen Automatisierungssystemen. Allerdings enthält die Norm keine Anforderungen, die sich nicht unverändert auf die Entwicklung und Wartung vernetzter Medizinprodukte übertragen lassen.

Umgekehrt berücksichtigt der Leitfaden keine Anforderungen, die spezifisch für Medizinprodukte sind wie die Safety und das (medizinische) Risikomanagement. Weil der Norm der Branchenfokus fehlt, könnte man die darin formulierten Anforderungen als notwendig aber als nicht als hinreichend bezeichnen.

Die FDA zählt andere und veraltete Mitglieder der Normenfamilie zu den recognized standards, nicht aber die IEC 62443-4-1.

d) Kleinere Logikbrüche

Die Zuordnung der Aktivitäten zu den Lebenszyklus-Phasen ist nicht in allen Fällen nachvollziehbar. Wie sollen vor(!) dem Entwurf bereits interne Protokolle bekannt sein, die die Norm bereits beim Threat Modelling während der Anforderungsphase analysiert haben will?

Umgekehrt verlangt die Norm die Spezifikation der externen Schnittstellen erst beim Entwurf.

Die Metriken im Anhang sind teilweise sehr „C-lastig“ und können eine nicht ganz berechtigte Illusion einer Genauigkeit erwecken.

e) Grundlage für eine Zertifizierung?

Viele Prüfhäuser und benannte Stellen bieten Zertifizierungen nach IEC 62443 an. Überdenken Sie immer den Wert von Zertifikaten, insbesondere in den folgenden Fällen:

• Ein Zertifikat wird nicht unter dem Dach der DaKKS ausgestellt. Solch ein Zertifikat kann jeder erstellen.
• Die Prüfung erfolgt nicht gemäß einer Prüfnorm.
• Die Norm, deren Konformität geprüft werden soll, enthält weder testbare Anforderungen noch Hinweise zu deren Prüfung.
• Die Norm, deren Konformität geprüft werden soll, ist keine harmonisierte Norm.

Damit sei nicht von diesen Zertifizierungen abgeraten. Vielmehr sollen die Hoffnungen auf einen „sicheren“ Konformitätsbeweis relativiert werden.

f) Hoher Preis und eine Alternative

Mit 270 CHF ist die Norm vergleichsweise teuer. Trotzdem sei sie zum Kauf empfohlen.

Der Leitfaden zur IT Sicherheit für Medizinprodukte, den das Johner Institut gemeinsam mit dem TÜV Süd entwickelt hat, enthält vergleichbare Anforderungen, ist noch spezifischer für Medizinprodukte und dabei kostenlos. Er ist ab dem 22.11.2018 verfügbar.