Herausforderung Security und Safety

Wechselwirkung zwischen Safety und Security

Funktionale Sicherheit (Safety) und Car-Security sind beide "First-Class" Probleme, d.h. beide sehen sich von der Wichtigkeit an erster Stelle. Die Funktionale Sicherheit soll vor Gefahren für Leib und Leben schützen, während die Car-Security den Schutz des Fahrzeugs und eben auch der sicherheitskritischen Systeme vor Angreifern sicherstellt. Kommt es dabei zu widersprechenden Anforderungen, ist es nicht möglich, einseitig entweder der Security oder der Safety Vorrang einzuräumen. So ist Kryptographie für sicherheitsrelevante Systeme mit harten Echtzeitanforderungen derzeit noch eine Herausforderung, da die bekannten starken kryptographische Algorithmen einen nicht unbeträchtlichen Mehraufwand an Speicherplatz, Bandbreite und Rechenkapazität benötigen. Auch wenn die Forschung auf dem Gebiet im laufenden Gange ist (siehe z.B. [6]), ist derzeit noch ein Spagat zwischen Safety, Security und nicht zuletzt Kosten nötig. Dazu kommt, dass die Erfahrungen mit dem Internet zeigen, dass die Anforderungen an die Kryptographie steigen - und damit der Bedarf an Rechenkapazität in den Steuergeräten. Für ein Auto, das zehn bis fünfzehn Jahre im Gebrauch ist, bedeutet das unter Umständen, dass die Hardware nach ein paar Jahren nicht mehr in der Lage ist, die geforderte Security unter Beibehaltung der notwendigen Echtzeitanforderungen sicherzustellen.

Im Folgenden werden drei verschiedene Arten, wie Safety und Security wechselwirken können, vorgestellt.

Einfluss der Safety auf die Security

Zunächst kann ein Fehler die Security beeinträchtigen. Bei einer elektronischen Wegfahrsperre (ESCL – Electronic Steering Column Lock) beispielsweise kann ein Fehler dazu führen, dass die Wegfahrsperre öffnet. Zwar ist die ESCL selbst ein sicherheitsrelevantes System, da ein fehlerhaftes Schließen während der Fahrt gefährlich ist, aber der Fall des fehlerhaften Öffnens, der die Security beeinträchtigt, würde von einer Gefahren- und Risikoanalyse (HARA – Hazard Analysis an Risk Assessment) nach ISO 26262 nicht als Gefahrensituation identifiziert, da das Fahrzeug in diesem Szenario nicht fährt und es damit nicht zu Schaden kommen kann. Andere Folgen von zufälligen Hardware- oder systematischen Hardware- oder Software-Fehlern können Sicherheitslücken in der Software oder ein Aushebeln der Kryptographie sein. Ein Beispiel für ein Szenario könnte ein Zufallsgenerator sein, der aufgrund eines Stuck-at-Fehlers konstante Werte zurückgibt. Eine andere Möglichkeit wäre der Ausfall einer Firewall im Systembus des Autos. Das könnte zur Folge haben, dass Security-Mechanismen Safety-Anforderungen haben, z.B. diversitär ausgelegt werden müssten, was einem Angreifer wiederum zwei potentielle Angriffswege eröffnet.

Einfluss der Security auf die Safety

Auf der anderen Seite kann ein Angriff auf die Safety beeinträchtigen. Im offensichtlichen Fall eines direkten Angriffs auf z.B. Fahrerassistenzsysteme kann ein Angreifer die Kontrolle über sicherheitsrelevanter Systeme erlangen. In diesem Fall kann der ASIL zumindest einen Anhaltspunkt bei der Bewertung der Kritikalität bieten.

Ein Sonderfall liegt vor, wenn die sicherheitskritischen Systeme gar nicht Ziel des Angriffs sind, aber die Absicherungsmechanismen eines sicherheitskritischen Systems (z.B. als Seiteneffekt eines Angriffs) ausfallen. In solchen Fällen arbeiten Security- und Safety-Maßnahmen nicht richtig zusammen, möglicherweise sogar gegeneinander.

