In der komplexen und vernetzten Welt von heute hat die Cyber-Security eine herausragende Rolle gewonnen. Nahezu jedes Produkt – von der Kaffeemaschine über Medizinprodukte bis hin zum Auto – sind vernetzt und Bestandteile des großen, weltumspannenden „Internet der Dinge“. Der Nutzer genießt die Vorzüge dieser Geräte und verflucht vielleicht seine Kaffeemaschine, die sich morgens nicht per App vom Bett aus bedienen lässt, weil ein Angreifer eine Sicherheitslücke ausgenutzt hat. Ein „Deny of Service“-Angriff auf eine Kaffeemaschine ist zwar unschön und lästig, jedoch hängt nicht Leib und Leben des Nutzers davon ab. Anders sieht es im Automotive- bzw. Medizinbereich aus, wo wir auf die Funktion des Bremssystems bzw. des Herzschrittmachers vertrauen.
Das Forschungsprojekt S3HIFT hat das Ziel die Zuverlässigkeit und Sicherheit von Systemen zu erhöhen. Es gilt den Entwicklungsprozess zu verbessern, so dass Sicherheitslücken und Schwachstellen in Systemen besser identifiziert, nachverfolgt und behoben werden können.
Ansatzpunkt ist, die Threat Assessment and Risk Analysis (TARA) zu verbessern, indem ein durchgängig automatisiertes, KI-unterstütztes Fuzz-Testing durchgeführt wird, welches neben den spezifizierten Systemschnittstellen auch Seitenkanalinformationen nutzt, um Anomalien und potenzielle Sicherheitslücken aufzudecken. Seitenkanäle sind z.B. Stromaufnahme, Wärmeentwicklung oder Geräusche des Systems. Sie kennen dies beispielsweise, wenn Ihr PC-Lüfter laut wird. Falls Ihr PC gerade komplexe Berechnungen durchführt, dann ist dies normal. Falls nicht, dann untersuchen Sie dies näher im Task-Manager, welcher Prozess eine so hohe Rechnerleistung benötigt, dass der Lüfter anspringt.
Besonderheit ist, dass dieser Ansatz nicht branchenspezifisch ist, sondern übergreifend genutzt werden kann. Konkret führen wir das Fuzz-Testing mit einem Automotive-Steuergerät durch und übertragen dieses Vorgehen auf ein Medizinprodukt („Push-Device“ zur Unterstützung von Herzdruckmassagen). Beide Branchen entwickeln sicherheitskritische Systeme, bei denen die Herausforderungen bzgl. Sicherheitslücken und Schwachstellen ähnlich kritisch sind.
Bei der Entwicklung von (sicherheits-) kritischen Systemen ist die „Threat Assessment and Risk Analysis“ (TARA) fester Bestandteil des Entwicklungsprozesses. Sie ist eine umfassende Methode zur systematischen Ermittlung, Bewertung und Bewältigung potenzieller Bedrohungen und Risiken im Zusammenhang mit einem Produkt. Durch den Einsatz von TARA gewinnen wir ein tiefes Verständnis für die Schwachstellen und Abhängigkeiten des Produkts.
Dieser Prozess ermöglicht es uns, die Arten von Angreifern zu antizipieren, die es auf das Produkt abgesehen haben könnten, sowie die verschiedenen Bedrohungen, die entstehen könnten. Durch eine detaillierte Risikoanalyse können wir diese Bedrohungen nach Prioritäten ordnen und wirksame Gegenmaßnahmen ergreifen, um so das Risiko für das Produkt und seine Benutzer zu verringern. Für das „Push-Device“ bietet TARA einen Rahmen, der sicherstellt, dass alle potenziellen Sicherheitslücken frühzeitig erkannt und proaktiv angegangen werden, wodurch die allgemeine Sicherheitslage des Produkts verbessert wird.
Fuzz-Testing ist Ende der 1980er Jahre von Barton Miller an der University of Wisconsin-Madison entstanden, um damit die Robustheit von UNIX-Programmen zu testen. Grundidee ist, mit Hilfe von Zufallseingaben die Programme zu testen, um unerwünschtes Systemverhalten oder gar Systemabstürze festzustellen. Da durch das Fuzz-Testing viele Schwachstellen identifiziert wurden, hat sich dieser Testansatz bewährt und ist heutzutage Bestandteil in der Softwareentwicklung – oder sollte es zumindest sein. Hierzu haben sich verschiedene Verfahren entwickelt, wie geeignete Eingabedaten generiert werden können, auf die wir später eingehen.
Vorteil vom Fuzz-Testing ist, dass Sicherheitslücken und Schwachstellen gefunden werden, die durch andere Tests nicht berücksichtigt worden sind. Auch eine systematische TARA liefert diese Art von Schwachstellenanalyse nicht. Insofern stell das Fuzz-Testing eine wertvolle Ergänzung dar.
Diese Einblicke ermöglichen es uns, unsere Sicherheitsanforderungen zu verfeinern und sicherzustellen, dass das Produkt robust genug ist, um potenziellen Angriffen zu widerstehen. Darüber hinaus können wir mit Hilfe von Fuzz-Tests überprüfen, ob das Produkt seine Funktionalität und Zuverlässigkeit auch bei unerwarteten Herausforderungen beibehält. Dieses umfassende Sicherheitskonzept erhöht nicht nur die Zuverlässigkeit des Produkts, sondern stärkt auch das Vertrauen der Kunden, indem es gewährleistet, dass ihre Bedürfnisse sicher und effektiv erfüllt werden.
Durch die Integration von TARA und Fuzz-Testing in einen Secure Development Process stellen wir sicher, dass das zu entwickelnde System resilient gegenüber Sicherheitsbedrohungen ist.
Abbildung 1: TARA-Prozessbild
Kern des Secure Development Process ist die TARA, wie sie in der Abbildung 1 dargestellt ist. Es gilt zunächst die Informationen zum System zu sammeln und zu dokumentieren. Im zweiten Schritt erfolgt die Analyse, welche Assets geschützt werden müssen. Als dritter Schritt werden Angriffsszenarien und potenzielle Angreifer ermittelt. Nachdem die Angriffsszenarien bekannt sind, kann eine Risikobewertung durchgeführt werden, die im letzten Schritt Abwehrmaßnahmen ableitet, wie z.B. weitere Sicherheitsanforderungen.
Im TARA-Prozess ist zudem eine Feedback-Schleife integriert, die prozesstechnisch sicherstellt, dass neue Erkenntnisse, wie z.B. eine neue Sicherheitslücke im Betriebssystem, betrachtet werden oder Risikobewertungen aktualisiert werden (z.B. veränderte Wahrscheinlichkeit oder Schadensausmaße).
Abbildung 2: Sub-Prozess Fuzz-Testing
Das Fuzz-Testing ist ein Sub-Prozess der TARA, um weitere mögliche Schwachstellen oder Sicherheitslücken zu entdecken (Prozessschritt 1: Systeminformationen sammeln). Falls Schwachstellen oder Sicherheitslücken identifiziert werden, so fließen diese Informationen in die Ermittlung der Angriffsszenarien ein.
Der Fuzz-Testing-Prozess ermittelt zunächst mit Hilfe eines Bewertungsmodells die Systemstelle, an der ein Angriff am wahrscheinlichsten ist. Dies ist ähnlich wie bei einer Wohnung oder einem Haus: Hier wird Einbrecher auch den einfachsten Weg wählen und keinen Tunnel graben und sich durch das Fundament durchbohren. Welcher Weg am wahrscheinlichsten ist, kann der Hausbesitzer durch eine Analyse ermitteln: Wie sicher sind Eingangs‑, Keller- und Terrassentüren und wie sicher sind die Fenster oder steht eine Leiter im Garten, mit deren Hilfe der Einbrecher in den ersten Stock einsteigen kann? Gleiches gilt für technische Systeme: Welche Schnittstelle(n) wird ein Angreifer höchstwahrscheinlich nutzen? In diese Betrachtung schließen wir mögliche Seitenkanäle ein, durch die Systeminformationen abfließen, die ein Angreifer oder wir als Fuzz-Tester nutzen können.
Diese Schnittstellen und Seitenkanäle stellen die ideale Konfiguration dar, um Fuzz-Testing durchzuführen. Der grundlegende Prozess hierfür ist:
Durch die Nutzung der Analyseergebnisse für die Generierung neuer Eingabedaten entsteht eine zweite Feedback-Schleife. Im Falle einer aufgedeckten Anomalie können die Eingabedaten gezielt variiert werden. So kann durch Variation oder Erweiterung der Eingaben getestet werden, ob weitere potenzielle Schwachstellen vorhanden sind.
Auf die technischen Details zur Umsetzung am Beispiel des „Push Device“ gehen wir später ein.
Das zufallsbasierte und automatisierte Fuzz-Testing liefert große Datenmengen, vor allem an Testdaten. Um diese zu bewältigen, müssen die Daten des Secure Development Process mit geeigneten Tools verwaltet werden, so dass sie für den Menschen lesbar, analysierbar und nachverfolgbar sind. Wir planen dazu folgende Tools zu nutzen:
Mit Hilfe des Enterprise Architect erstellen wird folgende Modelle:
Das modellbasierte Testen mit der MBTsuite ist ein bewährtes Tool von sepp.med, mit dessen Hilfe aus einem Testmodell eine große Anzahl von Testfällen generiert und automatisiert werden können. Es eignet sich daher ausgezeichnet, um das Fuzz-Testing durchzuführen bzw. zu visualisieren. Die Tester können durch Änderung der Testmodells den Testablauf ändern und variieren, ohne große Programmierkenntnisse für die Testautomatisierung zu besitzen.
Weitere Infos zur MBTsuite finden Sie hier: MBTsuite – „Model-Based Software Testing made easy“
Wir nutzen die MBTsuite, um Testfälle aus das Angriffsmodell zu generieren sowie für das Bewertungsmodell, um das „Testability Level“ (Wahrscheinlichkeitsmaß für einen Angriff) für die Konfigurationsvarianten zu ermitteln.
Alle relevanten Daten sollen dann in Jira fließen, welches wir als ALM-Tool nutzen wollen. PlugIns wie z.B. XRay sollen das Testmanagement unterstützen.
Auswerte- und Analysefunktionen werden hier mit Dashboards und Reports realisiert, so dass die Analyse und Nachverfolgbarkeit gegeben ist.
Die Testautomatisierung findet mit der Skriptsprache Python statt. Die MBTsuite generiert ausführbare Python-Skripte, die ausgeführt werden. Die Testspezifikation, Testskripte sowie die Testergebnisse werden in das ALM-Tool übertragen.
Für das Forschungsprojekt wurde ein Testsystem entwickelt, das die in 5.2. vorgestellten Fuzzing-Methoden zur Verfügung stellt und die automatisierte Auswertung mittels KI vornimmt. Dieses System wurde in Python realisiert. Das Testsystem ist für die verschiedenen Seitenkanäle und Antwortdaten konfigurierbar und somit für verschiedene zu testende Geräte anwendbar.
Das entwickelte System besteht aus den folgenden Komponenten:
Diese Daten werden an die Auswertung weitergegeben und außerdem, je nach Konfiguration, in Dateien in verschieden Formaten gespeichert. Die Speicherung der Daten kann auch in einer Datenbank erfolgen und stehen somit auch für eine nachträgliche Auswertung zur Verfügung.
Fuzz-Testing bedeutet ein Angriffsversuch mit zufällig generierten Tokens auf die Schnittstellen des Gerätes. Im Medizinbereich kommen hier als Schnittstellen in erster Linie USB-Anschlüsse, Bluetooth und Netzwerk Verbindungen in Frage.
Die Tokens können dabei auf verschiedene Arten generiert werden. Wir haben dazu folgende Methoden erforscht und implementiert:
Diese Methoden können auch miteinander kombiniert werden, um weitere Angriffspunkte zu finden. Außerdem ist die oben beschriebene Feedback-Schleife von der Auswertung zum Generator implementiert, welches wir als Feedback-basiert bezeichnen und weitere Kombinationen von Eingabedaten erzeugt.
Das von uns entwickelte System eignet sich insbesondere als zusätzliche Testmethode im Modultest sowie im Systemtest. Im Modultest können die definierten Schnittstellen mit den Fuzzing-Tokens traktiert werden und so die Reaktion des Moduls auf unerwartete Eingaben und Signale getestet werden. Dies dient der Härtung der zu testenden Komponenten gegenüber Angriffen von außen und erhöht damit die Sicherheit des zu entwickelten Systems.
Im Systemtest können dann die Fuzzing-Tokens an die äußeren Schnittstellen wie USB, Bluetooth oder Netzwerkschnittstellen gesendet werden und so das Gesamtsystem gegenüber Angriffen gehärtet werden. Durch die automatische Auswertung durch KI erreichen wir einen hohen Nutzen bei geringem zusätzlichem Aufwand.
Durch die weitgehende Automatisierung der Fuzzing-Tests und der Auswertung durch KI haben wir ein weitgehend automatisiertes Testvorgehen implementiert, das sich mit geringem Aufwand in den Testprozess integrieren lässt. Dieses Vorgehen ersetzt aber auf keinen Fall die klassischen Testmethoden, sie ist aber eine wirkungsvolle Ergänzung, die wir effektiv einsetzen können.
Da die KI angelernt werden muss und dafür möglichst viele Daten benötigt werden, sind der Methode dort Grenzen gesetzt, wo diese Daten (sowohl valide als auch fehlerbehaftete Daten) zum Anlernen der KI nicht oder nur schwer erzeugt werden können. Wir haben Methoden entwickelt und implementiert, mit denen sich diese Daten für medizinische Geräte weitgehend automatisiert erzeugen lassen und aufgezeichnet werden können, um sie als Anlerndaten für die KI zu verwenden.
Diese Methode ist nicht nur auf medizinische Geräte beschränkt, sondern lässt sich auch auf andere Branchen übertragen. Dies haben wir gezeigt, in dem wir das Fuzz-Testing vom Automotive-Bereich auf den Medizinbereich übertragen haben.
Mit dem S3HIFT-Projekt haben wir gezeigt, dass ein branchenübergreifendes Vorgehen prozesstechnisch definiert und tooltechnisch implementiert ist. Das automatisierte Testvorgehen ermöglicht das frühzeitige Auffinden von Sicherheitslücken und Schwachstellen im Entwicklungsprozess und verbessern die Systemhärtung deutlich und vermeidet eine Vielzahl von Problemen im Betrieb von Produkten und Systemen.
Sie sehen gerade einen Platzhalterinhalt von OpenStreetMap. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie müssen den Inhalt von hCaptcha laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Sie sehen gerade einen Platzhalterinhalt von Google Maps. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.