Cybersecurity mit überschaubarem Aufwand umsetzen

Autonomes Fahren schafft Sicherheit, da die Fahrzeugelektronik stets hellwach ist. Doch mit was beschäftigen sich die elektronischen Helfer eigentlich? Ist die Elektronik so verlässlich, wie man es von ihr erwartet?

Das Beispiel Infotainment veranschaulicht den Sachverhalt. Ein Fahrer fährt teilweise autonom auf einer Landstraße. Multisensorsysteme wiegen ihn in vermeintlicher Sicherheit. Plötzlich ertönt ein schriller Pfeifton im Lautsprecher. Der Fahrer reagiert falsch und verursacht einen Unfall. Mit wachsender Komplexität und Vernetzung, der Nutzung von Standardkomponenten sowie offenen Schnittstellen werden die verschiedenen Elektroniksysteme, vor allem im Infotainment, zunehmend angreifbarer und verlangen wirkungsvolle Schutzmaßnahmen.

Wieviel Security braucht Safety?

Cybersecurity ist in kurzer Zeit zu einem der intensiv diskutierten Themen der Automobilelektronik geworden. Typische Fragen in diesem Zusammenhang beschäftigen sich mit der Verwundbarkeit der Fahrzeugelektronik und der Zielsetzung, wie sich Funktionen, etwa ADAS oder OTA-Updates, nachvollziehbar sicher realisieren lassen. Doch wieviel Security braucht Safety eigentlich?

Sicher ist, die Fahrzeugelektronik ist angreifbar. Viele Funktionen sind aufgrund der hohen funktionalen Komplexität und Vernetzung direkt oder mittelbar sicherheitskritisch. Funktionale Sicherheit braucht Informationssicherheit (IS). Was für viele Autofahrer ein Fahrerlebnis mit tollen Funktionen ist, bedeutet für Ingenieure und Führungskräfte ein Sicherheitsrisiko – im Produkt und persönlich aufgrund der Haftungsrisiken.

Bild 1: Herausforderungen in der Elektronikentwicklung. www.vector.com/trends

Die wesentlichen Risiken der Produktentwicklung als Resultat einer Umfrage zeigt Bild 1. Kosten und Komplexität bleiben branchenübergreifend die größten Herausforderungen. Funktionale Sicherheit und Cyber Security sind 2016 als Paket jedoch schnell in den Vordergrund gerückt.

Sicherheit hat zwei Bedeutungen

Safety und Security gehören zusammen. Das zeigt auch die deutsche Etymologie. Wir verwenden den Begriff „Sicherheit“ im Deutschen mit zwei Bedeutungen. Sicherheit bedeutet die Abwesenheit von Gefahr. Die Nutzung eines Produkts oder einer Funktion darf keine Gefahr für die Gesundheit oder das Leben des Nutzers und seiner Umwelt verursachen. Der Produzent und damit die Entwickler einer Funktion müssen sicherstellen, dass diese Funktion über einen längeren Zeitraum erhalten bleibt. Sicherheit bedeutet aber auch Vertrauen. So müssen sich Nutzer darauf verlassen können, dass die Systeme und Funktionen keiner Manipulation ausgesetzt und die Daten geschützt sind. Dieser Begriff der Sicherheit stellt im näheren Sinne das Themengebiet „Security“ dar. Es geht um Integrität, Authentizität und Vertraulichkeit von Informationen, weshalb man im Deutschen auch von Informationssicherheit spricht.

Die Methodik des „Security Engineering“ lässt sich nicht einfach 1:1 aus der Informationstechnik (IT) übertragen. Ganz anders als in der IT und der Anwendungssoftware geht es bei Fahrzeugen heute um eine komplexe IT-Infrastruktur mit eingebetteten Systemen von fünfzig bis hundert Steuergeräten im Fahrzeug sowie einer schnell wachsenden IT-Infrastruktur in der Cloud für Diagnose, Kommunikation und zunehmend auch Software-Aktualisierungen, wie das Beispiel Tesla zeigt. Dies alles erfolgt in einem regulierten Rahmen, mit Milliarden Nutzern weltweit, und unter hohen Anforderungen an die funktionale Sicherheit des Fahrzeugs. Durch die dafür notwendige komplexe Software und IT dürfen betriebsunabhängig keine Schäden entstehen, weder für Personen noch für die Daten und Informationen der Nutzer, Eigentümer und Hersteller.

