Figure 10.10: Use cases for Firewall

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Use-Case-Diagramm (Anwendungsfalldiagramm) unter Verwendung des AUTOSAR Adaptive Platform (AP) Metamodell-Stereotypprofils («aapUseCase», «aapFunctionalCluster», «aapTriggers», «aapParticipates»).
• Funktionale Einordnung: AUTOSAR Adaptive Platform Security-Architektur (Spezifikationsdokument: AUTOSAR_EXP_SWArchitecture, Kapitel Firewall / Release R22-11).
• Technischer Zweck: Spezifikation der funktionalen Abgrenzung und Schnittstelleninteraktionen des Subsystems Firewall mit Akteuren der Plattform (Anwendungsebene, Kernel/OS) sowie dem Intrusion Detection System (IdsM).

2. Komponenten, Entitäten & Schnittstellen

System- und Subsystemgrenzen

• Adaptive Platform: Äußere Systemgrenze der Plattform-Laufzeitumgebung.
• Firewall: Subsystemgrenze des logischen Firewall-Clusters zur Regelwerk- und Filterverwaltung auf AP-Ebene.

Akteure (Actors)

• Adaptive Application (from Actors): Nutzer- oder Plattformapplikation (typischerweise State Management, Diagnose-Manager oder Update/OTA-Client), die autorisierte Systemzustandswechsel anfordert.
• Operating System (from Actors): POSIX-konformes Betriebssystem bzw. Kernel-Network-Stack (z. B. Linux netfilter/nftables, eBPF/XDP oder hardwarebeschleunigte Switch-Treiber).

Anwendungsfälle («aapUseCase»)

• Switch Firewall State: Dynamisches Umschalten des Firewall-Zustands bzw. Aktivieren alternativer Regelsätze (z. B. Umschaltung zwischen Normal Operation, Diagnostic Mode, Production Mode oder Failsafe).
• Report Security Event: Signalisierung detektierter Sicherheitsvorfälle (z. B. verworfene Pakete, Port-Scans, Rate-Limit-Überschreitungen, Spoofing-Versuche).

Funktionscluster («aapFunctionalCluster»)

• Intrusion Detection System Manager (IdsM): Standardisierter Plattform-Daemon (daemon-based). Fungiert als zentraler Empfänger, Filter und Aggregator für sicherheitsrelevante Ereignisse (Security Events) gemäß AUTOSAR-Spezifikation vor der Weiterleitung an ein bordnetz- oder backend-seitiges VSOC/SIEM.

Beziehungen & Stereotypen

• Adaptive Application $\xrightarrow{«\text{aapTriggers}»}$ Switch Firewall State: Unidirektionaler Auslöser; eine Applikation initiiert die Zustandsänderung über eine IPC-/ara-API.
• Operating System $\xleftarrow{«\text{aapParticipates}»}$ Switch Firewall State: Assoziation zur technischen Umsetzung; das OS realisiert die Filterkonfiguration auf Netzwerk- und Socket-Ebene.
• Operating System $\xrightarrow{«\text{aapTriggers}»}$ Report Security Event: Auslöser; Paketfilter oder Socket-Hooks des Kernels erkennen Anomalien und erzeugen Roh-Events.
• Report Security Event $\xrightarrow{«\text{aapParticipates}»}$ Intrusion Detection System Manager: Interaktion zur Weiterverarbeitung; das IdsM nimmt die standardisierten Security-Events über dessen IPC/OS-Schnittstelle entgegen.

3. Dynamisches Verhalten & Sequenzablauf

Use Case 1: Switch Firewall State (Zustandsumschaltung)

1. Trigger: Adaptive Application sendet einen Zustandswechsel-Request (z. B. ausgelöst durch SM-Zustandswechsel via ara::exec / ara::sm).
2. Rechteprüfung & Validierung: Die Firewall-Logik validiert Identität, Berechtigung (IAM – Identity and Access Management) und die Gültigkeit des Zielzustands.
3. OS-Interaktion (Participation): Die Firewall übersetzt den logischen Zustand in Betriebssystem-spezifische Filterregeln (z. B. atomic commit via nftables Ruleset, Manipulation von Routing-Tabellen oder Hardware-Offload-Registern).
4. Rückmeldung: Synchrone oder asynchrone Bestätigung des Zustandswechsels an die aufrufende Applikation.

Use Case 2: Report Security Event (Sicherheitsereignis melden)

1. Trigger: Netzwerk-Ingress-Verkehr verletzt eine aktive Firewall-Regel im Operating System.
2. Paketbehandlung: Das OS verwirft (DROP/REJECT) das Paket oder leitet es in eine Rate-Limiting-Queue um.
3. Event-Generierung: Das Kernel-Subsystem oder ein Userspace-Monitoring-Agent generiert einen Security-Event-Datensatz (IP, Port, Interface, Timestamp, Regel-ID).
4. IdsM-Reporting (Participation): Übermittlung des Events an den Intrusion Detection System Manager via IdsM-Reporting-Interface (IPC). Das IdsM führt Qualifikation, Kontextualisierung und Drosselung (Traffic Limiting) durch.

4. Normative Relevanz & Entwickler-Hinweise

• Architektonische Trennung (Separation of Concerns):
  • Applikationen steuern die Firewall ausschließlich indirekt über logische Zustände, niemals durch direkte Injektion roher Low-Level-Paketfilterregeln (IP/Port).
  • Paketinspektion und Drop-Entscheidungen verbleiben aus Performance- und Latenzgründen direkt im Kernelspace des Operating System.
• Sicherheits- und Zugriffssteuerung (IAM / Capabilities):
  • Entwickler von Adaptive Applications müssen für Switch Firewall State entsprechende Berechtigungen im Manifest (Execution / Service Instance Manifest, IAM) deklarieren. Nicht autorisierte Zugriffe werden plattformseitig blockiert.
• IdsM-Integration & Logging-Overhead:
  • Das OS-Reporting an den IdsM-Daemon darf den Echtzeit-Netzwerkstack nicht blockieren. Entwickler müssen asynchrone Queues/Ringspeicher (z. B. netlink-Sockets, Kernel-Ringbuffer) vorsehen, um Denial-of-Service (DoS) gegen das Betriebssystem durch gezielt provozierte Logging-Spikes zu verhindern.
• Zustandssynchronisation:
  • Der Firewall-Zustand muss zwingend mit dem Plattform-Gesamtzustand konsistent synchronisiert sein (z. B. keine offenen Diagnoseports außerhalb authentifizierter Diagnosesitzungen).