Autor: Dr. Jens Christian Lisner, T\u00dcV NORD Mobilit\u00e4t<\/p>\n
Bedingt durch die aktuellen Entwicklungen im Bereich der Automobilindustrie, wie etwa verschiedene Telematik-Anwendungen, entstehen auch f\u00fcr sicherheitskritische Systeme im Sinne von Safety zus\u00e4tzliche Anforderungen durch die Car-Security. Dabei stellt sich die Frage ob sich die beiden Disziplinen gegenseitig erg\u00e4nzen oder sogar behindern, und welche Konsequenzen daraus gezogen werden k\u00f6nnen.<\/strong><\/p>\n Anders als im Deutschen kennt das Englische zwei Begriffe von Sicherheit. Die Safety ist die Abwesenheit von Risiken in Form von Unf\u00e4llen. Security bezieht sich dagegen auf die Abwehr gegen Angreifer zum Beispiel bei Diebstahl oder Vandalismus. In der IT-Industrie haben beide Begriffe ihren festen Platz.<\/p>\n Klassischerweise ist ein Auto ein geschlossenes System, so dass Gefahren durch elektrische und\/oder elektronische (E\/E-) Systeme im Ausfall von Hardware- oder Softwarekomponenten zum Beispiel durch zuf\u00e4llig Auftretende Bauteilfehler oder Software-Fehler, bestehen. Dies ist die Spielwiese der funktionalen Sicherheit (functional safety), die nach ISO 26262 als die Abwesenheit unzumutbarer Risiken durch fehlerhafte E\/E-Komponenten (s. [1] Teil 1 1.51) definiert ist. Welches Risiko noch zumutbar ist, das ergibt sich aus den Anforderungen eines Standards, wie der ISO 26262, die sich speziell an die Automobilindustrie richtet.<\/p>\n Die ISO 26262 wurde in der aktuellen Fassung 2011 ver\u00f6ffentlicht und ist bis heute in der Automobilindustrie weitgehend adaptiert worden. Eine \u00fcberarbeitete zweite Edition ist f\u00fcr 2018 geplant. Inhaltlich besch\u00e4ftigt sich die ISO 26262 mit funktionaler Sicherheit f\u00fcr Personenfahrzeuge, d.h. unter 3,5 t. Daf\u00fcr werden Anforderungen entlang des Sicherheitslebenszyklus von sicherheitsrelevanten Fahrzeugfunktionen (z.B. adaptive Geschwindigkeitsregelung oder elektronisch Parkbremse) gestellt. Ein solches System soll so entwickelt werden, das es im Fall von Fehlern der Hard- oder Software-Komponenten in einen sicheren Zustand geht. In den meisten F\u00e4llen besteht der sichere Zustand in der Abschaltung des Systems.<\/p>\n Sicherheit im Sinne von Security hat auch in der Automobilindustrie eine lange Tradition in Form von Autot\u00fcrschl\u00f6ssern und Wegfahrsperren. Relativ neu ist allerdings die Gefahr durch den Angriff auf programmierbare Systeme in Form von Steuerger\u00e4ten, die auch sicherheitskritische Funktionen \u00fcbernehmen k\u00f6nnen (im folgenden Car-Security genannt). Gerade in diesem Jahr sind mehrere spektakul\u00e4re Angriffe auf Steuerger\u00e4teebene bekannt geworden (siehe z.B. [2], [3]). M\u00f6glich werden solche Angriffe durch die verst\u00e4rkte Benutzung nach au\u00dfen offener Schnittstellen f\u00fcr z.B. Telematiksysteme, Car2x Anwendungen, Online-Software-Updates und auf Internet-Technologie beruhende Infotainment-Systemen. W\u00e4hrend die klassischen Schlie\u00dfsysteme noch von einem Angreifer am Auto durch direktes Eingreifen \u00fcberwunden werden m\u00fcssen, sind Angriffe im Sinne der Car-Security potentiell auf eine ganze Fahrzeugflotte anwendbar und k\u00f6nnen gegebenenfalls auch entfernt und sogar automatisiert durchgef\u00fchrt werden.<\/p>\n Im Gegensatz zur Funktionalen Sicherheit gibt es noch keinen etablierten Security-Standard im Bereich der Automobilindustrie. Verschiedene Arbeitsgruppen von Standardisierungsgremien oder Interessenvertretungen der Industrie, wie der VDA, entwickeln derzeit noch entsprechende Standards. Bis dahin finden bekannte Security-Standards wie die ISO 27001 (siehe [4]) oder die Common Criteria (siehe [5]) Anwendung.<\/p>\n 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\u00fcr Leib und Leben sch\u00fctzen, w\u00e4hrend 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\u00f6glich, einseitig entweder der Security oder der Safety Vorrang einzur\u00e4umen. So ist Kryptographie f\u00fcr sicherheitsrelevante Systeme mit harten Echtzeitanforderungen derzeit noch eine Herausforderung, da die bekannten starken kryptographische Algorithmen einen nicht unbetr\u00e4chtlichen Mehraufwand an Speicherplatz, Bandbreite und Rechenkapazit\u00e4t ben\u00f6tigen. 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\u00f6tig. Dazu kommt, dass die Erfahrungen mit dem Internet zeigen, dass die Anforderungen an die Kryptographie steigen – und damit der Bedarf an Rechenkapazit\u00e4t in den Steuerger\u00e4ten. F\u00fcr ein Auto, das zehn bis f\u00fcnfzehn Jahre im Gebrauch ist, bedeutet das unter Umst\u00e4nden, dass die Hardware nach ein paar Jahren nicht mehr in der Lage ist, die geforderte Security unter Beibehaltung der notwendigen Echtzeitanforderungen sicherzustellen.<\/p>\n Im Folgenden werden drei verschiedene Arten, wie Safety und Security wechselwirken k\u00f6nnen, vorgestellt.<\/p>\n Zun\u00e4chst kann ein Fehler die Security beeintr\u00e4chtigen. Bei einer elektronischen Wegfahrsperre (ESCL \u2013 Electronic Steering Column Lock) beispielsweise kann ein Fehler dazu f\u00fchren, dass die Wegfahrsperre \u00f6ffnet. Zwar ist die ESCL selbst ein sicherheitsrelevantes System, da ein fehlerhaftes Schlie\u00dfen w\u00e4hrend der Fahrt gef\u00e4hrlich ist, aber der Fall des fehlerhaften \u00d6ffnens, der die Security beeintr\u00e4chtigt, w\u00fcrde von einer Gefahren- und Risikoanalyse (HARA \u2013 Hazard Analysis an Risk Assessment) nach ISO 26262 nicht als Gefahrensituation identifiziert, da das Fahrzeug in diesem Szenario nicht f\u00e4hrt und es damit nicht zu Schaden kommen kann. Andere Folgen von zuf\u00e4lligen Hardware- oder systematischen Hardware- oder Software-Fehlern k\u00f6nnen Sicherheitsl\u00fccken in der Software oder ein Aushebeln der Kryptographie sein. Ein Beispiel f\u00fcr ein Szenario k\u00f6nnte ein Zufallsgenerator sein, der aufgrund eines Stuck-at-Fehlers konstante Werte zur\u00fcckgibt. Eine andere M\u00f6glichkeit w\u00e4re der Ausfall einer Firewall im Systembus des Autos. Das k\u00f6nnte zur Folge haben, dass Security-Mechanismen Safety-Anforderungen haben, z.B. diversit\u00e4r ausgelegt werden m\u00fcssten, was einem Angreifer wiederum zwei potentielle Angriffswege er\u00f6ffnet.<\/p>\n<\/div>\n Auf der anderen Seite kann ein Angriff auf die Safety beeintr\u00e4chtigen. Im offensichtlichen Fall eines direkten Angriffs auf z.B. Fahrerassistenzsysteme kann ein Angreifer die Kontrolle \u00fcber sicherheitsrelevanter Systeme erlangen. In diesem Fall kann der ASIL zumindest einen Anhaltspunkt bei der Bewertung der Kritikalit\u00e4t bieten.<\/p>\n 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\u00e4llen arbeiten Security- und Safety-Ma\u00dfnahmen nicht richtig zusammen, m\u00f6glicherweise sogar gegeneinander.<\/p>\n Ein Fehlschluss ist \u00fcbrigens die Annahme, dass die Sicherheitsmechanismen zur Erkennung von Fehlern Angriffe ausreichend erkennen und behandeln k\u00f6nnen, 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\u00dfnahmen verschiedene vereinfachende Annahmen gemacht. Zuf\u00e4llige Hardware-Fehler werden grunds\u00e4tzlich 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\u00f6glicherweise in der Lage, ein System so anzugreifen, das die Sicherheitsmechanismen den Angriff nicht erkennen.<\/p>\n Obwohl es also die Notwendigkeit gibt, Safety und Security gleicherma\u00dfen zu ber\u00fccksichtigen, und beide Disziplinen wechselwirken, kommt die Security in der ISO 26262 nicht vor. Als Norm aus der funktionalen Sicherheit besch\u00e4ftigt sie sich ausschlie\u00dflich mit Safety-Anforderungen. Zus\u00e4tzliche Anforderungen aus externer Quelle sind w\u00e4hrend der Software-Entwicklung ab dem Design der Software-Architektur vorgesehen. \u00a0Dies ist in der Regel zu sp\u00e4t, wenn bedingt durch widersprechende Anforderungen zus\u00e4tzliche Anforderungen auf Systemebene entstehen oder das komplette Design \u00fcberarbeitet werden muss. Deshalb m\u00fcssen Anforderungen der Safety und Security bereits ab der Designphase zusammen entwickelt werden. F\u00fcr die Entwicklung von COTS-(Commercial-of-the-shelf) Komponenten, bedeutet dies auch, dass Annahmen und Hinweise bez\u00fcglich der Security im Safety Manual dokumentiert werden.<\/p>\n Um die Entwicklung von Security-Anforderungen von Seiten der Safety von Beginn an zu Unterst\u00fctzen, kann bereits mit der HARA begonnen werden. Dazu kann bei der Analyse von Gef\u00e4hrdungssituationen der Fall „Manipulation“ als allgemeiner Oberbegriff eingef\u00fchrt werden um zus\u00e4tzliche gef\u00e4hrliche Situationen zu betrachten. Dadurch lie\u00dfen sich auch Szenarien wie „Verlust der Fahrfunktion in ungew\u00f6hnlichen Umst\u00e4nden“, Mehrfehlerszenarios und T\u00e4uschung des Fahrers, beispielsweise durch bewusst falsche Anzeigen auf der Armatur. Zus\u00e4tzlich w\u00e4ren hier schon die Ergebnisse einer Threat-Analyse zu ber\u00fccksichtigen.<\/p>\n 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\u00fccksichtigen. Da Safety und Security miteinander wechselwirken m\u00fcssen 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\u00fccksichtigung von Threat-Analysen beginnend mit der HARA sein. Der Fall Manipulation kann hilfreich sein, um zus\u00e4tzliche Szenarien zu betrachten. Richtig ist aber auch, dass Security und Safety Methoden nicht einfach vermischt werden k\u00f6nnen. Safety- und Security-Anforderungen m\u00fcssen gleichwertig ber\u00fccksichtigt werden.<\/p>\n [1] ISO 26262 \u2013 Road Vehicles \u2013 Functional Safety, Teil 1-10, International Standard, 2011<\/p>\n [2]\u00a0Spaar, Dieter: Auto \u00f6ffne dich! \u2013 Sicherheitsl\u00fccken bei BMWs ConnectedDrive<\/a>\u00a0(abgerufen am 16.10.2015)<\/p>\n [3]\u00a0Timberg, Craig: Hacks on the Highway<\/a>\u00a0(abgerufen am 16.10.2015)<\/p>\n [4] ISO\/IEC 27001 \u2013 Information technology \u2013 Security techniques \u2013 Information security management systems \u2013 Requirements, International Standard, 2013<\/p>\n [5] Common Criteria for Information Technology Security Evaluation, Version 3.1 Rev. 4, International Standard, 2012<\/p>\n [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.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n<\/div>\n [1]<\/a>\u00a0Anmerkung: In der Praxis wird man jedoch \u2013 aus anderen Gr\u00fcnden au\u00dferhalb der Funktionalen Sicherheit \/ ISO 26262 \u2013 dennoch auch in diesem F\u00e4llen ein Standard-QM-System zur Anwendung bringen.<\/p>\n<\/div>\n<\/div>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Securitysteht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nFunktionale Sicherheit und Car-Security<\/h2>\n
Wechselwirkung zwischen Safety und Security<\/h2>\n
Einfluss der Safety auf die Security<\/h2>\n
Einfluss der Security auf die Safety<\/h2>\n
ISO 26262 und Security<\/h2>\n
Erweiterter Fokus der HARA<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur<\/h2>\n
\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n