Die nachhaltige und durchgängige Umsetzung von Informationssicherheit in sicherheitskritischen Systemen ist im Folgenden erläutert. Der Fokus liegt auf der Automobilbranche, da sie aktuell die höchsten Anforderungen an moderne IT-Systeme stellt. Wie keine andere Branche befinden sich dort ganz unterschiedliche IT- und Software-Systeme im Einsatz und sind miteinander verknüpft – und das bei einem weltweit einzigartigen Wachstum und Innovationstempo.

Informationssicherheit und funktionale Sicherheit

Safety funktioniert nur mit Security Vector Consulting

Die Bedrohungsszenarien in der Automobilbranche verändern sich derzeit stark. Als besonders akut gelten solche Risiken dort, wo Informationssicherheit und funktionale Sicherheit zusammenkommen. Diese Bedrohungen wachsen, denn der zunehmende Einsatz von standardisierten Komponenten und offenen Schnittstellen ruft Hacker oder Angreifer auf den Plan, die sich immer neue Herausforderungen suchen.

Durch die zunehmende Vernetzung auf verschiedenen Ebenen, sowohl innerhalb des Fahrzeugs als auch nach außen hin, entsteht eine noch nie da gewesene Komplexität. Diese Komplexität führt dazu, dass nicht mehr alle Kombinationen von Ereignissen und Funktionen in gleichem Ausmaß wie bisher beherrschbar sind.

Es ist eine Frage der Zeit, bis Angreifer hierdurch entstandene Schwächen identifizieren und missbrauchen. Beispielsweise lassen sich Bussysteme wie CAN von außen relativ leicht in Überlastsituationen bringen, die dann zu Fehlverhalten führen. Heute übliche Kommunikationssysteme, wie sie immer häufiger Einzug ins Auto halten, bieten offene Schnittstellen. Man denke beispielsweise an DVDs, USB, Bluetooth und Wartungsschnittstellen, über die sich Viren und Trojaner in die jeweiligen eingebetteten Betriebssysteme einbringen lassen. Schließlich können fehlerhafte Codes und Konfigurationen zu vielfältigen, unbekannten Angriffspunkten führen.

Einige aktuelle Beispiele aus untersuchten Fahrzeugen veranschaulichen die Bedrohungsszenarien. Viele Komfortfunktionen lassen sich heute von außen beeinflussen und konfigurieren. Nicht nur das Infotainment, sondern zunehmend die gesamte Elektronik weist über OTA-Updates Schnittstellen nach außen auf. Mit diesen Konfigurationen können sich Angreifer mit Fahrzeugen über externe Kommunikations- und Unterhaltungssysteme verbinden und Netzwerkschwachstellen nutzen, um wesentliche Funktionen anzugreifen. Dies kann aufgrund der engen Verknüpfung mit sicherheitsrelevanten Anforderungen, wie beispielsweise Bremssysteme, verheerende Folgen nach sich ziehen.

Die Ursachen für unzureichende Informationssicherheit zeigt Tabelle 1 anhand von Beispielen. Sie sind gemäß der ursächlichen Entstehungsszenarien im Produkt (Funktionen, Architektur und Konfigurationen), im Prozess (Entwicklung, Prüfung und Kommunikation) sowie im Feld (Wartung, Updates und Erweiterungen) unterschieden.

Tabelle 1: Ursachen und Beispiele für Risiken in der Informationssicherheit im Lebenszyklus. Vector Consulting

