Hand in Hand für sichere Fahrzeugsysteme

Wachsende Komplexität und zunehmende Software-Anteile innovativer Fahrzeugsysteme auch im safety-relevanten Bereich sind lang anhaltende Trends in der Automobilindustrie. Aktuell immer stärker im Fokus steht auch die wachsende Konnektivität der Systeme auch über Fahrzeuggrenzen hinweg ins Internet, zu anderen Fahrzeugen, Smartphones und ins Internet der Dinge. Diese Trends erweitern die Angriffsfläche für Hacking und Manipulation und erhöhen gleichzeitig die potenziellen Konsequenzen eines erfolgreichen Angriffs, speziell bei skalierenden Angriffen über drahtlose Schnittstellen. Entsprechende Security- und Privacy-Risiken im Automobilbereich sind inzwischen über verschiedene Medien umfangreich publiziert und bekannt. Auch die Gefahr, dass ein erfolgreicher Angriff und somit die Verletzung von Security-Zielen direkten Einfluss auf Safety-Funktionen haben kann, ist inzwischen breit diskutiert und anerkannt. Der sich damit ergebende Zusammenhang zwischen Safety und Security, ja die Notwendigkeit von Security für Safety-Systeme, erfordert das Zusammenspiel der Disziplinen über den gesamten Produktlebenszyklus, speziell auch schon im Entwurf und in der Entwicklung.

Etas

Security-Entwicklungsprozess analog zu ISO 26262?

Während der Bereich der funktionalen Sicherheit (Safety) im Automobilbereich eine ausgereifte, erprobte und standardisierte Disziplin darstellt, war der Bereich der Embedded-IT-Sicherheit (Security) im Automobilbereich lange auf kleine Teildomänen beschränkt, beispielsweise auf die Wegfahrsperre oder den Tuningschutz, sodass er in der inzwischen nötigen Breite somit relativ neu ist. Die entsprechenden Entwicklungsprozesse beider Disziplinen weisen große Ähnlichkeiten auf und lassen sich somit nebeneinander und miteinander durchführen – allerdings mit der jeweils spezifischen Expertise. Dementsprechend gibt es Bestrebungen, einen Security-Entwicklungsprozess analog dem etablierten Safety-Entwicklungsprozess (niedergelegt in der ISO 26262) zu definieren. Bei genauerer Betrachtung zeigen sich jedoch auch einige prinzipielle Unterschiede, Gegensätze und potenzielle Konflikte zwischen den Disziplinen, die auf dem Weg zu aus Safety- und Security-Sicht sicheren Systemen zu bewältigen sind und einer vollständigen Verschmelzung entgegenstehen. Dieser Beitrag beleuchtet dieses Spannungsfeld im Folgenden anhand einiger Beispiele.

Bild 1: Entwurfsaktivitäten für Safety und Security entlang dem V-Modell. Etas

Bei abstrakter Betrachtung sind beide Domänen sehr ähnlich, denn bei beiden Domänen soll eine qualitative Eigenschaft des Systems sichergestellt werden, wozu eine Betrachtung des gesamten Lebenszyklus‘ erforderlich ist. Safety strebt dabei im Wesentlichen die Sicherheit der Umgebung vor dem System an und soll sicherstellen, dass von dem System keine Gefährdung ausgeht, auch wenn im System selbst Fehler auftauchen sollten – systematische oder transiente – oder es durch externe Faktoren wie etwa besondere elektromagnetische Einstrahlung in Mitleidenschaft gezogen wird. Security hingegen betrachtet spezielle Eigenschaften des Systems – etwa Integrität oder Vertraulichkeit definierter Teilbereiche – und schützt diese Eigenschaften auch gegen gezielte, willentliche, intelligente Beeinflussung, also gegen direkte Angriffe. In diesem Beitrag liegt der Fokus auf dem Teilbereich der Security-Betrachtung, der als zu schützendes Asset die Safety des Systems selbst betrachtet und damit in erster Linie das bestimmungsgemäße, situationsgerechte Verhalten des Systems auch in Gegenwart eines Angreifers. Dabei sollte nicht außer Betracht gelassen werden, dass andere Teilbereiche wie der Schutz personenbezogener Daten oder Diebstahlschutz ebenfalls wichtige Anforderungen an das Security-Konzept stellen.

