Startseite > Automotive > Software + Tools > Intrusion Detection und Prevention in vernetzten Fahrzeugen

Immunsystem fürs Fahrzeug

Intrusion Detection und Prevention in vernetzten Fahrzeugen

11. Oktober 2017, 10:39 Uhr | Von Jan Holle und Marko Wolf

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Kombination verschiedener Erkennungsmechanismen

Bereits anhand der zwei beschriebenen Beispiele wird deutlich, dass erst durch die Kombination von verschiedenen Erkennungsmechanismen ein sinnvolles Fahrzeug-IDPS ermöglicht wird. Aktuelle IDPS-Lösungen nutzen daher ein gutes Dutzend Erkennungsmechanismen und sollten, basierend auf einer kontinuierlichen Analyse aktueller Angriffsvektoren, regelmäßig um neue Module ergänzt werden.

Die Fähigkeiten eines IDPS zur Ano¬malie oder Angriffserkennung geht dabei direkt einher mit der Qualität der eingesetzten Konfiguration. Gerade für CAN haben die Fahrzeughersteller schon aufgrund funktionaler Anforderungen immense Anstrengungen unternommen, um die Kommunikationsvorgänge zwischen den Steuergeräten zu spezifizieren. So sind unter anderem die Identifier der Botschaften, gegebenenfalls ihre Zykluszeit sowie die enthaltenen Signale typischerweise in sogenannten DBC-Dateien dokumentiert; dabei steht DBC für Data Base CAN, ein Dateiformat für CAN-Busdaten. Die Nutzung dieses Wissens erlaubt es, automatisch effiziente und zuverlässige initiale Regeln für die Erkennungsmechanismen zu generieren. Im Rahmen des IDPS-Kalibrierungsprozesses werden anschließend durch Simulationen und automatische Analysen des aufgezeichneten Netzwerkverkehrs, oft mit Unterstützung durch Machine Learning, geeignete Schwellwerte für die initialen Regeln festgelegt und zusätzliche Regeln für Ausnahmefälle definiert. Ziel ist es, hierdurch zum einen eine hohe Erkennungsrate zu gewährleisten und zum anderen möglichst wenige Fehleralarme auszulösen. Dieses Ziel erfordert daher einen umfassenden Konfigurationswerkzeugkasten als inhärenten Teil einer jeden IDPS-Lösung.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Eine ausschließlich lokale Angriffserkennung ohne die Möglichkeit, Gegenmaßnahmen einzuleiten, wird nur für wenige Bedrohungsszenarien sinnvoll sein – so zum Beispiel bei einer Dokumentation von Manipulationen im Bereich von unautorisierten Leistungssteigerungen. Seinen vollen Nutzen erreichen IDPS-Komponenten im Fahrzeug aber im Zuge einer Anbindung an ein IDPS-Back-End, wie ein „Cyber Defense Center“ (Bild 3). Die vollständige IDPS-Lösung besteht somit aus IDPS-Komponenten in den Fahrzeugen, die Anomalien detektieren und entsprechende Benachrichtigungen an das Back End übertragen, einem IDPS-Back-End und einer entsprechenden Lösung zur Verteilung von passenden Gegenmaßnahmen. Gerade die Aggregation von Meldungen angegriffener und nicht angegriffener Fahrzeuge im IDPS-Back-End ermöglicht es, neue Angriffstrends zu erkennen, die Ursachen von Security-Vorfällen im Rahmen von forensischen Untersuchungen zu ermitteln und letztendlich passende Gegenmaßnahmen zu definieren und an die Fahrzeugflotte zu verteilen. Diese neuen Möglichkeiten erweitern die bisherigen statischen, hauptsächlich auf Angriffsverhinderung ausgerichteten Security-Konzepte zu einer kontinuierlichen Security-Strategie für den ganzen Fahrzeuglebenszyklus.

