Spricht man im Zusammenhang mit funktionaler Sicherheit von Software-Security, mag dies zunächst inkorrekt erscheinen, befasst sie sich doch primär mit der Safety und damit mit der möglichen Beeinträchtigung von Leib und Leben. Fehlende oder unzureichend berücksichtigte Security kann allerdings durchaus einen negativen Einfluss auf die Safety ausüben.

Besonders eindringlich hat dies der sogenannte „Jeep-Hack“ Mitte des Jahres gezeigt. [1] Die beiden Sicherheitsforscher Charlie Miller und Chris Valasek haben dabei den Jeep Cherokee des Journalisten Andy Greenberg so manipuliert, dass es möglich war, das Fahrzeug aus der Ferne zu steuern. Sie konnten dabei nicht nur Infotainment- und Komfortfunktionen bedienen, sondern auch die Fahrt beeinflussen. So war es möglich das Getriebe zu entkuppeln und dem Fahrer auf diese Weise ein weiteres Beschleunigen unmöglich zu machen. Zwar wurde die Machbarkeit solcher Szenarien bereits zuvor gezeigt, dabei wurde jedoch stets vorheriger physischer Zugriff auf das Fahrzeug benötigt, um beispielsweise einen Diagnosestecker im Fahrzeug anzubringen oder andere Manipulationen vorzunehmen. [2, 3]

Infotainment-System gehackt

Miller und Valasek benötigten lediglich die IP-Adresse des im Fahrzeug verbauten und mit dem Internet verbundenen Infotainment-Systems, um über eine darin enthaltene Schwachstelle das Fahrzeug zu übernehmen. Dazu änderten sie die Firmware dahingehend, dass sie vom Infotainment-System aus Nachrichten über den CAN-Bus an die Steuergeräte des Fahrzeugs versenden konnten. Kurze Zeit später zeigte Andy Davis, wie sich Angriffe auf Fahrzeuge sogar ohne detaillierte Kenntnis über deren Verbindungsdaten ausführen lassen. Angriffskanal waren stattdessen Zusatzdienste des Digitalradios DAB, die über einen eigenen Sender übertragen werden. [4]

Dabei nutzte Davis unterschiedliche Schwachstellen verschiedener Infotainment-Systeme aus, wie zum Beispiel Sicherheitslücken in Grafikbibliotheken im Zusammenhang mit Slideshow-Bildern (MOT) oder aus dem Bereich der Webanwendungen bekannte Probleme wie SQL-Injection und Cross-Site-Scripting (XSS) im Zusammenhang mit Radio-Begleittext (DLS).

Für das vermehrte Bekanntwerden von Security-Problemen im Automotive-Umfeld in der letzten Zeit gibt es mehrere Gründe. Fahrzeuge werden mit immer zahlreicheren Komfort-, Infotainment- und Fahrerassistenzsystemen ausgestattet, was den Umfang und die Komplexität der im Fahrzeug eingesetzten Software erhöht. Außerdem werden vermehrt Schnittstellen zur drahtlosen Kommunikation verbaut, um beispielsweise während der Fahrt auf aktuelle Verkehrsdaten zugreifen zu können oder um die Klimaanlage des Fahrzeugs bereits einige Zeit vor der Fahrt starten zu können. Autonome Fahrzeuge sind in der Entwicklung und übernehmen Aufgaben, die über Gesundheit und Leben der Insassen entscheiden.

Schwachstellen durch neue Systeme und Schnittstellen

Die zusätzlichen Schnittstellen und neuen Systeme stellen potentielle Angriffsvektoren dar und werden teilweise mit Systemen verbunden, die ursprünglich nur für die Bedienung durch die Insassen des Fahrzeugs vorgesehen waren. Auch können sich die Lebenszyklen einzelner Komponenten stark unterscheiden, so dass zu Beginn der Entwicklung eines Geräts noch gar nicht absehbar war, dass es später zusammen mit einem anderen Gerät oder einer Schnittstelle eingesetzt werden wird. Die Entwickler eines Steuergeräts sind sich unter Umständen gar nicht bewusst, dass ihr System in einem Umfeld eingesetzt wird, in dem es Nachrichten nicht nur von wohlwollenden Kommunikationspartnern erhält. Gründe hierfür können entweder ein fehlendes Problembewusstsein auf Seiten der Entwickler, aber auch eine unvollständige, unklare oder sich im Verlauf der Entwicklung ändernde Spezifikation sein.

Um derartige Probleme zu umgehen, ist es notwendig, sowohl einen Überblick über das Gesamtsystem zu haben, als auch die notwendigen Details zu kennen, um potentielle Gefahren zu erkennen. Die Wahrscheinlichkeit, dass eine einzelne Person in einem Projekt oder Entwicklungsumfeld vorhanden ist, die sowohl Überblick als auch Detailkenntnisse hat, sinkt jedoch mit der Größe und Komplexität der Aufgabe. Eine andere Herangehensweise ist es daher, das Problem aufzuteilen und mehrere Personen damit zu betrauen, Gefahren zu erkennen und gegenzusteuern.