Spannungsfeld Risikobetrachtung und -bewertung

In beiden Disziplinen steht am Anfang des Entwicklungsprozesses eine Risikobetrachtung des Systems basierend auf der grundlegenden Risikodefinition als Kombination aus Eintrittswahrscheinlichkeit und Schadenshöhe. Einige Ansätze schlagen daher vor, die Security-Betrachtung auf Basis der Safety-Analyse aufzusetzen. Hier ergeben sich jedoch Konflikte durch die unterschiedlichen zugrundeliegenden Annahmen. Das Risikomodell der Safety betrachtet in der „Hazard Analysis and Risk Assessment“ (HARA) neben systematischen Designfehlern im Wesentlichen zufällige Hardware-Fehler natürlichen Ursprungs. Die Einführung eines intelligenten Angreifers in der „Threat and Risk Analysis“ (TRA) der Security ändert die Risikosituation jedoch fundamental und macht die beiden Ansätze grundlegend inkompatibel.

Bild 2: Vergleich der Risikomodelle und Einflussfaktoren von Safety und Security. Etas

HARA klassifiziert Risiken in „Automotive Safety Integrity Level“ (ASIL) basierend auf drei Parametern: Der potenziellen Schadenschwere (severity S), der Wahrscheinlichkeit einer Betriebssituation, in der der Effekt eintreten könnte (exposure E) und der Kontrollierbarkeit des Effekts durch die Verkehrsteilnehmer (controllability C). Externe Safety-Maßnahmen können entsprechend die Parameter beeinflussen und damit den ASIL verringern.

TRA betrachtet ebenfalls die möglichen Auswirkungen eines erfolgreichen Angriffs (consequence) und die Wahrscheinlichkeit des Eintretens (likelihood). Allerdings sind die Parameter für die Wahrscheinlichkeitsschätzung sehr unterschiedlich und basieren auf der Motivation eines potenziellen Angreifers, dem nötigen Angriffspotenzial (Ressourcen, Expertise, Zeit, Zugriff auf das System) und den eventuell vorhandenen Schutzmaßnahmen.

Die Klassifikationsparameter der Safety (S, E, C) sind unter Betrachtung eines gezielten Angriffs nur noch bedingt verwendbar: beispielsweise bei Fehlfunktionen mit potenziell schweren oder tödlichen Verletzungen (S2 oder S3), die aber aufgrund geringer Wahrscheinlichkeit (E1) und hoher Kontrollierbarkeit (C1) in einen niedrigen ASIL klassifiziert werden. Durch einen intelligenten Angreifer sind die Parameter nicht mehr stochastisch unabhängig. Ein Angreifer kann einen Angriff gezielt in einer kritischen Situation auslösen, wie zum Beispiel automatisch durch Überwachung von Fahrzeugparametern, und damit den Parameter E auf die binäre Aussage reduzieren, ob die Situation überhaupt eintritt. Die niedrige Wahrscheinlichkeit für die Situation ist dann nur noch am Rande relevant. Zusätzlich lässt sich die Kontrolierbarkeit durch den Angreifer beeinflussen: entweder durch parallele Angriffe auf mehrere Fahrzeugsysteme oder durch zusätzliche gleichzeitige Ablenkung des Fahrers, etwa durch plötzliche Erhöhung der Musiklautstärke, Öffnen der Fenster, Sichtreduktion durch Scheibenwaschflüssigkeit oder ähnliche, ansonsten eher harmlose Angriffe auf Fahrzeugsysteme. Auch kann ein Angriff auf Safety-Systeme direkt erfolgen, beispielsweise auf Überwachungs- und Fallback-Systeme, die dann ihre Aufgabe im Safety-Modell nicht mehr erwartungsgemäß erfüllen können.

