Figure 9.62: Interfaces of Adaptive Intrusion Detection System Manager

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (AUTOSAR Adaptive Platform Architecture Modeling).
• Technischer Zweck & Einordnung: Spezifikation der Zugriffspfade einer Adaptive Application auf den funktionalen Cluster Adaptive Intrusion Detection System Manager (IdsM) gemäß AUTOSAR R21-11 (AUTOSAR_EXP_SWArchitecture). Der IdsM fungiert als Sicherheits-Cluster zur Erfassung, Filterung (Rate-Limiting, Thresholds) und Aggregation sicherheitsrelevanter Ereignisse (Security Events – SEv) zu qualifizierten Ereignissen (QSEv), die an On-Board- oder Off-Board-Sicherheitsinstanzen (Vehicle SOC / SIEM) weitergeleitet werden. Das Diagramm definiert die Trennung zwischen Service-/Port-basierter Ereignismeldung und nativer C++-API-Interaktion.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • Adaptive Application (Stereotyp: «component» via UML-Symbol oben rechts): Anwendungsinstanz im POSIX-User-Space, die als Security-Sensor fungiert.
  • Adaptive Intrusion Detection System Manager (Stereotyp: «aapFunctionalCluster», Ausprägung: daemon-based): Systemdienst der Adaptive Platform, der als eigenständiger Hintergrundprozess (Daemon) läuft.
• Schnittstellen & Operationen:
  • EventReporter (Stereotypen: «aapPortInterface,aapAPI»):
    • Operation: + ReportEvent()
    • Standardisierte Port-Schnittstelle. Erlaubt der Applikation die standardisierte Meldung erkannter Anomalien/Sicherheitsvorfälle über ARA-Kommunikationskanäle (ara::com / Service-orientierte Schnittstelle).
  • Native Schnittstelle (Stereotypen: «aapNativeInterface,aapAPI»):
    • Operation: + RegisterTimestampProvider() (UML-Notation: statische Operation / unterstrichen).
    • Direkte C++ Native API (In-Process Linkage gegen die IdsM-Client-Bibliothek). Ermöglicht die systemweite Registrierung einer präzisen Zeitquelle (z. B. via ara::tsync / Time Synchronization) zur exakten zeitlichen Korrelation von Security Events.
• Beziehungen:
  • Interface Realization (gestrichelte Linie mit geschlossener, weißer Dreiecksspitze): Der Adaptive Intrusion Detection System Manager implementiert beide Schnittstellen (EventReporter und die native C++-API).
  • Usage Dependency (gestrichelte Linie mit offener Pfeilspitze, Stereotyp: «use»): Die Adaptive Application greift als Client/Consumer auf beide Schnittstellen zu.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungs- und Konfigurationsphase (Native API-Pfad):
   • Die Plattform bzw. eine autorisierte Adaptive Application ruft statisch RegisterTimestampProvider() auf.
   • Der IdsM-Client registriert die Callback-Schnittstelle/Funktor zur Zeitabfrage, um nachfolgende Security Events mit vertrauenswürdigen UTC-/Synch-Timestamps zu versehen.
2. Operativer Meldezyklus (Port-Interface-Pfad):
   • Trigger: Erkennung einer Anomalie (z. B. Authentifizierungsfehlschlag, ungültige Frame-Sequenzen, Interface-Violation) innerhalb der Adaptive Application.
   • Aufruf: Aufruf von ReportEvent() am konfigurierten R-Port der Applikation.
   • Verarbeitung: Synchrone oder entkoppelte asynchrone Übergabe über die lokale IPC-Schicht an den IdsM-Daemon (daemon-based).
   • Folgeaktionen im IdsM: Prüfung gegen Filterregeln (Filter Chain, Blocklisten, Schwellenwerte); bei Erreichen der Kriterien Generierung eines Qualified Security Event (QSEv).

4. Normative Relevanz & Entwickler-Hinweise

• Architekturtrennung (Port vs. Native):
  • EventReporter erfordert eine Modellierung im AUTOSAR-Modell (ARXML) mit Port-Prototypen (RPortPrototype an der Applikation, PPortPrototype am IdsM) sowie Service-Instance-Manifest-Mapping.
  • RegisterTimestampProvider() wird nicht über Ports modelliert, sondern als native C++-Schnittstelle direkt einkompiliert/gelinkt (Header-Inklusion aus dem ara::idsm- bzw. Security-Namespace).
• Daemon-Latenzen & Nicht-Blockierung: Da der IdsM daemon-based ausgeführt ist, läuft die Kommunikation zwischen Adaptive Application und IdsM prozessübergreifend via IPC. Implementierer müssen sicherstellen, dass ReportEvent() die Applikationslogik nicht blockiert (Zero-Copy-/Shared-Memory-IPC oder asynchrones Queuing), um Denial-of-Service-Zustände der meldenden Applikation bei Event-Flooding zu verhindern.
• Sicherheitskontext & Authentifizierung: Das Aufrufen von RegisterTimestampProvider() unterliegt strengen Zugriffsrechten (Integrity / Access Control Policies des POSIX-Betriebssystems), um Manipulationen an der zeitlichen Nachvollziehbarkeit von Sicherheitsvorfällen zu unterbinden.