Die exponentielle Entwicklung der Komplexität macht es immer schwieriger, die Systeme durchgehend zu verstehen, zu beherrschen und ihre Sicherheit zu gewährleisten. Hierbei setzt sich mittlerweile die Einsicht durch, dass neben dem klassischen Safety-Aspekt auch die Security, also die Sicherheit der Systeme gegen ungewollte oder gezielte Manipulation, notwendige Voraussetzung für ein zuverlässiges System ist und damit zentraler Bestandteil der Systementwicklung sein muss.

Automotive-Security

Automotive-Security ist gekennzeichnet durch die hohe Komplexität, Innovationsrate und zunehmende Vernetzung. Der hier vorgeschlagene holistische Ansatz über Security-Profile und -Level bildet ausgehend von einer strukturierten Risikoanalyse Produkte und Systeme anhand ihres Sicherheitsbedarfs auf die jeweils passgenauen Security-Maßnahmen, Prozessvarianten und Assurance-Niveaus ab. Dadurch lässt sich die sichere Einhaltung der jeweiligen Schutzziele bei ökonomischem Mitteleinsatz garantieren.

Durch diesen Aspekt wird die Sicherheitsbetrachtung breiter. Während die funktionale Sicherheit (Safety) generell die sichere Funktion im Fokus hat, betrachtet und schützt Security weitere Aspekte. Dazu gehören neben dem Schutz vor nicht autorisierter Veränderung (etwa zur Integritätssicherung von Safety-Systemen) auch der Schutz des geistigen Eigentums und der persönlichen Daten des Endanwenders, wie zum Beispiel Positionsdaten, Geschwindigkeit und Routenwahl. Hier gilt es auch, die verschiedenen Gesetze des Datenschutzes einzuhalten.

Ganzheitliche Sicht auf Security ist notwendig

Eine Vielzahl komplexer Systeme im Fahrzeug sieht sich also grundsätzlich veränderten Randbedingungen und einer bedeutend vergrößerten Bedrohungseinschätzung gegenüber und braucht zuverlässig, schnell und ökonomisch eine effektive Security-Absicherung. Hierbei ist eine holistische Sicht auf die Systeme unverzichtbar, da ein Angreifer immer die schwächste Stelle des Gesamtsystems attackieren wird. Dies ist im Automobilbereich nicht nur durch die Komplexität und Interdependenz der Systeme, sondern auch durch eine weitgehend verteilte Entwicklung über Firmengrenzen hinweg, eine weitverzweigte Zulieferer- und Wertschöpfungskette und den verhältnismäßig langen Lebenszyklus erschwert.

Security ist so wichtig wie Safety.

Security ist so wichtig wie Safety. ETAS/Escrypt

Umso wichtiger ist somit eine klare, strukturierte Sicht auf die Security-Anforderungen. Sie muss mögliche Bedrohungen und Angreifer identifizieren und beschreiben, schützenswerte Funktionen mit ihren Rahmenbedingungen definieren sowie konkrete Sicherheitsziele ableiten. Basierend auf passenden erprobten Sicherheitsmaßnahmen muss dann über den gesamten Entwicklungs- und Lebenszyklus die Erreichung der Sicherheitsziele bei ökonomischem Mitteleinsatz sichergestellt werden. Sicherheit muss hier mehr als ein Prozess und Qualitätsmerkmal und weniger als Feature oder Produkt wahrgenommen werden.

Schutzklassen – ein Konzept für die Security-Zukunft

Der Ansatz für eine effektive und effiziente Security-Lösung ist der Einsatz von Security-Profilen und Security-Leveln, um Security nahtlos in den verteilten Entwicklungsprozess zu integrieren. Sie bilden ein einheitliches Raster für die Risikobeurteilung, den Einsatz konkreter Schutzmaßnahmen und die Skalierung der Security im Entwicklungsprozess, auch für Tests und Evaluierung. Generell gilt: Je früher ein universelles Beurteilungssystem der Security-Anforderungen in den Lebenszyklus des Produkts eingebunden wird, desto zuverlässiger und ökonomischer lassen sich die gewünschten Security-Ziele erreichen.

