What Is ISO 21434? ISO/SAE 21434 Compliance Tips for Automotive Software Developers
ISO 21434 helps automotive product developers, OEMs, and their suppliers ensure the security of their vehicles. This is critical as vehicles become more connected and with the increase in autonomous cars, it is important that automotive software is designed and implemented with security in mind.
Here, we provide an overview of what is ISO 21434 and tips for automotive embedded software development teams.
Read along or jump ahead to the section that interests you the most:
➡️ Free ISO 26262 Compliance white paper
Back to topWhat Is ISO 21434?
Back to topISO 21434 “Road vehicles — cybersecurity engineering” is an automotive standard. It focuses on the cybersecurity risk in road vehicle electronic systems.
ISO/SAE 21434 Overview
ISO 21434 covers all stages of a vehicle's lifecycle — from design through decommissioning, by the application of cybersecurity engineering. This applies to all electronic systems, components, and software in the vehicle, plus any external connectivity.
What’s more, the standard provides developers with a comprehensive approach to implementing security safeguards that span the entire supplier chain.
Why Is ISO 21434 Important?
With the increase in connectivity in vehicles — such as Wi-Fi and Bluetooth — and the development of autonomous cars, the risks of cyberattack and subsequent damage also increase. Current safety-critical standards are not sufficient to cover this type of risk and therefore new guidelines and standards need to be established.
The intent behind the standard is to provide a structured process to ensure that cybersecurity considerations are incorporated into automotive products throughout their lifetime.
The standard requires automotive manufacturers and suppliers to demonstrate due diligence in the implementation of cybersecurity engineering and that cybersecurity management is applied throughout the supply chain to support it.
It intends that organizations will encourage a cybersecurity culture so that everything is designed with security considerations from the start.
📕 Related Resource: Check out the SAST tutorial for additional resources.
Back to topISO 21434 Compliance
ISO/SAE 21434 has specific requirements for software development including analysis to check for inherent weaknesses and the overall consistency, correctness, and completeness with respect to cybersecurity requirements.
Cybersecurity should be at the forefront of all design decisions including the selection of the programming language to be used for software development.
There are several criteria to be considered when selecting a programming language, including:
- Secure design and coding techniques.
- Unambiguous syntax and semantic definitions.
However, some of these criteria may not be sufficiently addressed in the selected language. This is why there are several ways of addressing these language deficiencies, including:
- Use of language subsets.
- Enforcement of strong typing.
- Use of defensive implementation techniques.
It is recommended to use coding guidelines to address the deficiencies of the chosen language.
▶️ Related On-Demand Webinar: Learn How to Effectively Apply a Coding Standard
Back to topWhy Are MISRA C:2012 Revision 1 and CERT C Guidelines Recommended for ISO 21434?
It is well known that programming languages such as C and C++ contain features that can result in critical or unspecific behavior. In a secure system, this is unacceptable. Prohibiting the use of such language constructs, with a language subset, may allow the adoption of the language in a system with cybersecurity requirements.
C continues to be the most common language used in automotive software. The MISRA C:2012 revision 1 and CERT C guidelines are particularly recommended in ISO/SAE 21434 for any projects using the C language.
Creating a language subset is the core of MISRA C:2012 and CERT C guidelines. MISRA C:2012 revision 1 states: “The MISRA C Guidelines define a subset of the C language”.
Both guidelines achieve this by preventing the use of functionality that may cause critical or unspecified behavior.
For example, MISRA C:2012 revision 1 Rule 21.5 prevents the use of the functions in <signal.h> and Rule 21.21 the use of the function ‘system’.
Similarly, CERT C Rule 11 Signals (SIG), prevents specific signal handlers and ENV33-C doesn't call system().
Strong typing ensures that there is an understanding of the language data types and thus prevents certain classes of programming errors. Using coding guidelines that have strong typing ensures correctness and consistency.
MISRA C:2012 Revision 1 has the essential type model which is specifically to enforce strong typing while CERT C implicitly addresses strong typing in individual rules such as INT32-C which guards against signed integer overflow.
Defensive implementation techniques allow the software to continue to function even under unforeseen circumstances. It requires thought about “what might happen”. There needs to be, for example, consideration of possible tainted data and understanding of the order of evaluation of arithmetic functions. Above all the code needs to be simple to understand.
All defensive implementation techniques should start with the use of recognized coding guidelines. Both MISRA C:2012 Revision 1 and CERT C achieve this by identifying critical and unspecified language behavior and thus making the resulting code more reliable, less prone to errors, and easier to maintain.
CERT C is a whole language security standard, so it is designed to identify those vulnerabilities that are particular to cybersecurity. While MISRA C:2012 Revision 1 defines a language subset applicable to both safety and security and has rules specifically for defensive implementation techniques that include switch statements (Rules 16.2 and 16.3) and resource management (Rules 22.x).
Back to topWhat Are ISO 21434 Tools?
To effectively identify vulnerabilities and weaknesses as well as to enforce the recommended coding guidelines (such as MISRA and CERT C), you should use an industry standardized tool — specifically a static code analyzer.
Static code analysis tools — such as Helix QAC — can both verify compliance with the coding guidelines and provide evidence of that compliance. This will provide overall consistency, correctness, and completeness with respect to cybersecurity requirements.
Software tools are an important part of the development of any vehicle and they must be managed with respect to the impact on the cybersecurity of the product. This includes verification tools like static analyzers.
It is necessary to ensure that any tool used in the development process does not adversely affect cybersecurity and this includes managing the tool to ensure that access is controlled and that it is used correctly. Evidence is required to show how the tool is managed which will include authenticated results.
The right tools will make compliance simpler, and a static analyzer like Helix QAC can help to meet development guidelines for the production of safe, secure, and reliable software.
With full compliance to both MISRA C:2012 and CERT C guidelines, Helix QAC, which has been previously certified for use for safety-critical systems by TÜV-SÜD, will make it easier to verify that your software is free from common code security vulnerabilities.
In addition, by using a static code analyzer — like Helix QAC — you are able to accelerate compliance by:
- Enforcing coding standards and detecting rule violations.
- Detecting compliance issues earlier in development.
- Accelerating code reviews and manual testing efforts.
- Reporting on compliance over time and across product versions.
See how Helix QAC will help you accelerate compliance, request a free trial.
Back to top