Intrusion detection and prevention solution

Intrusion detection and prevention solution

Whitepaper

Immune system for connected vehicle fleets

2 Intrusion Detection and Prevention Solution © ESCRYPT GmbH. All rights reserved.

Protecting digitally connected vehicles and fleets against cyberattacks and unauthorized access is not something that is done once and for all. Rather, it is a continuous, ongoing process that automotive manufacturers and fleet operators in the near future will have to guarantee throughout the entire lifecycle of vehicles. New regulations by the World Forum for Harmonization of Vehicle Regulations (UNECE WP.29) prescribe the introduction of a certified cybersecurity management system (CSMS) by the middle of 2024 as a prerequisite for the type approval of new vehicle models. Over 60 countries have already recognized the regulations.

One of the requirements of UN Regulation No. 155 (UN R155) is that OEMs and fleet operators have to record security-relevant incidents in vehicles and derive responses for their fleets accordingly. Meanwhile, UN R156 sets out the need for a software update management system (SUMS) to create the conditions for secure software updates.

This white paper shows how the regulations can be implemented in practice – and how to successfully protect the connected vehicle not just against today’s threats and hacking strategies, but those of the future. Without the interplay between distributed in-vehicle sensor systems and continual cross-fleet security monitoring, these efforts cannot succeed.

Technically and organizationally, the ground has been duly prepared: intrusion detection sensor technology embedded in the vehicle network and in ECUs monitors and protects the ECUs and communication. In the backend, a vehicle security operations center (VSOC) monitors the security of connected vehicle fleets around the clock. Based on a security incident and event management (SIEM) system, the VSOC uses cloud technology and big data analysis methods as well as highly specialized security analysts.

3© ESCRYPT GmbH. All rights reserved. Intrusion Detection and Prevention Solution

Contents

New regulations for the connected vehicle 4

UN Regulation No. 155/156: Automotive security to become an ongoing mandatory obligation 4

ISO/SAE 21434: Standardized approaches in the event of cyberattacks 6

AUTOSAR: Helping safeguard E/E architectures 7

In-vehicle security – Access control and reporting system 8

Smart, connected, and decentralized: ESCRYPT’s distributed in vehicle intrusion detection architecture 8

IDS sensor technology: Monitoring network traffic 9

IdsM: Collection point for all security-relevant incidents 10

IdsR: Interface between vehicle domains and external security control center in the backend 10

Cloud-based Vehicle Security Operations Center 12

Keeping an eye on fleet security 24/7 13

Automated SIEM qualification of reported security events using the cloud, big data algorithms, and AI 13

Deeper risk analysis: A job for highly qualified security analysts and data forensics experts 13

Secure OTA updates for immunization of the entire fleet 14

A learning immune system 16

Where in-vehicle and backend solutions work together, every hacking attempt strengthens the defenses 16

Summary: The road to compliance with UN regulations leads through an IDPS 18


New regulations for the connected vehicle

As Working Party WP.29 in the United Nations Economic Commis-sion for Europe (UNECE), the World Forum for Harmonization of Vehicle Regulations is responsible for establishing internationally standardized regulations for vehicle manufacturers and harmonized criteria for the approval of new vehicle types and existing architec-tures. An increasingly important aspect of this is vehicle protection.

In view of the increasing digital connectivity of modern vehicles, the UN regulations are redefining the requirements for vehicle cybersecurity. After all, there is no doubt that the connecting of vehicles and fleets will bring new risks as well as the many benefits of safety, comfort, software upgrades and updates, the automation of driving, and the telematic optimization of traffic flows. By digitally connecting previously closed vehicle systems to the outside world, we are making them more susceptible to unauthorized access and cyberattacks.

According to UNECE, vehicle manufacturers (OEMs) and fleet opera-tors must minimize these risks throughout the lifecycle of vehicles and across fleets. UN R155 sets out which security measures have to be taken into account for the approval of new vehicle types. With connectivity progressing rapidly, UN R155 imposes a tight time frame: the new regulations are to enter into force in stages by July 2024. This regulatory step will enshrine security as a key element in the digitalization of modern vehicles.

UN Regulation No. 155/156: Automotive security to become an ongoing mandatory obligationUN R155 sends a clear signal: cybersecurity management will become a mandatory task for OEMs and vehicle fleet operators throughout the entire lifecycle of vehicles. Unlike in the domains of active and passive security, a one-time integration of suitable in-vehicle technologies is not enough. In fact, UN R155 defines security as an ongoing process that OEMs and fleet operators have to man-age along the value chain. This begins with detailed vulnerability analyses and systematic security by design at the development stage, includes continuous in vehicle security monitoring, and con-tinues with the building up of forensic expertise so as to be able to analyze attempted attacks in due depth and prevent the scaling of successful attacks to the fleet.

