Cybersecurity: Anforderungen an Intrusion-Detection-Systeme im Auto

Security ist ein wichtiger Wegbereiter für die sichere Vernetzung von Fahrzeugen. Zunehmend etablieren sich beispielsweise signierte Software-Updates, sichere OnBoard-Kommunikation und Secure Boot. Aktuell rücken ­Intrusion-Detection-Systeme (IDS) als ein weiterer Security-Mechanismus in den Fokus der Aufmerksamkeit. Obwohl IDS ein lang bekannter Security-Mechanismus klassischer IT-Systeme ist, sind sie im Automobil noch nicht fest etabliert.

Fehlende Standardisierung

Bild 1: Der Security-Standard ISO 21434 fordert einen Incident-Response-Prozess für Security-Schwachstellen. Vector Informatik

Ein Grund dafür ist deren mangelnde technische Standardisierung. Es gibt keinerlei Standards für die Spezifikation von Security-Events (SEvs), deren Verarbeitung und Reporting im Fahrzeug, ihre effiziente Speicherung und auch keine definierte Onboard-Infrastruktur für das Realisieren von IDS. Außerdem lassen sich die Entwicklungsprozesse von IDS-Anbietern häufig nur schwer in existierende Systementwicklungsprozesse bei Fahrzeugherstellern und -zulieferern integrieren. Es sind zum Teil Eingriffe in die Steuergerätesoftware notwendig, die bereits abgeschlossene Safety-Prozesse torpedieren oder nicht zu der heutigen Aufgabenteilung zwischen Fahrzeughersteller und -zulieferer passen. Einige IDS-Ansätze verlangen den Einsatz proprietärer Hardwarekomponenten, die die Kosten für IDS explodieren lassen.

Gleichzeitig entsteht aktuell der Standard ISO 21434 (Road vehicles – Cybersecurity Engineering). Dieser fordert unter anderem einen definierten Incident-Response-Prozess (Bild 1). Darin ist festgelegt, dass ein Fahrzeughersteller auf Security-Schwachstellen (Vulnerabilities) reagieren muss, die in seinen Fahrzeugen aufgetreten sind. Das kann er aber nur, wenn er diese Schwachstellen auch kennt. Dazu können Automotive-IDS beitragen. Diese bestehen aus einem Onboard-IDS in den Fahrzeugen und einem Backend.

Onboard-IDS erkennen potentielle Security-Events im Fahrzeug und unterstützen deren schnelle Weitergabe an ein Security Operation Center (SOC) beim Fahrzeughersteller. Die dort arbeitenden Security-Experten plausibilisieren die vom Onboard-IDS gelieferten Daten und integrieren sie mit den Daten von weiteren gleichartigen Fahrzeugen. Damit erhalten sie die Grundlage für eine tiefgehende Analyse der Ereignisse und entscheiden die weiteren Schritte. Auf Basis der Erkenntnisse werden beispielsweise Gegenmaßnahmen implementiert und getestet, die die erkannten Bedrohungen ausschalten. Durch Software-Updates lassen sich die Gegenmaßnahmen auf den Fahrzeugen der betroffenen Flotte installieren. Dadurch verbessert sich der Schutz vor ähnlichen Angriffen in der Zukunft.

Anforderungen an Automotive-IDS

Für Automotive-IDS gelten eine Reihe spezifischer Herausforderungen. Zum einen stellt die E/E-Architektur von Fahrzeugen ein verteiltes System dar. Viele bekannte Fahrzeugfunktionen sind erst durch das Zusammenspiel von zwei oder mehr Steuergeräten realisierbar. Diese Eigenschaft hat Auswirkungen auf eine mögliche Onboard-IDS-Architektur. Da kein zentraler Knoten Wissen über alle Security-Events auf anderen Knoten hat, muss das IDS selbst ein verteiltes System sein.

Ein weiterer Punkt, der für ein verteiltes Onboard-IDS spricht, ist die Vermeidung eines Single Point of Failure. In der Steuergerätesoftware sind Erkennungsalgorithmen implementiert – so genannte Sensoren. Diese erkennen beispielsweise durch Hacker-Angriffe provozierte Protokollverletzungen. Falls die Security-Sensoren auf einem Steuergerät ausfallen, soll der Rest des IDS noch möglichst einschränkungsfrei funktionieren. Deshalb müssen die Schnittstellen zwischen den verteilten Elementen des IDS eindeutig definiert sein.

Eine weitere Herausforderung für ein Automotive-IDS sind die heterogenen Software- und Hardwareplattformen. Die Einführung der AUTOSAR-Adaptive-Plattform hat auch die Vielfalt der Softwarelösungen erhöht. Aus Sicht eines Fahrzeugherstellers sollten allerdings die Schnittstellen und die Security-Event-Definitionen möglichst konsistent sein, um das Gesamtsystemdesign nicht unnötig komplex zu machen.