ISO26262 - funktionale Sicherheit

Hierfür sind Werkzeuge und Vorgehensweise notwendig, die sicherstellen, dass alle notwendigen Informationen zur systematischen Bewertung des Gesamtsystems vorhanden sind und dass keine Aspekte übersehen werden. Außerdem ist es schwierig und teuer, Security für ein fertig entwickeltes Produkt im Nachgang sicher zu stellen. Daher ist es notwendig, Security als Bestandteil des kompletten Planungs- und Entwicklungsprozesses zu begreifen und in diesen zu integrieren.

Eine empfehlenswerte Herangehensweise ist es, von Methoden aus der funktionalen Sicherheit zu lernen. Hier existiert bereits ein Regelwerk, das sich in der Praxis bewährt hat. Aus ihm kann ein Vorgehen abgeleitet werden, dessen Ziel es ist, Gefahren zu erkennen und angemessen zu behandeln. [5]

Die ISO 26262, die die funktionale Sicherheit im Bereich von Kraftfahrzeugen definiert, geht von der Verwendung des V-Modells aus. Parallel zu diesem Vorgehen kann auch ein entsprechender Prozess mit dem Fokus auf Security modelliert werden.

Um einen vollständigen Überblick über die möglichen Gefahren und Risiken zu erhalten, muss zunächst eine Gefährdungs- und Risikoanalyse durchgeführt werden. Im Gegensatz zum Vorgehen in der funktionalen Sicherheit, wo man in der Betrachtung mit einem Item, wie zum Beispiel einem elektrischen Fensterheber, startet, beginnt man in der Security-Analyse mit den zu schützenden Daten. Eine Bewertung der Auswirkungen einer Gefahr auf Integrität, Verfügbarkeit und Vertraulichkeit ist in Hinblick auf die Wahrscheinlich des Auftretens und der Schwere der Folgen durchzuführen. In der funktionalen Sicherheit entspricht dies den Größen Severity und Exposure. Die in der funktionalen Sicherheit betrachtete Controllability ist im Security-Bereich üblicherweise gering, da die wenigsten Nutzer eine Security-Bedrohung erkennen oder ausreichen schnell behandeln können dürften.

Anhand der Gefährdungs- und Risikoanalyse können nun parallel zu den Safety-Goals in der funktionalen Sicherheit Security-Goals definiert werden, die wiederum zu einer Spezifikation der Security-Anforderungen für die zu schützenden Daten führen. Nach dieser Konzeptphase können in der Entwicklung die technische Spezifikation und schließlich die Implementierung folgen. Nach Fertigstellung des Gesamtsystems folgt dann die Validierung, in der überprüft wird, ob die spezifizierten Security-Goals erreicht wurden und so alle möglichen Risiken aus der zugrundeliegenden Gefährdungs- und Risikoanalyse behandelt wurden.

Strukturiertes Vorgehen sorgt für funktionale Sicherheit

Durch eine Formalisierung dieses Vorgehens, parallel zum Vorgehen in der funktionalen Sicherheit, wird sichergestellt, dass die Security nicht lediglich als unpräzise nichtfunktionale Anforderung im Lastenheft erscheint, sondern dass eine Dokumentation existiert, in der sämtliche Security-Anforderungen detailliert und strukturiert aufgezeichnet sind. Außerdem lässt sich so nachvollziehen, aufgrund welches Risikos bestimmte Maßnahmen zu treffen sind. Durch die systematische Herangehensweise wird dafür gesorgt, dass nicht lediglich besonders auffällige Security-Aspekte untersucht werden, sondern das Gesamtsystem einschließlich seiner Abhängigkeiten.

Eine systematische Betrachtung und eine spätere Validierung erfordern außerdem Rollen wie beispielsweise Security Manager und Security Assessor, die diese Tätigkeiten ausführen, wie dies in der funktionalen Sicherheit der Safety Manager und der Safety Assessor tun. Dadurch ergibt sich, dass das Thema Security nicht durch die Entwickler lediglich „nebenher“ betreut wird, sondern dass es klare Ansprechpartner gibt, die das Thema dauerhaft verfolgen. Die geforderte Gesamtübersicht bei gleichzeitiger Betrachtung der Security-kritischen Details wird erreicht, indem in separaten Arbeitsschritten zunächst das Komplettsystem und danach die relevanten Komponenten betrachtet werden.

Ein Hauptgrund, weshalb Systeme, die zunächst sicher erscheinen, sich in der Praxis als unsicher erweisen, sind spätere Änderungen, die unbemerkt entweder neue Gefahren hinzufügen oder die Wirksamkeit bereits implementierter Behandlungen von Gefahren vermindern. Um solche Effekte zu verhindern, ist es notwendig, das Gesamtsystem erneut im Hinblick auf potentielle Gefahren zu untersuchen, wenn Änderungen an Teilsystemen vorgenommen werden sollen oder Use-Cases sich ändern. In der funktionalen Sicherheit werden Fehlerbaumanalysen eingesetzt, um Gefahren und ihre Wahrscheinlichkeiten zu modellieren. Analog hierzu kann im Bereich Security eine Angriffsbaumanalyse durchgeführt werden. [6]

