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 (R25-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, Integritätsschutz und Lifecycle-Management benötigt er Basisdienste für Zeitsynchronisation, System-Logging, Prozessüberwachung (Execution Management) 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 vier 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» Execution Management (daemon-based):
  • Dämon-basierter Plattformcluster zur Prozessinitialisierung, Zustandsverwaltung und Überwachung des Applikationslebenszyklus.
• «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» ExecutionClient:
  • Bindung: Lokales C++-Interface («use», native Client-Bibliothek ara::exec), realisiert durch Execution Management.
  • Operationen: Create(), ReportExecutionState(ExecutionState).
• «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.
  • Execution Management implementiert ExecutionClient.
  • Cryptography implementiert CryptoStack.
• Usage Dependency («use», gestrichelte Linie mit offener Pfeilspitze):
  • IdsM konsumiert SynchronizedTimeBaseConsumer über einen formalen Adaptive-Port («aapRequiredPort»).
  • IdsM konsumiert Logger, ExecutionClient und CryptoStack prozesslokal über Native Interfaces (keine ARXML-Port-Modellierung).

3. Dynamisches Verhalten & Sequenzablauf

• Lebenszyklus- & Zustandsmeldung (synchron):
  • Nach dem Prozessstart erzeugt der IdsM über ExecutionClient::Create() eine Client-Instanz und meldet seinen Initialisierungszustand (ReportExecutionState(ExecutionState), z. B. kRunning) an das Execution Management, um die Betriebsbereitschaft des Security-Subsystems zu bestätigen.
• 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, ExecutionClient und CryptoStack ist keine Service-Port-Konfiguration erforderlich; die Einbindung erfolgt über native Bibliotheken (ara::log, ara::exec, ara::crypto) und Prozessdeklarationen im Execution Manifest.
• Lifecycle-Management (ara::exec):
  • Der IdsM muss ReportExecutionState(kRunning) innerhalb des im Execution Manifest definierten Startzeit-Timeouts aufrufen. Unterbleibt dies, wertet das Execution Management den IdsM-Start als fehlgeschlagen und löst je nach Recovery-Strategie einen Prozessneustart oder Safe-State-Wechsel aus.
• 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, Execution Management und Cryptography laufen als getrennte POSIX-Dämonen. Das Execution Management steuert die Startup-Dependencies und stellt sicher, dass TimeSync und CryptoStack initialisiert sind, bevor der IdsM seinen regulären Filterbetrieb aufnimmt.
• 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).