Car-IT Car-2-x: Was man von anderen Branchen lernen kann

Mit der Car-2-x-Kommunikation nach außen wird Datensicherheit zu einem drängenden Thema. Ein Blick auf andere Branchen zeigt, wie sich die Risiken im Entwicklungsprozess bewerten und Sicherheitsanforderungen erfüllen lassen.

Anbieter zum Thema

Pfeiffer Vacuum GmbH

IPG Automotive GmbH

»Automobil Industrie« China

Silver Atena Electronic Systems Engineering GmbH

Assystem Germany GmbH

Um die funktionale Sicherheit der Automobilelektronik sicherzustellen, gibt es etablierte Verfahren nach ISO 26262. Es liegt im Aufgabenbereich des OEMs, eine Risikoanalyse vorzunehmen. Risiken müssen identifiziert und bewertet werden. Dabei muss für jede einzelne identifizierte Gefährdung abgeschätzt werden, wie schwer sie sich auswirkt, wie häufig sie auftritt oder wie wahrscheinlich es ist, dass die Fehlfunktion eintritt und ob sie sich in der jeweiligen Fahrsituation beherrschen lässt. Daraufhin erfolgt für jede Gefährdung die Einstufung in eine ASIL-Sicherheitsanforderungsstufe von A bis D. So wird zugleich festgelegt, was der Entwickler einer Komponente tun muss, um der jeweiligen Sicherheitsanforderungsstufe gerecht zu werden. Für Safety sind in der Automobilelektronik somit bewährte Verfahren und Sicherheitsanforderungsstufen definiert.

Sensorik

Autonomes Fahren: Die Sicherheitsfrage

Für das schnell an Bedeutung gewinnende Feld der Security (Sicherheit durch Schutz vor Angriffen) sollten ähnliche Prozesse etabliert werden. So lassen sich beispielsweise die möglichen Folgen einer manipulierten Datenübertragung abschätzen.

Erfolgs- statt Eintrittswahrscheinlichkeit

Deutlich schwieriger aber wird es bei der Bewertung der Eintrittswahrscheinlichkeit. Bei der funktionalen Sicherheit lassen sich die Situationen identifizieren, in denen es zu einem Fehler kommen kann. Somit lässt sich an der Häufigkeit dieser definierten Situationen auch sinnvoll beurteilen, mit welcher Wahrscheinlichkeit es zu Fehlern kommt. Im Gegensatz dazu ist bei Datensicherheitsverletzungen die Ursache tendenziell unabhängig von der Funktion einer Komponente und der Häufigkeit ihres Abrufs im Betrieb.

An die Stelle der Eintrittswahrscheinlichkeit tritt hier die Erfolgswahrscheinlichkeit eines Angriffs. Diese zu bestimmen ist allerdings ungleich schwieriger, weil man vorab nicht wissen kann, welche Methoden der Angreifer entwickelt. IT-Sicherheit lässt sich als ein immerwährender Wettlauf zwischen Angreifern und Verteidigern beschreiben, bei dem beide Seiten ihre Methoden laufend verbessern: Datensicherheit ist ein „bewegliches Ziel“.

Um in einem Szenario die Erfolgswahrscheinlichkeit eines Angriffs zu bestimmen, kann man jedoch die erforderliche Komplexität des Angriffs abschätzen. Muss ein Angreifer beispielsweise gleichzeitig in mehrere Systeme eindringen, ist dies ungleich komplexer, als wenn er nur die Barrieren eines Systems überwinden muss. Ein weiteres Beispiel: Kann der manipulierende Zugriff auf Systeme über eine Funkverbindung erfolgen, oder braucht der Angreifer einen physischen Zugang zum Bordnetz?

Definition von Security Levels

Doch wie lassen sich diese Fragen methodisch und in Normen für die Automobilindustrie in den Griff bekommen? Um diese Frage zu beantworten, lohnt sich ein Blick auf die Methoden, mit denen anderen Branche sicherheitsrelevante Projekte bewältigen – etwa Aerospace oder industrielle Automation.

