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

Dienstag 6. November 2018

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.

Familie der IEC 62443 Normen

Abb. 1: Übersicht über die Normenfamilie IEC 62443 (zum Vergrößern klicken)

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:

IEC 62443-4-1 Life-Cycle

Abb. 2: Die „Ansätze“ („Practices“) als Teil des Produkt-Lebenszyklus (zum Vergrößern klicken)

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).

IEC-62443-4-1 in der Übersicht

Abb. 3: Übersicht über den Aufbau der IEC 62443-4-1 (zum Vergrößern klicken)

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.

IEC 62443-4-1: Practice 1

Abb. 4: Jeder „Ansatz“ („Practice) umfasst mehrere Aspekte wie hier am Beispiel „Verwaltung der IT-Sicherheit“ (englisch: „Security Management“) zu sehen. (zum Vergrößern klicken)

Downloads

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.

War dieser Artikel hilfreich? Bitte berwerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Autor des Beitrags " IEC 62443-4-1: IT-Sicherheit als Teil das Produktlebenszyklus

Johner Institut GmbH

Logo Johner Institut klein

Bewertung 0 von 5 bei 0 Bewertungen


Kategorien: Software & IEC 62304
Tags:

9 Kommentare über “IEC 62443-4-1: IT-Sicherheit als Teil das Produktlebenszyklus”

  1. Peter Pianegonda schrieb:

    im Navigator zuoberst rechts hat es einen kleinen Druckfehler:

    IST 62443-5-1
    SOLL 62443-4-1

    Vielen Dank für das Lesen, Zusammenfassen und Aufbereiten.

    Peter Pianegonda

  2. Prof. Dr. Christian Johner schrieb:

    Sie haben ja so Recht! Danke, lieber Herr Pianegonda!

    Danke Ihrer Hilfe konnte ich den Fehler korrigieren. Danke!

  3. Cord schrieb:

    Hallo,
    wo ist denn der Leitfaden von Ihnen und dem TÜV Süd verfügbar?

  4. Prof. Dr. Christian Johner schrieb:

    Sie können den Leitfaden hier herunterladen

  5. Christian Beck schrieb:

    Hallo Herr Johner,
    sie schreiben in ihrem Leitfaden: „Es besteht in Europa (im Gegensatz zu den USA) auch keine Pflicht, ein spezifisches Dokument zur IT-Sicherheit
    zu erstellen.“
    Frage dazu: Ist mit dem spezifischen Dokument hier die „Cybersecurity Bill of Materials (CBOM)“ gemeint?
    Viele Grüüße, C. Beck

  6. Gilbert Semmer schrieb:

    Hallo Christian,
    mal wieder eine super Analyse und Darstellung eines Standards 🙂
    Mir fällt dabei auf, dass keine der 57 Aspects oder 8 Practises „Security Risk“ explizit benennt.
    Risk Management ist ja ein zentraler Aspekt bei Medical Devices (MD), insbesondere vernetzte MDs (ISO/IEC 80001 family).
    Die AAMI TIR57 stellt den Zusammenhang zwischen Security & Safety Risks gut dar, orientiert sich dabei aber leider an NIST 800, die eher ganze Organisationen betrifft.
    Vielleicht sollte man als Fazit darauf hinweisen, dass es eine spezifische IEC 62443-3-2 „security risk assessment process“ als der der Standards-Family gibt. Dies sollte meiner Ansicht nach ein zentraler Teil eines Secure product development lifecycle sein.
    Note: „security risk assessment“ ist sehr spezifisch, braucht damit spezielle Guidelines (s.a. AAMI TIR57), und es reicht nicht, dies mit einem Satz a là „risk management requirements are woven into the requirements throughout the product life cycle“ abzuhandeln.

    Beste Grüße
    Gilbert

  7. Prof. Dr. Christian Johner schrieb:

    Lieber Gilbert, ich stimme Dir absolut zu! Das werde ich aktualisieren!

    Im IT-Security-Leitfaden haben wir die Aktivitäten explizit in den Software-/Produktlebenszyklus mit eingewoben. Dieser Leitfaden wird inzwischen auch bei Behörden und benannten Stellen als Standard referenziert, genannt und genutzt.

    Liebe Grüße, Christian

  8. Felix Schirmer schrieb:

    Naja, also ob die 62443 so empfehlenswert ist, da bin ich mir nicht sicher. Wir fertigen beispielsweise Produkte für Industriekomponenten und überlegen, nach -4-2 zertifizieren zu lassen. In der -4-2 steht drin, als common requirement, dass die Komponente nach -4-1 entwickelt worden sein muss. Eine explizite Anforderung, ob jetzt eine -4-1 Zertifizierung erforderlich ist, steht allerdings nicht drin. Und obwohl wir bei uns natürlich nach modernem SDLC entwickelt und so wohl auch die Anforderung nach -4-1 bestehen würden, kriege ich von KEINEM der üblichen Verdächtigen Zertifizierer eine klare Antwort auf die popeleinfache Frage:

    Brauche ich eine -4-1 Zertifizierung als Vorbedingung für eine -4-2 Zertifizierung?

    Neee. Nur rumgewiesel „lassen Sie uns telefonieren“ blabla „kommt drauf an“. Auf eine JA oder NEIN Frage. Unfassbar, dass so eine simple Fragestellung mit HORRENDEN Auswirkungen auf die Zertifizierungskosten von der 62443 nicht KLIPP UND KLAR geregelt ist. Das ärgert mich.

  9. Prof. Dr. Christian Johner schrieb:

    Sehr geehrter Herr Schirmer,

    danke für Ihre Gedanken.

    Es geht in diesem Beitrag nicht um eine Zertifizierung. Eine Zertifizierung unter dem Dach der DaKKS gibt es für Medizinprodukte auch gar nicht. Damit sind alle entsprechenden Zertifikate nur bedingt wertvoll und erzwingen v.a. keine Konformitätsvermutung.

    In anderen Beiträgen u.a. zur „Zertifizierung nach IEC 62304“ warnen wir sogar vor Beutelschneiderei durch Zertifzierungen.

    Beste Grüße, Christian Johner

Kommentar schreiben