Figure 9.72: Interfaces for reporting security events

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm mit Schnittstellen- und Realisierungsbeziehungen, annotiert mit Stereotypen des AUTOSAR Adaptive Platform (AAP) Profils.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP Release R24-11), Funktionsbereich Intrusion Detection System (IDS).
• Technischer Zweck: Spezifikation der standardisierten Schnittstellen zur Meldung sicherheitsrelevanter Ereignisse (EventReporter) sowie zur Steuerung und Abfrage des Reporting-Modus (ReportingModeProvider) zwischen einer Adaptive Application und dem zentralen Intrusion Detection System Manager (IdsM).

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application (UML-Komponente):
  • Repräsentiert einen Prozess im User-Space der Adaptive Platform, der als Security-Event-Sensor fungiert und über Ports auf die IdsM-Schnittstellen zugreift.
• «aapPortInterface,aapAPI» EventReporter (UML-Interface):
  • Stereotypen: «aapPortInterface», «aapAPI» (C++ Programmierschnittstelle ara::idsm::EventReporter).
  • Operationen: + ReportEvent(): Öffentliche Methode zum Übermitteln von Security Events inklusive Event-ID und optionaler Kontextdaten.
• «aapAPI,aapPortInterface» ReportingModeProvider (UML-Interface):
  • Stereotypen: «aapAPI», «aapPortInterface» (C++ Programmierschnittstelle ara::idsm::ReportingModeProvider).
  • Operationen:
    • + GetReportingMode(): Öffentliche Methode zur Abfrage des aktuellen Reporting-Modus des IdsM.
    • + SetReportingMode(): Öffentliche Methode zum Konfigurieren bzw. Umschalten des Reporting-Modus.
• «aapFunctionalCluster» Intrusion Detection System Manager (UML-Komponente):
  • Stereotyp: «aapFunctionalCluster»: Standardisierter Kernbestandteil der Adaptive Platform Architecture.
  • Realisierungsform: daemon-based: Läuft als eigenständiger System-Daemon/Dienstprozess auf OS-Ebene.
• Beziehungen:
  • Adaptive Application –«use»→ EventReporter: Abhängigkeitsbeziehung (Client-Nutzung zum Melden von Events).
  • Adaptive Application –«use»→ ReportingModeProvider: Abhängigkeitsbeziehung (Client-Nutzung zur Abfrage und Steuerung des Reporting-Modus).
  • Intrusion Detection System Manager $\dashrightarrow \triangle$ EventReporter: Schnittstellen-Realisierung durch den IdsM-Daemon.
  • Intrusion Detection System Manager $\dashrightarrow \triangle$ ReportingModeProvider: Schnittstellen-Realisierung durch den IdsM-Daemon.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Modusverwaltung:
   • Eine autorisierte Adaptive Application kann über GetReportingMode() den aktuellen Überwachungszustand des IdsM abfragen bzw. mittels SetReportingMode() den aktiven Reporting-Modus steuern (z. B. Aktivierung/Deaktivierung bestimmter Reporting-Klassen).
2. Security-Event-Trigger: Eine Adaptive Application erkennt zur Laufzeit ein sicherheitskritisches Ereignis.
3. Synchroner API-Aufruf: Die Applikation ruft ReportEvent() der Client-Bibliothek (ara::idsm) auf.
4. IPC-Transport: Die Aufrufe beider Schnittstellen (EventReporter, ReportingModeProvider) werden über Inter-Process-Communication an den daemon-basierten Intrusion Detection System Manager übertragen.
5. Daemon-Verarbeitung: Der IdsM-Daemon verarbeitet Moduskonfigurationen und filtert/aggregiert gemeldete Security Events gemäß den aktiven Filter- und Reporting-Regeln.
6. Rückmeldung: Beide Schnittstellen bestätigen die Entgegennahme der Anfragen über Standard-Rückgabetypen (ara::core::Result).

4. Normative Relevanz & Entwickler-Hinweise

• API- und Manifest-Vertrag:
  • Entwickler einer Adaptive Application müssen in den ARXML-Modellen (Application Design / Execution Manifest) Service-Ports für EventReporter und gegebenenfalls ReportingModeProvider konfigurieren und an die entsprechenden IdsM-Instanzen binden.
• Zugriffskontrolle & Privilegien:
  • Während das Melden von Ereignissen (EventReporter) typischerweise breiter gestreut für überwachte Applikationen zugänglich ist, erfordert die Modus-Steuerung (SetReportingMode()) restriktive Berechtigungen (z. B. Identity and Access Management / IAM), um unbefugtes Deaktivieren oder Manipulieren des IDS-Monitorings zu unterbinden.
• Architektur-Entkopplung:
  • Die Aufteilung in zwei funktionale Interfaces trennt administrative Steuerungsaufgaben sauber vom kontinuierlichen Sensor-Reporting, während die daemon-basierte Architektur eine robuste, nicht-blockierende Ausführung sicherstellt.