Figure 9.70: Users of the Intrusion Detection System Manager interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellen-Nutzungsdiagramm gemäß AUTOSAR Adaptive Platform (AP) Metamodell.
• Technischer Zweck: Spezifikation der standardisierten Reporting-Beziehungen zwischen sicherheitsrelevanten Plattform-Clustern (Security Sensors) und dem zentralen Intrusion Detection System Manager (IdsM).
• Funktionale Einordnung: Kernbestandteil der Cybersecurity-Architektur (ISO/SAE 21434, UNECE R155). Der IdsM konsolidiert, filtert und qualifiziert sicherheitsrelevante Ereignisse (Security Events) auf POSIX-basierten Adaptive ECUs zur späteren Weiterleitung an ein Security Operations Center (VSOC) oder On-Board-Diagnosesysteme.

2. Komponenten, Entitäten & Schnittstellen

• Dienstanbieter (Provider):
  • «aapFunctionalCluster» Intrusion Detection System Manager (daemon-based): Zentraler Plattform-Daemon zur Erfassung, Pufferung, Ratenbegrenzung und Aggregation von Security Events. Realisiert (gestrichelte Linie mit geschlossener Dreiecksspitze) das Interface EventReporter.
• Dienstnutzer (Clients / Security Sensors):
  • «aapFunctionalCluster» Firewall (daemon-based): Filtert IP-Netzwerkverkehr (z. B. Paketinspektion, DoS-Erkennung, ungültige Ports/Protokolle) und meldet Integritätsverletzungen.
  • «aapFunctionalCluster» Communication Management (daemon-based, ara::com): Erkennt Anomalien auf Transport- und Middleware-Ebene (z. B. SOME/IP-Fehlformate, Service-Discovery-Flooding, SecOC-Validierungsfehler, TLS-/DTLS-Handshake-Failures).
  • «aapFunctionalCluster» Diagnostic Management (daemon-based, ara::diag): Identifiziert unautorisierte Diagnosezugriffe (z. B. fehlgeschlagene SecurityAccess-Authentifizierungen gemäß Service 0x27, 0x29 oder ungültige Routine-Aufrufe).
• Schnittstellen & Operationen:
  • «aapPortInterface, aapAPI» EventReporter: Standardisierte AUTOSAR Adaptive API bzw. Port-Schnittstelle.
  • + ReportEvent(...): Primäre C++-API-Methode zur standardisierten Signalisierung eines Security Events unter Übergabe von Event-ID, Kontext-Payload und Zeitstempel.
• Beziehungen & Abhängigkeiten:
  • Gerichtete Abhängigkeiten («use», gestrichelte Pfeile): Firewall, Communication Management und Diagnostic Management greifen unidirektional auf die Schnittstelle EventReporter zu.

3. Dynamisches Verhalten & Sequenzablauf

1. Ereignis-Detektion: Eine Sicherheitsrichtlinie in einem Sensor-Cluster wird verletzt (z. B. Firewall blockt unzulässiges TCP-SYN-Flooding; Diagnostic Management verzeichnet wiederholte Brute-Force-Versuche auf UDS SecurityAccess).
2. Schnittstellen-Aufruf: Das betroffene funktionale Cluster ruft synchron oder asynchron die Methode ReportEvent() des lokalen Sensor-Adapters auf.
3. Interprozess-Kommunikation (IPC): Da alle beteiligten Einheiten als daemon-based ausgeführt sind, erfolgt der Aufruf prozessübergreifend via POSIX-IPC (Domain Sockets, Shared Memory oder Message Queues) an den IdsM-Daemon.
4. Idsm-Verarbeitungs-Pipeline:
   • Filterung: Abgleich mit konfigurierten Filter-Regeln (Suppress / Drop).
   • Traffic Shaping / Rate Limiting: Schutz vor Denial-of-Service-Zuständen durch überlastete Event-Puffer.
   • Qualifikation: Hochstufen von Einzelelementen zu Qualified Security Events (QSEv).
5. Persistierung & Egress: Pufferung in nichtflüchtigem Speicher und asynchrone Übergabe als Security Event Report (QSR) an das Backend/VSOC (typischerweise getunnelt über das Communication Management).

4. Normative Relevanz & Entwickler-Hinweise

• Echtzeit- und Latenzanforderungen (Non-Blocking API):
  • ReportEvent() muss aus Sicht der aufrufenden Cluster zwingend performant und reentrant ausgelegt sein. Insbesondere zeitkritische Netzwerkpfade (Firewall, Communication Management) dürfen bei IdsM-Pufferengpässen oder IPC-Latenzen nicht blockieren (Fire-and-Forget- oder Lockless-Ringbuffer-Muster).
• Prozessgrenzen & Ressourcen-Isolation:
  • Durch die daemon-based-Strukturierung laufen Sensor und IdsM in getrennten Adressräumen. Entwickler müssen IPC-Overheads bei der Dimensionierung der Security-Event-Raten und Sampling-Intervalle einberechnen.
• Konfigurationsaspekte (ARXML):
  • Zuweisung eindeutiger SecurityEventDefinition-IDs für jeden Sensor-Cluster im AUTOSAR-Modell.
  • Schwellwert- und Ratenkonfiguration im IdsMConfiguration-Container, um ein Fluten des IdsM-Daemons durch defekte oder kompromittierte Client-Cluster zu verhindern.
• Rückwirkungsfreiheit (Freedom from Interference):
  • Fehler im IdsM-Daemon (z. B. Absturz oder Pufferüberlauf) dürfen den deterministischen Betrieb der Basis-Kommunikation (ara::com) oder der Fahrzeugdiagnose (ara::diag) nicht beeinträchtigen.