Forschungsfeld · Product & OT Security
Sicherheit, die im Produkt steckt – vom Steuergerät bis zum Medizinprodukt
Vernetzte Fahrzeuge, Industriesteuerungen, Medizinprodukte und KI-Geräte bleiben lange im Feld. Vami Research untersucht, wie sich ihre Sicherheit über den gesamten Lebenszyklus nachweisen lässt – von der TARA mit der Automotive Threat Matrix über IEC 62443 und den Cyber Resilience Act bis zur Instandhaltung vernetzter Medizinprodukte und zur KI im Gerät.
- Automotive Threat Matrix
- ISO/SAE 21434
- IEC 62443
- CRA-Meldepflicht
- MDR & IEC 81001-5-1
- KI im Produkt
- TISAX
- Deep Dives
- 10
- Whitepaper
- 3
- Lösungen
- 3
Wenn Software im Produkt steckt, wird Sicherheit zur Produkteigenschaft
Product Security schützt nicht die eigene IT, sondern das Produkt im Feld – oft mit physischem Zugriff durch Angreifer und über Laufzeiten, die übliche IT-Supportzyklen deutlich überschreiten. Eine Schwachstelle betrifft die gesamte installierte Basis und kann Safety-Folgen, Rückrufe oder den Verlust der Typgenehmigung nach sich ziehen. Die Verantwortung wandert damit vom IT-Betrieb in die Produktentwicklung.
Die Regulierung zieht nach: Seit dem 7. Juli 2024 braucht jedes neue Fahrzeug der Klassen M, N und O in der EU eine Cybersecurity-Typgenehmigung nach UN R155, seit dem 1. August 2025 gelten Cybersicherheitsanforderungen für internetfähige Funkanlagen, seit dem 11. September 2026 die Meldepflichten des Cyber Resilience Act. Ab dem 20. Januar 2027 stellt die Maschinenverordnung erstmals verbindliche Cybersecurity-Anforderungen an Maschinen. Medizinprodukte regelt weiterhin die MDR – der CRA nimmt sie aus.
Mit KI im Gerät kommt eine neue Dimension hinzu: Planer, Skills und Tool-Aufrufe werden zu Befehlen an Motoren, Schlösser oder Ventile. Vami Research verbindet deshalb etablierte Methoden wie TARA, Zonenmodelle und IoT-Pentests mit Bedrohungsmodellen für agentische KI und veröffentlicht die Ergebnisse als Deep Dives, Whitepaper und Fachbeiträge, etwa in der Zeitschrift mt|medizintechnik.
Offene Fragen der Praxis
- 01
Wie beschreibt man Angreiferverhalten am Fahrzeug so, dass TARA, Pentest und Vehicle SOC dieselbe Sprache sprechen?
Unser Ansatz
Wir nutzen die Automotive Threat Matrix des Auto-ISAC, Release v4.02 vom 4. Dezember 2025, mit 14 Taktiken und 75 Techniken. Die Version frieren wir ein und vermerken sie in TARA und CSMS; Technik-IDs verankern wir in PSIRT, Pentest-Scope und Vehicle SOC. Für Backend, Companion-App, OTA-Server und Laden führen wir eine eigene Erweiterungsebene – die Matrix beschreibt vor allem das Fahrzeug selbst.
- 02
Wie verankern Hersteller Security vom Threat Model bis zur Meldung einer aktiv ausgenutzten Schwachstelle?
Unser Ansatz
Wir orientieren uns am Secure by Design and Default Playbook der ENISA: jedes Prinzip mit Checkliste, Mindest-Nachweis und Release-Gate. Dazu kommen Threat Modeling, eine SBOM je Release und ein PSIRT, das die CRA-Fristen von 24 Stunden, 72 Stunden und 14 Tagen hält. VamiGRC bildet den Product Security Lifecycle mit Release-Gates, TARA und SBOM ab; VamiAppSec bereitet Meldungen als Entwürfe vor.
- 03
Wie lassen sich Produktionsanlagen absichern, ohne Verfügbarkeit und funktionale Sicherheit zu gefährden?
Unser Ansatz
Wir gliedern Anlagen nach IEC 62443 in Zonen und Conduits und legen je Zone ein Ziel-Security-Level fest. Asset-Transparenz entsteht über passive Discovery, weil aktive Scans ältere Steuerungen stören können. Fernwartung läuft über dedizierte Gateways mit Freischaltung pro Sitzung. So werden die Pflichten aus NIS2, die auch das verarbeitende Gewerbe erfasst, im OT-Umfeld umsetzbar.
- 04
Wie bleiben vernetzte und KI-gestützte Medizinprodukte im Feld sicher, wenn Security zugleich Patientensicherheit ist?
Unser Ansatz
Wir verzahnen Security- und Safety-Risikomanagement nach MDCG 2019-16 und IEC 81001-5-1: Inventar mit SBOM, Triage mit klinischem Kontext, Patches als kontrollierte Änderung, abgestimmte Meldewege. Für KI kommen Prompt Injection und zu weit reichende Befugnisse von Agenten ins Bedrohungsmodell; für KI-Medizinprodukte mit Benannter Stelle gelten die Hochrisiko-Pflichten des AI Act ab dem 2. August 2028.
Was wir festhalten
- 01
Eine erschöpfende Risikobewertung braucht Matrix und UN-R155-Katalog
Wir haben die 75 Techniken der Automotive Threat Matrix auf den Bedrohungskatalog der UN R155 abgebildet: 52 lassen sich sauber zuordnen, Bedrohungen gegen Backend-Server fehlen der Matrix dagegen fast vollständig. Der UN-R155-Katalog wiederum zeigt keine Angriffspfade und begründet keine Machbarkeit. Erst beide Listen, verbunden über stabile IDs, tragen die Risikobewertung.
Beleg: Automotive Threat Matrix
- 02
In KI-Produkten kann eine Prompt Injection physische Folgen haben
Steckt KI in einem Gerät, werden Planer und Tool-Aufrufe zu Befehlen an Motoren, Schlösser oder Ventile. Das Produkt ist dann IoT-Gerät, KI-System und cyber-physisches System zugleich. Wer nur eine Schicht prüft, übersieht die Angriffsketten dazwischen – deshalb modellieren wir nach STRIDE und MAESTRO und testen von der Debug-Schnittstelle bis zum LLM.
Beleg: KI-Produkte Pentesting
- 03
Ein ausgelesenes Gerät kann die ganze Flotte gefährden
Wer ein vernetztes Gerät in der Hand hält, kann Debug-Schnittstellen ansprechen, Flash-Speicher auslesen und die Firmware analysieren. Zugangsdaten oder Signaturschlüssel aus einem einzigen Gerät wirken häufig für die gesamte Flotte. Geprüft wird deshalb, ob Debug-Ports deaktiviert sind, Secure Boot greift und Geheimnisse geschützt abgelegt sind.
Beleg: IoT-Pentesting
- 04
Bei Medizinprodukten entscheidet der klinische Kontext über die Priorität
CVSS, EPSS und KEV bewerten Schwere, Wahrscheinlichkeit und laufende Angriffe – nicht aber, ob ein Gerät am Patienten steht oder eine Manipulation Diagnose und Therapie verändert. Erst diese Fragen bestimmen die Prioritätsklasse. Eine mittel bewertete Lücke auf einem Therapiesystem kann deshalb dringlicher sein als eine kritische auf einem isolierten Gerät.
Wie wir vorgehen
Vami Research verbindet branchenspezifische Normen mit einer gemeinsamen Methodik: Bedrohungen modellieren, über alle Schichten prüfen und Nachweise führen, die in TARA, technischer Dokumentation und Konformitätsbewertung verwendbar sind.
TARA mit Automotive Threat Matrix
Techniken der Matrix als Bausteine von Angriffspfaden nach ISO/SAE 21434, abgeglichen mit dem Bedrohungskatalog der UN R155; Machbarkeitsannahmen versioniert.
STRIDE und MAESTRO
Bedrohungsmodell je Datenfluss und Vertrauensgrenze, für agentische KI entlang der sieben MAESTRO-Ebenen – in VamiThreat mit Zuordnung zu MITRE ATT&CK und ATLAS.
Zonen, Conduits, passive Discovery
Anlagen nach IEC 62443 in Zonen mit Ziel-Security-Level gliedern; Inventar aus gespiegeltem Verkehr statt aktiver Scans im Produktionsnetz.
Prüfung vom Chip bis zur Cloud
IoT- und KI-Produkt-Pentests entlang OWASP ISVS und ISTG sowie ETSI EN 303 645: Hardware, Firmware, Funk, Backend, App und Modell im Zusammenhang.
Release-Gates mit Mindest-Nachweis
ENISA-Playbooks mit Checkliste und Release-Gate; SBOM je Release, VEX und PSIRT-Prozess als Grundlage der Meldefähigkeit nach dem CRA.
Klinische Triage
Technische Bewertung um Erreichbarkeit, Patientennähe und Folgen für Diagnose oder Therapie ergänzen; Patches als kontrollierte Änderung einspielen.
So starten Sie
- 1ModellierenArchitektur, Datenflüsse und Vertrauensgrenzen erfassen; Bedrohungen und Angriffspfade per TARA, STRIDE oder MAESTRO ableiten.
- 2Prüfen und härtenPentests von der Debug-Schnittstelle bis zum LLM, Segmentierung nach Zonen, Release-Gates mit Mindest-Nachweisen.
- 3Im Feld betreibenSBOM je Release überwachen, Schwachstellenhinweise über CVD und PSIRT annehmen, Meldewege nach CRA, MDR und BSI-Gesetz vorab festlegen.
Deep Dives, Whitepaper und Analysen
Deep Dives 10
Whitepaper 3
Vom Feld in die Umsetzung
Verwandte Forschungsfelder
Ihr Produkt von der TARA bis zur Meldung absichern?
Ob Fahrzeugkomponente, Industriesteuerung oder Medizinprodukt: Wir ordnen Normen und Fristen ein, modellieren Bedrohungen und prüfen von der Debug-Schnittstelle bis zum LLM.