Vehicles today contain a lot of technology and software that makes them vulnerable to cybercrime, just like computers and IT networks, which is why many OEMs operate VSOCs – Vehicle Security Operational Centers.
Here in Cymotive, we provide a data analysis service in which a team of cyber security analysts, called ARL – Attack Research Lab, analyzes data collected from the entire fleet to detect anomalies and cyber-attacks, all the way to the resolution of a single vehicle.
Today’s article will discuss the technologies in the vehicle and their differences from the traditional IT field, as well as their challenges that we face on a daily basis.
Overview:
Just before we dig into the guts, let’s do a quick terms overview:
Your car is made up of many ECU’s (Electronic Control Unit) – micro-computer units that are responsible for actions or functions in the vehicle.
For example, as you can see in the picture below, each box represents an ECU. Each ECU has a different responsibility, such as the Airbag ECU – responsible for the Airbag system, the Motor ECU – responsible for the motor’s functionality, the infotainment ECU – responsible for the multimedia screen and its apps such as GNSS (e.g. GPS), music player etc.
The ECUs communicate using the CAN bus protocol (in modern vehicles ethernet communication between ECUs exists too).
“Controller Area Network” is a vehicle bus standard which allows communication between microcontrollers and devices without a host computer. It is a broadcast message-based protocol, designed originally for multiplex electrical wiring within automobiles, yet it can also be used in many other cases.
Each group of ECUs is placed on a different bus, partitioned based on functionalities and relations between the nodes. For one ECU to communicate with another ECU located on a different bus, transmitting the CAN message through a Gateway is required.
The “Gateway” ECU is one of the primary ECUs, which as previously mentioned, has the responsibility of connecting ECUs located on different buses. Messages are transmitted from the source ECU’s bus and then they are routed to the destination ECU’s bus.
As cyber security analysts, there are many different data types to be collected, using sensors, from critical components in the vehicle. A sensor collects information about your network or components and sends it for forward analysis, either locally on the vehicle or remotely to the connected cloud. Different types of sensors include Gateway sensors (for CAN-bus traffic), Infotainment sensors (for multimedia system monitoring), and the Ethernet sensors (for incoming and outgoing traffic).
Safety is Everything
The most important aspect in the automotive industry is safety. For car companies, the top priority is the safety of the vehicle and its passengers.
As a cyber security company in the automotive industry, we must keep this in mind. We must adapt to the many changes in vehicles and technologies, while perfectly suiting ourselves to the vendors and OEMs for vehicle functions to be available at any given time.
This leads to having little fault-tolerance. In the IT world, you can isolate an infected server for further investigation, all while having a backup server to provide the same service during this isolation. In our industry, most of the time you will not have any backup for a car’s critical systems like breaks, engine, and others. Therefore, these systems must not ever fail, whether from a real-life attack or a false-positive action by the defense systems. If something as minor as a headlight malfunction can create a minor risk for a passenger, then one can understand the levels of great safety risks posed from more serious problems and the need to make the vehicle’s systems infallible.
Regulations and Standards
Vehicles are obviously required to follow global standards and regulations, and this includes the products and services cybersecurity companies offer to OEMs and vendors.
This presents a challenge, as we must follow these standards and update ourselves accordingly. It might not always favor the cyber security side, but it also makes sure the industry stays ahead of itself and “keeps a finger on its pulse”.
Detection Challenges
As previously mentioned, the automotive cybersecurity field is different from the “traditional” IT field.
For instance, the vehicle’s CAN bus activity and the ECUs’ behaviors are affected by physical elements outside of its digital space, like the weather. The vehicle has unique features to handle weather scenarios. For example, when it’s raining the wipers will turn on in varying speeds, when it’s foggy the headlight’s mode might change, and uncertain road conditions might lead to the vehicle’s systems (such as ABS) to respond accordingly and affect the CAN bus behavior.
All of these and more affect the ECU’s CAN-bus known and anticipated behavior, as message types, values, and frequencies might change.
This complicates the baselining stage of the detection algorithms, as test vehicles and ECUs may not go through similar conditions like whether and roads, so many behaviors are learned all the time. Not only that, but considering every driver affects our studies, with so many varieties in driving styles\cultures, laws, and surfaces, finding the right baseline does not get any easier.
Another uphill battle is the variety of vendors and ECU models that can be found in a single car (not to mention a fleet). Each vendor has its own architecture, platforms, and implementation of the CAN-bus protocol. Additional research and different handling are required to expand our visibility on the vehicle’s behavior to better understand and differentiate normal activities from malicious ones.
Each sensor has its data type, and each data type requires a specific parser to make the data more readable. This is in order to finally send it to the relevant system to run some queries and look at the data for monitoring.
Same Cup, Different Tea
At the end of the day, the ECUs we get our data from are practically computers. Obviously, they usually run an embedded/Real-Time OS and use the CAN-bus protocol, but they still have many similarities to the traditional IT world.
Ethernet sensor – Using this sensor, we collect and sniff all incoming and outgoing traffic in the vehicle, as some ECUs have IP connections outside of the vehicles and transfer that data using Ethernet onto other ECUs. This is pretty much the same as “classic” IT traffic monitoring, where FW logs are being monitored and analyzed to find unwanted or malicious traffic. In the automotive industry, this is one of the most common attack surfaces.
Infotainment sensor – The in-vehicle multimedia system has many applications and connectivity, both physical (USB) and remote (Bluetooth, Internet etc.), causing it to be an interesting entry point for an attacker. This makes infotainment very similar to IT endpoints, so collecting logs and monitoring processes for suspicious behavior is required.
End Game
Monitoring each vehicle in a fleet creates a massive and diversified amount of data that is made up from system logs, network and CAN-bus traffic, and includes a lot of irrelevant data. Out of all this stray data, our goal is to verify the attacks and publish the findings to the relevant company, and the VSOC teams to respond to the attacks by taking the needed action.
All above mentioned challenges and more make the life of an automotive cyber security analyst a difficult one. But as difficult as it is, it’s also very interesting and satisfying, as there is always a place to grow, learn, and discover a new world.
How Do We Do It?
Cymotive provides a one-of-a-kind End-to-End solution.
CYMOTIVE’s Intrusion Detection System (CIDS) detects and alerts abnormal behavior in the vehicle’s network and components. It also reports critical threats to the Backend in real-time for further analysis, and if needed, for further preemptive measures.
The next part will discuss the IR process and how we handle the data we receive.
