Startseite > Automotive > Software + Tools > Risiko-orientiert und Lebenszyklus-übergreifend

Security gezielt umsetzen

Risiko-orientiert und Lebenszyklus-übergreifend

5. Juli 2017, 14:55 Uhr | Von Christof Ebert und Dominik Lieckfeldt

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

System-orientierte Absicherung

Security ist aufgrund intelligent und böswillig eingeschleuster Fehlerursachen [3] sowie der systemischen Wirkbreite sehr viel schwieriger zu behandeln, als mögliche Fehlfunktionen einzelner Komponenten, wie sie bei funktionaler Sicherheit betrachtet werden. Das Problem: Handelsübliche Technologien und offene Schnittstellen gemeinsam mit einer kaum beherrschten Komplexität und einer Architektur, die Sicherheit nur auf Komponentenebene unterstützt, laden Hacker und Zufälle geradezu ein. Korrekturen, Upgrades und nachträgliche Software-Verbesserungen lassen sich in solchen Konfigurationen nicht mehr hinreichend sicher verteilen.

Security im Automobil ist nicht mit den aus der IT bekannten Techniken wie Firewalls, Gateways und IDS/IPS gleichzusetzen, wie oftmals vereinfachend angenommen wird. Firewalls können verhindern, dass unerlaubte Signale von einem (unsicheren) Netzwerk in ein anderes übertragen werden. Doch realistische Bedrohungsszenarien sind sehr viel subtiler. Beispielsweise kann ein Angriff darauf zielen, dass eine Funktion dazu gebracht wird, zulässige aber trotzdem bezüglich Inhalt, Häufigkeit oder Zeitpunkt falsche Botschaften an andere Komponenten weiterzuleiten und dabei eine Störung zu verursachen, wie es obiges Beispiel zeigte.

Wesentlicher Startpunkt für die Gewährleistung von Security auf Systemebene ist die Technik der Bedrohungsszenarien, Misuse Cases und Negativ-Modelle [2,3, 4].

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Tabelle 2 zeigt das Vorgehen anhand einer Fenstersteuerung im Fahrzeug. Es wird mit einem funktionalen Modell des Produkts, also Zustände und gewünschte Funktionen, begonnen. Dann wird parallel zu diesem funktionalen Modell ein Negativmodell erstellt, das gezielt Missbrauchsszenarien beschreibt, zum Beispiel Fensteröffner wird bei abgeschalteter Zündung bedient, die dann mit weiteren funktionalen Szenarien korreliert werden – beispielsweise Fenster muss für versehentlich eingeschlossene Personen zu öffnen sein. Aus diesen Bedrohungsszenarien werden konkrete Systemanforderungen abgeleitet und umgesetzt. Ein Beispiel ist hier der Ausschluss aller nicht explizit erlaubten Szenarien, die zum Öffnen des Fensters führen können. Schließlich werden Prüfungen auf Komponenten-, System- und Netzwerkebene durchgeführt, vor allem mittels Code-Analyse, Szenario-Reviews und Angriffs-Tests.

Auswahl von Maßnahmen zur systemorientierten Absicherung