Operation of a certified cybersecurity management system (CSMS) and proof of a suitable IT security level for E/E architecture will be-come prerequisites for the approval of new vehicle types in the EU and Japan as early as July 2022. In mid 2024, the framework will be expanded to include the approval of vehicles with existing architec-tures. On top of the mandatory cybersecurity management set out in UN R155, UN R156 establishes standardized rules for the approval of vehicles with regard to software updates and software update management systems. One detail that should not be overlooked is that even existing architectures for which no IT security processes as described in UN R155 and R156 were originally foreseen need to be modernized punctually for type approval as of 2024.

Timeline for UN Regulation No. 155 (UN R155): appropriate cybersecurity will be a mandatory requirement to obtain approval for new vehicle types from July 2022 and for existing architectures from July 2024.

June 2020

Adoption of UN Regulation No. 155

for automotive cybersecurity

by WP.29

January 2021

UN Regulation No. 155comes into force

May 2021

Final draft ofISO/SAE 21434

July 2022

UN Regulation No. 155mandatory for

approval of newvehicle types (EU)

!

July 2024

UN-Regulation No. 155also mandatory for �rstregistration of vehicles

with existingarchitectures (EU)

!

August 2021

Publication ofISO/SAE 21434


To minimize cyberrisks for individual vehicles and entire fleets in a manner that is both meaningful and effective, the regulations laid down in UNECE WP.29 tackle the problem on four fronts:

■ Managing vehicle cyberrisks ■ Applying security by design during vehicle development to

mitigate risks along the value chain ■ Detecting and responding to security incidents across the

entire vehicle fleet ■ Providing safe and secure software updates and introducing

a legal basis for over-the-air updates (UN R156)

These address all phases of the vehicle lifecycle. However, the ma-jority of the measures, including the highly complex task of attack detection and defense, will be actively implemented only after start of production when vehicles and fleets are already in operation. This particular task serves as the basis for fleet protection. Only when attacks on the individual vehicle are reliably detected and analyzed

with suitable technical know-how will it be possible to prevent scal-able attacks on entire fleets.

This position depends both on having effective in-vehicle sensor technology and on the establishment of an organizational and pro-cedural superstructure, so as to be able to respond quickly to new kinds of dangers when needed and promptly take fleet wide defen-sive measures – for example, in the form of OTA security updates in accordance with UN R156. The UN regulations focus on both known and future risks. In this vein, they promote the interplay of prevention via security by design – which includes all attack vectors known at the time of development – and ongoing future-oriented monitoring.

Paragraphs 7.3.3 and 7.3.4 of UN R155 define the corresponding re-quirements for the implementation of measures with which vehicle manufacturers are obliged to ensure appropriate cybersecurity.

Firmwareupdate

OBD2

Remote access

Compromisedactuator

Key/certi�cate store

Mobiledevice

Softwarevulnerabilities

ECU

Man-in-the-middle attack

Externaldata media

Appdownloads

Spyingon user data

Key/certi�cate store

Operatingsystem

Personal data Browser

HMI

With regard to critical elements of the E/E architecture and appropriate security measures, all attack vectors of the vehicle must be considered.


To obtain type approval, they need to make sure that the compo-nents (ECUs) which make up the E/E architecture are sustainably safeguarded, and that the same goes for the connectivity between components and for all network communication both within ve-hicles and with the outside world.

ISO/SAE 21434: Standardized approaches in the event of cyberattacksAs a new technical standard, ISO/SAE 21434 “Road vehicles – Cyber-security engineering” will establish an important framework en route to a UNECE-compliant certified cybersecurity management system. The standard encompasses how to develop, manufacture, operate, maintain, and recycle a vehicle in accordance with cyber-security requirements. The final draft has been available since March 2021, with publication planned for the end of 2021. On the basis of the UN regulations, the standardization body places emphasis on the procedural character and the organization of security measures that need to shield the vehicle against cyberrisks throughout its en-tire lifecycle. Together, the UN regulations and ISO/SAE 21434 create the basis for industry-wide standardization of automotive security in an increasingly connected and digitalized world of transport. Based on these new requirements, manufacturers and suppliers can define and implement suitable processes, interfaces, and shared responsi-bilities.

ClassicR20-11

Adaptive

R20-11

Crypto stack

Secure communication

Secure diagnostics / logging

Identity andaccess management

Intrusion detection

Secure updates

Trusted platform

Security modules in AUTOSAR Classic and Adaptive (last updated November 2020).


