Figure 9.61: Interfaces for providing additional data for security events

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm gemäß AUTOSAR Adaptive Platform (AP) Metamodell.
• Funktionaler Kontext: Architektur zur dynamischen Datenanreicherung von Sicherheitsereignissen (Security Events / Qualified Security Events – QSE) im AUTOSAR Adaptive Intrusion Detection System Manager (IdsM).
• Architektonische Einordnung: Dargestellt ist das daemon-basierte IdsM-Deployment («aapFunctionalCluster» Intrusion Detection System Manager daemon-based). Die Datenanreicherung (Zeitstempel, applikationsspezifischer Kontext) erfolgt über eine Kontrollfluss-Inversion: Die Applikation (Adaptive Application) dient als Provider, während der zentrale IdsM-Daemon als Consumer agiert.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Komponenten

• Adaptive Application (Komponente): Applikationsprozess im User Space, welcher spezifische Laufzeitdaten bereitstellt.
• Intrusion Detection System Manager («aapFunctionalCluster», Ausprägung: daemon-based): Zentraler Sicherheits-Daemon der Plattform zur Aggregation, Filterung und Weiterleitung von Security Events an das Security Event Memory (SEM) bzw. ein externes Security Operations Center (SOC).

Port-Interfaces & APIs

• TimestampProvider («aapAPI,aapPortInterface»):
  • Schnittstelle zur Bereitstellung synchronisierter oder hochpräziser Zeitstempel.
  • Service-Lifecycle-Methoden: + Offer(), + StopOffer() zur Bekanntmachung bzw. Rücknahme der Service-Verfügbarkeit.
  • Callback-Methode («aapCallbackMethod»): + GetTimestamp() – wird vom IdsM abgefragt, um den exakten Erfassungszeitpunkt eines Events zu ermitteln.
• ContextDataProvider («aapAPI,aapPortInterface»):
  • Schnittstelle zur Bereitstellung und Modifikation von Kontextdaten (z. B. Systemzustand, Umgebungsdaten, Session-IDs).
  • Service-Lifecycle-Methoden: + Offer(), + StopOffer().
  • Callback-Methode («aapCallbackMethod»): + ModifyContextData() – ermöglicht das Manipulieren, Ergänzen oder Serialisieren von applikationsspezifischen Kontextinformationen direkt im Security-Event-Datensatz.

Beziehungen & Abhängigkeiten

• «aapProvidedPort» (Realisierungsbeziehung): Die Adaptive Application realisiert und exponiert beide Schnittstellen (TimestampProvider, ContextDataProvider) als Server/Provider über definierte Ports.
• «use» (Nutzungsbeziehung): Der Intrusion Detection System Manager besitzt eine gerichtete Client-Abhängigkeit auf die Interfaces beider Ports, um die Callback-Funktionen aufzurufen.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungs- & Registrierungsphase (Lifecycle):
   • Die Adaptive Application instanziiert die Provider-Klassen und meldet die Schnittstellen über Offer() an den Plattform-IPC / Service Discovery an.
   • Der IdsM-Daemon bindet die angebotenen Endpunkte.
2. Ereignis-Verarbeitung (Event Trigger):
   • Ein Security Event tritt auf (z. B. interner Sensor-Report, protokollierte Fehlauthentifizierung oder Schwellwertüberschreitung).
   • Zeitstempel-Erfassung: Der IdsM ruft synchron oder asynchron via IPC die Methode GetTimestamp() auf.
   • Kontextdaten-Anreicherung: Der IdsM ruft ModifyContextData() auf und übergibt die Rohdaten; die Applikation ergänzt prozesslokale Kontextdaten im Puffer.
3. De-Initialisierung:
   • Beim Herunterfahren oder Neustarten der Applikation wird StopOffer() ausgeführt. Der IdsM-Daemon fällt auf interne Standard-Zeitstempel (z. B. Posix CLOCK_MONOTONIC/CLOCK_REALTIME) zurück bzw. verwirft die Kontextdatenanreicherung für nachfolgende Events.

4. Normative Relevanz & Entwickler-Hinweise

• IPC- & Performance-Overhead: Da der IdsM als Daemon operiert, überqueren die Aufrufe GetTimestamp() und ModifyContextData() Prozessgrenzen via IPC (z. B. Unix Domain Sockets / ARA::COM). Entwickler müssen sicherstellen, dass die Implementierung der Callbacks strikt nicht-blockierend, reentrant und latenzarm ausgeführt ist, um einen Pufferüberlauf im IdsM-Ereignispuffer (QSE Buffer Overflow) zu verhindern.
• Architektonische Inversion: Entwickler dürfen den IdsM hier nicht als klassischen Service aufrufen (ProvidedPort liegt bei der Applikation). Die Applikation agiert als Dienstleister für den Sicherheits-Daemon.
• Manifest-Konfiguration:
  • Im Application Design Manifest müssen die Port-Prototypen als PPortPrototype mit typisierten PortInterface-Referenzen für TimestampProvider und ContextDataProvider modelliert werden.
  • Im Execution Manifest müssen entsprechende Prozess- und IPC-Berechtigungen gesetzt werden, damit der IdsM-Daemon auf die Applikations-Endpoints zugreifen darf (Access Control / SE-Linux Policies).
• Fallback-Strategie: Fällt die Adaptive Application aus oder wird StopOffer() getriggert, muss der IdsM-Stack robust gegen Timeouts sein und valide Default-Werte für Timestamp und Context Data erzeugen können, ohne Sicherheitsereignisse unprotokolliert zu verwerfen.