S3HIFT – „Cyber-Security-Maßnahmen für Automotive- und MedTech-Produkte“
1.1 Motivation
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.
1.2 Projektvorstellung
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.
1.3 Das Projekt hat folgende Projektziele:
- Etablierung eines Effort-Front-Loading-Ansatz im Entwicklungsprozess
- Kosten- und Zeiteffizienz durch Automatisierung
- Nachverfolgbarkeit der Ergebnisse mit einer durchgängigen Toolkette
- Kontinuierlich verbesserter Secure Development Process mittels eines Bewertungsmodells
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.
2. Grundlagen
2.1 Threat Assessment and Risk Analysis (TARA)
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.
2.2 Fuzz-Testing
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.
3. Secure Development Process
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:
- Generator zur Generierung von Eingabedaten
- Testautomatisierung & Injektor, mit dem das SUT (System under Test) angesteuert wird
- Monitor- & Measurement-System zur Messung von Systemausgaben & Seitenkanälen
- Analyzer (KI-basiert) zur Ermittlung von Anomalien (möglichen Systemschwachstellen)
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.
4. Tools & Toolkette
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:
4.1 Modellierungswerkzeug Enterprise Architect
Mit Hilfe des Enterprise Architect erstellen wird folgende Modelle:
- TARA-Modell: Dokumentation der Assets, Threats (Angriffsszenarien, Risiken und abgeleiteten Security Requirements)
- Bewertungsmodell: Ermittlung des wahrscheinlichsten Angriffspfads eines Angreifers
- Angriffsmodell: Modellbasiertes Vorgehen für die Generierung von Eingaben (=Angriffsszenarien)
4.2 Modellbasiertes Testtool MBTsuite
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.
4.3 ALM-Tool Jira + PlugIns
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.
4.4 Programmiersprache Python
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.
5. Technische Umsetzung
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.
5.1 Aufbau
Das entwickelte System besteht aus den folgenden Komponenten:
- Fuzz-Engine: Diese Komponente ist für das Generieren der Fuzzing Message verantwortlich und erzeugt je nach Konfiguration unterschiedliche Eingabedaten, die über die konfigurierte Schnittstelle an das zu testende Gerät gesendet werden.
- Data Manager: Der Datenmanager verwaltet die anfallenden Daten. Dieses sind zum einen die vom Gerät und zum anderen die von den Seitenkanälen gelieferten Daten.
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.
- Monitoring: Diese Komponente wertet die vom Gerät gelieferten Daten aus und stellt evtl. Anomalien über KI-Algorithmen fest. Die Ergebnisse werden an den Data Manager zurück geliefert und zum einen aufgezeichnet und zum anderen als Rückkopplung zur Fuzz-Engine genutzt.
- Instrumentation: Dieses Modul implementiert die verschiedenen Messgeräte wie Oszilloskop zur Strommessung, evtl. eine Wärmebildkamera oder Thermosensoren und dergleichen. Die aus den Instrumenten gewonnen Daten werden über den Data Manager aufgezeichnet und an das Monitoring zur Auswertung weitergereicht.
5.2 Fuzz-Testing und Fuzzing-Methoden
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:
- Generativ: das Token wird als zufällige Zeichenkette bestimmter Länge erzeugt und an das Gerät gesendet.
- Evolutionär: Eine zufällig generierte Zeichenkette wird in sich mutiert und an das Gerät gesendet
- Mutativ: Eine vorgegebene Zeichenkette wird zufällig in sich mutiert und an das Gerät gesendet
- Keyword-basiert: Aus einer Liste von Schlüsselwörtern wird eine zufällige Folge ausgewählt und an das Gerät gesendet.
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.
6. Anwendungsbereiche
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.
7. Anwendungsmöglichkeiten und ‑grenzen
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.
8. Zusammenfassung
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.
Wenn Sie auch Ihr Produkt oder System härten wollen, so kontaktieren Sie uns!
Profitieren Sie von der Expertise unserer Experten.
„Der erste Schritt ist der Wichtigste.
Sprechen Sie mich an!“Tel.: +49 9195 931–253