Software-definierte Fahrzeuge sind heute vernetzte, langlebige informations-technische Systeme: Komplexe E/E-Systeme, Cloud/Backend-Verbindungen, Mobile-Apps und OTA-Update-Infrastruktur bilden zusammen das moderne Produkt „Fahrzeug“. Entsprechend erfordert die zugehörige Realisierung von Cybersicherheit (über den gesamten Lebenszyklus, darüber wird gleich noch zu sprechen sein) heute ein kontinuierliches Bedrohungs- und Risikomanagement. Damit das in komplexen Fahrzeugarchitekturen effektiv gelingt, müssen wir die branchenweit etablierte Methodik der Threat Analysis und Risk Assessment/TARA (gemäß ISO/SAE 21434) an einer zentralen Stelle neu denken. Genauer gesagt: Wir müssen über ihre vertikale Integration sprechen. Los geht’s.
Arne-Peter Berg
In klassischen Entwicklungsprojekten der Automobil- und Fahrzeugindustrie wird die TARA häufig je Komponente oder Domäne erstellt. In komplexen Architekturen (z. B. rund um Sensorfusion, Domänen-ECUs, Connectivity-Module, V2X, Backend-APIs) führt das erfahrungsgemäß zu einer strukturell-bedingten „intransparenten Risiko-Propagation“. Das bedeutet im Klartext: Schäden und Wahrscheinlichkeiten wandern nicht nachvollziehbar von der Subsystem-Ebene konsistent weiter nach oben (Fahrzeug/Service) und zurück (in konkrete Requirements).
So wirken Ergebnisse lokal (z.B. auf Zuliefererseite) zwar konsistent, sind systemisch aber unzureichend vergleichbar oder sogar unvollständig.
Lassen Sie uns versuchen die vielen Nebenschauplätze im stets angespannten Arbeitsverhältnis zwischen Fahrzeug-OEMs und Zulieferern kurz auszuklammern und die angesprochene Problematik zunächst nur methodisch betrachten.
Warum stößt die klassische TARA an ihre Grenzen?
Wie praktisch wäre es, wenn Cybersecurity-Risiko-Analysen/TARAs die Systeme, um die es letztendlich geht, wirklich verstehen? Und das sogar über Organisations- und Entwicklungsgrenzen hinweg? Bei aller Liebe zur Utilisierung von KI – hier setzt die gelebte Realität des Entwicklungsalltags bis heute scheinbar unüberwindbare Grenzen:
- Risiken werden in Subsystemen in sich zwar konsistent analysiert, können im Gesamtsystem aber nicht sauber wiederverwendet werden.
- OEM und Zulieferer müssen zwar Cyber-Risiken miteinander granular abstimmen, stehen dabei aber stets vor der Herausforderung, nicht alle technischen Details preisgeben zu können oder zu wollen (Stichwort: IP).
- Im Subsystem ja eigentlich bereits vollumfänglich vorgenommene Cyber-Risiko-Analysen lassen aufgrund der methodisch unstrukturierten Verzahnung der Analysen mit übergeordneten Systemen immense Doppel- und Mehrarbeit entstehen.
- Verschiedene Varianten eines Fahrzeugs sollen darüber hinaus ebenfalls effizient bewertet werden – mit dem (häufig zu simpel gedachten) Anspruch, die zugehörige TARA aber doch bitte nicht neu erfinden zu müssen.
Aber warum ist das so? Lassen Sie uns dafür kurz einen Schritt zurück machen. Zeit für eine ganze kurze Wiederauffrischung zur Theorie rund um die ISO/SAE 21434 und die TARA.
ISO/SAE 21434 und TARA: Die Damage Scenarios als Schlüssel für den Informationsaustausch
In der TARA-Methodik bilden die Damage Scenarios das zentrale Element, um die möglichen Folgen eines Cyberangriffs auf die zu analysierende Komponente (ein Subsystem, das gesamte System oder ein Fahrzeug an sich) zu beschreiben.
Ein Damage Scenario definiert also, was genau schiefgehen kann, wenn ein Angriff erfolgreich ist. Also wenn eine Schwachstelle ausgenutzt und eines der Sicherheitsziele (idR. Vertraulichkeit, Integrität oder Verfügbarkeit) des betroffenen Assets kompromittiert wird.
Dabei wird konkret untersucht, wie sich die Verletzung eines Sicherheitsziels auf betroffene Stakeholder (z.B. den Fahrer, den Fahrzeughersteller u.a.) auswirkt. Hier werden auch die im ISO/SAE 21434-Standard definierten Impact-Kategorien betrachtet (Safety, Financial, Operational, Privacy).
Oder noch einmal ganz präzise dargestellt: Das Damage Scenario übersetzt den Verlust einer Cybersecurity-Eigenschaft in konkret beschreibbaren Schaden an den Interessen der definierten Stakeholder – und liefert so eine Möglichkeit für eindeutigen Informationsaustausch für alle Beteiligten.
Diese bewusst knapp und präzise ausformulierten Damage-Szenarien dienen in der Cyberrisiko-Bewertungsarbeit als Herzstück für den Informationsaustausch: Cybersicherheitsverantwortliche, Entwicklungsingenieure, Projektleiter (u.a.) können auf eine gemeinsame normative Beschreibungsebene zugreifen.
Kurzer Exkurs: Wie entsteht ein Damage Scenario innerhalb der TARA?
Nur kurz hier die wichtigsten Schritte für die Vorgehensweise, wie ein Damage Scenario konkret entsteht, noch einmal vereinfacht dargestellt:
- Sogenannte Kandidaten-Assets (also zu schützende Bestandteile der Komponente) auswählen
- Stakeholder definieren
- Betroffene Cybersicherheitseigenschaften festlegen (neben Vertraulichkeit, Integrität und Verfügbarkeit sei ggf. ergänzt Authentizität)
- Die eintretende Schädigung für diese Stakeholder präzise beschreiben
Wichtig: Hierbei ist stets noch nichts über eine zugehörige Eintrittswahrscheinlichkeit gesagt, dies geschieht erst im späteren Schritt der TARA-Analyse.
Die Damage Scenarios dienen also als ein fundamentales Informationsdrehkreuz in der Arbeit an der TARA, bzw. entlang des gesamten Prozesses der Ausarbeitung der Risikobewertung.
Sie dienen als Grundlage für die Bewertung der Auswirkungen sowie für die Ableitung von zu realisierenden relevanten Schutzmechanismen innerhalb der zu betrachtenden Komponente.
Stimmig erarbeitete Damage Scenarios sichern eine saubere Abgrenzung und sollen die spätere Kommunikation über den erforderlichen Schutzbedarf schlank und reproduzierbar halten.
Wir halten also fest: Es sind die Damage-Scenarios, die dem methodischen Analyse-Werkzeug TARA dienen, eine gemeinsame Sprache rund um die konkreten Auswirkungen von eintretenden Bedrohungsszenarien über Team-, Funktions- und Organisationsgrenzen hinweg zu sprechen.
Tipp für Automotive Cybersecurity Praktiker: Vertiefen Sie Ihr Wissen zur TARA in Theorie und Praxis. Lernen Sie die Umsetzung Schritt für Schritt in geführten Walkthrough-Exercise-Videokursen – mit unserem beliebten ACP L2 „Advanced Engineering“ Videokurs (14 Stunden, 74 Videos)
- Learning Advice
Jetzt kommt das Problem: Fragmentierte TARAs in komplexen Systemen
Nun bietet dies bereits ausreichend Möglichkeiten, um mit einem einheitlichen Verständnis der potenziellen Cyberrisiken und deren Folgen (besonders in komplexen Fahrzeugentwicklungsprojekten) eine saubere Cyberrisiko-Bewertungsarbeit vornehmen zu können?
Nein.
Das Problem sind die voneinander isolierten Analysen.
Das sieht dann etwa so aus:
- Zulieferer A erstellt für sein Kamera-System eine TARA,
- Zulieferer B erstellt für sein Radar-System eine TARA,
- der OEM erstellt für sein ADAS-System oder gleich auf Fahrzeug-Ebene eine eigene TARA.
Dabei bleiben Risiken auf Ebene der Subsysteme „unten“ gefangen; Für System-TARAs sind die Subsysteme eine Black-Box. Es gilt Annahmen zu treffen, Multimodalitäten, Redundanzen (u.a.) sind nicht ganzheitlich bewertbar.
Konkret gesagt: Sowohl die Ursachen für ein Risiko und die Folgen, wie es sich auf verbundene Systeme oder Komponenten auswirkt, sind nicht transparent bzw. verständlich dokumentiert.
So entsteht eine besondere Schwierigkeit, den genauen Ursprung und die Auswirkungen von Risiken zu erkennen – eine gesamtheitlich konsistente Risikobewertung wird letztendlich strukturell behindert.
Wir sprechen in diesem Zusammenhang von intransparenter Risiko-Propagation, also der erschwerten Nachvollziehbarkeit, was letztendlich die korrekte Bestimmung von Risikowerten (bezogen auf Wirkung und Durchführbarkeit) beeinträchtigt.
Einführung einer neuen Cyber-Risiko-Arbeitsrealität: Vertikale TARA-Integration
Ein Lösungsansatz, der seit Jahren in der Branche methodisch diskutiert, aber bis dato in der Praxis (noch) nicht tool- und prozess-gestützt realisiert ist: die vertikale Verschachtelung der TARA. Also ein Ansatz, um Subsystem-Analysen systematisch in übergeordnete System-TARAs einzubetten. Ohne dabei alles stets doppelt bewerten zu müssen.
Die Idee dahinter: Den Detaillierungsgrad (und die damit verbundenen Ressourcenaufwände) bewusst zu reduzieren, ohne aber Informationen zu verlieren, die für Entscheidungen auf der Systemebene relevant sind.
Wie funktioniert eine Vertikale TARA-Integration?
Als vertikale TARA-Integration wird hier die Integration von TARA-Analysen bezeichnet, die einen durchgängigen Arbeitsfluss über mehrere Ebenen einer Systemhierarchie festlegt.
Beispielsweise: Komponente → Subsystem → Fahrzeug → Flotte/Backend.
Ziel ist es, dass je Ebene die TARA mit klaren Arbeitsergebnissen und Informationsweitergaben organisiert wird, sodass Schäden, Wahrscheinlichkeiten und Mitigations kohärent weitergereicht, konsolidiert und zurückgespielt werden.
Kurz eingeschoben: Bis heute verwenden weder die UN R155 noch die ISO/SAE 21434:2021 die Begrifflichkeit als technischen Fachbegriff – gleichzeitig fordern sie aber genau die lebenszyklische und arbeitsteilige Risikosteuerung, die eine solche Integration, bzw. Verschachtelung erforderlich machen.
Voraussetzung für eine vertikale Integration ist zunächst eine hierarchische Ebene, die den Ausgangspunkt für die Verschachtelung bildet. Einfach gedacht sowas wie:
- Subsysteme (z.B. LiDAR, Radar, Kamera)
- Systeme (z.B. ADAS-Funktionen)
- Gesamtfahrzeug
Kernidee der vertikalen TARA: Damage-Szenarien als Daten-Übergabepunkt
Bei der vertikalen TARA-Integration soll ein diszipliniertes Weiterreichen von Risikoerkenntnissen von der Komponentenebene bis ins Gesamtsystem realisiert werden – mit einem klaren Datenübergabepunkt: dem oben aufgezeigten Damage-Szenario.
So soll die fachliche Tiefe der Analysearbeit dort bleiben, wo sie hingehört (im Subsystem), während die Systemebene mit konsolidierten, vergleichbaren Bausteinen arbeitet.
Konkret heißt das:
- Ein Subsystem führt eine eigene TARA durch: Es identifiziert Werte, Angriffsoberflächen und modelliert Threat-Szenarien; aus diesen leitet es Damage-Szenarien mit Impact- und Feasibility-Bewertungen ab.
- Für jedes Damage-Szenario werden alle zugehörigen Angriffspfade intern aggregiert: Mehrere Pfade, die denselben schadhaften Zustand erzeugen, werden zusammengefasst; pfadspezifische Details bleiben intern, wesentliche Kontextmetadaten (z. B. nötige Privilegien, Annahmen) werden wiederum mitgeführt.
- Nur die Damage-Szenarien werden nach oben weitergegeben: Damit wird IP geschont, gleichzeitig erhält die nächsthöhere Ebene genau die Informationen, die für Priorisierung und Behandlung relevant sind – inklusive konsistenter IDs und Versionen.
- Das übergeordnete System nutzt diese Damage-Szenarien als Angriffsschritte, ohne die Subsystem-Details kennen zu müssen: Die System-/Fahrzeugebene bindet die gelieferten DS in eigene Risikopfade ein, mappt Feasibility auf die interne Skala und bewertet die Wirkung dort, wo sie entsteht (Fahrzeug, Flotte, Betrieb).
Diese Vorgehensweise reduziert Komplexität und erhöht gleichzeitig die erforderliche Konsistenz – und schafft nebenbei die dringend erforderliche bessere Nachvollziehbarkeit über Ebenen und Organisationsgrenzen hinweg sowie schnellere, weniger personenabhängige Entscheidungen.
Wie funktioniert die vertikale TARA? Ein Beispiel
Stellen wir uns ein reales Zusammenspiel vor: Ein LiDAR-Subsystem liefert Entfernungsinformationen an ein ADAS (Advanced Driver Assistance System). Damage-Szenarien sind hier der ideale Verknüpfungspunkt, weil sie den Ergebniszustand eines kompromittierten Subsystems beschreiben – unabhängig davon, wie der Angreifer dorthin gelangt ist.
Wir machen uns nochmal klar: Für das ADAS-System (bzw. die involvierte Security-Risiko-Analyse-Abteilung) gilt es, die hier gegebenen Risiken und die im eigenen System ggf. erforderlichen Schutzmechanismen zu bewerten – nicht aber, sich zwangsläufig mit Angriffspfaden bei den zugelieferten Subsystemen im Detail zu beschäftigen.
Also betrachten wir das Zusammenspiel mit einem genauen Blick auf die typischen Zustände des LiDAR-Subsystems → ADAS.
In seiner eigenen TARA verdichtet das LiDAR-Team seine Ergebnisse zu drei klaren Damage-Szenarien, jeweils mit Impact- und Feasibility-Bewertung:
- DS1: Ausfall (keine Distanzwerte)
- DS2: Falsche Distanzwerte (systematisch verfälscht)
- DS3: Verrauschte Daten (stark schwankende Qualität)
Zu jedem solchen Zustand existieren intern auf Seiten des LiDAR-Teams gegebenenfalls mehrere Angriffspfade (z. B. Firmware-Manipulation, Schnittstellenmissbrauch, Timing-Störungen). Diese Pfade werden für die Analyse im ADAS-System pro Damage-Szenario zusammengeführt, sodass die Systemebene nur das Wesentliche sieht:
- Was kann passieren? (beschriebener Schaden/Zustand)
- Wie wahrscheinlich ist dieser Zustand? (eine aggregierte Feasibility, also ein zusammengefasster Durchführbarkeitswert, der alle bekannten Pfade berücksichtigt)
Wichtig: Die zugehörigen Angriffspfade sind sachlogisch im Ergebnis ja bereits in der Feasibility des jeweiligen DS enthalten. Das Subsystem wahrt also seine Detail-IP, liefert aber kontextrelevante Metadaten mit (z. B. nötige Privilegien, betroffene Softwarestände, Annahmen), damit die Systemebene die Bewertung wiederum korrekt einordnen kann. (Hier sollte sich im Zweifel granular definieren lassen, welche „Meta-Informationen“ parallel zum DS mitgegeben werden sollen.)
Wie nutzt nun das System (ADAS) die Damage Scenarios?
Dem hier vorgestellten Ansatz der vertikalen TARA-Integration folgend, importiert das ADAS nun nur die Damage-Szenarien, nicht die im Subsystem intern modellierten Angriffspfade. So wird aus dem ursprünglichen Damage Scenario innerhalb der TARA des übergeordneten Systems ein Attack Step (nicht zu verwechseln mit einem Attack Path), also ein möglicher Angriff. Diese Vorgehensweise folgt letztlich der einfachen Logik, dass man sich auf der höheren Ebene in der Regel für den Impact und nicht dafür, wie man dorthin gelangt, interessiert.
Das bedeutet: Aus den erhaltenen Damage-Szenarien werden Systemangriffe bzw. Risiko-Ketten aufgebaut – ohne die Subsystem-Details im Detail kennen zu müssen. Im Beispiel wären das dann:
- Fehlende Kollisionswarnung (nutzt DS1 „Ausfall“) – wenn keine LiDAR-Werte ankommen, kann die Warnlogik ausfallen oder zu spät reagieren.
- Fehlklassifizierte Objekte (nutzt DS2 „Falsche Distanzwerte“) – wenn Distanzen systematisch zu klein/groß erscheinen, kippt die Objektfusion; Folge können Fehlbremsungen oder verpasste Bremsungen sein.
Wichtig darüber hinaus: Das Subsystem kann auf der eigenen Ebene munter Feasibilities definieren. Die vom LiDAR gelieferten, bereits aggregierten Feasibility-Werte werden auf die hausinterne Systemskala übertragen und im Kontext der Systemarchitektur sowie vorhandener Kontrollen interpretiert; sie werden nicht pauschal übernommen oder über Subsysteme addiert, sondern gezielt für die jeweiligen eigenen Risiko-Ketten herangezogen.
Die Impact-Bewertung erfolgt ganz bewusst nur auf System-/Flottenebene, weil erst dort ja die tatsächliche Wirkung entsteht (Fahrzustand, Geschwindigkeit, Verkehrsdichte oder Einsatzhäufigkeit im Feld bestimmen letztendlich, inwiefern derselbe Impact welche tatsächliche Beeinträchtigung darstellt.)
Dieses Vorgehen hält die Risikorechnung konsistent, vermeidet die erwähnte intransparente Risiko-Propagation (gleiche DS-ID unten wie oben) und ermöglicht, aus der System-Perspektive präzise Anforderungen und Controls abzuleiten, die gezielt an das LiDAR und angrenzende Funktionen zurückgespielt werden können.
Mehrwerte für die übergeordnete TARA durch vertikale TARA-Integration
Die hier vorgestellte Methodik der vertikalen Integration von TARAs ist überhaupt kein Hexenwerk, ja nicht mal eine Neuerfindung oder Weiterentwicklung der TARA.
Vielmehr stellt die vertikale TARA-Integration eine einfache, aber durchdachte Möglichkeit dar, bestehende Analysen effizient miteinander zu verbinden. Durch die gezeigte Weitergabe von Damage-Szenarien, die im übergeordneten System als Angriffsschritt weiterverwendet werden, bleiben Details dort, wo sie hingehören (beim Lieferanten/Subsystem), während erarbeitete Risiken nachvollziehbar über Grenzen „wandern“, weil derselbe Zustand (DS-ID) unten und oben identisch bleibt.
Ganz konkret ergeben sich durch die konsistente Anwendung des Prinzips der vertikalen TARA-Integration konkrete, messbare Mehrwerte:
- Skalierbarkeit & Variantenfähigkeit: Bestehende DS lassen sich wiederverwenden; Varianten fügen nur spezifische DS hinzu. Basisergebnisse bleiben stabil, Aufwand und Review-Schleifen schrumpfen, Releases werden planbarer.
- Bessere OEM–Zulieferer-Kollaboration bei IP-Schutz: Die Systemebene erhält die risikorelevanten Informationen (Impact, Feasibility, Gültigkeitsbereich), ohne dass interne Angriffsgraphen offengelegt werden. Das reduziert Reibung, beschleunigt Abstimmungen und stärkt Vertrauen.
- Entscheidungsfähigkeit & Priorisierung: DS sind kommunikativ: Ein „DS: unbegründete Notbremsung“ ist für Management und Technik gleichermaßen greifbar. Priorisierung über Domänen hinweg wird möglich, Budgetentscheidungen werden belastbarer – und schneller.
- Traceability über Ebenen und Lebenszyklus: Vom Systemrisiko zur Subsystem-Anforderung und zurück zur Wirksamkeits-Evidenz im Feld: Die Kette bleibt geschlossen. Audits adressieren damit nicht nur Dokumente, sondern nachweisbare Zusammenhänge.
- Schnelligkeit & Effizienz in der Umsetzung: Änderungen fokussieren auf Deltas. Neue Supplier-Releases oder Patches werden auf betroffene DS gemappt; Re-Bewertungen bleiben zielgenau statt flächig – ein fundamentaler Mehrwert auch bei neu aufgedeckten Schwachstellen mit Blick auf die Zusammenarbeiten der Cybersicherheit entlang des gesamten Produkt-Lebenszyklus.
- Unabhängigkeit von manuellen Doings und „manueller Willkür“: Die DS-Schnittstelle erzwingt ein Minimum an Metadaten (Vorbedingungen, Privilegien, Annahmen) und erlaubt wohldefinierte Mappings auf die Systemskala. Entscheidungen werden damit weniger team- oder personenabhängig.
- Audit-/Compliance-Fitness: DS lassen sich direkt mit betrieblichen Security Controls (z. B. OTA-Gates, Monitoring) verknüpfen. So entstehen prüfbare Nachweise für CSMS-Pflichten – nicht nur nichtssagende Prosa in der Analysearbeit.
- Methodische Anschlussfähigkeit an System-Modelle: Gleiche Zustände können an verschiedenen Stellen des Architektur- und Funktionsmodells verankert werden – ohne Modellhoheit aufzulösen. Das stärkt Konsistenz innerhalb von MBSE/Architekturarbeit.
Zusätzlich gewinnt die TARA auf Systemebene durch die vertikale Verzahnung operative Schärfe:
- Priorisierung dort, wo es zählt: Beispielsweise ein ADAS kann Systemangriffe sachlogisch intelligenter gegeneinander abwägen – etwa höhere Schwere bei „Fehlende Kollisionswarnung“ versus höhere Feasibility bei „Fehlklassifizierte Objekte“.
- Mehr Klarheit für die Ableitung von Maßnahmen: Aus der Systemanalyse fallen möglicherweise einfacher und besser argumentierbar gezielte Anforderungen an das Subsystem zurück, z. B.: Plausibilitätsprüfungen (Cross-Checks mit Kamera/Radar), Selbstdiagnosen (Detektion von Ausfall/Verrauschung im Feld) oder robuste Update-Kontrollen (um Pfade zu erschweren, die falsche Distanzwerte begünstigen).
- Handlungsfähigkeit erhöhen für die fortlaufende Cybersicherheit im Lebenszyklus: Im Fall von Incidents ermöglicht sich das Rescoring der DS in fortlaufenden Lebenszyklusphasen, bzw. auch im Betrieb; neue DS-Versionen propagieren zurück ins Modell und triggern – falls nötig – zusätzliche Controls. Die TARA bleibt endlich tatsächlich „lebendig“ statt statisch.
Vertikale TARA-Integration: Ausblick und Tool-Unterstützung
Unterm Strich entsteht durch die strukturierte Verschachtelung von TARA-Analysen ein abstrahierter, aber technisch valider Baukasten: Subsysteme liefern DS als einheitliche Sprache der Risiken, die Systemebene ordnet Wirkung und Priorität dort zu, wo sie entstehen (Fahrzeug, Flotte, Betrieb).
Komplexität sinkt, Konsistenz steigt, Entscheidungen können schneller und nachhaltiger getroffen werden – ohne die erforderliche technische Tiefe zu verlieren.
Genau diese Anschlussfähigkeit macht arbeitsteilige, variantenreiche Systeme und komplexe Architekturen aus Perspektive der Cyberrisiko-Analyse steuerbar und befähigt die übergeordnete TARA, ihren eigentlichen Zweck zu erfüllen: Risiken systemweit vergleichbar zu machen, zielgerichtet zu behandeln und im Lebenszyklus nachweisbar zu steuern.
Und gleichzeitig erhöht sie fundamental die Klarheit in komplexen Systemen und strukturiert die Zusammenarbeit zwischen Zulieferern und OEMs – eben ohne zusätzliche Komplexität zu erzeugen, da sie im bekannten Rahmen der Methodik bleibt.
- Wenn TARAs isoliert voneinander realisiert werden, können Cyber-Risiken in vielschichtigen Fahrzeugsystemen unsichtbar werden. Sie führen in der Analyse zu Doppel- und Mehraufwand.
- Das Prinzip der vertikalen TARA-Integrationen nutzt erarbeitete Damage-Szenarien von der Subsystem-TARA und gibt sie strukturiert an die übergeordnete System-TARA weiter.
- Dabei werden Damage-Szenarien als Attack step importiert. Lieferanten-IP wird geschützt. Feasibility kann auf die eigene Skala gemappt werden – so wird Impact dort bewertet, wo er sich auswirkt.
- Im Ergebnis kann die vertikale TARA-Integration die Aufwände für Cyber-Risiko-Analyse in komplexen Fahrzeugarchitekturen reduzieren. Varianten lassen sich schneller bewerten, die Nachverfolgbarkeit bleibt erhalten.
- Klassische Lösungsansätze (Excel, Legacy-Tools) bieten keine ausreichenden Möglichkeiten der vertikalen TARA-Verzahnung. Die CYMETRIS-Plattform gilt als erste TARA-Software, die dies intelligent ermöglicht.
- Key Learnings
Gibt es eine toolgestützte Lösung für die vertikale Verbindung von TARAs?
Ganz klar, die Nutzung von Excel für die Umsetzung der TARA oder der Gebrauch von nicht-zeitgemäßen Legacy-Tools (also derzeit alle am Markt geläufigen Software-Lösungen!) bieten keinerlei Funktionen, um eine vertikale TARA-Integration methodisch durchgängig zu ermöglichen.
Erst mit der neu entwickelten CYMETRIS Cyber Risiko Analyse / TARA Software-Plattform, die in diesem Jahr der Öffentlichkeit zugänglich gemacht wurde, kann die vertikale TARA-Integration jetzt erstmals softwaregestützt und über Organisationsgrenzen hinweg in der international eng verflochtenen Automobil- und Fahrzeugentwicklung realisiert werden.
Probieren Sie es aus.