Bild 3: Risikomodell für Safety und Security. Ein Angreifer kann durch gezielte Manipulation nicht nur eine weitere Fehlerursache darstellen, sondern auch an anderen Stellen Einfluss nehmen, zum Beispiel direkt auf Safety-Systeme. Etas

Die ASIL-Klassifikation eignet sich somit nicht als Ausgangspunkt für die TRA, da die probabilistischen Annahmen nicht mehr zutreffen. Alle Parameter und Situationen müssen unter Security-Gesichtspunkten neu betrachtet und bewertet werden. Doch auch wenn oder gerade weil sich die Methoden nicht einfach nahtlos integrieren lassen, ist eine enge Abstimmung und Zusammenarbeit der jeweiligen Experten für die Realisierung sicherer Systeme notwendig. Bei Etas und der Security-Tochter Escrypt arbeiten Experten aus beiden Gebieten bereits seit geraumer Zeit eng zusammen, sodass Erfahrungen in die entsprechende Prozessgestaltung und Empfehlungen an Kunden zurückfließen können. Gerade auch in Kundenprojekten zeigt sich, dass die enge Zusammenarbeit einen Schlüsselfaktor für die Sicherheit des Systems darstellt.

Security altert

Ein weiterer Aspekt ist die zeitliche Komponente über den Lebenszyklus eines Systems. Natürlich können sowohl bei HARA als auch bei TRA grundsätzlich Aspekte übersehen werden. Aber davon abgesehen ist die Safety-Einschätzung eines konkreten Systems idealerweise konstant über die Zeit. Security jedoch altert, da sich die Fähigkeiten der Angreifer über die Zeit ändern: Neue Schwachstellen und Angriffe werden bekannt, komplizierte Angriffe werden automatisiert und damit einfacher (etwa als Tool im Internet für Angreifer verfügbar), kryptographische Komponenten können mit fortschreitender technischer Entwicklung leichter und schneller gebrochen werden. Nicht alle dieser Entwicklungen sind zum Zeitpunkt der Entwicklung vorhersehbar. Daher ist für Security die Begleitung eines Systems über den gesamten Lebenszyklus noch wichtiger als für Safety. Speziell bei langen Lebenszeiten von Systemen muss die Security auch auf spätere Veränderungen, Anpassungen und Updates ausgerichtet sein. Dies erfordert neben dem Monitoring der Entwicklungen und eventueller Angriffe Systemeigenschaften wie Kryptoagilität und Techniken wie Software-Updates über drahtlose Kanäle, um Systeme auf dem neuesten Stand zu halten.

Welcher Gebrauch ist zu erwarten?

Beide Disziplinen haben gemein, dass eine vollständige Sicherheit unerreichbar ist. Es ist also immer die Frage zu beantworten, welcher Rest-Risikolevel akzeptabel ist und welche Annahmen an die Umgebung gemacht werden können, auch bezüglich des Gebrauchs (oder Missbrauchs) eines Systems. Im (langjährig entwickelten) Safety-Bereich gibt es hierzu gesetzliche Vorgaben, etwa in der entsprechenden EU-Direktive [2001/95/EG, Artikel 2], oder im deutschen Produktsicherheitsgesetz. Letzteres fordert unter anderem, dass Produkte bei „beabsichtigter und vorhersehbarer Verwendung“ sicher (im Sinne der Safety) sein müssen. Im Zusammenhang mit Security stellt sich hier die Frage nach gezielter Manipulation und Sabotage. Wann ist eine Verwendung kein „Gebrauch“ mehr, sondern ein „Missbrauch“, und welche Arten von Angriffen sind von welcher Seite zu erwarten? Und wie ist die Wahrscheinlichkeit einzuschätzen, dass trotz bestehender Security-Maßnahmen eine gezielte Manipulation die Funktionssicherheit gefährdet? Speziell diese Einschätzung ist großer zeitlicher Veränderung unterworfen und muss durch Feldbeobachtung ständig überprüft werden.

Spannungsfeld Lösungsraum