Bild 3: High-Level-Architektur eines Onboard-IDS mit einer beispielhaften Verteilung der Module auf Steuergeräte Vector Informatik

Zusätzlich sind in den Steuergeräten die Ressourcen Rechenleistung und Speicherkapazität äußerst knapp bemessen. Die Entwickler müssen dies gerade beim Verarbeiten der Security-Events im RAM als auch bei deren Speicherung im Nichtflüchtigen-Speicher (NVRAM) berücksichtigen. Hier sind Optimierungen notwendig, die in klassischen IT-Systemen so nicht anfallen. Daher nutzen die Automotive-IDS einen Vorverarbeitungsschritt, um die gemeldeten Security-Events zu sammeln und zu qualifizieren – so lange, bis festgelegte Kriterien erfüllt sind. Die Qualifikation verhindert das Verschwenden von Ressourcen für irrelevante Security-Events. Das gilt besonders für den Fall, wenn Security-Events aus dem Fahrzeugnetzwerk über eine Sendestelle, den Intrusion Detection Reporter (IdsR), an ein Backend weitergeleitet werden. Daher ist eine wichtige Randbedingung, eine unnötige Belastung des Netzwerks zu vermeiden. Natürlich muss dabei berücksichtigt werden, dass die Qualifizierungen typischerweise unter Echtzeitbedingungen erfolgen.

Letztendlich unterliegt das IDS selbst einer Reihe von Security-Anforderungen. Beispielsweise müssen die einzelnen Elemente des verteilten IDS einander vertrauen können. Dies gilt zum einen für die qualifizierten Security-Events (QSEv), deren Übertragung im Fahrzeugnetzwerk an den IdsR erfolgt. Der IdsR muss überprüfen, ob das empfangene QSEv von einem authentischen Sender kommt und unverändert empfangen wurde. Falls ein Angreifer QSEv aufzeichnet und wiederholt abspielt (Replay Attack), muss der IdsR dies erkennen. Auch das SOC auf dem Backend muss den Daten vertrauen, die es von den angeschlossenen Fahrzeugen empfangen hat. Dies wird erreicht, indem der IdsR die Daten vor dem Versenden mit einem fahrzeugspezifischen Schlüssel signiert.

Außerdem sind sowohl die vom IDS im NVM dauerhaft gespeicherten QSEvs als auch IDS-Konfiguration mit den Regeln für die Qualifizierung von Security-Events schützenswert.

Standardisierung der Intrusion Detection in Autosar

Bild 4: Integration des IdsM in die Autosar-Classic-Architektur Vector Informatik

Ein erster Schritt in Richtung Standardisierung wurde schon 2018 mit der Definition von Security-Events in Autosar 4.4 vollzogen. Diese sind seitdem als Spezifikationselement in den Autosar-Dokumenten verfügbar. Dadurch wurde die Grundlage dafür geschaffen, dass für jedes Autosar-Basissoftwaremodul die von ihm gemeldeten Security-Events im Standard definiert sind. Zudem wurde das Basissoftwaremodul Diagnostic Event Manager (Dem) um spezielle Security-Anforderungen erweitert. Neben dem Standard-Diagnosespeicher ist ein Security Event Memory (Sem, Bild 2) konfigurierbar. Es ermöglicht das Speichern von Security-Events in einem getrennten und besonders abgesicherten Bereich. Für das Verwalten der Security-Events kommt weiterhin die existierende Werkzeug- und Prozesskette zum Einsatz.

In der kommenden Autosar-Version 20/11 wird die Standardisierung der Security-Mechanismen im Rahmen des Konzepts für den Intrusion Detection System Manager (IdsM) weiterentwickelt und detailliert. Der Fokus liegt dabei auf den folgenden Aspekten:

• Standardisierung einer High-Level-Architektur für verteilte Onboard-IDS
• Standardisierung eines Interface für das Melden von Security-Events der Basissoftwaremodule und Applikationssoftwarekomponenten an den IdsM
• Standardisierung von Qualifizierungsfiltern. Diese überführen die von den Sensoren gemeldeten Security-Events in qualifizierte Security-Events.
• Standardisierung der Kommunikation zwischen den Modulen IdsM und IdsR
• Standardisierung konkreter Security-Event-Typen für ausgewählte Basissoftwaremodule

Integration des IdsM-Moduls in Autosar

