Figure 9.66: Interfaces required by Firewall

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Komponentendiagramm (Abhängigkeits- und Schnittstellenmodellierung der AUTOSAR Adaptive Platform nach AUTOSAR_EXP_SWArchitecture).
• Architektur-Kontext: Spezifiziert die Systemintegration und die erforderlichen Schnittstellen (Required Interfaces) des Functional Clusters Firewall. Es definiert die bidirektionale Rolle der Firewall im Adaptive-System: Einerseits als filternde Kontrollinstanz auf Systemebene über dem OS-Netzwerk-Stack, andererseits als Security-Sensor, der Angriffs- und Anomalieereignisse an das fahrzeuginterne Intrusion Detection System (IdsM) meldet.

2. Komponenten, Entitäten & Schnittstellen

• Komponenten / Functional Clusters:
  • «aapFunctionalCluster» Firewall (daemon-based): Client- und Steuerungskomponente; als nativer OS-Daemon realisierter Functional Cluster zur Filterung des IP-basierten Datenverkehrs (Paketfilterung, Zustandsprüfung, Routing-Kontrolle).
  • «aapFunctionalCluster» Adaptive Intrusion Detection System Manager (daemon-based): IdsM-Instanz; eigenständiger Daemon zur Erfassung, Pufferung, Filterung und Weiterleitung sicherheitsrelevanter Vorfälle (Security Events / Qualified Security Events).
  • Operating System: POSIX-konformes Plattform-Betriebssystem (z. B. Linux/QNX), das die Basistreiber und den nativen Netzwerk-Stack kapselt.
• Schnittstellen & Stereotypen:
  • «aapPortInterface,aapAPI» EventReporter: Standardisierte funktionale Plattform-Schnittstelle (ARA-konforme C++-API).
    • Operation: + ReportEvent() zur standardisierten Übergabe von Security Events an den IdsM.
  • «aapInternal» TCP/IP Stack: Plattform-interne, nicht über das Adaptive Service Interface standardisierte Low-Level-Schnittstelle zum OS-Netzwerkstack (z. B. Kernel-Hooks, Netfilter/nftables, eBPF, Socket-Filter).
• Beziehungen & Abhängigkeiten:
  • Firewall $\xrightarrow{\text{«use»}}$ EventReporter: Die Firewall konsumiert die Reporterschnittstelle (Client-Rolle).
  • Adaptive Intrusion Detection System Manager $\xleftarrow{\text{realizes}}$ EventReporter: Der IdsM implementiert und exponiert diese Schnittstelle.
  • Firewall $\xrightarrow{\text{«use»}}$ TCP/IP Stack: Die Firewall bindet sich direkt an die Paketverarbeitung des Betriebssystems an.
  • Operating System $\xleftarrow{\text{realizes}}$ TCP/IP Stack: Das Betriebssystem stellt den Netzwerk-Stack bereit.

3. Dynamisches Verhalten & Sequenzablauf

1. Paket-Interzeption & Regelauswertung (Synchron/OS-Ebene):
   • Eingehende/ausgehende IP-Pakete durchlaufen den TCP/IP Stack des Operating System.
   • Die Firewall greift über die «aapInternal»-Schnittstelle in den Paketfluss ein und bewertet Pakete gegen hinterlegte Regelsätze (Stateful Packet Inspection, Black-/Whitelisting, Rate-Limiting).
2. Entscheidungs- und Filterpfad:
   • Valide Pakete passieren den Stack transparent.
   • Illegitime Pakete werden verworfen (Drop), abgewiesen (Reject) oder markiert.
3. Security Event Trigger:
   • Bei Regelverletzungen (z. B. Portscan-Erkennung, Payload-Anomalie, IP-Spoofing, DoS-Muster) generiert die Firewall einen Security-Incident.
4. Ereignismeldung (ReportEvent()):
   • Die Firewall ruft EventReporter::ReportEvent(...) auf dem IdsM auf.
   • Übergabe von Security Event ID, Timestamp und kontextspezifischen Daten (z. B. Quell-/Ziel-IP, Port, Protocol, Drop-Reason).
5. IdsM-Verarbeitung:
   • Der Adaptive Intrusion Detection System Manager verarbeitet das Event asynchron weiter (Aggregation, Schwellwertanalyse, Logging oder Alarmierung via Telematik/SOC).

4. Normative Relevanz & Entwickler-Hinweise

• Prozess- & Deployment-Modell:
  • Da die Firewall als daemon-based deklariert ist, muss sie im Manifest des Execution Management (ara::exec) als eigener Prozess mit entsprechenden POSIX-Capabilities (CAP_NET_ADMIN, CAP_NET_RAW unter Linux) und dedizierten Start-/Shutdown-Abhängigkeiten konfiguriert werden.
• Portabilitäts-Einschränkung («aapInternal»):
  • Die Kopplung an den TCP/IP Stack erfolgt proprietär/OS-spezifisch. Bei Plattform-Migrationen (z. B. Linux ↔ QNX) ist die Firewall-Engine bzw. der Binding-Layer neu zu implementieren, da hier kein standardisiertes ara::com-Service-Interface vorliegt.
• IdsM-API-Vertrag (ReportEvent):
  • Aufrufkonventionen und Pufferverhalten müssen latenzarm ausgelegt sein. Blockierende Aufrufe in ReportEvent() dürfen den Durchsatz des OS-Netzwerk-Stacks unter Last nicht drosseln (nicht-blockierende Ringpuffer oder asynchrone Dispatch-Mechanismen zwingend erforderlich).
  • Die von der Firewall gemeldeten Events müssen den in der Security-Extract-Konfiguration (AUTOSAR_SWS_IntrusionDetectionSystemManager) definierten EventDefinitionIds exakt entsprechen.