Defense In Depth für Fahrzeuge. Stand der Technik und zukünftige Möglichkeiten

Inhaltsverzeichnis

Erklärung

Kurzfassung

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Defense in Depth und Automotive Security - Theoretische Grundlagen
2.1 Defense in Depth – Bedeutung und Begriffsabgrenzung
2.2 IT-Sicherheit und ihre Komponenten
2.3 Fahrzeuge und Fahrzeugarchitektur - Grundlegende Bestandteile..

3 Aktueller Forschungsstand Automotive Security
3.1 Vorgehen bei der Auswahl und Auswertung von Studien und wissenschaftlichen Artikeln
3.2 Analyse ausgewählter Studien zu Automotive Security und Darstellung von deren Ergebnissen
3.2.1 Automotive Cyber-Security-Erfahrungen für die Entwicklungspraxis
3.2.2 Smart Apps in einem vernetzten (auto)mobilen Umfeld: IT-Security und Privacy
3.2.3 A Defense-in-Depth Approach to Securing the Wireless Vehicle Infrastructure.
3.2.4 A Survey of Remote Automotive Attack Surfaces.
3.2.5 A Car Hackers Handbook
3.2.6 Defense-in-depth and Role Authentication for Microservice Systems
3.2.7 Control Systems Cyber Security: Defense in Depth Strategies
3.2.8 IT-Sicherheit als besondere Herausforderung von Industrie 4.0
3.3 Zusammenfassung der Anforderungen und Rahmenbedingungen für IT-Sicherheit in Fahrzeugen
3.3.1 Anforderungen an Fahrzeugarchitekturen
3.3.2 Anforderungen an IT-Sicherheit in einem Fahrzeug
3.3.3 Neue Rahmenbedingungen im Automobilsektor
3.3.4 Unterschiede zwischen Standard-IT-Architektur und Fahrzeug-IT-Architektur
3.4 Forschungslücke im Bereich Automotive Security

4 Methodenauswahl und Marktstudie für Defense-in-Depth-Möglichkeiten
4.1 Vorgehen bei der Analyse für Defense-in-Depth-Mechanismen
4.2 Auswahl und Begründung der gewählten Methoden
4.3 Marktstudie von Hersteller-Lösungen
4.3.1 Argus Cyber Security
4.3.2 Autotalks
4.3.3 Gemalto
4.3.4 Harman
4.3.5 Kaspersky Lab
4.3.6 Trend Micro
4.4 Darstellung wesentlicher Erkenntnisse von Einzellösungen am Markt

5 Konzeption von Defence in Depth Mechanismen für Fahrzeuge
5.1 Vorgehensmodell
5.2 Vorgehen für den Architekturaufbau und die Bedrohungs- und Risikoanalyse
5.2.1 Gesamtmodell
5.2.1.1 Architektur
5.2.1.2 Bedrohungs- und Risikoanalyse
5.2.2 OnBoard-Modell
5.2.2.1 Architektur
5.2.2.2 Bedrohungs- und Risikoanalyse
5.2.3 Prozessmodell
5.2.3.1 Prozessablauf
5.2.3.2 Bedrohungs- und Risikoanalyse
5.3 Konzeption einzelner Security Bausteine
5.3.1 OnBoard Hardware
5.3.2 OnBoard Software
5.3.3 OnBoard Kommunikation
5.3.4 OnBoard Rechtemanagement
5.3.5 OnBoard Monitoring
5.3.6 Externe Kommunikation & Schnittstellen
5.3.7 Absicherung Backend
5.3.8 Prozesse
5.4 Erstellung ganzheitlicher Sicherheitsmodelle
5.4.1 Gesamtmodell
5.4.2 OnBoard Modell
5.4.3 Prozess-Modell
5.5 Evaluierung der Lösungen und weiterer Forschungsbedarf

6 Fazit und Ausblick

Quellenverzeichnis

Erklärung

Ich erkläre hiermit, dass ich die Arbeit selbständig verfasst, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel benützt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe.

Ingolstadt, den 12.07.2018

Georg Graupner

Kurzfassung

Sowohl Fahrzeuge als auch die Informationstechnologie sind unentbehrliche, essentielle Bestandteile in unserer modernen Gesellschaft. Da besonders die westliche Welt beides exzessiv nutzt, war es nur eine Frage der Zeit, bis diese beiden Technologien zusammenfinden. Dies fing beim einfachen Radio im Fahrzeug an, über Autotelefonie bis hin zu den heutigen, rundum vernetzten Fahrzeugen mit einer ständigen Verbindung zum Internet. Doch mit der Vernetzung sind Fahrzeuge auch Ziel von einer Gruppierung geworden, die sich bis dato wenig für Fahrzeuge interessiert hatten: Hacker. Während bis zu diesem Zeitpunkt das „Hacken“ eines Fahrzeugs in dessen Aufbruch und Diebstahl bestand, für welches der Hacker physisch am Fahrzeug sein musste, so gibt es heutzutage die Möglichkeit, Fahrzeuge auch aus der Ferne anzugreifen. Dies schafft neue Angriffswege, -gründe sowie neue Risiken und Bedrohungen, da bei diesen Angriffen im schlimmsten Fall das Leben von Personen gefährdet sein kann.

Bisher wurden Fahrzeuge von Automobilherstellern meist nicht als IT-System gesehen. Deshalb wurde auch bisher nur die funktionale Sicherheit (Safety) betrachtet und IT-Risiken waren maximal im Backendbereich ein Thema. Doch nicht zuletzt wegen einiger öffentlichkeitswirksamen Angriffe auf Fahrzeuge hat das Thema Security im Fahrzeug an Aufmerksamkeit gewonnen. Nun suchen die Hersteller nach Lösungen, wie sie ihre Fahrzeuge absichern können. An dieser Stelle ist ein ganzheitliches Sicherheitskonzept gefragt, welches Sicherheit in der Tiefe (Defense in Depth) bietet.

Abbildungsverzeichnis

Abbildung 1: Schematischer Aufbau einer Burg am Beispiel Burg Oberlauda (Krahe, 2000)
Abbildung 2: Defense in Depth Ansatz. Nach (Larson, et al., 2009)
Abbildung 3: Zusammenspiel von Sensor, ECU und Aktor
Abbildung 4: Beispielhafte Vernetzung im Fahrzeug
Abbildung 5: Schematischer Aufbau eines Cyber-Physischen Systems. (Veigt, et al., 2013)
Abbildung 6: Evolution von E/E-Architekturen in den nächsten Jahren. (Haas, et al., 2016)
Abbildung 7: Suchcluster "Defense in Depth"
Abbildung 8: Suchcluster "Fahrzeug Security"
Abbildung 9: Infrastruktur-Schichten (NTT Data Deutschland GmbH, 2018)
Abbildung 10: Angriffswege Fahrzeug (NTT Security (Germany) GmbH, 2018)
Abbildung 11: Angriffsreichweiten (NTT Data Deutschland GmbH, 2018)
Abbildung 12: IT-Architektur eines Unternehmens. (Dern, et al., 2009)
Abbildung 13: Vorgehensmodell Defense-in-Depth-Konzeption. In Anlehnung an (VDI, 2011)
Abbildung 14: Gesamtmodell, schematisch
Abbildung 15: OnBoad-Modell, schematisch
Abbildung 16: Lebenszyklus eines Fahrzeugs
Abbildung 17: Schichtenmodell Security-Bausteine
Abbildung 18: Abgesichertes Gesamtmodell
Abbildung 19: Abgesichertes OnBoard Modell
Abbildung 20: Abgesichertes Prozessmodell
Abbildung 21: Safety und Security Prozess

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Der digitale Wandel hat unser aller Leben in den letzten Jahren und Jahrzehnten bestimmt. Produkte im Bereich der Consumer-Elektronik wie Laptops oder Handys, sowie die tägliche Nutzung des Internets sind aus dem täglichen Leben nicht mehr wegzudenken. Dieser Trend hat unlängst auch den Automobilsektor erreicht. Radio oder Navigationssysteme gehören schon lange zur Standardausstattung der meisten Fahrzeuge.

