Safety- und Security-Management im Automobilbereich: die Grundlagen

Der Wandel scheint dieser Tage die einzige Konstante innerhalb der automobilen Landschaft darzustellen. Während in der Vergangenheit Markttrends bestimmte Technologieaspekte beeinflussten, lassen sich die derzeit diskutierten, sogenannten „Megatrends“, nicht unabhängig voneinander betrachten. Getrieben von deren gegenseitigen Wechselbeziehungen, arbeitet die Industrie an elektrisch angetriebenen Fahrzeugen, die sich autonom bewegen während sie mit anderen Fahrzeugen, Infrastruktureinrichtungen oder der Cloud verbunden sind. Das ultimative Ziel dieser Anstrengungen: günstige, sichere und ökologisch verträgliche Mobilität für Jedermann.

Allerdings bringt diese sehnsüchtig erwarte Fahrzeugkategorie nicht nur Vorteile für den Nutzer mit sich, sie beinhaltet gleichzeitig ein nicht unerhebliches Risikopotenzial: fahrlässiger oder vorsätzlicher Missbrauch kann zu einer Reihe von Konsequenzen führen, von einzelnen Personenschäden, Einbußen hinsichtlich des Vertrauens in einen Fahrzeughersteller, oder im Falle eines Angriffs auf eine ganze Fahrzeugflotte, Lösegeldforderungen, bis hin zum Einsatz derselben als Massenvernichtungswaffe.

Es ist deshalb nicht nur ratsam, sondern eine zwingende Notwendigkeit für Führungskräfte, die Zusammenhänge zwischen Safety und Security zu verstehen, sowohl für Software als auch für Hardware, ebenso wie deren Bedeutung und die daraus resultierenden Handlungsempfehlungen.

Dieser Beitrag beschreibt deshalb:

• Unterschied und Wechselwirkungen zwischen Safety und Security
• Schlechte Safety-/Security-Planung als Wurzel alles Übels
• Die Bedeutung von Zertifizierungen
• Rechtliche Implikationen

Der Fokus dieses Beitrags liegt auf den Safety- und Security-Aspekten von Software, wobei sich die meisten der hier vorgestellten Prinzipien ebenso anwenden lassen, wenn es um die Auswahl der richtigen Hardware-Plattform für ein sicherheitskritisches Projekt geht. Allerdings bedarf es für die Bewertung von in Frage kommenden Bauteilen, wie beispielsweise Prozessoren, noch einer genaueren Untersuchung. Hierbei sind gegebenenfalls die folgenden drei Aspekte zu betrachten:

• Unterstützt das in Frage kommende Bauteil (beziehungsweise enthält es die entsprechenden Module und Funktionsblöcke) alle benötigten Funktionen, zum Beispiel secure boot, key storage, HSM (Hardware Security Module), MMU (Memory Management Unit)?
• Wird das in Frage kommende Bauteil von den darüber liegenden (sicheren) Software-Schichten unterstützt? Oder müssen potenziell unsichere Anpassungsschichten eingefügt oder Änderungen vorgenommen werden?
• Kann der Sicherheitsaspekt über die gesamte Wertschöpfungskette dargestellt werden, das heißt von der Halbleiter-Fab über Assemblierung, Packaging, Testing, Lagerung, Distribution bis hin zur Unterstützung im Feld?

Die spezifischen Anforderungen und damit die genaue Fragestellung kann natürlich von Projekt zu Projekt variieren, allerdings sollte kein Gesichtspunkt völlig außer Acht gelassen werden, da dies einen deutlichen Einfluss auf die übergreifende Sicherheitsarchitektur hätte.

Safety und Security

Zunächst ist es wichtig herauszustellen, dass es in den meisten Fällen von Vorteil ist, die englischen Begriffe Safety und Security anstelle des deutschen Wortes Sicherheit zu nutzen. „Sicherheit“ deckt nicht eindeutig sondern nur kontextabhängig beide Bereiche ab und die gelegentlich genutzten Begriffe Funktionssicherheit (safety) und Datensicherheit (security) können für Verwirrung sorgen.

