Direkt zum Inhalt

Forschung & Wissen

Eigenes OT-Labor und angewandte Sicherheitsforschung.

Eigene Anlagen fuer die Sicherheitsforschung Mast, Tank, Pumpe, Foerderband und Signal auf einer Grundplatte, darunter echte Steuerungen auf der Hutschiene. Von links laeuft ein Angriff hinein, von rechts antwortet die Erkennung. >_ ATTACK DEFENCE
Der Kreislauf

Forschung, die im Labor steht und in Prüfungen zurückkommt

Wir betreiben ein eigenes OT-Labor mit Demonstratoren aus mehreren Sektoren. Angriffe und Absicherung spielen wir dort an echter Hardware durch, nicht in der Theorie und nicht in der Simulation.

Ein Teil dieser Arbeit lief von Juli 2022 bis Dezember 2025 in einem vom Bund geförderten Verbundvorhaben zu Cyberschutzsystemen für Fahrzeuge und Infrastruktur im Straßen- und Schienenverkehr, gemeinsam mit Partnern aus Bahn, Automobilindustrie, Fraunhofer und Universität. Unser Teilvorhaben trug das Förderkennzeichen 16KIS1588. Was dort entstanden ist, fließt direkt in unsere Prüfungen und Trainings zurück.

Was wir beigetragen haben

Drei Komponenten, die es vorher nicht gab

Aus dem Verbundvorhaben, öffentlich dokumentiert im Projektbericht.

Angriffserkennung für den Fahrzeugbus im Zug

Eine herstellerneutrale Erkennung für den Multifunction Vehicle Bus nach IEC 61375. Aufzeichnungen aus zwei Systemen unterschiedlicher Herkunft und eine eigene virtuelle Umgebung laufen über Adapter in ein gemeinsames Datenmodell. Erkannt wird hybrid, regelbasiert und lernbasiert.

Angriffserkennung für Fahrzeugdiagnose

Übliche Erkennung auf dem Fahrzeugbus liest nur Rahmenstrukturen und versteht das Diagnoseprotokoll nicht. Unsere Erkennung interpretiert es: Sitzungszustände, Dienstkennungen und Zugriffsstufen werden ausgewertet, um Auslesen, Speicherabtastung und Angriffe auf den Sicherheitszugang zu erkennen.

Ein Security Event Center im Fahrzeug

Einzelne Erkennungssysteme sehen jeweils nur ihre Technologie. Das Security Event Center sammelt und korreliert Ereignisse aus allen Quellen an Bord, macht damit technologieübergreifende Angriffsketten sichtbar und ist zugleich die Schnittstelle zur flottenweiten Auswertung.

Architektur

Von der Steuerung bis zur Flotte, in fünf Ebenen

Vehicle Security Operations Center Steuergeraete an zwei Bussen, eine Erkennungseinheit an Bord, der Uplink und die Auswertung im Betrieb. Was auffaellt, wird zur Regel und geht zurueck ins Fahrzeug. IN-VEHICLE ECUS ON THE BUS IDS UPLINK VEHICLE SOC USE CASES PER VEHICLE TYPE VEHICLE SOC · ON BOARD AND IN THE BACKEND

Sicherheitsereignisse entstehen an sehr unterschiedlichen Stellen und sie brauchen unterschiedliche Antwortzeiten. Deshalb haben wir die Architektur als Hierarchie angelegt: Rohdaten in Steuergeräten und Netzkomponenten, darüber die Überwachung einzelner Steuergeräte, darüber die Überwachung ganzer Fahrzeugdomänen mit ihren jeweiligen Protokollen, darüber die Zusammenführung im Fahrzeug und ganz oben die fahrzeugübergreifende Auswertung im Betrieb.

Die unteren Ebenen erlauben sofortige lokale Reaktion, die oberste erlaubt Zusammenhänge über die Flotte hinweg. Für die Ereignisformate haben wir einen bestehenden Automobilstandard um die Felder erweitert, die für eine belastbare Auswertung fehlten.

Im echten Zug

Erprobt auf einem Forschungszug

Zug-Demonstrator mit Fahrzeugbussen und Angriffserkennung Antrieb, Klimatisierung, Tueren und Anzeige an MVB und CANopen. Ein gefaelschtes Telegramm wird vom MVB-IDS erkannt und an das Rail Security Operations Center gemeldet. VEHICLE SYSTEMS TRACTION HVAC DOORS DISPLAY MVB CANOPEN REAL BUSES, NOT A SIMULATION FORGED TELEGRAM FROM THE DMI MVB-IDS NORMALISED RAIL SOC VIRTUAL MVB- SIMULATOR YEKTRAIN · MVB, CANOPEN, IDS, RAIL SOC

Das Advanced TrainLab von DB Systemtechnik diente als Testplattform unter realen Betriebsbedingungen. Fahrzeugbusse werden an Bord abgegriffen und an einen Rechner mit Sicherheitsmodul übertragen. Die Sensoren laufen in Containern, normalisieren die eingehenden Daten und prüfen sie auf Manipulation.