Ein Fehlschluss ist übrigens die Annahme, dass die Sicherheitsmechanismen zur Erkennung von Fehlern Angriffe ausreichend erkennen und behandeln können, indem das System in den sicheren Zustand gebracht wird. Wenn das Ziel des Angriffs nicht sowieso der sichere Zustand (d.h. Abschaltung) ist, dann muss davon ausgegangen werden, dass die Sicherheitsmechanismen ebenso von dem Angriff betroffen sind. In der Safety werden beim Design von Sicherheitsmaßnahmen verschiedene vereinfachende Annahmen gemacht. Zufällige Hardware-Fehler werden grundsätzlich als statistisch erfassbar angenommen. Insgesamt ist die Sicherheitsarchitektur in der ISO 26262 auf der Annahme von einem Einzelfehler und einem latenten Fehler aufgebaut. Solche Grundannahmen sind in der Security aber nicht mehr haltbar. Ein intelligenter Angreifer ist also möglicherweise in der Lage, ein System so anzugreifen, das die Sicherheitsmechanismen den Angriff nicht erkennen.

ISO 26262 und Security

Obwohl es also die Notwendigkeit gibt, Safety und Security gleichermaßen zu berücksichtigen, und beide Disziplinen wechselwirken, kommt die Security in der ISO 26262 nicht vor. Als Norm aus der funktionalen Sicherheit beschäftigt sie sich ausschließlich mit Safety-Anforderungen. Zusätzliche Anforderungen aus externer Quelle sind während der Software-Entwicklung ab dem Design der Software-Architektur vorgesehen.  Dies ist in der Regel zu spät, wenn bedingt durch widersprechende Anforderungen zusätzliche Anforderungen auf Systemebene entstehen oder das komplette Design überarbeitet werden muss. Deshalb müssen Anforderungen der Safety und Security bereits ab der Designphase zusammen entwickelt werden. Für die Entwicklung von COTS-(Commercial-of-the-shelf) Komponenten, bedeutet dies auch, dass Annahmen und Hinweise bezüglich der Security im Safety Manual dokumentiert werden.

Erweiterter Fokus der HARA

Um die Entwicklung von Security-Anforderungen von Seiten der Safety von Beginn an zu Unterstützen, kann bereits mit der HARA begonnen werden. Dazu kann bei der Analyse von Gefährdungssituationen der Fall "Manipulation" als allgemeiner Oberbegriff eingeführt werden um zusätzliche gefährliche Situationen zu betrachten. Dadurch ließen sich auch Szenarien wie "Verlust der Fahrfunktion in ungewöhnlichen Umständen", Mehrfehlerszenarios und Täuschung des Fahrers, beispielsweise durch bewusst falsche Anzeigen auf der Armatur. Zusätzlich wären hier schon die Ergebnisse einer Threat-Analyse zu berücksichtigen.

Zusammenfassung

Neben der Safety ist auch die Security als zweites "First Class" Problem im Automobil angekommen. Obwohl es zur Car-Security noch keinen allgemein anerkannten Standard gibt, ist es bereits jetzt notwendig, die Security in der Entwicklung zu berücksichtigen. Da Safety und Security miteinander wechselwirken müssen Safety und Security Anforderungen von Beginn an zusammen entwickelt werden. Dabei muss die Security auch in den Safety Manuals Eingang finden. Als erster Ansatzpunkt kann die Berücksichtigung von Threat-Analysen beginnend mit der HARA sein. Der Fall Manipulation kann hilfreich sein, um zusätzliche Szenarien zu betrachten. Richtig ist aber auch, dass Security und Safety Methoden nicht einfach vermischt werden können. Safety- und Security-Anforderungen müssen gleichwertig berücksichtigt werden.

Literatur

[1] ISO 26262 – Road Vehicles – Functional Safety, Teil 1-10, International Standard, 2011

[2] Spaar, Dieter: Auto öffne dich! – Sicherheitslücken bei BMWs ConnectedDrive (abgerufen am 16.10.2015)

[3] Timberg, Craig: Hacks on the Highway (abgerufen am 16.10.2015)

[4] ISO/IEC 27001 – Information technology – Security techniques – Information security management systems – Requirements, International Standard, 2013

[5] Common Criteria for Information Technology Security Evaluation, Version 3.1 Rev. 4, International Standard, 2012

[6] Philipp Mundhenk, Sebastian Steinhorst, Martin Lukasiewycz, Suhaib A. Fahmy, and Samarjit Chakraborty. 2015. Lightweight authentication for secure automotive networks. In Proceedings of the 2015 Design, Automation & Test in Europe Conference & Exhibition (DATE '15). EDA Consortium, San Jose, CA, USA, 285-288.