Security Engineering ist im Fahrzeug historisch bedingt derzeit vor allem auf Funktionen und Komponenten ausgerichtet. Einzelne Komponenten schützt man beispielsweise durch eine verschlüsselte Freischaltung von Flashware. Sensible Funktionen wie Motormanagement, Wegfahrsperre oder Diagnoseschnittstellen sind individuell zu prüfen. Darüber hinaus finden Mechanismen der funktionalen Sicherheit (Safety) wie beispielsweise die Orientierung an Automotive Safety Integrity Levels (ASILs) Verwendung. Diese decken allerdings die Informationssicherheit nicht ab, da sie von einem zufälligen Ausfall von Komponenten ausgehen und nicht von einem böswilligen Angriff. Zudem liegt der Fokus heute primär auf einzelnen Komponenten und nicht auf einer systematischen Abhärtung auf Systemebene mit Netzwerken und Architekturen. Insofern sind Sicherheitstechniken wie die durchgängige Prüfung kritischer Bedrohungsszenarien, Datenschutz, Fehlerbehandlung, Monitoring oder Selbsttest im Rahmen von Informationssicherheit noch stringenter anzuwenden als bei der funktionalen Sicherheit.

Informationssicherheit müssen die Entwickler für das gesamte Fahrzeug adressieren. Maßnahmen zur Informationssicherheit verlangen ein system- und lebenszyklusübergreifendes Konzept – vor allem, wenn deren Wirksamkeit zu einem späteren Zeitpunkt aus rechtlichen Gründen nachzuweisen ist. Wie Fachleute bereits in der Kommunikationstechnik vor einigen Jahren erkannten, reichen isolierte Mechanismen wie die Aufteilung in proprietäre Teilsysteme, der Schutz einzelner Komponenten, Gateways und Firewalls zwischen den Komponenten und das Testen kritischer Funktionen allein nicht aus.

Doch wie werden Autos sicher? Wie härtet man Fahrzeug-IT ab? Eines der sichersten bekannten Fahrzeuge hat eine komplette Trennung der drahtlosen Kommunikationssysteme von Rechnern und Netzen, die die wesentlichen Automotive-Aktivitäten kontrollieren. Wichtig für Security Engineering sind zwei Aspekte: Bedrohungsszenarien gehen über Einzelfunktionen hinaus, und sie greifen ein System im Zusammenspiel aller seiner Funktionen und Komponenten an.

Absicherung im Produkt: Architektur und Systemebene

Informationssicherheit ist aufgrund absichtlich eingeschleuster Fehlerursachen viel schwieriger zu gewährleisten als die Vermeidung von Fehlfunktionen einzelner Komponenten, wie man sie bei funktionaler Sicherheit betrachtet. Das Problem besteht darin, dass handelsübliche Technologien und offene Schnittstellen gemeinsam mit einer kaum beherrschten Komplexität und einer Architektur, die Sicherheit nur auf Komponentenebene unterstützt, Angreifer und Zufälle geradezu einladen. Korrekturen, Upgrades und nachträgliche Softwareverbesserungen lassen sich in solchen Konfigurationen nicht mehr hinreichend sicher verteilen.

Informationssicherheit im Automobil ist nicht mit den aus der IT bekannten Techniken wie Firewalls mit Gateways gleichzusetzen. Firewalls können die Übertragung unerlaubter Signale von einem (unsicheren) Netzwerk in ein anderes verhindern. Realistische Bedrohungsszenarien sind jedoch subtiler. Beispielsweise kann ein Angreifer eine Funktion dazu bringen, zulässige, aber trotzdem bezüglich Inhalt, Häufigkeit oder Zeitpunkt falsche Informationen an andere Komponenten weiterzuleiten und dabei eine Störung zu verursachen.

