Figure 9.71: Interfaces required by Intrusion Detection System Manager

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellen-Abhängigkeitsdiagramm der AUTOSAR Adaptive Platform (AP) Software-Architektur.
• Technischer Zweck: Spezifikation der ausgehenden Abhängigkeiten und Schnittstellenanforderungen des Functional Clusters Intrusion Detection System Manager (IdsM) zu benachbarten Plattform-Clustern (Time Synchronization, Log and Trace, Cryptography) sowie dem unterlagernden Operating System.
• Systemische Einordnung: Der IdsM fungiert als zentraler Sicherheits-Daemon (daemon-based) zur Erfassung, Filterung, Aggregation und Weiterleitung von sicherheitsrelevanten Vorfällen (Security Events / Qualified Security Events – QSEv) an fahrzeuginterne oder externe Sicherheitsinstanzen (z. B. VSOC).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Functional Cluster

• «aapFunctionalCluster» Intrusion Detection System Manager: Konsumierender Plattform-Daemon (daemon-based), welcher die Sicherheitsüberwachung hostet.
• «aapFunctionalCluster» Time Synchronization: Bereitstellender Plattform-Daemon (daemon-based) für netzwerkweit synchronisierte Zeitbasen (z. B. via IEEE 802.1AS / gPTP).
• «aapFunctionalCluster» Log and Trace: Plattform-Cluster für Laufzeitprotokollierung (ara::log).
• «aapFunctionalCluster» Cryptography: Plattform-Daemon (daemon-based) für kryptografische Operationen, Schlüsselspeicher und Zertifikatsmanagement (ara::crypto).
• Operating System: POSIX-kompatibles Betriebssystem / Adaptive Platform Foundation.

Schnittstellen & Stereotypen

• «aapAPI, aapPortInterface» SynchronizedTimeBaseConsumer:
  • Typ: Service-orientiertes Port-Interface («aapRequiredPort», Bindung über ara::com).
  • Methoden / Operationen:
    • Zeitabfrage: GetRateDeviation(), GetTimeWithStatus(): SynchronizedTimeBaseStatus.
    • Asynchrone Notifier-Registrierung: RegisterStatusChangeNotifier(), RegisterSynchronizationStateChangeNotifier(), RegisterTimeLeapNotifier(), RegisterTimePrecisionMeasurementNotifier(), RegisterTimeValidationNotification().
    • Notifier-Deregistrierung: Entsprechende Unregister*-Pendants.
• «aapAPI, aapNativeInterface» Logger:
  • Typ: Prozesslokale C++ Native API (ara::log).
  • Methoden / Operationen: IsEnabled(): bool, Log(MsgId, Params), WithLevel(): LogStream, typisierte Stream-Generatoren (LogDebug(), LogError(), LogFatal(), LogInfo(), LogVerbose(), LogWarn()).
• «aapAPI, aapNativeInterface» CryptoStack:
  • Typ: Native C++ API (ara::crypto) für kryptografische Primitiven.
• «aapInternal» TCP/IP Stack:
  • Typ: Interne Betriebssystem-Schnittstelle (POSIX Sockets / OS Network Stack) zur Netzwerkanbindung außerhalb von ara::com.

Beziehungen & Abhängigkeiten

• Nutzungsbeziehungen («use»): Gerichtete Abhängigkeiten vom IdsM zu den vier Schnittstellenblöcken.
• Realisierungsbeziehungen (--|>):
  • Time Synchronization realisiert SynchronizedTimeBaseConsumer.
  • Log and Trace realisiert Logger.
  • Cryptography realisiert CryptoStack.
  • Operating System realisiert TCP/IP Stack.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Status-Überwachung:
   • IdsM registriert sich beim Start über den Required Port an SynchronizedTimeBaseConsumer via RegisterStatusChangeNotifier() und RegisterTimeLeapNotifier(), um Zustandsänderungen der globalen Zeitbasis (z. B. Verlust des Grandmaster-Locks oder Zeitsprünge) asynchron über Callbacks gemeldet zu bekommen.
2. Event-Qualifizierung & Zeitstempelung (Synchroner Pfad):
   • Eintreffende Security Events (von Applikations-Sensoren via IPC/IdsM-Client) werden validiert.
   • IdsM ruft GetTimeWithStatus() auf, um dem forensischen Datensatz einen manipulationssicheren, synchronisierten UTC/TAI-Zeitstempel inklusive Validitätsstatus zuzuordnen.
3. Kryptografische Absicherung (Synchroner/Asynchroner Pfad):
   • Vor der Persistierung oder Übertragung ruft der IdsM native Schnittstellen des CryptoStack auf, um Security Event Reports via HMAC/CMAC zu signieren, Signaturen zu validieren oder Payloads asymmetrisch/symmetrisch zu verschlüsseln.
4. Export / Telemetrie (Transportpfad):
   • Über den TCP/IP Stack des OS sendet der IdsM serialisierte Qualified Security Event Messages (z. B. per TLS/TCP oder IPFIX) an ein fahrzeugzentrales IDS oder direkt an ein Backend.
5. Diagnose & Fehlerbehandlung:
   • Protokollierung interner Statuswechsel, Filterdropraten oder Kommunikationsfehler über Logger::LogWarn() / Logger::LogError().

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration:
  • Für den IdsM muss im Service Instance Manifest ein Required Port («aapRequiredPort») für die ara::tsync-Service-Schnittstelle (SynchronizedTimeBaseConsumer) deklariert und an den Provider von Time Synchronization gebunden werden.
  • Das Execution Manifest des IdsM erfordert ausreichende OS-Privilegien (z. B. POSIX Capabilities für Socket-Erzeugung / Raw Network Access), um direkt auf den TCP/IP Stack des OS zuzugreifen.
• Einschränkungen der Zeitbasis:
  • IdsM-Implementierer müssen bei der Protokollierung von Events das Rückgabe-Attribut SynchronizedTimeBaseStatus auswerten. Falls die Zeitbasis im Status TIMEOUT oder UNSYNC ist, dürfen Security Events nicht als forensisch synchronisiert deklariert werden; sie müssen als ungesichert/lokal markiert werden.
• Performance & Entkopplung:
  • Aufrufe von ara::log und ara::crypto erfolgen prozesslokal via C++-Header/Library-Bindings (aapNativeInterface). Kryptografische Berechnungen bei hohen Event-Raten müssen asynchron gepuffert werden, um ein Blockieren des IdsM-Main-Loops und damit Event-Drops bei Denial-of-Service-Angriffen zu verhindern.
• Kommunikationsarchitektur:
  • Die Ausleitung der Daten erfolgt explizit nicht über ein ara::com-Service-Interface, sondern über die native «aapInternal» TCP/IP Stack-Schnittstelle. Dies ermöglicht standardisierte Protokolle (z. B. Syslog, TLS, MQTT) für Backend-/SIEM-Verbindungen ohne zusätzlichen Service-Overhead.