Practical solutions for a secure automotive software development process according to ISO / SAE 21434


Find out which cybersecurity activities are critical to building secure automotive software systems using ISO / SAE 21434 as a guide.

The final draft of the ISO / SAE 21434 International Standard (FDIS) “Road vehicles – cybersecurity engineering” was published in May this year, with the final version due to be published a few months later. This standard specifies various engineering requirements and recommendations for managing cybersecurity risks in the concept, product development, production, operation, maintenance and decommissioning of electrical and electronic (E / E) systems. road vehicles, including their components and interfaces. It should be noted that during ISO / SAE FDIS 21434 Provides a more holistic view of cybersecurity, including descriptions of multiple cybersecurity requirements, activities, and work products at the organizational and project levels, this article focuses on practical cybersecurity solutions for a secure software development process. Specifically, the focus is on Application Security Testing (AppSec) solutions to address the factors that lead to weaknesses and vulnerabilities in automotive system software. According to a auto safety investigation, these factors include coding errors, lack of testing, and the use of vulnerable open source software (OSS) components.

Solutions to establish a secure software development process

There are a variety of solutions that automotive organizations can use during the software development lifecycle to help identify and remediate vulnerabilities. Since automotive organizations often have limited security resources, we will focus on automated AppSec solutions rather than manual activities. Figure 1 provides an overview of how these solutions are aligned with the V-model and the relevant clauses of ISO / SAE FDIS 21434.

solutions aligned with the V-model and relevant clauses of ISO / SAE FDIS 21434 |  Synopsis
Figure 1: Solutions aligned with the V-model and relevant clauses of ISO / SAE FDIS 21434

Integration and verification activities

Regarding coding, the requirement [RQ-10-09] in ISO / SAE FDIS 21434 states that integration and verification activities should verify that the implementation and integration of components meet defined cybersecurity specifications. Requirement [RQ-10-10] specifies that static analysis can be used as a verification activity for requirements [RQ-10-09]. In addition, the requirement [RQ-10-05] states that coding guidelines should be used when cybersecurity is not sufficiently considered by the programming language itself. Automated static analysis tools, such as Coverity®, can analyze source code without running software, which means manual activities to define test cases can be avoided. These tools can help detect buffer overflows, resource leaks, memory corruption, and other faults in code. Additionally, static analysis tools can check the software against relevant coding guidelines, for example, MISRA C / C ++, AUTOSAR C ++, and CERT C / C ++.

Component testing

Regarding testing, the recommendation [RC-10-12] indicates that component tests should be performed to confirm that weaknesses and unidentified vulnerabilities remaining in the component are minimized. In addition, the requirement [RQ-11-01] stipulate that penetration testing can be used as a validation activity to demonstrate the relevance and achievement of cybersecurity objectives. There are several testing methods that can be applied to perform this type of testing, including vulnerability scanning, fuzz test, and penetration testing.

Vulnerability analysis uses knowledge of known vulnerabilities or attack patterns to identify vulnerabilities in the target system. For example, software composition analysis tools, such as Black Duck®, can detect known vulnerabilities of OSS components of the target system. This automated source code or binaries analysis identifies open source components, their respective versions, and associated known vulnerabilities.

While vulnerability scanning tools typically use a database of known vulnerabilities or attack patterns, fuzz testing goes a step further to identify unknown vulnerabilities by generating a malformed entry that is then provided to the target system. Fuzz testing tools, such as Defensics®, can identify unknown vulnerabilities in various protocol implementations including CAN, CAN-FD, Automotive Ethernet, Wi-Fi, and Bluetooth, as well as higher layer protocols such as ISO- TP, UDS, DoIP, gPTP, IP, TCP, HFP, A2DP, etc.

Vulnerability analysis and fuzz testing can be performed using automated tools. Conversely, penetration testing usually involves manual activities in an attempt to break certain security objectives of the target system.

Companies should also continuously monitor new threats and vulnerabilities, both during development and after product release. Requirement [RQ-08-01] indicates that internal and external sources can be monitored to collect cybersecurity information. Software composition analysis tools such as Black Duck can provide alerts on newly identified vulnerabilities in OSS components as part of ongoing cybersecurity activities.

Get the most from your tools with automation

It is imperative to recognize that these tools by themselves are not as useful as automating them as part of the Continuous integration (CI) pipeline in the software development process. Automotive companies should establish appropriate processes for static analysis, vulnerability analysis, fuzz testing, and cybersecurity monitoring, and consider approaches to deploy automated AppSec tools. This includes determining which tools to use, what to test, what test environments are required, and how often the tests should be performed. Additionally, to ensure the efficiency and effectiveness of the tools, automotive organizations should consider integrating application security testing tools into the CI pipeline with other tools, including source code management systems, automation servers, build systems, and bug tracking systems.

Automotive organizations can also consider automation platforms, such as Code Dx, to run application security tools, correlate results and help prioritize vulnerabilities, as well as provide centralized risk visibility into what has been tested, when has been tested, what has been found and which has been corrected.

Create secure automotive software today using ISO / SAE 21434

When choosing solutions for a secure automotive software development process following ISO / SAE 21434, organizations must be dynamic. The integration of cybersecurity processes often requires a cultural shift. Emphasis should also be placed on automation using tools to effectively and efficiently integrate cybersecurity activities into the development process.

webinar: Developing secure automotive software in the age of ISO / SAE 21434 |  Synopsis


Gordon K. Morehouse