IDPS: KONTINUIERLICHER SCHUTZ FÜR FAHRZEUG UND FLOTTE

Netzwerk- und Host-basiertes IDS

Je nachdem, auf welchen Ebenen im Fahrzeug die Angriffserkennung erfolgen soll, wird dafür auf Netzwerk- oder Host-basierte Intrusion-Detection-Systeme (Network IDS, Host-based IDS) zurückgegriffen, die sich unterschiedlicher Technologie-spezifischer IDS-Sensoren bedienen. Netzwerk-IDS verfügen über ein breiteres „Blickfeld“, im besten Fall sogar über alle Fahrzeugnetze hinweg. Entsprechend lassen sich ihre Sensoren flexibel anordnen, beispielsweise auf den vermeintlich am besten gegen Zugriffe geschützten Fahrzeugsteuergeräten (ECU). Allerdings erkennen sie – außer bei Angriffen über offene Schnittstellen – die Cyberattacke oder Manipulation erst, wenn die angegriffene ECU bereits kompromittiert ist. Host-basierten IDS dagegen werden typischerweise ECU-spezifisch implementiert und verfügen demnach nur über ein auf die einzelne ECU begrenztes „Blickfeld“. Ihr Vorteil jedoch: Sie erkennen den Angriff auf die ECU bereits in dem Moment, in dem er erfolgt.

Host-basierte und Netzwerk-IDS schließen sich nicht aus, sondern können zielführend miteinander kombiniert werden. Entscheidendes Kriterium bei der Wahl der IDS-Sensoren sollte immer sein, dass diese Technologie-spezifisch auf die E/E-Architektur des Fahrzeugs hin optimiert sind, z.B. was den Grad ihrer Einbettung, ihren Ressourcenbedarf sowie Qualitäts- und Prozesserfordernisse fahrzeuginterner Netzwerke angeht. Zudem sollten die eingesetzten IDS-Sensoren speziell auf die Automotive-Kommunikationsstandards hin entwickelt worden sein.

Verteiltes IDS als Nervensystem des Fahrzeugs

Die verteilten IDS-Sensoren fungieren in Bezug auf etwaige Cyberangriffe, unerlaubte Zugriffe und Manipulationen wie „Synapsen im Nervensystem des Fahrzeugs“. Sie loggen mögliche Security Events (SEv), beispielsweise Anomalitäten im Netzwerkverkehr oder maliziöse Diagnoseanforderungen, weiter an den IDS-Manager (IdsM), von wo aus die konsolidierten Logfiles (Qualifizierte Security Events, QSEv) an den IDS-Reporter (IdsR) zwecks Upstream ans Backend übergeben werden. Wichtig dabei: In all diesen drei Instanzen des Intrusion Detection System muss das Regelwerk konsistent abgebildet sein; nur dann sind optimale Implementierung, Erkennungsgenauigkeit und Wirksamkeit des vernetzten Systems gewährleistet.



Bild 1: Bestandteile und Architektur eines verteilten Intrusion-Detection-Systems (IDS) im Fahrzeug.

Gleichzeitig gilt es, so früh wie möglich die Datenmenge zu reduzieren. Aufgrund begrenzter Bandbreiten und Ressourcen für den Datentransfer und im Backend ist es sinnvoll, bereits im Fahrzeug über smarte IDS-Sensoren und IDS-Manager falsch-positive Security Events, nicht relevante Events bzw. Rauschen herauszufiltern. Dabei muss jedoch im Sinne einer effektiven Ende-zu-Ende-Security dem Verlust relevanter Informationen vorgebeugt sein; die Optimierung der Datenmenge darf nicht zu Lasten der Erkennung gehen.

V-SOC: Kommandostand fürs flottenweite Monitoring

So unverzichtbar die Angriffserkennung im einzelnen Fahrzeug, so wichtig ist die Zusammenführung und Verarbeitung der Event-Daten für die vernetzten Fahrzeugflotte im Vehicle Security Operations Center (V-SOC) im Backend. Mit seinem maßgeblichen Ziel eines proaktiven Security-Monitorings wird das V-SOC quasi zum Kommandostand eines Regelkreises aus Monitoring, Detection, Analysis, Response und Prevention. Das V-SOC setzt dabei auf das Zusammenwirken von drei Komponenten:

