ISO 27034 zur Sicherheit von Anwendungen: Lesen = Zeitverschwendung?

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

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.

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

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.

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:

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:

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.

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.

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:

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.