Threat Modeling – eine Einführung

Das Threat Modeling ist für Sie ein „Pflichtthema“, wenn Sie Medizinprodukte herstellen, die Software enthalten oder die Software sind. Denn das Threat Modeling ist ein strukturierter Prozess zur systematischen Analyse von IT-Sicherheitsrisiken, den Auditoren als den „Stand der Technik“ voraussetzen.

1. Weshalb Sie das Threat-Modeling nutzen sollten

Grund 1: Sichere Produkte entwickeln

Das Threat Modeling trägt dazu bei, dass Sie Cybersecurity-Risiken systematisch finden und beseitigen und damit die IT-Sicherheit Ihrer Produkte gewährleisten können.

Damit kommen Sie Ihrer ethischen Pflicht nach und tragen Sorge für die Sicherheit von Anwendern, Patienten und Dritten.

Grund 2: Gesetzliche Anforderungen erfüllen

Sie sind nicht nur ethisch, sondern auch gesetzlich verpflichtet, die IT-Sicherheit Ihrer Produkte zu gewährleisten.

Weil das Threat Modeling ein systematischer Prozess ist, hilft die Anwendung Ihnen in der Argumentation gegenüber Behörden und Benannten Stellen, dass Sie keine Schwachstellen übersehen haben.

Grund 3: Entwicklung beschleunigen, Kosten sparen

IT-Sicherheit kostet Geld. Aber noch teurer wird es, wenn man Schwachstellen zu spät erkennt und darauf reagieren muss. Dann entstehen zusätzliche Kosten für

• die nachträgliche Analyse der Schwachstellen,
• das Beseitigen der Schwachstellen (im Worst Case durch ein Re-Design der Produkte),
• die Kompensation geschädigter Personen,
• die Rechtsfolgen und
• die Wiederherstellung der eigenen Reputation.

Je früher Hersteller also Schwachstellen entdecken, desto einfacher, schneller und kostengünstiger können sie diese beheben. Daher sollten die Hersteller das Threat Modeling bereits während der Produktentwicklung anwenden.

Grund 4: Transparenz und „Peace of Mind“

Durch die nachvollziehbare und grafische Methodik des Threat Modelings entsteht Transparenz über die Sicherheit des eigenen Produkts. Durch die Systematik erhalten Sie Gewissheit, die Risiken vollständig identifiziert und beseitigt zu haben. Und das gibt Ruhe – einen „Peace of Mind“.

2. Welche Notationselemente es gibt

Wie der Name bereits sagt, arbeitet das Threat Modeling mit Modellen.

Diese Modelle nutzen wenige Notationselemente, die schnell zu erlernen sind:

Notationselement	Bezeichnung	Beispiele
	Externe Entität	Menschen (z. B. Anwender), Systeme (z. B. andere Produkte), Cloud-Services, Browser
	Prozess	DDL, exe(D)COM, Webservice, virtuelle Maschine, Threat
	Datenspeicher	Datei, Datenbank, Registry, Cache, Cookie
	Datenfluss	http Request oder response, Remote Procedure Call, UDP Kommunikation
	Trust Boundary (innerhalb vertraut man den Prozessen und Datenspeichern, außerhalb nicht)	Grenze des Produkts, Grenze des Prozesses

3. Wie das Threat Modeling abläuft

Schritt 1: Anwendungsbereich und Ziel festlegen

Zuerst gilt es, das Ziel und den Gegenstand des Threat Modelings zu bestimmen. Sollen die Schwachstellen eines Webservices modelliert werden oder die des ganzen Servers? Soll das Threat Modeling die Sicherheit eines Produkts im Nachhinein nachweisen oder soll es dem Entwurf einer sicheren Systemarchitektur dienen?

Schritt 2: Modell erstellen

Um das Modell zu erstellen, müssen die Hersteller alle Elemente zusammenstellen. Im Detail sind das:

• Prozesse des Systems
• Datenspeicher des Systems
• Vorgesehene und alle unerwünschten externen Entitäten (z. B. Angreifer)
• Mögliche, d. h. vorgesehene und unerwünschte Datenflüsse zwischen den Entitäten, Prozessen und Datenspeichern