AUTOSAR: Helping safeguard E/E architectures Fortunately, manufacturers who want to implement the safety re-quirements from UN R155 and ISO/SAE 21434 for their vehicles do not have to develop all the necessary safety modules themselves: AUTOSAR. The tried-and-tested platform, which was developed by a broad alliance of OEMs and suppliers from the automotive industry for the automotive industry, has been dealing with IT security for many years. This applies both to AUTOSAR Classic and to AUTOSAR Adaptive. Based on standardized specifications, both platforms are already defining important IT security building blocks, upon which companies can build when implementing the new UN regulations for new models and existing architectures.

These building blocks include the crypto stack for providing cryp-tographic primitives, keys, and certificates as well as defined com-munication mechanisms for secure data traffic – such as secure onboard communication (SecOC) for CAN or IPSec for TCP/IP com-munication via automotive Ethernet. In addition, AUTOSAR features diagnostic and logging functions, identity and access management, a secure update function, and last but not least, the necessary provi-sions for the integration of a distributed intrusion detection system (IDS) for ongoing attack detection across the vehicle lifecycle.

Since Release R20-11, AUTOSAR contains detailed specifications for in-vehicle attack detection based on a distributed intrusion detec-tion system (IDS). The basic principle is as follows: IDS managers (IdsMs) in the ECUs collect the security events, which are detected for example by IDS sensors allocated to them, in order to pass them on in cleaned-up, aggregated form to an IDS reporter (IdsR) in the telematics unit. From there, they are transmitted to the monitor-ing infrastructure, such as a VSOC. The secure update function in AUTOSAR Adaptive then helps fix any identified vulnerabilities by receiving and processing security updates for individual applica-tions or even for the entire platform. The respective updates are signed by the OEM backend to ensure their trustworthiness.

In view of the tight time and cost restraints, it is advisable to build on the AUTOSAR building blocks when implementing the UNECE requirements. However, effective holistic automotive security that complies with UN R155/R156 cannot be implemented with AUTOSAR alone. Which measures are further required in the vehicle, the vehicle security operations center (VSOC), and the OEM back-end are explained in the next two chapters of this white paper.

Intrusion detection systems require very strong domain know-how, especially for non-traditional passenger cars.


Security measures for connected vehicles play twin roles: they protect the ECUs and networks against access from unauthorized parties and cybercriminals; and in the event of an attack that suc-ceeds despite these safeguards, they ensure that the breach cannot extend beyond the compromised section of the individual vehicle or cross over to other vehicles in a connected fleet. To this end, there is a second level that goes beyond the protection of indi-vidual vehicles: sensors embedded deep in the distributed system detect anomalies, record them, carry out a preliminary analysis in the vehicle, and forward these pre-processed findings (qualified security events) to a vehicle security operations center (VSOC) for deeper analysis. This distributed in-vehicle attack detection plays a key role in the protection of individual vehicles and whole fleets.

Smart, connected, and decentralized: Distributed in-vehicle intrusion detection architectureSensors strategically distributed through the vehicle are core com-ponents of an in vehicle solution. They monitor the data traffic and the system behavior and compare the latter against “normal behav-ior,” among other points of comparison. Through clever placement of IDS sensors (in a gateway, for example), they can monitor the relevant CAN data traffic – or keep track of automotive Ethernet communication via an automotive firewall/IDS solution built into the Ethernet switch. If the sensors register suspicious activity, such as anomalies in cyclical frames or malicious diagnostic requests, they log them as security events. Integrating these IDS functions into modern E/E architectures and adapting them to the limited resources in the vehicle and to the applicable regulations requires specific know-how. ESCRYPT’s AUTOSAR-compliant distributed IDS for vehicles is a perfect example of how the future requirements of UN R155 can be fulfilled.

In-vehicle security – Access control and reporting system

ESCRYPT’s dIDS architecture – Application example

Telematic ECU

Gateway / domain controller

AUTOSAR CP ECU AUTOSAR AP ECU

CycurGATE smart sensor

CycurIDS-M

CycurIDS-MCycurIDS-M

CycurIDS-M

CycurIDS smart sensor

NIDS sensorNIDS sensor

NIDS sensor

NIDS sensor

HIDS sensor

HIDS sensorHIDS sensor

HIDS sensor

HIDS sensor

CycurIDS-RCycurIDS-R Intrusion detection reporterCycurIDS-R collects QSEvs from different sources/ECUs. Using advanced aggregation techniques and event processing, CycurIDS-R reports QSEvs to an event reporter higher up in the hierarchy or directly to a VSOC.

