Illustration anhand exemplarisch gewählter Angriffsszenarien

Funktionen unmittelbar gefährden²³ sollten diese Ereignisse protokolliert und zentral ausge-wertet und ggf. behandelt werden.

Szenario 2: Erkannter Angriffsversuch auf eine geschlossene Sicherheitslücke

Die MAS-Malware versucht von der Freisprecheinrichtung aus die in Abschnitt 3.2.5 identifi-zierte Schwachstelle im zentralen Gateway-Steuergerät auszunutzen um mittels der Angriffs-technik aus L_4.2 im Antriebsstrang gefälschte Befehle für das ESP-Steuergerät zu generieren, die u.a. zur Ansteuerung einzelner Bremsen dienen. Im vorliegenden Fahrzeug wurde die betreffende Gateway-Schwachstelle jedoch bereits durch ein Firmware-Update geschlossen und ein NIDS erkennt den aus dem Infotainment-Netzwerk stammenden Angriffsversuch anhand einer Signatur wie der in Abbildung 37 vorgestellten.

 Schweregrad: Unkritischer Vorfall (mit Fahrerrelevanz)

Der im Infotainment-Netzwerk erkannte Angriffsversuch kann aufgrund der bereits ge-schlossenen Sicherheitslücke als grundsätzlich unkritisch eingestuft werden. Aufgrund der Detektion anhand einer bekannten Angriffssignatur liegen jedoch deutliche Hinweise auf das Vorliegen von Malware in der Infotainment-Domäne vor²⁴. Anhand dieser konkre-ten Feststellung kann auch bei einem unkritischen Vorfall eine grundsätzliche Relevanz für den Fahrer festgestellt werden²⁵.

 Reaktion Level 1: Protokollierung des Vorfalls

Das Auftreten des Security-Vorfalls wird protokolliert (Subtyp 1.1). Da der detektierte An-griff bereits bekannt ist, kann auf die Protokollierung zusätzlicher Angaben zum System-status (Subtyp 1.2) verzichtet werden.

 Reaktion Level 2: Visuelle und akustische Benachrichtigung

Im Rahmen einer Benachrichtigung wird der Fahrer wird aufgefordert, innerhalb der nächsten zwei Wochen die Werkstatt zur Durchführung eines Sicherheitschecks aufzu-suchen. Dies erfolgt in einer neutralen Formulierungsweise, um eine Beunruhigung des Fahrers zu vermeiden. Durch die Einordnung als unkritischer Vorfall wird eine visuelle Benachrichtigung als initialer Subtyp (2.1) gewählt.

Jedoch sei für das betrachtete Szenario 2 angenommen, dass die Innenraumhelligkeits-sensoren eine direkte Sonneneinstrahlung melden, die das Bemerken und die Lesbarkeit der visuellen Warnung potentiell einschränkt. Um sicherzustellen, dass die Warnung wahrgenommen wird, erfolgt daher eine dynamische, adaptive Anhebung der gewählten Benachrichtigungsweise auf Subtyp 2.2, indem die Meldung durch eine zusätzliche akus-tische Ausgabe ergänzt wird.

 Reaktion Level 3: Keine

Als unkritischer Vorfall kommt in Szenario 2 keine Level-3-Reaktion infrage.

Szenario 3: Informationsdiebstahl

Im dritten Szenario sei der Fall betrachtet, dass die eingeschleuste automotive MAS-Malware auf dem Steuergerät der Freisprecheinrichtung sensitive fahrzeuginterne Informati-onen sammelt um diese anschließend an den Angreifer zu übermitteln.

Grundsätzlich könnte ein Angreifer in einem solchen Szenario aus einem sehr breiten Spekt-rum potentiell ausspähbarer Informationen wählen. Diese reichen von lokal zugreifbaren In-formationen wie regulär verarbeiteten Sensor- und Netzwerkeingaben bis hin zu weiteren, externen Informationen, die von dieser Position aus ermittelt oder aktiv angefordert werden können. Mit Bezug auf die Quelle [Domk13] des Praxisbeispiels aus R_5.5 (vgl. auch Abschnitt 3.1.6) sei für Szenario 3 angenommen, dass die Malware zu ausgewählten Zeitpunkten Mik-rofonmitschnitte anfertigt und sämtliche Fahrtrouten anhand der GPS-Daten protokolliert.

23 Bei einer entsprechenden Anomalie in safetykritischen Domänen wie dem Antriebsstrang könnte hingegen eine Relevanz für den Fahrer vorliegen und eine Benachrichtigung erwogen werden.

24 Aus Sicht eines NIDS lässt es sich in diesem Szenario jedoch nicht feststellen, ob es sich dabei um ein bestehendes, mit MAS infiziertes Steuergerät oder um zusätzlich eingebrachte MAH handelt.

25 Dies rechtfertigt nicht zwangsläufig auch eine Anhebung des Schweregrads, u.a. da aus der Info-tainment-Domäne bei funktionaler Domänenisolation i.d.R. keine direkten (oder nur sehr einge-schränkten) Einflussmöglichkeiten auf safetykritische Systeme in anderen Domänen bestehen.

