ANGRIFFSERKENNUNG ALS VERTEILTES SYSTEM

So ist zu klären, welche Safety-kritischen und betriebswichtigen Systeme zu sichern sind und welcher Schutzbedarf für Netzwerke und Connectivity Units besteht. Wie angreifbar diese sind, hängt von ihrer Konnektivität über drahtlose oder hardwarebasierte Schnittstellen ab. Verfügbare Ressourcen für die IDS-Implementierung indes bemessen sich nicht nur in RAM, ROM und CPU-Load der jeweiligen E/E-Architektur oder etwaigen Einschränkungen des Datenverkehrs. Hier braucht es auch Fachleute mit spezifischem automotive Domänen-Knowhow; denn über hochwertige Konfiguration und regelmäßige Aktualisierung lässt sich die Menge an False-Positives verringern. Im Fahrzeugbetrieb sichern dann Updates der Engines, anlassbezogene Updates und regelmäßige Konfigurations-Updates ein hohes Schutzniveau, da Learnings aus dem Feld umgehend in die Optimierung der Anomalie-Erkennung des dIDS einfließen.

Host- und netzwerkbasierte IDS-Sensoren
Erste maßgebliche Instanz im verteiltenIntrusion-Detection-System sind die IDS-Sensoren im Fahrzeug. Sie überwachen die Fahrzeugsteuergeräte und Netzwerkkommunikation und erfassen alle Security Events (SEv), die auf Cyberattacken oder unerlaubte Zugriffe hindeuten. Diese Arbeit teilen sich Host-based IDS (HIDS)-Sensoren und Network IDS (NIDS)-Sensoren. HIDS-Sensoren sind auf einzelnen ECUs verortet und auf die Überwachung ihres „Hosts“ spezialisiert; ihr Fokus ist jedoch aufs einzelne Gerät beschränkt: Anders die NIDS-Sensoren: Sie überwachen den Datenverkehr für bestimmte Netzwerksegmente sowie Netzwerk-, Transport- und Anwendungsprotokolle auf verdächtige Aktivitäten hin. Angriffe und Manipulation erkennen sie allerdings meist erst, wenn die Systeme schon kompromittiert sind.

Im verteilten IDS (dIDS) setzen sich die Security-Informationen der spezialisierten HIDS und der breiter angelegten NIDS zum Security-Lagebild zusammen, das auch die heterogenen Kommunikationsstandards und Systeme im Fahrzeug einbezieht. Welche IDS-Sensoren an welcher Stelle zum Einsatz kommen, folgt dabei den spezifischen Security-Anforderungen: Im AUTOSAR-Stack definierte Sensoren genügen oft nur den Mindeststandards, Während „smarte Sensoren“ komplexe Sachverhalte prüfen und selbständig Security Events vorfiltern können.



Verteiltes System zur Angriffserkennung im Fahrzeug– vom (smarten) IDS-Sensor über den IDS-Manager zum IDS-Reporter.

Regelbasierter Ansatz
Die IDS-Sensoren registrieren Abweichungen vom Normalbetrieb als Security Events (SEv). Beispielsweise erkennt ein netzwerkbasierter Sensor eine nicht definierte CAN-ID oder eine nicht definierte Ethernet-MAC-Adresse als potenzielles IT-Sicherheitsereignis, während ein hostbasierter unzulässige Authentifizierungsversuche für eine Diagnose-Session an „seiner“ ECU registriert. Selbst wenn der Zugriff nicht gelingt, können die geloggten Security Events für die spätere Forensik und Bewertung der Gefahrenlage durchaus relevant sein.

Weil Fahrzeugen zwar komplexe, aber noch immer weitgehend statische Systeme darstellen, ist eine regelbasierte Angriffserkennung praktikabel. Die festen Vorgaben des OEM in Bezug auf Komponenten, Funktionalitäten, Ressourcenverbräuche, Protokolle und Traffic im Fahrzeug lassen sich mit einem regelbasierten Ansatz gut abbilden. Voraussetzung ist, dass die Spezifikationen dafür vollständig und fehlerfrei vorliegen und für erweiterte Regeln zusätzlich Signalinhalte oder physikalische Gesetzmäßigkeiten in die IDS-Implementierung mit einbezogen werden. In dem Fall lässt sich das regelbasierte IDS während der Entwicklung sogar zum Testen der Spezifikation einsetzen.

IDS-Manager: Security Events qualifizieren, Datenmenge reduzieren
Zielführende Aggregation, Qualifizierung und Auswertung der Security Events übernehmen anschließend die IDS-Manager (IdsM). Als softwarebasierter Schaltstellen innerhalb des verteilten IDS sammeln sie die erkannten SEv, filtern irrelevante Logs heraus und leiten nur qualifizierte Security Events (QSEv) an den IDS-Reporter (IdsR) des Fahrzeugs weiter, der diese wiederum der weiteren Analyse im Backend zuführt. Dort, im Vehicle Security Operations Center (V-SOC) laufen schließlich alle QSEv der Gesamtflotte zusammen.



Filter- und Verarbeitungsprozess von Security Events im IDS-Manager. (© AUTOSAR)

Die Spezifikationen der IDS-Manager, z.B. ihr zentrales Datenformat für die SEv oder auch die Einstellung ihrer Filterfunktionen, setzen jenen Rahmen für die Angriffserkennung, der über die gesamte Lieferkette des OEMs hinweg Berücksichtigung finden muss. Daher sind grundlegende IdsM-Spezifikationen seit dem Release R20-11 in AUTOSAR Classic und Adaptive integriert. Der im AUTOSAR-Stack festgeschriebene Standard umfasst jedoch nur den kleinsten gemeinsamen Nenner. Abhängig von der Reporting-Strategie und den verfügbaren Rechenleistungen innerhalb der E/E-Architektur kann und sollte der Funktionsumfang um eine komplexere SEv-Aggregation und tiefergreifende Filterfunktionen erweitert werden. Weil auch die IdsR-Spezifikation in AUTOSAR bisher fehlen, benötigen OEMs über die AUTOSAR-Spezifikationen hinaus ein Gesamtkonzept für das verteilte IDS im Fahrzeug.

Fazit: Das verteilte Intrusion-Detection-System im Fahrzeug wird künftig zum Eckpfeiler eines dauerhaft wirksamen Cyberschutzes, der sich über ein angeschlossenes V-SOC und Software-Update-Management-System (SUMS) über ganze Flotte hinweg skalieren lässt.

www.escrypt.com