Mit dem Aufkommen von Smartphones Mitte der 2000er Jahre sowie dem damit verbundenen Ausbau des mobilen Datennetzes (wie zum Beispiel den Übertragungsstandards UMTS und HSPA) war es nur eine Frage der Zeit, bis das Internet auch in Fahrzeugen Einzug halten würde. Dementsprechend bietet heutzutage nahezu jeder Fahrzeughersteller digitale Features in seinen Fahrzeugen an. Diese reichen von USB, Bluetooth und WLAN, über Infrarot-, Laser- oder Radarsensoren bis zur Internetfähigkeit des Fahrzeuges selbst durch integrierte Datenmodule. Fahrzeuge erhalten somit permanent Informationen von externen Quellen.

Allerdings werden sie dadurch auch mögliche Ziele von Hackerangriffen. Die Motivation für solch einen Angriff kann verschiedene Hintergründe haben: Zum Beispiel kann ein Hacker versuchen, über Softwaremanipulation sein Fahrzeug aufzubessern (zu „tunen“), um mehr Leistung zu erhalten, den Tachostand zu manipulieren oder um die Abriegelung einer maximal möglichen Geschwindigkeit abzuschalten. Ein weiterer Grund kann sein, dass sich ein Hacker über Fahrzeugsysteme unerlaubten Zugang verschaffen will, um das Fahrzeug zu entwenden ohne Einbruchspuren zu hinterlassen. Im schlimmsten Fall wird der Hacker aber versuchen, sicherheitsrelevante Systeme¹ wie Lenkung oder Bremsen zu übernehmen, was im schlimmsten Fall zu Unfällen führen kann. Dies ist insbesondere im Hinblick auf zukünftige Stufen des autonomen Fahrens überaus riskant. Für eine Privatperson ist es zwar ärgerlich, wenn deren Laptop oder Smartphone gehackt wird und für Unternehmen kann dies einen wirtschaftlichen Schaden bedeuten, allerdings besteht, im Gegensatz zum Fahrzeug, bei diesen Angriffen selten eine Gefahr für Leib und Leben.

Das solche Hackerangriffe auf Fahrzeuge durch aus möglich und umsetzbar sind, haben in der Vergangenheit schon mehrere Versuche gezeigt: So hat der ADAC 2014 eine Sicherheitslücke im BMW System „ConnectedDrive“ gefunden, über die Fahrzeuge über Mobilfunk geöffnet werden konnten (ADAC, 2014). Die beiden IT-Experten Javier V. Vidal und Alberto G. Illera zeigen in einem Livehack auf der Defcon 2013, wie sie mit Equipment für nur 20 Euro in die Elektronik eines Fahrzeugs einbrechen konnten (Reißmann, 2013). Das wohl prominenteste Beispiel kommt von Charlie Miller und Chris Valasek, welche einen werksneuen Jeep Cherokee während der Fahrt übernahmen und Lenkung und Bremse steuerten (Greenberg, 2015).

Dementsprechend hoch sind auch die Bemühungen der Fahrzeughersteller, solche Gefahren abzuwenden. Dabei wird meist versucht, die derzeitige Fahrzeugarchitektur möglichst gut gegen Angriffe abzusichern. Dies gelingt allerdings nur partiell. Gründe hierfür gibt es mehrere:

1. Die derzeitige Fahrzeugarchitektur ist meist historisch gewachsen. Dabei stand stets die Funktionsorientierung der Systeme und deren funktionale Sicherheit (Safety) im Vordergrund und nicht die Informationssicherheit (Security). Das bedeutet, dass Fahrzeugsysteme ursprünglich gar nicht darauf ausgelegt waren, Schutz vor Cyberangriffen zu bieten. (Shen, 2015)
2. Derzeitige Schutzmaßnahmen beschränken sich darauf, den Zu- und Abfluss der Daten in und aus dem Fahrzeug zu kontrollieren (Perimeter-Schutz). Dabei wird aber nicht überprüft, wie die Daten sich im Fahrzeug selbst verhalten oder welche Aktionen sie dort ausführen.
3. Fahrzeughersteller haben nur eine eingeschränkte Kontrolle über Daten, welche von externen Quellen in das Fahrzeug eingespielt werden. Dies gilt zum Beispiel für Daten welche über die USB- oder Bluetooth-Verbindung mit einem Smartphone in das Fahrzeug gelangen.

Dementsprechend ist es für kommende Generationen von vernetzten (und autonomen) Fahrzeugen essentiell, IT-Sicherheitskonzepte gegen Hackerangriffe zu entwickeln. Dafür muss das funktionale Sicherheitskonzept um Informationssicherheitsmaßnahmen erweitert und verbessert werden. An dieser Stelle setzt Defense in Depth an, welches die bisher einzelne Schutzschicht um mehrere Schichten erweitert. Defense in Depth beschreibt dabei ein Security-Konzept, welches durch mehrere Schutzschichten für eine erhöhte Sicherheit sorgt.

In dieser Hinsicht stellen sich mehrere Fragen: Welche Defense in Depth Maßnahmen sind für eine angemessene Absicherung von Fahrzeugen gegen Angriffe notwendig? Und wie lassen sich diese in die Fahrzeugarchitektur integrieren?

Da es hierzu zwar vereinzelt, aber keine öffentlichen oder konkretisierten Konzeptionen für solche ein Sicherheitskonzept gibt, wird sich diese Masterarbeit dieser Problemstellung widmen.

Ziel der Arbeit ist die Konzeption von generischen Defense in Depth Mechanismen, welche derzeitige Fahrzeugarchitekturen und Automotive Cyber-Systeme gegen Angriffe absichern. Dafür werden auch Ansätze und Produkte von Herstellern von IT-Sicherheitsprodukten evaluiert und deren Umsetzung für die Praxis kritisch hinterfragt.

Dafür wurden zuerst die wichtigsten Begriffe, welche den Kern dieser Arbeit beschreiben, zusammengetragen und anschließend eine Definition dieser Begriffe erstellt. Mit diesen Begriffen wurde dann die Quellenrecherche begonnen, um die Definitionen zu schärfen und mit Quellen belegen zu können.

Im Anschluss ist eine Recherche nach adäquaten Studien zum Thema „IT-Sicherheit im Fahrzeug“ sowie zum Thema „Defense in Depth“ durchgeführt worden. Der Recherche lagen neben den zuvor verwendeten Quellen auch solche zugrunde, auf die in den ersten gefundenen Quellen verwiesen wurde. Es folgte eine Literaturauswertung der Quellen, welche ein Bild des aktuellen Forschungsstandes ergaben.

Auf dieser Basis wurde ein Vergleich angestellt, welcher den Ist-Zustand der IT-Sicherheit in Fahrzeugen gegenüber einem angestrebten Soll-Zustand betrifft, sowie ein Vergleich, inwiefern sich klassische IT-(Sicherheits)Architektur von der eines Fahrzeugs unterscheidet. Darauf aufbauend wurden IT-Sicherheitslösungen für Fahrzeuge analysiert und evaluiert. Zum Schluss wurde analysiert, wie über einen Defense in Depth Ansatz die IT-Sicherheitsarchitektur in Fahrzeugen verbessert werden kann.

