Letztes Jahr hat ein Security Researcher einen Kia (jedes Modell ab 2013) remote aufgeschlossen, gestartet und geortet. Nur mit der Kennzeichen-Nummer. Ohne spezielle Hardware, und ohne physischen Zugriff. Nur ein Fehler in einer Web-API, den niemand im Development-Team getestet hatte.
Ich komme immer wieder auf diese Story zurück, weil sie genau zeigt, wo wir bei vernetzten Systemen stehen. Wir bauen unglaublich smarte KI – Perception Models, agentische Workflows, AR-Interfaces – und binden sie in Autos, Medizin-Geräte und Industrieanlagen ein. Aber das Security-Denken hinkt hinterher. Nicht weil es niemanden interessiert, sondern weil AI-Teams und Security-Teams meist in getrennten Welten agieren.
Wenn du KI-Systeme baust, besonders solche, die mit der physischen Welt interagieren, musst du anfangen, wie ein Hacker zu denken, um besser zu bauen. Und die Automotive-Branche liefert die überzeugendsten und alarmierendsten Beispiele, warum diese Denkweise zählt.
Autos sind jetzt Software-Produkte mit Software-Problemen
Vor noch nicht allzu langer Zeit hieß Fahrzeug-Sicherheit: Lenkradschloss. Heute verarbeitet ein modernes Auto Daten von Dutzenden Sensoren, verbindet sich mit Cloud-Services, kommuniziert mit Infrastruktur und anderen Fahrzeugen und lädt Software-Updates, während es in deiner Einfahrt parkt.
McKinsey schätzt, dass Connectivity-Services, Shared Mobility und softwaregesteuerte Upgrades den Automotive-Umsatz bis 2030 um bis zu 1,5 Billionen Dollar aufstocken könnten. Das ist ein riesiger Anreiz, alles mit allem zu vernetzen. Aber jede neue Verbindung ist auch eine Tür … und nicht alle sind abgeschlossen.
Die Kosten sind schon konkret: 2024 hat die Automotive-Branche laut VicOne-Jahresbericht geschätzte 22,5 Milliarden Dollar durch Cyberangriffe eingebüßt: 20 Milliarden durch Datenlecks, 1,9 Milliarden durch Systemausfälle und über 500 Millionen allein durch Ransomware. Upstream Security zählte im selben Jahr über 100 Ransomware-Attacken und mehr als 200 Datenlecks im Automotive- und Smart-Mobility-Ökosystem.
Ransomware ist eine Form von Schadsoftware (Malware), die den Zugriff auf Dateien oder ganze Systeme blockiert, indem sie Daten verschlüsselt oder Geräte sperrt. Anschließend fordern die Angreifer ein Lösegeld („Ransom“), um den Zugriff wiederherzustellen. Betroffene sehen meist eine Erpressernachricht mit Zahlungsanweisungen, häufig in Form von Kryptowährungen.
Wenn ein Kennzeichen zum Hacken reicht
Die Kia-Schwachstelle lohnt einen genaueren Blick, denn die technischen Details zeigen, wie banal der Fehler war.
Security Researcher Sam Curry und sein Team stellten fest, dass Kias Connected-Vehicle-Plattform Fernzugriff auf zentrale Fahrzeugfunktionen erlaubte – abschließen, aufschließen, starten, stoppen und orten – durch Schwachstellen, die jeder Penetration Tester als Standard-Webapp-Bugs erkennt. Der Angriff funktionierte unabhängig davon, ob der Besitzer eine aktive Connected-Services-Subscription hatte. Schlimmer noch: Der Angreifer konnte sich heimlich als unsichtbarer Zweitnutzer hinzufügen, ohne dass der echte Owner benachrichtigt wurde.
Ein paar Monate später entdeckte Curry ein ähnliches Muster bei Subarus STARLINK-Service. Die Admin-Konsole hatte einen Password-Reset-Endpoint ohne Bestätigungs-Token, und der Zwei-Faktor-Authentifizierungs-Prompt ließ sich umgehen, indem man einfach ein Overlay auf Kundenseite entfernte. Damit erhielten die Researcher uneingeschränkten Zugriff auf Fahrzeuge und Kundenkonten in den USA, Kanada und Japan. Sie konnten ein ganzes Jahr lang die History der Standorte präzise auf fünf Meter und aktualisiert bei jedem Motorstart abrufen.
Beide Hersteller haben die Lücken nach der Offenlegung schnell behoben, und es gibt keine Hinweise auf Angriffe in der Praxis. Das blieb bei mir hängen:
Die gefährlichsten Schwachstellen waren gar nicht im Auto. Sie waren in den APIs, Webportalen und Backend-Systemen.
Das Auto selbst war okay, aber nicht die leicht zugängliche Software.
Dieses Muster eines hochkomplexen Produkts und eines unsicheren Backend-Gerüsts taucht in KI-Projekten überall auf. Und es ist genau die Lücke, die du nur siehst, wenn du gezielt hinschaust.
Ich hab das selbst erlebt: Eine LLM-Integration mit solider Prompt-Architektur, sorgfältigem Filtern des Outputs und starkem User-Facing-Design – und einem ungeschützten internen API-Endpoint, der den System-Prompt komplett überschreiben konnte. Niemand hatte das getestet, weil es nicht im üblichen QA-Scope lag. Es war nicht mal als Sicherheitsthema auf dem Radar. Einfach so verankert in der schnellen Prototypenphase, die nie überprüft wurde.
Bildquelle: Photo by Mo Eid from Pexels https://www.pexels.com/photo/orange-sports-coupe-2631489/
Die KI-Schicht: Eine neue Angriffsfläche
Je mehr Fahrzeuge KI für Wahrnehmung, Navigation, Fahrerassistenz und zunehmend AR-gestützte Oberflächen nutzen, desto klarer wird eine völlig neue Risikoklasse: gegnerische KI-Angriffe (im Englischen „adversarial AI attacks“ genannt).
Was sind gegnerische KI-Angriffe?
Anders als klassische Software-Bugs nutzen diese Angriffe aus, wie Machine-Learning-Modelle Daten interpretieren. Kleine, gezielt manipulierte Störungen in den Eingabedaten lassen KI-Systeme Objekte falschklassifizieren, Hindernisse übersehen oder gefährliche Entscheidungen treffen. Und das alles, während sie nach außen hin normal funktionieren.
Wie greifen gegnerische Angriffe Fahrzeuge an?
| Angriffsart | Was wird getan | Beispiel |
| Gegnerische Patches | Physische Aufkleber oder Markierungen, die Object-Detection-Modelle dazu bringen, Objekte falsch zu klassifizieren oder zu ignorieren | Forscher haben Patches demonstriert, die Stoppschilder für YOLO-basierte Detection-Systeme unsichtbar machen (YOLO = „You Only Look Once“; ein spezieller Echtzeit-Objekterkennungs-Algorithmus aus der Computer Vision) |
| Sensordrehung | Einschleusen falscher Daten in LiDAR-, Radar- oder Kamera-Feeds (LiDAR = „Light Detection and Ranging“) | Simulierte LiDAR-Angriffe können Phantom-Hindernisse erzeugen oder echte vor autonomen Fahrsystemen verstecken |
| Datenvergiftung | Manipulieren von Trainingsdaten, um Hintertüren in Modelle einzubauen | Ein vergifteter Datensatz könnte ein Modell dazu bringen, unter bestimmten Bedingungen spezifische Objekte falsch zu erkennen |
| Modell-Inversion | Extraktion privater Trainingsdaten aus einem eingesetzten Modell | Angreifer könnten sensible Fahrverläufe oder Nutzerdaten aus einem offenen Modell-Endpunkt rekonstruieren |
Eine Springer-Studie aus 2025, die über 170 Papers zu gegnerischen Angriffen auf autonome Fahrzeuge analysierte, stellte fest, dass selbst hochentwickelte Deep-Learning-Systeme weiterhin stark anfällig bleiben, besonders bei Echtzeit-Attacken. Die Forscher forderten realistischere Security-Tests und dass Dev-Teams Abwehrstrategien schon früh im Design einbauen, nicht als Nachtrag.
Ein weiteres Forschungsprojekt aus 2025 testete ein „Perception–Streaming–Angriffs“-Framework (PSA) auf einem NVIDIA Jetson Edge-Device (genau die Hardware, die in echten Autos läuft). Es zeigte, dass über 76% der Objekte, die das Perception-Modul erkennen sollte, bei 12 Frames pro Sekunde effektiv verschwinden. Das reicht locker für Bedingungen im realen Straßenverkehr.
Warum sind gegnerische KI-Angriffe für AI-Teams genauso relevant wie für Autokonzerne?
Diese Schwachstellen sind nicht auf Autos beschränkt. Sie zeigen ein größeres Muster, wie KI-Systeme in allen Branchen gebaut werden. Jedes Team, das Machine-Learning-Modelle mit realen Daten einsetzt, sei es für autonomes Fahren, E-Commerce-Personalisierung oder konversationsbasierte KI, sollte sich diese Fragen stellen:
- Wie robust ist unser Modell gegen gegnerische Eingaben?
- Könnte jemand unsere Trainingsdaten manipulieren, um versteckte Biases oder Hintertüren einzubauen?
- Was passiert, wenn unser Modell Eingaben bekommt, für die es nie trainiert wurde?
- Sind unsere APIs und Daten-Pipelines genauso sicher wie die Modelle selbst?
Wenn du KI-Systeme baust und dir diese Fragen noch nicht gestellt hast, denkst du noch nicht wie ein Hacker. Und ehrlich: Das solltest du, weil jemand anderes tut es schon.
Regulierungen holen schnell auf
Der Cybersecurity-Weckruf der Automobilbranche hat weltweit Regulierungen ausgelöst. Der wichtigste Schritt: UN-Verordnung Nr. 155 (R155), beschlossen vom UNECE World Forum for Harmonization of Vehicle Regulations (WP.29).
R155 verlangt von Fahrzeugherstellern ein zertifiziertes Cybersecurity-Management-System (CSMS), das den gesamten Fahrzeuglebenszyklus abdeckt, von der Entwicklung über die Produktion bis zu den Postproduktionsphasen. Seit Juli 2024 ist die Einhaltung für alle Neuwagen in der EU Pflicht.
Die Verordnung nennt 69 konkrete Cyberbedrohungen und Schwachstellen in sieben Kategorien und fordert 23 Schutzmaßnahmen. Hersteller müssen nachweisen, dass sie Cybersicherheitsrisiken in der gesamten Lieferkette managen, Vorfälle in Echtzeit erkennen und reagieren sowie sichere Software-Update-Mechanismen bieten.
Die globale Einführung der Sicherheitsvorkehrungen beschleunigt sich
Die EU hat R155 im Juli 2024 für alle Neuwagen verpflichtend gemacht. Japan hat die Verordnung 2021 umgesetzt und ist voll konform. Südkorea entwickelt eigenständige, aber R155-kompatible Standards. China hat GB 44495:2024 veröffentlicht, verpflichtend für neue Fahrzeugtypen ab Januar 2026. Großbritannien berät aktiv die nationale Übernahme, während die USA freiwillige NHTSA-Richtlinien nutzen. Das Handelsministerium plant jedoch ein Verbot von chinesischer und russischer Fahrzeugsoftware.
Der Begleitstandard ISO/SAE 21434 liefert das Engineering-Framework für Cybersecurity-Risikomanagement, das R155-Konformität untermauert. Zusammen bilden sie den umfassendsten regulatorischen Vorstoß für Cybersecurity-by-Design, den je eine Branche erlebt hat.
Was können KI-Teams aus den Automotive-Regulierungen lernen?
Die Prinzipien hinter R155 sind nicht autospezifisch. Sie bieten ein gutes Framework, um an Sicherheit in jedem System zu denken, wo Software auf die physische Welt trifft.
- Bedrohungs- und Risikoanalyse ist der obligatorische erste Schritt, nicht optional und nicht erst nach dem MVP-Launch.
- Sicherheit muss den gesamten Lebenszyklus abdecken, nicht nur den Start.
- Verantwortung in der Lieferkette zählt, denn du haftest für jede Komponente, inklusive Code und Modelle von Drittanbietern.
- Kontinuierliches Monitoring ist Pflicht: Das Deployen eines Systems ist nicht das Ende, sondern der Beginn deiner Verantwortung für die Security.
- Und Notfallreaktionsplanung ist fest eingebaut, denn Sicherheitsvorfälle passieren und die Vorbereitung ist Pflicht.
Während KI-Regulierungen weltweit wachsen, vom EU AI Act bis zu branchenspezifischen Frameworks, sind Engineering-Teams mit diesem Denken besser gerüstet als die, die Security nachträglich in unvorbereitete Systeme einbauen müssen.
Das Hacker-Mindset: Wie es wirklich aussieht
Um das klarzustellen: Wie ein Hacker zu denken heißt nicht, einbrechen zu lernen. Es bedeutet, dich zu trainieren, Lücken zu sehen. Den Raum zwischen dem, was ein System tun soll, und dem, was du es tun lassen könntest, wenn du es versuchst. Security-Experten nennen das Verstehen deiner Angriffsfläche. Und das ist eine Gewohnheit, die jeder AI Engineer lernen sollte.
Altes Mindset vs. Hacker-Mindset
| Traditionelles KI-Denken | Hacker-Denken |
| „Unser Modell erreicht 98% Genauigkeit im Testset“ | „Welche Eingaben lassen die restlichen 2% spektakulär explodieren?“ |
| „Wir prüfen Datenqualität beim Training“ | „Könnte jemand die Daten vorher vergiften, ohne dass wir es merken?“ |
| „Unsere API braucht Authentifizierung“ | „Was, wenn jemand einen gültigen Token über einen nicht berücksichtigten Weg bekommt?“ |
| „Wir nutzen verschlüsselte Verbindungen“ | „Was ist offen, wenn jemand direkt das Backend trifft?“ |
| „Unsere OTA-Updates laufen super“ | „Könnte ein Man-in-the-Middle ein schädliches Update durchpushen?“ |
| „Das Modell läuft lokal auf dem Gerät“ | „Kann jemand die Weights rausziehen und alles reverse-engineeren?“ |
Eine Security-First-Kultur aufzubauen ist schwerer als es klingt
Die besten Cybersecurity-Programme setzen nicht nur auf extra Security-Teams. Sie verankern Sicherheitsbewusstsein in jeder Engineering-Rolle. Für KI- und Daten-Teams bedeutet das ein paar konkrete Maßnahmen:
Baue Bedrohungsmodellierung in den Designprozess ein.
Bevor du die erste Codezeile schreibst, skizziere, wer dein System angreifen könnte, was sie gewinnen könnten und wo die schwächsten Stellen sind. Das STRIDE-Framework (Verfälschung, Manipulation, Aberkennung, Informationsoffenlegung, Dienstverweigerung, Privilegienausweitung) ist ein guter Einstieg. Es ist nicht perfekt, aber es zwingt zu Gesprächen, die sonst nicht stattfinden.
Teste gegnerisch, nicht nur funktional.
Standard-Unit-Tests prüfen, ob dein System tut, was es soll. Gegnerisches Testen prüft, ob es nichts tut, was es nicht soll. Baue Fuzzing, Grenzwerte-Tests und gegnerische Beispiele in die CI/CD-Pipelines ein. Das ist leichter gesagt als getan, besonders bei engen Timelines, aber ein paar Stunden strukturierter gegnerischer Überprüfung decken auf, was funktionale Tests komplett übersehen.
Sichere die gesamte Pipeline, nicht nur das Modell.
Datensammlung, Annotation, Speicherung, Trainingsinfrastruktur, API-Deployment, Monitoring-Dashboards: Jedes Kettenglied ist ein potenzielles Ziel. Eine kompromittierte Annotation-Pipeline kann subtile Biases einschleusen, die kein Modelltest entdeckt. Hier hinkt die Branche hinterher; Tools für ML-Pipeline-Sicherheit reifen noch und Best Practices sind weit weniger etabliert als bei App-Sicherheit.
Gehe davon aus, dass der Perimeter durchbrochen wird.
Baue Systeme mit mehreren Sicherheitsschichten, damit bei einem Versagen nicht gleich alles zusammenbricht. Genau das haben Autohersteller auf die harte Tour gelernt – ein unsicheres Webportal sollte keine Fahrzeugsteuerung freischalten. Gleiches gilt für KI-Systeme: Ein kompromittierter API-Endpunkt sollte keine Trainingsdaten oder System-Prompts preisgeben.
Bleibe auf dem aktuellsten Stand.
Die Bedrohungslage verändert sich ständig. Melde dich für Sicherheitsmitteilungen an, folge Forschern im Bereich Security und sei in Communitys aktiv. Was heute theoretisch klingt, kann morgen Realität sein. Die Kia-Lücke, die fast zu simpel wirkt, wurde noch letztes Jahr in der Praxis ausgenutzt.
Bildquelle: https://www.asylas.com/wp-content/uploads/2022/12/einstein-security-meme.png
Der Weg nach vorn: Wie entwickelt sich die Cybersecurity in der Automobilbranche?
Die Cybersecurity-Reise der Automobilbranche zeigt, was jede KI-intensive Branche erwartet, wenn Systeme vernetzter, autonomer und fester im Alltag integriert werden. Es ist keine perfekte Analogie; KI-Systeme versagen anders als Autos, und die Regulierungen unterscheiden sich. Aber die grundlegende Herausforderung bleibt: Du setzt komplexe Software in Umgebungen aus, die du nicht voll kontrollierst, gegen Angreifer, die aktiv nach Lücken suchen.
Die Erwartungen der Nutzer ändern sich bereits. Laut RunSafe Securitys 2025 Connected Car Cyber Safety Index fühlen nur 19% der Besitzer vernetzter Autos ihr Fahrzeug ausreichend geschützt und 79% sagen, dass der Schutz ihrer körperlichen Sicherheit vor Cyberangriffen wichtiger ist als Datenschutz. Das Vertrauensproblem ist real und überholt die Fähigkeiten der Branche, es zu lösen.
KI wird das auch erreichen. Bald (wahrscheinlich früher als die meisten denken) werden KI-Sicherheitsvorfälle so prominent, dass Nutzer und Regulierer stärker nachfragen. Am besten dastehen werden dann Teams, die Sicherheit heute als Designzwang sehen, nicht als späteres Compliance-Häkchen.
Für Daten- und KI-Teams ist die Lehre nicht autospezifisch. Es geht um ein universelles Prinzip: Je intelligenter und vernetzter ein System wird, desto sorgfältiger muss seine Sicherheit designt werden. Von Anfang an eingebaut, von Ingenieuren, die wissen: Großartige KI bauen heißt auch, über ihre Zerbrechlichkeit nachzudenken.
Denn die Frage ist nicht, ob dein System Lücken hat. Sondern ob du genau genug danach gesucht hast, bevor es jemand anderes tut.
Dein Herz schlägt für Automotive-Themen? Dann lies hier weiter: Gamifizierte Augmented Reality: Die Zukunft der Automotive UX?
Quellen
1. Upstream Security, „2025 Global Automotive & Smart Mobility Cybersecurity Report“, 2025
2. Sam Curry, „Hacking Kia: Remotely Controlling Cars With Just a License Plate“, samcurry.net, September 2024
3. Sam Curry, „Hacking Subaru: Tracking and Controlling Cars via the STARLINK Admin Panel“, samcurry.net, January 2025
4. RunSafe Security, „2025 Connected Car Cyber Safety & Security Index“, 2025
5. VicOne, Automotive Cybersecurity Annual Report, 2024
6. A.D. Mohammed Ibrahum et al., „Deep learning adversarial attacks and defenses in autonomous vehicles: a systematic literature review from a safety perspective“, Artificial Intelligence Review, Springer, 2025
7. ScienceDirect, „Cross-task and time-aware adversarial attack framework for perception of autonomous driving“, Pattern Recognition, 2025
8. UNECE WP.29, UN Regulation No. 155 — Cyber Security Management System (CSMS)
9. ISO/SAE 21434:2021, „Road vehicles — Cybersecurity engineering“
10. McKinsey & Co., Connected Vehicle Revenue Projections, 2024
11. Joe Saunders (RunSafe Security), „Cybersecurity Is the New Safety Standard for Connected Cars“, Design and Development Today, September 2025
Author info
