If security experts talk with colleagues from the automotive industry about cyber security, it likely ends up in a fascinating discussion about various crypto algorithms, the number of key bits to employ, or the newest hacks from DEF CON. However, in truth, 99 percent of the real problems in daily automotive IT security practice have nothing to do with weaknesses in crypto algorithms, keys that are too short, or the latest DEF CON side-channel hacks. Rather, often enough it’s the very simple gateways that lead to trouble: “secret functions” that are quickly anything but; centrally shared folders full of crypto keys; or external production sites where thousands of activation codes regularly “get lost.”
In other words, rational attackers simply target attacks where they calculate they will meet the least resistance – and, it follows, these weak points are often where you would least expect them An integrated, systematic approach to protection that doesn’t just concentrate on assumed points of attack, but always systematically monitors the “protected object,” helps to avoid such security vulnerabilities. Such an approach normally involves much more than pure technology. In addition to possible technical weaknesses of the overall system – from an individual control unit through to the cloud infrastructure – an integrated approach to protection considers possible points of attack over the product’s entire lifecycle, from its development through to its withdrawal. It also considers the entire security-related organization of the manufacturer and operator, from secure coding guidelines to data protection officers.
In the case of a modern connected vehicle, all-around protection for the vehicle technology typically employs a bottom-up approach. Starting with a particularly well-protected security core (root of trust), normally implemented as a physically secured cryptographic hardware component such as the Secure Hardware Extension (SHE) or a Hardware Security Module (HSM), all further technical protection functions are built on this secure foundation. The cryptographic keys and algorithms stored in such a hardware security component to secure them against unauthorized reading, modification, or deletion can be employed to recognize, via Secure Boot, any manipulation of control unit firmware. Once the integrity of the control unit firmware has been assured via Secure Boot, the software-based security functions in the firmware can be employed for secure onboard communication. Using securely communicating control units and similarly secured network gateways, which reliably separate onboard networks into separate security levels, it is then possible to generate secure vehicle E/E architectures that allow secure communication with other vehicles or other IT infrastructures. Such vehicle IT infrastructures – among them connected traffic management systems, the manufacturer’s cloud services, or mobile payment terminals – must also be secured using classic IT security measures to ensure the IT security of the overall system. In the end, perfect vehicle security is not much use if, for instance, vehicle keys are stored in plain text in the backend and all it takes to steal them is a simple attack on the server.
Lasting protection required
Unfortunately, a strategy that is complete but purely technical often won’t provide lasting security if the measures to secure the vehicle IT stop when production starts. And this is where a major difference between IT security and IT safety – which is at least equally important – comes into play. While the boundary conditions in IT safety are essentially based on laws of nature and statistical predictions, which remain largely valid even after the start of production, assumptions and boundary conditions in IT security may fundamentally change from one day to the next. The discovery of a new, particularly efficient method of attack, for example, can cause what was a state-of-the-art security mechanism to suddenly provide only inadequate protection. In IT security research, such critical penetrations have occurred on multiple occasions, for instance the current successful collision attacks on the SHA1 hash function, and cannot be ruled out in the future, for instance if quantum computers render encryptions insecure. Consequently, even after the start of production and until decommissioning of the component or the vehicles, IT security solutions need to be monitored for potential newly discovered vulnerabilities and, if required, subsequently adapted. This means, for instance, that important security solutions must be designed from the outset with subsequent modifications and extensions in mind – for instance by employing editable memory to store central security parameters and functions, like HSMs with an option to update the firmware; by not completely exhausting the available IT resources from the beginning; and by deciding in advance to provide free storage areas and implement effective update mechanisms such as software over the air. But this also makes it necessary to continuously monitor the ever-changing progress of the security landscape, so as to be well-prepared and ready to respond to critical developments.
Setting up a security organization
To effectively implement and reliably operate all the available protective measures, it is crucial to set up an effective security organization. This covers all necessary organizational components such as security processes, security policies, security roles, and security officers. These organizational security measures, implemented across the whole company, encompass the entire product lifecycle and a vehicle’s overall IT system.
For almost all vehicle manufacturers and tier 1 suppliers, the starting point is typically a dedicated vehicle security department or a vehicle security competence and governance center (VSC). As shown in figure 4, the VSC, via the chief vehicle security officer (CVSO), ideally reports directly and exclusively to senior management. This gives the VSC and the vehicle security officers (VSO) posted or designated to all relevant departments by the VSC the necessary powers to effectively establish and enforce company-wide vehicle security regulations. The VSOs of individual OEM departments work closely in the process with the VSC’s dedicated security groups, which among other things
- support the development process with security consulting, security software and hardware components, specific security developments, and security tests;
- ensure continuous security monitoring of the IT security landscape, to provide a security incident response for advice and assistance in emergencies;
- adapt and roll out the vehicle security regulations for new circumstances;
- provide occupational training and continuing professional development for employees in vehicle security; and
- continue to develop cross-vendor vehicle security issues in relevant advocacy groups and standardization bodies.
In addition to the full-time staff of the vehicle security department, a powerful security organization also comprises numerous mixed as well as external departments and projects. These can be set up on a temporary basis to develop new safety mechanisms, or they can develop and operate shared functions and services together with other departments. “Vehicle security managed services,” as they are known, in which the central IT department of the automotive manufacturer and the VSC jointly operate a secure cloud backend, is one example of such a mixed department. In this scenario the corporate IT department, or even an external provider, ensures the necessary performance and availability of the cloud solution, while the security department provides the required protection and manages access rights.
Only once all organizational security measures and the complete protection of the vehicle E/E architecture (including all IT infrastructure services over all lifecycles) have been integrated throughout a company can a sustainable all-around protection for modern connected vehicles be guaranteed. Establishing and operating this entails considerable expenditure and perseverance, but it is the best way of preventing vulnerabilities in a company’s vehicle IT first coming to light at security events such as DEF CON