Die ISO 27034 trägt den Titel Informationstechnik – IT Sicherheitsverfahren – Sicherheit von Anwendungen. Sie wird u.a. im Leitfaden des BSI referenziert.

Doch mancher Hersteller fragt sich: Muss ich auch noch diese Norm lesen? Muss ich damit rechnen, dass mein Auditor diese Norm (mit Verweis auf den Stand der Technik) einfordert?

Lesen Sie diesen Artikel, bevor Sie diese Norm für teures Geld kaufen und Zeit für deren Studium aufwenden (es sind Hunderte von Seiten), und entscheiden Sie dann.

1. ISO 27034: Weshalb Sie diese Norm überhaupt in Betracht ziehen sollten

a) Weil mangelnde IT-Sicherheit Schäden verursacht und Patienten gefährdet

Jährlich traurige Rekorde zu Angriffen, neuer Schad-Software, geschädigten Firmen und Patienten machen klar: Wir haben die IT-Sicherheit der meisten Anwendungen nicht im Griff.

Eine Norm wie die ISO 27034 kann dabei helfen, Best Practices kennenzulernen und schließlich auch anzuwenden, um die IT-Sicherheit der eigenen Produkte und Systeme zu verbessern.

b) Weil IT-Sicherheit eine regulatorische Anforderung ist

Die Anzahl der regulatorischen Anforderungen mit Bezug zur IT-Sicherheit und zum Datenschutz explodiert geradezu. Zu diesen Anforderungen zählen zum einen branchenunabhängige Vorschriften, z.B. die NIS Richtlinie (Directive on security of network and information systems) und die Datenschutzgrundverordnung (DSGVO), zum anderen branchenspezifische Regulierungen.

Bei Medizinprodukten stellen die EU-Medizinprodukteverordnungen (MDR, IVDR) ebenso Anforderungen an die IT-Sicherheit wie die deutsche Verordnung für digitale Gesundheitsanwendungen (DiGAV).

Weiterführende Informationen

Sie finden hier eine Übersicht über die regulatorischen Anforderungen an die IT-Sicherheit von Medizinprodukten bzw. für das Gesundheitswesen.

c) Weil Sie den Stand der Technik nicht nur im Audit kennen müssen

Allerdings sind diese Gesetze und Verordnungen nicht in der Lage, dem technologischen Fortschritt in der Geschwindigkeit zu folgen, die notwendig wäre, um konkrete Vorgaben machen zu können. Daher fordern die Regularien, dass die Hersteller die IT Security ihrer Produkte nach Stand der Technik gewährleisten müssen.

Diesen Stand der Technik beschreiben Normen. Dass die IEC 27034 dazu zählt, bestätigt auch das BSI in seinem Leitfaden zur Sicherheit von Medizinprodukten.

Als Hersteller oder Betreiber von Medizinprodukten sollten Sie im Audit zumindest von der ISO 27034 gehört haben und es begründen können, wenn Sie diese Normenfamilie nicht angewendet haben.

2. Übersicht über die ISO 27034

a) An wen sich die ISO 27034 wendet

Die Normenfamilie wendet sich an eine sehr breite Leserschaft:

  • Manager inklusive Projektmanager, IT Security Manager, Verantwortliche für Software-Anwendungen
  • Technische Teams wie Software-Architekten, Software-Entwickler und -Tester, Systemadministratoren und anderes technisches Personal
  • Einkäufer von Software
  • Dienstleister, die Software entwickeln oder/und bereitstellen und die Sicherheit dieser Software gewährleisten müssen
  • Auditoren
  • Anwender, die Software installieren und nutzen

b) Ziele und Nicht-Ziele der ISO 27034

Die ISO 27034 verfolgt die Ziele,

  • Konzepte, Prinzipien und Prozesse zu vermitteln,
  • Hersteller dabei zu unterstützen, IT-sicherheitsbezogene Anforderungen risikobasiert festzulegen,
  • Hilfestellungen zu geben für den Nachweis der IT-Sicherheit von Anwendungen und
  • die Anforderungen der ISO 27001-Familie umsetzbar zu machen.

Leider möchte die ISO 27034 keine konkreten Maßnahmen festlegen, auch keine Kodierregeln. Sie erhebt auch nicht den Anspruch, selbst ein Standard zu sein für Software-Lebenszyklus-Prozesse, für das Projektmanagement und für die Entwicklung.

