Startseite > Automotive > Software + Tools > Cybersecurity: Wie mache ich mein Produkt sicher?

Auswirkungen der ISO 21434

Cybersecurity: Wie mache ich mein Produkt sicher?

9. Juli 2023, 8:30 Uhr | Autor: Matthias Spranz, Redaktion: Irina Hübner

Die CIA-Triade bestehend aus Vertraulichkeit, Datenintegrität und Verfügbarkeit.

Mit der Verabschiedung neuer Cybersecurity-Standards rückt die Wichtigkeit dieses Themas verstärkt in den Fokus von Entwicklungsabteilungen. Wie ist mit den gestiegenen Entwicklungsanforderungen umzugehen?

▶ Diesen Artikel anhören

Safety-Standards wie EN 5012x (Railway) und ISO 26262 (Automotive) sind vielen Entwicklerinnen und Entwicklern bekannt. Neu hingegen sind Security-Standards wie EN TS 50701 für Railway und ISO 21434 für Automotive. Nach einem kurzen Überblick über Cybersecurity-Grundbegriffe geht es im Folgenden anhand von ISO 21434 exemplarisch um die Auswirkungen der neuen Anforderungen.

TARA (Threat Analysis and Risk Assessment) definiert als zentrales Werkzeug unter anderem das Vorgehen bei den weiteren Entwicklungsschritten. Doch wie ist konkret die Durchführung? Was ist zu beachten? Welche neuen Dokumente sind zu erstellen bzw. auf welche hat die Norm einen Einfluss?

Auch an die Organisationsabläufe stellen die Cybersecurity-Normen strikte Anforderungen. Wie geht man mit Cybersecurity-Incidents um? Schafft eine Threat-Intelligence-Abteilung in jedem Fall Abhilfe?

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

CIA-Triade

Ein gemeinsames Verständnis über die Grundbegriffe ist wichtig. Im Cybersecurity-Umfeld hat sich die »CIA- Triade« als eines der Kernziele etabliert. Sie beschreibt die drei wesentlichen Anforderungen, wenn es um die Sicherheit von Daten und Informationen geht (Bild 1):

Confidentiality: Vertraulichkeit bedeutet, dass Informationen nur für den Personenkreis zugänglich sind, für den sie auch bestimmt sind. Häufig wird in diesem Kontext von Verschlüsselung oder Geheimhaltung gesprochen, aber auch das schlichte Nichterfassen von Daten kann dieses Ziel erfüllen.
Integrity: Datenintegrität zielt darauf ab, dass Informationen weder auf dem Übertragungsweg noch am Speicherort verändert, beschädigt oder verloren bzw. gelöscht werden können.
Availability: Verfügbarkeit wird häufig stiefmütterlich behandelt, stellt aber wie die beiden vorherigen Punkte ein Hauptziel der CIA-Triade dar. Informationen müssen verfügbar sein, wenn sie benötigt werden, zum Beispiel via Redundanz, Notstromversorgung oder Ähnliches. Hierbei liegen oft große Kostentreiber vor und ein frühes Einbinden dieses Ziels ist ratsam.

Die CIA-Triade verlangt: Daten müssen rechtzeitig und fehlerfrei nur für berechtigte Personen zugänglich sein. Im weiteren Verlauf wird die ISO 21434 exemplarisch referenziert, andere Normen sind im Kern vergleichbar, unterscheiden sich beispielsweise bei Begriffen oder Dokumentationsform. Erwähnt werden sollte, dass die ISO 21434 den Fokus auf die Verkehrsteilnehmer (Road-User) legt.

Schutz von Urheberrechten oder Auswirkungen auf Anbieter/Hersteller, was Reputationsverlust oder Mitigierungskosten angeht, sind nicht enthalten. Es ist zu empfehlen, diese Punkte bei der Analyse ebenfalls zu berücksichtigen.

Produktsicherheit

Das primäre Instrument, um das Vorgehen der Entwicklungsabteilung zu definieren, ist die Cybersecurity-Risikoanalyse. In ISO 21434 wird sie Threat Analysis and Risk Assessment (TARA) genannt.

Das Ziel der TARA ist, die High Level Cybersecurity Requirements zu ermitteln. Die Moderation bzw. mindestens die Teilnahme durch einen erfahrenen Entwickler sollte gewährleistet sein, um kritische Rückfragen eines unabhängigen Betrachters zu gewährleisten. Die Durchführung selbst lässt sich in einen sequenziellen Ablauf unterteilen. Als Praxisbeispiel wird die TARA eines Complex Device Drivers in einem Batteriemanagementsystem (BMS) zur Kommunikation mit Batterie-Monitoring-Chips herangezogen.

Die einzelnen TARA-Schritte sind

