Figure 5.2: Interfaces required by Intrusion Detection System Mananger from other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Architektur-Schnittstellendiagramm (AUTOSAR Adaptive Platform UML-Profil mit Stereotypen «aapFunctionalCluster», «aapAPI», «aapPortInterface», «aapNativeInterface», «aapRequiredPort»).
• Funktionale Einordnung: Spezifikation der architektonischen Abhängigkeiten des Intrusion Detection System Manager (IdsM) von anderen Functional Clusters (FC) innerhalb der AUTOSAR Adaptive Platform (R23-11, SWS_IntrusionDetectionSystemManager, Section 5.2).
• Technischer Zweck: Der IdsM-Dämon sammelt, filtert und aggregiert Security-Events (SEv/QSEv) aus der Plattform und den Applikationen. Für zeitliche Korrelation, Ereignisspeicherung, Diagnose und Integritätsschutz benötigt er Basisdienste für Zeitsynchronisation, System-Logging und Kryptografie.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Functional Clusters

• «aapFunctionalCluster» Intrusion Detection System Manager (daemon-based):
  • Zentraler Dämon-Prozess der Adaptive Platform zur Erkennung und Weiterleitung von Cyber-Angriffen.
  • Agiert als Konsument bezüglich aller drei referenzierten Plattform-Cluster.
• «aapFunctionalCluster» Time Synchronization (daemon-based):
  • Dämon-basierter Cluster zur netzwerkweiten Uhrensynchronisation (z. B. IEEE 802.1AS / PTP, CAN-TS).
• «aapFunctionalCluster» Log and Trace:
  • Plattformcluster zur standardisierten Protokollierung (ara::log).
• «aapFunctionalCluster» Cryptography (daemon-based):
  • Dämon-basierter Krypto-Cluster (ara::crypto) für Schlüsselverwaltung und kryptografische Operationen.

Schnittstellen & Stereotypen

• «aapAPI, aapPortInterface» SynchronizedTimeBaseConsumer:
  • Bindung: Dienstbasierte Port-Schnittstelle («aapRequiredPort», «use»), realisiert durch Time Synchronization.
  • Operationen / Methoden:
    • Zeit- und Statusabfrage: GetRateDeviation(), GetTimeWithStatus(): SynchronizedTimeBaseStatus
    • Notifier-Registrierung (Observer-Pattern): RegisterStatusChangeNotifier(), RegisterSynchronizationStateChangeNotifier(), RegisterTimeLeapNotifier(), RegisterTimePrecisionMeasurementNotifier(), RegisterTimeValidationNotification()
    • Notifier-Deregistrierung: Entsprechende Unregister...()-Methoden für alle oben genannten Notifier.
• «aapAPI, aapNativeInterface» Logger:
  • Bindung: Lokales C++-Interface («use», statisch/dynamisch gelinkte Client-Bibliothek), realisiert durch Log and Trace.
  • Operationen: IsEnabled(): bool, Log(MsgId, Params), WithLevel(): LogStream sowie niveauspezifische Stream-Fabriken LogDebug(), LogError(), LogFatal(), LogInfo(), LogVerbose(), LogWarn().
• «aapAPI, aapNativeInterface» CryptoStack:
  • Bindung: Lokales C++-Interface («use», native Client-Bibliothek zu Dämon-IPC), realisiert durch Cryptography.
  • Inhalt: Kapselt Standardfunktionen von ara::crypto (z. B. Hashing, Message Authentication Codes, digitale Signaturen).

Beziehungen

• Realization (gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze):
  • Time Synchronization implementiert SynchronizedTimeBaseConsumer.
  • Log and Trace implementiert Logger.
  • Cryptography implementiert CryptoStack.
• Usage Dependency («use», gestrichelte Linie mit offener Pfeilspitze):
  • IdsM konsumiert SynchronizedTimeBaseConsumer über einen formalen Adaptive-Port («aapRequiredPort»).
  • IdsM konsumiert Logger und CryptoStack prozesslokal über Native Interfaces (keine ARXML-Port-Modellierung).

3. Dynamisches Verhalten & Sequenzablauf

• Zeiterfassung & Event-Zeitstempelung (synchron):
  • Bei Eintreffen eines Security Events fragt der IdsM synchron über GetTimeWithStatus() den aktuellen Systemzeitstempel und dessen Synchronisationsstatus ab, um Qualified Security Event Reports (QSER) forensisch verwertbar zu datieren.
• Synchronisationsüberwachung & Zeitsprünge (asynchron/Callback):
  • IdsM registriert sich während der Initialisierungsphase über RegisterSynchronizationStateChangeNotifier() und RegisterTimeLeapNotifier().
  • Bei Verlust des Synchronisationsstatus (SynchronizedTimeBaseStatus) oder plötzlichen Zeitsprüngen (z. B. durch NTP/PTP-Manipulation als Angriffsvektor) wird der IdsM asynchron benachrichtigt und kann selbst ein Security Event generieren.
• Plattform-Logging (synchron/buffered):
  • Fehler bei der Event-Filterung, Pufferüberläufe oder interne Zustandswechsel werden über die Stream-Operatoren (LogError(): LogStream, LogWarn(): LogStream) in das Log and Trace-Backend geschrieben.
• Kryptografische Signatur/Verschlüsselung:
  • Vor dem Absenden gesammelter Security-Reports an ein fahrzeugweites Gateway oder ein Backend (Security Operation Center / SOC) nutzt der IdsM den CryptoStack synchron oder asynchron zur Berechnung von Signaturen/MACs zwecks Replay- und Manipulationsschutz.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML- / Manifest-Konfiguration:
  • Der Entwickler muss im Executable- / Service-Instance-Manifest des IdsM einen RPortPrototype anlegen, der das SynchronizedTimeBaseConsumer-Interface typisiert und auf die konkrete Instanz des TimeSync-Dämons bindet.
  • Für Logger und CryptoStack ist keine Service-Port-Konfiguration erforderlich; die Einbindung erfolgt über Linker-Flags gegen ara::log und ara::crypto sowie Prozessdeklarationen im Execution Manifest.
• Fehlerbehandlung bei Zeit-Ungültigkeit:
  • Zeitabfragen dürfen nicht blockieren. Der Entwickler muss den Rückgabewert SynchronizedTimeBaseStatus von GetTimeWithStatus() zwingend validieren. Ein Zustand TIMEOUT oder SYNC_LOST muss im Security-Report als fehlerhafte Zeitbasis vermerkt werden.
• Prozess-Lifecycle (daemon-based):
  • IdsM, Time Synchronization und Cryptography laufen als getrennte POSIX-Dämonen. Der Execution Manager (EM) muss über Startup-Dependencies sicherstellen, dass TimeSync und CryptoStack vollständig initialisiert sind, bevor der IdsM in den Running-State wechselt.
• Resource-Management & Non-Blocking-Anforderung:
  • In High-Frequency-Angriffsszenarien (DDoS auf den IdsM) darf der Aufruf von Logger (ara::log) nicht den IdsM-Hauptthread blockieren (Konfiguration von asynchronen Ringpuffern im Log-Cluster zwingend erforderlich).