To give it it’s full title, ISO/SAE 21434: 2021 “Road vehicles — Cybersecurity engineering”, was finally published in August 2021.
ISO 21434 compliance defines a set of guidelines and requirements for the design and development of ‘secure’ road vehicles, including for the assessment of security risks, the implementation of security controls, and the management of security incidents.
It is intended to help manufacturers ensure that their vehicles are secure against cyber-attacks and other forms of malicious activity, and to promote confidence in the safety and security of road vehicles.
Safety has long been a concern of automotive software development teams – since an uncontrollable automotive vehicle would very clearly have a potentially dangerous impact on other road users (and other bystanders).
The well-known Functional Safety (FuSa) standard for automotive vehicles – ISO 26262 – has been widely adopted since its original release in 2011.
Having an automotive system that is safe, and that behaves as intended and documented, is of course a base necessity.
However, we also need to consider the case where a system that behaves as intended is accessed and controlled by an external bad actor, potentially making it behave not as the driver intended.
This is equally (or possibly even more) unsafe but is now a security issue.
And this is where ISO 21434 is intended to help.
What does ISO 21434 compliance require?
ISO 21434 is a very broad standard covering the whole security lifecycle of on-board automotive systems.
It covers everything from design to development and engineering, through to production and even decommissioning of the systems.
Like ISO 26262, ISO 21434 has a number of sections which cover these different stages of the product development, operation, maintenance and decommissioning and each of these stages has a set of basic requirements.
The sections are summarised in the following table taken from the standard:
For software developers, the main section of concern is Section 10: Product Development – within the Product development phase – which includes the design and development of the software (Sub-section 10.4.1), as well as the integration and verification of the software (Subsection 10.4.2).
Each of these sub-sections has requirements in terms of the software development and expected work products that should be produced when following them.
Section 11: Cybersecurity validation – also within the Product development phase – includes requirements to review the work products from Section 10 to ensure the achievement of the cybersecurity goals for the finished product.
Requirements impacting software development
A significant part of ISO 21434 Section 10 requirements with respect to software security focuses on checking or reviewing the code being created for the presence of security vulnerabilities.
Or the likelihood of code to harbour such security vulnerabilities – the basic premise being that more complex the code, the more likely it is that the code could be hiding security flaws because it isn’t easy to visualize or understand the impacts of it.
A common solution here is to use coding standards – in this case security focused coding guidelines – which essentially encapsulate developer experience into rules that can then be applied to any code in order to detect cases of complex or insecure code.
There are a number of security focused coding guidelines that are well-known and well-regarded, internationally, including: OWASP, CWE Top25 and CERT. However, for embedded software – as is found in on-board automotive systems – CERT C, CERT C++ and MISRA C 2012, which covers security in addition to quality as of the Amendment 1 release, are generally regarded as more suitable.
In fact, ISO 21434 requirement [RQ-10-05], from Section 10, states: Criteria (see [RQ-10-04]) for suitable design, modelling or programming languages for cybersecurity that are not addressed by the language itself shall be covered by design, modelling and coding guidelines, or by the development environment.
It then goes further to provide an example of such coding guidelines (Example 5): Use of MISRA C:2012 or CERT C for secure coding in the “C” programming language.
Coding guidelines like CERT C and MISRA C 2012 generally comprise of many rules; 100 or so in the case of CERT C, and nearly 200 in the case of MISRA C 2012.
This is great from the perspective of ensuring that the code is being checked for potential security flaws.
But it is not great for the person responsible for the code review, who now has to remember 100+ rules and try to apply them to hundreds of lines of new code.
Or worse still, the entire projects consisting of thousands or even millions of lines of code.
This is where a static analysis code checker, or Static Application Security Test tool, can help; by automating the code check and providing the reviewer with a list of violations to look at, specifically.
A guided code review, if you will, with much of the laborious searching work done for you.
Another key aspect of the ISO 21434 Section 10 – such as requirements [RQ-10-02], [RQ-10-03] and [RQ-10-07] – is the necessity to understand and then assess the architecture of the system with respect to vulnerable components and interfaces.
Clearly, in almost any modern codebase, where development is often done in parallel and with so many interfaces to other related components or the outside world, this is a non-trivial task.
How Emenda can help
Static analysis tools, or SAST tools, have a vital role to play in ensuring that high-quality, readable and secure code is created from the ground up.
They are relatively cheap to use, in comparison to Dynamic Application Security Test (DAST) processes and provide actionable feedback directly to the developers.
In addition, static analysis tools like SciTools Understand Codecheck, Klocwork and Helix QAC are able to enforce many of the security focused coding guidelines – like CERT C and C++ and MISRA C 2012 – which are a recommendation for ISO 21434 compliance SciTools standards coverage
In addition to code checking and coding standards compliance, the SciTools Understand toolset is also capable of producing architectural visualisations of codebases, to help with the security assessments and dependency analysis of the components within the system, as required by ISO 21434.
Finally, the Secure Code Warrior developer learning platform provides context-sensitive real-time training equips developers to have a security-first mindset, by teaching them the skills needed to defend their organization through secure code.
When it comes to security, developers are the first line of defense.
What’s next?
Contact us today for a free trial, or to find out more information about any of our products and services and how Emenda can help you with your ISO 21434 compliance journey.
References & Useful Links
- ISO/SAE 21434:2021: https://www.iso.org/obp/ui/#iso:std:iso-sae:21434:ed-1:v1:en
- SciTools Code Check for MISRA C: https://support.scitools.com/support/solutions/articles/70000583267-misra-c-and-misra-c-
- SciTools Codecheck: https://support.scitools.com/support/solutions/articles/70000583282-codecheck-overview
- Secure Code Warrior for compliance: https://www.securecodewarrior.com/solutions/achieve-compliance