Anschließend sollten die Hersteller die Elemente des Systems (Prozesse, Datenspeicher) durch die „Trust Boundaries“ abtrennen von den anderen Elementen, die sie als vertrauenswürdig halten. Bei einem physischen Medizinprodukt definiert man häufig die Elemente innerhalb des Geräts als vertrauenswürdig. Genau genommen sollten die Hersteller aber mit einem „defense-in-depth-Konzept“ arbeiten, das man sich wie Zwiebelschalen vorstellen kann, bei dem es mehrere Trust Boundaries gibt.

Als Ergebnis dieses Schritts erhalten Sie ein Modell wie das in der Abbildung 1 gezeigte.

Schritt 3: Die möglichen Bedrohungen identifizieren

Hat man das Modell erstellt, ergeben sich daraus die möglichen Bedrohungen (Threats) automatisch, wenn man ein entsprechendes Werkzeug wie das Threat Modeling Tool von Microsoft einsetzt.

Andernfalls müssen die Hersteller diese Bedrohungen manuell identifizieren. Diese lassen sich gemäß dem STRIDE-Modell in die folgenden Klassen einteilen:

	Angriffsklasse	Beschreibung	Beispiel
S	Spoofing	Vortäuschen, jemand anderes zu sein	Ein Hacker gibt vor, ein berechtigter Anwender zu sein.
T	Tampering	Daten oder Code verändern	Eine Malware verschlüsselt Daten.
R	Repudiation	Abstreiten, etwas getan zu haben	Ein Anwender streitet ab, dass er den Patienten mit bestimmten Parametern mit dem Produkt behandelt hat.
I	Information disclosure	Vertrauliche Informationen werden nicht berechtigten Personen angezeigt	Die Pflegekraft erhält Einblick in die Diagnose des VIP-Patienten, den sie gar nicht behandelt und dessen Daten sie nicht sehen dürfte.
D	Denial of service	DoS-Angriff	Ein Bot-Netzwerk überflutet einen Webserver mit http-Anfragen.
E	Elevation of privilege	Eine Person oder ein System verschaffen sich unberechtigt Privilegien.	Ein Anwender schafft es, sich zum Administrator eines Systems zu machen.

Als Ergebnis dieses Schritts erhalten Sie eine Liste der Bedrohungen.

Schritt 4: Bedrohungen bewerten

Nicht jede mögliche Bedrohung muss zu einer Maßnahme führen. Aber Sie als Hersteller müssen es begründen können, wenn Sie für eine mögliche Bedrohung keine Maßnahme festlegen.

Eine Begründung könnte darin bestehen, dass ein kompromittiertes System zu keinem Schaden für einen Patienten oder Dritten führen kann. Auch eine vernachlässigbar kleine Wahrscheinlichkeit dafür, dass das Produkt tatsächlich kompromittiert wird, kann als Begründung dienen.

Schritt 5: Maßnahmen festlegen und umsetzen

Falls die Risiken nicht akzeptabel sind, müssen Sie Maßnahmen festlegen. Für jede Klasse an Bedrohungen (gemäß STRIDE) gibt es typische Maßnahmen:

Angriffsklasse	Beispiele für Maßnahmen
Spoofing	Authentifizierung z. B. mit Kerberos
Tampering	Digitale Signaturen
Repudiation	Sichere Auditlogs
Information Disclosure	Verschlüsselung
Denial of Service	Filtern von Anfragen
Elevation of privilege	Access Control Lists (ACLs)

Diese Maßnahmen müssen Sie als Hersteller festlegen. Das kann erfolgen z. B. als Anforderungen an das System oder an Komponenten des Systems. Damit stellen Sie sicher, dass

1. diese Maßnahmen tatsächlich umgesetzt werden und
2. diese Umsetzung sowie die Wirksamkeit der Maßnahmen verifiziert werden.

Schritt 6: Vollständige Umsetzung prüfen

Spätestens vor der Freigabe Ihres Medizinprodukts sollten Sie sicherstellen, dass alle definierten Maßnahmen umgesetzt sind und deren Wirksamkeit nachgewiesen wurde.