c) Übersicht über die ISO 27034-Familie

Bezeichnung

Name

Veröffentlichung

ISO/IEC 27034-1

Überblick und Konzept

2011 (Bestätigung 2017)

ISO/IEC 27034-2

Organisation des normativen Rahmens

2015

ISO/IEC 27034-3

Managementprozess für die Sicherheit von Anwendungen

2018

ISO/IEC 27034-4

Validierung und Verifizierung

2020 (DIS-Status)

ISO/IEC 27034-5

Protokolle und Datenstruktur zur Kontrolle der Anwendungssicherheit

2017

ISO/IEC TS 27034-5-1

Protokolle und Datenstruktur zur Kontrolle der Anwendungssicherheit, XML-Schema

2018

ISO/IEC 27034-6

Fallstudien

2016

ISO/IEC 27034-7

Modell zur Voraussage der Zusicherung von Sicherheitsanwendungen

2018

3. Die ISO 27034-1

Die ISO 27034-1 ist die einführende Norm. In Kapitel 5 beschreibt sie das Zusammenspiel mit den anderen Mitgliedern dieser Normenfamilie. In den Kapiteln 6 und 7.1. stellt sie allgemeine Konzepte vor.

Mindmap mit Übersicht über die Kapitelstruktur der ISO 27034-1
Abb. 1: Übersicht über die Kapitelstruktur der ISO 27034-1 (zum Vergrößern klicken)

Die Norm verfolgt einen ebenso ganzheitlichen wie akademischen Ansatz. Sie unterscheidet zwischen dem Framework auf organisatorischer Ebene (Organizational Normative Framework ONF, Kapitel 7.2 und 8.1) und dem Framework spezifisch für die jeweilige Applikation (Application Normative Framework ANF, Kapitel 7.3 und 8.3).

Skizze zeigt, wie die ISO 27041 Anforderungen und Best-Practices unterscheidet , die die Firma insgesamt betreffen, und solche, die sich auf eine spezifische Anwendung beziehen.
Abb. 2. Die ISO 27041 unterscheidet Anforderungen und Best Practices, die eine Firma insgesamt betreffen, und solche, die sich auf eine spezifische Anwendung beziehen.

a) Organization Normative Framework (ONF)

Auf der Ebene des ONF sollten Hersteller festlegen:

  • Die Prozesse mit Bezug zur IT-Sicherheit
  • Die damit verknüpften Rollen und Verantwortlichkeiten
  • Allgemeine Best Practices
  • Maßnahmenbibliothek (Application Security Control Library – ASC Library)

Die ISO 27034 fordert, diese Festlegungen spezifisch für den Business-, den regulatorischen und den technologischen Kontext der Firma zu bestimmen (s. Abb. 3).

Bei Herstellern von Medizinprodukten zählen zum regulatorischen Kontext die o.g. Verordnungen und Gesetze. Der Business-Kontext könnte z.B. umfassen, dass der Hersteller Produkte mit einer bestimmten Zweckbestimmung entwickelt und als Software as a Service betreibt, wie das beispielsweise viele DIGA-Hersteller tun.

Auch wiederkehrende Anforderungsspezifikationen der Anwendungen können bereits auf Ebene des ONF in einem Repository gesammelt werden.

Das „Organization Normative Framework“ der ISO 27034 bestimmt allgemeine Festlegungen wie Prozesse und die Bibliothek der „Application Security Controls“ (ASC). Diese Festlegungen sollen die Firmen spezifisch für ihre jeweilige Kontexte treffen.
Abb. 3: Das Organization Normative Framework bestimmt allgemeine Festlegungen wie Prozesse und die Bibliothek der Application Security Controls (ASC). Diese Festlegungen sollen die Firmen spezifisch für den jeweiligen Kontext treffen.

b) Application Security Control (ASC)

Die Application Security Controls sind ein zentrales Konzept der ISO 27034, das sowohl auf Ebene der Organisation als auch auf Ebene der spezifischen Anwendung zum Einsatz kommt.

Die Norm definiert diese ASC wie folgt:

Definition: Application Security Control
data structure containing a precise enumeration and description of a security activity and its associated verification measurement to be performed at a specific point in an application’s life cycle
Quelle: ISO 27034-1

