Figure 9.76: 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, Execution Management) 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). Sein Prozesslebenszyklus wird über das Execution Management gesteuert.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Functional Cluster

• «aapFunctionalCluster» Intrusion Detection System Manager: Konsumierender Plattform-Daemon (daemon-based), welcher die Sicherheitsüberwachung hostet.
• «aapFunctionalCluster» Execution Management: Bereitstellender Plattform-Daemon (daemon-based) zur Steuerung des Prozesslebenszyklus und der Ausführungszustände.
• «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, aapNativeInterface» ExecutionClient:
  • Typ: Prozesslokale C++ Native API (ara::exec).
  • Methoden / Operationen: Create(), ReportExecutionState(ExecutionState).
• «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 ExecutionClient, SynchronizedTimeBaseConsumer, Logger, CryptoStack und TCP/IP Stack.
• Realisierungsbeziehungen (--|>):
  • Execution Management realisiert ExecutionClient.
  • Time Synchronization realisiert SynchronizedTimeBaseConsumer.
  • Log and Trace realisiert Logger.
  • Cryptography realisiert CryptoStack.
  • Operating System realisiert TCP/IP Stack.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Lebenszyklus-Meldung:
   • IdsM instanziiert beim Start den ExecutionClient über Create() und meldet nach Abschluss der internen Initialisierung seinen Zustand via ReportExecutionState(ExecutionState) (z. B. kRunning) an das Execution Management.
2. Status-Überwachung & Zeitbasis:
   • IdsM registriert sich ü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.
3. 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.
4. 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.
5. 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.
6. 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 die Deklaration des Prozesses unter Execution Management sowie ausreichende OS-Privilegien (z. B. POSIX Capabilities für Socket-Erzeugung / Raw Network Access), um direkt auf den TCP/IP Stack des OS zuzugreifen.
• Lebenszyklus-Integration:
  • Der IdsM ist normativ verpflichtet, sich als Plattform-Daemon über ara::exec::ExecutionClient an Execution Management anzubinden und seinen Laufzeitzustand (ReportExecutionState) zeitgerecht zu melden, um Watchdog-Timeouts und Terminierungen zu verhindern.
• 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.