Entwicklungsbegleitendes Testen soll zukünftig für mehr Sicherheit von Anfang an sorgen
Automated Software Testing von Bosch
Unser Alltag wird schneller, smarter und besser verknüpft. In den positiven Entwicklungen der Digitalisierung und den wachsenden Möglichkeiten, Produkte mit dem Internet zu verknüpfen, steckt jedoch auch eine Herausforderung: Hackerangriffe nehmen nicht nur stetig zu, sie werden auch komplexer. Diese Tatsache macht Cybersecurity noch wichtiger. Die Bosch Forschung arbeitet an Lösungen, Software bereits im Entwicklungsprozess sicherer zu machen. Dies kann nur mit einer hochgradig automatisierten, entwicklungsbegleitenden Code-Analyse gelingen.
„Smart Times“ und die Antwort von Bosch
IT-Sicherheit ist eine der Schlüsseltechnologien für vernetzte Produkte von Bosch. Auch unsere Produkte sind immer anspruchsvolleren Cyberangriffen ausgesetzt, besonders Angriffen aus der Ferne, die durch die Konnektivität der verschiedenen Produkte mit dem Internet ermöglicht werden. Diese Produkte reichen vom vernetzten Sensor über ein vernetztes, autonomes Auto bis hin zum Smart Home und laufen alle mit Software.
Die meisten Angriffe in der Praxis nutzen Security-Schwachstellen in der Software aus. Dies ist ein großes – wenn nicht sogar das größte – Sicherheitsproblem für alle vernetzten Produkte / im Internet der Dinge.
Sicherheitslücken in moderner Software manuell zu suchen, ist aufgrund der teilweise mehrerer Millionen Zeilen Code sehr aufwändig und somit nicht praktikabel. Wichtig sind daher automatisierte Security Tests, um diese sicherheitsrelevanten Schwachstellen in Software zu erkennen.
Die Frage, wie eine effektive Methodik und Infrastruktur für automatisierte Security Tests gestaltet werden kann und welche Tools für das Testen der Software eingesetzt werden sollten, steht daher im Fokus unserer Forschungsarbeit.
Die Lösung: Automated Security Testing
Ressourcen schonen, Kapazitäten und Kompetenzen optimal nutzen – das ist aktuell wichtiger denn je. Und so geht es auch im Bereich der automatisierten Erkennung von Software-Schwachstellen darum, bestehende Arbeitsabläufe der Code-Analyse zu verbessern. Oder anders gesagt: zu automatisieren – und das entwicklungsbegleitend. Automatische Fehlersuche, automatisierte Code- sowie eine automatisierte Sicherheitsprüfung während der Entwicklungsphase sind Ansätze, die in der Bosch Forschung weiterentwickelt werden.
Das Bosch Forschungs-Projekt trägt den Namen „Software Dependability Assurance“ – kurz: SoDA – und befasst sich mit dem Thema der automatisierten Software-Analyse.
Die Bosch Forschung arbeitet an einer Lösung für automatisierte Sicherheitstests von Software, die speziell für vernetzte Produkte von Bosch entwickelt wird. Diese Lösung basiert auf einer Plattform, die eine kontinuierliche Sicherheitsanalyse und -prüfung in allen Phasen des Softwareentwicklungsprozesses ermöglicht. Im Kern geht es bei der Plattform um eine automatisierte Erkennung von Sicherheitsschwachstellen im Quellcode. Sicherheitstests und das damit verbundene Aufdecken von Sicherheitsschwachstellen werden bereits während der Entwicklungsphase des Softwareprodukts vollautomatisch und autonom durchgeführt. Wir sprechen hier von einem „entwicklungsbegleitenden Testen", das einen spürbaren Mehrwert bietet. Wird die automatische Fehlersuche bereits in den Entwicklungsprozess integriert, kann effektiver gearbeitet und schneller auf Schwachstellen im Code reagiert werden, was zu mehr Sicherheit und zu einer effizienteren Arbeitsweise führt.
Konkret bedeutet eine automatische Codeprüfung für den Entwickler:
Bugs früh und automatisiert finden und dadurch einfach bessere Software schreiben.
Automated Security Testing und die damit einhergehende automatisierte Erkennung von Softwareschwachstellen bietet einen nachvollziehbaren Vorteil für Entwickler: Die automatische Suche nach Sicherheitslücken reduziert den manuellen Aufwand erheblich. Da Fehler bereits im Entwicklungsprozess identifiziert werden können, trägt eine automatisierte Codeprüfung zusätzlich dazu bei, die Gesamtsicherheit der Systeme zu erhöhen.
Das Ziel unserer Forschungsarbeit
“IT-Giganten wie Microsoft und Google haben White Hat Teams, um ihre Produkte auf Sicherheitslücken intern vor der Veröffentlichung zu testen. Im SoDA Projekt haben die Experten meines Teams einen Prototyp entwickelt, der es uns ermöglicht, diese Tests bei Bosch Connectivity Produkten in großem Umfang durchzuführen.“
Ziel der Bosch Forschung ist es, smarte Lösungen für eine immer stärker vernetzte Welt zu finden. Die Anzahl der internetfähigen Bosch Produkte wird zukünftig weiter steigen. Auf der einen Seite schafft Konnektivität einen deutlichen Mehrwert für die Anwender – auf der anderen Seite bedingt sich jedoch auch ein neues Verständnis von Cyber-Sicherheit, da durch Vernetzung auch die Gefahr von Angriffen steigt. Automatisierte Sicherheitstests ermöglichen es, Probleme oder Sicherheitslücken im Code bereits frühzeitig in der Entwicklungsphase zu erkennen und so den Aufwand für die Softwareentwickler zu reduzieren. Auf diese Weise entstehen sichere, zuverlässige sowie innovative Bosch Produkte.
Mehr erfahren über Software-Analyse-Methoden und Hackerangriffe
Im Automotive Bereich muss die Software bzw. der Quellcode bestimmte Qualitätsrichtlinien erfüllen. Dazu zählen Best Practices sowie Codier-Richtlinien, zum Beispiel der automotive-spezifische MISRA C Standard. Mit statischer Code Analyse lassen sich solche Qualitätsrichtlinien automatisiert überprüfen.
Code Property Graphen [1] bilden die Grundlage für leistungsfähige statische Quellcode Analysemethoden. Die Grundidee ist, verschiedene Graphen-basierte Repräsentationen des Quellcodes – abstrakten Syntaxbaum, Kontrollfluss- und Programmabhängigkeits-Graphen – in einem einzigen Graph, dem sog. Code Property Graphen (CPG), zu integrieren. Der CPG kann dann programmatisch analysiert werden, um Software Schwachstellen zu finden. So lassen sich beispielsweise Schwachstellen identifizieren, bei denen nicht validierte Programm-Eingaben als Argumente von kritischen Funktionen verwendet werden.
---
[1] F. Yamaguchi, N. Golde, D. Arp and K. Rieck, "Modeling and Discovering Vulnerabilities with Code Property Graphs," 2014 IEEE Symposium on Security and Privacy, San Jose, CA, 2014, pp. 590-604. doi: 10.1109/SP.2014.44 Databases}, URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6956589&isnumber=6956545
Software Fuzzing ist eine dynamische Analysemethode, bei der das zu untersuchende Programm mit verschiedenen Eingaben mehrfach ausgeführt wird, um Stabilitätsprobleme sowie Sicherheitslücken zu finden. Sogenannte Graybox-Fuzzer sind darauf ausgelegt, die Abdeckung des Quellcodes währends des Fuzzing-Vorhangs zu maximieren. Dazu wird der Quellcode vor dem Fuzzing, während des Kompilierens, instrumentalisiert. Die Instrumentalisierung liefert während des Fuzzing Informationen, um die Programm-Eingaben gemäß einer Heuristik zu variieren, so dass möglichst viele Programm-Abzweigungen überprüft werden.
Das Mirai-Botnet hat Ende 2016 mehrere massive Distributed Denial-of-Service (DDos) Angriffe ausgelöst, wodurch Teile der Internet-Infrastruktur lahmgelegt wurden. Der initiale Mirai Scan fand am 1. August 2016 statt und nahm seinen Ursprung von einer IP-Adresse von DataWagon, einem in den USA basierten Hosting Provider [2]. Der Bootstrap-Scan dauerte knapp zwei Stunden (01:42-03:59 UTC) und knapp 40 Minuten später (04:37 UTC) kam das Mirai-Botnet zum Vorschein. Innerhalb der ersten Minute begannen 834 Geräte mit dem Scan und 11 000 Hosts wurden innerhalb der ersten 10 Minuten infiziert. In 20 Stunden infizierte Mirai 64 500 Geräte. Im September 2016 wurden 200 000 – 300 000 Geräte infiziert; ein Infektionshöhepunkt wurde Ende November 2016 beobachtet. Das entspricht 2,2 – 3,4 infizierte Geräte pro Minute oder 17,6 – 27,2 Sekunden für die Infektion eines einzelnen Gerätes, allein in den ersten zwei Monaten.
---
[2] Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard, Elie Bursztein, Jaime Cochran, Zakir Durumeric, J Alex Halderman, Luca Invernizzi, Michalis Kallitsis, et al. Understanding the mirai botnet. In 26th USENIX Security Symposium (USENIX Security 17), pages 1093-1110, 2017.