Der Angriffsbaum stellt eine formale Methode zur Verfügung, um Gefahren zu erkennen, sie zu bewerten und zu dokumentieren. Da es möglich ist, einzelne Äste statt des gesamten Baums zu betrachten, bleibt die Übersichtlichkeit auch in komplexen Systemen gewahrt. Insbesondere im Hinblick auf die unter dem Eindruck des „Jeep-Hacks“ in den USA auf den Weg gebrachten Gesetzesvorhaben ist die Einführung anwendbarer und dokumentierter Prozesse in der Entwicklung Security-relevanter Produkte im Automotive-Umfeld empfehlenswert. So hat Edward Markey, Senator für den US-Bundesstaat Massachusetts, den sogenannten „SPY Car Act of 2015“ vorgeschlagen. [7]

Gesetztliche Verpflichtungen kommen

Das Gesetzesvorhaben beinhaltet die Verpflichtung der Automobilhersteller, die am US-amerikanischen Markt teilnehmen, dazu, Netze und Steuergeräte in den Fahrzeugen so abzusichern, dass eine Manipulation wie im eingangs genannten Beispiel nicht möglich ist. Des Weiteren sind Datenschutzregeln und Maßnahmen enthalten, die zu mehr Transparenz hinsichtlich der von den Herstellern geforderten Security-Standards führen. Verstöße gegen die Regelungen zur Security sind mit Geldstrafen bedroht. Ungefähr zur gleichen Zeit hat sich unter dem Dach der Alliance of Automobile Manufacturers, der auch deutsche Automobilhersteller beziehungsweise deren US-amerikanische Töchter angehören, die Auto ISAC (Information Sharing and Analysis Center) gebildet. [8] Ihr Ziel ist es, Informationen über potentielle Security-Gefährdungen zu sammeln und ihren Mitgliedern zur Verfügung zu stellen. Dass dies sinnvoll ist, zeigt ein Blick in die Zukunft des Automobils. Der Verband der Automobilindustrie (VDA) geht davon aus, dass bereits im Jahr 2017 weltweit 80% aller Neuwagen mit einer Schnittstelle ins Internet ausgeliefert werden. [9]

Zusammenfassend lässt sich sagen, dass viele Methoden der funktionalen Sicherheit auch in der Planung und Entwicklung von Systemen, die hohen Security-Anforderungen gerecht werden sollen, sinnvoll einsetzbar sind und gegenüber einer in dieser Hinsicht ungeordneten Entwicklung auch einen Mehrwert bieten. Ebenso existieren im Bereich Security bereits Werkzeuge, die sich sinnvoll in einen Rahmen, wie ihn die funktionale Sicherheit bietet, einbetten lassen, um auf die speziellen Anforderungen der Security eingehen zu können.

LITERATURHINWEISE
[1] Greenberg, A.: Hackers Remotely Kill a Jeep on the Highway – With Me in It. Stand: 21.07.2015; http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/  (Abgerufen: 12.10.2015)
[2] Koscher, K.; Czeskis, A.; Roesner, F.; P. Shwetak; and Kohno T.; Checkoway, S.; McCoy D.; Kantor, B.; Anderson, D.; Shacham, H.; Savage, S.: Experimental Security Analysis of a Modern Automobile. IEEE Symposium on Security and Privacy, Oakland, CA, USA, 16.-19. Mai 2010
[3] Checkoway, S.; McCoy, D.; Kantor, B.; Anderson, D.; Shacham, H.; Savage, S.; Koscher, K.;Czeskis, A.; Roesner, F.; Kohno, T.: Comprehensive Experimental Analyses of Automotive Attack Surfaces. USENIX Security Symposium, San Francisco, CA, USA, 10.-12. August 2011
[4] Davis, A.: Broadcasting Your Attack: Security Testing DAB Radio in Cars. Black Hat USA 2015; Las Vegas, NV, USA, 1.-6. August 2015
[5] Klauda, M.; Schaffert, M.; Lagospiris, A.; Piel, G.; Kappel, S.; Ihle, M.: Weichenstellung für 2020 – Paradigmenwechsel in der E/E-Architektur. In: ATZelektronik 02/2015, S. 16-22
[6] Schneier, B.: Attack Trees. Stand: 01.12.1999; http://www.drdobbs.com/attack-trees/184411129 (Abgerufen: 12.10.2015)
[7] Markey, E: SPY Car Act of 2015. https://www.congress.gov/bill/114th-congress/senate-bill/1806/all-info (Abgerufen: 12.10.2015)
[8] Auto Alliance: Automakers Announce Initiative to Further Enhance Cyber-security in Autos. http://www.autoalliance.org/index.cfm?objectid=8D04F310-2A45-11E5-9002000C296BA163 (Abgerufen: 12.10.2015)
[9] Wissmann, M.: Auftaktpressekonferenz IAA, Frankfurt, 14.09.2015