In Kapitel zwei dieser Arbeit werden die theoretischen Grundlagen dieser Arbeit behandelt, welche für das weitere Verständnis notwendig sind. Dabei werden die wichtigsten Begriffe und deren Bedeutung definiert und voneinander abgegrenzt.

Im dritten Kapitel wird auf den aktuellen Forschungsstand eingegangen. Es werden ausgewählte Studien zur derzeitigen Situation im Bereich „Automotive Security“ dargestellt, zusammengefasst und anschließend ausgewertet. Auf dieser Basis werden Anforderungen und Rahmenbedingungen für die IT-Sicherheit in Fahrzeugen definiert und daraus die dort bestehende Forschungslücke hervorgehoben.

Im Mittelpunkt des vierten Kapitels steht das Beleuchten der in dieser Arbeit verwendeten Methoden. Es wird das Vorgehen bei der Analyse von Defense in Depth Mechanismen beschrieben sowie die Auswahl der gewählten Methoden begründet. Anschließend folgt die Darstellung von Hersteller-Lösungen für IT-Sicherheit in Fahrzeugen und Erkenntnisse über diese.

Die Erstellung von Modellen, eine Bedrohungs- und Risikoanalyse, die Konzeption von verschiedenen Security-Bausteinen sowie die Konzeption von Defense in Depth Mechanismen erfolgt im fünften Kapitel. Dort erfolgt auch eine Evaluierung und kritische Analyse der Lösungen und Mechanismen sowie ein Ausblick auf eventuellen weiteren Forschungsbedarf.

Das sechste Kapitel schließt mit einer Zusammenfassung der Ergebnisse, einer Schlussfolgerung, wie Fahrzeughersteller und deren Zulieferer die Erkenntnisse dieser Arbeit nutzen können sowie ein Ausblick auf die möglichen weiteren Entwicklungen.

2 Defense in Depth und Automotive Security - Theoretische Grundlagen

In diesem Kapitel werden die wichtigsten Begriffe beschrieben, welche für das Verständnis der Arbeit notwendig sind. Im Laufe der Arbeit verwendete Begrifflichkeiten werden sich stets auf die hier getroffenen Definitionen beziehen.

2.1 Defense in Depth – Bedeutung und Begriffsabgrenzung

Defense in Depth hat, je nach Einsatzgebiet, verschiedene Bedeutungen. In der Informationstechnologie (IT) beschreibt Defense in Depth ein umfassendes Security-Konzept (Kästner, 2007) für IT-Systeme. Dafür werden verschiedene Maßnahmen, auch Abwehr- oder Verteidigungslinien genannt, kombiniert, um Risiken für einen Angriff auf die IT zu minimieren (Lass, et al., 2014). Maßnahmen können sowohl IT-Maßnahmen sein, also zum Beispiel der Einsatz von Sicherheitssystemen für Verschlüsselung, Virenschutz, Berechtigungsmanagement etc., oder auch organisatorische Maßnahmen, wie das Schulen von Mitarbeitern bezüglich Security-Awareness oder dem Aufstellen von entsprechenden Dienstanweisungen. Wichtig ist auch, dass für einen erfolgreichen Defense-in-Depth-Ansatz alle Beteiligten mitwirken müssen: Ob Hersteller, Provider, Integratoren, Externe Ressourcen, IT-Mitarbeiter und Mitarbeiter aus anderen Bereichen (Kobes, 2016).

Defense in Depth ist, keine Erfindung der heutigen IT. Defense in Depth und dessen Konzept kommt aus dem Militärgebrauch und wurde schon im Mittelalter angewandt. Dort wurden Städte und Burgen nach dem Defense in Depth Konzept aufgebaut, wie Abbildung 1 zeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Schematischer Aufbau einer Burg am Beispiel Burg Oberlauda (Krahe, 2000)

Die äußerste Abwehrlinie war hier ein Graben, dann kam die erste Mauer mit Türmen, dann die Vorburg und zum Schluss die Hauptburg mit dem Bergfried als letzten Rückzugsort. Zwischen den einzelnen Bereichen gab es jeweils nur einen Zugang durch ein Tor wo kontrolliert wurde, wer reinkommt und wer rausgeht. Ein Angreifer konnte nicht gleich in das Innerste der Burg vordringen, sondern musste nach und nach die einzelnen Verteidigungsanlagen überwinden. Das gleiche Prinzip gilt noch heute in der IT.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Defense in Depth Ansatz. Nach (Larson, et al., 2009)

Ein anderer Ansatz von Defense in Depth stammt von den schwedischen Wissenschaftlern Dr. Ulf Larson und Dennis Nilsson. Diese beschreiben Defense in Depth als das Zusammenspiel von verschiedenen Stufen oder Vorgehensweisen, um Angreifer abzuwehren. In ihrem Model gibt es drei Stufen, welche auch in dieser Reihenfolge greifen sollen: Vermeidung (Prevention), Erkennung (Detection) und Ablenkung (Deflection), wie. Abbildung 2 zeigt.

Dabei gilt der Grundsatz, dass so viele Angriffswege wie möglich vermieden werden sollen. Angriffe, die nicht abgewehrt werden können, deren Schutz zu teuer ist bzw. die Kosten dafür nicht in Relation mit dem Sicherheitsgewinn stehen, diese sollen zumindest erkannt werden, um dann Maßnahmen treffen zu können. Ablenkung beschreibt das Aufstellen von sogenannten „ Honeypots ² “. Angreifer sollen so auf Systeme gelenkt werden, bei denen sie keinen Schaden anrichten können und um Sicherheitsexperten die Möglichkeit zu geben, den Angreifer und sein Vorgehen zu studieren.

Viele Unternehmen oder Systeme, die Defense in Depth noch nicht anwenden, beschränken sich darauf, dass geprüft wird, welche Daten zu- und welche abfließen, den sogenannten Perimeterschutz. Perimeterschutz ist als Schutz eines Objektes wie einem IT-System durch Vorkehrungen in dessen Umfeld gedacht (Kersten, et al., 2008) und soll Schutz vor unerlaubtem Eindringen bieten, die Grenze des Schutzraumes nach außen markieren und diese Grenze durch geeignete Überwachungsmaßnahmen überwachen (Schwarz, 2018).

Um Defense in Depth auch für Unternehmen, denen das Wissen oder der Ansatz für den Aufbau einer sicheren IT-Landschaft fehlt, besser verständlich zu machen, wurde von der International Electrotechnical Commission (IEC) in Zusammenarbeit mit dem American National Standards Institute (ANSI) und der International Society of Automation (ISA) ein Standard für Cyber Security entwickelt. Dieser Standard trägt die Normnummer IEC62443, bzw. ANSI/ISA-99, wenn man das Pendant des ANSI dazu nimmt. Der Standard ist in vier Kategorien aufgeteilt:

1. Generelles: Terminologie, Konzepte und Modelle
2. Richtlinien und Verfahren: Aufbauen von Kontroll-Systemen, eines Patchmanagements und Anforderungen an Service Provider
3. Systeme: Netzwerk- und Systemsicherheit, Security Technologien und Security-Anforderungen, Aufbau von Zonen und Security-Level
4. Komponenten: Anforderungen an einen sicheren Produktentwicklungslebenszyklus