Bild 1: Beispiel für ein Security-Profil anhand eines Fahrerassistenzsystems (vereinfachte Darstellung).

Bild 1: Beispiel für ein Security-Profil anhand eines Fahrerassistenzsystems (vereinfachte Darstellung). ETAS/Escrypt

ETAS und Escrypt bündeln hier Erfahrungen aus der Embedded-Security und der Automotive-Embedded-Software-Entwicklung, um sowohl über die Breite der Automotive-Systeme als auch über den gesamten Lebenszyklus die Erreichung der Security-Ziele und den passgenauen Schutz der Systeme zielgerichtet zu unterstützen. Der hier vorgestellte Ansatz ist ein Vorschlag für einen strukturierten und harmonisierten Lösungsweg für die Security-Herausforderungen in der Automobilindustrie.

Ansätze aus anderen Domänen

Die Herausforderung, verlässliche und vergleichbare Sicherheit für komplexe Systeme sicherzustellen, beschränkt sich nicht auf Security im Automobilbereich. So bestehen in anderen Domänen Ansätze und Erfahrungen, die eine hervorragende Grundlage für ein angepasstes Vorgehen liefern. Für den Teilbereich Evaluierung und Assurance bieten etwa die „Common Criteria (for Information Technology Security Evaluation)“ einen detaillierten und international anerkannten Rahmen. Der „IT-Grundschutz“ des Bundesamts für Sicherheit in der Informationstechnik (BSI) bietet einfache Regeln, bei IT-Systemen Sicherheitsmaßnahmen nach dem Stand der Technik zu identifizieren und umzusetzen, und im Bereich der Automatisierungstechnik beschäftigt sich der IEC 62443-Standard mit Security-Leveln für Produkte und Systeme.

Nicht zuletzt existiert mit der ISO 26262 für den Automobilbereich ein umfangreiches Regelwerk für den Safety-Aspekt der Sicherheit, ebenfalls mit Leveleinteilung (ASIL – Automotive Safety Integrity Level) und Prozessvorgaben entsprechend der Einstufung. Allerdings existiert bisher kein Verfahren, das direkt auf den Automotive-Security-Bereich angepasst und über den ganzen Lebenszyklus anwendbar ist.

Security-Profile und Security-Level für Automotive-Systeme

„Security“ ist keine binäre Eigenschaft, die ein System hat oder eben nicht. Security hat verschiedene Aspekte und Abstufungen; der Schutz eines Systems kostet Geld und Aufwand. Die Aufgabe ist somit zweigeteilt: Das erreichbare Security-Niveau erhöhen und gleichzeitig die Entwicklung der notwendigen Security-Maßnahmen so ökonomisch wie möglich gestalten. Der verfolgte Ansatz zielt daher auf die möglichst frühzeitige Beantwortung von zwei Kernfragen: „Was genau muss geschützt werden?“ und „Wie gut muss der Schutz sein?“.

Bild 2: Aufgrund einer Risikoanalyse werden Produkte und Systeme einem Security-Profil und einem Security-Level zugeordnet. Anhand dieser Klassifizierung können die Security-Maßnahmen und der Entwicklungsprozess zielgerichtet gewählt werden.

Bild 2: Aufgrund einer Risikoanalyse werden Produkte und Systeme einem Security-Profil und einem Security-Level zugeordnet. Anhand dieser Klassifizierung können die Security-Maßnahmen und der Entwicklungsprozess zielgerichtet gewählt werden. ETAS/Escrypt

