Figure 19.1: Distributed IDS Architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: E/E-Topologie- und Verteilungsdiagramm (System Architecture / Deployment View) der fahrzeugweiten Intrusion Detection System (IDS)-Infrastruktur.
• Technischer Zweck: Visualisierung des hierarchischen, verteilten Erfassungs-, Aggregations- und Reporting-Pfads für Cyber-Security-Ereignisse über heterogene Steuergeräte (Classic AUTOSAR, Adaptive AUTOSAR, Zonen-Gateways, HPCs) hinweg bis zum cloudbasierten Security Operations Center (SOC / VSOC).
• Funktionale Einordnung: Standardisierter Systemansatz gemäß AUTOSAR IDS Architecture (eingeführt ab R20-11, spezifiziert in AUTOSAR_SWS_IntrusionDetectionSystemManager für CP und AUTOSAR_AP_EXP_PlatformDesign / ara::idsm für AP) zur Erfüllung regulatorischer Cybersicherheitsvorgaben (UN R155, ISO/SAE 21434).

2. Komponenten, Entitäten & Schnittstellen

• Security Sensors (S / Cyan):
  • Entität: Sensor-Instanzen in BSW-Modulen (z. B. Can, Eth, SecOC, PduR), OS, Adaptive-Plattform-Diensten oder Anwendungs-SWCs (Sensor SW-C).
  • Funktion: Detektion vordefinierter Sicherheitsanomalien (z. B. Frame-Drop, Message Counter Mismatch, ungültige UDS-Authentifizierung, DoS-Muster) und Generierung von Roh-Sicherheitsereignissen (Security Events, SEv).
• Intrusion Detection System Manager (IDSM / Grau):
  • Entität: Zentraler Core-Dienst pro ECU (BSW-Modul in CP; System-Service bzw. Daemon in AP).
  • Funktion: Event-Filterung (Sampling, Thresholding, Limiting), Filterketten-Auswertung, Aggregation und Einstufung zu qualifizierten Sicherheitsereignissen (Qualified Security Events, QSEv). Bildet protocol-spezifische Security Event Frames (SEF).
• Security Event Memory (SEM / Orange):
  • Entität: Persistenter/nicht-flüchtiger oder zirkulärer Pufferbereich (unterlagert an NvM in CP bzw. ara::per in AP).
  • Funktion: Lokale forensische Speicherung und Pufferung von QSEv, falls der Reporting-Pfad offline, überlastet oder ratenlimitiert ist.
• Intrusion Detection System Reporter (IDSR / Lila):
  • Entität: Master-Reporting-Funktion auf zentraler Connectivity- / Telematik-ECU (typischerweise AP-Knoten).
  • Funktion: Konzentration fahrzeuginterner Security Event Frames, Serialisierung/Kompression, kryptografischer Schutz (Signatur, TLS) und Bereitstellung des Off-Board-Uplinks via zellulare Netzwerke.
• Security Operations Center (SOC / Cloud-Symbol):
  • Entität: Off-Board Vehicle SOC (VSOC / SIEM).
  • Schnittstelle: Bidirektionale Verbindung (Uplink: Incident-Reporting via MQTT/HTTPS/Protobuf; Downlink: Dynamische Rekonfiguration von Filterregeln, Blacklists, Detection-Thresholds).
• Netzwerkhierarchie & Topologie-Beziehungen:
  • Leaf/Edge-ECUs (Standard/Sensoren): Mikrocontroller mit lokaler Sensorik + IDSM + SEM (1:1:1 pro ECU) oder reine passive Sensor-Knoten, angebunden über Sub-Busse (CAN-FD, LIN).
  • Domain-/Zonen-Gateways & HPCs (Zentrale Blöcke): Multi-Core/High-Performance-Instanzen (Gelb/Blau), die aggregierte Busdaten überwachen, Bridge-Filterung bereitstellen und Events an den IDSR weiterleiten.
  • Kardinalität: n Security Sensoren → 1 lokaler IDSM → 1 lokaler SEM; m IDSMs → 1 zentraler IDSR → 1 globales Backend-SOC.