IDPS für Fahrzeuge und Fahrzeugflotten sind ein sinnvoller und logischer Schritt in Richtung eines ganzheitlichen Rundumschutzes, der auch den Zeitraum nach der Fahrzeugproduktion mit einschließt. Wichtig bleibt aber, dass IDPS-Lösungen komplementär zu anderen, teilweise bereits etablierten Sicherheitsmaßnahmen sind. Das bedeutet insbesondere, dass der konsequente Einsatz von sicherer Fahrzeugkommunikation – Secure Onboard Communciation (SecOC) –, wie sie beispielweise im Rahmen von AUTOSAR spezifiziert ist [4], genauso empfehlenswert bleibt wie der Einsatz von Gateways zur Separierung von Fahrzeug- und Sicherheitsdomänen. Es ist zu erwarten, dass die Bedeutung solcher Separierungsmaßnahmen im Rahmen der Einführung von Automotive Ethernet sogar weiter zunehmen und den Einsatz von Firewalls, die den kompletten Ethernet- und IP-Kommunikations-Stack abdecken, erforderlich machen wird. Ein (Over-the-Air) Update der Regelsätze dieser Firewalls stellt hierbei eine weitere sinnvolle Gegenmaßnahme im Rahmen einer vollständigen IDPS-Lösung dar.

Zukünftiger Einsatz von IDPS-Lösungen für Fahrzeuge

Aktuelle, regelbasierte IDPS-Lösungen sind bereit für den Praxiseinsatz und fester Bestandteil der Security-Strategie zahlreicher Fahrzeughersteller. Es ist zu erwarten, dass Fahrzeuge noch vor dem Jahr 2020 in der Lage sein werden, Angriffe zu erkennen und zu melden, um die Anwendung entsprechender Gegenmaßnahmen durch die Fahrzeughersteller zu ermöglichen.

Dennoch steht die Entwicklung von IDPS-Lösungen für Fahrzeuge noch am Anfang; einige der spannenden Trends und Herausforderungen sind bereits abzusehen (Bild 4):

Integration in neue E/E-Architekturen und insbesondere die Entwicklung von geeigneten Erkennungsmechanismen beim zunehmenden Einsatz von Automotive Ethernet Einsatz von Machine Learning zur automatischen und kontinuierlichen Verbesserung der IDPS-Konfiguration sowie gegebenenfalls zur Ablösung von regelbasierten Erkennungsmechanismen im Fahrzeug Anwendung von aktiven Gegenmaßnahmen (Prevention/Reaction) im Fahrzeug Verteilte Anwendung von mehreren, kooperierenden IDPS-Instanzen im Fahrzeug.

Es ist zu erwarten, dass der kontinuierliche Schutz von Fahrzeugen im Sinne der Automotive Security in der Zukunft effektiv nur aufgrund einer breiten Datenbasis bekannter Angriffsmuster möglich sein wird. Der Aufbau dieser Datenbasis beginnt heute, durch die Einführung regelbasierter IDPS-Komponenten im Fahrzeug und die Anbindung an ein IDPS-Back-End. Die Konzepte und Anforderungen für ein solches Back End und „Cyber Defense Center“ sind Thema des letzten Beitrages der aktuellen Themenreihe, der im Sonderheft Software 2017 erscheint.

Referenzen

[1] NHTSA: Part 573 Safety Recall Report – Recall No. 15V-461. 2015-07-23. www-odi.nhtsa.dot.gov/acms/cs/jaxrs/download/doc/UCM483036/RCLRPT-15V461-9407.pdf
[2] Charlie Miller; Chris Valasek: Remote Exploitation of an Unaltered Passenger Vehicle. 2015-08-10. illmatics.com/Remote%20Car%20Hacking.pdf
[3] Charlie Miller; Chris Valasek: CAN Message Injection, OG Dynamite Edition. 2016-06-28. illmatics.com/can%20message%20injection.pdf
[4] AUTOSAR Consortium: Requirements on Module Secure Onboard Communication. www.autosar.org

Die Autoren

Dr.-Ing. Marko Wolf

studierte Elektrotechnik an der Ruhr-Universität Bochum. Er promovierte an der Universität im Bereich Embedded Security. Seit 2008 ist Dr. Wolf bei Escrypt beschäftigt, zunächst als Senior-Security-Ingenieur, dann als Abteilungsleiter für die Niederlassung in München. Im Oktober 2013 wurde er Entwicklungsleiter. Seit Dezember 2014 ist Marko Wolf als Leiter für den Bereich Consulting & Engineering im Unternehmen tätig.

Dipl.-Inf. Jan Holle

studierte angewandte Informatik mit Fachrichtung Elektrotechnik an der Universität Siegen. Er ist seit August 2013 bei der Escrypt GmbH tätig, zunächst als Security-Ingenieur, seit Juli 2016 als Product Manager.