IT security flaws that enable attackers to access vehicle data and communications or even manipulate safety-relevant vehicle systems may not even be located in the vehicle itself but in the ECU production stage or in an inadequately secured backend. Integrated automotive cyber security must therefore identify and eliminate possible IT security gaps in all connected applications at all levels: in product security, in vehicle production, in the vehicle itself, in the backend, and in the detection and defense of attacks in the vehicle fleet.
Digital products are vulnerable by definition, and vehicles are no exception. In the case of non-connected vehicles, such vulnerabilities can be exploited only locally, so the attacker must have physical access to the vehicle. For example, if the locking system uses an outdated crypto function, it becomes an easy target for thieves. However, the risk is much greater with connected vehicles due to the fact that the attack vectors are more exposed and more easily accessible. Where interfaces are not properly secured, incorrect readings or fake commands can be simulated, such as by wheel sensors that report locking wheels and thus impair the vehicle’s braking performance.
To effectively prevent such attacks, IT security must be integrated into the design and development of every vehicle platform from the outset. IT security analysis, design, and specification, as well as security implementation and testing, are fundamental prerequisites for taking a vehicle platform into large-scale production with a secure IT setup. A secure product development process must be ensured no matter what. Risk-mitigating measures for the vehicle platform itself as well as risk-mitigating development methods (such as secure coding practices) must be considered.
IT security in vehicle production
IT security deficiencies in production can cancel out some of the security measures taken in the design and development of vehicle platforms. That is why it is so important to ensure secure vehicle production throughout the supply chain. Production itself comes with its own challenges: To a not insignificant extent, ancient systems such as Windows 98 or Windows NT 4.0 are still employed, which are no longer supported by the manufacturer. These environments must be isolated from simple attacks, e.g. viruses or Trojans, by means of multilayered security measures. As became apparent only recently, such systems are otherwise an easy target for blackmail Trojans (e.g. WannaCry, Petya). Current generations of this type of malware cause “only” production outages, but future generations may be capable of reaching vehicle systems by going in through production.
IT security in the backend
Modern vehicles communicate with a system in the cloud or in the OEM’s data center. In the simplest case, only statistical data is transmitted; advanced use cases include the transmission of firmware updates and patches via mobile communications (firmware over the air), or the connection to mobile apps, for example to control pre-air-conditioning of the vehicle. And in the not too distant future, autonomous driving commands will be sent to the vehicle – pilot projects for automated valet parking are already providing a taste of what’s to come here.
All these interfaces represent potential points of attack via a vulnerable backend, even if they are correctly implemented in the vehicle. A vulnerability in an interface exposed to the internet may be all it takes for an attacker to take over the backend system and issue commands from there via legitimate channels. For example, a vehicle’s battery could be drained via the air-conditioning system, or a seemingly legitimate driving command could direct the vehicle to a place where it can be easily stolen.
The backend is mostly based on classic enterprise IT technology and can therefore be secured very well with standard security measures. Nonetheless, compliance with appropriate development standards and a secure application architecture are still indispensable. Communication with the vehicle via elegant trust modeling must be designed in such a way as to achieve a certain robustness against security incidents in the backend. For example, end-to-end encryption including cryptographic authentication ensures that only a mobile device approved by the end customer is able to access the vehicle.
Detection and defense of attacks in the fleet
Often, vulnerabilities only become apparent when the vehicle has been on the road for a while. Mitigating the possible far-reaching consequences of such an attack on vehicles in the field will, in the future, be the job of a security operations center (vehicle SOC) in the backend. Not unlike a classic cyber defense center, this is where the vehicles’ intrusion detection system brings together logged anomalies and typical attack signatures, whereupon they are evaluated in security information and event management (SIEM) systems. The SIEM software identifies acute threats in real time using its continuously growing database of attacks and will alert the cyber security team when necessary. In turn, the team can then conduct further forensic investigations, initiate the necessary defensive measures, and roll out appropriate security updates to all vehicles in the fleet. The advantage of this kind of vehicle SOC is that it detects an attack as soon as one vehicle is targeted and triggers the rollout of protection measures for the entire fleet.