module ara::idsm — Intrusion Detection System Manager

As a central platform service, the Intrusion Detection System Manager collects security-relevant events from functional clusters and applications via standardized instances of class [SWS_AIDSM_10101] AUTOSAR_AP_EXP_SWArchitecture p. 124. Incoming messages can be enriched with timestamps and context data, filtered, and forwarded as qualified security events to authorized receivers [SWS_AIDSM_10800]. The integration of all interfaces and event IDs requires consistent modeling via the AUTOSAR manifest AUTOSAR_AP_TPS_ManifestSpecification p. 257.

more ›

In the AUTOSAR Adaptive Platform, the Intrusion Detection System Manager (IdsM) acts as a central daemon-based Functional Cluster for aggregating, filtering, and evaluating security-relevant events AUTOSAR_AP_EXP_PlatformDesign p. 95. Both functional clusters such as Communication Management, Firewall, and Diagnostic Management as well as application-specific components report security incidents thread-safely to the IdsM via standardized instances of class [SWS_AIDSM_10101] AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

Context diagram: Embedding of the IdsM daemon as a central sink for security events from functional clusters and applications. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

Event reporting via ReportEvent supports variable levels of detail ranging from simple counters and explicit timestamps to unversioned or versioned context data [SWS_AIDSM_10302], [SWS_AIDSM_10307]. For dynamic enrichment, applications can be integrated via [SWS_AIDSM_10400] and [SWS_AIDSM_10500] as providers for timestamps or additional context bytes AUTOSAR_AP_EXP_SWArchitecture p. 122. After evaluating internal filter chains, the IdsM forwards qualified events to registered receivers via notification callbacks of class [SWS_AIDSM_10800] [SWS_AIDSM_10807].

Sequence diagram: Synchronous reporting of a security event by a sensor component via EventReporter. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101].

The configuration of ports and the assignment of event definitions take place via standardized metamodel elements in the manifest AUTOSAR_AP_TPS_ManifestSpecification p. 257. The reporting behavior of individual events can also be controlled at runtime via [SWS_AIDSM_10600], where invalid event IDs are signaled via the error domain [SWS_AIDSM_10706] with error code kUnknownEventId [SWS_AIDSM_10204], [SWS_AIDSM_10602].

more ›

Role and System Boundaries of the Intrusion Detection System Manager

The Intrusion Detection System Manager (IdsM) forms the central platform instance for collecting, pre-filtering, and qualifying security-relevant events (Security Events) on an AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_PlatformDesign p. 95. In accordance with the cybersecurity requirements of ISO/SAE 21434, the IdsM functions on POSIX-based electronic control units as an independent background service (daemon-based Functional Cluster) AUTOSAR_AP_EXP_SWArchitecture p. 124. Its core task consists of collecting anomalies and potential attack attempts, evaluating them based on configured rules such as rate limits or thresholds, and consolidating them into qualified security events (Qualified Security Events) AUTOSAR_EXP_SWArchitecture p. 97.

The architecture of the IdsM is designed for interoperability with other functional clusters. Platform services such as Communication Management AUTOSAR_AP_SWS_CommunicationManagement p. 34, Firewall AUTOSAR_AP_SWS_Firewall p. 11, and Diagnostic Management AUTOSAR_AP_SWS_Diagnostics p. 67, as well as application-specific processes, act as security sensors AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13. The following overview illustrates the embedding of the IdsM daemon into the runtime environment of the Adaptive Platform.

Context diagram: Embedding of the IdsM daemon as a central sink for security events from functional clusters and applications. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13, AUTOSAR_AP_EXP_PlatformDesign p. 95.

Event Reporting via EventReporter and Interaction Patterns

The primary ingress interface for transmitting security incidents is implemented by the class [SWS_AIDSM_10101]. A reporting entity instantiates this class thread-safely via constructor [SWS_AIDSM_10301] by specifying a defined port using ara::core::InstanceSpecifier. This establishes the connection to the SecurityEventReportInterface defined in the manifest AUTOSAR_AP_TPS_ManifestSpecification p. 257. The actual transmission takes place via overloaded variants of the synchronous method ReportEvent, each of which can be executed in a thread-safe manner [SWS_AIDSM_10302].