Safety beziehungsweise Functional Safety dient vereinfacht dargestellt dazu, die Wahrscheinlichkeit zu verringern, mit der eine Maschine, also beispielsweise ein Fahrzeug, eine Person verletzt. Dazu wird eine detaillierte Beschreibung aller Nutzungsszenarien und -risiken erstellt, sowie Maßnahmen ergriffen, um diese Risiken zu minimieren beziehungsweuse zu eliminieren und letztendlich das erwünschte Systemverhalten zu gewährleisten.

Verschiedene Techniken lassen sich einsetzen, die dafür sorgen sollen, ein vorhersehbares Systemverhalten zu erreichen, zum Beispiel soll ein Notbremsassistent eine Vollbremsung auslösen, falls bestimme Objekte die Trajektorie des Fahrzeugs kreuzen. Dies betrifft etwa Personen, andere Fahrzeuge oder Gebäude, allerdings keine kleinen Objekte wie Bierdosen oder Müllsäcke. Im Rahmen des Entwicklungsprozesses setzt man dazu auf Anforderungsnachverfolgung/-monitoring, Design- und Code-Reviews und natürlich umfangreiche Funktionstests.

Es ist an dieser Stelle anzumerken, dass ein hoher Grad an Safety bei einem vernetzten System nur dann erreicht werden kann, wenn auch das Thema Security entsprechend adressiert wird (natürlich ist Security auch in nicht-vernetzten Systemen wichtig, allerdings ist hier die Zahl der potenziellen Bedrohungen und der daraus resultierende Aufwand deutlich niedriger).

Security wiederum soll sicherstellen, dass niemand, als Ergebnis einer inadäquaten Software-Architektur oder eines mangelhaften Entwicklungsprozesses, einem gegebenen System schaden oder es in schädlicher Weise beeinflussen kann. In anderen Worten schützen Security-Mechanismen ein System, so dass es die ihm zugedachten Funktionen erfüllen kann, ohne von einer dritten Person beeinflusst zu werden, was letztendlich zu einem unsicheren (unsafe) Betriebsverhalten führen könnte.

Dies lässt sich an einem Kamerasystem veranschaulichen, das zur Verkehrszeichenerkennung genutzt wird. Würde ein Hacker etwa die Referenzdaten manipulieren, die herangezogen werden, um die Bedeutung von Verkehrsschildern (zum Beispiel Tempolimit) zu erkennen, könnte das System eine falsche erlaubte Höchstgeschwindigkeit annehmen und in dessen Folge den Temporegelautomaten falsch anleiten, was letztendlich das Unfallrisiko erhöhen würde oder sogar zu einem Unfall führen könnte. In einem korrekt aufgebauten System wäre es allerdings für einen Hacker nicht möglich, Zugang zu safety-kritischen Daten oder Funktionen zu erlangen, da diese von nicht-kritischen Komponenten separiert wären.

Während innerhalb der Automobilindustrie mittlerweile ein tiefgreifendes Verständnis hinsichtlich der Anforderungen an ein sicheres (safe) System existiert, ist das beim Thema Security nur bedingt der Fall, zumal auch noch eine andere Herangehensweise notwendig ist. Zunächst ist es wichtig, alle sicherheitskritischen (safe) Funktionen (Fahrerassistenzsysteme, Telltales im Kombiinstrument) zu identifizieren, und sie von nicht-kritischen Funktionen (zum Beispiel Radio) zu trennen. Einem Hacker wäre zwar gegebenenfalls der Zugang zu offenen, nicht-kritischen Teilen des Systems möglich, alle sicherheitskritischen Funktionen verbleiben aber in einen entsprechend geschützten, nicht-zugänglichen Bereich.

Ein System kann als sicher (im Sinne von Safety) betrachtet werden, falls während der Entwicklung alle entsprechenden Standards und Normen, sowie Test- und Verifikationsmethoden zum Einsatz kommen (vorausgesetzt es gibt keine gravierenden Änderungen der Umgebungsbedingungen, die Auswirkungen auf das ursprüngliche Safety-Konzept hätten). Security beziehungsweise Security-Maßnahmen unterliegen demgegenüber einem steten Wandel. Die zunehmende Vernetzung von Fahrzeugsystemen mit Consumer- oder Netzwerkinfrastruktur öffnet quasi täglich neue Einfallstüren für Hacker und gewährt zumindest indirekten Zugang zu verschiedenen Steuergeräten. Gleichzeitig wird die Schutzfunktion etablierter Verschlüsselungsalgorithmen durch die Verfügbarkeit praktisch unbegrenzter Rechenleistung ausgehebelt.

