Figure 7.5: Filter categories and processing order

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Funktionales Datenfluss- und Filter-Pipelinediagramm (Verarbeitungskaskade).
• Technischer Zweck: Spezifikation der normativen Verarbeitungsreihenfolge (Processing Order) und hierarchischen Gliederung der Filterstufen für eingehende Security Events (SEv) im Intrusion Detection System Manager (IdsM).
• Architektur-Kontext:
  • Verortung im AUTOSAR Classic Platform (CP) Service Layer (System Services) gemäß AUTOSAR Security-Architektur (ISO/SAE 21434, UNECE R155).
  • Bindeglied zwischen dezentralen Sicherheitsüberwachungen (Security Sensors) und den zentralen On-Board-/Off-Board-Meldesenken (IdsR / Sem).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Schichten (vertikale Farbindikatoren):
  • Sensor (orange): SW-Cs oder BSW-Module (z. B. CanSM, EthSM, SecOC, TcpIp, Firewalls), die als Quellen Security Events über die IdsM-API melden.
  • IDS Manager (IdsM, bordeaux): Zentrales BSW-Modul zur Filterung, Pufferung und Aggregation der gemeldeten Events.
  • IdsR / Sem (blau / gelb): Zielsenken (Sinks). IdsR (IdsReporter) serialisiert und transferiert qualifizierte Events an On-board/Off-board-Instanzen; Sem (Security Event Memory) speichert Events lokal persistent.
• Filterkategorien & Filter-Algorithmen (von oben nach unten):
  • Event ID-spezifische Filter (Event ID specific): Werden pro konfigurierter Event-Definition (Event ID p, p+1 … q-1, q) strikt getrennt evaluiert.
    1. Blockers:
       • Reporting Mode: Filtert Events basierend auf dem aktuellen Betriebs-/Reporting-Modus (z. B. Off, Detailed, Aggregated).
       • Block State: Blockiert Events temporär oder permanent (z. B. zur Laufzeit über Management-APIs gesetzt).
    2. Sampling:
       • Forward Every n-th: Dezimierungsfilter / Unterabtastung; leitet deterministisch nur jedes n-te Event weiter.
    3. Aggregation:
       • Event Aggregation: Zählt Events über ein definiertes Aggregationsintervall.
       • Event Threshold: Schwellwertprüfung; lässt das aggregierte Event erst nach Erreichen eines konfigurierten Zählwerts passieren.
  • Instanz-spezifische Filter (instance specific – unterhalb der Demarkationslinie):
    1. Rate Limitation:
       • Event Rate Limitation: Begrenzung der Event-Frequenz (Events/Sekunde) über alle Events hinweg je IdsM-Instanz/Sink.
       • Traffic Limitation: Begrenzung der akkumulierten Nutzdatenmenge (Bytes/Zeitfenster), um Puffer- und Busüberläufe zu verhindern.
• Schnittstellen:
  • Ingress: API IdsM_SetSecurityEvent() / IdsM_SetSecurityEventWithContextData().
  • Egress: Interne Schnittstelle to sink (Übergabe der qualifizierten Security Events an IdsR oder Sem).

3. Dynamisches Verhalten & Sequenzablauf

• Trigger: Synchroner Aufruf durch einen Sensor bei Detektion eines Sicherheitsvorfalls.
• Deterministische Kaskadenverarbeitung (SWS_IdsM_01010):
  1. Phase 1: Event-ID-spezifisch (Fail-Fast-Prinzip, SWS_IdsM_01011):
     • Eintritt des Events mit spezifischer ID (p … q).
     • Reporting Mode und Block State prüfen: Ist das Event deaktiviert oder blockiert, wird es sofort verworfen (Early Drop).
     • Sampling prüfen: Ist der n-Zähler noch nicht erreicht, erfolgt kein Forwarding.
     • Aggregation / Threshold: Bei aktiver Aggregation wird das Event im internen Aggregationsspeicher aufsummiert. Das Weiterschleifen erfolgt erst, wenn die Schwelle (Threshold) erreicht ist oder ein Aggregations-Timer abläuft.
  2. Phase 2: Instanz-spezifische Filterung (SWS_IdsM_01012):
     • Alle überlebenden Events aus den parallelen Event-ID-Strömen münden in die instanzweite Pipeline.
     • Event Rate Limitation: Prüfung gegen das globale Frequenzbudget.
     • Traffic Limitation: Prüfung gegen das Bandbreitenbudget der Zielverbindung.
  3. Ausgabe: Erfolgreich passierte Events werden an den konfigurierten Sink (to sink) weitergeleitet.
• Abbruchbedingungen: Jeder negative Filterbefund führt zum unmittelbaren Verwerfen des Events. Nachfolgende Filterstufen werden nicht mehr ausgeführt, was minimale CPU-Laufzeit garantiert.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsanforderungen (ARXML / BSW-Konfiguration):
  • Die Filterhierarchie ist normativ festgelegt (SWS_IdsM_01010); Stack-Implementierer dürfen die Ausführungsreihenfolge nicht abwandeln.
  • Blocker-, Sampling- und Aggregationsparameter werden unter IdsMEventDefinition parametriert; Raten- und Traffic-Limiter unter IdsMInstance bzw. IdsMSink.
• Laufzeit- und Echtzeitimplikationen:
  • Da IdsM_SetSecurityEvent() aus hochprioren Kontexten (auch ISR-nah) aufgerufen werden kann, dient die Platzierung der Blockers an erster Stelle der Vermeidung unnötiger CPU-Zyklen.
  • Kontextdaten-Kopien (Context Data Buffer) dürfen erst erfolgen, wenn die Blocker- und Sampling-Stufen erfolgreich passiert wurden.
• DoS-Schutz (Safety & Security Co-Existence):
  • Die zweistufige Trennung (Event ID specific vs. instance specific) verhindert, dass ein kompromittierter oder fehlerhafter Sensor durch Flooding den gesamten Kommunikationsstack (PduR/Com/Eth) lahmlegt.