Startpunkt für die Gewährleistung von Informationssicherheit im Produkt ist die Technik der Bedrohungsszenarien, Misuse Cases und Negativmodelle. Tabelle 2 zeigt das Vorgehen anhand einer Fenstersteuerung im Fahrzeug. Man beginnt mit einem funktionalen Modell des Produkts, also Zustände, gewünschte Funktionen und Gebrauchsszenarien. Parallel zu diesem funktionalen Modell erstellt man ein Negativmodell, das gezielt Missbrauchszenarien beschreibt. Zum Beispiel das Szenario „Fensteröffner wird bei abgeschalteter Zündung bedient“.

Tabelle 2: Sicherheitsanalyse am Beispiel einer Fenstersteuerung (Ausschnitt). Vector Consulting

Diese Missbrauchszenarien korreliert man dann mit weiteren funktionalen Szenarien, zum Beispiel „Fenster muss für versehentlich eingeschlossene Personen zu öffnen sein“. Aus diesen Bedrohungsszenarien erfolgt die Ableitung und Umsetzung konkreter Systemanforderungen. Dies ist zum Beispiel der Ausschluss aller nicht explizit erlaubten Szenarien, die zum Öffnen des Fensters führen können. Schließlich erfolgen Prüfungen auf Komponenten-, System- und Netzwerkebene, vor allem mittels Codeanalyse, Szenario-Reviews und Angriffstests.

Bezüglich der Informationssicherheit im Produkt sollten Ingenieure Informationssicherheit bereits in die Architektur ihrer Komponenten oder Netze einbauen (Design for Security). Beispiele sind ROM und Flashspeicher, bei denen eine Prüfung des Schlüssels zur Laufzeit erfolgt, sowie Algorithmen und Steuergeräte, die sich zur Laufzeit authentifizieren müssen.

Außerdem sollten Netze physikalisch getrennt sein und Lockkeeper-Techniken bei der Übermittlung von Signalen oder Upgrades zum Einsatz kommen. Niederwertige oder offene Netze dürfen keinesfalls direkt Botschaften in sicherheitskritische Netze senden. Das Kommunikationssystem Sync etwa, das in den USA Verkaufszahlen von rund drei Millionen Stück erreicht hat, ist von der sicherheitsrelevanten Elektronik komplett abgekoppelt.

In Gateways und bei externen Schnittstellen sollten Intrusion-Detection- und -Prevention-Systeme zum Einsatz kommen, die gezielt den Datenstrom auf Unregelmäßigkeiten (Denial of Service, Überlast, Fehlersignale) prüfen und gegebenenfalls unterbrechen oder indirekt die Regeln der Firewalls im Gateway anpassen.

Zu beachten ist, dass viele Protokolle und damit Netze keine verlässliche QoS liefern. Informationen von Systemen, die potentiell nicht verlässlich sind, dürfen für sicherheitskritische Funktionen nur als Zusatzkriterium dienen. Die Entscheidungsbefugnis ist maßgeblich durch verlässliche Sensoren zu erzeugen. Beispielsweise sind Informationen über Funkverbindungen wie Mobilfunk oder Car2x ü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 Car2x-Kommunikation darf weder Voraussetzung für Schutz sein, noch dürfen relevante Informationen für sicherheitskritische Assistenzsysteme ausschließlich von außen kommen.

Ferner ist die Ablage kritischer Parameter oder die Kommunikation auf Bussystemen in Klartext zu vermeiden. Derart abgelegt Parameter laden zur Manipulation ein. Authentizität und Integrität der Daten sollte man über MAC (Message Authentication Codes) sichern. Desweiteren sollten Ingenieure kritische Informationen verschlüsseln und Prüfsummen anwenden. Dabei spielt es keine Rolle, ob es um eine Datenübertragung auf den CAN-Bus oder die Ablage von Konfigurationsparametern geht.

In jedem Fall sollten die eingesetzten Bussysteme gegenüber üblichen Fehlern wie zum Beispiel Überlast, Denial of Service, Adress- und Paketstörungen gehärtet sein. Alle äußeren Schnittstellen zu Standardbussystemen sollten gleichermaßen mechanisch, elektrisch und kryptografisch abgesichert sein. Zudem sind alle Schnittstellen (zum Beispiel USB im Auto oder Diagnose im Motorraum) sowie Bussysteme mit möglichem externen Zugriff bei abgezogenem Zündschlüssel zu deaktivieren.