Weil die Mobilfunkanbindung eines fahrenden Zuges begrenzt ist, filtern die Sensoren vor: Übertragen wird nur, was sicherheitsrelevant ist. Fällt die Verbindung zur Auswertung aus, puffert das Security Event Center an Bord, bis sie wieder steht. Das sind die Randbedingungen, die einen Zug von einem Rechenzentrum unterscheiden.

Veröffentlichungen

Was daraus publiziert wurde

Die Ergebnisse sind begutachtet veröffentlicht, nicht nur in Projektberichten:

  • VATT&EK: Formalization of Cyber Attacks on Intelligent Transport Systems. A TTP based approach for Automotive and Rail. 7th ACM Computer Science in Cars Symposium, 2023. Das Modell gliedert gegnerisches Vorgehen in vierzehn Taktikklassen, von der Manipulation der Umgebung über den Erstzugriff bis zur Auswirkung. Damit deckt es ab, was das gängige IT-Modell für Fahrzeuge offenlässt.
  • UDS Attack Taxonomy. Systematic classification of vehicle diagnostic threats. IEEE Conference on Communications and Network Security, 2025.
  • From ECU to VSOC. UDS Security Monitoring Strategies. SECURWARE, 2025. Drei Kategorien von Erkennungsstrategien, vom Muster im Fahrzeugprotokoll über die Bewertung im Kontext des Fahrzeugzustands bis zur Einbeziehung öffentlicher Schwachstelleninformationen.
  • Towards a Holistic and Multi-modal Vehicle Security Monitoring. Critical Information Infrastructures Security, 20th International Conference.
  • Multi-modales Intrusion Detection System. Angriffserkennung für Mobilitätssysteme. Signal + Draht 117 (2025) 3.
  • KI auf Schienen. Beschleunigung der digitalen Transformation des Bahnbetriebs. Signal + Draht 116 (2024) 4, Seite 15 bis 21, auch auf Englisch erschienen.

Zur Systematik gibt es eine begleitende öffentliche Matrix, in der die Taktiken und Techniken nachgeschlagen werden können.

Was daraus für Sie folgt

Forschung ist bei uns kein Marketingbegriff

Die Erkennungsregeln, die wir in Kundenprojekten schreiben, stammen aus derselben Arbeit. Die Trainings, in denen Teilnehmende selbst angreifen, laufen auf denselben Aufbauten. Und die Prüfvorgehen, die wir in einer Anlage anwenden, sind vorher an eigener Hardware durchgespielt worden.

Was wir finden und lernen, teilen wir im Blog, in Veröffentlichungen und in eigenen Sicherheitshinweisen mit koordinierter Offenlegung.

Warum eigene Forschung

Forschung, die im Labor steht.

Wir betreiben ein eigenes OT-Labor mit realen Demonstratoren aus mehreren Sektoren. Drei Punkte beschreiben unsere Arbeit.

Reale Hardware

Angriffe und Absicherung spielen wir an echter Hardware durch, nicht in der Theorie und nicht in der Simulation.

Geförderte Projekte

Ein Teil dieser Arbeit lief bis Dezember 2025 im Verbundprojekt FINESSE. Erkenntnisse aus der Forschung fließen direkt in unsere Prüfungen und Trainings zurück.

Wir geben weiter

Was wir finden und lernen, teilen wir im Blog, in geplanten Whitepapern und in eigenen Security Advisories.

Beweis

Die Demonstratoren sind der Beweis.

Drei Demonstratoren aus verschiedenen Sektoren, an denen sich Angriffe und Gegenmaßnahmen reproduzierbar zeigen lassen. Sie sind Grundlage unserer Prüfungen, Trainings und Live-Demos.

YekCity

Aus der Analyse realer Angriffe auf Strom- und Versorgungsnetze entstanden: eine Modellstadt mit echten Steuerungen, an der sich diese Angriffe nachstellen, erkennen und üben lassen.

YekTrain

Fahrzeugsysteme an MVB und CANopen, aufgebaut aus Aufzeichnungen echter Züge. Angriffe und ihre Erkennung lassen sich daran reproduzierbar zeigen.

YekCar

Emulierte Steuergeräte mit CAN, UDS und Keyless, daneben Angreifer-Dashboard und IDS-Monitor im selben Aufbau.

Förderung & Programm

Woran wir arbeiten.

Unsere Forschung ist in Förderprogramme und ein eigenes Labor eingebettet.

BMBF

Förderung durch das Bundesministerium für Forschung, Technologie und Raumfahrt, vormals BMBF.

Projekt FINESSE

Angewandte Sicherheitsforschung im geförderten Verbundprojekt.

OT-Labor

Reale Demonstratoren aus mehreren Sektoren als Basis der Arbeit.

Nächster Schritt

Das Labor aus der Nähe sehen.

Vereinbaren Sie ein Erstgespräch oder fragen Sie eine Live-Demo an. Wir zeigen die Demonstratoren und was sich an ihnen prüfen lässt.

Telefon
0231 39814905
Mo–Fr · 9–17 Uhr
E-Mail
info@yekta-it.de
PGP verfügbar
Standort
Dortmund
Ruhrallee 9 · 44139