Cyberangriffe auf Medizinprodukte abwehren
Im Umkreis der amerikanischen Verwaltung – Department of Defense, Homeland Security, Department of Veterans Affairs, Food and Drug Association, National Electrical Manufacturers Association – enstandene Texte definieren Maßnahmen zur Sicherheit eines Produkts. Etwa der Standard HN 1–2013 der NEMA: „Manufacturer Disclosure Statement for Medical Device Security“ MDS2, die SP 800–53A des NIST: “Assessing Security and Privacy Controls in Federal Information Systems and Organizations Building Effective Assessment Plans“ oder SP 800–53 “Security and Privacy Controlsfor Federal Information Systems and Organizations“.
Aus Europa könnte das ETSI TR 103 305–1 V2.1.1 „Critical Security Controls for Effective Cyber Defence“ genannt werden. Ergänzt werden solche Veröffentlichungen durch nicht bindende Dokumente wie die „Common Weakness Enumeration“, „Common Criteria“, „CIS Critical Security Controls“ und viele mehr.
In solchen Dokumenten werden Anforderungen definiert wie:
- kann das Produkt Patientendaten verschlüsseln?
- wie kann sichergestellt werden, dass solche Daten beim Versenden nicht manipuliert werden?
- ist das Betriebssystem auf dem letzten Patch-Level, wie wird dieser aufgespielt und sichergestellt, dass keine unerwünschte Fremdsoftware auf dem Produkt installiert wird?
- „Off–the-Shelf-Software“ ist auf dem letzten Patch-Level.
- minimale administrative Rechte.
- nur notwendige Dienste, User, Shares, Ports sind eingerichtet.
- kein Booten von Wechseldatenträgern.
- Begrenzung des Netzwerkverkehrs auf vertrauenswürdige IPs.
- Zwei-Faktor-Authentifikation für administrative Benutzer. Ein Audit-Trail wird erstellt und kann archiviert und digital signiert werden.
- personenbezogene Daten auf USB Datenträgern sind zu verschlüsseln.
- Schulung der Entwickler.
- Benennen von Beauftragten im Incident Response Management.
Allen diesen Dokumenten ist gemeinsam, dass sich aus ihnen Listen zu Sicherheitsaspekten ableiten lassen. Solche Listen von Sicherheitsanforderungen werden in der Design-Phase eines Produkts erstellt und nach allen wesentlichen Änderungen überprüft. Änderungen können intern (am Produkt ändert sich etwas) wie extern (benutzte Software bekommt einen sicherheitsrelevanten Patch) sein. Die Überprüfung der Sicherheitsanforderungen ist mit der Freigabe nicht beendet, sondern auf den ganzen Lebenszyklus des Produkts auszuweiten.
Die Herausforderung besteht darin, für jedes Listenelement festzulegen, welchen Wert und welche Konsequenz diese Anforderung für das Produkt hat. Wenn die Netzwerkverbindung, die ein Servicetechniker braucht, einmal nicht zustande kommt, ist das ärgerlich und kann hoffentlich durch Verwendung von Wechseldatenträgern umgangen werden, für eine Webapplikation jedoch ist ein solcher Ausfall schädlich.
Als Zweites ist die Wahrscheinlichkeit zu bestimmen, mit der solche Ereignisse eintreten können. Das Ausspionieren von Passwörtern über die Meltdown/Spectre-Lücke soll hier als Beispiel dienen. Über diese Lücke wird versucht, den Speicher eines anderen Prozesses, aber auch des Betriebssystems, auszulesen. Die Wahrscheinlichkeit ist eigentlich immer gegeben, wenn ein Anwender das Produkt bedient.
Die Voraussetzungen, diesen Hack überhaupt durchführen zu können, sind aber sehr hoch. In der Regel sollte der normale Anwender überhaupt keine Command-Shell öffnen dürfen und das System sollte durch eine Whitelist geschützt sein. D.h. die Wahrscheinlichkeit, dass der Cyberangriff erfolgreich durchgeführt wird, ist geringer als im ersten Moment erwartet.
Als dritter Schritt ist zu bewerten, wie groß der Aufwand ist, eine Sicherheitslücke zu schließen. Meltdown/Spectre kann nur extern geschlossen werden, aber Maßnahmen, um den Angriff zu erschweren, sind empfehlenswert und durchführbar.
Aus mindestens diesen drei Schritten besteht eine Risikoanalyse, auch als Risk and Threat Analysis bezeichnet. Es entsteht eine Matrix zu Sicherheitseigenschaften des Produkts.
Für größere Produkte empfiehlt sich der Einsatz von Werkzeugunterstützung. Aber das ist eine andere Geschichte.
Die angerissenen Schritte können nur passive Sicherheit gewährleisten. Denn bisher wurden Sicherheitsaspekte betrachtet, die allgemeiner Natur sind, die Listen aus den angesprochenen Dokumenten, oder sicherheitsrelevante Fehler, die andere schon gefunden haben, wie Patchdays von Software-Herstellern. Fehler im eigenen Produkt werden dadurch nicht berücksichtigt. Aktive Sicherheit kann nur durch produktspezifische Tests gefunden werden. Erst statische Codeanalyse, Fuzzing und Penetrationtests können aktive Sicherheit gewährleisten. Die nächste Geschichte, die zu erzählen wäre …
Und ein abschließender Punkt: Schon der Testing Guide 4 von OWASP stellte fest, dass zwar die Zeit zwischen der Entdeckung einer Gefährdung und ihrem Patch gleich bleibt, die Zeit bis zur aktiven Ausnutzung aber immer kürzer wird. Umso notwendiger wird die Durchführung der angeführten Schritte zur Risikoanalyse und regelmäßiger Test des Produkts auf Sicherheitslücken.
Sie möchten mehr über dieses Thema erfahren? Dann sprechen Sie mich bitte jederzeit an. Ich freue mich auf das Gespräch mit Ihnen.
