The wave of innovation in automotive industry is bringing more safety, smarter driving assistance and even more connectivity, launching the vehicle in the IoT (Internet of Things) Era, where the vehicle is the new ‘thing’, a connected thing even more efficient than ever before, but also, introducing more cyber risks as inexorable consequence.
We´ve seen a couple of initiatives in automotive industry to reach higher security and cybersecurity levels in its products in order to cover all this driving automation and connectivity in a secure way. This kind of industry is renowned by its inertia to move forward to big changes, but fortunately, with a good market competition, the companies must speed this change up in its traditional processes. or at least, try to do it, otherwise they will be left behind the scenes, since safety and security is crucial for its brands images.
One big step of OEMS and Tiers1´s to it, was the creation of AUTO ISAC community in 2014, where all associated partners can share and analyze intelligence about cybersecurity risks to the vehicle, and collectively bring values and capabilities in cybersecurity across the industry.
The resulting of this effort and others around the globe was the launching of standards and guidelines in the area, one great example was SAE J3061, published in 2016. This standard comprises fundamentally in a framework for a lifecycle process to incorporate cyber security into automotive cyber-physical systems, highlighting the importance of cyber security throughout product development cycle, from Concept and Design to product´s end of life. It´s possible to say as ISO26262 means for critical safety systems as J3061 means for automotive cyber physical protection, they are complementary to meet safety and security into vehicle development systems.
There are 3 (three) major phases of guiding principles; Concept and Design, Development and Validation, Incident Response and Product ´s end of life. In this article, some steps of some of the stages will be presented with some practical examples, in this way, the reader could materialize some concepts as well as realize the complexity to adopt practices in overall development phases.
One of the basics steps from the first phase starts from security assessment, the main idea of this task is to determine the assets to be protected, identifying physical and trust boundaries of the system, considering: authenticity, integrity, confidentiality and so on, as well as determine the security level of possible threats of each asset considering attack probability and severity. This evaluation process in concept phase is called TARA (Threat Analysis and Risk assessment), the resulting of this process is the potential threats and assets rated with its associated risks.
| Asset | Attack scenario | Threat | Effect | Probability | Severity | Risks |
| Infotainment Software Integrity | Modifying the firmware in Infotainment ECU | Tampering | Take control of system ECU operations | 7 (1+2+2+2) | 4 | Medium |
| Exploit known OS vulnerabilities | Trojan or rootkit installation | Take control of system ECU operations/Acess data | 9 (2+1+3+3) | 4 | High | |
| Remote Control Functions | Man-in-the-middle | Password eavesdropping for remote connection | Hijack established connection | 8 (1+1+3+3) | 2 | Medium |
| Brute Force | Password revealing | Normal Operation disturbance | 9 (2+1+3+3) | 4 | High |
Usually the frameworks and guidelines like J3061, provides suggestions for methods and techniques for TARA, is possible to highlight OCTAVE, ETSI and E-safety Vehicle Intrusion Protected Applications EVITA. Besides its recommendations in some standards, exists other approaches which may be used, each method have its own probability and severity classes, as well as risk matrix to support TARA rating.
After the assessment, the idea is to keep tracking the assets into Concept and Design, analogous for traditional functional requirements in traditional V-Cycle, the requirements are the main output, but with security as a goal. For each system and assets mapped in previous phase, is possible to set protection goals and specific requirements to cover and minimize possible systems flaws, which could compromise the assets and for consequences compromises the vehicle or even the car driver in somehow. This process starts with what we called as Security by Design, it means the product and systems is designed considering security from its birth.
Follow some examples of security Goals and system requirements:
- Asset: ECU Software
- Goal: Ensure a secure software
Requirements that may be used as countermeasures:
- Secure boot for the OS (Operation system):ECU (Electronic Control unit) hardware shall be based security with a secure environment like SHE – Secure Hardware extension on chip, in this case, is required a boot in a specific ECU which can assure in a secure environment, shifting the control of cryptographic keys from a software mechanism to a hardware one, therefore, providing hardware protection of these keys.
- Asset: Vehicle Network
- Goal: Ensure network availability
Requirements that may be used as countermeasures:
- Isolate and separate the vehicle networks: In order to avoid the vehicle network compromising due and infotainment ECU hacking for example, secure gateways with firewalls may be used, allowing only authorized messages ID from Ethernet from telematics domain being gated to Vehicle Safety CAN network, also it could allow only authorized critical diagnostic services with authentication and so on.
- Apply IDS (Intrusion Detection System) on Vehicle network: In modern vehicle architectures with central gateways for example, may be possible to install IDS systems on it, in order to monitoring Vehicle CAN network behavior and detect possible anomalies and CAN network compromising due an ECU affected by malicious code. The current Market IDS vehicle systems used AI (artificial intelligence) / Machine Learning algorithms to detect it.
- Asset: Remote Software updating (SOTA)
- Goal: Ensure authenticity with right partner
Requirements that may be used as countermeasures:
- Use certificates, asymmetric encryption (private/public key) and challenges protocols for Software updating partner authentication.
Since Concept and Design phase has been finished and product/system requirements completed, it´s time for security implementation itself, Finally, is possible to say it’s time for development and coding the product, the main goal is avoid design and code errors in implementation.
For Software development, some approaches may be used in order to minimize the risk of non-secure implementation, usually is possible to find general recommendations in specific security standards like CERT C, and for Hardware security, SAE J3101 can be a good source for consulting.
Follow some recommendations examples following standards and guidelines:
- Recommendation of hardened OS with secure partitioning, avoiding embedded Linux for example due its complexity, rapid change and security gaps like NULL function pointer, which can make easier for malicious code injection.
- The usage of rigorous static code analysis: tools such as Polyspace, Coverity and Klocwork covers many security checks in order to avoid common programming mistakes like memory access outbound areas, non-initialized variables, buffers overflows, zero division etc.
- Deployment of a secure boot strategy verifying with core root of trust ex: pre burned cryptographic Keys.
Despite of all this kind of recommendations, the most important thing is the engagement of development team on those practices, as well as a good and specialized training and certifications, to be succeed on this task, the people is the key factor.
After product released by development team, it’s time for product validation, the idea in this phase is to abuse in applying different tools for cyber security testing and hardening, in this step is really necessary to have a “red team” specialized in testing which didn´t participate in product development. The most usual test tools used are:
- Static code analyzer: Tool used to analyze source code before a program is run, usually checking coding rules, security standards, code metrics, and find bugs related to it, some examples of errors covered by this kind of tool are buffer overflows, division by zero, out of bound arrays index, non-initializer punters and so on.
- Dynamic Code Analyzer: Relies on studying how the code behaves during execution, being able to find security issues caused by the code’s interaction with other system components, to be successful on dynamic analyzes is necessary to cover all system inputs testing for errors stimulation, for this reason dynamic testing is so far more complex compared with static one.
- Network Traffic Analyzer: It is used for network troubleshooting, analysis, software and communications protocol development, with this tool is possible to act as a sniffer in automotive Wi-Fi system for example and discover uncovered functionalities and backdoors.
- Exploit tester: Testing tools which exploits system flaws with a large database of it, for example some Linux distribution have known flaws in some specific port, so if this port is opened on Infotainment system for example, it can be exploited and allow root access.
- Fuzz Tester: Is a dynamic test which consists in High volumes of random or malformed data in a system, for automotive, it can be used to stress CAN network data and observe the resulting.
There are a lot of more security test tools to be used in validation, like encryption crackers and vulnerability scanners, but again, the point is to have a strong security validation team able to be trained and updated with most recent market tools.
The final step of Development and Validation is the system security certification, the OEMs used to hire external companies to perform penetration tests on their systems and vehicles, in this way is assured a security testing with a different mindset, closer to a real hacker mind. The hiring form of this job can be done in three approaches: Black, Grey or White Box approach.
- Black Box: This approach is the closest to an real external attack, as no information from the client is needed by the test analyst therefore, all and any type of information for performing a Black Box test is acquired through specific hacking techniques on the target’s available features and services. ex: Infotainment bench test given to supplier or even the entire vehicle and nothing more.
- White Box: All systems that are included in the scope of the intrusion test, and other access information to them, are provided so that, extensive and more comprehensive tests can be carried out, OEM usually delivery the source code files to Pentest supplier in this approach.
- Grey Box: This approach is a mix between the black and white, some system information is given to the test analyst in additional to the component itself, like internal technical specifications, software image files and so on.
There is no best penetrating test scope, the most suitable can vary for each project, due its timing and complexity, in OEMs the components (ECUs) and systems testing can have a different approach from entire Vehicle testing, but there is no rule for it.
After this audition/certification, the product can be launched to the market, from this point the automaker has to monitor its products on the roads, this phase is the Incident and product end of life, for this task, a SOC (Security operation center) with an incident response team may be establish, if their vehicles are equipped with intrusion detection systems for example, it may be integrated with it, assuring rapid incident responses and analysis.
Other program that some OEMs have been used after vehicles launches, is the adoption of Bug Bounty programs, where the public in general can be rewarded by finding vehicles security vulnerabilities, of course with a confidentiality agreement, in this way, the companies can actuate in advance for possible future exploitation. Tesla, GM and FCA has used this approach in last few years.
Security needs to be an integrated part of product life cycle, from its birth to death, assure security throughout all product lifecycle is a very complex and hard way, but extremely necessary to protect companies’ images and its receipts against hacking. Is no doubt that is very hard for this companies to achieve this state of security engineering, but somehow, they should get used to it, laws regulating cybersecurity in automotive industry have emerged in recent times, certainly it is a path with no return.
Author:
Electro electronic engineer with Embedded Systems specialization, 10 years of experience based on automotive and semiconductor industry, Head of Cybersecurity strategy in LATAM market for 2 years in OEM, working with secure software development process and methods, security systems and product development. Currently working as an automotive software development lead.
Published in Telematics Wire