Der Punkt, welcher den Grundgedanken von Defense in Depth am treffendsten beschreibt, nämlich den Aufbau eines Schichtmodelles mit verschiedenen Verteidigungslinien, ist im Standard IEC62443-3.2, bzw. ANSI/ISA-99-3.2 geregelt. Dort wird das Konzept von „Zones“ und „Conduits“ (z.dt. Zonen und Leitungen) wie folgt beschrieben:

- „Zonen sind Gruppierungen logischer oder physischer Anlagen mit gleichen Security Anforderungen. Eine Zone hat eine klar definierte Grenze (entweder logisch oder physisch), welche die Abgrenzung von enthaltenen und ausgeschlossenen Elementen darstellt.“ (Torfino Security, 2012)
- „Ein Conduit ist ein Pfad für den Fluss von Informationen zwischen zwei Zonen. Der Conduit kann Sicherheitsfunktionalitäten haben, welche die Kommunikation zwischen Zonen absichert. Daten zwischen Zonen dürfen ausschließlich über Conduits ausgetauscht werden.“ (Torfino Security, 2012)

Für jede Zone und für jeden Conduit kann es dann unterschiedliche Sicherheitsmaßnahmen geben. Bei Zonen kommt es auf deren Systeme an, welche sich in ihr befinden. Eine Zone mit Webservern braucht andere Schutzmaßnahmen als eine Zone, in welcher Datenbanken mit hochkritischen Daten stehen. Ebenso gibt es für Conduits Sicherheitsfunktionen. Die am häufigsten genutzten sind hier Firewalls und VPNs. Firewalls überwachen und kontrollieren den Datenstrom zwischen Zonen, während der VPN dafür sorgt, dass Daten nur verschlüsselt und damit für Unbefugte nicht lesbar zwischen Zonen ausgetauscht werden.

Allerdings hat der Defense-in-Depth-Ansatz auch Nachteile. Ein Nachteil ist zum Beispiel die Geschwindigkeit. Je mehr Zwischenstationen und Prüfungen durchlaufen werden müssen, umso länger brauchen die Daten von ihrer Quelle zu ihrem Ziel. In Systemen oder Anwendungen, wo Zeit ein wichtiger Faktor ist, kann dies zum Problem werden. Dies gilt insbesondere bei Echtzeitanforderungen wie in Connected Cars. Ein weiterer Nachteil sind die Kosten. Mehr Sicherheit heißt in der Regel auch immer zusätzliche Investitionen. Und je mehr Zonen und Conduits es gibt, desto mehr Sicherheitskomponenten werden benötigt, um diese abzusichern. Es gilt also Kosten und Nutzen abzuwägen, ob mehr Sicherheitstechnik ab einem bestimmten Level das Sicherheitsniveau noch merklich hebt. Außerdem muss bei diesem Modell Sicherheit von allen Beteiligten gelebt und umgesetzt werden. Dazu müssen diese auch das benötigte Wissen und die Security-Awareness besitzen. Dies durchzusetzen ist oft eine organisatorische Herausforderung für Unternehmen.

2.2 IT-Sicherheit und ihre Komponenten

IT-Sicherheit, hier synonym mit Informationssicherheit und IT-Security verwendet, beschreibt den Schutz von Informationen, welche elektronisch gespeichert sind oder elektronisch transportiert werden, Dabei sollen vor allem Knowhow von Unternehmen sowie die Daten von Mitarbeitern, Kunden und Lieferanten geschützt werden, um wirtschaftliche Schäden zu verhindern (Prof. Dr. Eckert, 2013). Hierfür wird durch Schutzziele für IT-Sicherheit beschrieben, welche Systeme und deren abzusichernde Zustände und Eigenschaften (Bedner, et al., 2010) mit welchen Maßnahmen geschützt werden müssen.

Dazu werden zwei Arten von Schutzzielen beschrieben: Der Schutz von Privacy und der Schutz von IT-Systemen. Privacy beschreibt den Schutz von allen Daten, die als sogenannte personenbezogene Daten gelten. Dies gilt für alle Daten, die sich einer Person unmittelbar oder mittelbar zuordnen lassen, wie Name, Alter, Anschrift, aber auch IP-Adressen, GPS-Standort, Mails, Kalendereinträge, Einkaufsverhalten etc. Zum Schutz von IT-Systemen zählen alle Maßnahmen, die IT-Systeme jeglicher Art vor Angriffen schützen. Ein System kann dabei ein Server in einem Rechenzentrum, ein Smartphone oder ein Sensor in einem Auto sein. Die Aufgabe von IT-Sicherheit dabei ist, einen möglichst umfassenden, effektiven und effizienten Schutz vor Angriffen zu bieten, ohne den Nutzer oder das System unnötig zu belasten und ohne unverhältnismäßige Kosten zu verursachen.

Um die Gliederung und Einführung von Maßnahmen zu vereinfachen, wurden Schutzziele in ursprünglich drei Hauptkategorien eingeteilt: Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability). Diese Einteilung wurde als „ CIA-Triade “ bezeichnet. In der Literatur werden diese Schutzziele oft noch um weitere verschiedene Kategorien erweitert, wie zum Beispiel die „Nichtverfolgbarkeit bei Privatpersonen“ (Untraceability), „Verfolgbarkeit bzw. Revisionssicherheit bei Firmen“ (Traceability) und Verbindlichkeit (Liability). In dieser Arbeit werden aber nur die drei Schutzziele aus der CIA-Triade behandelt:

- Vertraulichkeit besagt, dass Daten nur von Personen oder Systemen gelesen werden dürfen, wenn diese dafür berechtigt sind. „Vertrauliche Informationen müssen vor unbefugter Preisgabe geschützt werden“. (BSI, 2018)
- Integrität beschreibt, dass Daten weder verloren gehen, noch auf dem Übertragungsweg unerlaubt verändert werden dürfen. „Die Daten sind vollständig und unverändert. Der Begriff ‚Information‘ wird in der Informationstechnik für ‚Daten‘ verwendet, denen je nach Zusammenhang bestimmte Attribute wie z. B. Autor oder Zeitpunkt der Erstellung zugeordnet werden können. Der Verlust der Integrität von Informationen kann daher bedeuten, dass diese unerlaubt verändert wurden oder Angaben zum Autor verfälscht wurden oder der Zeitpunkt der Erstellung manipuliert wurde.“ (BSI, 2018)
- Verfügbarkeit sagt aus, dass Dienstleistungen, Funktionen eines IT-Systems oder auch Informationen dem Benutzer zum geforderten Zeitpunkt zur Verfügung stehen. (BSI, 2018). Dies wird mit der Ausfallabsicherung, der Skalierbarkeit und der entsprechenden Flexibilität und Performance von Systemen erreicht.

Um diese Schutzziele zu erreichen, gibt es verschiedene Wege. Zum einen organisatorisch im Betrieb selber, durch das Umstellen von internen Strukturen und Prozessen, zum anderen durch Schulung und Sensibilisierung von Mitarbeitern. Ein anderer Weg ist die Investition in Hardware und Software, welche zur Erhöhung der Sicherheit beitragen oder das Beauftragen von Experten und externen Ressourcen.

