15 Sicherheitsempfehlungen für den Aufbau einer sicheren Telematikplattform

Das vernetzte Fahrzeug bietet zahllose neue Vorteile in nähmlich Sicherheit, Effizienz und Komformität. Die Verbindung von Fahrzeugen mit dem Internet wirft jedoch neue Fragen zu Cyber-Sicherheit auf und hat eine branchenweite Diskussion entfacht. Solche Bedenken äußerten unter anderem das FBI, die NHTSA und NASA.1,2,3 Das FBI empfahl insbesondere, "Fahrzeugbesitzer sollten sich mit den Sicherheits- und Datenschutzrichtlinien externer Anbieter von Geräten und Dienstleistungen vertraut machen und keine unbekannten oder unzuverlässigen Geräte an den OBD II-Port anschließen." Ähnlich empfiehlt NAFA: "Fuhrparkmanager sollten Richtlinien festlegen, um zu gewährleisten, dass nur sichere Geräte an den Port angeschlossen werden." Unser Blog soll als Ausgangspunkt für diese Diskussion dienen.

Für Fahrzeugbesitzer und Fuhrparkmanager ist es natürlich schwierig zu wissen, was bei der Bewertung der Sicherheitsrichtlinien und -maßnahmen im Zusammenhang mit ihrer Telematikplattform genau zu beachten ist. Zweck dieses Blogs ist es, hierzu Hilfestellungen zu geben. Außerdem möchten wir die weitere Diskussionen vorantreiben, wie die Telematikindustrie im Allgemeinen Sicherheit fördern kann und sollte.

In der Vergangenheit stützte sich die Telematikbranche weitgehend auf drahtlose 3G-Netzwerke und neuere Mobilfunkinfrastrukturen, die eine gewisse Sicherheit bieten. GSM hat allerdings gezeigt, dass die Mobilfunkinfrastruktur, wie jedes andere verbundene System, nicht gegen Sicherheitsverletzungen gefeit ist, und dass noch mehr zu tun ist.4 Nach zeitintensiven eingehenden Studien der Thematik und Gesprächen mit anderen Experten sprechen wir hiermit die folgenden 15 Sicherheitsempfehlungen für den Aufbau einer Telematikplattform aus, die sicher gegenüber virtuellen Gefahren ist.

1. Sorgen Sie für sichere Datenübertragung

Die Einführung von Socket-Datenverschlüsselung bietet Datenschutz unabhängig vom Status des Mobilfunknetzwerks oder eines anderen zwischengeschalteten Verbindungsmediums. Durch Authentifizierung prüfen Sie, dass die empfangenen/übertragenen Datenquellen und -ziele auch tatsächlich das sind, wofür Sie sie halten. Lesen Sie auch die NIST-Empfehlungen für geeignete Verschlüsselungs- und Authentifizierungsalgorithmen.5

Verwenden Sie soweit möglich Standardverzeichnisse. Eigene Algorithmen zu schreiben ist zeitaufwändig und hoch komplex in der Umsetzung. Enthält das System Elemente, für die Standardlösungen die Anforderungen nicht erfüllen oder nicht kompatibel sind, empfehlen wir auf alle Fälle einen externen Durchdringungstest durchführen zu lassen. Es ist wesentlich besser, Probleme im Vorfeld zu erkennen und zu beheben, bevor Exploits dafür entwickelt werden.

2. ‘Digitally Sign Updates’

‘Digitally Sign Updates’ ist ein wesentliches Sicherheitselement für Telematikgeräte. Bei Sicherheitsverletzungen in der Datenkommunikation, egal wie gefährlich, kann der Angreifer nur im Funktionssatz des Gerätes aktiv werden. Bei den gefährlichsten Angriffen auf eingebettete Systeme muss oft eine bösartige Anwendung oder ein Firmware-Image eingeschleust werden. So kann der Angreifer Systemelemente aktivieren, die nicht so beabsichtigt waren oder (etwa aus Sicherheitsgründen) absichtlich beschränkt waren.

Durch Signieren von Anwendungsaktualisierungen können Geräte prüfen, ob die Aktualisierungen von einer vertrauenswürdigen Quelle stammen. Mehr über geeignete Algorithmen zur Verwendung für die Signatur erfahren Sie in diesen NIST-Empfehlungen.5 Dabei ist es wichtig, einen sicheren internen Signaturvorgang und einen Speicherort für den Schlüsseln einzurichten, um interne Bedrohungen zu minimieren.

3. Aktivieren Sie Hardware-Code-Schutz

Sofern es der Microcontroller unterstützt, deaktivieren Sie die Fähigkeit, Firmware-Code vom Gerät aus zu lesen. Code-Schutz auf dem Microcontroller zu aktivieren beschränkt deutlich die Fähigkeit des Angreifers, Geräte rückzuentwickeln, da der Angreifer keinen einfachen Zugriff auf den Code mehr hat. So kann man sich sehr gut gegen Angreifer mit beschränkten Fähigkeiten oder Ressourcen wehren. Gegen Bedroher mit mittleren (oder fortgeschrittenen) Fähigkeiten oder Ressourcen richten sie jedoch wenig aus. Manche Unternehmen bieten gegen Gebühr Code-Extraktion von verschiedenen Code-geschützten Prozessoren. Dies ist ein sehr gutes Beispiel, warum Sie stets davon ausgehen sollten, dass der Angreifer Ihr System in- und auswendig kennt.