Sie prüfen somit nicht nochmals die IT-Security Ihres Produkts, sondern die Konformität Ihres IT-Security-Prozesses (auch als Secure Development Lifecyle bezeichnet).

Reflektieren Sie an dieser Stelle Ihr Vorgehen. Passen Sie Prozess, Verfahrens- und Arbeitsanweisungen sowie Werkzeuge bei Bedarf an und/oder verbessern Sie die Ausbildung Ihres Teams. Dabei kann Ihnen das Seminar zur IT-Security hilfreich sein, um die entsprechenden gesetzlichen Anforderungen an die Kompetenz der Mitarbeitenden zu erfüllen.

4. Was Sie beim Threat Modeling beachten sollten

Tipp 1: IT-Security ist ein kontinuierlicher Prozess

Das Threat Modeling ist keine einmalige Aktivität. Sie sollten sie vielmehr regelmäßig wiederholen, insbesondere wenn Sie Ihr Produkt ändern oder wenn Daten aus dem Markt (z. B. aus der Post-Market Surveillance) Hinweise geben.

Tipp 2: Die analytische Qualitätssicherung nicht vergessen

Das Threat Modeling zählt zur konstruktiven Qualitätssicherung. Das ist die Qualitätssicherung (QS), die den Fokus auf das Vermeiden von Fehlern legt. Diese konstruktive QS muss durch eine analytische QS ergänzt werden, bei der der Fokus auf dem Finden von Fehlern liegt. Dazu zählt z. B. das Penetration Testing von Produkten.

Tipp 3: Nutzen Sie Werkzeuge

Ein Werkzeug wie das Threat Modeling Tool von Microsoft hilft Ihnen, mögliche Bedrohungen Ihrer Produkte und Systeme systematisch zu finden. Damit können Sie auch Ihre Entscheidungen über Maßnahmen dokumentieren und nachverfolgen.

Für das „Tracing“ von den festgelegten Maßnahmen empfehlen sich zu deren Überprüfung ALM-Werkzeuge, beispielsweise von Medsoto.

5. Welche regulatorischen Anforderungen es an das Threat Modeling gibt

Weder MDR noch IVDR noch der Food Drug and Cosmetic Act in den USA verpflichten die Hersteller zum Threat Modeling. Allerdings bestehen sie darauf, dass die Hersteller die IT-Sicherheitsrisiken minimieren.

Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.

MDR Anhang I Absatz 17.1

Diesen „Stand der Technik“ beschreiben Normen und Leitlinien wie z. B.:

• Leitfaden des Johner Instituts zur IT-Sicherheit
• Quellen der FDA zur Cybersecurity
• Playbook zum Threat Modeling (FDA gesponsert, aber keine offizielle FDA-Guidance)
• Die Norm IEC 81001-5-1 zur Sicherheit, Effektivität und Sicherheit von Gesundheitssoftware und Gesundheits-IT-Systemen
• MDCG 2019-16 rev. 1 „Guidance on Cybersecurity for medical devices“

Alle diese Dokumente erwähnen das Threat Modeling. Daher wird Herstellern die Begründung schwerfallen, weshalb sie auf das Threat Modeling verzichten.

6. Fazit

Die Grundlagen des Threat Modelings sind schnell erlernt, auch weil es gute Werkzeuge gibt und die Modellierungssprache nur wenige Notationselemente umfasst.

Die Systematik verschafft Herstellern ebenso wie Benannten Stellen und Behörden das notwendige Vertrauen in die IT-Sicherheit der Medizinprodukte.

Daher sollte das Threat Modeling bei allen Medizinprodukten, die Software sind oder Software enthalten, ein unverzichtbarer Teil des Secure Development Life Cycles sein.

---

Das Johner Institut unterstützt Medizinproduktehersteller dabei, sichere Medizinprodukte zu erstellen, z. B.

• mit Videoserien zur IT-Security im Auditgarant,
• mit dem Seminar zur IT-Security,
• bei der Erstellung der Software- bzw. Systemarchitektur sowie
• beim Penetration Testing.

Melden Sie sich einfach über die Webseite.