Modul ara::idsm — Intrusion Detection System Manager

Der Intrusion Detection System Manager erfasst als zentraler Plattformdienst sicherheitsrelevante Ereignisse von funktionalen Clustern und Anwendungen über standardisierte Instanzen der Klasse [SWS_AIDSM_10101] AUTOSAR_AP_EXP_SWArchitecture S. 124. Eingehende Meldungen können mit Zeitstempeln und Kontextdaten angereichert, gefiltert und als qualifizierte Sicherheitsereignisse an autorisierte Empfänger weitergeleitet werden [SWS_AIDSM_10800]. Die Anbindung aller Schnittstellen und Ereignis-IDs erfordert eine konsistente Modellierung über das AUTOSAR-Manifest AUTOSAR_AP_TPS_ManifestSpecification S. 257.

mehr ›

Der Intrusion Detection System Manager (IdsM) fungiert in der AUTOSAR Adaptive Platform als zentraler daemon-basierter Functional Cluster zur Aggregation, Filterung und Bewertung sicherheitsrelevanter Ereignisse AUTOSAR_AP_EXP_PlatformDesign S. 95. Sowohl funktionale Cluster wie Communication Management, Firewall und Diagnostic Management als auch anwendungsspezifische Komponenten melden Sicherheitsvorfälle threadsicher über standardisierte Instanzen der Klasse [SWS_AIDSM_10101] an den IdsM AUTOSAR_AP_SWS_IntrusionDetectionSystemManager S. 13.

Kontextdiagramm: Einbettung des IdsM-Daemons als zentrale Senke für Sicherheitsereignisse aus funktionalen Clustern und Applikationen. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager S. 13.

Die Ereignismeldung über ReportEvent unterstützt variable Detaillierungsgrade von einfachen Zählern über explizite Zeitstempel bis hin zu unversionierten oder versionierten Kontextdaten [SWS_AIDSM_10302], [SWS_AIDSM_10307]. Zur dynamischen Anreicherung können Anwendungen über [SWS_AIDSM_10400] und [SWS_AIDSM_10500] als Provider für Zeitstempel oder zusätzliche Kontextbytes eingebunden werden AUTOSAR_AP_EXP_SWArchitecture S. 122. Nach der Auswertung interner Filterketten leitet der IdsM qualifizierte Ereignisse über Benachrichtigungs-Callbacks der Klasse [SWS_AIDSM_10800] an registrierte Empfänger weiter [SWS_AIDSM_10807].

Sequenzdiagramm: Synchrones Melden eines Sicherheitsereignisses durch eine Sensor-Komponente via EventReporter. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 232, [SWS_AIDSM_10101].

Die Konfiguration der Ports und die Zuordnung von Ereignisdefinitionen erfolgt über standardisierte Metamodell-Elemente im Manifest AUTOSAR_AP_TPS_ManifestSpecification S. 257. Das Meldeverhalten einzelner Ereignisse lässt sich zudem zur Laufzeit über [SWS_AIDSM_10600] steuern, wobei ungültige Ereignis-IDs über die Fehlerdomäne [SWS_AIDSM_10706] mit dem Fehlercode kUnknownEventId signalisiert werden [SWS_AIDSM_10204], [SWS_AIDSM_10602].

mehr ›

Rolle und Systemgrenzen des Intrusion Detection System Manager

Der Intrusion Detection System Manager (IdsM) bildet die zentrale Plattforminstanz zur Erfassung, Vorfilterung und Qualifizierung sicherheitsrelevanter Ereignisse (Security Events) auf einer AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_PlatformDesign S. 95. Gemäß den Cybersicherheitsanforderungen der ISO/SAE 21434 fungiert der IdsM auf POSIX-basierten Steuergeräten als eigenständiger Hintergrunddienst (daemon-based Functional Cluster) AUTOSAR_AP_EXP_SWArchitecture S. 124. Seine Kernaufgabe besteht darin, Anomalien und potenzielle Angriffsversuche zu sammeln, anhand konfigurierter Regeln wie Ratenbegrenzungen oder Schwellwerten zu bewerten und zu qualifizierten Sicherheitsereignissen (Qualified Security Events) zusammenzuführen AUTOSAR_EXP_SWArchitecture S. 97.

Die Architektur des IdsM ist auf Interoperabilität mit anderen funktionalen Clustern ausgelegt. Plattformdienste wie Communication Management AUTOSAR_AP_SWS_CommunicationManagement S. 34, Firewall AUTOSAR_AP_SWS_Firewall S. 11 und Diagnostic Management AUTOSAR_AP_SWS_Diagnostics S. 67 sowie anwendungsspezifische Prozesse fungieren als Security-Sensoren AUTOSAR_AP_SWS_IntrusionDetectionSystemManager S. 13. Die nachfolgende Übersicht veranschaulicht die Einbettung des IdsM-Daemons in das Laufzeitumfeld der Adaptive Platform.