4. Gehen Sie davon aus, dass Ihr Code öffentlich ist

Sicherheit, die auf Verborgenheit setzt, ist eine höchst anfällige Lösung. Sicherheitselemente sollten unter der Annahme gestaltet werden, dass der Angreifer Ihr System bestens kennt und bereits vollen Zugriff auf den Code hat. Selbst wenn interne Maschinen und Speicherorte derzeit als sicher erachtet werden, muss das nicht immer in der Vergangenheit der Fall gewesen sein oder künftig so bleiben. Ein ehemaliger Mitarbeiter könnte Gelegenheit gehabt haben, den System-Code auf seinen Heimcomputer zu kopieren.

5. Verwenden Sie kryptographisch starke Zahlen

Viele Sicherheitsalgorithmen generieren Zufallszahlen. Dabei ist es wichtig, dass die Quelle der Zufallszahlen kryptographisch starke Zahlen erstellen kann. Sind die generierten Zahlen kryptographisch schwach ("nicht zufällig genug"), kann dies die Stärke der Algorithmen, die diese Zufallszahlen verwenden, drastisch schwächen.

6. Individualisieren Sie sicherheitskritische Daten

Sicherheitskritische Daten wie Verschlüsselungs-Codes und Authentifizierungs-Tokens sollten für jedes Gerät individuell sein. Wird die Sicherheit eines einzigen Geräts beeinträchtigt, sollte dies niemals andere Geräte oder weitere Teile eines Ökosystems gefährden. Integrierte Systeme sind dafür berüchtigt, dass sie oft einen Schlüssel für viele Geräte verwenden.

7. Verwenden Sie unterschiedliche Schlüssel für unterschiedliche Rollen

Wird ein Element der Sicherheitslogik beeinträchtigt, sollte dies niemals weitere Elemente gefährden. Für unterschiedliche Rollen sollten unterschiedliche Schlüssel verwendet werden. Es sollte beispielsweise nicht der gleiche Schlüssel für Socket-Kommunikation und für die Signatur der Anwendung verwendet werden.

8. 8. Überwachen Sie Metadaten

Um den von bösartigen Akteuren angerichteten Schaden zu begrenzen, ist es wichtig, verdächtige Aktivitäten zu erkennen, um frühzeitig darauf reagieren zu können. Schäden aus Angriffen lassen sich vermeiden oder vermindern, indem man aktiv nach Fehlern oder Trends in sog. Debug-Informationen sucht. Es gibt viele Cloud-Processing-Dienste, mit denen sich selbst große Mengen an Leistungsdaten in Echtzeit überwachen lassen. Für die Früherkennung von Angriffen ist es unerlässlich, Dienste einzurichten, die bei Fehlern oder Anomalien die entsprechenden Ansprechpartner benachrichtigen.

9. Deaktivieren Sie Debug-Funktionen

Debug-Modi und Daten sind wesentliche Teile der Entwicklung, Fehlerbehebung und Funktionalitätsprüfung. Sie sind auch sehr gut dafür geeignet, in einem System Anomalien zu erkennen. Debug-bezogene Logik wird allerdings häufig übersehen, wenn es um Sicherheit geht. Debug-Logik, die sicherheitskritische Informationen enthält, sollte nicht in den Builds für Produktions-Software zugänglich sein.

10. Lassen Sie externe Prüfungen durchführen

Alle sicherheitsrelevanten Systemkomponenten sollten angemessen überprüft werden. Scheuen Sie sich nicht davor, Ihren Code einem professionellen Drittunternehmen zur Verfügung zu stellen, denn Ihr System sollte ja unter der Annahme gestaltet sein, dass ein Angreifer Ihre Code-Basis genau kennt. Es ist wesentlich besser, Schwachstellen privat zu erkennen und zu beheben. Für bekannte Schwachstellen mit inakzeptablen Risiken sollten angemessen zeitnah Gegenmaßnahmen getroffen werden.

11. Schränken Sie den Server-Zugriff ein

Interne Kontenhierarchien sollten so umgesetzt werden, dass nur die Personen Zugriff auf Backend-Server/-Funktionen haben, die ihn auch wirklich benötigen. Multi-Faktor-Authentifizierung ist ein hoch wirksames Werkzeug der Zugangskontrolle. Es gibt verschiedene Hardware- oder Handy-Anwendungen, die für diesen Zweck geeignet sind. Für die forensische Analyse verdächtiger Kontoaktivitäten ist es wichtig, Aufzeichnungen über Logins zu führen.

12. Bauen Sie Sicherheitsmechanismen schon bei der Entwicklungmit ein

