What is ISO 21434? Compliance Tips for Automotive Software Developers
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. To help enforce this, automotive product developers, OEMs, and their suppliers will need to comply with ISO 21434.
Here, we provide an overview of what is expected in ISO 21434, and tips for automotive software development teams.
What Is ISO 21434?
ISO 21434 “Road vehicles — cybersecurity engineering” is an automotive standard currently under development. It focuses on the cybersecurity risk in road vehicle electronic systems.
ISO 21434 Overview
ISO 21434 will cover all stages of a vehicle's lifecycle — from design through to decommissioning by the application of cybersecurity engineering. This will apply to all electronic systems, components, and software in the vehicle, plus any external connectivity.
What’s more, ISO 21434 will provide developers with a comprehensive approach to implementing security safeguards that spans the entire supplier chain.
Why Is ISO 21434 Is 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 the 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 ISO 21434 is to provide a structured process to ensure that cybersecurity considerations are incorporated into automotive products throughout their lifetime.
The standard will require 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 is intended that organizations will encourage a cybersecurity culture so that everything is designed with security considerations from the start.
ISO 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. Which 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.
Why Are MISRA C:2012 Revision 1 and CERT C Guidelines Recommended?
It is well known that programming languages such as C and C++ contain features that can result in critical or unspecified behavior. In a secure system, this is unacceptable and prohibits the use of such language constructs with a language subset that will 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 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).
ISO 21434 Tools
To effectively identify vulnerabilities and weaknesses as well as to enforce the recommended coding guidelines (such as MISRA and CERT), 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 the 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 ensuring 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 to ISO 21434 simpler, and a static analyzer like Helix QAC can helpto 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 SGS-TÜV-SAAR, 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 trial to learn more.