Security Innovation explains ways to create an impenetrable connected car
The car maker’s own security team will have to develop a set of security requirements that are part of the general specifications to which their suppliers will be required to comply
Gene Carter, Director of Product Management | Security Innovation
There is growing public realization of potential cybersecurity vulnerabilities in cars. And now the US Government has started to treat the potential hazard seriously, with Senator Ed Markey issuing a well-researched report in February that strongly criticized the cybersecurity preparedness of automakers. Bipartisan leaders of the House Energy and Commerce Committee followed up the Markey report by writing to CEOs of seventeen car manufacturers requesting information about their plans to address cybersecurity challenges. The answers to these questions from the car makers may never be publicly available, but it is highly probable that the responses won’t instill great confidence in the House Committee.
But what answers could the auto manufacturers give that would be satisfactory to the politicians and car owners? Security Innovation has spent the past 12 years advising Fortune 500 companies on how to secure their products, applications, websites and automobiles. Many of the cyber security lessons learned in other industries, can be applied to automobiles. This legacy knowledge can help automakers move along the security maturity curve more rapidly. There is no quick fix in security and there certainly is no single “magic bullet” solution that will protect a car. The best solution is to build security into every step of their development process. But how?
First, the automakers need a secure Software Development Lifecycle to guide them. A good recommendation is to start with the Microsoft SDL and modify it to meet the particular needs of automotive OEMs. Alternatively, they could use the Automotive SDL, a new set of guidance promoted by Secure By Design (SBD), an English automotive consultancy.
The automakers should then require technical security training for all of their developers, architects, engineers and quality assurance teams. Most of which will have received little to no formal security training during college or their professional careers. Without this specialized training it is unreasonable to expect engineering teams to be able to implement best practices in security. Each and every group needs to be trained because a system with secure application software is still vulnerable if the underlying architecture is rife with vulnerabilities.
Next, the automakers need to develop comprehensive threat models to anticipate the many ways that hackers might misuse and abuse the system. Threat modeling identifies possible gaps in the architecture and helps to improve the overall security of a vehicle. As has been shown countless times in the IT industry, these potential threats are significantly easier and cheaper to mitigate at the initial stages of a design than during system test and validation stages. The car makers have only recently recognized that cybersecurity threats can target privacy, credit card and/or identity theft, mischief and safety. A good threat model comprises these four factors:
- Entry points – How an attacker may gain access to the vehicle systems. Examples could include Wi-Fi, Bluetooth, GPS receiver, OBD-II port, CD-player, keyless entry/RFID, USB port, etc.
- Access methods – The means an attacker may use to access the entry points. Examples of access methods are spoofing a sensor input, injecting malware via a CD or USB stick, breaking weak encryption on an app that talks to the OBD-II port, etc.
- Types – The type of attack that may be launched. Examples of attacks that hackers could use are Denial of Service (DOS), Ransomware, data-logging, man-in-the-middle, etc.
- Outcomes – The potential effects of the attack. This could range from nuisance items like horns honking in the middle of the night, to privacy issues like tracking or cyberstalking, financial impacts such as credit card information or the car itself being stolen, or safety issues including brakes or steering being disabled.
After the threats are documented, car makers need to classify and rank them. A widely used method is the DREAD model, co-created by Security Innovation’s CTO Jason Taylor during his tenure at Microsoft and used globally to qualify risk. DREAD stands for:
Damage – how bad would an attack be?
Reproducibility – how easy is it to reproduce the attack?
Exploitability – how much work is it to launch the attack?
Affected users – how many people will be impacted?
Discoverability – how easy is it to discover the threat?
Using these factors, an organization can properly prioritize and address the vulnerabilities. Merely looking at damage alone, for example, may not be the best move if the vulnerability is hard to discover and exploit.
One of the outcomes of this threat modelling may be that the engineering team decides the existing architecture of a car is not sufficient to protect against cyber-attacks. The car makers may be forced to dramatically reimagine the overall design of the car, possibly replacing technologies that have worked well for them over the years. For example, they may determine that the Controller Area Network (CAN) bus is insufficient to secure the car’s internal network and needs to be replaced by Automotive Ethernet. They may decide that a secure element, such as a Trusted Platform Module (TPM) is required to ensure safe software booting and cryptographic key storage. Or they could determine the network needs better segmentation and isolation between safety and non-safety applications. Whatever the conclusion, a good threat modeling process will help uncover or highlight the security gaps.
Only when the car maker has carefully designed and reviewed the security architecture, completed the threat modeling and trained their developers, are they then ready to start writing secure code. But the car makers can’t just trust that the developers are really writing secure code. Performing code security scans (including SAST, DAST and IAST) whenever new code is checked in must become an industry standard best practice that will result in early detection and correction of vulnerabilities. There are several source code scanners with a good example being the Klocwork scanning tool which is popular with auto makers. Combining the results of these scanners with regular code reviews makes the software more resilient and reinforces the importance of security within the software development team.
But of course, most of an automobile’s software is not written by the car makers themselves. We can’t ignore the role of Tier 1 suppliers, where the majority of the car’s electronics are designed and software produced. The car maker’s own security team will have to develop a set of security requirements that are part of the general specifications to which their suppliers will be required to comply. Cyber security reviews should incorporated into the standard design review process and the entire supply chain should be required to implement a secure SDL as part of their development process. Ideally, the automakers should implement a recognition and reward program for suppliers demonstrate cyber security excellence. The more pressure the car makers put on their suppliers to incorporate and embrace a secure automotive SDL, the better the security profile of the car will be in the end. Without this pressure the Tier 1’s are unlikely to adopt these measures on their own. Margins for automotive suppliers are already notoriously thin. The additional costs for security are unlikely to be incurred by Tier 1’s unless specifically mandated by either the car makers or governments.
Finally, the cars need to have a way to detect that a vulnerability has occurred and then a way for the software and/or hardware to be updated. One often sees the phrase “there have been no known ‘real-life’ remote cyber-attacks on cars.” This is most likely true … for now …, but this might have more to do with the inability to detect an attack rather than the lack of any actual attacks. Few, if any, vehicles have intrusion detection systems and data loggers to actually know if an attack occurs. But as connectivity to the internet continues to increase and the threat surface expands, the additional expense of detection and logging hardware is becoming a requirement. Argus Security’s Intrusion Prevention System (IPS) is a good example of an automotive focused tool that is designed to detect and stop many types of attacks.
Improving the security of an automobile is a difficult task that requires the car makers and their suppliers to adopt security throughout their development process. There is a temptation to go for the “quick-fix”, which usually leads to spending a lot of money on a tool that only addresses a small portion of the problem. Like many things in life, good security requires hard work, discipline and commitment. And unfortunately, even doing everything correctly does not guarantee that a hacker cannot gain access to the automobile, given enough time, money and persistence. So in the end, one cannot feasibly create an impenetrable car. The goal of good security is to make it so difficult to breach and to limit the gains from that breach that the hacker turns his attention to easier targets.
Stay Tuned with Telematics Wire for more!