Absicherung im Prozess: Entwicklung und Test

Prozesse zur Gewährleistung von Informationssicherheit sind ähnlich strukturiert wie Safety-Prozesse und müssen den gesamten Produkt-Lebenszyklus systematisch betrachten. 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 bei Informationssicherheit mit dem schlimmsten anzunehmenden Fehlverhalten zur exakt falschen Zeit zu rechnen ist, da der Fehlerverursacher absichtlich und intelligent Fehler einschleusen kann.

Qualitätsmanagement im Entwicklungsprozess muss gezielt die wesentlichen Anforderungen an die Informationssicherheit und ihre Umsetzung sicherstellen. Dies beginnt bereits in der Spezifikationsphase, wo Kriterien wie Sicherheitsanforderungen, Misuse Cases, Umgebungsanalyse, Security-Risikoanalyse, Common Criteria und Bedrohungsmodelle zu berücksichtigen sind, und setzt sich in der Implementierung und Integration fort. In dieser Phase geht es zum Beispiel um sichere Architekturen, Komponentenauswahl und -verifikation, Design- und Coderichtlinien, Verwundbarkeitsanalyse, Codeanalyse und Sicherheitstests. Die Bestätigung erfolgt durch eine unabhängige Evaluierung auf Prozess- und Produktebene.

Dies alles beinhaltet stringente Prozesse für die gesamte Lebensdauer des Automobils, wie zum Beispiel auch Patch-Management, Diagnose und Fehleranalyse. Bild 2 zeigt, wie verschiedene Maßnahmen zur Informationssicherheit im Entwicklungsprozess zusammenspielen müssen.

Bild 2: Integrierte Maßnahmen zur Informationssicherheit kritischer Systeme. Vector Consulting

Maßnahmen zur Informationssicherheit im Entwicklungsprozess

Zur Implementierung einer wirkungsvollen Informationssicherheit gehört ein gesteigertes Bewusstsein für diese Thematik in der Entwicklung. Dies beinhaltet das Training von Entwicklern gezielt durch IS-Spezialisten aus verschiedenen Branchen, um eine Security-Kultur zu etablieren.

Ferner sollte man Informationssicherheit als nichtfunktionale Anforderung mit bezogenen funktionalen Anforderungen spezifizieren und Sicherheitsanforderungen, Misuse Cases und Bedrohungsmodelle einsetzen, die gezielt Bedrohungsszenarien spezifizieren.

Darüber hinaus sollte man verbindlich Design- und Code-Standards definieren und einsetzen sowie die Umsetzung dieser Standards prüfen. Ferner sind verbindliche Verifikations- und Validierungstechniken zu definieren und Werkzeuge zur statischen und dynamischen Codeanalyse zu nutzen, die gezielt für Informationssicherheit konfiguriert sind.

Weiterhin ist durch Richtlinien und Audits sicherzustellen, dass es keine im Feld nutzbare Angriffsmöglichkeiten gibt, die beispielsweise als Diagnoseunterstützung vorgesehen waren. Auch kunstvoll versteckte Schlupflöcher lassen sich nicht geheim halten.

Generell sollten die Verantwortlichen Informationssicherheit von den Anforderungen bis zum Produkt systematisch nachvollziehbar und prüfbar machen und die getroffenen Maßnahmen regelmäßig durch externe Spezialisten auditieren lassen.

Zu empfehlen ist auch, dass Security-Experten gezielte Angriffe auf Produkte und Systeme, in denen sie sich befinden, durchführen.

Absicherung im Feld: Wartung und After Sales