Kontextdiagramm: Einbettung des IdsM-Daemons als zentrale Senke für Sicherheitsereignisse aus funktionalen Clustern und Applikationen. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager S. 13, AUTOSAR_AP_EXP_PlatformDesign S. 95.

Ereignismeldung über EventReporter und Interaktionsformen

Die primäre Eingangs-Schnittstelle zur Übermittlung von Sicherheitsvorfällen wird durch die Klasse [SWS_AIDSM_10101] realisiert. Eine meldende Einheit instanziiert diese Klasse unter Angabe eines definierten Ports mittels ara::core::InstanceSpecifier threadsicher über den Konstruktor [SWS_AIDSM_10301]. Hierdurch wird die Anbindung an das im Manifest definierte SecurityEventReportInterface hergestellt AUTOSAR_AP_TPS_ManifestSpecification S. 257. Die eigentliche Übermittlung erfolgt über überladene Varianten der synchronen Methode ReportEvent, die jeweils threadsicher ausgeführt werden können [SWS_AIDSM_10302].

Abhängig von der Art des Ereignisses und den verfügbaren Sensordaten bietet die Schnittstelle abgestufte Meldeformen. Die Basismethode übermittelt lediglich eine Wiederholungsanzahl vom Typ [SWS_AIDSM_10203] (Standardwert 1) ohne weitere Metadaten [SWS_AIDSM_10302]. Für zeitkritische Vorgänge kann ein sensorspezifischer Zeitstempel vom Typ [SWS_AIDSM_10202] direkt mitgegeben werden [SWS_AIDSM_10303]. Zudem lassen sich unveränderliche Nutzdaten als Byte-Span vom Typ [SWS_AIDSM_10201] entweder allein [SWS_AIDSM_10304] oder kombiniert mit Zeitstempel übergeben [SWS_AIDSM_10305]. Für strukturierte Ereignisformate existieren Überladungen mit versionierten Kontextdaten vom Typ [SWS_AIDSM_10206], die ein Wertepaar aus Kontextdaten-Span und einem 16-Bit-Versionsindikator darstellen [SWS_AIDSM_10306], optional ergänzt um einen expliziten Zeitstempel [SWS_AIDSM_10307].

Ein typisches Szenario für diesen Meldepfad ist das Verwerfen unzulässiger Netzwerkpakete durch den TCP/IP-Stack und die Firewall: Das Betriebssystem meldet blockierte Pakete an den Firewall-Daemon, welcher daraufhin unverzüglich ReportEvent aufruft AUTOSAR_AP_EXP_SWArchitecture S. 232. Das folgende Sequenzdiagramm verdeutlicht diesen synchronen Meldeprozess.

Sequenzdiagramm: Synchrones Melden eines Sicherheitsereignisses durch eine Sensor-Komponente via EventReporter. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 232, [SWS_AIDSM_10101], [SWS_AIDSM_10302].

Erweiterte Kontextdaten und Zeitstempel über Provider-Schnittstellen

Um meldende Prozesse nicht mit aufwendigen Zeitabfragen oder statischen Kontextinformationen zu belasten, unterstützt die Architektur eine Kontrollfluss-Inversion über Provider-Schnittstellen AUTOSAR_AP_EXP_SWArchitecture S. 122. Anwendungen können als Zeitstempel-Dienstleister agieren, indem sie von der abstrakten Klasse [SWS_AIDSM_10400] ableiten. Nach der Instanziierung über den Konstruktor [SWS_AIDSM_10401] schaltet die Anwendung den Dienst mit Offer() aktiv [SWS_AIDSM_10408]. Ab diesem Zeitpunkt kann der IdsM bei Bedarf die reine virtuelle Methode GetTimestamp() aufrufen, um den aktuellen Zeitwert abzufragen [SWS_AIDSM_10407]. Die Bereitstellung wird mit StopOffer() beendet [SWS_AIDSM_10409].

In analoger Weise ermöglicht die Basisklasse [SWS_AIDSM_10500] die dynamische Anreicherung oder Modifikation von Kontextdaten. Der Konstruktor erwartet neben dem InstanceSpecifier die Größenangabe zusätzlicher Bytes sowie den Offset für die ursprünglichen Kontextdaten [SWS_AIDSM_10501]. Nach Freigabe durch Offer() [SWS_AIDSM_10507] ruft der IdsM-Daemon bei Ereigniseingang die Methode ModifyContextData auf [SWS_AIDSM_10509]. Hierbei wird ein beschreibbarer Byte-Span übergeben, in den die Anwendung modifizierte Daten schreibt und die resultierende Datengröße als ara::core::Result<std::size_t> zurückmeldet [SWS_AIDSM_10509]. Mit StopOffer() wird die Entgegennahme weiterer Modifikationsanfragen deaktiviert [SWS_AIDSM_10508].