Erstere bezieht sich auf die mehrdimensionale Struktur des Security-Begriffs. Generell zielt Security immer auf den Schutz eines Wertes (Asset). Das kann etwa die Vertraulichkeit einer Information sein, die Integrität und Authentizität eines Systems oder einzelner Daten sowie die Verfügbarkeit einer Funktion. Je nach Typ des Assets sind unterschiedliche Maßnahmen notwendig. Eine klassische Datenverschlüsselung etwa schützt die Vertraulichkeit der Daten, nicht jedoch ihre Integrität. Eine Zugriffsbeschränkung schützt evtl. die Vertraulichkeit persönlicher Daten, kann aber gleichzeitig negative Auswirkungen auf die Verfügbarkeit haben. Jedes System erfordert den Schutz verschiedener Aspekte in verschiedener Ausprägung. Hieraus ergibt sich ein Security-Profil, das oftmals domänenspezifisch charakteristisch für eine Klasse von Systemen ist. Dieses Security-Profil beantwortet die Frage nach dem „Was?“ in Form eines Vektors mit Skalenwerten für die verschiedenen Automotive-Security-Aspekte.

Beispielsweise ergibt sich für ein safety-kritisches Regelsystem, etwa ein aktives Fahrerassistenzsystem, typischerweise ein Schutzprofil mit Schwerpunkt auf Integrität des Systems, Authentizität und Integrität der Sensor- und Aktuatorkommunikation sowie der Verfügbarkeit der entsprechenden Funktion (Bild 1). Vertraulichkeit der Daten ist hier, falls überhaupt, ein untergeordnetes Schutzziel.

Die Beantwortung der zweiten Frage nach dem Umfang des Schutzes basiert auf einer Abschätzung des Security-Risikos bestehend aus zwei Unterfaktoren, von denen einer zunächst die zu erwartenden Konsequenzen oder Kosten sind, die durch eine Verletzung der Sicherheitsziele entstehen. Sind Menschen gefährdet oder werden Gesetze verletzt? Wie hoch sind möglicherweise entstehende Kosten oder Imageschäden? Darüber hinaus muss abstrakt formuliert die Eintrittswahrscheinlichkeit einer Sicherheitsverletzung betrachtet werden. Anders als etwa bei Safety kann sich Security hier kaum auf Messungen und Statistik stützen, denn sie muss vielmehr die Fähigkeiten, Ressourcen und Motivation des Angreifers sowie die Eigenschaften der Einsatzumgebung berücksichtigen. Wichtige Faktoren sind dabei der Wert der zu schützenden Assets – je nach Wert wird der Angreifer bereit sein, Ressourcen einzusetzen – und die Zugriffsmöglichkeiten auf das Gerät.

Bild 3: Beispiel für unterschiedliche Ausprägung des Security-Entwicklungsprozesses anhand von fünf Security-Leveln.

Bild 3: Beispiel für unterschiedliche Ausprägung des Security-Entwicklungsprozesses anhand von fünf Security-Leveln. ETAS/Escrypt

Aus der Risikobeurteilung ergibt sich der Security-Level, der die Frage nach dem „Wie gut?“ beantwortet, was sich mit anderen Worten auch so formulieren lässt: „Vor welcher Angriffsintensität soll das System geschützt werden?“. Der Security-Level quantifiziert die Stärke des Schutzes in verschiedenen Abstufungen von „kein Schutzbedarf“ bis „extrem hoher Schutzbedarf“, der dann auch gegen Angreifer schützen muss, die beispielsweise versuchen, mit millionenteurem Equipment und unter Zerstörung des Systems auf geheime Daten zugreifen.

Zielgerichtete Entwicklung und kontinuierliche Verbesserung

Die beschriebene Klassifizierung wird nun in mehrere Richtungen genutzt. Der Security-Level bestimmt die Security-Prozessvariante, nach der das Produkt entwickelt wird. Sie betrifft die Auswahl der durchzuführenden Schritte, den Umfang der Dokumentation und Kontrolle, Art, Umfang und Intensität der Tests sowie den Umfang der Beobachtung, Wartung/Updates und Reaktionen im Fall eines Security-Zwischenfalls für Systeme im Feld. Außerdem ergibt sich aus dem Level auch, in wie weit die Security zusätzlich evaluiert und interner oder externer Überprüfung unterzogen wird. So wird sichergestellt, dass die definierten Sicherheitsziele zuverlässig und ökonomisch erreicht werden.

