Was wir gemacht haben – und was dabei herauskam.

Ausgangslage

Fünf Monate bis zur Meldepflicht, ein breites Produktportfolio – und noch keine zentrale Funktion für Produkt-Security.

Vorgehen

• Produktinventar und Einordnung nach CRA-Produktklassen
• Pilot-Risikoanalyse nach IEC 62443-4-1/-4-2 als wiederverwendbare Vorlage
• Rollenmodell mit klaren Verantwortlichkeiten in den Produktteams
• Konzept für PSIRT, Meldekette und SBOM
• Roadmap rückwärts von den CRA-Stichtagen

Ausgangslage

Vernetzte Geräte im OP-Umfeld mit Bluetooth-, CAN- und USB-Schnittstellen müssen vor jedem Release nachweisbar sicher sein.

Vorgehen

• White-Box-Pentests mit Quellcode und Zugriff auf die Hardware
• Review von Architektur, Security Controls und Threat Model vor dem Test
• Getrennte Berichte für die Entwicklung und für den Nachweis gegenüber Dritten
• Maschinenlesbare Befundlisten (CSV/VEX) für das Schwachstellen­management

Ausgangslage

Neue Fahrfunktionen, ein strenger OEM-Prozess nach ISO/SAE 21434 und viele Zulieferer, die mitziehen müssen.

Vorgehen

• Risikoanalysen (TARA), Security-Konzepte und Testspezifikationen
• Delta-Analysen bei geänderten Schnittstellen und Signalen
• Wöchentliche Guidance-Runde für alle Projektbeteiligten
• Coaching der Zulieferer zu SBOM und Schwachstellenanalysen

Ausgangslage

Ein internationaler Technologiekonzern entwickelt Fahrzeug-Betriebssystem und Software-Stack für das autonome Fahren – mit vielen Teams und einem eigenen Entwicklungsprozess nach ISO/SAE 21434.

Vorgehen

• Assessments von Software-Arbeitsprodukten entlang des gesamten V-Modells: Risikoanalyse, Anforderungen, Architektur, Design, Code, Tests und Verifikation
• Confirmation Reviews nach dem Entwicklungsprozess des Kunden
• Meilenstein-Assessments mit Interviews und Zwischenberichten für die Entwicklungsteams
• Findings mit konkreten Hinweisen für die Teams und Vorschlägen für den Entwicklungsprozess

Ausgangslage

Mehrere tausend Geräte, gewachsene Netze, Werke in Deutschland, Frankreich und Polen – und kein aktuelles Lagebild.

Vorgehen

• Remote-Scans aus externer und interner Sicht
• Rechtlicher Rahmen vorab geklärt: Auftragsverarbeitung, Freigaben, Haftung
• Manuelle Validierung und Priorisierung der Befunde

Ausgangslage

Langlebige, sensible Daten – und die Frage, was Quantencomputer für die eigene Verschlüsselung bedeuten.

Vorgehen

• Architekturaufnahme und Kryptografie-Inventar
• Analyse von Schlüsselverwaltung, Transport- und Speicherverschlüsselung
• Bewertung des Risikos „store now, decrypt later“

Ausgangslage

Ein Engineering-Dienstleister wollte eigene Fachkräfte für Automotive Security ausbilden – berufsbegleitend und praxisnah.

Vorgehen

• Modulares Curriculum von Fahrzeug-Grundlagen bis Binary Exploitation und Fuzzing
• Mehrere Live-Durchläufe online
• Weiterentwicklung zum Selbstlernkurs mit Übungs-VM und LMS-Integration