Figure 5.1: Interfaces provided by Intrusion Detection System Mananger to other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Interface Realization & Dependency) der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: Dargestellt ist das Ingress-Schnittstellenmodell des funktionalen Clusters Intrusion Detection System Manager (IdsM, SWS AP R23-11/R24-11).
• Funktionale Einordnung: Der IdsM fungiert als zentrale Plattform-Senke für Security Events im Steuergerät. Das Diagramm spezifiziert die standardisierte Service-/API-Schnittstelle, über die andere plattformnahe, daemongestützte funktionale Cluster (Security Event Sensors) sicherheitsrelevante Anomalien und Protokollverletzungen in die IdsM-Pipeline einspeisen.

2. Komponenten, Entitäten & Schnittstellen

• Schnittstelle:
  • «aapPortInterface, aapAPI» EventReporter: Dual-stereotypisierte Schnittstelle (modelliert als C++-API aapAPI und adaptives Port-Interface aapPortInterface).
  • Operation: + ReportEvent() zur Übergabe normierter Sicherheitsereignisse (inkl. Event-ID, Timestamp und Context Data).
• Provider (Realisierende Instanz):
  • «aapFunctionalCluster» Intrusion Detection System Manager (daemon-based): Implementiert die EventReporter-Schnittstelle vollständig (gekennzeichnet durch die geschlossene, gestrichelte Realisierungs-Pfeilspitze).
• Consumer (Nutzende funktionale Cluster):
  • «aapFunctionalCluster» Firewall (daemon-based): Verwendet («use») die Schnittstelle zur Meldung netzwerkbasierter Anomalien (z. B. gedroppte IP-Pakete, Port-Scans, MAC-Spoofing).
  • «aapFunctionalCluster» Communication Management (daemon-based): Verwendet («use») die Schnittstelle zur Meldung protokollspezifischer Verletzungen (z. B. SOME/IP-Serialisierungsfehler, E2E- oder SecOC/TLS-Validierungsfehler).
  • «aapFunctionalCluster» Diagnostic Management (daemon-based): Verwendet («use») die Schnittstelle zur Meldung diagnostischer Sicherheitsvorfälle (z. B. fehlgeschlagene UDS-SecurityAccess-Authentifizierungen, unberechtigte Flash-/RoutineControl-Versuche).
• Beziehungsstruktur & Kardinalität:
  • n:1-Nutzungsbeziehung («use»): Mehrere sensorische funktionale Cluster nutzen denselben standardisierten Ingress-Port des IdsM.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Erkennung einer sicherheitsrelevanten Abweichung im jeweiligen Subsystem (z. B. IP-Regelverletzung in der Firewall, fehlerhafte Signaturen im Communication Management, brute-force Seed/Key im Diagnostic Management).
2. Aufruf: Der meldende Daemon ruft synchron oder entkoppelt die C++-Methode ReportEvent() auf der lokalen EventReporter-Instanz auf.
3. Parameterübergabe: Übergabe der SecurityEventDefinitionId zusammen mit plattform-/ereignisspezifischen Kontextdaten (Payload).
4. IdsM-Verarbeitungspfad:
   • Validierung der Event-ID gegen die konfigurierte SecurityEventDefinition.
   • Anwendung konfigurierter Filterregeln (Rate Limiting, Thresholding, Sampling), um DoS-Angriffe auf das Protokollierungssystem zu unterbinden.
   • Aggregation und Qualifizierung zum Qualified Security Event (QSEv).
   • Pufferung für die interne Persistierung oder Weiterleitung an übergeordnete Instanzen (z. B. IdsR / Vehicle Security Operations Center).
5. Rückmeldung: Nicht-blockierende Rückgabe via ara::core::Result<void>, um Latenzen in zeitkritischen Kommunikations- oder Routingpfaden (z. B. Firewall) auszuschließen.

4. Normative Relevanz & Entwickler-Hinweise

• Daemon-to-Daemon Interaktionsmodell: Da alle beteiligten FCs als daemon-based klassifiziert sind, erfolgt die Kommunikation prozessübergreifend. Die Implementierung erfordert ein performantes IPC-Transport-Binding der Adaptive Platform (z. B. via Shared Memory oder Domain Sockets unter Linux/QNX).
• Manifest- & Port-Konfiguration:
  • In den jeweiligen Execution Manifests und Service Instance Manifests müssen die meldenden FCs als R-Port (RPortPrototype typisiert mit EventReporter) und der IdsM als P-Port (PPortPrototype) modelliert und gebunden werden.
  • Jedes meldbare Ereignis muss im ARXML-Datenmodell (IdsMConfiguration) eindeutig definiert sein; nicht deklarierte Event-IDs werden von ReportEvent() zurückgewiesen.
• Echtzeit- und Latenzschutz: Melder dürfen bei Ausfall oder Überlastung des IdsM-Daemons nicht blockieren. Entwickler von Firewall- und Kommunikations-Stacks müssen sicherstellen, dass ReportEvent() asynchron abgesetzt oder ein lokaler Ringpuffer vorgeschaltet wird, falls der IdsM nicht antwortet.