Die ISO 27034-5 beschreibt die Datenstruktur in Form von XML-Schema-Dateien.

Ein ASC umfasst folgende Informationen:

Element

Zugehörige Attribute

Beispiele

Identifikation des ASC

Name; ID; Autor; Datum; Verweise auf andere ASC und auf zugehörige Elemente des Kontexts

 

Ziel des ASC

Grund für das ASC; Level of Trust, das erreicht werden soll (s.u.); Bedrohung, die damit beherrscht werden soll; Element der Spezifikation, das damit in Verbindung steht

Ein ASC kann sich z.B. auf die Anforderung beziehen, dass ein Anwender korrekt authentifiziert wird.

Target Level of Trust = hoch

Aktivität

Beschreibung der Aktivität; zu erzielende Outputs; Methode, die anzuwenden ist; Gegenstand der Aktivität; Zeitpunkt der Aktivität; verantwortliche Rolle (mit notwendiger Qualifikation); damit verbundene Kosten

Entwickler soll freigegebene Java-Bibliothek verwenden, um die Session-Verwaltung zu implementieren. Das soll er während der Entwicklungsphase tun. Als Ergebniss wird erwartet, dass das Login im Audit-Log gespeichert wird und dass ein Unit-Test diese Funktion überprüft. Der Aufwand beträgt dafür 10 Tage.

Verifizierung der ASC

Auch hier muss angegeben werden, wer, was, wann, mit welchem Objekt, wie (mit welcher Methode) und zu welchen Kosten tut.

Die Überprüfung durch einen anderen Entwickler erfolgt anhand der Reviews des Audit-Logs und der dokumentierten Ergebnisse des Unit-Tests . Der Aufwand für die Überprüfung beträgt 1 Tag.

Die ISO 15408-3 und die NIST-Special Publication 800-53 enthalten Tausende dieser ASC. Bereits auf Ebene der Organisation sollen die ASC mit den zuvor genannten Kontexten und mit sogenannten Targeted Level of Trust arbeiten.

c) Targeted Level of Trust

Die ISO 27034 definiert den Targeted Level of Trust wie folgt:

Definition: Targeted Level of Trust
name or label of a set of Application Security Controls deemed necessary by the application owner to lower the risk associated with a specific application to an acceptable (or tolerable) level, following an application security risk analysis
Quelle

Letztlich darf die Organisation diese Labels selbst festlegen, z.B. „1 bis 5“ oder „niedrig“, „mittel“ und „hoch“. Sie gruppieren ASC, die gemeinsam für ein Trust-Level die notwendigen Aktivitäten festlegen.

Kontext

Spezifikationen, Einschränkungen

Target Level niedrig

Target Level mittel

Target Level hoch

Business-Kontext

Programmierung Defibrillator

 

ASC9

ASC12

Regulatorischer Kontext

IEC 60601-1

 

ASC22

ASC3

Regulatorischer Kontext

DSGVO

ASC11

 

ASC3

Technischer Kontext

Windows Betriebssystem

 

ASC22, ASC23

 

Applikationen

Login

ASC31

ASC12

 

d) Referenzmodell für den Application Security Life Cycle

Ähnlich wie bei einer SOP sollen Hersteller für ihren jeweiligen Kontext, aber noch unabhängig von der konkreten Anwendung, ein Referenzmodell für Prozesse mit Bezug zur IT-Sicherheit festlegen. Diese Prozesse müssen alle Phasen des Lebenszyklus der Anwendung umfassen:

  • Bereitstellung
    • Vorbereitung inklusive Erheben der Anforderungen
    • Outsourcing
    • Entwicklung
    • Kauf
    • Überführung in den Betrieb
  • Betrieb
    • Nutzung
    • Archivierung
    • Außerbetriebnahme

Für beide Phasen müssen auch die Prozesse beschrieben werden, um die zugehörige Infrastruktur zu „managen“ und alles zu auditieren.

Abb. 4: Die Prozesse des Referenzmodells müssen den ganzen Lebenszyklus abbilden
Abb. 4: Die Prozesse des Referenzmodells müssen den ganzen Lebenszyklus abbilden