Für Szenario 3 sei zudem angenommen, dass das infizierte Steuergerät der Freisprechein-richtung nicht selbst über eine Anbindung an fahrzeugexterne Kommunikationssysteme ver-fügt sondern das Einleiten bzw. Entgegennehmen von Telefonverbindungen über ein exter-nes Telefoniesteuergerät als eigentliche Sende- und Empfangseinheit abwickeln muss. Um die aufgezeichneten Informationen von Zeit zu Zeit an den Angreifer zu übermitteln, kodiert die Malware sämtliche Daten als Audiosignal und sendet sie über die externe Sende-/Emp-fangseinheit an eine Nummer unter Kontrolle des Angreifers²⁶. Ein NIDS kann einen solchen ausgehenden Verbindungsversuch als deutlichen Hinweis auf einen Security-Vorfall werten, z.B. wenn dieser nachweislich nicht durch die Insassen initiiert worden sein kann²⁷.

 Schweregrad: Kritischer Vorfall

Die für die Warnung maßgebliche Ursache liegt in der Detektion des unautorisierten Ver-bindungsaufbaus, als dessen Quelle ein Gerät in der Infotainmentdomäne ermittelt wer-den kann. Zunächst ist bekannt, dass die aufgebaute Verbindung bidirektionalen Charak-ters ist, d.h. ein Angreifer darüber sowohl lesend als auch schreibend mit einer automoti-ven Malware interagieren kann. Für safetykritische Systeme anderer Fahrzeugdomänen sind bei funktionaler Domänenisolation hierdurch keine unmittelbaren Gefahren zu erwar-ten. Allerdings werden innerhalb der betroffenen Infotainmentdomäne vergleichsweise viele personenbezogene bzw. -beziehbare Daten erfasst und verarbeitet, die in diesem Fall möglicherweise ausgespäht und ausgeleitet werden. Ob und auf welche Daten dies in welchem Umfang zutrifft und in welchem Umfang die Privatsphäre der Insassen be-droht ist, ist im betrachteten Szenario aus Sicht des NIDS jedoch nicht klar ersichtlich.

Während die vorigen Aspekte mindestens eine Einordnung als unkritischer Vorfall mit Fahrerrelevanz rechtfertigen, ergibt sich die Behandlung als kritischer Vorfall durch einen wichtigen zusätzlichen Aspekt: Zwar weisen die Randbedingungen darauf hin, dass die detektierte Kommunikation im Verborgenen abgewickelt wird, jedoch ist die Verfügbarkeit des Telefonsystems währenddessen durch die belegte Verbindung stark eingeschränkt.

Während dieser Phasen wäre der Fahrer nicht in der Lage, eigene Anrufe einzuleiten und aufgrund entsprechender, vergeblicher Versuche wäre mit einer zunehmenden Ablen-kung des Fahrers zu rechnen.

 Reaktion Level 1: Protokollierung des Vorfalls und Systemstatus

Der detektierte Hinweis auf einen Security-Vorfall in der Infotainment-Domäne wird pro-tokolliert (Subtyp 1.1) und zur späteren Analyse mit Angaben zum Systemstatus (Subtyp 1.2) ergänzt.

 Reaktion Level 2: Visuelle und akustische Benachrichtigung

Wie bereits in Szenario 2 wird der Fahrer im Rahmen einer Benachrichtigung in einer neutralen Formulierungsweise aufgefordert, innerhalb der nächsten zwei Wochen die Werkstatt zur Durchführung eines Sicherheitschecks aufzusuchen. Da der zu behandeln-de Vorfall als kritisch eingeordnet ist, wird bereits als initial gewählter Subtyp eine akusti-sche Benachrichtigung (Subtyp 2.2) gewählt, die mit einer visuellen Meldung (Subtyp 2.1) einhergeht. In Szenario 3 kann über die Innenraummikrofone ein normaler Geräuschpe-gel im Fahrzeuginneren festgestellt werden, so dass der Fahrer die akustische Warnung – und in der Folge die grafische Repräsentation – bemerken sollte. Eine dynamische, adaptive Anpassung der Benachrichtigungsweise bzgl. einer zusätzlichen Einbeziehung haptischer Ausgabeelemente (Subtyp 2.3) ist daher nicht erforderlich.

 Reaktion Level 3: Keine

Da es sich bei Szenario 3 um keinen als „sehr kritisch“ einzustufenden Vorfall handelt, kommt keine Level-3-Reaktion infrage.

26 Grundsätzlich wäre auch transparentes, steganographisches Einbetten in bestehende Telefonver-bindungen möglich, auf die sich der Angreifer jedoch erst (ggf. aufwändig) Zugriff verschaffen müsste.

27 Z.B., wenn dem Verbindungsaufbau kein Vertreter einer vordefinierten Menge von Busnachrichten voranging, mit denen eine reguläre Initiierung durch die Insassen bekanntermaßen verbunden wäre.

Szenario 4: Safetykritischer Eingriff

