Security im Kontext der Funktionssicherheit

Die Abbildung 5 (siehe PDF) veranschaulicht den Zusammenhang zwischen der ISO 26262 [5] und der allgemeinen Begrifflichkeit / Vorgehensweise nach [3].

Das verbleibende Risiko (in Abbildung 5 als "Risk" bezeichnet) ist somit eine Kombination aus dem initialen Risiko und der Wahrscheinlichkeit des tatsächlichen Auftretens der Gefährdung (im Sinne einer Ausfallrate). Ist dieses verbleibende Risiko auf ein Niveau unterhalb eines (nicht quantifizierten!) zumutbaren Restrisikos zu limitieren, so heißt das, dass je höher das initiale Risiko ist, umso geringer muss die Wahrscheinlichkeit des tatsächlichen Auftretens der Gefährdung sein, z.B. die Ausfallrate des Systems.

Die "Feindbilder", die die ISO 26262 für die Funktionale Sicherheit von Straßenfahrzeugen adressiert, sind systematische Fehler und zufällige Hardware-Fehler. Zur Vermeidung systematischer Fehler stellt sie Anforderungen an den Entwicklungsprozess (Safety Life Cycle), zur Beherrschung zufälliger Hardware-Fehler und verbleibender systematischer Fehler (deren Vermeidung grundsätzlich nicht vollständig sichergestellt werden kann) stellt sie Anforderungen an die technische Umsetzung im Produkt (z.B. Redundanzen, Monitoring, Diagnosen).

Automotive Security aus Safety-Sicht

Verlassen wir nun die Feindbilder der funktionalen Sicherheit, nämlich die systematischen Fehler und zufälligen Hardware-Fehler, und schauen uns ein weiteres Feindbild an: den bewussten Angriff auf das Fahrzeug bzw. seine E/E-Systeme. Zunächst gilt festzustellen, dass wir uns mit diesem Feindbild außerhalb des Anwendungsbereichs der ISO 26262 befinden. Trotzdem kann auch dieses Feindbild zu einem Safety-kritischen Verhalten führen und daher prinzipiell Safety-relevant sein, wie in [1] eindrucksvoll gezeigt wird. Die Frage, die es nun aus Safety-Sicht zu beantworten gilt, ist: Sind für einen gegebenen Angriff risikoreduzierende Maßnahmen notwendig zur Sicherstellung einer ausreichenden Produktsicherheit (i.S.v. Safety)?

Auch hier empfiehlt sich die oben und in [3] dargestellte zweistufige Vorgehensweise:

1. Ermittlung des initialen Risikos ohne Berücksichtigung risikoreduzierender Maßnahmen in einer Gefährdungsanalyse und Risikobewertung. Während jedoch bei der ISO 26262 die Wahrscheinlichkeit der Fahrsituation (Exposure) und das tatsächliche Auftreten der Fehlfunktion ("Ausfall") prinzipiell voneinander unabhängige Ereignisse sind, ist bei der Automotive Security zu berücksichtigen, dass das Auftreten einer Fehlfunktion gezielt in einer bestimmten Fahrsituation provoziert wird, so dass diese Unabhängigkeit nicht vorausgesetzt werden darf. Damit ist eine Übernahme des E-Parameters und damit der ASIL-Einstufung aus der Gefährdungsanalyse und Risikobewertung der ISO 26262 nicht zulässig, es muss eine Neubewertung der Exposure vorgenommen werden. Insbesondere wäre der Ansatz, sich bei der Betrachtung von safetyabsichernden Security-Maßnahmen z.B. nur auf ASIL C oder D Fehlfunktionen zu beschränken, zu kurz gesprungen.
2. Bewertung des verbleibenden Restrisikos und gegebenenfalls Umsetzung von Maßnahmen zur Risikoreduktion.

Im Schritt 1 stellt man sich letztendlich die Frage, wie wahrscheinlich ein Angriff auf das Fahrzeug ist. Ist dieser hochwahrscheinlich, weil zum Bespiel das Angriffsziel sehr attraktiv ist, und ergibt sich hieraus ein initiales Risiko für eine durch den Angriff provozierte Fehlfunktion, das höher liegt als das zumutbare Risiko, so sind zur Sicherstellung der Product Safety risikoreduzierende Maßnahmen notwendig. Hervorzuheben ist, dass die Einschätzung der Angriffswahrscheinlichkeit eine Experteneinschätzung mit sehr hohen Unsicherheiten darstellt, da Parameter wie Angreiferfähigkeiten, Angreifermotivation sowie die das betrachtende System umgebenden Komponenten starken Einfluss auf das Ergebnis haben. Insbesondere kann sich die Einschätzung über die Wahrscheinlichkeit eines Angriffs im Laufe der Zeit stark ändern, z.B. durch Hinzufügen einer bei der ursprünglichen Betrachtung nicht vorhandenen Vernetzungsfunktion oder durch steigende Angreiferfähigkeiten.