Dabei kann zudem unterschieden werden in aktive und passive IT-Sicherheit. Aktive Sicherheitskomponenten sind solche, die aktiv und präventiv für eine erhöhte IT-Sicherheit sorgen. Das können Infrastrukturkomponenten wie Firewalls, Virenscanner oder Public Key Infrastrukturen (PKIs) sein, aber auch Investitionen in Beratung, in ein Rollen- und Berechtigungsmanagement, in Systemhärtung und ähnliches. Passive Sicherheit umfasst zum einen alles, was im Falle eines Angriffs bzw. eines erfolgreichen Angriffs dabei hilft, dessen Auswirkungen abzuschwächen. Darunter zählen Backups, Log-Dateien, die ausgewertet werden können oder entsprechende Notfallpläne. Aber auch das IT-sicherheitskonforme Verhalten der Mitarbeiter im Berufsalltag trägt passiv zur Gesamtsicherheit bei.

Es ist aber auch anzumerken, dass hier eine Lösung zu wählen oder ein Weg einzuschlagen wieder nur zu einem unvollständigen Schutz führen würde. Erst das Zusammenspiel der einzelnen beschriebenen Komponenten bringt eine umfasse IT-Sicherheit hervor.

2.3 Fahrzeuge und Fahrzeugarchitektur – Grundlegende Bestandteile

Der Begriff Fahrzeug in dieser Arbeit ist gleichzusetzen mit einem Kraftfahrzeug (Kfz). Laut Straßenverkehrsgesetz (StVG) ist ein Kraftfahrzeug „ein durch Maschinenkraft angetriebenes, nicht an Gleise gebundenes Landfahrzeug“ (§ 1 II StVG), beziehungsweise beschreibt der Begriff Fahrzeug im Strafgesetzbuch (StGB) „nicht nur Kfz, sondern alle Fahrzeuge, die zur Beförderung von Personen oder Sachen dienen und am Verkehr auf der Straße teilnehmen“ (§315c Rn. 5 StGB). In dieser Arbeit wird sich der Begriff Fahrzeug allerdings auf Personenkraftwagen (Pkw) und Lastkraftwagen (Lkw) beschränken, da diese in erster Linie die Zielgruppe im Kontext der Arbeit ausmachen.

Unter die Bezeichnung eines Fahrzeugs fällt auch die Definition eines Connected Car. Bislang gibt es keine offizielle Definition, was ein Connected Car ist. Es ist mehr ein Sammelbegriff, welcher die Konnektivität eines Fahrzeugs mit seinen eigenen Systemen, mit seinem Fahrer und seiner Umwelt beschreibt (Dr. Löffler, et al., 2017). Die Konnektivität mit der Umwelt wird meist noch untergliedert in Begriffe wie Car-to-Car (meist geschrieben als Car2Car), Car2Infrastructure, Car2Pedestrian, Car2X etc.

In dieser Arbeit werden die Begriffe Connected Car und Fahrzeug synonym verwendet.

Ein Teil eines Fahrzeugs ist dessen Architektur. Die Fahrzeugarchitektur beschreibt den Aufbau des Fahrzeugs hinsichtlich seiner E/E-Architektur³ (Elektrik-/Elektronik-Architektur) und deren Funktionen. Dazu gehören alle elektrisch oder elektronisch gesteuerten oder ansteuerbaren Bauteile eines Fahrzeugs wie Fahrassistenz, Infotainment (Informations- und Entertainmentsystem), Controler-Area-Network-Bus-Systeme (CAN-Bus-Systeme), Aktoren, Sensoren, Electronic Control Units (ECUs⁴ ) und Telematic Control Units (TCUs) (Dégardins, et al., 2009); (Kerschenlohr, 2015). In der Fahrzeugarchitektur wird außerdem die Vernetzung im Fahrzeug und die Steuergerätetopologie beschrieben. Basis sind hier meist Anforderungen an Funktionen und technische Kriterien (Gerstel, 2016).

Die einzelnen Begriffe werden dabei wie folgt definiert:

- Ein Sensor ist eine technische Komponente, welcher einen bestimmten Umwelteinfluss meist physikalisch „wahrnimmt“ und darauf reagiert, in dem er den Einfluss in ein elektrisches Signal umwandelt. So gibt es zum Beispiel einen druckempfindlichen Sensor, welcher wahrnimmt, ob der Knopf für den Fensterheber betätigt wurde und einen optischen Sensor der merkt, wenn Regen auf die Frontscheibe tropft.
- Als ECU werden kleine Steuergeräte im Fahrzeug bezeichnet, die meist nur eine einzige spezifische Funktion haben. So gibt es zum Beispiel eine ECU, die steuert, ob ein Fenster auf- oder zugehen soll. Eine andere ECU entscheidet, ob die Scheibenwischer eingeschaltet sein müssen und mit welcher Geschwindigkeit sie wischen.
- Ein Aktor ist eine elektronische Einheit, welche ein Signal (meist aus einer ECU) in eine mechanische Aktivität umsetzt. Ein Aktor ist zum Beispiel der Motor, der das Fenster öffnet oder schließt. Ein anderer Aktor betreibt den Scheibenwischer.
- Als TCU werden jene Bauteile beschrieben, welche für die Kommunikation zwischen den verschiedenen Bus-Systemen, als auch mit externen Quellen über Funk, WLAN, Bluetooth usw. verantwortlich sind. Ein anderer häufig verwendeter Begriff ist demnach auch Kommunikationsmodul oder Com-Unit.

Abbildung 3 zeigt für beide aufgeführte Beispiele, wie die einzelnen Komponenten, Sensor, ECU und Aktor zusammenarbeiten. Der Sensor nimmt ein Umwelteinfluss wahr, in diesem Fall Regen. Er leitet diesen Eindruck elektrisch an die ECU weiter. Diese nimmt das Signal auf, interpretiert und kombiniert es mit Signalen von anderen Sensoren oder ECUs (z.B. ob die Zündung eingeschalten ist oder ob der Scheibenwischerhebel auf „Automatik“ steht).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Zusammenspiel von Sensor, ECU und Aktor

Die ECU entscheidet, welches Signal an den Aktor weitergegeben wird, in diesem Fall „wischen in gewissen Abständen“, je nach benötigter Wischgeschwindigkeit. Der Aktor wandelt das Signal in Bewegungsenergie um. Der Scheibenwischer bewegt sich.

Über die letzten Jahre hat die Anzahl der Sensoren, Aktoren und ECUs stark zugenommen. Im Jahr 2003 waren in einem durchschnittlichen Mittelklassefahrzeug (z.B. Golf 3) noch rund 30 Sensoren, 50 bis 80 Aktoren und 35 ECUs verbaut. Zehn Jahre später, im Jahr 2013 waren es schon rund 75 Sensoren, 120 bis 150 Aktoren und 70 ECUs. Also eine Verdopplung der elektronischen Komponenten. Ein Connected Car aus dem Jahr 2016, wie der damals vorgestellte neue BMW 7er, mit Funktionen wie einer Gestensteuerung, Lenkassistent, Abstandstempomat, Stauassistent, adaptiven Scheinwerfern, ferngesteuertem Parken und vielen weiteren Funktionen, hat schon rund 130 Sensoren, 170 Aktoren und 120 ECUs, also teilweise nochmal eine Verdoppelung von elektronischen Komponenten in nur drei Jahren. Dazu ist zu sagen, dass dieser BMW 7er nur Level zwei der fünf Level des autonomen Fahrens⁵ leisten kann. Es ist also anzunehmen, dass mit dem baldigen Aufkommen von Level-3-Fahrzeugen (wie dem 2018 vorgestellten neuen Audi A8) die Anzahl der Komponenten nochmal stark zunehmen wird.