Der Erfahrung nach erfolgt die stärkste Kompromittierung der Informationssicherheit unmittelbar nach der Entwicklung und Freigabe von Produkten. Häufig arbeiten die Entwickler Änderungen spontan ein und folgen nicht mehr den ursprünglichen Anforderungen und Freigabekriterien. Dies gilt insbesondere für die Anforderungen der Informationssicherheit auf Systemebene. Denn häufig möchte man den zusätzlichen Aufwand für Prüfungen und Konsistenzsicherung bei vermeintlich kleinen Anpassungen oder Erweiterungen einsparen.

Änderungen in einzelnen Funktionen oder Komponenten müssen sich einer weitreichenden Einflussanalyse unterziehen, um die potenzielle Auswirkung auf das IS-Konzept auf Systemebene zu bewerten. Dies gilt bei der Freigabe von neuen Entwicklungsständen, aber auch bei Austausch und Einbau von neuen Komponenten im Feld. Vor dem Einbau ist eine Konsistenzprüfung der dadurch neu entstehenden Systemkonfiguration durchzuführen. So lässt sich erkennen, ob durch die Änderung Kompatibilitätsprobleme auftreten und ob eine Aktualisierung weiterer Komponenten erfolgen muss. Ein Beispiel sind Fehlallokationen von Speicherplatz oder einfache Überläufe von Eingangsspeichern.

Maßnahmen zur Informationssicherheit im Feld

Zu den Maßnahmen für eine wirkungsvolle Informationssicherheit im Feld gehört, dass bei Änderungen im Feld eine Konsistenzprüfung der daraus neu entstehenden Systemkonfiguration erfolgt und unzulässige Konfigurationen nicht aktivierbar sind.

Außerdem sollten einfache Prüfungen zur Informationssicherheit für Betrieb und Service zur Verfügung stehen, zum Beispiel Integritätschecks bei der Übertragung neuer Softwarestände. Zu raten ist auch die Installation eines effektiven und effizienten Wartungsmanagements, damit sich Notfalllösungen schnell und weltweit ausbringen lassen. Als Komponentenlieferant sollte man die Informationssicherheit zu einem Marketingthema machen und Informationssicherheit und ihre Bedeutung vermitteln, statt auf Probleme zu warten.

Die Kommunikation von Risiken und Lösungen sollte schnell und wirksam an Betroffene erfolgen. Als OEM sollte man sich klar machen, dass IS zu einem guten Teil auch Kommunikation und Wahrnehmung ist. Kunden sind sensibel dafür, wie ein OEM mit Zwischenfällen umgeht, und Angreifer beobachten genau, welche Schlupflöcher existieren.

Abschließend sollte man Unternehmenskommunikation, Vorstände und Marketing instruieren, wer welche Rolle bei Notfällen mit Informationssicherheit in Ihren Produkten hat. Schnelligkeit und Klarheit zählen, sobald solche Nachrichten öffentlich sind – selbst wenn sie technisch gesehen haltlos sind.

Beispiel C2X-Kommunikation

Eine neue Herausforderung für die Absicherung der Fahrzeugnetze stellt die Car2X-Kommunikation dar. Während bei den In-Vehicle-Netzwerken der Zugriff auf die Fahrzeugbusse einen physikalischen Zugang zur Verkabelung und somit ein Öffnen des Fahrzeugs erfordert, ist dies bei der funknetzbasierenden Nachrichtenübertragung (zum Beispiel WLAN) nicht der Fall. Befindet sich ein Angreifer innerhalb des Sendebereichs des Fahrzeugs, kann er eingehende und ausgehende Kommunikation mitschneiden, stören oder auch eigene einbringen.

Bedingt durch den Einsatzzweck tauschen die Verkehrsteilnehmer ihre Meldungen im Klartext aus, beispielsweise die Warnung vor einer Gefahrenstelle. Daher ist es hier besonders wichtig, die Integrität und Authentizität der Nachrichten zu gewährleisten. Zur Realisierung dient eine zertifikatsbasierende Sicherheitslösung, bei der jede Meldung eine digitale Unterschrift trägt und somit von den Empfängern auf Gültigkeit überprüfbar ist.

