Figure 3.35: Specification of the SecurityEventReportToSecurityEventDefinitionMapping

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm auf AUTOSAR M2-Metamodell-Ebene (Manifest-Spezifikation für die Adaptive Platform, R23-11).
• Technischer Zweck: Formale Definition des Mappings zwischen anwendungsspezifischen Ports zur Sicherheitsereignismeldung (RPortPrototype) und standardisierten Sicherheitsereignisdefinitionen (SecurityEventDefinition) des Intrusion Detection System Managers (IdsM).
• Funktionale Einordnung: Verortet im Subsystem IdsDesign der Adaptive Platform. Es entkoppelt das funktionale Softwaredesign (Software-Komponenten/Compositions) von der Security-Sensorik-Konfiguration. Ermöglicht dem IdsM-Stack, eingehende Event-Meldungen an definierten Ports zur Laufzeit eindeutig einer genormten Security-Event-ID zuzuordnen. Durch die Spezialisierung als UploadableDesignElement ist die gesamte IDS-Konfiguration modular über das Update and Configuration Management (UCM) aktualisierbar.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen und deren Hierarchien

• IdsDesign
  • Stereotypen / Vererbung: Spezialisierung von ARElement und UploadableDesignElement.
  • Semantik: Top-Level-Container für das IDS-Gesamtdesign.
  • Aggregation: Hält über +element 0..* Elemente vom Typ IdsCommonElement. Assoziation ist mit «atpVariation» (Variantenbildung über System-Conditions) und «atpSplitable» (Verteilung über mehrere ARXML-Dateien) annotiert.
• IdsCommonElement
  • Stereotypen / Vererbung: Abstraktes ARElement, spezialisiert UploadableDesignElement.
  • Semantik: Basis-Metaklasse für modulare IDS-Konfigurationselemente.
• SecurityEventDefinition
  • Stereotypen / Vererbung: Spezialisiert IdsCommonElement.
  • Attribute: + id: PositiveInteger [0..1] – Die numerische Sicherheitsereignis-Kennung (Security Event ID / SEv-ID) für Filterung, Ratenbegrenzung und Qualifizierung im IdsM.
• SecurityEventReportToSecurityEventDefinitionMapping
  • Stereotypen / Vererbung: Spezialisiert UploadableDesignElement.
  • Semantik: Zentrales Zuordnungselement zwischen Sensor-Port und IdsM-Event.
  • Assoziationen:
    • +securityEventDefinition (0..1): Unidirektionale Referenz auf die adressierte SecurityEventDefinition.
    • +reportedSecurityEvent (0..1): Komposition auf eine RPortInCompositionInstanceRef.
    • Stereotyp «instanceRef»: Bildet den logischen Instanzpfad auf den konkreten RPortPrototype ab.
• RPortInCompositionInstanceRef & PortInCompositionTypeInstanceRef
  • Semantik: Instanz-Referenz-Container zur Auflösung des hierarchischen Komponentenpfads innerhalb einer Komposition (ermöglicht die eindeutige Adressierung bei mehrfach instanziierten Software-Komponenten).
  • Assoziation: +targetRPort (0..1, {redefines targetPort}) referenziert das Ziel AbstractRequiredPortPrototype.
• RPortPrototype & AbstractRequiredPortPrototype
  • Stereotypen / Vererbung: AbstractRequiredPortPrototype erbt von PortPrototype. RPortPrototype erbt von AbstractRequiredPortPrototype.
  • Typisierung: Referenziert über +requiredInterface (0..1, {redefines atpType}, Stereotyp «isOfType») ein PortInterface.
• PortInterface-Hierarchie
  • PortInterface (ARElement, AtpBlueprint, AtpBlueprintable, AtpType).
  • IdsmAbstractPortInterface: Abstrakte Basisschnittstelle für IdsM-bezogene Ports.
  • SecurityEventReportInterface: Konkretes Interface für Applikations-Ports zur Übermittlung von Security-Events an den IdsM.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm definiert eine statische M2-Konfigurationsstruktur. Die daraus generierte Laufzeitsemantik vollzieht sich wie folgt:

1. Ereignis-Erkennung (Detection): Eine Adaptive Application (z. B. Firewall, TLS-Stack, Diagnose-Manager oder User-Applikation) erkennt eine Anomalie oder Sicherheitsverletzung (z. B. Authentifizierungsfehlschlag, ungültige Frame-Signatur).
2. Port-Aufruf (Event Reporting): Die Applikation meldet das Ereignis über ihren Client-Port (RPortPrototype), der mit dem SecurityEventReportInterface typisiert ist (Aufruf der ara-API bzw. Port-Methoden wie ReportEvent(...)).
3. Kontext-Auflösung (Context Resolution): Der IdsM-Daemon nutzt das aus dem Manifest (SecurityEventReportToSecurityEventDefinitionMapping) generierte Mapping, um anhand des aufrufenden Ports und dessen Instanzkontexts (RPortInCompositionInstanceRef) die Ziel-SecurityEventDefinition und die dazugehörige id (PositiveInteger) zu ermitteln.
4. Qualifizierung & Pufferung (Asynchron): Das Event wird im IdsM gegen Schwellenwerte geprüft (Thresholding/Filterung). Der Reporting-Aufruf der Applikation erfolgt entkoppelt/nicht-blockierend, um die funktionale Reaktionszeit der sicherheitskritischen Anwendung nicht zu beeinträchtigen. Qualifizierte Events werden als Qualified Security Events (QSEv) gepuffert und via IdsM-Protokoll an ein On-Board-/Off-Board-SOC weitergeleitet.

4. Normative Relevanz & Entwickler-Hinweise

• Trennung von Zuständigkeiten (TPS_MANI_01338): Entwickler von adaptiven Anwendungen müssen keine systemweiten Event-IDs hardcodieren. Die Applikation interagiert rein abstrakt über den RPortPrototype mit dem SecurityEventReportInterface. Die Zuweisung der Event-ID erfolgt deklarativ im Manifest über SecurityEventReportToSecurityEventDefinitionMapping.
• Instanz-Eindeutigkeit (TPS_MANI_01339): Wird ein Software-Komponententyp mehrfach in einer Composition instanziiert, sorgt RPortInCompositionInstanceRef dafür, dass der IdsM exakt nachvollziehen kann, welche Instanz das Ereignis ausgelöst hat, und mappt diese auf die jeweilige SecurityEventDefinition.
• Lifecycle & OTA / UCM (RS_MANI_00068): Da sowohl IdsDesign, SecurityEventDefinition als auch das Mapping von UploadableDesignElement erben, können Security-Filterregeln, neue Event-Definitionen und Port-Zuweisungen als eigenständige Manifest-Pakete via UCM nachgeladen oder modifiziert werden, ohne dass Anwendungscode neu kompiliert oder geflasht werden muss.
• Modellierungs-Constraint: Ein RPortPrototype, der über SecurityEventReportToSecurityEventDefinitionMapping referenziert wird, muss zwingend ein Interface implementieren, das von SecurityEventReportInterface abgeleitet ist; eine Zuweisung an beliebige Service-Interfaces ist semantisch unzulässig.