Das System soll auch unter widrigen Bedingungen und in Anwesenheit eines Angreifers seine bestimmungsgemäße Funktionalität stets sicher und zuverlässig erfüllen. Die Integrität des Systems und seiner Funktion in allen Situationen ist oft ein gemeinsames Ziel von Safety und Security. Trotz eines gemeinsamen abstrakten Ziels kann die Betrachtungsweise von Safety und Security ja grundsätzlich unterschiedlich sein und zu jeweils eigenen Ergebnissen führen. Dies setzt sich auch fort, wenn es um die Auswahl und Umsetzung von Maßnahmen geht. Hier zeigt es sich, dass bewährte Ansätze zur funktionalen Absicherung zumindest überprüft und angepasst werden müssen, wenn zusätzlich auch die Security im Fokus steht. Ein Beispiel sind Systeme zur Fehlererkennung und -behebung wie Diagnose- und Debugging-Schnittstellen. Während sie wertvolle Informationen und Möglichkeiten zur Verbesserung und Reparatur von Systemen liefern, bieten sie im selben Maße auch Angriffspotenzial bei Missbrauch, sodass sie entsprechend mit einem Zugriffsschutz versehen werden müssen, was den bestimmungsgemäßen Gebrauch gleichzeitig zumindest erschwert. Schwieriger wird es bei internen Testverfahren zur Laufzeit, beispielsweise bei Speichertests durch Einbringen von Testpattern oder beim Auslesen von Flash-Inhalten zur Integritätsüberprüfung. Hier kommen Verfahren zum Einsatz, die aus Security-Sicht als Angriffsinstrumente oder zumindest als Indikatoren interpretiert werden und somit unterbunden beziehungsweise von einem Intrusion-Detection-System erkannt und gegebenenfalls sanktioniert werden. Das Auslesen von Speicherinhalt muss zum Schutz von geistigem Eigentum oder vor Reverse-Engineering verhindert werden, RAM- und Hardwaretests erfordern exklusiven Zugriff durch die Testfunktion, was für Security- und Überwachungskomponenten nicht akzeptabel ist oder mit Anforderungen kollidiert, die etwa die Unveränderbarkeit von Security-Log-Daten fordern. Um den bestimmungsgemäßen Einsatz von Test- und Safety-Mechanismen von Angriffen unterscheiden und Missbrauch verhindern zu können, sind eine enge Zusammenarbeit sowie ein Co-Design zwischen Safety und Security nötig. Außerdem ist es erforderlich, etablierte Verfahren aus dem Safety-Bereich aus Security-Sicht zu überprüfen und bei Bedarf anzupassen. Umgekehrtes gilt natürlich ebenfalls, ist aber aufgrund der längeren Historie der funktionalen Sicherheit im Automobilbereich seltener zu erwarten.

Synergien von Safety und Security

Neben den Spannungsfeldern gibt es aber auch Synergiepotenzial. Hierzu gehören beispielsweise der Einsatz von Virtualisierung und die Isolation von Teilsystemen zur Trennung verschieden kritischer Bereiche. Auch der Einsatz von Programmierregeln (Coding Rules), die sowohl Safety- als auch Security-Ziele unterstützen können, gehört dazu. So ergab ein Vergleich von MISRA-C-Regeln für Safety mit einschlägigen Secure-Coding-Richtlinien eine Überlappung von etwa 30 Prozent bei gleichzeitig praktisch keinen Widersprüchen.

Ein weiteres Beispiel ist der Integritätsschutz von Daten im Speicher sowie bei der Kommunikation. Aus Security-Sicht ist hier zusätzlich die Authentizität der Daten zu schützen. Vergleiche der jeweils üblichen Verfahren zeigen, dass der Einsatz von kryptographischen Security-Mechanismen wie etwa von Message Authentication Codes (MAC) an Stelle von Cyclic Redundancy Checks (CRC) die Safety-Anforderungen weitgehend überdecken kann, wenn auch mit etwas veränderter Erkennungswahrscheinlichkeit über die verschiedenen Fehlerklassen.

(av)