Obwohl ein gewisser Anteil an Security-Funktionen über die Betriebsdauer eines Fahrzeugs stabil bleibt, müssen spezielle Verteidigungsmechanismen oder kryptografische Verschlüsselungsalgorithmen bedarfsabhängig aktualisiert werden. Ironischerweise birgt die Funktion zur Software-Aktualisierung per Funkschnittstelle (over-the-air update, OTA), was sowohl aus wirtschaftlichen Gründen als auch bezüglich Safety/Security nötig sein kann, ebenso Security-Risiken, falls deren Implementierung Mängel aufweist. Dies ist eine reale Bedrohung, vor allem für die Millionen von Fahrzeugen, bei denen keine zuverlässige Separierung beziehungsweise Isolation von sicherheitskritischen Funktionen vorgenommen wurde.

Safety- und Security-Planung

Safety- und Security-Planung teilen sich eine Gemeinsamkeit: in beiden Fällen ist es unabdingbar, schon zu Beginn des Entwicklungsprojekts mit der jeweiligen Planung zu starten. Wie bereits beschrieben, ist eine korrekt ausgeführte Systemarchitektur ein wesentlicher Bestandteil, um ein hohes Safety- und Security-Niveau zu erreichen. Zusätzliche Funktionen oder Eigenschaften, welche Safety oder Security verbessern sollen, können nur schwerlich zu einem späteren Zeitpunkt hinzugefügt werden; wenn überhaupt möglich, dann nur in Verbindung mit hohen Kosten und signifikantem Risiko.

Speziell bei hohen Security-Anforderungen ist eine frühzeitige (sprich: vor Projektbeginn) Planung essenziell für den Projekterfolg. Man kann dies mit dem Versuch vergleichen, ein neues, zusätzliches Steuergerät in die E/E-Architektur eines sich bereits in Produktion befindlichen Fahrzeugs integrieren zu wollen. Dabei verursacht nicht in erster Linie die physische und elektrische Integration Aufwand und Kosten, sondern die gegenseitigen Verflechtungen und Abhängigkeiten mit anderen Steuergeräten (beziehungsweise Steuergerätefunktionen) und der daraus resultierende Testaufwand. Die Integration in einen in der Regel komplizierten Produktionsprozess mit entsprechenden notwendigen Modifikationen erzeugt zusätzlichen Stress bei allen Beteiligten.

Zwei Methoden haben sich in diesem Zusammenhang als sehr wertvolle Herangehensweisen bewährt: Inside-out-Security und Security-in-Depth. Security-in-Depth ist von einer altbewährten, militärischen Abwehrstrategie abgeleitet, bei der davon ausgegangen wird, dass jeder Abwehrmechanismus durchbrochen wird und deshalb ein schichtweiser Aufbau der Abwehrmaßnahmen sinnvoll ist (Bild 1).

Bild 1. Mehrschichtige Verteidigungsstrategie: Security muss auf jeder Schicht einer Software-Architektur Anwendung finden. Beginnend vom Betriebssystem als Kern bis zu den höheren/äußeren Schichten. Green Hills

Übertragen auf die Fahrzeugsysteme bedeutet dies, dass die kritischen Teile des Systems beziehungsweise Informationen durch mehrere übereinanderliegende, aber unterschiedliche Security-Mechanismen geschützt werden.

Inside-out-Security ist ein hierzu symbiotischer Ansatz, der empfiehlt, bei der Zusammenstellung der verschiedenen Schutzmechanismen im Kern des Systems beziehungsweise auf der untersten Ebene zu beginnen. Dabei werden zunächst Bereiche des Systems identifiziert, die geschützt werden müssen. Diese kritischen Teile werden dann von den nicht-kritischen Teilen über entsprechende Software- oder Hardware-Separierungsfunktionen voneinander getrennt – wobei deren Verfügbarkeit natürlich von der verwendeten Software und Hardware abhängt. Security-in-Depth sollte nicht als Ersatz für eine Inside-out-Security-Herangehensweise dienen, es dient vielmehr als Erweiterung zum prinzipiellen Ansatz der Trennung von kritischen/nicht-kritischen Systembestandteilen.