Auf Basis dieser Erfahrungen lässt sich ein Lösungsansatz für die Automobilindustrie vorschlagen: Die ISO/IEC 62443 „Industrial communication networks – Network and system security“ zeichnet sich durch eine sehr gut abgestufte Abstraktion in der Beschreibung von Sicherheitsanforderungen und Maßnahmen aus. Auch hier wird, vergleichbar mit den in der Automobilbranche bekannten Sicherheitsanforderungsstufen der funktionalen Sicherheit, mit Security Levels gearbeitet.

ISO/IEC 62443 als Vorlage

Ein Netzwerk industrieller Steuerungen unterscheidet sich auf abstrakter Ebene nicht grundsätzlich von einem Netzwerk von Steuerungen in einem Fahrzeug. Daher kann die ISO/IEC 62443 als gute Vorlage dienen, um Security Level für ein System zu definieren und daraus Anforderungen ableiten zu können.

Ein weiterer Vorteil: Diese Security-Anforderungen werden in der Norm abstrakt vorgegeben und beziehen sich nicht auf bestimmte Bussysteme oder Protokolle. Die Definition der Security Level erfolgt nach dem Top-down-Ansatz: Der OEM würde im Idealfall aus dem Level eines Systems das erforderliche Level eines Subsystems ableiten und dies dem Zulieferer mitteilen. Da dies noch nicht gebräuchlich ist, könnte auch ein Entwicklungspartner seinerseits ein Security Level aus der Norm wählen und würde so Lösungen liefern, die eine eigene Definition ihrer Sicherheit bereits mitbringen.

Netzwerke voneinander trennen

Das Zusammenführen und Gruppieren von Steuergeräten im Fahrzeug senkt Kosten und Platzbedarf, verkürzt Kommunikationswege und -latenzen und schafft so Ressourcenpuffer, die anspruchsvollen Anwendungen zur Verfügung gestellt werden können. Doch diese Vernetzung vorher unabhängiger, getrennter Steuerfunktionen im Fahrzeug hat einen nicht unproblematischen Einfluss auf Security-Aspekte.

Engineering

BMW eröffnet dritten Entwicklungsstandort in Peking

Bei Safety wie bei Security verstehen wir Gefährdung als das Produkt aus Eintrittswahrscheinlichkeit und Folgenschwere. Folgen eines Hacks können z. B. Datendiebstahl oder ein Imageschaden sein. Doch weitaus gefährlicher für die Nutzer von Fahrzeugen ist es, wenn ein Angriff die funktionale Sicherheit des Fahrzeugs beeinflussen kann. Ein plakatives Beispiel dafür: Ein Angreifer schafft es, über die Update-Funktion des Infotainmentsystems und das Netzwerk der diversen Steuergeräte auf die Bremsen zuzugreifen. Angesichts der Folgenschwere eines solchen Szenarios muss die Eintrittswahrscheinlichkeit maximal gesenkt werden. So könnte es dafür erforderlich bzw. zielführend sein, die entsprechenden Netze möglichst stark zu trennen.

Safety und Security trennen

Das Gruppieren und die Vernetzung von Steuergeräten dürfen nicht dazu führen, dass unkritische Steuerfunktionen mit kritischen Funktionen zusammengelegt werden. Schwachstellen unkritischer Geräte, die bis dato geringe Bedeutung hatten, bedrohen sonst direkt kritische Funktionen. Auch Safety- und Security-Funktionen sollten getrennt bleiben, denn die einen dürfen nicht verändert werden, wohingegen die anderen mit jeder neuen Cyberbedrohung upgedatet werden müssen.

*Dr. Falk Lindner ist Senior Security Engineer bei Silver Atena Electronic Systems Engineering

(ID:45215292)