Das Organization Normative Framework einschließlich seiner Prozesse muss selbst einem „Meta-Prozess“ unterworfen werden. Dieser hat ähnlich wie die Managementbewertung in einem ISO-13485-konformen QM-System das Ziel, das System (hier das ONF) kontinuierlich zu verbessern und an geänderte Kontexte anzupassen.

e) Application Normative Framework (ANF)

Mit dem Application Normative Framework (ANF) erzeugen die Organisationen eine applikationsspezifische Instanz des Organization Normative Frameworks (ONF). Dazu müssen Sie die spezifischen Anforderungen und Umgebungen bzw. Kontexte beschreiben und die Risiken abschätzen (s. Abb. 2).

Als Teil des ANF zählen vergleichbar dem ONF:

  • Kontexte
  • Prozesse
  • Akteure, Rollen, Verantwortlichkeiten
  • ASC mit zugehörigen Targeted Levels of Trust

Im Rahmen der Auditierung (Verifizierung, Validierung) nutzen die Auditoren/Prüfer die ASC, die das ANF benennt, und überprüfen damit sowohl das Projekt als auch das Produkt (s. Abb. 2).

4. Zusammenfassung & Empfehlungen

a) Die Stärke: ein präzises (Daten-)Modell

Die Familie der ISO 27034-Normen folgt einem holistischen und logischen Top-down-Ansatz. Beginnend mit präzisen Definitionen betrachtet die Norm den kompletten Kontext.

Davon ausgehend legt sie einen Prozess fest, der zuerst die allgemeinen Spielregeln auf Unternehmensebene, das Organization Normative Framework (ONF), bestimmt. Zu diesem Framework zählen Application Security Controls (ASC).

Dank einer spezifizierten Datenstruktur lassen sich diese ASC nicht nur wiederverwenden, sondern in einen firmen- und produktspezifischen Zusammenhang stellen.

Ähnlich wie bei QM-Systemen werden aus den allgemeinen Festlegungen spezifische Vorgaben abgeleitet. Bei QM-Systemen wären dies beispielsweise Entwicklungspläne; hier ist es das Application Normative Framework (ANF).

b) Die Schwäche: zu abstrakt für viele Organisationen

Doch genau in diesem ebenso systematischen wie komplexen Ansatz liegt auch die Schwäche: Die ISO 27034 alleine ist den Herstellern nur bedingt nützlich. Sie müssen den Weg von einer Meta-Ebene hin zum konkreten Produkt gehen. Dabei dürfen Sie die Risiken gemäß ISO 27034 nicht mit den Risiken gemäß ISO 14971 verwechseln.

Dieser mehrstufige Prozess zur Konkretisierung und zum Mapping auf die spezifische Situation dürfte die meisten Firmen, insbesondere die kleineren, überfordern. Sie benötigen konkrete und spezifische Anleitungen, was zu tun ist.

c) Alternativen nutzen

Leitfäden des Johner Instituts bzw. der Benannten Stellen

Hersteller sind besser mit dem Leitfaden des Johner Instituts bedient, den die Benannten Stellen in adaptierter Form inzwischen übernommen haben. Denn er konsolidiert Dutzende regulatorischer Vorgaben und nennt direkt überprüfbare Anforderungen an die IT-Sicherheit der Produkte und die Gestaltung von Prozessen mit Bezug zur IT-Sicherheit.

Dieser Leitfaden erspart nicht nur das Lesen all dieser Regularien, sondern auch den Transfer von den abstrakten Ebenen einer ISO 27034 in das konkrete Projekt.

Konkretes Prozessmodell

Damit haben die Hersteller auch einen Secure Development Life Cycle implementiert, wie ihn die ISO 27034 als ein mögliches Beispiel im informativen Anhang nennt.

An den Secure Software Development Lifecycle angelehnter Entwicklungsprozess
Abb. 5: An den Secure Software Development Lifecycle angelehnter Entwicklungsprozess

d) Klug mit Auditoren argumentieren