Betrachtet man diese beiden Konzepte, sollte es klar sein, weshalb eine nachträgliche Integration von Security-Funktionen Probleme verursacht: zusätzliche Schichten und deren Wechselbeziehung zu anderen Systembestandteilen beeinflussen in der Regel die Leistungsfähigkeit des Gesamtsystems bis hin zum kompletten Funktionsausfall.

Zertifizierungen

Jede Branche hat im Laufe der Zeit ihre eigenen Normen und Zertifizierungen hervorgebracht, wie beispielsweise die Automobilindustrie die Norm ISO26262 für funktionale Sicherheit oder die kommende ISO/SAE21434 für Cybersecurity-Anwendungen im Fahrzeug. Es ist empfehlenswert diesen Normen zu folgen und dabei zwei Punkte zu beachten:

• Ein System, welches komplett aus beziehungsweise mit gemäß ASIL D zertifizierten Komponenten und Werkzeugen zusammengesetzt wird, ergibt nicht automatisch ein Gesamtsystem, welches sich ebenfalls nach ASIL D zertifizieren lässt. Neben der sicher sinnvollen Verwendung von vor-zertifizierten Komponenten, ist der eigentliche Systemaufbau mindestens genauso wichtig. Der Vorteil von vor-zertifizierten Komponenten oder Modulen liegt darin, dass sich die Zertifizierung des Gesamtsystem, zum Beispiel gemäß ASIL D, schneller und zu niedrigeren Kosten durchführen lässt.
• Ein vorhandenes Zertifikat kann dabei helfen, Aussagen über eine einzusetzende Komponente zu verifizieren und gegebenenfalls verschiedene Angebote zu vergleichen. Speziell bei der Entwicklung von hochsicheren (secure) Systemen ist die Auswahl der richtigen Komponenten, zum Beispiel die Wahl des richtigen Betriebssystems, von entscheidender Bedeutung. So erscheint es sehr unwahrscheinlich, dass sich ein sicheres (secure) System auf Basis eines Betriebssystems entwickeln lässt, welches lediglich gemäß EAL4+ (Evaluation Assurance Level) oder sogar niedriger zertifiziert ist (Bild 2). Um die größtmögliche Security zu erreichen, ist es
  

  Bild 2. Evaluation Assurance Levels entsprechend der Common Criteria Security-Evaluierung. Typischerweise bezeichnet ein „+“ angehängt an die Einstufung, dass das entsprechende Produkt über die jeweilige Stufe hinaus, weitere Anforderungen erfüllt. (Quelle: Wikipedia) Green Hills

  angeraten auf ein Betriebssystem mit „Separation Kernel Architektur“ zu setzen, wie sie beispielsweise das Echtzeitbetriebssystem Integrity-178 von Green Hills Software bietet. Integrity-178 ist das einzige kommerziell verfügbare Echtzeitbetriebssystem, welches gemäß EAL 6+ zertifiziert ist und damit eine absolut sichere Basis für die darüber liegenden Software-Schichten bietet.
  Die richtige Wahl bezüglich der untersten Software-Schicht ist entscheidend für die Sicherheit des Gesamtsystems, da das Echtzeitbetriebssystem nicht nur alle Hardware-Ressourcen kontrolliert, zum Beispiel Speicher- und Kommunikationsschnittstellen, sondern gleichzeitig auch verschiedene Funktionen beziehungsweise Applikation voneinander separiert, was gleichzeitig das System vor einem Angreifer schützt, der unter Umständen bereits die Schutzmechanismen einer einzelnen Software-Partition überwunden hat.

Rechtliche Implikationen

