Evaluierung des signaturbasierten Prototyps und Ergebnisse

Im Rahmen praktischer Versuche in der im vorigen Abschnitt vorgestellten Testumgebung wurde anhand der entwickelten Signaturen einerseits die Korrektheit ihrer Funktionsweise sowie andererseits die erzielbare Performanz bei ihrer Anwendung / Verarbeitung untersucht.

Ergebnisse aus der Evaluierung der Angriffssignaturen

Unter anderem wurde die Funktionalität der in Abschnitt 5.2.3 vorgestellten Signatur zur Er-kennung von Angriffen auf die in den Labortests identifizierte Gateway-Schwachstelle (L4.x in Abschnitt 3.2.5) verifiziert. Hierzu wurde mittels des verwendeten Prototyping-Systems die CAN-Bus Kommunikation während entsprechender Angriffe beaufsichtigt. Im folgenden Bei-spiel wird vom Diagnose-CAN aus (welcher an der vom Innenraum aus frei zugänglichen OBD-Schnittstelle anliegt) ein entsprechender Angriff durchgeführt, um interne CAN-Nach-richten mit der ID 0x320 aus dem Subnetz der Instrumentierung auszulesen. Diese Angriffs-ereignisse wurden durch das IDS jeweils korrekt und in Echtzeit erkannt. Abbildung 42 zeigt einen beispielhaften Logeintrag zu diesem Angriffsszenario. Zeile 1 dokumentiert den Ein-gang der zuvor am OBD-Interface eingespielten CAN-Nachricht im internen, vom IDS über-wachten Instrumentierungsnetzwerk (Angabe von ID, Kanal, Zeitstempel, DLC und Nutzda-ten). Zeile 2 zeigt die anschließend generierte Angriffsmeldung mit Angabe des meldenden Netzes und der geschalteten Transition sowie Zeile 3 Informationen über das auslösende Token (das meldende Signaturnetz verwendet keine Variablenbindungen).

[SIG] processing CAN Message 1605; id:200 chan:0 time:6.793697 data[07]:07 c0 00 10 20 03 01 [SIG] Alert: sniffing from instrumentation network; triggered by t1

[SIG] alerted token: tok_id = 0; no variables set

Abbildung 42: Meldung im Ergebnislog des IDS-Moduls zu einem Angriff auf die Gateway-ECU Die Verifikation der Signatur zur Erkennung von Message-Injection-Angriffen auf periodische CAN-Nachrichten wurde am Beispiel des als L_3.1 vorgestellten Angriffs auf die Airbag-Warnleuchte des Kombiinstruments (Abschnitt 3.2.4) durchgeführt. Bei der Einrichtung der für dieses Überwachungsziel in Abschnitt 5.2.3 vorgestellten Erkennungssignatur wurde für den verwendeten Schwellenwert thr in einigen einleitenden Vortests experimentell ein geeig-neter Wert ermittelt. Um False Negatives, d.h. fälschlicherweise unerkannte Angriffe zu ver-meiden, sollte dieser grundsätzlich so niedrig wie möglich gewählt werden – gleichzeitig je-doch groß genug, dass im Normalbetrieb keine False Positives, d.h. fälschlicherweise ausge-löste Alarmierungen zu beobachten sind.

Bei Aktivierung des Angriffs aus L_3.1 liefern die Praxistests des prototypischen automotiven IDS als Ergebnis, dass auch das vorgestellte Signaturnetz zur Überwachung periodisch auf-tretender CAN-Nachrichten geeignet ist, irreguläre Anstiege in deren Häufigkeit zuverlässig zu detektieren. Auch die Funktionsfähigkeit der weiteren, in dieser Arbeit nicht ausführlich vorgestellten Signaturen (vgl. Abschnitt 5.2.3 unten) konnte erfolgreich verifiziert werden.

Die in den aufgestellten Signaturen gesetzten Schwellenwerte sind grundsätzlich nicht von der Plattform abhängig, auf der das IDS betrieben wird (hier die MicroAutoBox), sondern plattformübergreifend nutzbar. Dies konnte in ergänzenden Untersuchungen bestätigt wer-den, in denen die Tests ohne Nutzung der MicroAutoBox im o.g. Emulationsbetrieb des IDS-Frameworks auf einem PC-System durchgeführt wurden. Dazu wurden Nachrichtenlogs aus den Realversuchen als Eingabe bereitgestellt, die erzeugte Ergebnis-Logdatei ausgewertet und mit den Ergebnissen aus dem Realbetrieb verglichen, die jeweils übereinstimmten.

Zusammenfassend kann die Funktionsfähigkeit der aufgestellten Erkennungssignaturen im Rahmen der durchgeführten Evaluierung erfolgreich aufgezeigt werden.

Obwohl in den Tests auf Basis des letztendlich verwendeten Signaturdatensatzes sämtliche getesteten Angriffsversuche detektiert werden und keine Fehlalarme zu beobachten sind, fehlt für eine begründbare Bezifferung der erzielbaren Erkennungsleistung (u.a. FPR, FNR) jedoch noch ein wesentlicher Teil der hierzu erforderlichen Grundlage:

 Einerseits ist die Zahl der derzeit umgesetzten Erkennungssignaturen zu bekannten automotiven Angriffen noch äußerst gering, weshalb z.B. auch nur durch eine sehr gerin-ge Zahl von Signaturen überhaupt Fehlalarme produziert werden könnten.

 Andererseits liefert der verwendete, unvollständige Steuergeräteverbund kein vollständi-ges bzw. repräsentatives Bild über das normale Kommunikationsverhalten entsprechen-der Fahrzeuge. Problematische Konstellationen in entsprechen-der regulären Fahrzeugkommunikation, die z.B. Fehlalarme auslösen könnten, kommen daher während der Tests ggf. zu keinem Zeitpunkt zustande.

