Embedded-Systeme bilden häufig das Kernstück von lebens- und sicherheitskritischen Produkten. Dementsprechend fallen sie in den Anwendungsbereich zahlreicher Vorschriften und Standards, die ihre Sicherheit regeln. Hersteller analysieren diese Systeme auf eine Vielzahl möglicher Gefahren, die sich beispielsweise aus der Unzuverlässigkeit des Bauteils, Benutzerfehlern, physischem Missbrauch und möglichen Konstruktionsfehlern ergeben können. Mit der Vernetzung dieser Geräte kommt Datensicherheit jedoch als neues Risiko für die Gerätesicherheit hinzu.
Die Absicherung von Embedded-Systemen, auf die über ein Netzwerk fernzugegriffen werden kann, stellt für viele Hersteller eine Herausforderung dar. Der klassische Entwickler von Embedded-Systemen ist ein Laie auf dem Gebiet der Sicherheitstechnologie aus und kann nicht das Risiko eines potenziellen Hackerangriffs abschätzen, der eine Schwachstelle des Geräts ausnutzt. Leider ist die herkömmliche Welt der Informationstechnologie (IT) keine große Hilfe, weil die Experten in diesem Bereich sich nicht mit Embedded-Steuersystemen in Echtzeit, Sicherheitsrisikomanagement oder regulierter Softwareentwicklung auskennen.
Ein Ansatz
Mit dem zusätzlichen Merkmal der „Vernetzung“ vergrößert sich der Umfang eines Embedded-Systems auf das Netzwerk und möglicherweise alles, was daran angeschlossen ist. Es wurden zahlreiche Prozesse entwickelt, die eine effiziente und wirksame Analyse eines derartigen Systems und fundierte, intelligente Entscheidungen zur Abwendung der Sicherheitsbedrohung ermöglichen. Das nationale Normungsinstitut der USA (NIST) hat zwei solche Prozesse veröffentlicht: SP-800-30 und SP-800-39.
Den Ausgangspunkt einer Sicherheitsanalyse bildet ein Bedrohungsmodell, das durch eine Auflistung der Bedrohungen, Schwachstellen und Assets im Kontext des Gesamtsystems entsteht. Anschließend wird ein formaler Ansatz angewendet, der als Entscheidungshilfe dient, an welchen Stellen evtl. zusätzliche Sicherheitskontrollen erforderlich sind und welche Teile des Systems das größte Sicherheitsrisiko bergen. Das Sicherheitsrisiko wird normalerweise anhand des „CIA-Dreiecks“ analysiert: Vertraulichkeit (Confidentiality) (der Zugriff auf das System (einschließlich Daten) erfolgt nur auf festgelegte Weise), Integrität (das System wird nur auf festgelegte Weise verändert oder bearbeitet) und Verfügbarkeit (Availability) (das System ist zugänglich und betriebsbereit, wenn es benötigt wird).
Ebenfalls kritisch für die Entwicklung sicherer Embedded-Systeme ist die Umsetzung eines sicheren Entwicklungslebenszyklus, um ein kontinuierliches Risikomanagement zu gewährleisten. NIST SP 800 und andere Standards anerkennen die Wichtigkeit der Festlegung von Sicherheitsvorgaben – sowohl am Anfang als auch während des Lebenszyklus eines Geräts. Dies kann dadurch erfolgen, dass der normale „Anwendungsfall“ um eine Reihe von Fällen missbräuchlicher Anwendung erweitert wird, die dokumentieren, was ein Angreifer versuchen könnte, und die bereits vom Design her unterbunden werden müssen.
Risikoanalyse und Entscheidungsfindung müssen sich über den gesamten Lebenszyklus fortsetzen. Die Hardware-/Softwarearchitektur sollte auf Schwachstellen analysiert werden, und es sollten Sicherheitskontrollen zur Verringerung potenzieller Sicherheitslücken eingerichtet werden. Es sind Strategien für die Codeanalyse und sicherheitsbasierte Tests, wie Fuzz-Tests und Penetrationstests, zu entwickeln.
Dabei muss man sich bewusst sein, dass es bei der Adressierung des Sicherheitsrisikos nicht möglich ist, den Nachweis für die Sicherheit eines Geräts zu erbringen. Man kann lediglich die Messlatte höher ansetzen, um sicherer sein zu können, dass einfache Exploits erfolglos sein werden. Dementsprechend ist es wichtig, Methoden für die Erfassung von Informationen von im Einsatz befindlichen Geräten zu entwickeln, um unerkannte Schwachstellen zu identifizieren, und einen Mechanismus für die sichere Bereitstellung von Patches einzurichten, wenn neu erkannte Probleme die für das Risiko festgelegte Reaktionsschwelle überschreiten.
Beispiel: Medizinische Geräte
Die vorstehend erläuterten Aspekte sind besonders kritisch und aktuell im Fall von medizinischen Geräten. Mit dem US-amerikanischen Health Information Technology for Economic and Clinical Health (HITECH) Act von 2009 wurde ein Anreiz für die Verwendung elektronischer Patientendatensysteme geschaffen, was den Anstoß gab, ein breites Spektrum medizinischer Geräte in diese Systeme zu integrieren.
Die Vorteile, die eine derartige Integration mit sich bringt, liegen auf der Hand: Eliminierung von Fehlern auf Papier und bei der manuellen Übertragung, Entlastung des Krankenhauspersonal und kontinuierliche Überwachung mit Warnmeldungen, um nur einige zu nennen. Die Risiken sind vielleicht nicht ganz so offensichtlich. Da ein medizinisches Gerät mit Embedded-Elektronik entweder Informationen erfasst, die für die Diagnose eines Patienten verwendet werden (z. B. bettseitige Überwachungsgeräte) oder zur direkten Behandlung eines Patienten dienen (z. B. Infusionspumpen), kann die nicht ordnungsgemäße Funktionsweise eines elektronischen medizinischen Geräts dem Patienten Schaden zufügen. Böswillige (oder inkompetente) Anwender können den Patienten beeinträchtigen.
Nehmen wir als konkretes Beispiel eine bettseitige Infusionspumpe, die dem Patienten eine genau dosierte Menge eines Arzneimittels zuführt. Eine Über- oder Unterdosierung kann gefährlich oder sogar tödlich sein. Tatsächlich nennt das unabhängige Forschungsinstitut ECRI in einem kürzlich veröffentlichten Bericht1 „Medikationsfehler mittels Infusionspumpen“ als zweithäufigste technische Gefahrenquelle. Da es sich um ein eigenständiges Gerät handelt, wurden viele ausgeklügelte Merkmale, wie lokale Alarme für Trockenlauf, Überlauf, Verschlussalarm, Nachfüllalarm usw., hinzugefügt, um viele dieser Sicherheitsgefahren zu mindern.
Die lokalen Alarmvorrichtungen wurden mit einer Netzwerkschnittstelle ergänzt, die den Alarm an ein entferntes Stationszimmer übermittelt. Um Fehler bei der Behandlung des richtigen Patienten mit dem richtigen Medikament in der richtigen Dosierung zu minimieren, wurden Arzneimittelhandbücher, Barcode-Scanner und Fernzugriff auf Patientengewicht und Verschreibungsstatus hinzugefügt. Auf das CIA-Dreieck zurückzukommend, ergeben sich bei dem neu vernetzten Gerät einige problematische Aspekte.
Vertraulichkeit
Eine Infusionspumpe enthält Daten wie den Namen des Patienten, eine Patientenkennung (möglicherweise die Nummer seiner Krankenakte) und Informationen über das verabreichte Medikament und dessen Dosierung. Gemäß den Datenschutzbestimmungen des HIPAA handelt es sich bei diesen Daten um geschützte Gesundheitsinformationen, die vertraulich zu behandeln sind. Es liegt auf der Hand, dass diese Daten bei der Übertragung über das Netzwerk (in beide Richtungen) angemessen verschlüsselt werden müssen. Die Analyse muss sich aber auch auf die im Gerät gespeicherten Daten erstrecken – insbesondere, wenn die Pumpe vom Patienten entfernt und wieder eingelagert oder an einen neuen Patienten angeschlossen wird.
Integrität
Zur Sicherstellung der Integrität der Pumpe ist eine Analyse der Mechanismen erforderlich, die den Zugriff auf die Pumpe vom Netzwerk aus kontrollieren. Natürlich müssen die Infusionseinstellungen, die die Arzneimittelzufuhr regeln, geschützt werden. Änderungen dürfen nur mit entsprechender Autorisierung möglich sein. Das Arzneimittelhandbuch und der Prozess zu seiner Aktualisierung müssen ebenso geschützt werden. Die Protokolle für den Zugriff auf Patientendaten, wie das Gewicht des Patienten und das verschriebene Medikament, müssen so angelegt sein, dass der Pumpe keine falschen Informationen übermittelt werden. Die Datenquelle muss angemessen authentifiziert werden, da das falsche Gewicht/der falsche Patient/die falsche Verschreibung die Gesundheit des Patienten schädigen kann.
Ein weniger offensichtlicher Teil, dessen Vertrauenswürdigkeit sichergestellt sein muss, ist die Pumpensoftware selbst. Wenn ein Angreifer die Gerätesoftware modifizieren oder ersetzen kann, sind alle in die legitime Software eingebauten Schutzvorrichtungen nutzlos. Es sollten Authentifizierungsmechanismen verwendet werden, die den Zugriff auf die Patch-/Neuprogrammierungsfunktion schützen. Durch Hinzufügen von kostengünstigen Hardwareoptionen wie dem Trusted Platform Module2 (TPM) lässt sich die Softwareintegrität während des Bootvorgangs mit hoher Sicherheit bestätigen.
Verfügbarkeit
Bei der Verfügbarkeit geht es unter anderem darum, sicherzustellen, dass die Pumpe selbst dann ihren normalen Betrieb fortsetzt, wenn ein böswilliger Akteur die Netzwerkverbindung stört. Ein Denial-of-Service-Angriff auf die Verbindung kann zwar dazu führen, dass die Pumpe nicht mehr auf ein anderes Medikament/einen anderen Patienten umgestellt werden kann, jedoch sollte das Gerät so robust konstruiert sein, dass es für den regulären Betrieb vom Netzwerk unabhängig ist. Wenn das Netzwerk für die Fernalarmierung verwendet wird, können Warnmechanismen am Gerät vorgesehen werden, falls mit dem Downstream-Alarmmanager keine sichere Verbindung aufrechterhalten werden kann.
Fazit
Wie das Fallbeispiel zeigt, wird Datensicherheit ein wichtiger Aspekt der Gerätesicherheit, sobald ein Gerät mit Embedded-Elektronik an ein Netzwerk angeschlossen wird. Gleichzeitig nimmt die Komplexität des Systems massiv zu. Zum Glück gibt es Prozesse und Verfahren, wie die oben genannten NIST-Beispiele, die eine formale Methodik zur Bewertung der Sicherheitsrisiken in einem System und Priorisierung der Minderungsmaßnahmen zur Adressierung dieser Risiken bereitstellen.