CycurIDS-M Intrusion detection managerCycurIDS-M collects and qualifies (pre-filters) security events (SEVs) and sends the qualified security events (QSEvs) to the CycurIDS-R or retains them in non-volatile memory.

Smart sensors CycurIDS/CycurGATESmart sensors aggregate and pre-select potential security events (SEVs) to enable fast and correct analysis.

SensorsDetection of security events by host-based IDS (HIDS) or network-based IDS (NIDS)

Vehicle security operation center


IDS sensor technology: Monitoring network trafficDepending on the vehicle level at which intrusion detection is to take place, network-based IDS (NIDS) or host-based IDS (HIDS) sen-sors are used. NIDS sensors have a broader “field of view” – ideally across all vehicle networks. In contrast, HIDS are suitable for moni-toring individual ECUs. As such, both fulfill different but vital and complementary functions. While HIDS sensors detect an attack pre-cisely where it occurs, the NIDS sensor system of flexibly selectable ECUs keeps watch over large swaths of the network.

If the strengths of HIDS and NIDS are properly combined, they create the foundation for an equally flexible and reliable access control and defense system embedded deep within the vehicle. It is crucial to optimize the sensors for the respective technology (such as CAN or automotive Ethernet) – in other words, the degree to which they are embedded, their consumption of resources, and their performance need to fulfill the specific requirements of the ECUs and networks to be protected. This means, for example, using IDS sensors that were developed for automotive communication standards such as CAN and automotive Ethernet.

The combination of distributed network-based intrusion detection for CAN buses, the close monitoring of Ethernet traffic, and a reli-able firewall solution produces a sensitive reporting system that quickly recognizes attacks from outside – in particular, attacks on

driving-relevant systems such as the steering or engine control – as well as securely detecting manipulation attempts via easily acces-sible interfaces such as the diagnostic interface.

To this end, the IDS sensor system monitors the CAN traffic from, say, a central gateway and analyzes it according to rule-based specifications, optionally using a signature-based approach, or in the case of attacks that have not yet been classified, using heuristic methods. In addition, HIDS sensor technology monitors the integ-rity of the operating system and the applications directly at the re-spective ECU; for example, at the connectivity ECU or, in the future, one of the vehicle computers that are increasingly being used. The HIDS registers changes in system and application files, for example, and monitors outgoing and incoming network connections.

If you picture a distributed IDS as a vehicle’s nervous system, then the distributed HIDS and NIDS sensors function as sensi-tive synapses with maximum coverage of the potential points of attack in the vehicle. If the hybrid sensor systems register security-relevant events and anomalies, this sets in motion a comprehensive reporting, analysis, and reaction chain, where other central IDS instances play the leading role within the vehicle: IDS manager (IdsM) instances and the IDS reporter (IdsR). As AUTOSAR-compliant modules, they serve the purpose of distributing, forwarding, and collecting all events in the vehicle network all the way through to

Distributed vehicle IDS architecture

Vehicle Computer (e.g. AUTOSAR adaptive)

Telematics Control Unit

Mobile Network Provider

Vehicle Backend Security Analysis, Security Incident Response & Threat Intelligence

Opt

imiz

atio

n Autom

ation

Automated Assessment

Level 1

Level 2

Advanced Threat Analysis

Incident Response

Incident Response

In-vehicle distributed IDSCollects security incidents, performs pre-analysis and communicates with the backend

IDS SensorsIdentify security incidents on host and network level

IDSSensors

IDSSensors

IDSSensors

IDSSensors

IDSSensors

IDSSensors

CycurIDS-MCycurIDS-M

CycurIDS-R

Gateway (e.g. AUTOSAR classic)

IDSSensors

IDSSensors

IDSSensors

CycurIDS-M

CycurGUARD

Available ESCRYPT IDS Sensors

CycurIDS-ETH

CycurIDS-CAN

CycurGATE


coordinated transfer via connectivity ECUs to the vehicle security operations center (VSOC) or alternatively to the OEM backend. The advantage of these IDS solutions developed especially for embedding in modern vehicles is that they significantly reduce the bandwidth requirements for the transmission of security monitoring information. Here, the IDS acts as a pre filter: it scans all the data traf-fic and the events on the ECUs and, instead of sending voluminous logs, it reports only the relevant anomalies to the VSOC or backend, which greatly reduces the quantity of data transmitted.