Wenn ein Auditor z.B. in Bezugnahme auf den BSI-Leitfaden fragt, ob man konform der ISO 27034 arbeitet, bieten sich folgende Argumente an:

  1. Der BSI-Leitfaden schlägt die ISO 27034 nur als Beispiel vor. Als anderes Beispiel nennt er die IEC 62304. Damit lässt sich die Konformität einfacher nachweisen.
  2. Die ISO 27034 stellt keine konkreten Anforderungen im Sinne von ASC. Vielmehr wende man einen Lebenszyklus an, wie ihn die ISO 27034 im Anhang A skizziert, und nutze die ASC des Leitfadens des Johner Instituts bzw. der Benannten Stellen.
  3. Die Anforderungen an den ONF-Prozess erfülle man bei ISO 13485-Konformität. Das setzt aber voraus, dass z.B. das Management-Review auch tatsächlich die IT-Sicherheit der Produkte und der Organisation mit Ihrem Kontext bewertet.
  4. Der regulatorische Kontext sowie der Business-Kontext seien durch die Tätigkeit der Firma bereits ausreichend scharf beschrieben.

Auditoren sei daher empfohlen, keine Zeit mit Diskussionen über die ISO 27034 aufzuwenden und dafür die Einhaltung der grundlegenden Sicherheits- und Leistungsanforderungen einzufordern. Leider ist deren Mapping auf konkrete und überprüfbare Anforderungen im MDCG 2019-16 nicht wirklich gelungen.

e) Hände weg von der ISO 27034-4

Kaufen Sie nicht den Entwurf der ISO 27034-4. Denn dieser enthält v.a. leere Überschriften:

Screenshot der ISO 27034-4: Außer Überschriften enthält der Normenentwurf stellenweise nichts.
Abb. 6: Dieser „Entwurf“, der teilweise nicht mehr als Überschriften enthält, ist kostenpflichtig.

Dafür Geld zu verlangen, dürften viele als fragwürdig empfinden.

f) Fazit

Sie sollten wissen, um was es in der ISO 27034 geht. Mit dem Lesen dieses Artikels haben Sie sich mit vielen wichtigen Konzepten bereits vertraut gemacht.

Wenn Sie über ausreichende Ressourcen verfügen, dann kaufen, lesen und befolgen Sie die ISO 27034.

Laufen Sie dagegen Gefahr, im akademischen Dickicht stecken zu bleiben? Dann sind Sie besser beraten, wenn Sie die Gesetze studieren und mit dem Leitfaden bzw. mit einem konkreten Prozessmodell wie dem oben gezeigten sicherzustellen, dass Sie

  • die regulatorischen Anforderungen erfüllen und
  • die IT-Sicherheit Ihrer Produkte und
  • damit die Safety gewährleisten.

Denn es geht letztlich um eines: um Ihre Patienten.

Wie hilfreich war dieser Beitrag?

Bitte bewerten Sie:

Durchschnittliche Bewertung 4.9 / 5. Anzahl Bewertungen: 14

Geben Sie die erste Bewertung!


Kategorien: Software & IEC 62304

4 Kommentare

  1. Bettina Zucker | Dienstag, 1. Dezember 2020 um 09:25 Uhr - Antworten

    Hallo Herr Prof. Johner,
    hier hat sich ein Zahlendreher eingeschlichen.
    Die ISO 27034 wird an mehreren Stellen als ISO 27043 genannt.
    Das ist eine andere Norm der ISO 27000 Reihe.
    Mit freundlichen Grüßen
    Bettina Zucker


    • Prof. Dr. Christian Johner | Dienstag, 1. Dezember 2020 um 09:31 Uhr - Antworten

      Sie haben absolut Recht, Frau Zucker!

      Vielen Dank für Ihren Hinweis! Damit konnte ich das sofort fixen!

      Beste Grüße, Christian Johner


  2. Peter Beck | Dienstag, 1. Dezember 2020 um 09:46 Uhr - Antworten

    Hallo Herr Prof. Johner,

    noch ein Zahlendreher? In Abschnitt 2 b) steht „Leider möchte die ISO 27042 keine konkreten Maßnahmen festlegen,…“, obwohl es sonst um die 27034 geht.

    Wir haben uns in der technischen Dokumentation unseres Softwareprodukts beim Stand der Technik auf den IT Security Leitfaden bezogen (was die benannte Stelle dazu sagt kann ich allerdings noch nicht berichten 😉

    LG,
    Peter Beck


    • Prof. Dr. Christian Johner | Dienstag, 1. Dezember 2020 um 09:54 Uhr - Antworten

      Auch Ihnen besten Dank, Herr Beck!
      Ich war (und bin) etwas in Eile. Da sollte man keine Überarbeitungen machen.
      Nochmals vielen Dank!


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.