Sequenzdiagramm: Lebenszyklus und Inversion-of-Control-Ablauf bei der Anreicherung von Sicherheitsereignissen über TimestampProvider und ContextDataProvider. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 122, [SWS_AIDSM_10408], [SWS_AIDSM_10509].

Empfang qualifizierter Sicherheitsereignisse und Betriebssteuerung

Nachdem der IdsM die eingehenden Ereignisse verarbeitet und anhand seiner Filterregeln qualifiziert hat, können autorisierte Adaptive Applications über das Vorliegen eines qualifizierten Ereignisses informiert werden AUTOSAR_AP_EXP_SWArchitecture S. 123. Hierzu dient die Klasse [SWS_AIDSM_10800], die über ihren Port-spezifischen Konstruktor instanziiert wird [SWS_AIDSM_10801]. Nach dem Aufruf von Offer() [SWS_AIDSM_10808] leitet der IdsM Benachrichtigungen an die Applikation weiter, indem er den entsprechenden Callback aufruft. Stehen unversionierte Daten bereit, erfolgt der Aufruf über OnEventQualification mit optionalem Kontext und optionalem Zeitstempel [SWS_AIDSM_10807]. Liegen versionierte Kontextdaten vor, bedient der Daemon die überladene Schnittstelle [SWS_AIDSM_10810]. Die Benachrichtigung kann mit StopOffer() beendet werden [SWS_AIDSM_10809].

Sequenzdiagramm: Empfang qualifizierter Sicherheitsereignisse durch eine Reaktions-Anwendung über QualifiedEventsReceiver. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 123, [SWS_AIDSM_10801], [SWS_AIDSM_10808], [SWS_AIDSM_10807].

Zur dynamischen Steuerung des Meldeverhaltens pro Ereignis existiert die Klasse [SWS_AIDSM_10600], die über den Konstruktor [SWS_AIDSM_10601] initialisiert wird. Über GetReportingMode lässt sich der aktuelle Modus für eine Ereignis-ID vom Typ [SWS_AIDSM_10205] abfragen [SWS_AIDSM_10602]. Mittels SetReportingMode kann der Modus zur Laufzeit modifiziert werden [SWS_AIDSM_10603]. Die Enumeration [SWS_AIDSM_10207] definiert die verfügbaren Modi, welche von der vollständigen Abschaltung (kOff) über standardmäßige und detaillierte Erfassung (kBrief, kDetailed) bis hin zur gezielten Umgehung interner Filterketten (kBriefBypassingFilters, kDetailedBypassingFilters) reichen [SWS_AIDSM_10207].