Das Prinzip des IdsM lässt sich am besten anhand seiner High-Level-Architektur vorstellen (Bild 3). Jeder Knoten der E/E-Architektur kann einen eigenen lokalen IdsM beinhalten. Es können also sowohl Autosar-Classic- als auch Autosar-Adaptive-Steuergeräte einen IdsM enthalten. Zwischen den einzelnen IdsM besteht keinerlei hierarchische Abhängigkeit. Jeder lokale IdsM empfängt die Security-Events seiner lokalen Security-Sensoren. Diese sind entweder hostbasierte oder netzwerkbasierte Sensoren.

Ein Beispiel für einen hostbasierten Sensor ist das für Schlüsselmaterial zuständige Modul Key Manager (KeyM). Im Sinne eines Security-Sensors erzeugt das KeyM Module ein Security-Event, wenn jemand ein Root-Zertifikat installiert, dessen Gültigkeit abgelaufen oder dessen Signatur nicht valide ist. Ein Netzwerk-basierter Sensor auf einem Gateway-Steuergerät überprüft beispielsweise, ob CAN-IDs empfangen wurden, die das Ziel-Netzwerk laut Kommunikationsdefinition nicht erreichen sollen.

Relevante Security-Events leitet der lokale IdsM an den IdsR weiter. Der IdsR überträgt die Security-Events an das Security Operation Center. Welche Knoten der E/E-Architektur über einen IdsM verfügen ist eine Entscheidung, die der Fahrzeughersteller im Laufe des Security-Engineering-Prozesses trifft.

Zum besseren Verständnis lohnt sich ein Blick auf die Integration des IdsM in die Autosar-Classic-Architektur (Bild 4). Die blauen Pfeile zeigen Verbindungen von beispielhaften Modulen mit Security-Sensoren zum IdsM. Nach der Qualifikation der Security-Events im IdsM werden je nach Konfiguration die QSEv dauerhaft im Steuergerät gespeichert oder via IdsR an das SOC gesendet. Das Speichern erfolgt im Security Event Memory (orange Pfeile). Für das Ablegen der Daten verwendet das Sem-Modul den Non Volatile RAM Manager (Nvm). Optional kann der Nvm die Daten verschlüsseln (grüne Pfeile) und so ablegen, dass der IdsM Manipulationen erkennt. Zusätzlich zur lokalen Speicherung lassen sich QSEv über den PduR an den IdsR schicken (braune Pfeile).

Auf Basis dieser Grundarchitektur lassen sich Onboard-IDS entwickeln, mit denen eine angemessene Balance zwischen der Verfügbarkeit von Ressourcen und den benötigen Security-Event-Daten erreicht wird. Dazu muss das IDS ein hohes Maß an Konfigurierbarkeit bieten, beispielsweise durch Anpassen der folgenden Aspekte für jedes Security-Event: Qualifizierungsregeln, lokale, dauerhafte Speicherung der QSEv – ja oder nein – und Weiterleitung der QSEv an den IdsR – ja oder nein.

Ausblick

Auf Basis der genannten Anforderungen hat Vector einen Designvorschlag für ein verteiltes Automotive-Onboard-IDS zur Standardisierung in Autosar erstellt. Dieser Designvorschlag adressiert die dargestellten Randbedingungen und funktionalen Anforderungen. Parallel zur Standardisierung in Autosar entwickelt Vector eine standardkonforme IDS-Lösung als Teil seiner Autosar-Basissoftware Microsar. Diese Implementierung wird schon vor dem Release des Standards Autosar 20/11 verfügbar sein.

Die Standardisierung von Automotive-Onboard-IDS bietet einen großen Mehrwert für Automotive-Security. Dadurch ergibt sich die Chance auf ein nachhaltiges und robustes Ökosystem für Automotive-IDS, in das Hersteller, Zulieferer und Security-Experten ihre spezifischen Stärken einbringen: Die Fahrzeughersteller definieren Ihre Security-Anforderungen. Basissoftware-Hersteller bringen ihre Expertise ein, um die technische Infrastruktur rund um IdsM, IdsR und Security-Sensoren in den Basissoftware-Modulen effizient zu implementieren. Und die Security-Experten beteiligen sich mit Ihren Kompetenzen zum Definieren von fortschrittlichen Security-Sensoren, die beispielsweise auf Künstlicher Intelligenz (KI) basieren, als auch mit innovativen Qualifizierungsregeln für Security-Events. Diese Zusammenarbeit wird durch das im Rahmen der Standardisierung definierte Austauschformat Security Extract (SecXT) vereinfacht. Das SecXT erleichtert den Datenaustausch zwischen Entwicklungswerkzeugen und vereinfacht das firmenübergreifende Umsetzten von Security-Prozessen. So wird die Aufgabenteilung zwischen Fahrzeugherstellern und Zulieferern beim Thema Security auf eine neue Ebene gehoben.

(na)