Aber nicht nur die steigende Anzahl an Fahrassistenz- und Komfortsystemen sorgt dafür, dass die Fahrzeugarchitektur immer komplexer wird und somit auch die elektronischen Komponenten zunehmen. Ein anderer Grund ist auch der modulare Aufbau der Fahrzeuge. Zum einen werden immer mehr Komponenten zu Modulen zusammengefasst, da so der Einkauf wirtschaftlicher ist, Module innerhalb eines Konzerns für verschiedene Fahrzeugbaureihen oder Marken verwendet werden können, weil so die Reparatur schneller geht und weil es bei den meisten Fahrzeugen für verschiedene Module mehr als eine Auswahlmöglichkeit gibt. Letzteres ist der Tatsache geschuldet, dass Kunden, welche ein Neufahrzeug erwerben möchten, dieses auch nach eignen Wünschen und Vorstellungen selber konfigurieren und anpassen möchten. Dementsprechend gibt es in den Konfiguratoren der Fahrzeughersteller tausende verschiedene Möglichkeiten, wie das fertige Fahrzeug am Ende aussehen kann. Dabei unterscheidet sich dadurch auch die Architektur von Fahrzeug zu Fahrzeug. Wie Abbildung 4 zeigt, gibt es bei den Plattformen CAN-Antrieb, CAN-Komfort und CAN-Diagnose stets mehrere Möglichkeiten, welche der Kunde wählen kann. Teils können Module parallel genutzt werden, wie die Parksensoren, der Abstandsradar und der Spurhalteassistent beim CAN-Antrieb. Teils ist es aber auch eine Entweder-oder-Entscheidung: Entweder nur das Radio oder das Navigationssystem „Standard“ oder „Premium“ usw.

Deshalb ist es im Gegensatz zu den Fahrzeugen vor der Jahrtausendwende bei neueren Fahrzeugen unwahrscheinlicher, zwei Fahrzeuge desselben Modells zu finden, welche eine identische Konfiguration haben. Trotzdem müssen alle Module, Komponenten und ECUs im Fahrzeug zusammenpassen, egal welche Konfiguration der Kunde wählt.

Aufgrund dieses Aufbaus mit Sensoren, Aktoren und ECUs werden Fahrzeuge heutzutage oft auch als Automotive Cyber-System bzw. Automotive Cyber-Physical-System bezeichnet. „Cyber-Physical-Systems adressieren die enge Verbindung eingebetteter Systeme zur Überwachung und Steuerung physikalischer Vorgänge mittels Sensoren und Aktuatoren über Kommunikationseinrichtungen mit den globalen digitalen Netzen (dem ‚Cyberspace‘)“. (Broy, 2010)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Beispielhafte Vernetzung im Fahrzeug

Ein Automotive Cyber-System ist demnach das Zusammenspiel der elektronischen Komponenten (Aktoren, Sensoren, ECUs…) mit der digitalen Umwelt, mit welcher das Fahrzeug über Mobilfunk, WLAN etc. verbunden ist, wie Abbildung 5 Fehler! Verweisquelle konnte nicht gefunden werden. schematisch zeigt. Der Kommunikator ist in diesem Fall die ECU, der Prozessor das zentrale CAN-Gateway. Die Zusammenführung von Umwelt und einem System, was diese selbstständig wahrnehmen und auf sie reagieren kann, ist eine Voraussetzung für die zukünftigen Level des autonomen Fahrens.

Auch die Fahrzeughersteller haben erkannt, dass die steigende Komplexität durch immer neue Funktionen bald nur noch schwer zu managen ist. Deshalb gibt es Überlegungen und Konzepte, um die heutige E/E-Architektur weiter zu entwickeln. Wie häufig in der IT, wenn ein System in viele kleine Bestandteile aufgeteilt und dadurch eine hohe Komplexität erlangt hat, so geht auch bei Fahrzeugen der Trend wieder in Richtung Zentralisierung, wie die folgende Abbildung 6 zeigt.es autonomen Fahrens.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Evolution von E/E-Architekturen in den nächsten Jahren. (Haas, et al., 2016)

Wie schon beschrieben, sind ECUs derzeit modular aufgebaut und jede ECU hat meist nur eine einzige Funktion. Es gibt teils aber schon Ansätze, einzelne ECUs zu einem größeren Modul zusammenzufassen, die sogenannte funktionale Integration. Ein Bei spiel hierfür ist die kombinierte Multifunktionskamera in der Frontscheibe, welche mehrere Aufgaben, die früher getrennt waren, inzwischen vereint und in einer gemeinsamen ECU verarbeitet (z.B. Lichteinfall, Regen und die Erkennung von Fahrstreifen).

Der nächste wahrscheinliche Schritt ist die Zusammenfassung von ECUs unter einer Master- bzw. Domain-ECU, welche alle Aufgaben einer Domäne bewältigt. Zum Beispiel eine ECU für die Domäne „Licht“ oder „Temperatursteuerung“. Auch die Fusionierung von Domänen ist denkbar, dass immer mehr Funktionen in einer zentralen Einheit verwaltet und gesteuert werden. Ein letzter Schritt könnte die Zusammenfassung zu Zonen sein, was einer Zone aus dem Defense in Depth Konzept gleichgesetzt werden kann: Domänen mit gleichen Security Anforderungen werden zusammengefasst und im allerletzten Schritt, sofern möglich, in der Cloud abgebildet. Bis dahin ist es allerdings noch ein weiter Weg. (Haas, et al., 2016)

Ein letzter Punkt, welcher in diesem Unterkapitel noch beleuchtet werden soll, ist der Unterschied zwischen Safety und Security. In der deutschen Sprache gibt es für beide Begriffe nur einen: Sicherheit. Dabei beschreiben Safety und Security zwar zwei zusammenhängende, aber doch unterschiedliche Dinge. Safety beschreibt ein System, das sich auf den Schutz von Menschen und Umwelt fokussiert, oft auch als funktionale Sicherheit bezeichnet wird (Lass, et al., 2014). Im automobilen Kontext fallen bislang fast alle Funktionen, die als „Sicherheitsfunktionen“ aufgeführt werden, in die Kategorie Safety. Für diese Kategorie gibt es auch eine international gültige Norm: Die ISO 26262 und die IEC61508, welche aufeinander aufbauen. Diese gliedert Safety in Automotive Safety Integrity Levels (ASIL) von A bis D, wobei ASIL A für ein niedriges Level steht und ASIL D für ein hohes. Beispiele für Safety-Funktionen sind Airbags, die Knautschzonen des Fahrzeugs oder Notbremsassistenten.

Mit Security wird der Schutz eines Systems oder Informationen vor unerlaubten Zugriffen oder vor Manipulation beschrieben, ob durch Menschen oder die Umwelt (Lass, et al., 2014). In einem Fahrzeug wäre das zum Beispiel die Absicherung einer Mobilfunkschnittstelle gegen Angreifer. Grundsätzlich kann man, wenn man von Privacy mal absieht, bei Fahrzeugen davon ausgehen, dass alle Security-Maßnahmen der Safety gelten. Das heißt, durch Security-Maßnahmen, wie Zertifikate oder Verschlüsselung, wird zum Beispiel verhindert, dass Angreifer auf Safety-Features wie den Airbag zugreifen und diesen auslösen.

Eine ähnliche Einteilung, welche in der Literatur häufig zu finden ist, ist die Einteilung in sicherheitsbezogene- und sicherheitsrelevante Systeme, sowie in aktive und passive Sicherheit:

- Das sicherheitsbezogene System reduziert Risiken (zählt also zu Safety)
- Das sicherheitsrelevante System kann durch Fehlfunktionen Gefahren verursachen und muss deshalb entsprechend abgesichert werden (Benz, 2004)
- Aktive Sicherheit beinhaltet Systeme, die helfen, Unfälle zu vermeiden
- Passive Sicherheit beschreibt Systeme, die die Folgen eines Unfalls mindern