Traditionell wird im Falle eines Verkehrsunfalls der Fahrzeugführer zur rechtlichen Verantwortung gezogen (ein Grund für die Einführung der Haftpflichtversicherung). Dies war und ist immer noch sinnvoll, da der Fahrer in mehr als 90 Prozent aller Fälle direkt für den Unfall verantwortlich ist. Bezogen auf den derzeitigen Trend von Fahrerassistenzsystemen hin zum autonomen Fahren, verschiebt sich die Verantwortung allerdings kontinuierlich in Richtung Fahrzeugproduzent, also OEM. Für diesen gestaltet sich diese Situation dahingehend schwierig, dass er nicht in allen Fällen einen kompletten Einblick in die genaue Implementierung einer speziellen Funktion hat, vor allem wenn diese Funktion auf große Mengen von Applikations-Software zurückgreift. Natürlich wird ein Großteil der eingesetzten Software vom OEM kontrolliert, zum Beispiel der Kommunikations-Stack, um Interoperabilität zwischen verschiedenen Steuergeräten zu garantieren, die wiederum von verschiedenen Zulieferern stammen können, aber in vielen Fällen handelt es sich um proprietäre Software, deren genauer Aufbau dem OEM nicht bekannt ist.

Das bedeutet, dass der OEM – trotz sorgfältiger Spezifikation, Test und Validierung – der Kompetenz des Zulieferers vertrauen und im Falle von schweren Defekten, Schadensersatzforderungen an diesen weiterreichen muss.

Um sich gegen derartige rechtliche Schritte und/oder Prozesse zu schützen, müssen Zulieferer bei der Auswahl von Hardware, Software, Prozessen und auch Werkzeugen mit äußerster Vorsicht vorgehen. Dabei ist generell zu unterscheiden zwischen den „anerkannten Regeln der Technik“, „Stand der Technik“ sowie „Stand von Wissenschaft und Technik“. Obwohl diese drei Begrifflichkeiten in vielen Fällen wahllos untereinander ausgetauscht werden, unterscheidet sich deren Bedeutung deutlich – eine Tatsache, die speziell bei der Ausformulierung eines Werkvertrages nicht ignoriert werden sollte.

• Die unterste Stufe dieser „Drei-Stufen-Theorie“ hört auf den Namen „anerkannte Regeln der Technik“ und enthält diejenigen Werkzeuge und Methoden, die in der Praxis am weitesten verbreitet sind. Eine wissenschaftliche Bestätigung beziehungsweise Überprüfung, ob diese den besten Weg darstellen, um ein bestehendes Problem zu lösen, ist nicht notwendig.
• „Stand der Technik“ nähert sich dem an, was zumindest theoretisch möglich ist. Dies beinhaltet Methoden und Werkezeuge, die nach wissenschaftlichen Gesichtspunkten, den effizientesten und fortschrittlichsten Lösungsansatz bieten.
• „Stand von Wissenschaft und Technik“ stellt die höchste Stufe dar und enthält alle neuen Erfindungen und Technologien, wobei kein Augenmerk auf deren technisch oder ökonomisch sinnvollen Einsatz gelegt wird.

Entsprechend dieser feinen Unterschiede ist es mehr als anzuraten, Anforderungs-Management mit größtmöglicher Sorgfalt zu betreiben. Anforderungen, speziell in Bereichen, in denen Richtlinien oder rechtliche Rahmenbedingungen lückenhaft sind oder ganz fehlen, sollten sehr präzise und eindeutig formuliert werden.

Zusammenfassung

Es ist mittlerweile weithin bekannt, dass kein Entwicklungsprojekt erfolgreich abgeschlossen werden kann, ohne Safety- und Security-Aspekte mit einzubeziehen. In vielen Fällen werden diese allerdings nicht von Beginn an in die Projektplanung integriert. Auch die kleinsten und einfachsten Komponenten und Subroutinen, obwohl sie vielleicht nicht direkt zur eigentlichen Applikation beitragen, können von einem Hacker zu einem gefährlichen Instrument umfunktioniert werden. Das zunehmende sich auf die Software verlassen und die Transformation der Fahrzeug-E/E-Architekturen zu reinen IT-Systemen, erhöhen diese Bedrohung zudem. Diese Situation zu verstehen und gleichzeitig einen Entwicklungsrahmen zu schaffen, in dem Safety und Security von Beginn an miteinbezogen sind, sollte zu den Kernaufgaben der Management-Ebene gehören.

(wi)