Seit Juni 2020 liegt die „ISO/SAE 21434 Road Vehicles – Cybersecurity Engineering“ als Draft International Standard vor. Bevor sie internationaler Standard wird, stellen sich bereits einige Fragen: Welche Ziele, Anforderungen und Richtlinien dienen als Grundlage für ein gemeinsames Verständnis der Cybersecurity-Perspektive bei der Entwicklung von Fahrzeugen im Straßenverkehr? Wie definiert man die Prozesse und managt die Risiken in Übereinstimmung mit ISO 31000?
Bedrohungsanalyse, Risikobewertung, Aktivitäten und Work Products warten darauf, in Angriff genommen zu werden. Schauen wir uns die Motivation an, die der Norm und dem Dokument zugrunde liegt:
Sie behandelt die Cybersecurity-Perspektive bei der Entwicklung von elektrischen und elektronischen Systemen (E/E-Systemen) in Straßenfahrzeugen.
Sie stellt eine angemessene Berücksichtigung der Cybersecurity sicher.
Sie soll die Entwicklung von E/E-Systemen dazu befähigen, mit den sich ändernden Technologien und Angriffsmethoden Schritt zu halten.
Sie stellt Vokabular, Ziele, Anforderungen und Richtlinien als Grundlage für ein gemeinsames Verständnis in der gesamten Lieferkette bereit.
Sie ermöglicht es Organisationen, Cybersicherheitsrichtlinien und -prozesse zu definieren, Cybersecurity-Risiken zu managen und eine Cybersecurity-Kultur zu fördern.
Es geht also auch darum, eine gemeinsame Sprache für Kommunikation und Management von Cybersecurity-Risiken zu etablieren und eine Kultur der Cybersicherheit zu fördern.
Allgemeine Begriffe und Definitionen
Zu einer gemeinsamen Sprache gehören Begriffe, deren Bedeutung allen Ebenen in einem Cybersecurity-Projekt geläufig sein sollten. Voraussetzung dafür ist ein Bewusstsein der Terminologie und der Kultur hinter den Begriffen. Aufgaben und Verantwortlichkeiten erstrecken sich über den Bereich der Entwickler hinaus bis in die Management-Ebene hinein.
Wenn wir in der Security von einem Threat sprechen, meinen wir eine Bedrohung, die Verwundbarkeiten (Vulnerabilities) ausnutzt, um einen Angriff (Attack) auszuführen. Die Risiken (Risks) ergeben sich dabei aus der Wahrscheinlichkeit einer erfolgreichen Attacke, gepaart mit dem Schaden, der dadurch entstehen kann.
Um hier ein bestmögliches und sicheres Szenarium zu schaffen, bedient man sich sogenannter Cybersecurity Properties. Ob diese für mein Projekt anzuwenden sind, muss ich in einer entsprechenden Analyse herausfinden. Für gewöhnlich handelt es sich dabei um eine Kombination mehrerer Attribute.
Zu den wichtigsten schützenswerten Properties (Security Services) gehören:
Integrity (Integrität von Daten oder Nachrichten )
Confidentiality (Vertraulichkeit)
Availability (Verfügbarkeit)
Accountability (Rechenschaftspflicht)
Authenticity (Authentizität)
Privacy (Privatheit)
Evaluation von Cybersecurity-Maßnahmen
Nicht alle in Fahrzeugen verbauten Komponenten sind aus Sicht der Cybersecurity relevant. Um das festzustellen, hilft ein kurzer Fragenkatalog, mit dem man evaluieren kann, ob die Norm hier greift. Die Fragen beziehen sich dabei jeweils auf die zu untersuchende Komponente.
Implementiert oder trägt sie zur Fahrzeugfunktionalität durch den Einsatz von E/E-Technologie bei?
Enthält sie Schnittstellen außerhalb des Fahrzeugs?
Trägt sie zum sicheren Betrieb des Fahrzeugs bei?
Enthält sie drahtlos verbundene Sensoren oder Aktoren?
Implementiert sie Funktionen, die eine Erfassung oder Verarbeitung von benutzerbezogenen Daten erfordern?
Implementiert sie Fahrzeugfunktionen, die auf vernetzten Komponenten basieren?
Übergreifendes Cybersecurity-Management: Ziele, Governance und Culture
Ein übergreifendes Cybersecurity-Management verfolgt eine Reihe von Zielen (Objectives):
eine Cybersecurity-Richtlinie sowie organisationsspezifische Regeln und Prozesse definieren
Verantwortlichkeiten und Befugnisse zuweisen, die zur Durchführung von Cybersecurity-Aktivitäten erforderlich sind
die Umsetzung von Cybersecurity unterstützen (inklusive Ressourcen und Steuerung der Wechselwirkungen zwischen Cybersecurity-Prozessen und verwandten Prozessen)
eine Cybersecurity-Kultur einführen und pflegen (inklusive Kompetenzmanagement, Awareness-Management sowie ihre kontinuierliche Verbesserung)
ein Cybersecurity-Audit zur Prüfung der Organisation durchführen
den Austausch von Cybersecurity-Informationen managen
Management-Systeme, die Cybersecurity-Aktivitäten unterstützen, einrichten und pflegen
Nachweise erbringen, dass die verwendeten Tools die Cybersecurity nicht beeinträchtigen
Das Cybersecurity-Management ist wie ein Schirm aus Kultur und organisatorischer Führung (Governance & Culture), der Cybersecurity ermöglicht, aber auch überwacht. Dabei legt sie Richtlinien (Policy) fest, stellt Regeln auf und etabliert Prozesse, indem sie zum Beispiel Guidelines, bewährte Methoden und Templates zur Verfügung stellt. Sie legt Verantwortlichkeiten fest, weist Befugnisse zu (Responsibilities) und schafft Ressourcen.
Zusätzlich etabliert Governance & Culture eine Kultur, indem sie Kompetenzen und das Bewusstsein für die Wichtigkeit einer Cybersecurity schafft und einen kontinuierlichen Verbesserungsprozess vorantreibt. Dies geschieht zum Beispiel durch Trainingsprogramme, dem Etablieren von nachvollziehbaren Verantwortlichkeiten (Traceable Accountability) und der Betonung von „Security & Safety First“.
Mit Anreizen gewinnt man Mitarbeiter dazu, die einen Vorteil darin sehen, sich in dem Feld Cybersecurity zu engagieren. Gefördert und belohnt werden sollten in diesem Zusammenhang eine proaktive Einstellung, Vielfältigkeit und Kreativität im Denken sowie die Befolgung von Prozessen.
Risiken, Audits und Informationsmanagement
Das Risikomanagement sollte im Einklang mit der ISO 31000 stehen, doch Abweichungen sind grundsätzlich erlaubt. Wird ein Audit durchgeführt, so sollte es mit einem Qualitätsmanagement kombiniert werden, um hier effizienter zu arbeiten und keine Ressourcen zu vergeuden.
Im besten Fall wird ein Audit nicht nur einmal durchgeführt, sondern erfolgt periodisch und fortlaufend. Dabei ist neben den internen Stellen ausdrücklich ein Blick von außen durch eine extern arbeitende Organisation erwünscht. Auch das Teilen von Informationen (Sharing) unterliegt einem kritischen Blick.
So sollte festgelegt werden, welche Art von Information unter welchen Umständen überhaupt geteilt werden soll oder darf und wann das nicht erlaubt ist. Wie sieht der Informationsaustausch innerhalb der Organisation aus, und welche Maßnahmen brauche ich, um einen sicheren Austausch mit externen Stellen durchzuführen?
Auch die Organisation der unterschiedlichen Managementsysteme darf nicht dem Zufall überlassen werden. Innerhalb des Qualitätsmanagements gehören dazu das Änderungsmanagement (Change Management), das Dokumentationsmanagement, das Configuration Management sowie das Anforderungsmanagement (Requirements Management).
Für wen der Begriff neu ist: Im Konfigurationsmanagement wird festgelegt und dokumentiert, aus welchen unterschiedlichen Bauteilen und unterschiedlicher Software ein System besteht. Für den Fall eines Fehlers kann so die Ursache besser nachvollzogen, überprüft und gefunden werden. Der Umfang des Änderungsmanagements in der Cybersecurity besteht darin, Änderungen an Elementen beziehungsweise Komponenten so zu verwalten, dass die betreffenden Cybersecurity-Ziele und -Anforderungen weiterhin erfüllt werden.
Schließlich verdient das Tool Management noch besondere Beachtung. Denn auch die Hilfsmittel und Werkzeuge, die man verwendet, um Software zu schreiben und zu testen, können einen negativen Einfluss auf die Security haben. Die korrekte Verwendung der Tools anhand des Benutzerhandbuchs einschließlich Errata, der Schutz vor unbeabsichtigter Verwendung sowie eine Zugriffskontrolle oder Authentifizierung der Benutzer von Software gehören hier dazu.
Ähnlich verhält es sich mit der Informationssicherheit (Information Security Management), die ebenfalls einem Cybersecurity-Plan folgen sollte und die zum Beispiel die sichere Ablage der Arbeitsprodukte und Dokumente auf einem Fileserver garantiert, der vor unbefugten Zugriffen geschützt ist.
Die bisherigen Punkte, die man unter dem Begriff eines übergreifenden (Overall) Cybersecurity Management zusammenfassen kann, stehen über der ganzen Organisation und müssen ständig im Auge behalten werden. Komplettiert wird dies durch das Project Specific Management, das bei jedem neuen Projekt gezielt gerichtet eingesetzt wird.
Projektspezifisches Cybersecurity Management: Ziele, Planung und Assessment
Da in jedem Projekt die Zusammenstellung der teilnehmenden Personen und Teams unterschiedlich ist, werden auch die Verantwortlichkeiten bezüglich der Cybersecurity-Aktivitäten eines Projekts neu festgelegt. Dazu wird ein Plan erstellt, der die Cybersecurity-Aktivitäten, einschließlich der Definition der maßgeschneiderten Maßnahmen, festlegt.
Das Erstellen eines Cybersecurity-Cases liefert den Nachweis für den erreichten Grad an Cybersecurity. Wurde alles Notwendige unternommen, um das System sicher zu bekommen? Ein regelmäßiges Cybersecurity-Assessment beurteilt den erreichten Grad an Cybersecurity, was zur Entscheidung führt, ob die Komponente für das Post Development freigegeben werden kann.
Verantwortlichkeiten können übertragen werden – vorausgesetzt, dies wird kommuniziert und es findet eine Übergabe der relevanten Informationen statt. Beim Zuschneiden der Prozesse (Tailoring) werden Tätigkeiten weggelassen oder abweichend ausgeführt.
Wenn Aktivitäten zugeschnitten werden, muss immer eine Begründung geliefert werden, die beinhaltet, warum die Anpassung angemessen und ausreichend ist. Aktivitäten, die von einer anderen Einheit in der Kette durchgeführt werden, gelten nicht als maßgeschneidert, sondern als verteilte Aktivitäten (distributed activities).
Planung und Analyse
Welche Komponenten und Elemente sind weiterhin relevant, welche müssen neu entwickelt werden und wo verwende ich Teile von früheren Projekten? Auf diesen Cybersecurity-Plan kann im Projektplan verwiesen werden, oder er wird in den Projektplan inkludiert, wo er unter „Cybersecurity-Aktivitäten“ unterscheidbar aufgeführt ist. Auch hier müssen die Verantwortlichkeiten für die Aufrechterhaltung und Verfolgung des Fortschritts von Aktivitäten zugewiesen werden.
Ein solcher Plan zeigt genau auf, wer was wann warum wie macht. Im Detail listet er die Aktivitäten auf sowie ihre Ziele und Abhängigkeiten zu anderen Zweigen im Projekt. Wer ist verantwortlich? Welche Ressourcen werden benötigt? Startpunkt beziehungsweise Endpunkt und die erwartete Dauer sind genauso wichtig wie die Identifizierung der Arbeitsprodukte, die am Ende dabei rauskommen sollen.
Das Wiederverwenden (Reuse) von Elementen und Komponenten ist besonders kritisch zu betrachten. Zwar spart es Zeit im Projekt, doch man muss davon ausgehen, dass nichts zu 100 Prozent genau so wiederverwendet werden kann, wie es in der Vergangenheit eingesetzt wurde. Irgendwo muss immer eine Änderung eingefügt werden. Eine entsprechende Reuse-Analyse bewertet deshalb anhand genau festgelegter Parameter, ob eine Wiederverwendung den Security-Anforderungen entspricht.
Out of Context oder Off-the-Shelf?
Unter Umständen arbeitet man zusammen mit anderen Firmen oder Teams an einem größeren Projekt. Diese Projektsituation nennt man Out of Context. Man entwickelt für sich, doch man weiß, dass das Produkt am Ende zusammen mit anderen Komponenten in ein größeres Produkt integriert wird. In diesem Fall muss man sich stark auf Annahmen verlassen, die ebenfalls dokumentiert und kontinuierlich abgeglichen und validiert werden, ob sie auch weiterhin zutreffend sind.
Kauft man Off-the-Shelf-Komponenten hinzu, dann braucht man Klarheit darüber, ob das Produkt wirklich für meinen spezifischen Einsatz geeignet ist. Gibt es eine Dokumentation dazu? Muss ich es noch anpassen an meine Vorgaben und Bedürfnisse? Es können sich mitunter Ableitungen ergeben, auf deren Basis man dann weitere Entscheidungen treffen muss. So zum Beispiel, wenn damit zusätzliche Vulnerabilities erzeugt werden und damit potenzielle Gefahr droht.
Cybersecurity Assessment: Bin ich auf dem richtigen Weg?
Während der Entwicklung eines Produktes kann es passieren, dass man vom ursprünglichen Weg abkommt. Das kann beabsichtigt sein oder auch unbemerkt passieren.
Damit dadurch die Cybersecurity nicht in Gefahr kommt, brauche ich geregelte Assessments, die darauf einen prüfenden Blick werfen. Anhand der zur Verfügung stehenden Dokumentation und einem Fragenkatalog kann schnell festgestellt werden, ob alles weiterhin nach Plan läuft.
Das Resultat ist der Assessment Report, der beurteilt, ob die verfügbaren Arbeitsprodukte das Vertrauen schaffen, damit der erreichte Grad der Cybersecurity des Teils beziehungsweise der Komponente als ausreichend gilt. Wird befunden, dass man eine Komponente in dem Projekt nicht weiterverwenden kann, dann wird es zurückgewiesen.
Release-for-Post-Development-Report
Zusammen mit dem Cybersecurity Case und dem Assessment Report bieten die Requirements for Post-Development als dritte Säule Anforderungen, die fortlaufend gesammelt werden und die darüber Vorgaben liefern, wo in welcher Produktphase nach der eigentlichen Entwicklungsarbeit potenzielle Angreifer Schaden anrichten können. Attacken können zum Beispiel auch während der Produktion erfolgen. Die entsprechenden Vorgaben, die man als wichtig empfindet, werden bereits während der Entwicklung gesammelt.
Am Ende steht die Frage: Wird die Cybersecurity mit diesen Vorgaben und Informationen erfüllt? Sind entsprechende Anforderungen für die Post-Development-Phase identifiziert und überprüft? Die Antwort führt dann im besten Falle zur einer expliziten Freigabe, etwa für den Start der Produktion.
Fazit
Ein Cybersecurity-Projekt braucht eine solide Grundlage für eine gemeinsame, klare Kommunikation. Irrtümer und Missverständnisse können ein solches Projekt von Anfang an gefährden. Wer die Risiken kennt und sie gemeinsam benennen kann, der sichert nicht nur sein Projekt ab, sondern ist auf dem besten Weg, die übergreifende Kultur der Cybersicherheit zu fördern.
