ISO 31000 Eine gemeinsame Sprache für die Cybersecurity

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Ein gemeinsames Verständnis der Cybersecurity-Perspektive beim Entwickeln von Fahrzeugen ist nicht selbstverständlich. Wie definiert man Prozesse und managt Risiken in Übereinstimmung mit ISO 31000?

Seit einiger Zeit ist die Industrie in Wartestellung für genormte Vorgaben zur Behandlung von Bedrohungen, auch um Rechtssicherheit herstellen zu können. Die nun als finaler internationaler Standard vorliegende „ISO/SAE 21434 Road Vehicles — Cybersecurity Engineering“ ist angetreten, diese Lücke zu schließen. 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 (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, Cyber­sicherheitsrichtlinien und -prozesse zu definieren sowie das Management von Cybersecurity-Risiken 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. 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 das eigene Projekt anzuwenden sind, muss man mittels 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:

Bildergalerie

Bildergalerie mit 7 Bildern

• Integrity (Integrität von Daten oder Nachrichten )

• Confidentiality (Vertraulichkeit)

• Availability (Verfügbarkeit)

• Accountability (Rechenschaftspflicht)

• Authenticity (Authentizität)

• Privacy (Privatheit)

Evaluierung von Cybersecurity-Maßnahmen

Nicht alle in Fahrzeugen verbauten Komponenten sind aus der Sicht der Cybersecurity relevant. Bei der Beantwortung der Frage, ob die Norm greift, hilft ein kurzer Fragenkatalog. 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?

I. Übergreifendes Cybersecurity Management

Ein übergreifendes Cybersecurity-Management verfolgt eine Reihe von Zielen:

• 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?

Das Cybersecurity-Management ist wie ein Schirm aus Kultur und organisatorischer Führung (Governance & Culture), der Cybersecurity ermöglicht, aber auch überwacht. Dabei legt es Richtlinien (Policy) fest, stellt Regeln auf und etabliert Prozesse, indem es zum Beispiel Guidelines, bewährte Methoden & Templates zur Verfügung stellt. Es legt Verantwortlichkeiten fest, weist Befugnisse zu (Responsibilities) und schafft Ressourcen.

Zusätzlich etabliert Governance & Culture eine Kultur, indem es 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, 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 ISO 31000 stehen, doch Abweichungen sind erlaubt. Ein Audit sollte mit einem Qualitätsmanagement kombiniert werden, um keine Ressourcen zu vergeuden. Im besten Fall wird ein Audit periodisch und fortlaufend durchgeführt. 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 brauch man, 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). Im Konfigurationsmanagement wird festgelegt und dokumentiert, aus welchen unterschiedlichen Bauteilen und unterschiedlicher Software ein System besteht. Im Fehlerfall kann so die Ursache besser nachvollzogen, überprüft und gefunden werden. Der Umfang des Änderungsmanagements in der Cybersecurity besteht darin, Änderungen an Elementen bzw. Komponenten so zu verwalten, dass die betreffenden Cybersecurity-Ziele und -Anforderungen weiterhin erfüllt werden. Darüber hinaus verdient das Tool Management noch besondere Beachtung.

Denn auch die Hilfsmittel und Werkzeuge, die man zum Schreiben und Testen von Software verwendet, 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 lassen sich als übergreifendes (Overall) Cybersecurity Management zusammenfassen. Es steht ü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.

II. Projektspezifisches Cybersecurity Management

Gewöhnlich unterschieden sich die Akteure von Projekt zu Projekt – und daher auch die Verantwortlichkeiten bezüglich der Cybersecurity-Aktivitäten. Daher wird je Projekt ein Plan erstellt, der die Cybersecurity-Aktivitäten festlegt und passende Maßnahmen definiert. Das Erstellen eines Cybersecurity-Cases liefert den Nachweis für den erreichten Grad an Cybersecurity. Ein regelmäßiges Assessment beurteilt diesen. Das führt zur Entscheidung, ob die Komponente für das Post Development freigegeben werden kann. Verantwortlichkeiten lassen sich übertragen – sofern dies kommuniziert wird und eine Übergabe relevanter Informationen statt­findet. Beim Zuschneiden der Prozesse (Tailoring) werden Tätigkeiten weggelassen oder abweichend ausgeführt. Wenn beim Zuschneiden von Aktivitäten ist eine Begründung nötig, warum die Anpassung angemessen und ausreichend ist. Von einer anderen Einheit in der Kette durchgeführte Aktivitäten gelten nicht als maßgeschneidert, sondern als verteilte Aktivitäten (distributed activities).

Welche Komponenten und Elemente bleiben relevant, welche müssen neu entwickelt werden, und wo lassen sich Teile von früheren Projekten wiederverwenden? 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, 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?

Start- und Endpunkt sowie die erwartete Dauer sind genauso wichtig wie das Identifizieren 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 genauso 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.

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 wird das Produkt am Ende zusammen mit anderen Komponenten in ein größeres Produkt integriert. In diesem Fall muss man sich stark auf Annahmen verlassen, die ebenfalls dokumentiert und kontinuierlich abgeglichen und validiert werden. 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 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 man – beabsichtigt oder nicht – vom ursprünglichen Weg abkommen. Zum Sicherstellen der Cybersecurity benötigt man geregelte Assessments. Der Dokumentation und einem Fragenkatalog folgend lässt sich feststellen, ob alles nach Plan läuft. Der resultierende Assessment Report beurteilt, ob die verfügbaren Arbeitsprodukte Vertrauen schaffen, damit der erreichte Grad der Cybersecurity des Teils bzw. der Komponente als ausreichend gilt. Wird befunden, dass man eine Komponente in dem Projekt nicht weiterverwenden kann, dann wird es zurückgewiesen.

Zusammen mit dem Cybersecurity Case und dem Assessment Report liefern die Requirements for post-development als dritte Säule Anforderungen, die fortlaufend gesammelt werden. Daraus ergeben sich Vorgaben, wo in welcher Produktphase nach der eigentlichen Entwicklungsarbeit potentielle Angreifer Schaden anrichten können. Attacken können z. B. während der Produktion erfolgen. Als wichtig erachtete Vorgaben 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 im besten Falle zu einer expliziten Freigabe, etwa für den Start der Produktion. 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 fördert die übergreifende Kultur der Cybersicherheit.

* Marcus Gößler ... ist Trainer und Coach im Bereich Embedded Systems tätig, mit Schwerpunkten in sicherheitsrelevanten Anwendungen und Multicore-Bausteinen

(ID:48200370)