6 Integration und Management von Prävention, Detektion und Reaktion
6.3 Automotive Malwareanalyse: Grundlegende Strategien und Möglichkeiten
Als Ergebnis der teilautomatisierten Routenrekonstruktion am Beispiel der o.g. Testfahrt in Magdeburg konnte ausgehend von den eingespielten Logdaten und der angegebenen Start-position die korrekte Route und das korrekte Ziel ermittelt werden. Die Illustration in Abbil-dung 51 zeigt einige Bildschirmfotos bzw. -ausschnitte. Als eine Schwierigkeit des hierzu verwendeten Testgeräts zeigte sich, dass es vom CAN-Bus zwar die Geschwindigkeit ein-liest, die Lenkbewegungen jedoch selbst über ein integriertes Gyrometer ermittelt. Da kein weiteres Testgerät vorlag, das beide Eingabewerte busseitig einliest, mussten die Übergabe der protokollierten Lenkbewegungen im Test daher durch manuelles Drehen des Gerätes simuliert werden.
Bezugnehmend auf das Beispielszenario wären beide vorgestellte Verfahren im Rahmen der Datenanalyse des IT-forensischen Prozesses geeignet, um Indizien zu sammeln, die die Entlastung des der Fahrerflucht verdächtigten Fahrzeugführers unterstützen. Durch die Ko-operation des Fahrzeugbesitzers stellen die im Rahmen der strategischen Vorbereitung pro-tokollierten Daten somit im vorliegenden Fall auch ohne die enthaltenen Geokoordinaten ein wertvolles Hilfsmittel für die IT-forensische Untersuchung des vermuteten Vorfalls dar.
die zu treffende Auswahl aus den verfügbaren Techniken und Werkzeuge haben kann, ist die automotive Malwareausprägung des vorliegenden Untersuchungsgegenstands.
Im Folgenden werden für jede der vorgestellten drei automotiven Malwareausprägungen aus Abschnitt 4.1.1 verschiedene Beispiele relevanter Techniken der Malwareanalyse aufgelistet.
6.3.1 Analysetechniken für Malicious Automotive Software (MAS)
Die Durchführung automotiver Malwareanalysen diskutiert dieser Abschnitt in Bezug auf automotive Malware der Ausprägung MAS. Dazu werden im Folgenden einige beispielhafte Vorgehensweisen genannt, die beim Verdacht des Vorliegens von automotiver Schadsoft-ware auf einem bestehenden Steuergerät für deren Analyse infrage kommen. Insbesondere wird auf Möglichkeiten und Grenzen zur statischen und dynamischen Analyse eingegangen.
Separation der MAS: Extraktion des digitalen Untersuchungsobjekts
Bei MAS handelt es sich um automotive Schadsoftware, die bestehende Steuergeräte infi-ziert hat und dort parallel zur weiterhin vorhandenen Originalsoftware vorliegen kann. In Vor-bereitung der Analyse des eigentlichen Schadcodes ist es daher nötig, zunächst eine kon-krete digitale Repräsentation dieses Codes zu ermitteln, die anschließend untersucht wird.
Soll eine auf einem kompromittierten Gerät vorliegende bzw. vermutete MAS analysiert wer-den, so kann in einem Rohdatenabbild der Gerätespeicher nach der Ablageposition des Schadcodes gesucht werden – beispielsweise indem in Abgleich mit einem als integer be-kannten Abbild der Originalsoftware alle legitimen Bestandteile ausgeblendet werden. Wird die Malwareanalyse im Rahmen einer IT-forensischen Untersuchung betrieben (siehe Ab-schnitt 6.2) liegt ein solches Abbild der Speicherinhalte des betroffenen Steuergeräts typi-scherweise bereits aus dem Prozessschritt der Datensammlung (Abschnitt 6.2.2) vor.
Grundsätzlich ist beim Auslesen von Speicherbereichen eines Steuergeräts die Eventualität einzubeziehen, dass die Nutzung hierfür ggf. verfügbarer (Diagnose-)Dienste des aktiven Geräts das Risiko birgt, dass sich auf dem Gerät aktive Schadsoftware z.B. mittels Rootkit-Techniken gezielt tarnen/verstecken könnte. Bei gegebenem Verdacht auf MAS-Befall sollte das Sichern der Speicher daher möglichst offline erfolgen, z.B. durch direkte Zugriffe auf die enthaltenen Chips.
Teils kann die zu untersuchende MAS auch aus anderen Quellen bezogen werden, z.B.
wenn die MAS bereits vor (z.B. Eigenerwerb durch den Analysten) oder während einer Infek-tion sichergestellt werden kann (z.B. wenn ein automotives IDS aufgrund eines Anfangsver-dachts den über eine Diagnoseverbindung übertragenen Updatedatensatz gesichert hat).
Statische Analysen an MAS
Liegt eine digitale Repräsentation des Schadcodes vor, kann diese im Rahmen einer stati-schen Analyse untersucht werden. Beispielhafte Möglichkeiten sind:
Stringsuche – z.B. zur Suche nach enthaltenen Zeichenketten, die Hinweise auf die Funktion des Schadcodes liefern
Hex-Editoren – z.B. zum Verschaffen eines ersten Überblicks über die Struktur des Schadcodes oder zum Identifizieren von modifizierten Stellen mittels eines Abgleichs mit entsprechenden Auszügen der Originalsoftware.
Disassembler – u.a. zur detaillierten Analyse der enthaltenen Maschinencodebefehle um Rückschlüsse auf die (Schad-)Programmfunktionalität ziehen zu können. Weitere Er-kenntnisse, die auf Basis der Disassemblierung schnell ermittelt werden können, sind Aussagen zur grundsätzlichen Programmstruktur.
Decompiler – kann wie ein Disassembler zur Analyse der Programmfunktionalität einge-setzt werden. Durch Aufbereitung des (Schad-)Codes in einer Hochsprachen-Darstellung können Lesbarkeit und Codeverständnis durch den Menschen gesteigert werden.
Wesentliche Unterschiede zur Schadsoftware-Analyse in der Desktop-IT sind z.B.:
Heterogene Prozessorarchitekturen: Während ein Großteil der Schadsoftware in der Desktop-IT für die dort vorherrschenden Intel-x86-basierten Prozessorarchitekturen kon-zipiert ist, ist das Spektrum im automotiven Bereich deutlich breiter. Für die tiefergehen-den statischen Analysen ist die Kenntnis über die Prozessorarchitektur und das Vorhan-densein kompatibler Disassembler oder Decompiler jedoch eine wichtige Voraussetzung.
Da MAS laut Definition auf vorhandener automotiver (Original-) Hardware ausgeführt wird, ist jedoch davon auszugehen, dass dem Untersuchenden die verwendete Systemarchi-tektur i.d.R. bekannt ist bzw. von ihm in Erfahrung gebracht werden kann. Während kommerzielle Disassembler auch ein breites Spektrum an Prozessorarchitekturen be-herrschen, kann die Verfügbarkeit kompatibler Decompiler jedoch häufig ein Problem darstellen. Beispielsweise unterstützt die etablierte Analysesoftware IDA [Hexr14] derzeit (Stand: August 2014) über 60 Prozessorfamilien für die Disassemblierung, während der zugehörige Hex-Rays Decompiler bislang nur für x86, x64 und ARM verfügbar ist.
Heterogene Systemumgebungen: Bei automotiven Steuergeräten herrscht zudem eine größere Vielfalt der (sofern vorhanden) eingesetzten Betriebssysteme, während Schad-software im Desktop-IT-Bereich zu einem großen Teil für die Ausführung in Microsofts Windows-Umgebungen konzipiert ist. Bei der statischen Analyse eines automotiven Schadcodes sind daher oft auch strukturelle Kenntnisse der vorhandenen Systemumge-bung erforderlich – beispielsweise um durch den Schadcode getätigten Aufrufen externer Funktionen (z.B. system calls) eine Bedeutung zuordnen zu können.
Dynamische Analysen an MAS
Dynamische Analysen am extrahierten Schadcode sind grundsätzlich ebenfalls möglich. Um dessen Verhalten während seiner Ausführung beobachten und analysieren zu können, ist jedoch das Vorhandensein einer geeigneten Ausführungsumgebung erforderlich.
Soll die dynamische Analyse eines automotiven Schadcodes auf einem PC-System ausge-führt werden, so scheidet der zur Malwareanalyse im Desktop-Bereich etablierte Virtualisierungsansatz jedoch i.d.R. aufgrund unterschiedlicher Prozessorarchitekturen aus.
Eine Alternative stellt eine vollwertige oder teilweise Emulation des Zielsystems dar.
Vollwertige Emulation: Für eine möglichst vollwertige Emulation des Zielsystems müss-te neben dessen Hardware (z.B. Prozessorarchimüss-tektur, Ein- / Ausgabeschnittsmüss-tellen) auch die Softwareumgebung (Betriebssystem) geeignet nachgebildet werden. Entsprechende Lösungen zur Simulation bzw. Emulation von Embedded-Umgebungen, die teilweise be-reits während des Entwicklungsprozesses zum Einsatz kommen, können grundsätzlich auch bzgl. ihrer Nutzbarkeit im Rahmen einer Malwareanalyse überprüft werden.
Teilweise Emulation: Auch der im Kontext der statischen Analysen vorgestellte Disassembler IDA bietet Möglichkeiten zur dynamischen Schadcodeemulation. Über die Nutzung des Prozessor-Emulators QEMU [Qemu14] können aus IDA heraus auch Code-auszüge verschiedener Mikroprozessorarchitekturen über die integrierte Debugging-Funktionalität dynamisch analysiert werden. Dies ist i.d.R. problemlos möglich, wenn der zu untersuchende Code keine externen Abhängigkeiten aufweist – d.h. keine Code- oder Datenbereiche adressiert, die außerhalb des vorliegenden Ausschnittes liegen. Auch im Fall bestehender Abhängigkeiten kann eine Emulation gelingen, wenn diese geeignet auflösbar sind. Grundsätzlich ist hierzu an allen verwendeten externen Adressen adres-sierbarer Speicher mit ggf. dort erwarteten Daten bzw. Programmcode einzurichten. Dies muss teils manuell durch den Untersuchenden erfolgen, während Abhängigkeiten zu gängigen Systemfunktionen durch teils für QEMU verfügbare Systemumgebungen aufge-löst werden können. Die Emulation von Code mit Abhängigkeiten zu unbekannten Funk-tionen und Daten stellt folglich ein grundsätzliches Problem dar.
Alternativ könnte als Ausführungsumgebung auch ein Originalgerät des Infektionsziels die-nen. Indem dieses ähnlich wie ein Bare-Metal-System bei Malwareanalysen im Desktop-IT-Bereich (Abschnitt 2.3.2) als kontrollierte Testumgebung nutzbar gemacht wird, steht hier-durch automatisch eine kompatible Ausführungsumgebung bereit. In dieser kann das Verhal-ten des enthalVerhal-tenen MAS-Schadcodes auf folgende Weisen analysiert werden:
Nutzung von Debug-Schnittstellen: Viele der in Steuergeräten eingesetzten Mikrocon-troller bieten Schnittstellen, die zum In-System-Debugging enthaltener (Schad-) Software geeignet sind. Beispiele sind das im IEEE-Standard 1149.1 beschriebene Verfahren der Joint Test Action Group (JTAG) sowie proprietäre Schnittstellen wie der Background Debug Mode (BDM) von Controllern des Herstellers Freescale. Eine Übersicht und Hin-tergründe zu diesen und weiteren entsprechenden On-Chip-Debug-Systemen verschie-dener Embedded-Mikrocontroller kann beispielsweise [Saue05] entnommen werden.
Überwachung der Geräteschnittstellen (Black-Box-Perspektive): Richtet sich das Schadverhalten des Schadcodes primär gegen Ressourcen außerhalb des infizierten Steuergeräts, kann die abstrakte Funktionsweise ggf. auch aus Black-Box-Perspektive, also ohne Betrachtung der internen Abläufe, nachvollzogen werden. Eine vergleichbare Technik wird im Folgenden auch für die Analyse von Malicious Automotive Hardware (MAH) vorgeschlagen und in Abschnitt 6.3.2 beschrieben.
6.3.2 Analysetechniken für Malicious Automotive Hardware (MAH)
Dieser Abschnitt diskutiert die Durchführung von Schadode-Analysen (siehe Abschnitt 2.1.14) im automotiven Bereich in Bezug auf automotive Malware der Ausprägung MAH.
Dazu werden im Folgenden einige beispielhafte Vorgehensweisen genannt, die beim Ver-dacht des Vorliegens schädlicher Hardware in einem Fahrzeug-IT-Verbund für deren Analy-se infrage kommen.
Separation der MAH: Extraktion der physischen MAH
Auch im Fall von MAH ist die schadhafte Logik, die innerhalb des Zielsystems in diesem Fall in Form von unautorisierter Hardware vorliegt, vor der Analyse zunächst zu identifizieren und (nach Dokumentation der aufgefundenen Situation) entnehmen.
Ein naheliegender Ansatz hierzu ist eine optische Sichtung des Systems. Weniger invasive MAH kann beispielsweise in vielen Fällen an bestehenden Schnittstellen / Steckverbindern vermutet werden, während invasivere Exemplare auch innerhalb bestehender Steuergeräte (-gehäuse) verborgen sein könnten. Das Freilegen (und teils erforderliche Öffnen) entspre-chender Steuergeräte oder Teile des Kabelbaums kann jedoch umfangreichere Arbeiten am betreffenden Fahrzeug erfordern. Um diesen Aufwand zu reduzieren, sollte die optische Sichtung daher möglichst mit Vorwissen kombiniert werden, das z.B. aus dem vorliegenden Vorfallsverdacht ableitbar sein kann. Wurden z.B. symptomatische Fehlfunktionen festge-stellt, könnte zunächst in lokaler Nähe des jeweils „zuständigen“ Steuergeräts gesucht wer-den, bevor wiederum an weiteren (z.B. für Eingaben) relevanten Geräten fortgefahren wird.
Statische Analysen an MAH
Bereits ohne (erneute) Inbetriebnahme des Fundstücks können aus einem physisch vorlie-genden MAH-Exemplar gewisse Schlüsse über dessen Funktionsweise abgeleitet werden.
Einige Erkenntnisse können bereits aus einer Sichtprüfung ableitbar sein. Ist die MAH ihrer-seits von einem physischen Gehäuse umschlossen, kann hierbei noch zwischen einer äuße-ren und einer inneäuße-ren Sichtprüfung unterschieden werden. In der äußeäuße-ren Sichtprüfung wür-den dann z.B. die vorhanwür-denen Schnittstellen zum Gesamtsystem einbezogen werwür-den wie auch ggf. vorhandene Beschriftungen/Aufdrucke des Geräts. Nach Öffnung des MAH-Exem-plars können auch die Art und Anordnung der verbauten elektronischen Komponenten (z.B.
vorhandene Mikroprozessoren, Bustransceiver etc.) weitere Aufschlüsse liefern. Zusätzlich können nach Identifikation der aufgefundenen Komponenten konkrete Informationen zu ih-nen recherchiert werden (z.B. Datenblätter der Hersteller).
Für konkretere Aussagen zur Funktionsweise bestehen weitere statische Analyseoptionen:
Besteht die gefundene MAH ausschließlich aus einer einfachen Schaltung (z.B. Festwi-derstand, ggf. in Kombinationen mit weiteren Halbleitern wie z.B. Dioden), kann deren Funktionsweise bereits in Abgleich mit dem vorhandenen Wissen über die Einsatzumge-bung rekonstruiert werden. Dies wäre z.B. für die in Kapitel 3 als R1.1 behandelten Angrif-fe (z.B. „10-Cent-Tuning“) der Fall.
Bei komplexerer MAH auf Basis eigener Mikrocontroller kann auch die auf dem Gerät gespeicherte Software mit Hilfe statischer Analysemethoden (z.B. Stringsuche, Disas-semblierung etc., vgl. Abschnitt 2.1.14) untersucht werden. Die hierfür erforderliche Ex-traktion und statische Analyse erfolgt dann größtenteils äquivalent zu den in Abschnitt 6.3.1 für MAS behandelten statischen Schritten.
Dynamische Analysen an MAH
Ein vergleichsweise direkter Ansatz zur dynamischen Analyse an MAH ist die beaufsichtigte Inbetriebnahme des sichergestellten Geräts in einer realen (Fahrzeug-IT) oder simulierten Umgebung.
Die Beaufsichtigung kann hierbei das Ein-Ausgabeverhalten des Testobjekts auswerten, wozu dieses in einer simulierten Umgebung mit geeigneten Eingaben zu versorgen ist.
Auch steuergeräteinterne Abläufe können im Rahmen entsprechender Tests ausgewertet werden, z.B. wenn hierzu auf der MAH vorhandene Debugschnittstellen (siehe Abschnitt 6.3.1) genutzt werden können.
Sofern die auf dem Untersuchungsgegenstand vorhandene Software (z.B. im Rahmen der zur statischen Analyse, s.o.) extrahiert werden konnte, könnten dynamische Analysen grundsätzlich auch unabhängig von der originalen Hardware betrieben werden. Dies würde größtenteils äquivalent zu denjenigen in Abschnitt 6.3.1 für MAS diskutierten Ansätzen zur dynamischen Analyse erfolgen, welche ohne Nutzung des Originalgeräts auskommen.
6.3.3 Analysetechniken für Malicious Automotive Peripherals (MAP)
Dieser Abschnitt diskutiert die Durchführung von Malwareanalysen (siehe Abschnitt 2.1.14) im automotiven Bereich in Bezug auf automotive Malware der Ausprägungsform MAP. Dazu werden im Folgenden einige beispielhafte Vorgehensweisen genannt, die beim Verdacht des Vorliegens schädlicher automotiver Eingabequellen für deren Analyse infrage kommen.
Separation der MAP: Beschaffung des zu untersuchenden MAP-Objekts
Bereits seitens der (i.d.R. vorgelagerten) IT-Forensik besteht eine wesentliche Herausforde-rung darin, dass bei Vorfällen mit dieser Malwareausprägung die schadhafte Logik aus-schließlich außerhalb des Fahrzeugs vorliegt (siehe Abschnitt 4.1.1), d.h. das Fahrzeuginne-re lediglich das Ziel, nicht aber die (infizierte) Quelle des Angriffs darstellt. Folglich können von einer Analyse der Fahrzeugkomponenten höchstens Spuren der Angriffsfolgen, jedoch nicht des eigentlichen Schadcodes erwartet werden. Im Rahmen einer Malwareanalyse zu untersuchende MAP-Exemplare müssen daher zunächst aus anderen Quellen beschafft werden, die bei Einleitung der IT-forensischen Aufklärung teils nicht (mehr) zugreifbar sind.
Angriffswerkzeuge der Ausprägung MAP können sowohl in Hardwareform, d.h. als eigen-ständige Geräte, oder als Software, z.B. als Anwendungen für PC-Systeme vorliegen (siehe Abschnitt 4.1.1). Entsprechende Geräte bzw. Computersysteme oder Datenträger können als Untersuchungsgegenstand für die Analyse darauf enthaltener MAP vorliegen, z.B. wenn diese im Rahmen einer laufenden Ermittlung beschlagnahmt wurden oder die „Produk-te“ durch die Analysten selbst über entsprechende Bezugsstellen erworben werden können.
Statische Analysen an MAP
Statische Analysen von als Softwareprodukt vorliegender MAP (die z.B. auf gängigen PC-Systemen oder Smartphones installiert wird), sollten voraussichtlich über die hierfür etablier-ten Malwareanalysetechniken aus Abschnitt 2.1.14 erfolgen können, ohne dass durch den automotiven Kontext grundsätzliche Anpassungen erforderlich werden.
Liegt MAP stattdessen in Form eigenständiger, physischer Geräte vor, können als statische Analysetechniken z.B. äußere und innere Sichtprüfungen erfolgen sowie extrahierbarer Code statisch analysiert werden (Stringsuche, Disassemblierung etc.). Die Vorgehensweisen hier-zu entsprechen in wesentlichen Teilen den in Abschnitt 6.3.2 für MAH diskutierten.
Wesentliche erste Erkenntnisse aus der statischen Analyse von MAP können beispielsweise aus der Identifikation der genutzten Soft- und Hardwareschnittstellen abgeleitet werden, die das Untersuchungsobjekt für die Interaktion mit dem Automobil nutzt (z.B. für PC-Software mitgelieferte OBD-Interfaces). Weitergehende Details können anschließend in detaillierten Untersuchungen des zugrundeliegenden Programmcodes ermittelt werden.
Dynamische Analysen an MAP
Als Alternative zur vergleichsweise aufwendigen Funktionalitätsrekonstruktion am abgeschal-teten Gerät (d.h. der statischen Analyse) können einige dynamische Analysetechniken deut-lich schneller zu aussagekräftigen Ergebnissen führen.
Ein i.d.R. einfach aufzustellendes Testsetup ist die Anwendung des Untersuchungsobjekts auf ein (kompatibles) Testfahrzeug, denn die erforderlichen Schnittstellen zwischen MAP und dem Fahrzeug sind typischerweise klar definiert (teils mitgelieferte Handbücher) und be-grenzt (häufige Nutzung einer einzigen Schnittstelle, z.B. OBD). So lassen sich mit ver-gleichsweise geringem Aufwand Protokolle der Kommunikation über die jeweilige genutzte
Schnittstelle sowie der beobachtbaren Folgen am Testfahrzeug erstellen. Zudem stellt MAP dem Anwender nach dem Start in vielen Fällen (i.d.R. grafische) Bedienschnittstellen bereit.
Die dort vorhandenen Optionsbezeichnungen sind ein weiterer wichtiger Anhaltspunkt über die Funktionalität und können in der Auswertung mit den jeweiligen Protokolldaten in Bezie-hung gesetzt werden.
Um auch interne Abläufe der MAP in die dynamische Analyse einzubeziehen, können bei PC-basierten Softwareprodukten die entsprechenden etablierten Techniken und Werkzeuge eingesetzt werden (vgl. Abschnitt 2.1.14, z.B. Analyse mittels Debugger). Bei gegebenen Voraussetzungen (z.B. Debugschnittstellen) ist dies auch bei physischen Geräten möglich und erfolgt dann grundsätzlich entsprechend des Vorgehens, das in Abschnitt 6.3.2 für die dynamische Analyse an MAH behandelt wurde.
6.3.4 Erkenntnisse aus automotiven Malwareanalysen
Zum Ende jeder Malwareanalyse sollten aus den – über die diversen Analysetechniken – zusammengetragenen Informationen die wichtigsten Erkenntnisse zusammengefasst und bewertet werden. Für das fahrzeugherstellerseitige Sicherheitsmanagement (Abbildung 46) stellen sie wichtige Eingaben für die Analyse und Bewertung der Bedrohungslage sowie ggf.
angeschlossenen Maßnahmen zur Verbesserung des Sicherheitsniveaus dar (vgl. auch Ab-schnitt 6.1.1). Insbesondere sollten die erlangten Erkenntnisse dahingehend geprüft werden, ob Handlungsbedarf für die aktuell betroffenen und/oder zukünftigen Modellreihen besteht.
Ein wesentlicher Teil des Ergebnisses einer Malwareanalyse sind zusammengefasste Er-kenntnisse zu dessen primären, funktionellen Eigenschaften. Hinsichtlich einer (auch für Nicht-Malwareanalysten) verständlichen Darlegungsweise sollte dies auf einer eher abstrak-ten Ebene, d.h. losgelöst von technischen Einzelheiabstrak-ten der einzelnen Analyseschritte erfol-gen. Eine geeignete Möglichkeit hierzu ist, die Grundzüge von auf der untersuchten Malware basierenden Vorfällen anhand der CERT-Taxonomie zu beschreiben (siehe Abschnitt 2.1.8), bei der die automotive Malware als Werkzeug eingeordnet werden kann. Die klare Strukturie-rung der vorliegenden Informationen zu den von ihm ausgenutzten Schwachstellen sowie darüber, welche Aktionen auf welche Ziele mit welchen unautorisierten Resultaten möglich sind, verspricht für das fahrzeugherstellerseitige Sicherheitsmanagement deutliche Vorteile.
Gleiches gilt für begründbare Rückschlüsse auf den zugrundeliegenden Angreifer und die durch ihn verfolgte Motivation.
Neben der Feststellung der primären funktionellen Eigenschaften, die nach Abschnitt 4.1.4 auch als Funktionswirkungen der Malware aufgefasst werden können, sollte auch die Mög-lichkeit weiterer, darüber hinausreichender Konsequenzen abgeschätzt werden. Einer-seits könnten solche in Form der ebenfalls in Abschnitt 4.1.4 vorgestellten Strukturwirkungen vorliegen, die sich – teils unbeabsichtigt – aufgrund der komplexen Wechselwirkungen in automotiven Systemen ergeben können. Aber auch mit vorsätzlich eingebrachten Nebenwir-kungen sollte bei Malware grundsätzlich gerechnet werden, was z.B. im Desktop-IT-Bereich oft zu beobachten ist. Beispielsweise enthalten viele im Kontext von Softwarepiraterie ver-breitete Programme (z.B. sog. „Cracks“ oder „Keygeneratoren“) zusätzliche, versteckte Schadfunktionen bzw. Hintertüren (Backdoors, vgl. z.B. [SkZe03]), die i.d.R. ohne Wissen des Anwenders entsprechender Software mit aktiviert werden. Wie im Praxisreview in Kapitel 3 festgestellt wurde, werden viele Manipulationen automotiver IT durch die Nutzer der Fahr-zeuge selbst initiiert. Von ihnen verwendete WerkFahr-zeuge, die teils als automotive Malware eingeordnet werden können, könnten ebenfalls versteckte weitere Schadfunktionalitäten aufweisen, die durch das fahrzeugherstellerseitige Sicherheitsmanagement ebenfalls mit zu adressieren wären.
Ob Handlungsbedarf vorliegt, kann einerseits anhand einer Abwägung der Kosten einer wirksamen Gegenmaßnahme im Vergleich zu den drohenden monetären Schäden entschie-den werentschie-den. Eine im Bereich der Desktop-IT-Sicherheit verbreitete Bemessungsgrundlage zur Ermittlung der Wirtschaftlichkeit von Securitymaßnahmen ist der sog. Return On Security Investment (ROSI, siehe z.B. [KeKl08]), der sich aus den Kosten der potentiellen Schäden und der Sicherheitsmaßnahmen sowie der darüber erzielbaren Schadensreduktion ermitteln lässt. Hingegen kann im speziellen automotiven Anwendungsgebiet der IT-Sicherheit (vgl.
Abschnitt 2.4.3) ein Handlungsbedarf in besonders kritischen Fällen, in denen konkrete Safe-ty-Risiken für Leib und Leben von Menschen drohen, auch angesichts unwirtschaftlicher Ge-genmaßnahmen gegeben sein sowie auch bereits ausgelieferte Fahrzeuge betreffen.
Bei festgestelltem Handlungsbedarf sollten die identifizierten Schwachstellen geschlossen werden. Hierzu sollten die Ergebnisse der Malwareanalyse je nach Art der Schwachstelle (vgl. CERT-Taxonomie) abschließend in Empfehlungen münden, wie das Design, die Imple-mentierung oder die Konfiguration der betroffenen (Teil-) Systeme anzupassen ist.