In the past, the greatest risk of a car being “hacked” was theft – someone has to physically break the car and steal it. Today, it is no longer necessary to be physically at the car to hack it, since vehicles have become more and more connected in the last decade. This started with simple techniques like radio or car phones. Nowadays, cars have a permanent connection to the internet. This makes cars a better target from remote hackers around the world. Car manufacturers have already recognized this issue and started to protect their cars against attackers with different security measures.
Unfortunately, these measures are only made to prevent common attacks, so keeping hackers outside the car. Nevertheless, what if a hacker manages to overcome the preventive measures? In this case, a second line of defense must take place, according to the motto: “If I cannot prevent it, I must detect it.” This could be the case, whether it is technically impossible to implement preventive measures or the measures are too expensive related to the costs.
For InCar attack detection, several components are needed: First, there must be a component in the car, a so-called Intrusion Detection System (IDS) or Log-Collector, which can collect all security-relevant logs in the car. Second, a backend component must store and correlate all these logs and publish them to the third component, the Security Operation Center (SOC).
Since a modern car is producing around 25 GB per hour of operative data, it is impossible to send all of this data for analysis to a backend system due to traffic and mobile data costs. Therefore, the IDS must also be able to categorize, compress and correlate the data before sending it to the backend. Further, due to data protection laws like the General Data Protection Regulation (GDPR), all data that is sent from the cars to a backend system must be properly protected since it belongs to the car owner or the car driver.
The second component, which receives the logs from the cars, must fulfill different tasks. In contrast to the “normal” IT world, where all data sources are at one place in a data center, cars are spread all over the world and send their data from many different places while in motion. Second, it must fulfill all data protection laws and other legal requirements in the specific countries regarding anonymization, pseudonymization, data retention etc. Third, it must be able to correlate all logs from single cars with data from backend systems, threat intelligence and CVEs with data from all other cars to find out attacks on a single car or the whole fleet as fast as possible and generation alerts and reports out of it.
In the third component – the SOC – all these data and alerts are monitored by specialists who are doing further investigation, analyzing attacks and setting up countermeasures such as patching the car with new software or bringing it securely to stop.
For Original Equipment Manufacturers (OEMs) and tier 1 suppliers, such a monitoring, attack detection and reaction on their vehicles and components has many benefits:
- Software systems in cars and the misuse of vulnerabilities in these will no longer be a black box. Vulnerabilities can be detected and patched.
- It will be possible to detect fleet attacks all over the world and respond to them quickly.
- Higher safety for passengers and their environment due to the possibility of “emergency shutdowns” of compromised cars.
- Better disaster recovery and faster patching cycles due to better visibility of vulnerabilities and remote updates (OTA) without a repair shop visit.
Nevertheless, there are some challenges left which have to be solved to get this concept going.
First of all, OEMs and suppliers are nowadays unable to get software developed and tested such fast to do a contemporary emergency patching. What makes it even more important to monitor these known vulnerabilities before getting it patched.
Furthermore, it is always a thin line between the data protection of a single person (or driver) and the protection of the general public. As already mentioned before, data from the car belongs to the car owner. Today, it is always necessary to get the approval of the car owner before being allowed to monitor it. But what if the car owner is the attacker? What if he or she wants to make changes to the car software to get more features or more horsepower? He or she is the last one who wants to be monitored.
Finally, think about self-driving or highly automated cars. If nobody in the car is watching the street anymore, who will recognize if something is going wrong? And who will protect uninvolved people if the car is behaving abnormal due to an attack? These questions are still a way off being solved.
Download our latest whitepaper on securing connected cars here.