CYBERSECURITY IN AUTOMOTIVE
IDS/IPS Systems in Automotive – AUTOSAR Architecture and Vehicle Security
This article is part of a series dedicated to the topic of cybersecurity in the automotive industry, prepared by Krzysztof Labuda.
Introduction to the IDS/IPS Context in Automotive and the AUTOSAR Approach
In this part of the series, we expand on the topic of IDS/IPS systems in the automotive sector, which was previously introduced in the article “What Lies Beneath Automotive Cybersecurity?”. This time, we take a closer look at the IDS architecture through the lens of AUTOSAR (AUTomotive Open System Architecture), a widely adopted standard for designing secure automotive software.
AUTOSAR IDS – General Architecture of the Intrusion Detection System
According to the AUTOSAR documentation, the IDS (Intrusion Detection System) architecture defines a set of components and interfaces used for monitoring, analyzing, and responding to security incidents. A key element of this architecture is the concept of SeV (Security Events) – standardized security events logged within the vehicle software.
Source: https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_RS_IntrusionDetectionSystem.pdf
SeV and the Importance of Standardized Security Events
AUTOSAR defines standardized formats and interfaces for recording security-related events and incidents in the vehicle software using SeV (Security Events). Without such elements (metrics), there is no way to control or track the system. Thanks to these events and their accompanying parameters, the system allows for monitoring, auditing, and analyzing security events in order to detect and respond to security breaches or anomalies.
Physical and Software Security in the AUTOSAR Architecture
The architecture also supports mechanisms for detecting and mitigating attempts to tamper with vehicle software and hardware. This includes sensors, detectors, and algorithms to detect physical intrusion, unauthorized modifications, or abnormal behavior in the vehicle system. One of the main components here is SecOC, which will be discussed in the next part of the series.
Key AUTOSAR Components Related to IDS/IPS
To better understand how the intrusion detection system works, it’s worth getting familiar with the following core concepts and components:
Complex Driver Design (CDD): A software unit not standardized by AUTOSAR, which can access or be accessed through AUTOSAR and/or BSW interfaces. (BSW – Basic Software layer between the microcontroller and the RTE – RunTime Environment). This layered approach was discussed in the earlier part of the series.
SWC (Software Component): A component that contains application logic. In AUTOSAR, functionality is encapsulated within SWCs. For example, controlling electric windows in a car is performed by a dedicated SWC. SWCs communicate with each other or access lower layers via RTE ports.
SOC (Security Operations Center): An organizational unit for threat detection located outside the vehicle. It aims to respond to and prevent threats by coordinating all cybersecurity technologies and operations.
Security Sensors: Elements responsible for collecting and reporting security metrics and events to the IdsM.
Sem (Security Event Memory): A defined memory area for diagnostic events related to cybersecurity, separate from standard diagnostic event memory.
IdsM (Intrusion Detection System Manager): Buffers reported security events. It also applies a chain of filters to the reported SeV to assess their severity and criticality. In the vehicle, it can be considered the heart—and even the central nervous system (including the brain)—of the IDS.
Qualified Security Events (QSEv): If the SeV pass through the filtering chain, they are recognized as Qualified Security Events (QSEv). This is the module where critical decisions are made about sensor data.
Depending on the configuration of IdsM, the following scenarios are possible:
- Storing QSEv in the local Sem (security event memory) on the ECU,
- and/or serializing QSEv and sending it IdsR.
IdsR – Intrusion Detection System Reporter
IdsR receives QSEv from various IdsM instances across different ECUs. The communication protocol between IdsM and IdsR is defined in the IdsM protocol specification. IdsR may enrich the received data with additional information, such as geographical location. This raises considerations for compliance with regulations like GDPR, since location data (if linked to a vehicle user, as it usually is) may be considered PII (Personally Identifiable Information). Proper safeguards must be in place for both data in transit and at rest.
SOC and SIEM – Off-Vehicle Threat Analysis
Depending on the OEM’s (Original Equipment Manufacturer) needs, data can be propagated to the SOC for further analysis in a SIEM (Security Information and Event Management) solution. The SIEM system within the SOC has comprehensive capabilities to identify qualified security events (QSEv) transmitted from the vehicle and to respond effectively to potential cybersecurity incidents.
It’s important to note that the IdsR specification is not provided by AUTOSAR, suggesting a degree of flexibility. This is also the case for CDD and SWC, which report security events without strict implementation requirements.
Summary: A Modular Approach to Automotive Cybersecurity
In summary, AUTOSAR CDDs can act as sensors reporting SeV to the IdsM, which then processes and forwards QSEv to IdsR, and finally to the SOC. This entire data flow enables in-depth threat analysis and effective mitigation of potential cyberattacks. The modular and scalable architecture of AUTOSAR IDS forms the foundation of modern cybersecurity in connected vehicles.
Author: Krzysztof Labuda,
Security Testing Consultant
A participant in the Certified Ethical Hacker CEH v11 program, which teaches the latest commercial-grade hacking tools, techniques, and methodologies used by hackers and information security professionals.
