Seit Juli 2024 müssen alle Steuergeräte in Fahrzeugen gemäß der Norm ISO/SAE 21434, auch bekannt als ISO 21434, entwickelt werden. Das Fehlen eines entsprechenden Security-Nachweises nach ISO 21434 kann die Homologation des gesamten Fahrzeugs beeinträchtigen und im schlimmsten Fall dazu führen, dass keine Straßenzulassung erteilt wird. Um eine fundierte Threat Analysis and Risk Assessment (TARA) durchführen zu können, ist die Identifikation der relevanten Assets unerlässlich. In diesem Blogartikel wird erläutert, was ein Asset ist, wie es im Automobilkontext definiert wird und wie man diese systematisch identifiziert.
Asset Definition
Bevor wir mit der Identifikation von Assets beginnen können, ist es wichtig, den Begriff “Asset” im Kontext der Produkt Cybersicherheit zu klären und auf Steuergeräte anzuwenden. Was zunächst trivial erscheinen mag, erweist sich als deutlich komplexer als erwartet.
Die ISO 21434 bietet eine recht vage Definition eines Assets. Laut der Norm ist ein Asset ein Objekt mit Wert oder ein Objekt, das zum Wert beiträgt. Diese breite Definition lässt viel Raum für Interpretationen, was sowohl Vor- als auch Nachteile mit sich bringt.
Das National Institute of Standards and Technology (NIST) bietet mehrere Definitionen an, aus denen wir die geeignetste auswählen sollten.
Definition aus NIST SP 800-160v1r1 (Stand 01.09.2024):
„Anything that has value to a person or organization.“
Diese Definition ist äußerst unpräzise und bietet zu viel Interpretationsspielraum, weshalb sie im Kontext von Steuergeräten nicht ausreichend ist.
Definition aus NISTIR 7693 und NISTIR 7694 (Stand 01.09.2024):
„Anything that has value to an organization, including, but not limited to, another organization, person, computing device, information technology (IT) system, IT network, IT circuit, software (both an installed instance and a physical instance), virtual computing platform (common in cloud and virtualized computing), and related hardware (e.g., locks, cabinets, keyboards).“
Diese Definition bleibt ebenfalls zu allgemein, da Steuergeräte eine feinere Granularität erfordern und eine präzisere Asset-Definition notwendig ist.
Definition aus NIST SP 800-160 Vol. 2 Rev. 1 (Stand 01.09.2024):
„An item of value to stakeholders. An asset may be tangible (e.g., a physical item such as hardware, firmware, computing platform, network device, or other technology component) or intangible (e.g., humans, data, information, software, capability, function, service, trademark, copyright, patent, intellectual property, image, or reputation). The value of an asset is determined by stakeholders in consideration of loss concerns across the entire system life cycle. Such concerns include but are not limited to business or mission concerns.“
Diese Definition trifft den Kern des Begriffs „Asset“ im Automotive-Security Kontext am besten. Zwar ist sie nicht perfekt, aber sie kommt der Praxis am nächsten.
Um eine optimale Definition für Embedded Systems zu formulieren, müssen wir die obige Definition verfeinern und an den spezifischen Kontext anpassen. Ein geeigneter Vorschlag lautet:
Ein Asset ist ein Gegenstand von Wert für die betroffenen Stakeholder. Ein Asset kann greifbar sein (z. B. physische Gegenstände wie intelligente Sensoren oder integrierte Schaltkreise, Firmware, Mikrocontroller) oder immateriell (z. B. persönliche Daten, Schlüsselmaterial, Konfigurationsparameter, Funktionalitäten, Services, geistiges Eigentum oder andere Daten/Informationen/Konfigurationsparameter). Der Wert eines Assets wird von den Stakeholdern im Hinblick auf potenzielle Verluste über den gesamten Produktlebenszyklus hinweg bestimmt.
Wie man Assets identifiziert
Da wir jetzt eine Definition dafür haben, was Assets sind, können wir loslegen und anfangen Assets zu identifizieren. Die erste Frage, die man sich dabei stellt ist, wo kommen diese Assets her? Laut der ISO 21434 können diese aus der Item Definition und Cybersicherheit Spezifikationen stammen. Die Frage ist: Reicht das aus? Ein klares “Nein”. Diese Dokumente können zwar dabei helfen Assets zu identifizieren, aber je nach dem Detailgrad der Dokumentation beider, kann es einfach oder unmöglich sein Assets zu identifizieren.
Mögliche Assets
Meistens sind bei Steuergeräten folgende Assets aufzufinden:
- Firmware
- Schlüsselmaterial (Asymetrische Schlüssel, Symetrische Schlüssel)
- Flags, die zur Abriegelung von Hauseigenen Debug-Interfaces verwendet werden
- Jegliche Informationen, die nicht verändert werden dürfen.
- Konfigurationensparameter
- Einzelfunktionen des Steuergeräts z. B. CAN Nachricht zum Türöffnen
Je nach Spezifikation des Steuergerätes können die unterschiedlichsten Assets identifiziert werden.
Asset Herkunft / Quellen
Gemäß ISO/SAE 21434:2021-08 sollten die Item-Definition und die Cyber Security Anforderungen grundsätzlich ausreichen. Doch was passiert, wenn ein Asset in der Software Spezifikation übersehen wurde? Oder wenn während der Vulnerability Analyse ein neues Asset identifiziert wird? Auch während der Threat Assessment and Risk Analysis (TARA) sowie bei der Erstellung des Cyber Security Konzepts können unerwartet neue Assets entdeckt werden.
Das folgende Diagramm fasst die möglichen Quellen für die Identifikation solcher Assets übersichtlich zusammen.
Praktische Durchführung der Asset Identifikation
In unserem Beispiel betrachten wir ein fiktives Türsteuergerät (DCU), das verschiedene Speicherbausteine für unterschiedliche Funktionen nutzt. Innerhalb des Steuergeräts findet zudem eine Kommunikation zwischen zwei Mikrocontrollern statt.
Aus der Item-Definition wissen wir, dass die DCU wie folgt aufgebaut ist:
MCU1: Enthält einen Bootloader, der es ermöglicht, neue Firmware-Images zu flashen. Zudem steuert MCU1 die Hauptlogik, die für die Ausführung aller spezifizierten Funktionen verantwortlich ist, wie das Auf- und Abschließen der Türen sowie das Öffnen der Fenster.
MCU2: Verfügt ebenfalls über einen Bootloader, um neue Firmware-Images zu flashen. Diese MCU ist für das Auslesen und Verarbeiten von Sensordaten zuständig und übermittelt die verarbeiteten Daten auf Anforderung an MCU1.
EEPROM: Dieser Speicherbaustein wird zur Speicherung von Konfigurationsparametern verwendet, beispielsweise zur Regelung der Fensterbewegungsgeschwindigkeit. Zudem speichern die Entwickler hier einen öffentlichen Schlüssel, der für den Update-Prozess genutzt wird.
NAND: Da das Türsteuergerät einen in der Tür integrierten Bildschirm ansteuert, werden einige Bildsequenzen in diesem externen Speicher abgelegt. Zudem dient der NAND-Speicher zur Speicherung der vorherigen Firmware von MCU1 und MCU2 im Rahmen eines Dual-Bank-Verfahrens.
RAM: Da der interne RAM nicht ausreicht, um während des Update-Prozesses die neue Firmware zwischenzuspeichern, wird ein externer RAM-Baustein eingesetzt.
Dieses Beispiel zeigt die verschiedenen Speicherarten und ihre spezifischen Rollen innerhalb der DCU, die für die korrekte Funktion und Sicherheit des Systems von entscheidender Bedeutung sind.
Im Folgenden werden die verschiedenen Ebenen dargestellt, auf denen, wie zuvor beschrieben, potenzielle Assets identifiziert werden können:
1. Item Definition
- Firmware MCU1
- Firmware MCU2
- Öffentlicher Schlüssel (Bootloader)
- Bildsequenzen (abhängig davon, ob Änderungen durch die Organisation zugelassen werden)
- Funktionen (z. B. Fenster öffnen, Fenster schließen)
- Konfigurationsparameter zur Einstellung der Fensteröffnungsgeschwindigkeit
2. Cyber Security Konzept
Angenommen, im Rahmen der detaillierten Spezifikation einer Maßnahme aus der Threat Assessment and Risk Analysis (TARA) stellt sich heraus, dass ein bestimmter öffentlicher Schlüssel zur Sicherstellung der Kommunikationsintegrität nicht identifiziert wurde. Zudem wird entdeckt, dass ein logisches Flag übersehen wurde, welches, wenn aktiviert, den Update-Prozess auf ein unsicheres Flashen umschaltet – eine Art Backdoor für Entwickler. Diese Beispiele sind projektspezifisch und dienen zur Veranschaulichung. In diesem Zusammenhang wurden die folgenden Assets identifiziert, die in die Gesamtliste aufgenommen werden müssen:
- Öffentlicher Schlüssel für SecOC
- Flag zur Umgehung des sicheren Update-Prozesses (Backdoor)
3. Threat Assessment and Risk Analysis (TARA)
Das Ergebnis der TARA sind Maßnahmen, die umgesetzt werden müssen, um die Assets abzusichern. Angenommen, eine dieser Maßnahmen ist die Implementierung einer sicheren Diagnosefunktion. Dabei könnte festgestellt werden, dass ein öffentlicher Schlüssel erforderlich ist, um eine sichere Kommunikation auf Fahrzeugebene zu gewährleisten. Das in diesem Zusammenhang identifizierte Asset wäre folgender:
- Öffentlicher Schlüssel für die sichere Diagnose
Dies ist lediglich ein Beispiel. Es ist durchaus möglich, dass der Bedarf an einem öffentlichen Schlüssel zu diesem Zeitpunkt noch nicht erkannt wird. In einem solchen Fall würde dieses Asset erst im Rahmen des Cyber Security Konzepts oder in der Software-Spezifikation identifiziert werden.
4. Software Specification / Software Development
Nach Erstellung des Cybersecurity-Konzepts muss in der Software-Domäne eine detailliertere Spezifikation erfolgen. Dabei könnte sich herausstellen, dass ein zusätzliches Flag spezifiziert wurde, das die Möglichkeit bietet, die sichere Diagnose zu deaktivieren. Darüber hinaus könnte der Software-Ingenieur feststellen, dass die Systemanforderungen vorsehen, ein vom Kunden vorgegebenes Datum sicher zu speichern und vor Manipulation zu schützen. Aus diesen Erkenntnissen lassen sich die folgenden Assets ableiten:
- Flag zur Deaktivierung der sicheren Diagnose
- Kundenspezifisches Datum
5. Vulnerability Management
- JTAG-Locking-Register
6. Customer Specification
In der heutigen Entwicklungsumgebung sind die Anzahl der vom Kunden bereitgestellten Spezifikationen erheblich gestiegen und kann bis zu 20.000 bis 30.000 Anforderungen umfassen. Diese große Menge an Anforderungen erschwert die Identifikation von Assets erheblich. Daher ist es essenziell, auf allen Ebenen der Produktentwicklung eine umfassende Sicherheitsbewusstseinsbildung zu fördern. Jede Ebene muss in der Lage sein, sicherheitsrelevante Anforderungen zu erkennen und das Cyber Security Team entsprechend zu informieren.
Ein Beispiel hierfür ist die Anforderung des Kunden nach Secure Boot, die im Cyber Security Konzept nicht berücksichtigt wurde, da sie in der Threat Assessment and Risk Analysis (TARA) nicht als notwendige Maßnahme identifiziert wurde. Trotz dieser Lücke im Cyber Security Konzept fordert der Kunde dennoch die Implementierung von Secure Boot. Daher ist es entscheidend, auch in diesem Fall die relevanten Assets zu identifizieren und abzusichern, selbst wenn Secure Boot nicht als Maßnahme eingestuft wurde. Im Kundenlastenheft konnte das folgende Asset identifiziert werden:
- Öffentlicher Schlüssel für Secure Boot
