When talking about development processes for cars, most people would instantly connect all the safety features, which are built into a car. Safety critical systems, such as brakes, seat belts, airbags and Radio Detection and Ranging (RADAR) or Light Detection and Ranging (LIDAR) technologies are common and partly also mandatory in every car. Technology, which is not common and mandatory for cars, are IT security systems. However, modern and connected vehicles are increasingly becoming “rolling IT systems” which also needs to be protected with IT security measures.
Attack points in connected cars are manifold. Hackers could attack the vehicle bus, or download (in-car) apps or backend services. They can try to manipulate Engine Control Unit (ECU) data, exploit (open source) software vulnerabilities, sniff user data or install malicious firmware updates. Furthermore, with SIM cards a part of every connected vehicle, attackers could do these attacks remotely and in every step of a car's lifecycle.
Most Original Equipment Manufacturers (OEMs) already have a mature lifecycle process for their cars, mainly due to different (safety related) regulations. This process includes all steps of a car’s life, from the specification until decommissioning, as shown in the process graphic below.
Unfortunately, security is not part of any of these process steps. Therefore, additional security elements should be included into every step of the lifecycle. The following overview will show some elements, which should be implemented to improve security (but are not limited to):
An IT security threat and risk analysis should be part of every specification and lead into a set of security measures. These measures could flow into a security concept, which has to be part of every requirements catalogue, which is sent to suppliers. What's more, every supplier should also commit to general, mandatory security guidelines for the development, testing and production of a component (e.g. coding guidelines and security standards like ISO 27001 etc.)
During development, OEMs should regularly check for vulnerabilities (e.g. CVEs and CWEs) which could affect the security and therefore the development of a component. Furthermore, security standards for design and coding should be established, as mentioned for the suppliers before.
Security tests should be part of every testing cycle and, at the end of the development, part of all functional and non-functional tests. Security tests could include penetration tests, integration tests but also security tests, which are mandatory for the new upcoming type approval (with new UN ECE cybersecurity guideline, respective ISO 21434) to get the needed security certifications.
During the car’s production, security relevant components (such as HSMs or SIM-modules) and security relevant material (such as keys or certificates) should be implemented in a secure environment to eliminate the possibility of keys or certificates being stolen. Also, crypto material should be handled only by the OEM to avoid security risk such as devices with dummy keys being shipped around the world. Also, suppliers do not need to know the secret key material.
For operations, there are two main tasks. First, keeping the car and its software up-to-date, so the car's configuration and crypto material are updated through measures like over-the-air-updates (OTA updates) and proper key management. Second, cars should be monitored to prevent or respond to attacks as described in an earlier post (see: How to detect and respond to attacks on vehicles).
When the car is decommissioned, all (security relevant) components should be deactivated and all keys and certificates should be revoked to prevent attackers to use old car parts from the scrapyard for reverse engineering or getting access to the car or its backend systems. The “digital twin” of a car in the OEM backend should also be deleted to avoid the delivery of software or keys and certificates to a car, which does not exist anymore.
If all these security elements are implemented, the lifecycle process should before could look like the following example:
Finally, if there is a person accountable for every process step, which is responsible for every element in his or her step and not a dedicated department for safety and one for security, it should be easier to bring both together.