Das Security-Profil hingegen ermöglicht die zielgerichtete Auswahl von Security-Maßnahmen aus einem Empfehlungskatalog, der natürlich ständig dem Stand der Technik angepasst werden muss (Bild 2). Domänenspezifisch lassen sich hier Maßnahmenpakete definieren, welche die unterschiedlichen Profilanforderungen abbilden und einen Rahmen für das Security-Konzept bilden. Diese Maßnahme stellt sicher, dass erprobte standardisierte Verfahren aufeinander abgestimmt zum Einsatz kommen und korrekt konfiguriert werden, so dass ein kontinuierlicher Verbesserungsprozess auch über System- und Unternehmensgrenzen hinweg ermöglicht wird (Bild 3).

Bild 4: Abgestufte Maßnahmen für verschiedene Level für den Security-Aspekt Systemintegrität.

Bild 4: Abgestufte Maßnahmen für verschiedene Level für den Security-Aspekt Systemintegrität. ETAS/Escrypt

Als Beispiel betrachten wir den Aspekt Systemintegrität (Bild 4). Ein stufenweise abgestimmtes Maßnahmenpaket für verschiedene Absicherungslevel könnte hier als Einstieg lediglich aus einem gesicherten (Re-)Programmierprozess in Software bestehen, der in weiteren Ausbaustufen um eine Integritätsprüfung beim Systemstart und dann zusätzlich um eine zyklische Überprüfung zur Laufzeit und Security-Unterstützung in Hardware erweitert wird.

Harmonisierung bringt mehr Schutz

Schutzklassen für Security können im ersten Schritt firmenintern sinnvoll sein. So lassen sich Entwicklungskosten sparen und Security-Level konsistent über Produktklassen hinweg kategorisieren. Den größten Nutzen bringt ein solches Konzept jedoch, wenn es branchenweit eingeführt und über Standards harmonisiert wird. Im Moment laufen einige Bemühungen, um Verfahren, Vorgehensweisen oder Komponenten für Automotive-Security zu standardisieren. Gremien wie ISO, Autosar oder SAE sind internationaler Sammelpunkt, um ein abstrahierendes Security-Konzept einzuführen. Was im Bereich Safety der ISO-Standard 26262 erreicht hat, soll in ähnlicher Art und Weise für Security umgesetzt werden.

Bild 5: Escrypt-Services im Bereich der Security-Evaluierung (Auszug).

Bild 5: Escrypt-Services im Bereich der Security-Evaluierung (Auszug). ETAS/Escrypt

Security-Level und Security-Profil helfen dabei, firmen- und länderübergreifend zu kommunizieren und die Prozesse miteinander abzustimmen. So entstehen interoperable Standard-Lösungen mit dem geforderten Security-Niveau, selbst wenn sie von unterschiedlichen Anbietern hergestellt werden. ETAS und Escrypt können Hersteller und Zulieferer dabei in allen Bereichen von der Bedrohungs- und Risikoanalyse über die Definition der Security-Level bis hin zur Auswahl der Test- und Analysemethoden unterstützen – und das nicht nur bei der Entwicklung, sondern auch im operativen Serienbetrieb. Das Spektrum reicht dabei von Bedrohungs- und Risikoanalysen zur Klassifizierung über die Konzeptionierung und Implementierung von Security-Lösungen entsprechend der Ziel-Level bis zu angepasster Evaluierung, funktionalen Security- und Penetration-Tests sowie Zertifizierung und Assurance-Services – und zwar auch über den Automotive-Bereich hinaus (Bild 5).

Ganzheitliche Sicherheit

Mehr über ganzheitliche Sicherheitskonzepte im Auto erfahren Sie unter diesem Link, der zu einem Beitrag der Redaktion führt.

Durch die Schutzklassen wird außerdem die Kommunikation verschiedener Entwicklungspartner einfacher und klarer. Hier kann der auch in IEC 62443 gewählte Ansatz über Ziel- und Fähigkeitslevel verwendet werden. Zusammen mit einem korrekten, an die Einsatzumgebung angepassten Einsatz und einer entsprechenden Konfiguration, lässt socj der angepeilte Security-Level dann auch im Ziel-Gesamtsystem verifizieren.