Zustandsdiagramm: Melde- und Filtermodi der Ereignisverarbeitung gemäß ReportingModeType. Quellen: [SWS_AIDSM_10207], [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Manifest-Modellierung, Port-Bindung und Deployment

Die Einbindung aller Schnittstellen in das Gesamtsystem erfolgt deklarativ über das AUTOSAR-Manifest. Alle IdsM-bezogenen Port-Schnittstellen leiten sich im Metamodell von der gemeinsamen Basisklasse IdsmAbstractPortInterface ab AUTOSAR_AP_TPS_ManifestSpecification S. 257. Das Reporting wird über ein SecurityEventReportInterface modelliert, welches über ein SecurityEventReportToSecurityEventDefinitionMapping mit einer formalen SecurityEventDefinition verknüpft wird AUTOSAR_AP_TPS_ManifestSpecification S. 146. Diese explizite Entkopplung gestattet es, standardisierte Software-Komponenten wiederzuverwenden und projektspezifische Ereignis-IDs erst auf Konfigurationsebene zuzuordnen TPS_ManifestSpecification S. 146.

Auf Deployment-Ebene werden die verschiedenen Provider und Receiver als UploadableDeploymentElement abgebildet TPS_ManifestSpecification S. 881. Hierzu zählen IdsmTimestampProviderMapping AUTOSAR_AP_TPS_ManifestSpecification S. 664, IdsmContextProviderMapping AUTOSAR_AP_TPS_ManifestSpecification S. 665, IdsmReportingModeProviderMapping AUTOSAR_AP_TPS_ManifestSpecification S. 667 sowie IdsmQualifiedEventReceiverMapping AUTOSAR_AP_TPS_ManifestSpecification S. 669. Diese Metaklassen verknüpfen die modulare Plattform-Instanz IdsPlatformInstantiation mit dem jeweiligen Prozess (Process) und dem Ziel-Port (PPortPrototype bzw. RPortPrototype) TPS_ManifestSpecification S. 664. Für funktionale Cluster existiert zudem ein spezielles Mapping FunctionalClusterToSecurityEventDefinitionMapping, um Plattform-Ereignisse ohne direkte Prozessbindung normgerecht zuzuordnen AUTOSAR_AP_TPS_ManifestSpecification S. 873.

Verhalten im Fehlerfall und Diagnosebehandlung

Fehlersituationen innerhalb des IdsM-Moduls werden nach dem standardisierten AUTOSAR-Fehlerbehandlungskonzept über die Fehlerdomäne [SWS_AIDSM_10706] abgewickelt. Diese wird über die globale Funktion GetIdsmErrorDomain() referenziert [SWS_AIDSM_10702]. Konkrete API-Fehler werden durch die Enumeration [SWS_AIDSM_10204] (Alias [SWS_AIDSM_10707]) repräsentiert. Tritt beispielsweise beim Abfragen oder Setzen eines Reporting-Modus eine unbekannte Ereignis-ID auf, geben die Operationen GetReportingMode und SetReportingMode ein fehlerhaftes ara::core::Result mit dem Code IdsmErrc::kUnknownEventId zurück [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Zur Umwandlung in strukturierte Fehlerobjekte dient die Hilfsfunktion MakeErrorCode [SWS_AIDSM_10703]. Die Fehlerdomäne implementiert die Schnittstellen zur Abfrage des Domänennamens [SWS_AIDSM_10710] sowie der beschreibenden Textmeldung [SWS_AIDSM_10711]. Sofern Ausnahmen im System aktiviert sind, kann ein Fehlercode über ThrowAsException [SWS_AIDSM_10712] als Ausnahme vom Typ [SWS_AIDSM_10704] (Alias [SWS_AIDSM_10708]) geworfen werden, deren Konstruktor den zugrundeliegenden ErrorCode kapselt [SWS_AIDSM_10705].

Weiterführende Detailbelege und Spezifikationsbezug

Die nachfolgende Zusammenstellung fasst die wesentlichen Spezifikationsdokumente und Architekturstellen des Moduls zusammen:

• Ereignis-Ingress und Sensor-Reporting: Die Spezifikationen [SWS_AIDSM_10101] und [SWS_AIDSM_10302] bis [SWS_AIDSM_10307] definieren die C++-Signatur von EventReporter. Die architektonische Einbettung durch Plattform-Sensoren wird in AUTOSAR_AP_SWS_IntrusionDetectionSystemManager S. 13 und AUTOSAR_AP_EXP_SWArchitecture S. 121 dargestellt.
• Plattforminterne Integration: Die Abhängigkeiten und Nutzungsmuster anderer funktionaler Cluster wie Communication Management (AUTOSAR_AP_SWS_CommunicationManagement S. 34), Firewall (AUTOSAR_AP_SWS_Firewall S. 11) und Diagnostic Management (AUTOSAR_AP_SWS_Diagnostics S. 67) belegen die universelle Rolle des IdsM als Sicherheitskollektor.
• Zusatzdaten- und Zeitstempel-Provider: Die Spezifikationen [SWS_AIDSM_10400] und [SWS_AIDSM_10500] regeln das Bereitstellungsmuster für Zeitstempel und Kontextmodifikationen, ergänzt durch das Architekturschaubild AUTOSAR_AP_EXP_SWArchitecture S. 122.
• Empfang qualifizierter Ereignisse und Betriebsmodi: Die Anforderungen [SWS_AIDSM_10800] und [SWS_AIDSM_10600] beschreiben die Egress-Kommunikation und Laufzeitkonfiguration, veranschaulicht in AUTOSAR_AP_EXP_SWArchitecture S. 123.
• Manifest- und Deployment-Modellierung: Die Metamodell-Regeln in AUTOSAR_AP_TPS_ManifestSpecification S. 257 sowie die Deployment-Mappings AUTOSAR_AP_TPS_ManifestSpecification S. 664 bis AUTOSAR_AP_TPS_ManifestSpecification S. 669 sichern die konsistente Instanziierung und Anbindung zur Entwurfs- und Ladezeit.
• Fehlerbehandlung: Die Definitionen [SWS_AIDSM_10204] und [SWS_AIDSM_10706] bilden das Fundament der Fehlerbehandlung bei ungültigen Ereignisbezeichnern.