IdsM: Collection point for all security-relevant incidentsIf the IDS sensors distributed throughout the ECUs and networks register anomalies in the network traffic or malicious diagnostic requests, then first of all they forward the findings to the next-highest instance: the IdsMs that are also distributed throughout the vehicle. These IDS managers collect the incoming messages from the specific ECUs, data networks, and gateways and subject them to a preliminary analysis. The purpose here is to filter out false-positive security events, non-relevant events, and noise. An example would be login attempts from non-defined CAN IDs or Ethernet MAC addresses that are picked up by a NIDS sensor. Another would be repeated attempts at illegitimate authentication for a diagnostic session that are detected by a host-based sensor. Even if access fails, security events would be logged in such cases, as they could be relevant for the subsequent forensics and evaluation of the risk situ-ation. After all, it could be the forerunner of a multiple-phase attack (cyber kill chain).

The objective of pre-selection via IdsM is to reduce the data vol-ume to the necessary amount so that only qualified security events (QSEvs) are forwarded to an external monitoring infrastructure for further analysis. To this end, a central data format must be defined in the IdsM for the security events recorded in the IDS sensors. It can also be specified in the IdsM in advance which security events are prioritized as relevant and are thus forwarded as QSEvs to the next IDS instance: the IDS reporter (IdsR) built into the telematics ECU.

IdsR: Interface between vehicle domains and external security control center in the backendIn ongoing cybersecurity monitoring as required by UN R155, the IdsR functions as the central interface. From there, QSEvs pre-filtered by the IdsMs are forwarded to an external VSOC that is responsible for the entire fleet or an OEM backend. Using modern aggregation techniques, the IdsR collects QSEvs from the IdsMs and smart sen-sors. Once it has carried out a further preliminary analysis on them, it cleans them up and forwards them to a non-volatile storage unit for subsequent transfer or else sends them directly to the VSOC or OEM backend.



Analyst Workbench

SecurityAnalyst

SIEM

SOC PlatformMobile network operator

Context datapush/pull

IDS eventsIDS BackendVehicle backend

Fleet DataBackend

SIEM feeder

Contextualizer

Acceptor/Normalizer

IT Systems

Log data

CycurGUARD

VSOC

Regi

on E

U

Regi

on N

A

Regi

on E

U

Regi

on N

A

Threat intelligence

VSOC Infrastructure

Vehicle Databases

Cloud-based Vehicle Security Operations Center

Since the data from the various sources is usually available in differ-ent formats and different data structures, it must be processed ac-cording to certain aggregation rules and its own data logic before it can be integrated into the SIEM solution. This task is rather complex. At ESCRYPT, CycurGUARD was developed, handles this step, and en-sures that the data can be cross-referenced so that the entire range of detection mechanisms in the SIEM system can be used.

However, SIEM alone is not enough. Should the SIEM analysis reveal the need for further action – for example, because the attack pat-tern is new or the analysis points to a structural security gap – then the second level comes into play: highly specialized automotive security analysts and data forensics experts. These are organized together with the SIEM system in an operational unit: the vehicle security operations center (VSOC). In the worst case, OEMs and fleet operators can respond through the VSOC and derive new protec-tive measures for all vehicles in their fleets – for example, the rollout of a new over-the-air firmware update.

For the ongoing cross-fleet security process as set out in UN R155, a process designed to arm vehicles also against the threats of the more distant future, in vehicle measures alone are not enough. Instead, it is vital to safeguard each individual vehicle and its subsystems with fire-walls, to control access, and to detect manipulation attempts – and aggregate all QSEvs from all vehicles in the field in order to systema-tically evaluate them. After all, the goal of immunizing whole fleets against cybersecurity risks is contingent on QSEvs being continuously investigated for new attack patterns and potential points of attack.

This investigation takes place at two complementary levels: first, the reported QSEvs are aggregated in a security incident and event management (SIEM) system. Supported by cloud technology, big data analysis, and artificial intelligence (AI), the SIEM system qualifies and validates the events on a largely automated basis. To enable a comprehensive analysis, other data sources are included in addition to the QSEvs from the vehicles themselves. These sources include primarily the fleet and vehicle data available at OEMs and fleet operators, obtained through telematics systems, for example. It is also possible to incorporate data into the analysis from the vehicle’s backend IT systems, especially where vehicle functions are con-trolled using such backend systems (e.g. via a smartphone app).

Components of a complete vehicle security monitoring system.


Keeping an eye on fleet security 24/7Cyberattacks and manipulation attempts can occur at any time in any region without warning. To lose no time in such an event and quickly prevent any crossover to further vehicles in the fleet, global OEMs and fleet operators depend upon a VSOC, which collates relevant events, conducts analyses, and handles responses around the clock. Using a combination of automated SIEM solutions and manual expert teams, the VSOC keeps track of which data the vehicles in the field are transmitting and what acute threats and risks they pose.

