Automotive Intrusion Detection SystemsChallenges, concepts and implementation
Detecting Cyber-Attacks With Automotive Intrusion Detection Systems
In the future, intrusion detection systems (IDS) will also be used to secure vehicles against unauthorized access. However, these cannot simply be adopted from the IT environment. Instead, automotive-specific requirements such as limited computing power, low memory capacity and real-time capability must be taken into account. The standardization of such an automotive IDS facilitates the exchange of data between development tools and simplifies the cross-company implementation of security processes between vehicle manufacturers, suppliers and security experts.
Are you interested in more know-how about Automotive Intrusion Detection Systems? Then please go on reading the next chapters.
In case you are just interested in Cybersecurity products:
What is an Automotive IDS?
The ISO/SAE 21434 (Road vehicles - Cybersecurity Engineering) is the future security standard for motor vehicles. Among other things, it requires a defined incident response process based on the 5 steps shown in the figure. A vehicle manufacturer must respond to security vulnerabilities that have occurred in his vehicles. However, this can only be done if these vulnerabilities are known. An automotive IDS, which consists of an onboard IDS in the vehicles and a backend, contributes to this.
The IDS detects external attacks on ECUs and networks in the automobile, collects them and sends them to a backend at the vehicle manufacturer - also called a Security Operations Center (SOC). The OEM evaluates the data and then decides how to respond to the attempted attacks.
Requirements for Automotive-IDS
- In a distributed system such as the E/E architecture of a vehicle, no central ECU has knowledge of all security events on the other ECUs. So the IDS itself must also be implemented as a distributed system.
- For security reasons, a single point of failure should be avoided. The best way to do this is with a distributed IDS.
- To avoid making the overall system design unnecessarily complex, vehicle manufacturers want consistent interfaces – even if the software and hardware platforms are very heterogeneous.
- Consideration of the automotive-specific constraints of the ECUs, such as limited computing power and low memory capacity
- Avoiding unnecessary load on the networks, e.g. by collecting and qualifying the reported security events before sending them to the backend.
- Qualifying the security events under real-time requirements
Structure of an Automotive IDS
In simple words, an automotive IDS consists of five parts:
- The security sensors are software algorithms. They detect attacks and report them as security events to the Intrusion Detection System Manager.
- In the Intrusion Detection System Manager (IdsM), the security events pass through qualification filters and become qualified security events (QSEv) when specified criteria are met. The IdsM sends QSEvs that are considered relevant to the central Intrusion Detection Reporter and stores them in the Security Event Memory.
- The Intrusion Detection Reporter (IdsR) forwards the QSEvs to a Security Operations Center at the vehicle manufacturer.
- Security experts work in the Security Operations Center (SOC) and check the plausibility of the data supplied. Based on the findings, countermeasures are implemented that eliminate the detected threats and improve protection against similar attacks in the future.
- The Security Event Memory (SEM) enables storing of security events in a separate and specially secured area.
Standardization in AUTOSAR Classic
A first step towards standardization of IDS in AUTOSAR was done in 2018: the definition of Security Events and the Security Event Memory (Sem) in AUTOSAR 4.4.
Since AUTOSAR 20/11, the concept of the Intrusion Detection System Manager (IdsM) has been anchored in the standard with a focus on:
- High-level architecture for distributed onboard IDS
- Interfaces for reporting security events to the IdsM – from the basic software modules and application software components
- Qualification filters for transforming reported security events into qualified security events
- Communication between the modules IdsM and IdsR
- Standardization of security event types for selected base software modules
This figure provides an overview of the integration of the IdsM into the AUTOSAR Classic architecture: The blue arrows show exemplary connections of BSW modules with security sensors that report security events to the IdsM. After qualification of the security events in the IdsM, the QSEv are permanently stored in the ECU or sent to the SOC via IdsR, depending on the configuration. The orange arrows show the storage in the Security Event Memory (Sem). The Sem module uses the Non Volatile RAM Manager (Nvm) to store the data. Optionally, the Nvm can encrypt the data (green arrows) and store it in such a way that the IdsM detects manipulation. The brown arrows show the second way, when in addition to local storage, QSEv are sent via the PduR to the IdsR on another ECU.
Based on this basic architecture, onboard IDSs can be developed to achieve a balance between resource availability and the required security event data. To achieve this, the IDS must provide a high degree of configurability, for example by customizing the following aspects for each security event:
- Qualification rules
Local persistent storage of the QSEv – yes or no
Forwarding the QSEv to the IdsR – yes or no
Advantages of the AUTOSAR Solution
Provides a standardized technical framework for efficient implementing an onboard IDS
Offers interoperability of AUTOSAR Classic and AUTOSAR Adaptive
Avoiding a single point of failure by using a distributed approach
Scalable approach to balance available resources and reporting needs
Configurable detection and reporting behavior to meet OEM needs and constraints of vehicle E/E-architecture
Set of standardized security event types provided for standard software
Framework serves as an automotive industry “state of the art” reference concept for onboard IDS
Adoption of the framework can drive down costs for OEMs for implementing onboard IDS
Available AUTOSAR Basic Software
Vector played a leading role in the definition of an automotive IDS within AUTOSAR from the very beginning and provided the head of the concept group, Dr. Eduard Metzker. Therefore, an implementation of the IdsM module within MICROSAR – Vector's AUTOSAR basic software – was available at an early stage.
The IdsM (Intrusion Dection System Manager) module offers the advantages mentioned in the previous section and, together with many other modules, is part of the MICROSAR security solution. This also includes libraries with cryptographic functions, software for key and certificate management, firmware for hardware security modules and much, much more.
Start a Conversation
Are you interested in easy implementing an Automotive IDS? Then let’s talk!
Dr. Eduard Metzker
Helping to simplify Automotive Cybersecurity.
Recorded Lectures and Tutorials
AUTOSAR Intrusion Detection System Manager - MICROSAR IdsM
This tutorial shows the basics of the MICROSAR Classic module Intrusion Detection System Manager (IdsM), introduced with AUTOSAR 4.4. You experince the characteristics of security events, processing of these events in the AUTOSAR architecture and about configuration of the IdsM in the Vector tool DaVinci Configurator Pro.
Duration: 11 minutes
An AUTOSAR based Solution for Automotive IDS
Standardization of Intrusion Detection Systems for Vehicles via an AUTOSAR Approach
Reliably Detecting and Defending Attacks - Requirements for Automotive Intrusion Detection Systems
Many new customer functions in vehicles are based on extensive connectivity of onboard and offboard services. This also poses the challenge of protecting the vehicle against cybersecurity attacks. Along with established security mechanisms, industry experts are now discussing the use of Intrusion Detection Systems (IDS) intensively. But there are special challenges for their use in the automotive environment.