Sicherheit sollte bereits bei der Entwicklungintegriert und nicht erst im Nachhinein hinzugefügt werden. Halten Sie sich an das Prinzip der geringsten Privilegien — sorgen Sie dafür, dass wirklich nur diejenigen Personen Zugriff auf ein Systemelement haben, die ihn auch benötigen. Vertrauen Sie nicht darauf, dass Sie über Systemeingaben kontrollieren können, wie ein Angreifer Ihr System sondieren kann.

13. Holen Sie sich Support für Software-/Firmware-Updates

Realistischerweise sollten Sie nicht davon ausgehen, dass ein System jemals perfekt abgesichert ist. Sicherheitsprobleme werden auftreten und sie sollten darauf vorbereitet sein, sie zu beheben. In einem verbundenen System ist die Fähigkeit, Software/Firmware zu aktualisieren, eine ganz wichtige Sicherheitsfunktion. Zur Bekämpfung von Zero-Day-Bedrohungen ist es ganz wichtig, rasch Aktualisierungen durchführen zu können. Es ist essentiell, dass der Hersteller für die Pflege der Firmware auf dem Gerät verantwortlich ist. Man sollte sich nicht darauf verlassen, dass der Endnutzer sein Gerät aktualisiert und sicher hält — Aktualisierungen müssen automatisch an alle im Einsatz befindlichen Geräte gepusht werden. Die Hersteller von Telematikgeräten (oder anderer IoT-Geräte) sollten für ihre eigenen Sicherheits-Patches verantwortlich sein.

14. Verifizieren und prüfen Sie

The system code base is constantly changing. Have a formal development process. Peer reviewing each change will catch countless issues in advance before they have the opportunity to do damage. Unit testing is also crucial in ensuring security logic remains functional. Unit testing should be set up at both code and hardware levels for comprehensive coverage.

15. Entwickeln Sie eine Sicherheitskultur

Selbst Systeme mit dem besten Sicherheitsdesign können von ihren Nutzern beeinträchtigt werden. Alle Mitarbeiter mit Netzwerkzugriff (nicht nur die Sicherheitsentwickler!) sollten regelmäßig in sicherer Internetnutzung geschult und darüber geprüft werden. Dazu gehört rasches Reagieren auf Phishing-Angriffe, die Nutzung starker Passwörter, Vorsicht beim Anklicken von URLs und Achten auf Sicherheitszertifikate. Schulungen sind ein guter Anfang; noch wirksamer ist es jedoch, das Interesse und Bewusstsein der Mitarbeiter für Sicherheitsfragen zu wecken.

Mehr erfahren Sie im White Paper: "Preserving Privacy and Security in the Connected Vehicle: The OBD Port on the Road Ahead" (Auf Englisch).

Wir sind davon überzeugt, dass diese Empfehlungen Sie schon ein großes Stück weiterbringen werden, eine Telematikplattform gegen Cyber-Angriffe zu wappnen. Allerdings müssen Sie sich unbedingt auch weiterbilden und weiterentwickeln, um Ihre Systeme und Nutzer auch in Zukunft zu schützen. Diese Bemühungen müssen von der ganzen Branche mitgetragen werden. Wenn Sie also Ideen oder Vorschläge haben, wie sich das Bewusstsein für Sicherheitsthemen schärfen lässt, dann werden Sie aktiv und teilen Sie weiter unten Ihr Feedback mit uns!

Literaturhinweise:

1. Federal Bureau of Investigation, “Alert Number I-031716-PSA: Motor Vehicles Increasingly Vulnerable to Remote Exploits,” 17. März 2016. [Online] Erhältlich: https://www.ic3.gov/media/2016/160317.aspx.
2. National Highway Traffic Safety Administration, “25-16: U.S. DOT issues Federal guidance to the automotive industry for improving motor vehicle cybersecurity,” 24. Oktober 2016. [Online] Erhältlich: https://www.nhtsa.gov/About-NHTSA/Press-Releases/nhtsa_cybersecurity_best_practices_10242016.
3. NAFA Fleet Management Association. “Fleet Management and the Connected Vehicle,” Oktober 2016. 
4. G. Cattaneo, G. De Maio und U.F. Petrillo, “Security Issues and Attacks on the GSM Standard: a Review,” Journal of Universal Computer Science, Band 19, Nr. 16 (2013), 2437-2452,” Oktober 2013. [Online] Erhältlich: http://www.jucs.org/jucs_19_16/security_issues_and_attacks/jucs_19_16_2437_2452_cattaneo.pdf.
5. E. Barker, “National Institute of Standards and Technology Special Publication 800-57 Teil 1, Überarbeitung 4. Recommendation for Key Management,” Januar 2016. [Online] Erhältlich: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf.
6. I. Arce u.a., “Avoiding the Top 10 Software Security Design Flaws,” IEEE Computer Society, 13. November 2015. [Online] Erhältlich: http://cybersecurity.ieee.org/blog/2015/11/13/avoiding-the-top-10-security-flaws/.