Zusammenspiel zwischen Automotive Security und Funktionaler Sicherheit

Maßnahmen zur Sicherstellung der Product Safety müssen das jeweilige Feindbild adressieren, d.h. der bewusste Angriff als Feindbild fällt in den Bereich der Automotive Security, und entsprechende Maßnahmen sind prinzipiell zunächst außerhalb der Funktionalen Sicherheit / ISO 26262 zu suchen. Bei näherer Betrachtung stellt man jedoch fest, dass die beiden Themen nicht so isoliert voneinander zu betrachten sind wie man zunächst annehmen könnte.

Bei der Betrachtung der Vorgehensweisen stellt man fest, dass sie sich sehr ähnlich sehen (Abbildung 6, PDF).

Auf der linken Seite des V-Modells finden ähnliche Aktivitäten statt, jedoch mit unterschiedlicher inhaltlicher Ausprägung. Zu ihrer Durchführung sind unterschiedliche Expertisen notwendig, es ist nicht unbedingt sinnvoll, Security-Aufgaben bei Safety-Experten anzusiedeln. Wichtig ist aber, Synchronisationspunkte einzuführen, bei denen sich die Safety- und Security-Experten miteinander abgleichen, um Widersprüche aufzulösen, um sich konterkarierende Maßnahmen im Produkt zu vermeiden und um mögliche Synergien zu heben.

Da auf der rechten Seite des V-Modells idealerweise gegen Anforderungen getestet wird, sollte hier die Quelle der Anforderung (Safety oder Security) keine (große) Rolle spielen. Erst bei der abschließenden Validation findet wieder eine Auftrennung statt, Safety Validation und Security Validation erfordern deutlich andere Vorgehensweisen und Maßnahmen.

Bei der Definition oder Einführung eines "Security Engineering Process" sollte darauf geachtet werden, dass die Prozesse und Vorgehensweise im Bereich der Funktionalen Sicherheit bereits implementiert sind und sich am aktuellen Stand der Technik orientieren. Vorgehensweisen bzw. Maßnahmen der Security sollten sich hier möglichst nahtlos einfügen und dem Bestehenden nicht widersprechen, um eine effiziente Umsetzung zu ermöglichen.

Auf der technischen Ebene gilt es zunächst zu vermeiden, dass sich Safety- und Security-Konzepte gegenseitig negativ beeinflussen. Dies sei an einem (stark vereinfachten) Beispiel erläutert:

Safety-kritischste Fehlfunktion eines Fahrerairbags stellt die ungewollte Auslösung dar, gemäß ISO 26262 ist diese Fehlfunktion mit der höchsten Einstufung ASIL D versehen. Die Vermeidung dieser Fehlfunktion hat höchste Priorität, insbesondere sollte sichergestellt sein, dass es auch im Falle eines Hackerangriffs – sei es gewollt oder unbeabsichtigt –  nicht zu dieser Fehlfunktion kommt (Safety braucht Security). Andererseits darf aber ein "zu stringenter" Security-Mechanismus nicht dazu führen, dass die Airbagauslösung im Falle eines Unfalls verzögert oder gar verhindert wird, da damit die intendierte Funktion des Airbags, der Schutz der Insassen im Falle eines Unfalls, gemindert wird (Security darf Safety nicht beeinträchtigen).

Neben der Herausforderung, Safety und Security gemeinsam und widerspruchsfrei zu implementieren, gibt es auf der technischen Ebene auch mögliche Synergien. Als Beispiel seien hier die Botschaftsabsicherungsmaßnahmen CRC (Cyclic Redundancy Check) und MAC (Message Authentication Code) genannt (Abbildung 7, PDF). Unter bestimmten Voraussetzungen ist es möglich, die Botschaftsabsicherung durch den CRC durch eine Absicherung durch den MAC zu ersetzen, so dass dieser sowohl der Safety- als auch der Security-Absicherung nützt [7], [8].

Darüber hinaus gibt es noch weitere mögliche Synergien sowohl auf technischer Ebene als auch auf Ebene der Prozesse, die eine enge Zusammenarbeit der Safety- und Security-Experten sinnvoll machen.

Standardisierung

Wie bei der Safety gibt es auch bei der Security keine absolute Sicherheit. Somit kann jede individuelle Lösung im Nachhinein dem Vorwurf ausgesetzt sein, nicht ausreichend sicher zu sein. Ein Schritt in die richtige Richtung wäre eine branchenweite Abstimmung über die Vorgehensweisen zur Erreichung des Mindeststands der Technik. Im Bereich der Safety gibt es hierfür zahlreiche Normen, speziell für die Funktionale Sicherheit von Straßenfahrzeugen beschreibt die im November 2011 veröffentlichte und derzeit in Überarbeitung befindliche ISO 26262, welche Anforderungen an die Entwicklung funktional sicherer E/E-Systeme im Automobil gestellt werden. Spezielle Berücksichtigung finden hier die Spezifika der Automobildomäne, zum Beispiel die Vorgehensweisen bei der verteilten Entwicklung über mehrere Zulieferergrenzen hinweg. Diese Norm stellt damit die gemeinsame Sicht der Automobilindustrie auf die Funktionale Sicherheit dar, die Anwendung ist eine notwendige aber nicht hinreichende Voraussetzung zur Erreichung des Stands der Technik.