Security bereits in die Architektur der Komponenten oder Netze einbauen („Design for Security“). Beispiele sind ROM und Flashspeicher, deren Schlüssel zur Laufzeit geprüft wird, Algorithmen und Steuergeräte, die sich zur Laufzeit authentifizieren müssen. Secure Boot von der Hardware aufwärts mit einem robusten Schlüsselmanagement sind wesentliche Voraussetzungen dafür.
Netze physikalisch trennen und Lockkeeper-Techniken bei der Übermittlung von Signalen oder Upgrades einsetzen. Niederwertige oder offene Netze dürfen niemals direkt Botschaften in sicherheitskritische Netze senden. Das Kommunikationssystem „Sync“ etwa ist von der sicherheitsrelevanten Elektronik komplett abgekoppelt.
Innerhalb von Gateways und bei externen Schnittstellen Intrusion-Detection-and-Prevention-Systeme (IDS/IDP) einsetzen, die gezielt den Datenstrom auf Unregelmäßigkeiten, wie Denial of Service, Überlast beziehungsweise Fehlersignale prüfen und gegebenenfalls unterbrechen oder indirekt die Regeln der Firewalls im Gateway anpassen.
Es sollte beachtet werden, dass viele Protokolle und damit Netze keine verlässliche QoS liefern. Informationen von Systemen, die potenziell nicht verlässlich sind, dürfen für sicherheitskritische Funktionen nur als Zusatzkriterium herangezogen werden. Die Entscheidungsbefugnis muss maßgeblich durch verlässliche Sensoren erzeugt werden. Ein Beispiel hierfür sind Informationen über Funkverbindungen wie Mobilfunk oder V2X über Straßenzustand und Verkehrslage an einer stark befahrenen Straße – ein darauf basierender Kollisionsschutz ist jedoch damit nicht gewährleistet. Authentifizierung und Informationszugriff von einem externen Netz oder von V2X-Kommunikation darf weder Voraussetzung für Schutz sein, noch dürfen relevante Informationen für sicherheitskritische Assistenzsysteme ausschließlich von außen kommen.
Die Ablage von kritischen Parametern oder die Kommunikation auf Bussystemen in Klartext sollten vermieden werden. Derart abgelegt Parameter laden zur Manipulation ein. Authentizität und Integrität der Daten über Message Authentication Codes (MAC) müssen gesichert werden. Es ist notwendig, kritische Informationen zu verschlüsseln und Prüfsummen anzuwenden, egal ob es um eine Datenübertragung auf CAN oder die Ablage von Konfigurationsparametern geht.
Eingesetzte Bussysteme müssen gegen die üblichen Fehler, wie Überlast, Denial of Service, Adress- und Paketstörungen, etc. abgehärtet werden.
Alle äußeren Schnittstellen zu Standardbussystemen sollten gleichermaßen mechanisch, elektrisch und kryptografisch abgesichert werden.
Es ist wichtig, alle Schnittstellen – zum Beispiel USB im Fahrzeuginnenraum oder zur Diagnose im Motorraum sowie extern zugreifbare Bussysteme, wie CAN im Außenspiegel – bei abgezogenem Zündschlüssel zu deaktivieren.

Prozessuale Absicherung

Prozesse zur Gewährleistung von Security sind ähnlich strukturiert wie Safety-Prozesse und müssen den gesamten Produkt-Lebenszyklus systematisch betrachten. Aus Gründen der Effizienz ist zumindest anfangs eine Überlagerung empfehlenswert – prozessual und organisatorisch. Bild 3 zeigt, wie verschiedenen Maßnahmen zur Security im Entwicklungsprozess und Aftersales zusammen spielen müssen.

Der Unterschied ist, dass man es bei funktionaler Sicherheit mit mehr oder minder zufälligen Fehlern in Hardware und Software zu tun hat, während man bei Security mit dem schlimmsten anzunehmenden Fehlverhalten zur exakt falschen Zeit rechnen muss, weil der Fehlerverursacher absichtlich und intelligent Fehler einschleusen kann.

Qualitätsmanagement im Entwicklungsprozess muss gezielt die wesentlichen Anforderungen für Informationssicherheit (IS) und ihre Umsetzung sicherstellen. Das beginnt bereits in der Spezifikationsphase, zum Beispiel mit Sicherheitsanforderungen, Misuse Cases, Umgebungsanalyse, Security-Risikoanalyse, Common Criteria, Bedrohungsmodellen. Und es setzt sich in der Implementierung und Integration fort, beispielsweise bei sicheren Architekturen, Komponentenauswahl und -verifikation, Design- und Code-Richtlinien, Verwundbarkeitsanalyse, Codeanalyse sowie Sicherheitstests. Schließlich wird Qualitätsmanagement durch eine unabhängige Evaluierung auf Prozess- und Produktebene bestätigt und bedeutet stringente Prozesse für die gesamte Lebensdauer des Automobils, zum Beispiel auch Patch Management, Diagnose, Fehleranalyse.