Ein V-SOC ist dabei auf die speziellen Anwendungsfälle im Automotive-Bereich zugeschnitten, denn die potenziellen Bedrohungen und Daten, die der Analyse zugeführt werden, unterscheiden sich zum Teil von denen der klassischen IT. Da sind zum einen die IDS-Logfiles aus den Fahrzeugen, aber auch Flotten- und Fahrzeugdaten, die bei den OEMs und Flottenbetreibern verfügbar sind, zum Beispiel aus Telematiksystemen. Zudem können Daten aus den zum Fahrzeug-Backend gehörenden IT-Systemen mit in die Analyse miteinbezogen werden, insbesondere dort, wo Fahrzeugfunktionen (z.B. per Smartphone-App) über solche Backend-Systeme kontrolliert werden. Entsprechend müssen all diese Automotive-spezifischen Daten gemäß V-SOC-eigenen Aggregationsregeln und eigener Datenlogik aufbereitet werden (Bild 2).



Bild 2: Von der Angriffserkennung zum Vehicle Security Operations (V-SOC).

Zusätzlich sind im V-SOC Analysten gefragt, die spezielles Automotive-Domänen-Wissen mitbringen und z.B. fachgerecht beurteilen können, ob eine Meldung oder eine Anomalie tatsächlich auf einem mutwilligen Eingriff basiert oder eine tolerierbare Falschmeldung ist. Der Schlüssel für ein erfolgreiches V-SOC liegt in der Zusammenarbeit von Security- und Domänen-Experten – auch um das Domänenwissen nach und nach in die Optimierung der Plattform und der Abläufe einzubringen.

Response per Update und SUMS

Weiterer wesentlicher Baustein des kontinuierlichen Risikomanagements ist die Response. Software-Updates sind ein probates Mittel, um Sicherheitslücken und erkannte Schwachstellen zu schließen und den „Prevention Status“, den hinreichenden Schutz des Fahrzeugs, wiederherzustellen. Die zunehmende Vernetzung der Fahrzeuge über Luftschnittstellen eröffnet die Möglichkeit, konventionelle Updates in der Werkstatt durch Over-The-Air(OTA)-Systeme zu ergänzen oder gar zu ersetzen. Die Update Frequenz kann auf diese Weise beliebig verkürzt, die Kosten reduziert werden.

Dabei muss es sich mitnichten immer um Security-relevante Updates handeln; Updates befähigen OEMs und Flottenbetreiber generell, die Funktionen ihrer Fahrzeuge zu verbessern und zu erweitern. Allerdings bleibt die Cybersicherheit der Updates selbst ein maßgeblicher Aspekt, der entsprechend beachtet und in naher Zukunft gemäß der Forderung der UN-Regulierungen 155 und 156 qua „Security-by-Design“ systematisch umgesetzt werden muss.

Es bedarf daher künftig eines Software-Update-Managementsystems (SUMS), welches die Aufbereitung und Verteilung von Software-Updates für die Flotte entlang festgeschriebener Prozesse organisiert. Gemäß UN R156 adressiert ein solches SUMS unter anderem die Weitergabe von Informationen an OEMs oder Zulassungsbehörden, die Identifikation typgenehmigungsrelevanter Softwareanpassungen, die Nachverfolgbarkeit von Änderungen, mögliche Interdependenzen aktualisierter Systeme, die Integrität und Authentizität der Software-Updates, die Funktionssicherheit des Fahrzeuges oder auch den Umgang mit fehlgeschlagenen Updates.



Bild 3: Software-Update-Managementsystem (SUMS) – Sicheres Ausrollen und Installation von Software-Update-Paketen.

Wichtigstes „Security Goal“ (Cybersicherheitsziel) für das Update-Management ist es, die Integrität und Authentizität der Updates sicherzustellen. Es gilt unbedingt zu verhindern, dass Update-Mechanismen missbraucht werden, um Steuergeräte oder andere Instanzen im fahrzeuginternen Netzwerk anzugreifen, zu manipulieren oder zu deaktivieren. Ein Firmware-Over-The-Air(FOTA)-Update muss daher im Rahmen eines integrierte Software-Update-Managements festen Authoring-Security-Prozessen sowie einem Backend- und In-Vehicle-Security-Konzept folgen.

www.escrypt.com