Im Bereich der Automotive Security fehlt es momentan noch einem solchen Standard. Als erste Aktivität in dieser Richtung entsteht zwar derzeit eine Guideline (SAE J3061, [9]), diese beschreibt aber in erster Linie mögliche Maßnahmen ("was ist zu tun"), ohne normativen Anspruch und ohne sie in einen entsprechenden Lebenszykluskontext zu setzen ("wann ist wie viel zu tun"). Hier wäre eine der ISO 26262 vergleichbare Norm wünschenswert, die Vorgehensweisen standardisiert, wie bei der Entwicklung von sicheren (im Sinne von "secure") Systemen in Straßenfahrzeugen vorzugehen ist, zum Beispiel wie eine Klassifikation der notwendigen Risikoreduktion durchgeführt werden kann.

Darüber hinaus fokussiert die SAE Guideline zu sehr auf die Safety als durch Security-Maßnahmen zu schützendes Gut und berücksichtigt die anderen "Assets" zu wenig, z.B. Privacy oder Confidentiality. Dies sollte bei einer zukünftigen Standardisierung stärkere Berücksichtigung finden. Eine solche, mit der ISO 26262 vergleichbaren Norm, könnte auch im Bereich der Automotive Security dazu beigetragen werden, eine gemeinsame Sicht der Automobilbranche auf das Thema zu formulieren und damit die Entwicklung von sicheren ("secure") Systemen auch über Zulieferergrenzen hinweg zu verbessern.

Zusammenfassung

Durch die zunehmende Vernetzung von Straßenfahrzeugen und die damit neu entstehenden Zugangsmöglichkeiten von außen gewinnt das Thema Automotive Security immer stärkere Bedeutung. Neben anderen zu schützendes Assets wird die (Functional) Safety zukünftig stärker in den Fokus rücken, da heute schon – wenn momentan auch noch hauptsächlich auf akademischem Niveau – Angriffe demonstriert werden können, die safetykritisches Verhalten auslösen. Aus Sicht der Produktsicherheit sind Security-Maßnahmen dann notwendig, wenn die Wahrscheinlichkeit für einen Angriff zu einem Safety-Risiko führt, so dass das Produkt nicht mehr die erwartbare Sicherheit bietet. Synergien zwischen Functional Safety und Automotive Security sind sowohl auf Prozessebene als auch bei der technischen Umsetzung möglich, so dass eine Abstimmung zwischen den beiden Disziplinen notwendig und sinnvoll erscheint. Eine der ISO 26262 vergleichbare Norm zur Automotive Security kann das gemeinsame Verständnis in der Automobilbranche fördern und dazu beitragen, sichere (im Sinne von "secure") Systeme auch über Zulieferergrenzen hinweg zu entwickeln. Einerseits ist es nicht sinnvoll, das Thema Automotive Security innerhalb der ISO 26262 zu standardisieren, andererseits muss aber darauf geachtet werden, dass eine solche Norm nicht zur ISO 26262 im Widerspruch steht, da ansonsten eine effiziente Implementierung in den Unternehmen nicht möglich sein wird.

Referenzen

[1] "Hacker remotely crashes Jeep", The Telegraph (abgerufen am 03.08.2015)

[2] Gesetz über die Bereitstellung von Produkten auf dem Markt (Produktsicherheitsgesetz – ProdSG), 08.11.11

[3]  ISO/IEC Guide 51:2014: "Safety aspects – Guidelines for their inclusion in standards"

[4]  IEC 61508:2010: "Functional safety of electrical/electronic/programmable electronic safety-related systems"

[5]  ISO 26262:2011: "Road vehicles – Functional safety"

[6]  M. Klauda, S. Kriso: "Sicherheit als Treiber der zukünftigen Systementwicklung", ESE Management Summit 2014, Würzburg, 10.07.2014

[7]  B. Glas et al.: "Automotive Safety and Security Integration Challenges", In: Automotive - Safety & Security 2015, Lecture Notes in Informatics, Volume P-240, 2015, ISBN 978-3-88579-634-3.

[8]  B. Glas, C. Gebauer: "Safety & Security: Synergies and Challenges of Integrity-protected Bus Communication" (to be published)

[9]  "SAE committee busy developing standards to confront the cybersecurity threat",  SAE, (abgerufen am 11.08.2015)