Automated SIEM qualification of reported security events using the cloud, big data algorithms, and AIThe SIEM system collects the data from various security-relevant data sources and puts it through an automated evaluation in real time. To do this, it uses machine learning methods, which also help it derive its own models from the existing database. As a learning system, SIEM’s capabilities grow constantly, and it is therefore able

to detect, classify, and evaluate relevant IT security incidents with ever greater efficiency and finer differentiation. Meanwhile, its real-time analysis focuses on known attack patterns and whitelisting/blacklisting methods. In comparisons, it filters all attacks and ma-nipulation attempts that follow known patterns out of the mass of incoming security logs. Dashboards and security reports visualize the findings of this automated analysis. If vehicle protection is to be truly complete, however, it must also analyze previously unknown attack scenarios and validate their threat potential. Here we see a gap opening up, as there is a lack of vulnerability management solutions with standardized applications in the automotive security environment. This calls for the specific know-how of highly special-ized cyberdefense teams.

Deeper risk analysis: A job for highly qualified security analysts and data forensics expertsOn top of operating an automated SIEM solution, it is advisable to incorporate a threat intelligence solution. This deepens the com-

Fleet Data Backend

Vehicle Databases

IT Systems

Platform

Process

People

AnalysisImplementation of Response

OEMVehicle Backend

VSOC

Security incident reports: Detailed summary and actionable

response recommendations

Filtering false positives

Aggregation of all incident data

Contextualization

OEM Responsibility

ESCRYPT offers a VSOC for connected fleets that enables OEMs to establish a life cycle of permanent security monitoring. This puts OEMs in the position to implement continuous adjustments improving vehicle security as response to the UN R155. We provide:

■ VSOC Use Cases: Successive build-up of library of VSOC use cases based on vehicle fleet data ■ VSOC Operation: Operative infrastructure (platform, processes, analysts) for continuous processing of data


parative SIEM approach by analyzing the database for symptoms (indicators of compromise) of new attacks and new methods of attack. (V)SOC operators share the corresponding findings in the interests of industry-wide security. But even that is not enough. To remain capable of acting against previously unknown threats, there are highly specialized automotive security experts working in the VSOC, who analyze the attack pathways and systematically expand the methodology for threat detection. The overriding goal of this manual analysis is to expand the capabilities of the SIEM system and the smart IDS sensors such that they can subsequently recog-nize new threats automatically. In this way, fleet operators receive valuable actionable information, on the basis of which they can immediately develop and roll out countermeasures.

This reporting and reaction chain presupposes that automated and manual analyses are intelligently intertwined. The automatic classi-fication of data and events and the automatic processing of known attacks furnishes the required overview and clustering, which allows the analysts to intervene in a time- and cost-efficient manner at the precise moment when such action is called for with the emer-

gence of new threats. This creates a closed security loop – a learn-ing system whose detection accuracy increases with every attack and every manipulation attempt, as these are used to optimize the stored set of rules for automated SIEM analyses and the smart IDS sensors in the vehicles. Ideally, the findings from the field data of millions of vehicles are continually “coded.” The detection rate in the system increases continuously – and consequently, so too does the system efficiency, because a constantly growing proportion of analyses can run on a fully automated basis.

Secure OTA updates for immunization of the entire fleetTo enable the closed security loop described above to cover the systems of all vehicles in the field, the conditions must be created for secure software updates. After all, only by means of the con-tinual updating of the rules stored in the IDS sensors will an IDS be transformed into a solution for intrusion detection and prevention. In this respect as well, UN R156 supplements the ongoing cyber-security management laid down in UN R155 by means of specific requirements for a secure software update management system (SUMS).

Software update management system (SUMS) – For the secure rollout and installation of software update packages.

Campaignmanager

Softwaremanagement

server

Softwaremanagement

client

Vehicle /manifestdatabase

Downloadpackages

(repository)

Validation ofdownload

package (QM)

Creation of downloadpackage

Preparation of download packageson the basis of o�cially approved or

non-approval-relevant �ash data packages

Campaigns and �eet managementfor traceability of SW per vehicle

Authentic and con�dential communication pathwaysfor the exchange of download packages and for

providing feedback about progress of installation

Flash datarepository• Flash data packages• Type approval• RXSWIN

• Veri�cation of signature• Decryption, if necessary Flash manager

Expansion or adjustment of existing OEM requirements for secure �ashing

Flash-Manager

Downloadmanager

• Calculate dependencies• Convert format• Sign and (if required) encrypt


The core task of a SUMS is to prepare and distribute software updates to the fleet following defined processes. For updates to be secure, there must be clear rules governing how information is passed on to OEMs and approval authorities, the potential effects of subsequent software modifications on type approval must be clarified, and the traceability of all modifications must be ensured. In addition, the possible interdependencies of updated systems must be clarified and the functional safety of the vehicle and the integrity and authenticity of the software updates must be guaranteed. And UN R156 stipulates that clear rules are also needed for how to deal with failed updates.

