Figure 7.2: Architecture of the FC Firewall

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturschaubild / Kontext-Blockdiagramm der AUTOSAR Adaptive Platform (AP).
• Funktionale Einordnung: Spezifiziert die Systemarchitektur und Interaktionsgrenzen des Functional Clusters FC Firewall (AUTOSAR_AP_SWS_Firewall). Das Diagramm trennt deklarative Konfiguration (Machine Manifest), Management- und Steuerlogik (FC Firewall), datenpfadgebundene Regeldurchsetzung (Firewall Engine), dynamische Betriebsmodussteuerung (OEM application) und sicherheitsrelevantes Audit-Reporting (IdsM).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Komponenten

• Machine Manifest: AUTOSAR-Deployment-Artefakt für die Zielmaschine. Beinhaltet deklarative Regelsätze (Filter rule), die statisch Paket-Header, Protokolle (IPv4, IPv6, TCP, UDP, ICMP), Netzwerkschnittstellen, Adressbereiche und Portgrenzen definieren.
• FC Firewall (Functional Cluster Firewall): Zentrale Management- und Orchestrierungskomponente im Adaptive User Space. Verwaltet Regelsätze, evaluiert Zustandswechsel und steuert die Low-Level-Engine.
• Firewall Engine: Ausführendes Paketfilter- und Inspektions-Subsystem (typischerweise im Host-OS-Kernel wie Linux Netfilter/nftables, eBPF/XDP oder als dedizierter Hardware-Filter auf Switch-/Phy-Ebene).
• OEM application: Adaptive Application oder State-Management-Entity zur Vorgabe betriebszustandsabhängiger Sicherheitsrichtlinien.
• IdsM (Intrusion Detection System Manager): Standardisierter AUTOSAR Functional Cluster zur Erfassung, Filterung, Aggregation und Qualifizierung von Security Events (SEvs) gemäß ISO/SAE 21434.

Schnittstellen & Interaktionspfade

• Provides firewall configuration (Machine Manifest → FC Firewall): Bereitstellung/Einlesen der im Machine Manifest definierten Filterregeln während der Initialisierung oder bei Software-Updates (UCM).
• Configures firewall engine (FC Firewall → Firewall Engine): OS-/Treiberspezifische Programmierschnittstelle (z. B. Netlink, ioctl, eBPF-Maps, Switch-Register), über welche die FC Firewall die abstrakten Regeln in plattformspezifische Filterketten übersetzt und scharfschaltet.
• Firewall State (OEM application → FC Firewall): Eingangs-Service-Port (Adaptive Interface / ara::com) zur dynamischen Aktivierung vordefinierter Regelgruppen abhängig vom Fahrzeugzustand (z. B. Fahrmodus, Ladevorgang, Diagnose-/Werkstattmodus).
• Raise SEvs (FC Firewall → IdsM): Ausgangs-Port / Client-Schnittstelle zur Meldung detektierter Anomalien, verworfener Pakete (Drops/Rejects) und Schwellwertüberschreitungen an das IdsM-Subsystem.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Regeldruck (Bootstrap / Update):
   • FC Firewall liest bei Start oder Manifest-Update die statischen Filterregeln (Filter rule) aus dem Machine Manifest ein.
   • Initialer Download der Grundfilter (Default-Deny / Default-Allow-Policies) in die Firewall Engine.
2. Dynamischer Zustandswechsel (Runtime Mode Switch):
   • Die OEM application sendet über den Port Firewall State eine Zustandsänderung (z. B. Eintritt in Diagnosemodus oder OTA-Download).
   • FC Firewall wählt die für diesen Zustand validierten Regelsätze aus und modifiziert transaktional die Regeltabellen in der Firewall Engine.
3. Filterdurchsetzung & Event-Signalisierung:
   • Eintreffende Netzwerkpakete werden autonom in der Firewall Engine verarbeitet.
   • Führt ein Paket zu einem Regeltreffer mit Alarmierungsanforderung (Audit/Drop), triggert die Engine eine Benachrichtigung an FC Firewall.
   • FC Firewall leitet das Ereignis über den Pfad Raise SEvs mit relevanten Kontextdaten (Sensor-ID, Timestamp, Header-Metadaten) asynchron an das IdsM weiter.

4. Normative Relevanz & Entwickler-Hinweise

• Plattform-Integration & Engine-Binding:
  • Der AUTOSAR-Standard abstrahiert die Firewall Engine. Integratoren müssen den Adapter zwischen der FC Firewall und dem OS-Kernel bzw. Switch-Controller bereitstellen (z. B. Mapping auf nftables-Regelsätze).
  • Echtzeit- und Performance-Trennung: Datenpfad-Filterung verbleibt strikt in der Firewall Engine; der Control Path verläuft über die FC Firewall.
• Manifest-Modellierung:
  • Filter rule-Definitionen müssen im ARXML präzise an Interfaces und Maschinen-Konfigurationen gebunden sein. Eine fehlerhafte Syntax oder unvollständige Adressbindung führt zu Validierungsfehlern beim Deployment.
• API-Restriktionen:
  • Applikationen (OEM application) haben keinen direkten Zugriff auf Kernel-Paketfilter oder raw network sockets, sondern steuern das Regelwerk ausschließlich über den Service-Vertrag der State-Schnittstelle.
• Cybersecurity & SIEM-Anbindung (ISO/SAE 21434):
  • Für jede relevante Filterregel muss definiert werden, ob sie stumm verwirft (DROP) oder ein Sicherheitsereignis (SEv) via IdsM erzeugt.
  • Implementierungen müssen Rate-Limiting für Raise SEvs vorsehen, um Denial-of-Service-Zustände im IdsM durch Packet-Flooding an der Firewall zu verhindern.