Depending on the type of event and the available sensor data, the interface offers graduated reporting modes. The basic method transmits only a repetition count of type [SWS_AIDSM_10203] (default value 1) without further metadata [SWS_AIDSM_10302]. For time-critical operations, a sensor-specific timestamp of type [SWS_AIDSM_10202] can be provided directly [SWS_AIDSM_10303]. Furthermore, immutable payload data can be passed as a byte span of type [SWS_AIDSM_10201] either alone [SWS_AIDSM_10304] or combined with a timestamp [SWS_AIDSM_10305]. For structured event formats, overloads exist with versioned context data of type [SWS_AIDSM_10206], representing a value pair consisting of a context data span and a 16-bit version indicator [SWS_AIDSM_10306], optionally supplemented by an explicit timestamp [SWS_AIDSM_10307].

A typical scenario for this reporting path is the discarding of impermissible network packets by the TCP/IP stack and the Firewall: The operating system reports blocked packets to the Firewall daemon, which subsequently invokes ReportEvent without delay AUTOSAR_AP_EXP_SWArchitecture p. 232. The following sequence diagram illustrates this synchronous reporting process.

Sequence diagram: Synchronous reporting of a security event by a sensor component via EventReporter. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101], [SWS_AIDSM_10302].

Extended Context Data and Timestamps via Provider Interfaces

To avoid burdening reporting processes with computationally expensive time queries or static context information, the architecture supports an inversion of control via provider interfaces AUTOSAR_AP_EXP_SWArchitecture p. 122. Applications can act as timestamp providers by deriving from the abstract class [SWS_AIDSM_10400]. After instantiation via constructor [SWS_AIDSM_10401], the application enables the service using Offer() [SWS_AIDSM_10408]. From this point forward, the IdsM can call the pure virtual method GetTimestamp() as needed to retrieve the current time value [SWS_AIDSM_10407]. Provision is terminated with StopOffer() [SWS_AIDSM_10409].

In an analogous manner, the base class [SWS_AIDSM_10500] enables dynamic enrichment or modification of context data. In addition to the InstanceSpecifier, the constructor expects the size specification of additional bytes as well as the offset for the original context data [SWS_AIDSM_10501]. Following release by Offer() [SWS_AIDSM_10507], the IdsM daemon calls method ModifyContextData upon event arrival [SWS_AIDSM_10509]. In doing so, a writable byte span is passed into which the application writes modified data, reporting the resulting data size back as ara::core::Result<std::size_t> [SWS_AIDSM_10509]. With StopOffer(), the acceptance of further modification requests is deactivated [SWS_AIDSM_10508].

Sequence diagram: Lifecycle and inversion-of-control sequence during the enrichment of security events via TimestampProvider and ContextDataProvider. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 122, [SWS_AIDSM_10408], [SWS_AIDSM_10509].

Reception of Qualified Security Events and Operational Control

After the IdsM has processed incoming events and qualified them based on its filter rules, authorized Adaptive Applications can be informed about the presence of a qualified event AUTOSAR_AP_EXP_SWArchitecture p. 123. Class [SWS_AIDSM_10800], which is instantiated via its port-specific constructor, serves this purpose [SWS_AIDSM_10801]. After calling Offer() [SWS_AIDSM_10808], the IdsM forwards notifications to the application by invoking the corresponding callback. If unversioned data is available, the invocation occurs via OnEventQualification with optional context and an optional timestamp [SWS_AIDSM_10807]. If versioned context data is present, the daemon serves the overloaded interface [SWS_AIDSM_10810]. The notification can be terminated with StopOffer() [SWS_AIDSM_10809].

Sequence diagram: Reception of qualified security events by a reaction application via QualifiedEventsReceiver. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 123, [SWS_AIDSM_10801], [SWS_AIDSM_10808], [SWS_AIDSM_10807].

For dynamic control of the reporting behavior per event, class [SWS_AIDSM_10600] exists, which is initialized via constructor [SWS_AIDSM_10601]. Via GetReportingMode, the current mode for an event ID of type [SWS_AIDSM_10205] can be queried [SWS_AIDSM_10602]. By means of SetReportingMode, the mode can be modified at runtime [SWS_AIDSM_10603]. The enumeration [SWS_AIDSM_10207] defines the available modes, which range from complete deactivation (kOff) and standard as well as detailed acquisition (kBrief, kDetailed) to deliberate bypassing of internal filter chains (kBriefBypassingFilters, kDetailedBypassingFilters) [SWS_AIDSM_10207].

