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 3

Auswahl von Maßnahmen zur prozessualen Absicherung

1. Das Bewusstsein für Security in der Entwicklung sollte gesteigert und Entwickler ganz gezielt durch IS-Spezialisten aus verschiedenen Branchen trainiert werden.
2. Security als Qualitätsanforderung mit bezogenen funktionalen Anforderungen zu spezifizieren, ist notwendig. Es sollten Sicherheitsanforderungen, Misuse Cases, und Bedrohungsmodelle zum Einsatz kommen, die gezielt Bedrohungsszenarien verdeutlichen.
3. Verbindliche Design- und Code-Standards müssen definiert und eingesetzt werden. Die Umsetzung dieser Standards muss regelmäßig überprüft werden.
4. Es ist notwendig, verbindliche Verifikations- und Validierungstechniken zu definieren und einzusetzen. Dabei sollten Werkzeuge zur statischen und dynamischen Code-Analyse zum Einsatz kommen, die gezielt für Security konfiguriert sind.
5. Richtlinien und Audits stellen sicher, 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.
6. Security sollte – von den Anforderungen bis zum Produkt – systematisch nachvollziehbar und prüfbar sein. Getroffene Maßnahmen können externe Spezialisten regelmäßig auditieren.
7. Es ist notwendig, dass Security-Experten gezielte Angriffe auf Produkte und die Systeme, in die diese eingesetzt werden, wie Diagnosesysteme oder Telematiklösungen durchführen.

Aftersales-Absicherung
Security wird nach aller Erfahrung am stärksten kompromittiert, wenn das Produkt entwickelt und freigegeben ist. Häufig werden Änderungen spontan eingearbeitet und folgen nicht mehr den ursprünglichen Anforderungen und Freigabekriterien. Das gilt insbesondere für IS-Anforderungen auf System¬ebene, denn häufig wird der zusätzliche Aufwand für Prüfungen und Konsistenzsicherung bei vermeintlich kleinen Anpassungen oder Erweiterungen nicht spendiert. Änderungen in einzelnen Funktionen oder Komponenten müssen einer weit reichenden Einflussanalyse unterzogen werden, um die potenzielle Auswirkung auf das IS-Konzept auf Systemebene zu bewerten. Das gilt sowohl bei der Freigabe von neuen Entwicklungsständen als auch bei Austausch und Einbau von neuen Komponenten im Feld. Vor dem Einbau muss eine Konsistenzprüfung der dadurch neu entstehenden Systemkonfiguration durchgeführt werden, um zu erkennen, ob durch die Änderung Kompatibilitätsprobleme auftreten und ob weitere Komponenten aktualisiert werden müssen. Ein Beispiel sind Fehlallokationen von Speicherplatz oder simple Überläufe von Eingangsspeichern.

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

Auswahl von Maßnahmen zur Aftersales-Absicherung

Absicherung auf der Systemarchitekturebene, so dass bei der Änderung im Feld eine Konsistenzprüfung der daraus neu entstehenden Systemkonfiguration durchgeführt wird und, dass unzulässige Konfigurationen gar nicht aktiviert werden können.
Einfache Prüfungen zur Security sollten für Betrieb und Service zur Verfügung stehen, zum Beispiel Integritätschecks bei der Übertragung von neuen Software-Ständen.
Es ist wichtig, ein effektives und effizientes Wartungs-Management zu installieren, damit Notfalllösungen schnell und weltweit ausgebracht werden können.
Security sollte zu einem Marketing-Thema gemacht und ihre Bedeutung vermittelt werden.
Risiken und Lösungen müssen schnell und wirksam an Betroffene kommuniziert werden. Security ist zu einem guten Teil Kommunikation und Wahrnehmung. Kunden sind sensibel dafür, wie der Automobilhersteller mit derartigen Zwischenfällen umgeht, und Hacker beobachten genau, welche Schlupflöcher existieren.
Die Unternehmenskommunikation sollte instruiert werden: Vorstände und Marketing müssen wissen, wer welche Rolle bei Notfällen mit Security in den Produkten hat. Schnelligkeit und Klarheit zählen, sobald solche Nachrichten öffentlich sind – selbst wenn jene technisch gesehen haltlos sind.

Beispiel: Fahrzeugkommunikation

Eine neue Herausforderung für die Absicherung der Fahrzeugnetze stellt die V2X-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 das bei der funknetzbasierten Nachrichtenübertragung wie 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 für solche Fälle besonders wichtig, die Integrität und Authentizität der Nachrichten zu gewährleisten.

Der initiale Angriffsschutz wird durch eine zertifikatsbasierte Sicherheitslösung realisiert, bei der jede Meldung mit einer digitalen Unterschrift versehen wird, und somit von den Empfängern auf Gültigkeit überprüft werden kann. Die Vergabe der Zertifikate ist Aufgabe einer Public-Key-Infrastruktur. Es wird unterschieden zwischen Langzeit- 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 V2X-Applikationen. Um den Schutz der Privatsphäre zu berücksichtigen, wird für den kooperativen Funkverkehr eine Identifikation des Fahrzeugs durch den Einsatz temporär begrenzter Zertifikate, den Pseudonymzertifikaten, verhindert.

Zu festgelegten Ereignissen, wie dem Einschalten der Zündung, wird aus dem Satz vorhandener Pseudonymzertifikate zufällig eines für die Signierung der V2X-Botschaften ausgewählt. 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.