From a security perspective, the most vitally important goal of a SUMS is to ensure the integrity and authenticity of updates. Under no circumstances should it be possible for the update mechanisms to be abused by unauthorized parties in order to manipulate or deactivate ECUs in the in-vehicle network.

Corresponding authentication solutions should safeguard updates in specialist workshops as well as for firmware-over-the-air (FOTA) updates. To this end, the following requirements set out in UN R156 must be fulfilled:

■ Authoring security processes: These ensure that update pack-ages created by OEM developers or suppliers are released after

validation exclusively by specially authorized units by means of a digital signature. As an option, the packages can be additionally encrypted – for example, to protect intellectual property (IP).

■ Backend security: The backend itself must be protected using a defense-in-depth approach such that validated update packages are secured against unauthorized access. In any case, the back-end is a trouble spot in the security chain, because this is where rollouts of the updates to the fleet are controlled and usually also where the error messages from the vehicles are managed. According to UN R156, moreover, the backend is responsible for the central documentation of the respective software statuses on individual ECUs and in the vehicles across the entire fleet in order to guarantee the required traceability.

■ In-vehicle security concept: In addition, secure updates are con-tingent upon an in-vehicle authenticity check in which the digital signature is checked as well as the respective planned and actual states of the software packages. If necessary, the vehicle status should also be checked. The latter is needed above all when updates affect the engine control, the steering system, or other safety-relevant domains. Automotive know-how is called for here in order to harmonize the applicable regulatory requirements with the technical requirements.


A learning immune system

These days, we are more aware than ever of the importance of the human immune system, which protects us in particular from patho-gens that it knows. If a new threat arises, then the requisite immune response can be activated by specific vaccines. A similar pattern must underlie the immunization of connected vehicle fleets in the future.

What is needed is a holistic cybersecurity system that routinely fends off known dangers and attack strategies – but that is also capable of quickly countering new attack techniques and con-stantly changing threat situations with suitable new protection mechanisms. This adaptive “immunity” can be implemented with an intrusion detection and prevention solution (IDPS). An IDPS combines intrusion detection in the vehicle with monitoring, analysis, and determination of all necessary countermeasures in the backend – and with an over-the-air software update management system as a “vaccination campaign” for the fleet. In this way, an IDPS can continuously shield whole fleets against cyberrisks in a highly effective manner.

Where in-vehicle and backend solutions work together, every hacking attempt strengthens the defensesThis generally begins with AUTOSAR-compliant in-vehicle measures, the integration of which follows the security-by-design approach. First of all, firewalls and hardware security modules (HSMs) protect the onboard communication, subsystems, and ECUs, so that there cannot be a successful attack on or manipulation of the overall system and safety-relevant domains. And second, IDS sensors embedded directly in hosts (ECUs, vehicle computers) and data networks (CAN, Ethernet) constantly check whether anomalies such as cyclical messages or malicious diagnostic requests occur. Based on stored rule sets, the smart sensors and the IdsM instances can already identify – and at the same time, log – known attacks. If the smart host- and network-based IDS sensor technology registers indications of new attack patterns and attempted manipulations that they cannot qualify directly on board with the stored rules, it transmits them along with the known hacking attempts in the form of SEvs to a VSOC or alternatively to the OEM backend for deeper analysis. There, the QSEvs filtered by the IdsM go through an auto-mated security incident and event management (SIEM) process supported by AI technologies. Any security events that point to new, as yet unknown attack patterns and strategies are deliberately

filtered out of the logs. While security events that indicate known attack patterns can usually be processed automatically, security events that could indicate new, as yet unknown attack patterns and strategies are also filtered.

Then it is time for the specialists in this immune system for con-nected vehicle fleets to step in. Security analysts and data forensics experts analyze the strategies of the new attacks and manipulation attempts and deliver actionable information to the developers at the OEM or contracted supplier. On the basis of this informa-tion, they develop suitable defensive measures for the new attack type, which in the case of acute threats they can then transmit to all vehicles via OTA update. Among other benefits, this serves to continuously expand the set of rules stored in the smart IDS sensor system. In this way, each attack on each individual vehicle strength-ens the immune system of the fleet and makes its immune defenses more efficient. In the interplay between decentralized in-vehicle sensor technology, centralized threat intelligence in the VSOC, and secure OTA redistribution of a suitable immune response to the vehicle’s decentralized IDS and defense systems, the closed secu-rity loop creates a learning system. This learning system fends off known attacks on a fully automated basis, and in the case of a new “pathogen,” it immediately compiles the necessary information for the development of a suitable “vaccine” code.

