Cybersecurity mit ISO/SAE 21434
Leitlinien zur Software-Zertifizierung
Die Norm ISO/SAE 21434 enthält eine Reihe sinnvoller Zielsetzungen für Entwickler, auch wenn sie keine genauen Leitlinien liefert, wie diese Ziele zu erreichen sind. Korrekt angewandt, können bewährte Tools wie die LDRA Tool Suite einen pragmatischen Ansatz bieten, um die Zielvorgaben zu erreichen.
In der Welt der funktionalen Sicherheit (Functional Safety) bleibt der Schutz eines einmal entwickelten Systems so lange erhalten, wie es sich im Einsatz befindet. Ganz anders ist es im Bereich für Datensicherheit (Security). Hier wird verlangt, dass die Software das betreffende System auch lange nach der Markteinführung eines Produkts fortlaufend gegen sich ständig weiterentwickelnde Angriffsmethoden verteidigt. Angesichts der explodierenden Nachfrage nach Vernetzung innerhalb des Fahrzeugs sind wir inzwischen so weit, dass unkritische Systeme, die beispielsweise der Unterhaltung dienen, dieselbe Kommunikationsinfrastruktur nutzen wie kritische Lenk-, Brems- und Steuerungs-systeme.
Für die Entwickler von Automobilsystemen bedeutet dies, dass sie in beiden Welten die einschlägigen Normen einhalten müssen. Als Leitlinie für optimale Vorgehensweisen setzt die Norm ISO/SAE 21434 dort an, wo die ISO-Norm 26262 (Road Vehicles – Functional Safety) aufhört. Die ISO/SAE 21434 nimmt immer wieder Bezug auf die ISO 26262, und tatsächlich bietet es sich an, beide Normen in jeder Phase des Produktlebenszyklus miteinander zu integrieren. Dies geht sogar so weit, dass ein mit vertrauten und verfügbaren Tools arbeitendes Testteam mit beiden Aufgaben betraut werden kann.
Zum Beispiel ist es mit ein und derselben, integrierten Vorlage und Methode möglich, parallel zueinander eine Gefährdungsanalyse, eine Safety-Risikobewertung, eine Bedrohungsanalyse und eine Security-Risikobewertung vorzunehmen.
Um deutlich zu machen, wie sich die in der Norm ISO/SAE 21434 beschriebenen Prinzipien auf die jeweiligen Phasen anwenden lassen, werden im Folgenden die einzelnen Schritte einer Entwicklung nach dem traditionellen V-Modell durchexerziert (Bild 1).
Schwachstellenanalyse nach ISO/SAE 21434 §8.5
Die Schwachstellenanalyse ist ein entscheidendes Unterscheidungsmerkmal zwischen den Entwicklungslebenszyklen von Cybersecurity-kritischen Systemen und solchen, bei denen es »nur« um funktionale Sicherheit geht. Da die Norm die dabei beteiligten Prinzipien generalisiert, ist es sinnvoll, Überlegungen über deren Gültigkeit für ein vernetztes eingebettetes Softwaresystem anzustellen.
Ein möglicher Ansatz stützt sich auf das Konzept der Vertrauensgrenzen. Diese kann man sich wie Linien vorstellen, die durch ein Programm hindurch eingezeichnet werden. Den Daten auf der einen Seite der Linie wird nicht vertraut, die Daten auf der anderen Seite dagegen werden als vertrauenswürdig angesehen.
Der erste Schritt im Zuge einer Software-Schwachstellenanalyse (Software Vulnerability Analysis, SVA) besteht im Analysieren der Daten und der Kontroll-Ein- und -Ausstiegspunkte. Geeignete Kontrollen werden überall dort definiert, wo Daten die Vertrauensgrenzen überqueren, und in einem »Bedrohungsmodell« als spezielle Datenfluss-Diagramme dokumentiert, die verschiedene Wege durch das gesamte System aufzeigen und Berechtigungsgrenzen hervorheben. Diese Analyse und die damit zusammenhängende Dokumentation helfen dem Entwicklerteam bei der Bestimmung derjenigen Punkte, die während der Cybersecurity-Validierung besonderer Beachtung bedürfen.
Im zweiten Schritt der SVA wird eine Bedrohungskategorisierung wie etwa STRIDE oder DREAD genutzt, um die Bedrohungen auf der Basis eines Systemabsturzes zu identifizieren.
Das Common Vulnerability Scoring System (CVSS) und das Common Weakness Scoring System (CWSS) hängen mit CVE bzw. CWE zusammen und können auf der Modul-, Applikations- oder Quellcodeebene Hilfestellung bei der Kategorisierung von Anfälligkeiten und Schwachstellen in der Software leisten.
Diese Bedrohungsidentifikationen und -Kategorisierungen verzahnen sich auf organische Weise in den in der Norm ISO/SAE 21434 behandelten TARA-Prinzipien (Threat Agent Risk Assessment) und helfen dafür zu sorgen, dass angemessene Sicherheitsmaßnahmen angewandt werden.
ISO/SAE 21434 §9 Konzept
In der Konzeptphase werden die Funktionen auf der Fahrzeugebene berücksichtigt. Funktionen werden dabei als sogenannte »Items« implementiert, für die entsprechende Cybersecurity-Ziele definiert werden. Bei diesen Cybersecurity-Zielen handelt es sich um übergeordnete Anforderungen, die sich in den nachfolgenden Entwicklungs- und Implementierungsphasen widerspiegeln müssen. Der Nachweis dieser Rückverfolgbarkeit mit traditionellen Mitteln kann sich allerdings für das Projektmanagement problematisch gestalten, und zwar insbesondere dann, wenn Tests fehlschlagen oder sich die Anforderungen ändern.
Rückverfolgbarkeit von Anforderungen
Die Rückverfolgbarkeit von Cybersecurity-Anforderungen ist eine entscheidende Zielsetzung der Norm ISO/SAE 21434, ebenso wie es die Rückverfolgbarkeit von Functional-Safety-Anforderungen in der Norm ISO 26262 ist. Die Anforderungen RQ 09 08, RQ 09 09 und RQ 09 10 der ISO/SAE 21434 befassen sich mit der Herleitung von Cybersecurity-Anforderungen aus Cybersecurity-Spezifikationen, wobei das Prinzip der Rückverfolgbarkeit über den gesamten Entwicklungszyklus hinweg etabliert wird.
Die Rückverfolgbarkeit sowohl zu den Projektanforderungen als auch zu den Zielsetzungen der Norm im Auge zu behalten, kann sich für das Projektmanagement zu einem wahren Albtraum entwickeln, und zwar insbesondere dann, wenn Änderungen vorkommen. Die Herausforderung wird sogar noch gravierender, wenn gleichzeitig weitere Normen wie etwa ISO 26262, AUTOSAR oder ASPICE anzuwenden sind. Hier bietet die automatisierte Rückverfolgbarkeit (Bild 2) den Zugang zu einer permanent aktualisierten Requirements Traceability Matrix (RTM).
- Leitlinien zur Software-Zertifizierung
- Produktentwicklung
Das könnte Sie auch interessieren
Advertorial: Kompakt und leistungsstark
Neue CoMs von Advantech
Software-Entwicklungsumgebung
Im Paket mit vereinfachter Installation und…
Testautomatisierung
Mit automatisierten Tests zur ASIL-D-Konformität
Verwandte Artikel
LDRA Inc.
Alle Beiträge im Überblick
Online-Themenwoche »Embedded-Systeme«
MISRA C:2023
Konformität für alle Security- und…