State diagram: Reporting and filter modes of event processing according to ReportingModeType. Sources: [SWS_AIDSM_10207], [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Manifest Modeling, Port Binding, and Deployment

The integration of all interfaces into the overall system takes place declaratively via the AUTOSAR manifest. In the metamodel, all IdsM-related port interfaces derive from the common base class IdsmAbstractPortInterface AUTOSAR_AP_TPS_ManifestSpecification p. 257. Reporting is modeled via a SecurityEventReportInterface, which is linked to a formal SecurityEventDefinition via a SecurityEventReportToSecurityEventDefinitionMapping AUTOSAR_AP_TPS_ManifestSpecification p. 146. This explicit decoupling allows standardized software components to be reused and project-specific event IDs to be assigned only at configuration level TPS_ManifestSpecification p. 146.

At deployment level, the various providers and receivers are mapped as UploadableDeploymentElement TPS_ManifestSpecification p. 881. These include IdsmTimestampProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 664, IdsmContextProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 665, IdsmReportingModeProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 667, and IdsmQualifiedEventReceiverMapping AUTOSAR_AP_TPS_ManifestSpecification p. 669. These metaclasses link the modular platform instance IdsPlatformInstantiation with the respective process (Process) and the target port (PPortPrototype or RPortPrototype) TPS_ManifestSpecification p. 664. For functional clusters, a dedicated mapping FunctionalClusterToSecurityEventDefinitionMapping also exists to map platform events in compliance with the standard without direct process binding AUTOSAR_AP_TPS_ManifestSpecification p. 873.

Behavior in Case of Errors and Diagnostic Handling

Error situations within the IdsM module are handled according to the standardized AUTOSAR error handling concept via the error domain [SWS_AIDSM_10706]. This is referenced via the global function GetIdsmErrorDomain() [SWS_AIDSM_10702]. Concrete API errors are represented by the enumeration [SWS_AIDSM_10204] (alias [SWS_AIDSM_10707]). If, for example, an unknown event ID occurs when querying or setting a reporting mode, operations GetReportingMode and SetReportingMode return an erroneous ara::core::Result with error code IdsmErrc::kUnknownEventId [SWS_AIDSM_10602], [SWS_AIDSM_10603].

The helper function MakeErrorCode serves to convert into structured error objects [SWS_AIDSM_10703]. The error domain implements the interfaces for querying the domain name [SWS_AIDSM_10710] as well as the descriptive text message [SWS_AIDSM_10711]. If exceptions are enabled in the system, an error code can be thrown via ThrowAsException [SWS_AIDSM_10712] as an exception of type [SWS_AIDSM_10704] (alias [SWS_AIDSM_10708]), whose constructor encapsulates the underlying ErrorCode [SWS_AIDSM_10705].

Further Detailed Evidence and Specification References

The following compilation summarizes the essential specification documents and architectural passages of the module:

• Event ingress and sensor reporting: Specifications [SWS_AIDSM_10101] and [SWS_AIDSM_10302] to [SWS_AIDSM_10307] define the C++ signature of EventReporter. Architectural embedding by platform sensors is presented in AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13 and AUTOSAR_AP_EXP_SWArchitecture p. 121.
• Internal platform integration: Dependencies and usage patterns of other functional clusters such as Communication Management (AUTOSAR_AP_SWS_CommunicationManagement p. 34), Firewall (AUTOSAR_AP_SWS_Firewall p. 11), and Diagnostic Management (AUTOSAR_AP_SWS_Diagnostics p. 67) substantiate the universal role of the IdsM as a security collector.
• Additional data and timestamp providers: Specifications [SWS_AIDSM_10400] and [SWS_AIDSM_10500] govern the provisioning pattern for timestamps and context modifications, supplemented by architectural diagram AUTOSAR_AP_EXP_SWArchitecture p. 122.
• Reception of qualified events and operating modes: Requirements [SWS_AIDSM_10800] and [SWS_AIDSM_10600] describe egress communication and runtime configuration, illustrated in AUTOSAR_AP_EXP_SWArchitecture p. 123.
• Manifest and deployment modeling: Metamodel rules in AUTOSAR_AP_TPS_ManifestSpecification p. 257 as well as deployment mappings AUTOSAR_AP_TPS_ManifestSpecification p. 664 to AUTOSAR_AP_TPS_ManifestSpecification p. 669 ensure consistent instantiation and binding at design and load time.
• Error handling: Definitions [SWS_AIDSM_10204] and [SWS_AIDSM_10706] form the foundation of error handling for invalid event identifiers.