Interfaces definieren: Die Schnittstellen der zu betrachtenden Komponente werden definiert. Das schließt alle Interfaces extern sowie intern ein. Im Praxisbeispiel wären dies APIs (Application Programming Interface) zur übergelagerten Applikation, Error-Handler, Kommunikationsschnittstelle zu den Chips, Interrupt-Modul, GPIO und das Betriebssystem.
Annahmen treffen: Welche Annahmen können getroffen werden, die den Rahmen der Betrachtung genauer abstecken und ein gemeinsames Verständnis im TARA-Team sicherstellen? Beispiel: Die erfassten Daten der Zellen werden nicht zur Ladekostenberechnung verwendet, haben daher keinen finanziellen Einfluss für den Endanwender, haben auch keinen Einfluss auf die TARA und werden somit ausgeschlossen. Auch werden Attacken, die physischen Zugriff auf das Produkt erfordern, in der Regel für die Betrachtung ausgeschlossen, was in der Liste der Annahmen notiert wird: Denn wenn physischer Zugriff nötig ist, um das Ziel zu erreichen, sind andere Attacken einfacher und effektiver als elektronische Angriffe, daher können in vielen Fällen die elektronischen Angriffe vernachlässigt werden. Ein Praxisbeispiel: Das BMS könnte durch Veränderung der Messdaten getäuscht werden, die Zellen überbelastet und ein Fahrzeugbrand ausgelöst werden. Oder jemand könnte die Bremsen mit einer Zange sabotieren.
Schützenswerte Assets benennen: Assets sind greifbar (Hardware, Gehäuse etc.) oder nicht greifbar (Informationen, Software etc.) und stellen schützenswertes Gut in dem zu betrachtenden System dar. Beispielsweise die Batteriegesundheit, die von dem BMS beeinträchtigt werden kann, oder aus Sicht des Herstellers die Software, die nicht von Dritten ausgelesen werden darf.
Schadensszenarien definieren und bewerten: In diesem Schritt wird definiert, was passieren kann, wenn ein Asset kompromittiert wird und ebenso der Schweregrad des potenziellen Schadens auf die folgenden vier Bereiche:
➔ Safety – Funktionale Sicherheit
➔ Financial – Finanzieller Schaden
➔ Operational – Verlust einer Kernfunktion des Fahrzeugs
➔ Privacy – Verstoß gegen die informationelle Selbstbestimmung
Bedrohungen identifizieren: Ein Asset kann auf verschiedene Weisen angegriffen werden. Dazu können verschiedene Methoden des »Threat Modeling« herangezogen werden, z. B. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). Jeder Angriff wird mit einem Schadensszenario verbunden, um den Schweregrad zu ermitteln.
Anforderungen ableiten oder Risiko bewahren oder teilen: Die erkannten Bedrohungen können auf drei verschiedene Arten behandelt werden. Es werden Maßnahmen abgeleitet, um sie zu verhindern oder die Auswirkungen abzudämpfen. Sie können auch bewahrt werden, falls sie nicht vermieden werden können. Oder als dritte Möglichkeit an eine übergeordnete Stelle delegiert werden, da es nicht sinnvoll ist, diese Komponente isoliert abzusichern. Bewahrte oder geteilte Risiken müssen über das Cybersecurity-Manual mitgeteilt werden.

Wurden aus der TARA keine Cybersecurity-Anforderungen abgeleitet, ist die Arbeit der Entwicklungsabteilung zu diesem Punkt erledigt und es sind keine weiteren Schritte nötig. Andernfalls findet die gesamte ISO 21434 Anwendung und bringt nötige Erweiterungen für diverse Work-Products mit und fordert einige komplett neue. Das sollte im Quality-Management-System berücksichtigt werden. Neu sind:

Cybersecurity Plan: stellt das Kerndokument dar, in dem die Abhängigkeiten, Zuständigkeiten, Ressourcen, Dokumente und die Planung (Zeitplan, Reihenfolge etc.) der Cybersecurity-fokussierten Arbeiten benannt werden.
Cybersecurity Case: liefert eine strukturierte Aufarbeitung über den erreichten Level an Sicherheit. Er sollte die gesteckten Ziele, Argumente wie sie erreicht wurden und Nachweise über die Erreichung beinhalten.
Threat Analysis and Risk Assessment Report: Bericht über die Ergebnisse aus der TARA.
Cybersecurity Process Audit Report/Checklist: Ein Audit (intern oder extern) soll durchgeführt werden, um die Tauglichkeit der Prozesse zur Einhaltung der ISO 21434 zu überprüfen und nachzuweisen.
Cybersecurity Assessment Report: Eine Überprüfung, ob der Prozess korrekt eingehalten wurde und Argumentationen schlüssig sind, um eine Konformität zur Norm zu beanspruchen, muss durchgeführt und dokumentiert werden.
Cybersecurity Interface Agreement: Auftraggeber und Zulieferer definieren in diesem Dokument die Zuständigkeiten.
Cybersecurity Manual: Im Falle von aufgeteilter Entwicklung muss, wie im TARA-Abschnitt beschrieben, zum Beispiel ein Integrator der Sub-Komponente über geteilte oder bewahrte Risiken durch dieses Dokument informiert werden. Ähnlich dem Safety Manual im SEooC-Ansatz (Safety Element out of Context) bei der ISO 26262.
Cybersecurity Monitoring and Cybersecurity Event Report/Vulnerability Analysis Report: Nachweise über die Aktivitäten zur Überwachung auf Schwachstellen bzw. bekannte Exploits.

Die größte Auswirkung auf die Entwicklung hat natürlich die Umsetzung der in der TARA ausgearbeiteten Anforderungen. Diese müssen beispielsweise wie High Level Safety Requirements besonders sorgfältig behandelt werden und haben damit eine Anpassung aller Dokumente bzw. Vorlagen zur Folge, die die Anforderungen durch das Projekt begleiten (Requirements Specification, Architektur, Design, Test Specification, Traceability Matrix Verification Plan etc.).