UN R155/156, EU-Maschinenverordnung 2023/1230, IEC 62443, IEC 81001-5-1: Cybersecurity ist heute Pflicht in nahezu jeder Engineering-Domäne. VPATH AI unterstützt die drei Stufen des Cybersecurity-Engineerings nach ISO/SAE 21434 — TARA, Security Concept und Validierung — auf einer gemeinsamen, vernetzten Engineering-Datenbasis.
Cybersecurity-Engineering folgt einer klaren Logik: erst die Bedrohungs- und Risikoanalyse (TARA), dann die Ableitung eines Sicherheitskonzepts, dann die Planung der Verifikation. Jede Stufe baut auf der vorigen auf, und jede Stufe erzeugt eigene Artefakte mit eigenen Audit-Pflichten. Das Problem im Alltag ist nicht, dass die Methodik unklar wäre, sondern dass die Datenwelten der drei Stufen heute getrennt voneinander leben.
Eine Cybersecurity-Schwachstelle, die die Manipulation einer sicherheitsrelevanten Funktion erlaubt, ist gleichzeitig eine Safety-Verletzung. Die TARA muss deshalb mit der Safety-Analyse gekoppelt sein, das Security Concept mit dem Safety Concept — ohne gemeinsame Datenbasis kaum machbar.
Voraussetzung für eine wirksame KI-Unterstützung ist die gemeinsame Datenbasis, in der Architektur, Schnittstellen, Komponenten, Anforderungen, Safety-Analysen und Security-Artefakte verknüpft sind. Auf dieser Grundlage arbeiten drei Apps an den drei Stufen des Cybersecurity-Engineerings.
Architektur, Schnittstellen, Komponenten, Anforderungen, Safety-Analysen und Security-Artefakte werden im Product Knowledge Graph verknüpft. Alle drei Apps greifen auf dieselbe Datenbasis zu.
Assets, Bedrohungsszenarien, Attack Path Analysis und Risikobewertung nach ISO/SAE 21434 — verankert im Graphen, nicht als einmaliges Dokument.
Für jedes priorisierte Risiko wird die passende Schutzmaßnahme gewählt und als Verknüpfung zwischen Bedrohung, Maßnahme, Architekturkomponente und Security Requirement im Graphen verankert.
Aus Security Requirements und Concept entsteht das Verifikations- und Validierungskonzept. Die Ergebnisse fließen zurück in den Graphen und schließen den Cybersecurity-Lebenszyklus.
Liest Architektur, Funktionen, Komponenten und Datenflüsse aus dem Knowledge Graph, identifiziert schützenswerte Assets und generiert systematisch Bedrohungsszenarien (CIA-Schema). Attack Path Analysis und Risikobewertung priorisieren die Risiken, daraus entstehen Security Goals und Security Requirements.
Wählt für jedes Risiko die passende Schutzmaßnahme (Akzeptanz, Mitigation, Transfer, Vermeidung) und schlägt etablierte Maßnahmen vor: Hardening, Authentifizierung, Verschlüsselung, Secure Boot, signierte Updates, Netzwerksegmentierung. Konsistenzprüfung gegen das Safety Concept inklusive.
Leitet aus Security Requirements und Concept das Verifikations- und Validierungskonzept ab und schlägt je Anforderung die passende Methode vor: statische Analyse, Penetration Testing, Fuzz Testing, Side-Channel-Analyse, formale Verifikation. Ergebnisse fließen zurück in die TARA.
Was sich gegenüber einem klassischen Tool-Setup ändert, ist nicht die Methodik (sie bleibt ISO/SAE 21434-konform), sondern Konsistenz und Aktualität: Eine Architektur-Änderung propagiert durch den Graphen und zeigt, welche Bedrohungsszenarien, Anforderungen und Tests betroffen sind — ohne manuelle Synchronisation der drei Tools.
ISO/SAE 21434 ist der methodische Standard, UN R155 verlangt das Cybersecurity Management System, R156 das Software Update Management System. Ohne funktionierendes CSMS gibt es seit Juli 2024 keine neuen Typgenehmigungen. Die Argumentation läuft typischerweise gemeinsam mit ISO 26262.
Die EU-Maschinenverordnung 2023/1230 verlangt ab dem 20. Januar 2027 in Anhang III, Punkt 1.1.9 explizit den Schutz vor Manipulation („Korrumpierung") sicherheitsrelevanter Steuerungssoftware. Die TARA-Methodik aus dem Automotive-Bereich ist hier methodisch übertragbar.
IEC 81001-5-1 wandert in die Pflicht, gekoppelt mit der MDR und den FDA-Guidances zu Cybersecurity in Premarket Submissions. Methodisch ähnlich zur 21434, mit Schwerpunkt auf Post-Market Surveillance und Patient-Safety-Implikationen.
IEC 62443 ist der Standard und unterscheidet Sicherheitsniveaus von SL 1 (Schutz vor gelegentlichen Angriffen) bis SL 4 (Schutz vor staatlich unterstützten Angreifern). Die Methodik von TARA, Security Concept und Validierung passt sich entlang dieses Niveaus an.
Sobald die TARA mit der Safety-Analyse im selben Graphen sitzt, werden Konfliktpotenziale sichtbar, die in getrennten Tools verborgen geblieben wären. Eine Security-Maßnahme, die die Reaktionszeit eines sicherheitsrelevanten Steuergeräts verlängert, kann eine Safety-Anforderung verletzen. Eine Safety-Maßnahme, die einen sicheren Zustand erzwingt, kann als Cybersecurity-Angriffsvektor missbraucht werden (etwa Denial-of-Service über einen erzwungenen Safe State). Diese Konflikte zu identifizieren und aufzulösen ist genau der Wert, den eine gemeinsame Engineering-Datenbasis stiftet.
Wenn der Security Concept Designer eine Maßnahme vorschlägt, prüft die App im Graphen, ob sie mit den verbundenen Safety-Anforderungen kompatibel ist. Entsteht ein Konflikt, wird er sichtbar markiert — mit der Empfehlung, gemeinsam mit dem Safety-Team eine Lösung zu finden. Mehr zur methodischen Safety-Seite finden Sie auf der Safety-Analyse-Seite.
Cybersecurity-Engineering ist eine Disziplin, in der die Folgen einer Fehleinschätzung erst im Angriffsfall sichtbar werden, oft Monate oder Jahre später. Eine KI-generierte TARA, die zwei wichtige Bedrohungsszenarien übersehen hat, kann den Unterschied zwischen einem sicheren und einem kompromittierten Produkt ausmachen. Die drei Apps sind als Vorbereitungs- und Konsistenzwerkzeuge konzipiert, nicht als Entscheidungsinstanz: Sie generieren Hypothesen, prüfen Vollständigkeit gegen Bedrohungsbibliotheken, machen Konflikte sichtbar und schlagen Schutzmaßnahmen vor. Die fachliche Freigabe trifft das Cybersecurity-Team. Jede KI-generierte oder KI-veränderte Aussage trägt im Graphen ihre Provenance, was die Audit-Argumentation gegenüber Aufsichtsbehörden (KBA, Benannte Stelle, FDA) deutlich vereinfacht.
Ein sinnvoller Einstieg orientiert sich am tatsächlichen Druckpunkt: Ist UN R155 die nächste Hürde, beginnt der Pilot mit der TARA für ein konkretes Steuergerät. Erzeugt die EU-Maschinenverordnung den Druck, startet er mit der Cybersecurity-Argumentation für eine Maschine. Steht ein interner Reifegrad-Schritt an (etwa der Aufbau eines CSMS), beginnt er mit der Strukturierung des bestehenden TARA-Bestands.
In den ersten Wochen werden die relevanten Datenquellen angebunden, Architektur und Funktionen aus dem Knowledge Graph konsolidiert, und der TARA Generator liefert erste Bedrohungsszenarien für den ausgewählten Bereich.
In den folgenden Wochen entstehen Security Concept und Validierungsplan, das Team validiert die Vorschläge, und der Workflow läuft einmal vollständig durch — von der Bedrohung bis zum Test.
Erst danach erweitert sich der Einsatz auf weitere Funktionen, weitere Produkte und tiefere Automatisierung. Ein abgegrenzter Pilot liefert in der Regel innerhalb von sechs bis acht Wochen erste produktiv nutzbare Ergebnisse.
Security und Safety greifen ineinander. Wer FTA, Safety Concept und Safety-Verifikation methodisch sauber führen will, findet auf der Safety-Analyse-Seite die KI-gestützte Lösung, die auf demselben Product Knowledge Graph aufsetzt. Security- und Safety-Analyse arbeiten auf derselben Engineering Intelligence Platform.
Mehr zur Safety-AnalyseMethodisch deckt die Security-Analyse alle Normen ab, die auf der TARA-Logik aufbauen: ISO/SAE 21434 mit UN R155/156 für Automotive, EU 2023/1230 für Maschinenbau, IEC 62443 für industrielle Steuerung, IEC 81001-5-1 für Medizintechnik. Die Norm-Ontologien werden im Projekt-Setup hinterlegt; methodisch ist der Workflow identisch.
Beide Analysen laufen auf demselben Product Knowledge Graph, sodass TARA und Safety-Analyse, Security Concept und Safety Concept, Security Validation und Safety-Verifikation strukturell verknüpft sind. Konflikte zwischen Maßnahmen werden sichtbar, sobald sie entstehen. Mehr zur Safety-Methodik auf der Safety-Analyse-Seite.
Die App folgt der in 21434 definierten Drei-Stufen-Logik (Risk Assessment, Concept, Verification & Validation). Die einzelnen Schritte werden durch die KI vorbereitet, die fachliche Verantwortung bleibt beim Cybersecurity-Engineer. Damit sind die Voraussetzungen für eine TARA nach 21434 erfüllt.
Ja. Vorhandene TARAs (typischerweise als Excel-Tabellen oder dedizierte Tool-Exporte) werden in den Knowledge Graph importiert, ihre Bedrohungsszenarien werden mit der Architektur verknüpft, und die App schlägt anschließend gegebenenfalls ergänzende Bedrohungen aus der Bibliothek vor.
Das CSMS verlangt einen kontinuierlichen, nachweisbaren Cybersecurity-Lebenszyklus über die gesamte Fahrzeuglebensdauer. Die drei Apps liefern die methodische Datenbasis dafür: TARA bleibt aktuell, Security Concept ist mit der Implementierung verknüpft, Validierungsergebnisse fließen zurück. Die UN-R155-Audit-Argumentation läuft als Norm-Ontologie auf demselben Graph.
Ein abgegrenzter Pilot (ein Steuergerät oder eine Funktion, ein Team) liefert in der Regel innerhalb von sechs bis acht Wochen erste produktiv nutzbare Ergebnisse. Die Skalierung auf weitere Funktionen und Produkte erfolgt anschließend schrittweise.
Als Pilotkunde begleiten wir die Einführung von Anfang an und entwickeln die Lösung gemeinsam an Ihrem Use Case weiter.