The new cyberrisks associated with the digital connectivity of mod-ern vehicles are minimized effectively through ongoing, closely interconnected security monitoring and the possibility of a central-ized response to any threat – even ones arising in the distant future. As such, ESCRYPT gives the automotive industry the opportunity to punctually ensure the continuous protection of connected vehicle fleets against the cyberrisks of today and tomorrow as required by UN R155.


In the EU, Japan, Korea, and many other countries worldwide, the UNECE regulations on the cybersecurity of connected vehicles make continuous attack detection and defense a condition for type approval.

“The vehicle manufacturer shall implement measures for the vehicle type to:

(a) detect and prevent cyber-attacks against vehicles of the vehicle type;

(b) support the monitoring capability of the vehicle manufacturer with regards to detecting threats, vulnerabilities and cyber-attacks relevant to the vehicle type;

(c) provide data forensic capability to enable analysis of attempted or successful cyber-attacks.” (7.3.7)

UNECE WP.29


Summary: The road to compliance with UN regulations leads through an IDPS

By virtue of its rigorous focus on and active participation in the universally recognized AUTOSAR standard (AUTOSAR Classic / AUTOSAR Adaptive) and in the relevant regulatory bodies, ESCRYPT has successfully managed over the past few years to precisely align its portfolio of security solutions for modern vehicle architectures with the regulatory and technological requirements of the automotive market. In the course of this strategy, ESCRYPT has systematically worked on developing all the building blocks of the intrusion detection and prevention solution (IDPS) described in this white paper.

These years of preparation have laid the groundwork for what we can deliver today. In conjunction with our partners from the Bosch family and through worldwide collaborations, for example with KPMG management consultants for our PROOF services and with major semiconductor manu-facturers, we offer a holistic end-to-end solution that allows OEMs and fleet operators to achieve prompt compliance with the new UN regula-tions and their implementation as per the ISO/SAE 21434 standard. Time is of the essence: aside from the tight time frame for the incremental entry into force of the UN regulations for new vehicle types as of 2022, and for existing architectures as of mid-2024, there is an urgent need for effective, holistic protection in view of the rapidly advancing connectivity of mod-ern vehicle fleets. What’s at stake is the security of each individual vehicle, the safety of the occupants – and the most precious commodity in our industry: the trust of our customers.


All information provided is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate

and up-to-date information, there can be no guarantee that this information is as accurate as it was on the date it was received or that it will continue to be accurate in the future.

No one should act upon this information without appropriate professional advice and without thoroughly examining the facts of the situation in question.

© ESCRYPT GmbH. All rights reserved.

Last updated: 09/2021

AuthorsDr. Jan Holle Lead Product Manager Intrusion Detection & Prevention [email protected]+49 (711) 3423-2225

Dr. Jens GrammSenior Product Manager Vehicle Security Operations Center [email protected]+49 (711) 3423-3718

Dr. Siddharth Shukla Product Manager Intrusion Detection System & Automotive [email protected]+49 (711) 3423-2819

Andreas WeberProduct Manager Intrusion Detection [email protected]+49 (711) 3423-2960

Niclas WillTrainee Product ManagementIntrusion Detection & Prevention [email protected]+49 (711) 811-27975

ESCRYPT GmbHBorsigstraße 2470469 Stuttgart, Germany+49 (234) [email protected]

www.escrypt.com

ReferencesIntrusion detection & prevention solution, Hanser automotive 03-2020

Lifecycle security, ATZelektronik 11-2020

Vehicle security operations center, Hanser automotive 06-2020

In-vehicle attack detection via Intrusion Detection System, Automobil Elektronik 07/08-2021

Using AUTOSAR to achieve UNECE-compliant cybersecurity, ESCRYPT white paper, 03-2021

Automotive cybersecurity – Part 1: CSMS & AUTOSAR, Elektronik automotive 07-2019

UN Regulation No. 155 – Cyber security and cyber security management system, March 4, 2021, https://unece.org

UN Regulation No. 156 – Software update and software update management system, March 4, 2021, https://unece.org

Additional InformationIDPS-Website: https://www.escrypt.com/en/solutions/intrusion-detection-prevention-solution

IDPS-Flyer: https://www.escrypt.com/sites/default/files/flyer/210720_ESCRYPT_Flyer_IDPS_EN_screen.pdf

IDS-Webinar I: https://www.escrypt.com/en/webinarrecording/CycurIDS-ETH

IDS-Webinar II: https://www.escrypt.com/en/node/911

Documents

Intrusion detection and prevention solution