3. Dynamisches Verhalten & Sequenzablauf

1. Ereigniserfassung (Synchron/Asynchron):
   • Ein HW-/SW-Treiber oder Stack-Modul detektiert eine Verletzung und ruft synchron die API IdsM_SetSecurityEvent(SecurityEventDefinitionId, ContextData, ContextDataSize) (CP) bzw. ara::idsm::SecurityEventReporter::ReportEvent(...) (AP) auf.
2. Qualifikation & Ratenlimitierung (IDSM Core):
   • Ausführung der statischen/dynamischen Filterkette:
     • Rate Limiting / Leaky Bucket: Verhindert Denial-of-Service auf dem internen Kommunikationsbus durch flutende Sensoren.
     • Thresholding: Erst nach Erreichen von n Events innerhalb des Zeitfensters t wird ein Roh-Event zu einem QSEv aggregiert.
3. Pufferung & Serialisierung (SEM & Bus-Transit):
   • Übergabe an den SEM zur temporären oder permanenten Archivierung.
   • Asynchrone Verpackung in standardisierte Security Event Frames (SEF) und Versand via In-Vehicle-Netzwerk (typischerweise SOME/IP oder statische CAN-FD/PduR-Routen) an die Zieladresse des IDSR.
4. Off-Board Dispatch (IDSR → SOC):
   • IDSR empfängt Frames aller zonalen Sub-Systeme, verifiziert Integrität, serialisiert nach OEM-Payload-Spezifikation (z. B. ASN.1, Protocol Buffers) und sendet Batches TLS-gesichert an das VSOC.
5. Feedback-Schleife (SOC → IDSR → IDSM):
   • SOC pusht dynamische Richtlinienänderungen (Payload Downlink) zur Laufzeit herunter, um Schwellwerte bei akuten Angriffskampagnen sensitiver zu schalten.

4. Normative Relevanz & Entwickler-Hinweise

• Treiber- & BSW-Entwickler:
  • Native Stack-Module (z. B. CanIf, TcpIp, DoIP, KeyM, CryIf) müssen als Security-Sensoren konfiguriert werden. Bei Detektion (z. B. MAC-Prüffehler in SecOC, Port-Scan im TCP-Stack) darf der Aufruf an IdsM den deterministischen Busverkehr nicht blockieren (Ausführung muss O(1) oder nicht-blockierend gepuffert sein).
• Konfigurationsverträge (ARXML):
  • SecurityEventDefinition: Exakte Parametrierung von SecurityEventId, Kontextdaten-Länge und Severity.
  • IdsMFilterAlgorithm: Definition von Filtern (ThresholdFilter, TimeAggregationFilter) im BSW-Konfigurator zur Vermeidung von Pufferüberläufen im RAM/NVRAM.
• Abgrenzung Dem (Diagnostic Event Manager) vs. SEM / IdsM:
  • Das Dem dient der Fahrzeugwartung (UDS DTCs nach ISO 14229). Das IdsM dient der Manipulations- und Cyberangriffserkennung. Ein Security Event darf nicht unreflektiert als DTC abgebildet werden, kann aber bei Bedarf über Inter-Module-Schnittstellen eine standardisierte Fehlereintragung anstoßen.
• Persistenz & Dimensionierung (SEM):
  • Entwickler müssen SEM-Puffer gegen Ringpuffer-Überschreibung (Overwriting Attacks) absichern. Bei NVRAM-Anbindung ist die maximale Flash-Schreibzykluszahl (Endurance) durch adäquate IdsM-Filterketten zwingend zu schützen.
• Adaptive Platform (ara::idsm):
  • Bereitstellung serviceorientierter Schnittstellen via IPC/SOME/IP für Non-Platform Applications; Einbindung von Context-Data-Serializern unter strikter Beachtung des deterministischen Scheduling im Execution Management.