www.auto-innovations.net
15
'21
Written on Modified on
Escrypt News
IDPS: CONTINUOUS PROTECTION FOR VEHICLE AND FLEET
Once UN regulations UN R155 and UN R156 come into force, which is soon, OEMs will be required to permanently protect their vehicle fleets from cyberattacks. An intrusion detection and prevention solution (IDPS) makes just this kind of continuous risk management possible – with an intrusion detection system for detecting in-vehicle attacks, a vehicle security operations center for fleet-wide monitoring, and a security-compliant software update management system.
Network IDS and host-based IDS
Depending on the vehicle level at which intrusion detection is to take place, network-based or host-based intrusion detection systems (IDS) are used; each relies on different technology-specific IDS sensors. A network IDS has a broader field of view – ideally across all vehicle networks. Accordingly, their sensors can be arranged flexibly, say, on the ECUs that are assumed to have the best protection against access. However, with the exception of attacks via open interfaces, a network IDS detects cyberattacks or manipulation only once the ECU under attack has already been compromised. In contrast, a host-based IDS is typically implemented on a specific ECU, which means its field of view is limited to that ECU only. But the advantage of host-based IDS sensors is that they detect an attack on an ECU at the precise moment it happens.
Host-based and network IDSs are not mutually exclusive; they can be used together where it makes sense to do so to achieve the best possible outcome. When selecting IDS sensors, the decisive factor should always be that their technology is optimized specifically for the vehicle’s E/E architecture; regarding for example the degree to which the sensors are embedded, their consumption of resources, and the quality and processing requirements of in-vehicle networks. In addition, the IDS sensors used should always be developed specifically for automotive communication standards.
A distributed IDS as the vehicle’s nervous system
When it comes to potential cyberattacks, unauthorized access, and tampering, distributed IDS sensors behave like synapses in the vehicle’s nervous system. They log potential security events (SEv), such as anomalies in network traffic or malicious diagnostic requests, to the IDS manager (IdsM). From there, the consolidated log files (qualified security events, QSEv) are passed on to the IDS reporter (IdsR) for upstreaming to the backend. What is important here is that the rules are consistent in all three instances of the IDS; that is the only way to ensure the optimum implementation, detection accuracy, and effectiveness of the connected system.
Figure 1: Components and architecture of a distributed intrusion detection system (IDS) in the vehicle.
At the same time, it is important to reduce the volume of data as early as possible. As bandwidths and resources for data transfer and in the backend are limited, it is wise to use smart IDS sensors and IDS managers to first filter out false-positive security events, non-relevant events, or noise in the vehicle. However, to ensure effective end-to-end security, no relevant information must be lost; optimization of the data volume must not come at the expense of detection capability.
VSOC: Nerve center for fleet-wide monitoring
Just as intrusion detection is crucial in the individual vehicle, the consolidation and processing of event data in the backend is important for the connected vehicle fleet. This takes place in the vehicle security operations center (VSOC). With proactive security monitoring as its key objective, the VSOC is the nerve center of a control loop comprising monitoring, detection, analysis, response, and prevention. It relies on the interaction of three components:
- A software platform that aggregates data and processes it effectively,
- Processes that ensure and control the handling of security events, and
- Analysts, who examine, evaluate, and process the data manually.
A VSOC is tailored to the specific use cases in the automotive sector, because some of the potential threats and data that are analyzed are different than those in traditional IT. These include the IDS log files from the vehicles, but also fleet and vehicle data available from 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 controlled using such backend systems (e.g. via a smartphone app). Accordingly, all this automotive-specific data must be processed according to the VSOC’s own aggregation rules and data logic.
Figure 2: From intrusion detection to vehicle security operations (VSOC).
Moreover, the VSOC needs analysts who have specialist knowledge of the automotive domain and can expertly assess whether a report or an anomaly is based on a malicious intrusion or is a tolerable false positive. The key to a successful VSOC is collaboration between security and domain experts. This also enables the successive incorporation of domain knowledge into the optimization of the platform and processes.
Response by update and SUMS
Another key element of continuous risk management is the response. Software updates are an effective means of closing security gaps and identified vulnerabilities and restoring the vehicle’s “prevention status”; in other words, it is properly protected. The increasing connectivity of vehicles via wireless interfaces opens up the possibility of supplementing or even replacing conventional updates in the workshop with over-the-air (OTA) systems. This also makes it possible to shorten the frequency of updates as required and reduce costs.
These do not always have to be security-related updates; updates generally enable OEMs and fleet operators to improve and expand the functions of their vehicles. However, the cybersecurity of the updates themselves remains a crucial aspect that must be given appropriate attention and systematically implemented in the near future in line with the security-by-design requirements of UN regulations 155 and 156.
In the future, a software update management system (SUMS) will be needed to organize the preparation and distribution of software updates for the fleet based on defined processes. According to UN R156, a SUMS is responsible for, among other things, dissemination of information to OEMs or approval authorities, identification of software modifications relevant for type approval, traceability of modifications, possible interdependencies of updated systems, the integrity and authenticity of software updates, the functional safety of the vehicle, and even handling of failed updates.
Figure 3: Software update management system (SUMS) – For the secure rollout and installation of software update packages.
Ensuring the integrity and authenticity of the updates is the most important cybersecurity goal for update management. The aim is to absolutely prevent the misuse of update mechanisms to attack, manipulate, or disable ECUs or other instances in the vehicle’s internal network. A firmware over-the-air (FOTA) update must therefore follow fixed authoring security processes as well as a backend and in-vehicle security concept as part of integrated software update management.
www.escrypt.com
Figure 2: From intrusion detection to vehicle security operations (VSOC).
Moreover, the VSOC needs analysts who have specialist knowledge of the automotive domain and can expertly assess whether a report or an anomaly is based on a malicious intrusion or is a tolerable false positive. The key to a successful VSOC is collaboration between security and domain experts. This also enables the successive incorporation of domain knowledge into the optimization of the platform and processes.
Response by update and SUMS
Another key element of continuous risk management is the response. Software updates are an effective means of closing security gaps and identified vulnerabilities and restoring the vehicle’s “prevention status”; in other words, it is properly protected. The increasing connectivity of vehicles via wireless interfaces opens up the possibility of supplementing or even replacing conventional updates in the workshop with over-the-air (OTA) systems. This also makes it possible to shorten the frequency of updates as required and reduce costs.
These do not always have to be security-related updates; updates generally enable OEMs and fleet operators to improve and expand the functions of their vehicles. However, the cybersecurity of the updates themselves remains a crucial aspect that must be given appropriate attention and systematically implemented in the near future in line with the security-by-design requirements of UN regulations 155 and 156.
In the future, a software update management system (SUMS) will be needed to organize the preparation and distribution of software updates for the fleet based on defined processes. According to UN R156, a SUMS is responsible for, among other things, dissemination of information to OEMs or approval authorities, identification of software modifications relevant for type approval, traceability of modifications, possible interdependencies of updated systems, the integrity and authenticity of software updates, the functional safety of the vehicle, and even handling of failed updates.
Figure 3: Software update management system (SUMS) – For the secure rollout and installation of software update packages.
Ensuring the integrity and authenticity of the updates is the most important cybersecurity goal for update management. The aim is to absolutely prevent the misuse of update mechanisms to attack, manipulate, or disable ECUs or other instances in the vehicle’s internal network. A firmware over-the-air (FOTA) update must therefore follow fixed authoring security processes as well as a backend and in-vehicle security concept as part of integrated software update management.
www.escrypt.com