3 Aktueller Forschungsstand Automotive Security

In diesem Kapitel wird zunächst der aktuelle Forschungsstand ausgewertet. Es wird beschrieben, wie vorgegangen, welche Studien herangezogen und welche Erkenntnisse getroffen wurden. Im Anschluss werden die Erkenntnisse zusammengefasst und die Rahmenbedingungen um IT-Sicherheit in Fahrzeuge zu bringen, erläutert.

3.1 Vorgehen bei der Auswahl und Auswertung von Studien und wissenschaftlichen Artikeln

Die wichtigsten Schlüsselbegriffe bei der Suche waren zunächst einmal die Termini aus den Bereichen „Defense in Depth“ und „Fahrzeug Sicherheit“. Von diesen beiden Begriffen ausgehend wurden über Schlagwörter in den Dokumenten und über genannte Quellen weitere Begriffe identifiziert, nach denen im Anschluss ebenfalls gesucht wurde. Es stellte sich heraus, dass sich zwei Suchcluster voneinander unabhängig bildeten: Das eine beschäftigte sich mit IT und IT-Sicherheit, das andere mit Fahrzeugen und Unterthemen hierzu. Die beiden Suchcluster und die dazugehörigen Schlüsselwörter werden im Folgenden in Abbildung 7 und Abbildung 8 dargestellt.

Anhand dieser Sammlung an Suchwörtern wurden dann Studien gesucht. Es wurden vorrangig Studien gewählt, welche mehr als eins der aufgezeigten Schlüsselwörter beinhalteten. Außerdem wurde auf eine möglichst hohe Aktualität der Studien geachtet. So wurden nur Studien gewählt, welche nach 2005 veröffentlicht wurden. Dabei wurden ähnliche Studien, welche ein neueres Veröffentlichungsdatum aufwiesen, bevorzugt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Suchcluster "Fahrzeug Security

Die Studien wurden in erster Instanz nach Schlagworten durchsucht und dementsprechend gegliedert, ob sie sich eher mit „Fahrzeug Security“ oder mit „Defense in Depth“ beschäftigten. Die Studien, die beide Themen enthielten, sind die dritte Kategorie.

Es wurden schlussendlich acht Studien und Artikel ausgewählt, die hier im Folgenden dargestellt werden:

- Adler, Ebert: Automotive Cyber-Security-Erfahrungen für die Entwicklungspraxis
- Bouard, Graf, Weyl: Smart Apps in einem vernetzten (auto)mobilen Umfeld: IT-Security und Privacy
- Braunbach, Jander, Pokahr: Defense-in-depth and Role Authentication for Microservice Systems
- Fabro, Kuipers: Control Systems Cyber Security: Defense in Depth Strategies
- Larson, Nilsson: A Defense-in-Depth Approach to Securing the Wireless Vehicle Infrastructure
- Kotarski, Lass: IT-Sicherheit als besondere Herausforderung von Industrie 4.0
- Miller, Valasek: A Survey of Remote Automotive Attack Surfaces
- Smith: A Car Hackers Handbook

3.2 Analyse ausgewählter Studien zu Automotive Security und Darstellung von deren Ergebnissen

3.2.1 Automotive Cyber-Security-Erfahrungen für die Entwicklungspraxis

Adler und Ebert (2016) zeigten in ihrem Artikel auf, wieso das Zusammenspiel von Connected Cars und IT-Sicherheit für Automobilhersteller so ein großes Problem ist und mit welchen Methoden gegen dieses Problem vorgegangen werden kann. Dabei fokussierten sie sich besonders auf die Phase der Fahrzeugentwicklung. Sie stellten fest, dass hardwareseitig insbesondere die hohe Komplexität, der hohe Vernetzungsgrad und Verknüpfungen von elektronischen, standardisierten Komponenten, sowie offene Schnittstellen diese zu einem sicherheitskritischen Ziel für Angreifer machen. Die bislang von den Automobilherstellern gelebte Sicherheit ist eine reine funktionale Sicherheit und hat mit IT-Sicherheit wenig zu tun. Wenn überhaupt, dann werden bisher nur Einzelkomponenten geschützt, was zu keinem sicheren Gesamtkonzept führen kann. Außerdem reichte es bislang zwar aus, Fahrzeuge vor direkten Angriffen, bei denen eine physikalische Anwesenheit des Täters nötig ist, zu schützen, aber mit Connected Cars und funkbasierten Verbindungen ist diese Annahme veraltet. Auf der Softwareseite ist das Problem, dass Änderungen an der Software im Fahrzeug oft spontan oder von Dritten durchgeführt würden ohne einen Security-Prozess zu durchlaufen.

Adler und Ebert schlagen daher vor, ein Konzept für den gesamten Produktlebenszyklus zu gestalten, um den Sicherheitsanforderungen gerecht zu werden. Sie benennen dafür einzelnen Maßnahme, insbesondere für die frühen Phasen des Produktlebenszyklus, also Design und Entwicklung. Diese Maßnahmen sehen die Absicherung von Komponenten (z.B. sichere ROM und Flash Module), Schlüsselprüfungen zur Laufzeit Intrusion Detection Systeme (IDS), Verschlüsselung und Penetration Tests vor. Außerdem setzen sie auf eine Sensibilisierung der Mitarbeiter in der Entwicklung sowie auf die Einführung von verbindlichen Design und Coding Standards.

3.2.2 Smart Apps in einem vernetzten (auto)mobilen Umfeld: IT-Security und Privacy

Der Ansatz von Bouard, Graf und Weyl (2012) beschäftigt sich mit Apps, welche für die Kommunikation mit dem Fahrzeug gedacht sind, um damit entweder Daten aus dem Fahrzeug zu erhalten oder Daten einzuspeisen. Dabei betrachten sie neben IT-Sicherheitsaspekten dieser Apps auch deren Privacy-Aspekte. Sie zeigen auf, dass insbesondere personenbezogene Daten des Fahrers ins Visier von Angreifern geraten könnten, die Daten wie Fahrverhalten, Fahrrouten, Kontakte oder Bezahldaten selbst verwerten oder an interessierte Dritte weiterverkaufen könnten, welche wiederum diese dann für Werbung oder ähnliches nutzen. In Bezug auf IT-Security stellen sie besonders das Problem der Validität von Nachrichten oder Daten aus Apps dar. Sie fragen sich, wie ein Fahrer sich zum Beispiel sicher sein kann, das eine Warnung über eine Gefahrenstelle tatsächlich auch wahr und valide ist, und nicht manipuliert. Um darum die Apps besser abzusichern, schlagen die Autoren mehrere Maßnahmen vor: Zum einen sollten Sicherheitskomponenten modularisiert werden, um diese besser anpassen und optimal konfigurieren zu können. Dadurch sind einzelne Module auch besser und schneller austauschbar. Schnittstellen sollten zudem vereinfacht werden, um eine Integration erfolgreich zu machen. Dafür stellen sie ein Schichtenmodell vor, welches auf dem ISO/OSI-Schichtenmodell basiert. Zwischen den dort aufgezeigten einzelnen Units sind einheitliche Schnittstellen (Layer-Enforcement-Points) definiert. Für die Einbindung von externen Modulen ist eine Adapter-API angedacht. Damit könnten auch Apps von OEMs die Security-Features des Modells verwenden. Im Anschluss beschreiben die Autoren die einzelnen Komponenten, sowie den Ablauf des Datenflusses für dieses Modell.