Einige Trends moderner automotiver Systeme lassen erkennen, dass auch Systeme in info-tainment- oder komfortzentrierten Fahrzeugdomänen zunehmend mit safetykritischen Fahr-zeugfunktionen interagieren. So ist z.B. das in [Niss07] beschriebene Navigationssystem in der Lage, u.a. auf Basis von Kartenmaterial (z.B. vor Kurven) das Fahrzeug automatisch herunterzubremsen und ggf. ein „Herausdrücken“ des Gaspedals einzuleiten. In einem sol-chen System müssten die Gateways an den entspresol-chenden Netzwerkübergängen Regeln vorsehen, um aus der Infotainment-Domäne entsprechende Ansteuerungsbefehle zu den relevanten Systemen im Antriebsstrang (u.a. Bremsensteuergerät) weiterzuleiten.

In Szenario 4 sei angenommen, dass die (im Infotainment-Netzwerk auf dem Steuergerät der Freisprecheinrichtung befindliche) MAS-Malware entsprechende Weiterleitungsregeln aus-nutzt. Ähnlich wie in Szenario 2 versucht sie hierdurch ungewollte Bremsvorgänge einzulei-ten und vorsätzlich eine Gefährdung für das Fahrzeug, seine Insassen und ggf. Menschen in der Umgebung hervorzurufen. Da die dazu auf den Infotainment-Bus eingespielten Nachrich-ten formal zulässige Ereignisse darstellen, sind sie weder für das Gateway-Steuergerät noch für ein vorhandenes NIDS ohne weiteres als bösartig erkennbar. Allerdings kann ein ent-sprechender Angriff durch ein HIDS des (nicht infizierten) Navigationssystems detektiert werden, da die auf dem Infotainmentbus generierten Befehle nicht – wie ausschließlich üb-lich – von diesem System selbst abgesendet wurden.

 Schweregrad: Sehr kritischer Vorfall

Entgegen der Annahmen aus den vorhergehenden Szenarien besteht in Szenario 4 kei-ne wirksame Abschottung der Infotainmentdomäkei-ne zu safetykritischen Systemen. Durch die ungewollten Eingriffe in das Bremssystem ist der betrachtete Vorfall als sehr kritisch einzustufen.

 Reaktion Level 1: Protokollierung des Vorfalls und Systemstatus

Das Auftreten des Security-Vorfalls wird protokolliert (Subtyp 1.1) und zur späteren Ana-lyse mit Angaben zum Systemstatus (Subtyp 1.2) ergänzt.

 Reaktion Level 2: Visuelle, akustische und haptische Benachrichtigung

Der Fahrer wird darüber benachrichtigt, dass eine schwerwiegende IT-Sicherheitsverletz-ung erkannt wurde. Während das Schutzsystem vorläufige Maßnahmen treffen konnte um die bestehende Gefahr einzudämmen (s.u.), sollte der Fahrer das Fahrzeug bei nächster Gelegenheit in sicherer Position anhalten, um es von einem Servicefahrzeug in die nächstgelegene Werkstatt zur Behebung des Problems bringen zu lassen. Durch die Einordnung als sehr kritischer Vorfall wird diese dringliche Benachrichtigung bereits ohne das Vorliegen weiterer Voraussetzungen mit maximaler Intensität nach Subtyp 2.3 unter Einbeziehung visueller, akustischer und haptischer Ausgabeelemente kommuniziert.

 Reaktion Level 3: Wiederherstellung des normalen Systemverhaltens

Da ein als sehr kritisch eingestufter Vorfall vorliegt, wird zunächst versucht, den Angriff zu blockieren (Subtyp 3.1). Dies scheitert im betrachteten Szenario, da das Gateway-Steuergerät – bzw. ein darauf platziertes (N)IDS – die betreffende Busnachricht nicht be-reits bei ihrem Eintreffen als schadhaft identifizieren konnte und diese somit bebe-reits in das Antriebsstrangnetzwerk bzw. an das Bremsensteuergerät weitergeleitet hat. Daher wird mittels Subtyp 3.2 versucht, den Folgen des Angriffs aktiv entgegenzuwirken und so eine Wiederherstellung des normalen Systemverhaltens zu erzielen. Da die Busnachricht unmittelbar nach ihrem Auftreten als schadhaft gemeldet wird, kann das Bremsensteuer-gerät mit geringem zeitlichem Versatz zum sofortigen Abbrechen des Vorgangs ange-wiesen werden. Je nach Ansprechverhalten der elektrischen und mechanischen Umset-zung des Bremseingriffs können die Auswirkungen des Angriffs für den Fahrer somit auf nicht oder nur minimal bermerkliche Effekte begrenzt werden. Zudem wird die ausgenutz-te Weiausgenutz-terleitungsregel bis zur ansausgenutz-tehenden Behebung des Vorfalls deaktiviert. Ein auto-matisiertes Erzwingen des (grundsätzlich angeratenen, s.o.) kontrollierten Anhaltens zum Erzwingen eines sicheren Fahrzeugszustands (Subtyp 3.3) ist daher nicht erforderlich.