Die Vergabe der Zertifikate ist Aufgabe einer Public-Key-Infrastruktur. Man unterscheidet zwischen Langzeitzertifikaten und Pseudonymzertifikaten. Ein Langzeitzertifikat wird einem Fahrzeug für die Dauer von mehreren Jahren zugeteilt, erlaubt die eindeutige Identifikation und dient neben administrativen Zwecken der Zertifikatsverwaltung auch dem Aufbau verschlüsselter Kanäle der C2X-Applikationen.

Zum Schutz der Privatsphäre verhindern temporär begrenzte Zertifikate (Pseudonymzertifikate) im Rahmen des kooperativen Funkverkehrs die Identifikation des Fahrzeugs. Zu festgelegten Ereignissen wie dem Einschalten der Zündung wählt das System aus dem Satz vorhandener Pseudonymzertifikate zufällig eines für die Signierung der C2X-Botschaften aus. Weitere bestimmte Ereignisse oder das Erreichen der Gültigkeitsdauer sorgen während der Fahrt für einen gelegentlichen Wechsel des Pseudonymzertifikats. Über die Public-Key-Infrastruktur ist gewährleistet, dass das Fahrzeug den Vorrat an Pseudonymzertifikaten rechtzeitig erneuern kann.

Zusammenfassung

Funktionale Sicherheit braucht Informationssicherheit. Aus der IT übernommene Techniken wie proprietäre Teilsysteme, der Schutz einzelner Komponenten, Firewalls zwischen den Komponenten oder das Testen einzelner kritischer Funktionen und Missbrauchsszenarien genügen nicht mehr.

Intelligente Bedrohungsszenarien erwachsen aus ungewohnten Richtungen – zum Beispiel Angriffe auf ungeschützte Verbindungen, eingeschleuste gefährliche Code-Segmente durch offene Schnittstellen, Viren, Eindringen und Rekonfigurationen – und machen Informationssicherheit zu einem Querschnittsthema mit hoher Managementpriorität.

Entsprechende Maßnahmen sind sowohl im Produkt als auch im Entwicklungsprozess und im Feld umzusetzen. Die Entwicklung von Architekturen, Systemen und Protokollen muss spezifisch erfolgen. Außerdem sollten Unternehmen bereichsübergreifende Kompetenzen aufbauen und Mitarbeiter einzeln für Informationssicherheit entlang des gesamten Lebenszyklus trainieren. Am wichtigsten aber ist die systematische Umsetzung der getroffenen Maßnahmen und die Prüfung ihrer Wirkung, sprich Effektivität und Nutzeffekt. Nur dann lassen sich Sicherheitsmaßnahmen zielorientiert verbessern.

Die im Beitrag vorgeschlagenen Maßnahmen unterstreichen, dass sich Informationssicherheit auf der Basis eines etablierten Qualitätsmanagements, wie es heute in der Automobilentwicklung üblich ist, fokussieren und mit überschaubarem Aufwand umsetzen lässt. Nur wenn OEMs gemeinsam mit ihren Partnern zu solchen übergreifenden Sicherheitskonzepten auf Produkt-, Prozess- und Feldebene kommen, können sie die zunehmenden Risiken der Informationssicherheit beherrschen. Dann können OEMs und Lieferanten das Thema Sicherheit auch zunehmend vermarkten und damit bei Kunden als Garant für Sicherheit stehen.

Der Nutzeffekt ist groß. Von der Firma Vector durchgeführte Projekte zeigen, dass die Kosten für Sicherheitslösungen durch Test und Patch dreimal teurer – und oftmals wirkungslos – sind als umfassende Lösungen, die hier beschrieben sind. Kein Hersteller will durch unzureichende Informationssicherheit seine Marke gefährden. Informationssicherheit ist zudem Voraussetzung für funktionale Sicherheit und ist daher genauso systematisch umzusetzen.

(hb/av)