3.2.3 A Defense-in-Depth Approach to Securing the Wireless Vehicle Infrastructure.

Mit einem ähnlichen Thema beschäftigten sich auch Larson und Nilsson (2009). Bei ihnen standen aber nicht die Apps, sondern die Verbindung dieser zum Fahrzeug im Vordergrund. Sie beschäftigten sich mit der Frage, wie Funkzugänge zu einem Fahrzeug abgesichert werden können, auch wenn dazu gesagt werden muss, dass ihre Ausarbeitung schon von 2009 ist.

Die erste Erkenntnis, welche Larson und Nilsson ziehen, ist, dass sich mit dem Einzug von Funktechnologie in Fahrzeuge neue Wege für Angreifer öffnen werden. In-Car-Netzwerke wurden bislang als isoliert betrachtet und auch nur dementsprechend geschützt. Zwar bringen neue Techniken wie „Firmwareupdate Over the Air“ (FOTA) Vorteile für Hersteller und Kunden, dabei sollte aber nicht vergessen werden, solche Technologien auch entsprechend sicher auszugestalten. Außerdem bemängeln sie, dass jede ECU eine eigene Firmware hat und somit auch jede ECU einzeln abgesichert werden muss, zumal ECUs sowieso nur eine limitierte Leistung haben und die Echtzeitübertragung von Daten trotz Security-Maßnahmen weiter gegeben sein muss. Datenverkehr zwischen ECUs erfolgt zudem nicht nur auf IP, sondern auf CAN-Ebene und muss daher auch anders als klassischer IP-Verkehr abgesichert werden.

Nach ihrem schon in Abbildung 2 vorgestellten Modell schlagen sie drei Stufen vor, um Funkverbindungen und ECUs abzusichern: In der ersten Stufe (Prevention) sollte es die Möglichkeit von Secure-FOTA geben. Dabei setzen sie auf die Maßnahmen Verschlüsselung, Hashfunktionen und digitale Signaturen. Über einen von ihnen definierten Prozess soll es somit möglich sein, Firmware-Updates über Funk einzuspielen, ohne dass ein Angreifer dieses manipulieren kann. Für die Verbindung zwischen ECUs schlagen sie eine Verschlüsselung basieren auf Message Authentication (MAC)-Blöcken und MAC-Keys vor. In der zweiten Stufe (Detection) wird die Einführung eines IDS empfohlen, wobei dies so designt wird, dass die Detektoren jeweils direkt an den ECUs andocken, um eine korrekte Zuordnung von richtigen und manipulierten Datenströmen machen zu können. In der dritten Stufe (Deflection) wird der Aufbau eines „Honeypots“ dargestellt, inklusive Logging-Funktionalitäten für eine Analyse im Nachgang.

3.2.4 A Survey of Remote Automotive Attack Surfaces.

Einen anderen Ansatz verfolgen Miller und Valasek (2014), welche durch ihren medienwirksamen Jeep-Hack Bekanntheit erlangt haben. Diese Vorgehensweise sowie ihre Untersuchungen an insgesamt 14 Fahrzeugen werden in ihrer Studie vorgestellt. Dabei analysieren sie die Fahrzeuge und zeigen dabei auf, über welche Komponenten sie sich in die Fahrzeuge einhacken konnten.

Miller und Valasek haben als ihren Ausgangspunkt festgestellt, dass manche ECUs sowohl nach außen (Funk, WLAN, Bluetooth…) als auch nach innen in das In-Car-Network eine direkte Verbindung haben. Das macht diese ECUs besonders anfällig für Angriffe. Dabei beschreiben sie ihren Angriffsweg: Zunächst einmal wird eine ECU, welche eine Verbindung nach außen hat, kompromittiert. Dies kann zum Beispiel bei einer ECU im Listening-Mode durch Code-Injection geschehen. Über diese ECU wird im zweiten Schritt versucht, auf ECUs vorzudringen, welche sicherheitskritische Funktionen (wie Lenkung, Bremsen oder Gas) haben. Dabei wird versucht, auch in diese ECU wieder Schadcode einzubringen und somit eine Verbindung zwischen den Angreifer und der Ziel-ECU aufzubauen. Der letzte Schritt ist, die Ziel-ECU dazu zu bringen, eine sicherheitskritische Aktion auszuführen. Dies kann entweder durch manipulierte Signale (z.B. das Signal „Notbremsung einleiten“) oder durch ein aufspielen von manipulierter Firmware („flashen“) geschehen. Manchmal reicht es aber scheinbar auch aus, nur eine ECU anzugreifen, wenn diese schon die Informationen beinhaltet, auf die es der Angreifer abgesehen hat (wie z.B. Telemetriedaten).

Im Anschluss werden verschiedene Möglichkeiten und Wege beschrieben, über die ein Auto angegriffen werden kann, wie die Diebstahlsicherung, Reifendruckkontrolle, Keyless-Entry-Systeme, oder wie schon angesprochen Funk, WLAN und Bluetooth und viele mehr.

In einer anschließenden Studie von 14 Fahrzeugen unterschiedlicher Marken werden jeweils die Angriffsmöglichkeiten, die verwundbaren ECUs, der Entry-Point und der Angriffsweg dargestellt. Das Ergebnis ihrer Studie war, dass durch die starke Zunahme von ECUs die Angriffsoberfläche ebenso stark zugenommen hat. Zwar unterscheiden sich die getesteten Fahrzeuge von einander, was den Aufbau ihrer Systeme und ihrer Netzwerk-Topologie anbelangt, ähneln sich aber in den einzelnen Regionen (US/Japan/Deutschland) wieder sehr stark. Neuere Modelle haben teils schon eine Segmentierung von Systemen. Angreifbar waren aber alle getesteten Autos. Zum Schluss schlagen Miller und Valasek einige Punkte vor, mit denen Hersteller ihre Fahrzeuge gegen die von ihnen versuchten Angriffe besser schützen können. Die Maßnahmen sind dabei nicht überraschend: Remote-Endpoints sollen besser abgesichert werden, es sollte Maßnahmen gegen Injection auf CAN-Systemen geben, Nachrichten im Fahrzeug sollten verschlüsselt, die Netzwerk-Architektur verbessert und eine Angriffserkennung (IDS) implementiert werden.

[...]

---

¹ Ein sicherheitsrelevantes System ist ein System, dessen Ausfall oder Fehlfunktion eine Gefahr für Leib und Leben bedeuten kann. (Benz, 2004)
² Honeypots sind Server mit nur scheinbar wertvollen Daten wie Adressen und Dokumenten zur Täuschung von Angreifern. Mit ihnen soll von Systemen abgelenkt werden, die tatsächlich wertvolle Daten verarbeiten. (Stevens, et al., 2004)
³ Heutzutage teils auch als E/E/PE-Architektur (Elektrik-/Elektronik/Programmierbar elektronische-Architektur) bezeichnet
⁴ Teils wird mit „ECU“ auch die Engine Control Unit beschrieben, in dieser Arbeit wird aber stets die Electronic Control Unit gemeint sein
⁵ Die fünf Level sind:

1. Assistiert: Fahrer bekommt Unterstützung
2. Teilautomatisiert: Kfz kann Aktionen übernehmen, Fahrer behält Verantwortung
3. Hochautomatisiert: Kfz kann abschnittsweise selbst fahren
4. Vollautomatisiert: Kfz fährt Großteils selbstständig, Fahrer muss nur selten eingreifen
5. Autonom: Fahrzeug kann komplett selbstständig fahren (VDA, 2018)