Selbst bei Verfügbarkeit von Komplettfahrzeugen für die detaillierte Evaluation eines automo-tiven IDS müssten Aspekte wie unterschiedliche Fahrzeugausstattungen sowie Systemzu-stände bzw. Nutzungsszenarien (z.B. reguläre Diagnosesitzungen) einbezogen und syste-matisch eine große Zahl verschieden parametrisierter Angriffsszenarien simuliert werden, um zu begründbaren Aussagen über dessen Erkennungsleistung bzw. Fehlerraten zu kommen.

Ergebnisse der Performance-Untersuchungen

Zur Verarbeitung von Eingaben stehen im Fall vieler automotiver Steuergeräte bzw. Anwen-dungen nur begrenzte Ressourcen wie insbesondere Zeit zur Verfügung. Auch auf der Mic-roAutoBox können nur begrenzt viele eingehende Busnachrichten vorgehalten werden, bis die Verarbeitung der vorangegangenen abgeschlossen ist. Geschieht dies zu langsam, kann es auftreten, dass eingehende Nachrichten verworfen, d.h. nicht verarbeitet werden können.

Anhand des für diese Problematik entwickelten Signaturnetzes wurde die Umsetzung auf dem Prototyping-System MicroAutoBox hinsichtlich ihrer Belastungsgrenzen untersucht. Da-zu wird ein Da-zuvor aufgezeichneter Mitschnitt der Buskommunikation aus dem Instrumentie-rungsnetzwerk (insgesamt 87.122 Nachrichten) mittels der Software CANoe (PC-System in Abbildung 40) wiederholt über CAN-Kanal 1 in die MicroAutoBox eingespielt. Durch einen IDS-internen Zähler wird jeweils die Anzahl der verarbeiteten Nachrichten ermittelt, die an-schließend mit der Zahl der gesendeten Nachrichten (87.122) verglichen werden kann. Unter schrittweiser Erhöhung des im Belastungsnetz verwendeten Schwellenwertes kann so ermit-telt werden, wie viele Token vom Netz gespeichert und verarbeitet werden können, ehe bei einer zum Beispiellog vergleichbaren Nachrichtendichte einzelne Ereignisse übersprungen werden. Abbildung 43 zeigt das Ergebnis einer entsprechend durchgeführten Messung.

Abbildung 43: Ergebnis der Belastungsgrenzenermittlung

Wie Abbildung 43 zeigt, ist der Prototyp unter Verwendung des vorgestellten Belastungsnet-zes bei einer Anzahl von ca. 1400 aktiven Token noch in der Lage, alle eingehenden CAN-Nachrichten zu verarbeiten. Anschließend bricht dieser Wert zunehmend ein, d.h. je mehr Token darüber hinaus gespeichert und verarbeitet werden, ein desto größerer Teil der ein-gehenden CAN-Nachrichten muss verworfen werden. Bei einer Zahl von 2700 aktiven Token konnte über die Hälfte aller gesendeten Nachrichten nicht verarbeitet werden.

Dieses Ergebnis unterstreicht nochmals, dass insbesondere bei der Definition von Angriffs-signaturen für die automotive Anwendung Augenmerk auf eine kompakte Definition und ins-besondere eine möglichst geringe Anzahl gleichzeitig genutzter Token gelegt werden sollte.

Im Rahmen der durchgeführten Tests konnte jedoch auch bei gleichzeitiger Nutzung aller erstellten Angriffssignaturen nicht beobachtet werden, dass Nachrichten aus der verwende-ten Buskommunikation (aus Logdateien sowie den Versuchsverbünden) verworfen wurden – d.h. die Verarbeitung erfolgte auch auf der MicroAutoBox trotz beschränkter Ressourcen zeitnah.

Zusätzlich wurde der benötigte Speicherplatz von Signaturen und zur Laufzeit erzeugten Token überschlagen und mit den Restriktionen der Prototyping-Hardware sowie potentieller Seriengeräte verglichen. Beispielsweise beansprucht das Belastungsnetz bei einer Anzahl

von 4000 Token ca. 94 KB Hauptspeicher. Auch bei einer weiteren untersuchten, vielfach komplexeren Signatur könnten in 4MB Hauptspeicher (z.B. auf der MicroAutoBox) noch bis zu 170.000 Token vorgehalten werden, die jedoch nicht mehr zeitnah abgearbeitet werden können. In diesem Fall stellt die Speicherbeanspruchung im Vergleich zur Abarbeitungszeit daher nur einen untergeordneten Faktor dar.

Die untersuchten Faktoren Verarbeitungszeit und Speicherplatz könnten jedoch bei einem potentiellen Einsatz auf nochmals ressourcenärmeren Seriengeräten relevant werden. Infra-ge käme hier z.B. ein zentrales Gateway-SteuerInfra-gerät, auf dem ein IDS-Modul anInfra-gesichts der Vielzahl angebundener Teilnetzwerke prinzipiell gut mit untergebracht werden könnte. Auf einem typischen Gateway-Steuergerät (wie z.B. im hier verwendeten Systemverbund aus 2007) stehen häufig lediglich ein Prozessor mit 20-30 MHz und ca. 512 KB Arbeitsspeicher zur Verfügung. Da insbesondere die Rechenleistung für die Nutzung des umgesetzten Proto-typs voraussichtlich nicht ausreichen würde, müssten die Ressourcen eines entsprechenden Gerätes für die Aufnahme einer zentralen IDS-Komponente entsprechend erweitert werden.