Wir müssen über die Item Definition sprechen – jenes Work Product der ISO/SAE 21434, das die Grundlage für alle Arbeiten im Cybersecurity Engineering für Automobilsysteme darstellt. Dafür werden wir etwas ausholen. Stellen Sie sich vor, Sie wollen ein Haus bauen. Aber ohne Grundriss und ohne Bauplan. Die Folge: Nichts passt zusammen. Rohre führen ins Nirgendwo, Fenster passen nicht in die Wände usw. Genau das passiert, wenn die Erstellung des Work Products Item Definition übersprungen oder falsch angegangen wird. Mit fatalen Folgen für die Cybersicherheit.
Jan-Peter von Hunnius
Die ordnungsgemäße Erarbeitung der Item Definition ist der Grundstein für die Cybersicherheit und die systematische Reduzierung von Cyber-Risiken in einem Entwicklungsprojekt. Dabei ist die Item Definition bei weitem nicht nur ein Dokument, das irgendwie erstellt werden muss. Vielmehr ist eine fundierte Item Definition eine Roadmap, ein Wörterbuch und eine Kristallkugel in einem.
Sie schafft die Voraussetzungen, um das zu entwickelnde System genau zu verstehen, Angriffsvektoren zu identifizieren und schließlich eine umfassende Bedrohungs- und Risikoanalyse (TARA) durchführen zu können. Wer an dieser kritischen Stelle bereits Abkürzungen sucht, muss mit schwerwiegenden Konsequenzen rechnen.
Im Folgenden soll daher näher erläutert werden, warum eine gut strukturierte Item Definition so wichtig ist und welche Rolle sie im Gesamtbild der Cybersicherheit von Fahrzeugen spielt:
- um unbemerkte Sicherheitsrisiken zu vermeiden,
- um sicherzustellen, dass sich Einfallstore für Angriffe und Angriffspunkte nicht (überraschend) vergrößern
- und dass Schutzmechanismen der Cybersicherheit proaktiv (und nicht reaktiv) implementiert werden.
Was ist die Item Definition entlang der ISO/SAE 21434?
Im Wesentlichen beschreibt die Item Definition das System, das Sie entwickeln wollen. Konkret werden dabei folgende Inhalte ausgearbeitet:
- Grenzen und Schnittstellen (Input und Output): Was geht in das System ein, wie werden Daten intern verarbeitet, was geht aus dem System heraus und wie interagiert das System mit seiner Umgebung?
- Funktionen und Architektur: Wie ist das System aufgebaut, was macht es genau und wie interagieren die Komponenten des Systems miteinander?
- Annahmen und Einschränkungen: Nach welchen Regeln agiert das System und welche Einschränkungen, unter denen es arbeitet, kommen zum Tragen?
Stellen Sie sich diese strukturierte Ausarbeitung von Antworten wie eine hochauflösende Karte Ihres Systems vor. Ohne diese granulare Karte sind alle nachgelagerten Prozesse der Risikominimierung, wie z.B. TARA und die bedarfsgerechte Entwicklung von Cybersicherheitskonzepten, nichts anderes als der Versuch, ohne Navigation im Nebel zu navigieren.
Ohne eine angemessene Definition des Items arbeiten Sicherheitsanalysten und Cybersecurity-Spezialisten mit unzureichendem Wissen über das System. Dies macht es faktisch unmöglich, alle kritischen Angriffsmöglichkeiten und Sicherheitsrisiken und deren mögliche Konsequenzen angemessen in Betracht zu ziehen.
Es ist daher nicht verwunderlich, dass die ISO/SAE 21434, der weltweit führende Standard für Cybersecurity in der Automobilindustrie, die sorgfältige Erarbeitung des Work Products der Item Definition fordert, um den Grundstein für eine umfassende Cybersicherheit zu legen.
Deep Dive in die Item Definition der ISO/SAE 21434: Was beschreibt die Item Definition genau?
Okay, schauen wir uns nun genauer an was die Item Definition da eigentlich beschreibt.
Grenzen und Schnittstellen
Die Grenzen eines Items definieren, womit genau das Item interagiert (Input/Output) und wo sein Wirkungsbereich endet. Input können Sensordaten, Nachrichten von anderen Systemen, aber auch Software-Updates sein, die over-the-air geliefert werden. Zum Output gehören z. B. Aktuatorsignale, die die Lenkung steuern, oder Kommunikationsmeldungen, die an andere elektronische Steuergeräte (ECUs) gesendet werden.
Die Definition der Grenzen eines Items umfasst auch die Identifizierung der physischen und logischen Zugangspunkte, einschließlich Diagnoseschnittstellen wie JTAG, Netzwerkschnittstellen (CAN, Ethernet, LIN, I2C, SPI usw.) und des internen Datenflusses zwischen Softwarekomponenten.
Insbesondere das Übersehen interner Schnittstellen ist ein häufiger (und folgenschwerer) Fehler, da diese zu Einfallstoren für Cyber-Angriffe werden können.
Fehlerhafte Konfigurationen an den Systemgrenzen werden häufig von Angreifern ausgenutzt, um sich unberechtigten Zugang zu verschaffen.
Ein ungeschützter Diagnoseport könnte es einem Angreifer beispielsweise ermöglichen, die Authentifizierung zu umgehen, schädliche Firmware einzuschleusen und sogar das sicherheitskritische Fahrzeugverhalten zu verändern, z. B. Bremssysteme abzuschalten oder die Geschwindigkeitsregelung zu manipulieren.
Das Verständnis der Grenzen und Schnittstellen ist daher entscheidend, um später Bedrohungen und mögliche Angriffspfade in der TARA vollständig und korrekt identifizieren zu können.
Funktionen und Architektur
Die Funktionen eines Items definieren seinen beabsichtigten Zweck, während die Architektur beschreibt, wie diese Funktionen im System implementiert werden.
Eine sorgfältig ausgearbeitete und dokumentierte Item Definition beschreibt sowohl primäre als auch sekundäre Funktionen (z. B. Diagnose) und erfasst, wie das Item mit anderen Komponenten im Fahrzeug interagiert und ob es unter verschiedenen Bedingungen unterschiedlich funktioniert, z. B. unter normalen Fahrbedingungen im Vergleich zu Notfall- oder Diagnoseszenarien.
Fehlerzustände und Rückfallmechanismen werden ebenfalls berücksichtigt, um sicherzustellen, dass das Item im Falle eines Ausfalls ein gewisses Maß an Funktionalität und Sicherheit beibehält.
Ein genaues Verständnis der Betriebszustände des Items, wie z. B. Start, Normalbetrieb, ausfallsicherer Modus und Abschaltung, hilft bei der Identifizierung von Schwachstellen in jeder dieser Phasen.
Beispielsweise ist die Bootloader-Phase aufgrund nicht initialisierter Sicherheitsmechanismen besonders anfällig. Angreifer könnten außerdem auch den ausfallsicheren Modus manipulieren, um kritische Sicherheitsfunktionen zu deaktivieren, z.B. die Aktivierung eines Notbremssystems zu verhindern oder eine elektrische Servolenkung in einen nicht ansprechbaren Zustand zu versetzen.
Um potenzielle Schwachstellen und Angriffspfade später systematisch identifizieren zu können, ist es wichtig, genau zu verstehen, wie Informationen und Daten zwischen den einzelnen Komponenten fließen.
Neben der Definition der Systemfunktionen und der Systemarchitektur muss in der Item Definition besonderes Augenmerk auf die Datenflüsse sicherheitskritischer Daten gelegt werden.
Bestimmte Datentypen sind inhärent sicherheitskritisch, da sie für unbefugtes Tracking, Datenschutzverletzungen oder Identitätsdiebstahl ausgenutzt werden können.
Im Gegensatz zu Keys für die Verschlüsselung, die immer explizit geschützt werden, bleiben Betriebsdaten wie Standortverlauf, Fahrverhalten oder Fahrzeugtelemetrie oft ungeschützt, sofern sie nicht frühzeitig als besonders schützenswerte Assets identifiziert werden.
Diese Datentypen werden häufig erst innerhalb der TARA zu schützenswerten Assets, die Schutzmechanismen wie Anonymisierung, Verschlüsselung oder strenge Richtlinien für die Zugriffskontrolle erfordern.
Annahmen und Einschränkungen
Jede Item Definition basiert auf bestimmten Annahmen und muss innerhalb vordefinierter Einschränkungen funktionieren. Annahmen sollten explizit gemacht werden, um Fehlinterpretationen und fehlerhafte Cybersicherheitsplanung zu vermeiden.
Annahmen in Bezug auf die Umgebung (“Environmental assumptions”) können die erwartete Exposition gegenüber physischer Manipulation beinhalten.
Annahmen in Bezug auf den Betrieb (“Operational assumptions”) können sich darauf beziehen, ob das Element immer Zugriff auf sichere Firmware-Updates hat oder ob davon ausgegangen wird, dass es nur mit authentifizierten Komponenten interagiert.
Auch hier kann bereits regulatorisch eingewirkt werden. So kann die Einhaltung von Standards wie ISO/SAE 21434, ISO 24089 und UN R155/R156 verpflichtend sein.
Auch physikalische Restriktionen wie Leistungsbegrenzungen und die Position im Fahrzeug können die Cybersicherheit grundlegend beeinflussen, indem sie vorgeben, welche Sicherheitsmechanismen notwendig oder überhaupt möglich sind.
Beispielsweise kann bei Steuergeräten mit geringer Rechenleistung eine Verschlüsselung der Firmware aufgrund von Leistungsbeschränkungen nicht praktikabel sein.
Wenn die Annahmen und Einschränkungen bezüglich eines Items in der Item Definition nicht korrekt definiert sind, könnten Ingenieure davon ausgehen, dass Firmware- und Nachrichtenverschlüsselung verfügbar sind, obwohl dies tatsächlich nicht der Fall ist. Dies kann zu falschen Risikobewertungen und letztendlich zu entsprechend ungeschützten sensiblen Daten führen.
Die sorgfältige Definition von Annahmen und Einschränkungen stellt sicher, dass Cybersicherheits-Risikobewertungen auf realistischen Erwartungen und nicht auf theoretischen Möglichkeiten basieren.
Werden diese Faktoren außer Acht gelassen, kann dies schnell zu einer falschen Bedrohungsmodellierung und unwirksamen Cybersicherheitsmaßnahmen führen.
Wer macht die Item Definition gemäß ISO/SAE 21434? + Wer definiert das Item und wann?
Die Verantwortung für die Definition des Items variiert je nach Ebene der Automobilzulieferkette und Phase des Produktlebenszyklus. In der Praxis tragen verschiedene Akteure zu unterschiedlichen Zeitpunkten zur Definition von Items bei, um sicherzustellen, dass alle relevanten Aspekte berücksichtigt werden.
In der Konzept- und frühen Entwicklungsphase definieren OEMs Items auf Systemebene, wie z. B. ein Fahrerassistenzsystem (ADAS), ein Infotainmentsystem oder ein Antriebsstrangsteuerungsmodul.
Die Aufgabe des OEM besteht darin, sicherzustellen, dass die Item Definition mit der Gesamtarchitektur des Fahrzeugs, den funktionalen Anforderungen und den Cybersicherheitsrichtlinien übereinstimmt.
In dieser Phase arbeiten funktionsübergreifende Teams, darunter Systemingenieure, Cybersicherheitsspezialisten, Sicherheitsexperten (und im Idealfall Teams für die Einhaltung von Vorschriften und Industriestandards!) eng zusammen, um sicherzustellen, dass die Item Definition vollständig und konsistent ist.
Im weiteren Verlauf der Entwicklung übernehmen Tier 1-Lieferanten die Verantwortung für die Definition von Items auf Subsystemebene, wie z.B. ein AEB-Modul (Autonomous Emergency Braking) oder ein elektrisches Servolenkungssystem.
Tier-1-Lieferanten stellen sicher, dass die Item Definition den Anforderungen des OEM entspricht und dass alle funktionalen und sicherheitsrelevanten Aspekte auf Komponentenebene konsistent integriert sind.
Sie arbeiten eng mit Cybersicherheitsexperten zusammen, um potenzielle Bedrohungen zu bewerten und Annahmen und Einschränkungen zu dokumentieren, um die spätere Umsetzung der TARA zu erleichtern.
Tier-2-Zulieferer und Komponentenhersteller definieren typischerweise spezifische Hardware- und Softwarekomponenten wie Sensoren, elektronische Steuergeräte, Aktoren oder Netzwerkkommunikationsmodule.
Ihr Hauptaugenmerk liegt darauf sicherzustellen, dass ihre Komponenten die Cybersicherheitsanforderungen der Tier-1- und OEM-Kunden erfüllen.
Tier-2-Zulieferer dokumentieren auch potenzielle Sicherheitseinschränkungen (z. B. die bereits erwähnten Leistungseinschränkungen, kryptografische Fähigkeiten und Software-Updatemechanismen), um die Einhaltung bewährter Cybersicherheitspraktiken zu gewährleisten.
Item Definition: Safety und Security?
Obwohl sich Safety- und Security-Aspekte häufig überschneiden, werden sie traditionell von voneinander unabhängigen Teams bearbeitet.
Die Integration von Safety und Security in eine einheitliche Item Definition erfordert ein hohes Maß an Koordination zwischen Sicherheitsingenieuren, Cybersicherheitsteams und Compliance-Experten.
Dieser Koordinationsaufwand zahlt sich in der Regel dahingehend aus, dass sichergestellt wird, dass Cybersicherheitsrisiken entlang der funktionalen Bedrohungen berücksichtigt werden, was in der Regel zu einem widerstandsfähigeren Systemdesign führt.
Item Definition: Aus dem Auge aus dem Sinn?
Wichtig zu verstehen: Die Item Definition ist kein einmaliges Dokument. Sie muss sich während des gesamten Fahrzeuglebenszyklus weiterentwickeln, um Systemaktualisierungen, Sicherheitspatches und gegebenenfalls Änderungen der Compliance-Erforderlichkeiten zu berücksichtigen.
Wenn neue Bedrohungen entstehen, sich Fahrzeugkonfigurationen ändern oder sich Cybersicherheitsstandards weiterentwickeln, muss die Item Definition überarbeitet werden. Nur so kann sichergestellt werden, dass sie weiterhin die erforderliche Relevanz ist.
Konkret gilt es die Item Definition anzufassen in mindestens diesen Fällen:
- Während der Entwicklung: Wenn sich Systemanforderungen, Architektur oder Funktionsdesign ändern, muss die Item Definition aktualisiert werden, um neue Sicherheitsaspekte und Abhängigkeiten zu berücksichtigen.
- Software-Updates und Patches: Bei jedem Firmware- oder Software-Update sollte die Item Definition neu bewertet werden, um mögliche neue Schwachstellen oder Änderungen im Systemverhalten zu berücksichtigen.
- Änderungen der Regelkonformität: Wenn neue rechtlich verbindliche oder branchenspezifische Regelwerke (z.B. UN R155, ISO/SAE 21434, ISO 24089) neue Sicherheitsanforderungen einführen, muss die Item Definition überarbeitet werden, um die Anforderungen von Regulierungen und Industriestandards an eine “State-of-the-Art”-Entwicklung weiterhin zu erfüllen.
- Fahrzeugplattform-Integration: Wenn ein Item in mehrere Fahrzeugplattformen mit unterschiedlichen Architekturen integriert wird, muss die Item Definition unterschiedliche Betriebsumgebungen, potenzielle neue Schnittstellen und unterschiedliche Angriffsflächen berücksichtigen.
- Reaktion auf Sicherheitsvorfälle / Incident Response: Wenn in der Post-Production-Phase (neue) Schwachstellen entdeckt werden, können Aktualisierungen der Item Definition den beteiligten Cybersicherheitsteams helfen, die Auswirkungen zu bewerten und geeignete Gegenmaßnahmen zu bestimmen.
Durch die Festlegung von Verantwortlichkeiten in jeder Phase und die kontinuierliche Aktualisierung der Item Definition als dynamisches Dokument stellen Automobil- und Fahrzeugunternehmen sicher, dass sie Cybersicherheit proaktiv und nicht reaktiv managen.
Dieser strukturierte Ansatz reduziert nicht nur proaktiv Sicherheitsrisiken, sondern unterstützt auch die Einhaltung sich entwickelnder Industriestandards und kann – organisatorisch sauber strukturiert – eine vorteilhafte Positionierung von ordnungsgemäßer Cybersicherheit als Business-Treiber initiieren.
Weiter im Prozess: Warum ist die Item Definition so wichtig für TARA?
Im Prozess der TARA-Methodik geht es darum, Bedrohungen und mögliche Schadensszenarien zu identifizieren, Risiken zu bewerten und Maßnahmen zur Schadensbegrenzung festzulegen.
Eigentlich logisch: Dazu braucht man ein klares Verständnis des betrachteten Systems. Eben mit der Item Definition. Der Zusammenhang ist also offensichtlich: Eine unzureichend ausgearbeitete Item Definition führt zu fehlerhaften Risikobewertungen innerhalb der TARA.
Wird z.B. ein Input übersehen, kann eine ganze Kategorie von Angriffsvektoren unentdeckt bleiben, wodurch Schwachstellen nicht behoben werden.
Wird beispielsweise die Wireless-Fähigkeit eines Steuergerätes nicht in der Item Definition erfasst, kann es passieren, dass Remote-Angriffsvektoren in der TARA komplett übersehen werden. Solche Versäumnisse können letztendlich einen Einstiegspunkt schaffen, über den Angreifer ungesicherte Kanäle ausnutzen, die Kontrolle über ein Steuergerät erlangen und so einen massiven Angriff auf das interne Netzwerk eines Fahrzeugs durchführen können.
Die Bedeutung der Inputs in der Item Definition
Eine Item Definition sollte, wie bereits erwähnt, die Inputs aus dem Umfeld und die internen Schnittstellen innerhalb des Systems genau auflisten. Zur Veranschaulichung seien in diesem Zusammenhang mögliche Einstiegspunkte für Angreifer genannt:
- In einem ADAS-System können die Inputs Kamera- und Radarsignaldaten umfassen. Beide können bei unzureichender Absicherung einen potenziellen Angriffsvektor darstellen. Die interne Kommunikation zwischen den Komponenten erfolgt über Ethernet? Ein weiteres mögliches Einfallstor für Angriffe.
- In jedem Steuergerät kann ein physikalischer Diagnose-Port Firmware-Updates ermöglichen. Ohne entsprechende Annahmen und Sicherheitsmaßnahmen wird dieser Port zum Einfallstor für Angreifer.
- Die meisten elektronischen Steuergeräte kommunizieren über CAN, was diesen Kommunikationskanal zu einem Hauptziel für Angreifer macht. Ohne geeignete Sicherheitsmechanismen können Angreifer bösartige CAN-Nachrichten einschleusen, um Sicherheitsfunktionen zu deaktivieren, Aktoren zu steuern oder sogar kritische Fahrzeugfunktionen abzuschalten.
- Der Flash-Speicher eines elektronischen Steuergeräts kann über eine SPI-Leitung mit dem Mikrocontroller verbunden sein. Diese Leitung kann von einem Angreifer abgefangen werden, um die Software während der Übertragung oder im Flash-Speicher auszulesen oder sogar zu verändern.
Die Bedeutung der Outputs in der Item Definition und Auswirkungen auf Fahrzeugebene
Die Outputs eines Items – seien es Befehle an Aktoren oder Daten, die an andere Steuergeräte gesendet werden – können in der Praxis schwerwiegende Auswirkungen auf die Cybersicherheit haben. Eine Schwachstelle in einem einzelnen Item kann eine ganze Kaskade im Fahrzeug auslösen:
- Ein kompromittiertes ADAS-System könnte falsche Befehle senden, die zu Lenk- oder Bremsfehlern führen.
- Ein Airbag-Steuergerät könnte bei einem Unfall die Airbags nicht auslösen, was direkte Auswirkungen auf die physische Sicherheit („Safety“) der Insassen hätte. Oder, vielleicht noch gefährlicher, ein Airbag könnte ohne Unfall fälschlicherweise ausgelöst werden und dem Fahrer bei hohen Geschwindigkeiten die Sicht nehmen.
Wie bildet die Item Definition die Grundlage für TARA-Methodik?
Wie bereits eingangs erwähnt, spielt die Item Definition als Grundlage für die Umsetzung der TARA-Methodik nach ISO/SAE 21434 und damit letztlich für die Cybersicherheit im gesamten Lebenszyklus des Items und des Fahrzeugs eine entscheidende Rolle.
Nachfolgend soll eine visuelle Darstellung zeigen, wie die verschiedenen Bestandteile und Elemente des Work Product Item Definition mit denen der TARA verbunden sind:
Die Funktionen und Datenströme der Item Definition sind in der Regel die Hauptkandidaten für die Assets, die in TARA zu untersuchenden Objekte. Dabei ist zu beachten: In einigen Fällen müssen auch Daten explizit vor Cybersicherheitsbedrohungen geschützt und somit als Assets behandelt werden, insbesondere wenn es sich um personenbezogene Daten (PII) handelt.
Wie bereits erwähnt, stellen die Inputs und die internen Schnittstellen des Items in der Regel die Hauptangriffsvektoren dar. Dementsprechend werden sie für die Analyse der Bedrohungs- und Angriffspfade im TARA-Prozess verwendet. (Lese-Tipp: Risikobewertungen zur Cybersicherheit in der Fahrzeugentwicklung neu denken)
Die Outputs der Item Definition bilden wiederum die Grundlage, um zu verdeutlichen, inwieweit ein Angreifer bzw. eine ausgenutzte Schwachstelle dem Item bzw. dem Fahrzeug welchen Schaden zufügen kann. Für die Item Definition gilt also: Die Outputs werden zur Hauptquelle für mögliche Schadensszenarien.
Ein weiterer Blick gilt den Annahmen („Assumptions“). Die in der Item Definition getroffenen Annahmen müssen bei der TARA-Entwicklung berücksichtigt werden, mit besonderer Relevanz für die Out-of-Context-Entwicklungen.
Die Herausforderung der „Out-of-Context“-Entwicklungen
Betrachten wir nun die „Out-of-Context“-Elemente aus Sicht der Item-Definition. Dabei handelt es sich um Komponenten, die ohne Berücksichtigung eines bestimmten Fahrzeugs oder einer bestimmten Betriebsumgebung entwickelt wurden. Obwohl dieser Ansatz Flexibilität bietet, bringt er auch neue Probleme mit sich: die Notwendigkeit, spezifische Annahmen zu treffen.
Aber was bedeutet das? Konkret wird beispielsweise ein Bauteil entwickelt, das in Zukunft in verschiedenen Fahrzeugen oder Fahrzeugplattformen zum Einsatz kommen soll. Dementsprechend können nicht alle Bedingungen im Vorhinein konkretisiert werden, Annahmen werden notwendig.
Arbeitet man hier „Out-of-Context“, ist man gezwungen, sich auf Annahmen zu verlassen. Zum Beispiel:
- Die Umgebung: Wird das Item in einem PKW oder in einem LKW verwendet? In der Stadt oder im Gelände? ADAS-System oder Wechselrichter für einen elektrischen Antriebsstrang? Wie ist es im Fahrzeug geschützt?
- Schnittstellen: Mit welchen anderen Systemen wird es interagieren? Sind diese Systeme sicher?
- Durchführbarkeit von Angriffen: Ist die Komponente in ihrer Betriebsumgebung zugänglich?
Diese Annahmen sind keine willkürlichen Platzhalter. Vielmehr bilden sie das gesamte Rückgrat der Cyber-Sicherheitsstrategie. Werden an dieser kritischen Stelle falsche Annahmen getroffen, wird die TARA fehlerhaft und die Risikoanalyse und die Bewertung möglicher Schäden werden weitgehend nutzlos.
Als Beispiel sei ein Airbag-Steuergerät genannt, von dem angenommen wird, dass es in einem manipulationssicheren Gehäuse eingebaut und nur von innen zugänglich ist. Wenn diese Annahme nicht zutrifft, könnte das Gerät anfällig für physische Angriffe sein. Dies würde viele Angriffe wesentlich einfacher machen, als es die zuvor auf Basis der Annahmen erstellte TARA vermuten lässt.
Ohne eine solide Item-Definition, die diese Art von Annahmen dokumentiert, wird es nahezu unmöglich, Bedrohungen in TARA vollständig und genau zu identifizieren.
Umgekehrt ist es bei der Entwicklung einer Plattform ebenso notwendig, die Kunden, die ein Bauteil später nutzen sollen, bestmöglich über die getroffenen Annahmen zu informieren. Andernfalls kann es passieren, dass eine Komponente unter völlig anderen Bedingungen eingesetzt wird (z.B. kann die physische Lage im Fahrzeug ganz anders sein als vom Hersteller angenommen), so dass die Sicherheitsanalysen (und Cybersicherheitsanforderungen), die im Vorfeld für die Plattform erstellt wurden, gar nicht mehr zur Praxis passen.
Wichtig ist auch: Die getroffenen Annahmen müssen auch außerhalb der Item Definition nachvollzogen werden können, z.B. in einem dedizierten Cybersecurity Manual. (In Bezug auf das Beispiel etwa formuliert: Bitte geschützt im Fahrzeuginneren verbauen).
In der Praxis üblich: Ein ISO/SAE 21434-konformes Item Definition Template nutzen
Zunächst einmal: Hut ab! Gut, dass Sie bis hierher gelesen haben. Sie werden zustimmen: Eine korrekte Item-Definition erscheint komplex und durchaus aufwändig. Mit dieser Einschätzung sind Sie nicht allein. Die Erstellung einer umfassenden Item-Definition erfordert Zeit, Fachwissen und eine systematische Vorgehensweise.
In der Praxis der Fahrzeugentwicklung ist es daher nicht unüblich, auf ISO/SAE 21434 Templates zurückzugreifen, um mit Hilfe einer vorbereiteten Vorlage eine eigene Item Definition zu erstellen, die zum einen vollständig und konsistent ist und zum anderen den Anforderungen der ISO/SAE 21434 entspricht.
Das ISO/SAE 21434:2021 Item Definition Template der CYEQT Knowledge Base wurde von Cybersicherheitsexperten mit jahrelanger Erfahrung in weltweiten OEM- und Tier-X-Entwicklungsprojekten entwickelt und entspricht zu 100% den Anforderungen der ISO/SAE 21434. Wesentliche Vorteile des Templates auf einen Blick:
- Geführte Abschnitte: Von Input und Output bis hin zu Annahmen und Betriebsumgebungen wird jedes kritische Detail abgedeckt.
- Praktische Checkliste: Von internen Schnittstellen bis zu bekannten Schwachstellen wird nichts übersehen.
- Effizienz: Sparen Sie Zeit und reduzieren Sie das Fehlerrisiko durch ein strukturiertes Format.
Zusammengefasst: Effektive Fahrzeug-Cybersicherheit beginnt mit der Item Definition
Lassen Sie sich nicht von der schieren Menge an Work Products und Ausarbeitungen der ISO/SAE 21434 (u.a.) verunsichern: Die Item Definition ist nicht einfach ein weiteres Dokument. Sie ist stets die erste Verteidigungslinie in Sachen Cyber-Sicherheit für jedes Entwicklungsprojekt.
Die Item Definition schließt die Lücke zwischen dem Verständnis eines gegebenen Systems und dem tatsächlich erforderlichen Schutz vor Bedrohungen für genau dieses System.
Sie zu überspringen oder nur halbherzig anzugehen, ist wie ein Haus auf Sand zu bauen: Es mag eine Weile halten, aber irgendwann werden die Risse durch das wackelige Fundament deutlich sichtbar.
Die klare Empfehlung für die Praxis lautet daher: Nehmen Sie sich die Zeit, die Item-Definition richtig, vollständig und korrekt vorzunehmen. Denn in der Welt der Automotive Cybersecurity sollte es keinen Raum für Spekulationen geben.
