Figure 11.21: Scenario: Report Security Event

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck & Einordnung: Spezifikation des Zusammenspiels zwischen dem Betriebssystem-Netzwerkstack (OS), dem Functional Cluster Firewall und dem Functional Cluster Intrusion Detection System Manager (IdsM) innerhalb der AUTOSAR Adaptive Platform (AP R23-11, Kapitel 11.4.1.2 Report Security Event).
• Systemkontext: Entkopplung der Low-Level-Paketfilterung auf OS-/Kernelebene von der standardisierten Sicherheitsüberwachung (Security Event Reporting) der Adaptive Platform zur Detektion von Angriffsvektoren und Regelverletzungen.

2. Komponenten, Entitäten & Schnittstellen

• :Operating System (UML-Akteur):
  • Repräsentiert das zugrunde liegende POSIX-kompatible Betriebssystem inkl. Netzwerk-Treiberstack und nativer Paketfilter-Engine (z. B. nftables, iptables, eBPF oder herstellerspezifische IP-Stack-Module).
• «aapFunctionalCluster» :Firewall:
  • Instanz des AUTOSAR Adaptive Platform Functional Clusters Firewall.
  • Stereotyp: «aapFunctionalCluster».
  • Fungiert als Vermittlungs- und Abstraktionsschicht zwischen nativer OS-Filter-Engine und AP-Laufzeitumgebung. Mappt OS-spezifische Filterereignisse auf formal spezifizierte Sicherheitsereignisse.
• «aapFunctionalCluster» :Intrusion Detection System Manager:
  • Instanz des AUTOSAR Adaptive Platform Functional Clusters IdsM.
  • Stereotyp: «aapFunctionalCluster».
  • Zentrale Instanz zur Aggregation, Filterung, Ratenbegrenzung und Persistierung/Weiterleitung von Security Events an fahrzeuginterne oder externe Security-Backends (VSOC).
• Schnittstellen & Operationen:
  • «aapInformative» packetBlocked(): OS-interne Ausführungsfunktion / Signal nach Regelabgleich (mit Stereotyp «aapInformative» als rein informativ gekennzeichnet).
  • «aapInformative» handlePacketBlocked(): Plattform-/implementierungsspezifische Schnittstelle (z. B. Socket, Netlink/NFQUEUE, ULOG, Hook) vom OS an den Firewall-Cluster (mit Stereotyp «aapInformative» als rein informativ gekennzeichnet).
  • «aapInformative» raiseSecurityEvent(): Cluster-interne Bewertungs- und Mapping-Funktion der Firewall (mit Stereotyp «aapInformative» als rein informativ gekennzeichnet).
  • ReportEvent(): Standardisierte funktionale Schnittstelle des IdsM zur Annahme von Security Events (ara::idsm::ReportEvent).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger / packetBlocked() (Self-Call OS): Ein eingehendes oder ausgehendes IP-/Ethernet-Paket verletzt eine aktive Firewall-Regel auf OS-Ebene und wird verworfen (Drop/Reject).
2. handlePacketBlocked() (OS → :Firewall): Das OS signalisiert den Blockiervorgang samt Metadaten (z. B. Interface, Header-Auszug, Regel-ID) an den Userspace-Dienst des Firewall Functional Clusters. Dieser Pfad ist typischerweise asynchron entkoppelt, um den Durchsatz des OS-Netzwerkstacks nicht durch AP-IPC zu blockieren.
3. raiseSecurityEvent() (Self-Call :Firewall): Die Firewall prüft anhand des Execution Manifests, ob für die verletzte Regel eine Zuordnung zu einem konkreten Security Event (SecurityEventDefinition) konfiguriert ist:
   • Bedingung nicht erfüllt: Sequenz bricht ab; das Paket bleibt verworfen, ohne Event-Erzeugung.
   • Bedingung erfüllt: Die Firewall erzeugt das entsprechende Security Event inklusive zugehöriger Kontextdaten.
4. ReportEvent() (:Firewall → :Intrusion Detection System Manager): Die Firewall meldet das Ereignis synchron oder asynchron an den IdsM zur weiteren Auswertung und Speicherung.

4. Normative Relevanz & Entwickler-Hinweise

• Aufgabenteilung OS vs. AP: Der Functional Cluster Firewall ist kein eigenständiger Userspace-Paketfilter, sondern eine Konfigurations- und Event-Brücke. Paketprüfung und -verwerfung müssen aus Performance- und Latenzgründen im OS-Kernel bzw. Hardware-Beschleuniger verbleiben.
• Manifest-Konfiguration: Nicht jedes blockierte Paket führt zu einem Security Event. Die Zuordnung zwischen Paketfilterregel und Security Event muss im Manifest explizit deklariert sein, um Denial-of-Service-Effekte (Event-Flooding) auf den IdsM zu vermeiden.
• Context-Data-Vertrag: Entwickler des Firewall-Integrationsmoduls müssen sicherstellen, dass bei Aufruf von ReportEvent() die erforderlichen Kontextdaten (z. B. Rule-ID, Quell-/Ziel-Adresse, Port) kompatibel zu den IdsM-Event-Typdefinitionen übergeben werden.
• Schutz vor DoS/Starvation: Wegen potenzieller Angriffe mit hohem Paketaufkommen muss der Übergang handlePacketBlocked() ratenbegrenzt oder gepuffert werden, damit die Interprozesskommunikation der Adaptive Platform nicht überlastet wird.