In today’s automotive landscape, connectivity stands as a cornerstone of innovation driving vehicle manufacturers. It enables the development of new features tailored to customer needs, such as controlling vehicle functions via smartphones and facilitating fleet management with real-time vehicle data. However, making vehicles part of the internet of things by integration of connected edge devices, has substantially expanded the cyber security threat landscape for vehicles. Consequently, there has been a massive increase in vehicle hacks, research on vehicle cyber security and significant industry investment in protecting products and consumers against cyber-attacks.
Even regulatory bodies, recognizing the importance of cyber security, have implemented regulations such as UN – R 155, mandating the implementation of a Cyber Security Management System (CSMS) for vehicle manufacturers seeking to sell their products in the associated markets. Similar regulations covering important markets like China or India are also coming up.
One of the major challenges in the domain of vehicle cyber security and by this within the mandatory CSMS is to realize a proper vehicle security monitoring. In this article we want to dive into the challenges of vehicle security monitoring and see how honeypots can contribute to solving them.
Challenges in Vehicle Security Monitoring
Let’s start with getting a better understanding on vehicle security monitoring by looking on some of the major UN – R 155 requirements on this topic:
7.2.2.2
The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management System ensure security is adequately considered, including risks and mitigations listed in Annex 5. This shall include:
g. The processes used to monitor for, detect and respond to cyber-attacks, cyber threats and vulnerabilities on vehicle types and the processes used to assess whether the cyber security measures implemented are still effective in the light of new cyber threats and vulnerabilities that have been identified.
7.2.2.4
The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management System will ensure that the monitoring referred to in paragraph 7.2.2.2 (g) shall be continual. This shall:
b. Include the capability to analyse and detect cyber threats, vulnerabilities and cyber-attacks from vehicle data and vehicle logs. This capability shall respect paragraph 1.3. and the privacy rights of car owners or drivers, particularly with respect to consent.
7.3.7
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.
To sum this up, the regulation requires the manufacturers to build up a framework that ensures a continual surveillance of their products on cyber security events like new vulnerabilities or actual attacks, all this based on actual vehicle data. It also requires manufacturers to implement measures for the respective vehicle type that ensure support of the vehicle security monitoring objectives. This could mean implementing measures which provide meaningful security data.
To cope with those requirements, vehicle manufacturers need to invest heavily into their field of vehicle operations by setting up a so-called Vehicle Security Operation Center (VSOC) by either hiring staff or leveraging resources from an existing IT-SOC and equipping it with the right toolset.
Typically, the VSOC is formed by a group of vehicle security experts and tools that need to be available 24/7, ready to analyze incoming cyber security information to qualify cyber security events out of it. These need then to be further investigated in order to enable the also required vulnerability or incident management for the actual treatment.
It becomes clear that it is a hard task for a manufacturer to build up a good vehicle security monitoring. There are lots of challenges in getting the right resources, ensure their skill level as well as having procedures in place that allow you to react on events.
However, the biggest challenge might be already the first step of collecting actual relevant security information about the products and identifying security events out of it.
Due to this, this will be the focus of this article in the following.
Generally, the common approaches to provide input to the VSOC can be clustered into three categories, all with their own challenges:
Non-technical input sources:
The first approach a manufacturer normally takes to get security information on his product landscape, are the non-technical measures. This means demanding the manufacturers suppliers to do a security monitoring as well, release a vulnerability disclosure program that provides interfaces to researchers and set up a threat intelligence service that tries to filter publicly available data like vulnerability data bases, forums, etc. for security information that affects the relevant products.
All mentioned means are great and there is no way around them. But the challenge with them, is that the raised events are often very generic and not vehicle specific, which leads to a high internal analysis effort. Furthermore, those measures alone do not fulfill the regulation requirements to perform a monitoring based on actual vehicle data.
Detection based on functional vehicle data
Due to this, as a next step, manufacturers normally screen their existing IT systems for already available vehicle data that is suitable to identify indicators of malicious behavior. Typically, data from e.g. software update systems or workshops can be meaningful here.
However, as this data was never designed for the purpose of doing vehicle security monitoring, the ability to detect security events with functional data is often very much limited.
Embedded Intrusion Detection Systems
Out of these limitations of functional data, a technology that meanwhile finds more and more adaption in the industry is the integration of so-called Intrusion Detection Systems (IDS). IDS are specialized security systems that are integrated into the vehicle to provide great cyber security insights to the vehicle manufacturers VSOC.
Unfortunately, IDS are often rather complex systems, that need high internal implementation and maintenance efforts, as well as a hardware platform that can offer the needed resources for them.
If not configured with great care they tend to create high rates of false positives, increasing the needed efforts, complexity and by this also costs in your vehicle security operations even more.
In summary, while there are various approaches to gathering input for a vehicle security monitoring, each comes with its own set of relevant challenges. Therefore, when looking for a simple yet powerful monitoring approach, honeypots stand out as a promising solution, offering an innovative approach to augmenting vehicle security monitoring capabilities.
Using Honeypots for Vehicle Security Monitoring
Honeypots are very well monitored decoy systems that are integrated into an eco-system (like a vehicle and its backends) and intended to be discovered by attackers and then being attacked, first.
Honeypots thereby provide early notifications on malicious activities, detailed data, allowing to gain knowledge on actual threat landscape, as well as protecting the real assets by luring attackers away from them. All this with typically a low false positive rate as honeypots have no real functional valid use case and therefore no legit interactions with them.
With this, they seem like a great addition to complement the approaches to vehicle security monitoring.
This is also shown by various research out there, discussing the use of honeypots in the automotive security domain. To list some:
- “A strategy for vehicular honeypots” by Yvonne Maria Schmitz Née Nestler
- “Investigating the Use of Honeypots in Vehicles” by Elin Eriksson and Lisa Fahlbeck
- “IGNITE: Honeypot Flavors: Open-Source Honeypots and their Use in the Automotive Industry” by Niclas Ilg
However, developing a good honeypot solution is not a trivial task. You need to build and operate a system that is attractive to an attacker, implements very well monitoring and is not easily disclosable as a honeypot by an attacker. All this while being integrable into your eco-system without introducing to much risk itself.
That’s why we started developing CROWSI, a honeypot platform for edge devices, enabling you to make use of the benefits without facing the challenges on your own.
At CROWSI, we believe in the concepts of honeypots as a mean to protect against malicious threat actors in the automotive domain. Out of this, CROWSI is an open-source honeypot platform, tailor made to protect edge device scenarios like connected vehicles.
Therefore CROWSI is developed to be a platform that mimics e.g. vehicle backend APIs that are integrated into the edge device (like the connected ECU of a vehicle) via a reverse proxy application.
With this more special approach of integrating honeypots into the automotive domain, it differentiates from the common integration approaches and follows the target to be very easy in deployment and operation.
With this it requires only very small changes in the product it protects, making it a perfect fit for scenarios where there are not enough resources (like in legacy systems) to implement an Intrusion Detection System, but still proper security insights are needed.
Browse our website to learn about the details or please reach out to us. We would love to hear from you.