Compiler tool qualification for functional safety and cybersecurity
In 2020 the United Nations Economic Commission for Europe released the regulation on uniform provisions concerning the approval of vehicles with regards to cybersecurity and cybersecurity management system, also known as WP.29.
In the EU, Japan, Korea and the UK, this regulation is being incorporated into legislation for vehicle type approval, rendering cybersecurity compliance as non-negotiable for securing market access.
Although WP.29 does not mention the ISO/SAE 21434:2021 road vehicles -cybersecurity engineering standard, it is understood that if an OEM and its supply chain can demonstrate compliance with this standard, then that compliance can be used to demonstrate compliance with the WP.29 regulation. Demonstrating compliance with the ISO cybersecurity standard should protect OEMs and their suppliers from liability.
Compiler qualification
The ISO 26262 standard devotes a chapter to criteria to determine the required level of confidence in a software tool and provides methods for qualifying the tool to create evidence that it is suitable to be used for functional safety-related software development.
Four methods qualify a software tool: increased confidence from use; evaluation of the development process; validation of the software tool; and development in accordance with a safety standard.
For higher Automotive Safety Integrity Levels (ASIL), only the latter two methods are suitable. Tool validation means using measures to prove that the software tool meets specified requirements for its purpose.
Two different approaches are being used to meet the ISO 26262 tool validation requirements. Some compiler suppliers perform the tool validation in-house and invite a conformity assessment body to certify that the tool and its safety documentation are fit for purpose. The customer receives a certified compiler toolset and needs only to apply the guidelines from the safety manual to show that the use case is compatible with a qualified use case. Other vendors offer a certifiable (versus certified) compiler toolset plus a tool qualification methodology with supporting tools and documentation.
The tool qualification methodology is generally certified and the customer must perform the tool qualification, which can be summarised as:
* Specifying the use case to define the requirements to be satisfied by the tool
* Selecting the appropriate tests to verify those requirements
* Performing the tests and analysing the test results
* Generating the safety documentation and applying the guidance from the safety documents.
There are hidden costs with this approach, such as learning the qualification methodology and associated tooling, licensing the necessary tests suites, performing the tool validation process, interacting with the certifier and finally, what to do if tests fail.
Compiler qualification
A compiler can modify (optimise) the behaviour of a program in ways that the programmer did not foresee. The software developer’s structural intent may not be accurately depicted in the final representation of the source program and the compiler can affect the security of the software.
Unlike the ISO Functional Safety (FuSa) standard, the ISO cybersecurity standard (ISO 21434 section 5.4.7 Tool Management) does not specify tool qualification requirements. The criteria to determine the required level of confidence in a compiler toolset for the development of cybersecurity related software are unknown and no method is specified to demonstrate that the cybersecurity related criteria have been met.
The ISO standard does contain references to the ISO functional safety standard. The proven tool validation method of the ISO 26262 standard is suitable to qualify a compiler toolset used in the development of a cybersecurity regulation compliant software. In order to apply this method, the tool validation criteria for the development of cybersecurity-related software need to be established.
Tool validation
Analogous to the tool validation criteria for functional safety, the criteria for tool validation for cybersecurity can be specified as measures to provide evidence that the software tool complies with the specified cybersecurity requirements.
The cybersecurity risks that can be introduced by the software tool and their corresponding behaviours shall be analysed with information on possible consequences and with measures to avoid or detect them.
The reaction of the software tool to anomalous operating conditions shall also be examined.
The Mission Assurance Engineering (MAE) process developed by the National Cyber Security FFRDC can be used to specify the cybersecurity requirements of the compiler toolset. This process is compatible with ISO 21434 Chapter 15 Threat Analysis and Risk Assessment methods. If the MAE process is performed by the tool vendor and the results are described in safety and cybersecurity documentation, this eliminates the need for the tool user to perform a tool validation.
The tool user must assess the residual risk associated with the specific use case that remains after applying the guidelines.
The tool supplier has to analyse the reaction of the software tool to anomalous operating conditions using the MAE process. The findings are translated into guidelines and included in the tools’ safety and cybersecurity manual. The tool user must implement the provided guidelines and assess the residual risk for a use case.
The MAE process (Figure 1) provides an analytic approach to identify the cyber assets most critical to mission accomplishment, understand the cyber threats and associated risks to those assets and select mitigation measures to prevent and/or fight through attacks.
A failure mode and effects analysis (FMEA) and a threat assessment and remediation analysis (TARA) ensure the integrity of the tool user’s software, rather than the integrity of the compiler toolset in line with the aim of ISO 21434 to address cybersecurity in electrical and electronic systems within road vehicles where systems external to the vehicle are not within the scope of ISO 21434. The integrity of the compiler toolset and files operated upon is governed by other standards such as ISO/IEC 27001 (Information Security Management). It is important that both the tool supplier and user also comply with an IT security standard.
The FMEA is used to identify the potential cybersecurity risks that the compiler toolset can introduce into the user’s software. The objective of the compiler tool is for the behaviour of the software being compiled to meet the user’s intentions under both normal conditions and under cybersecurity attack conditions. The ISO C and C++ language specification allows compiler engineers to apply transformations on the software that are correct based on a legalistic interpretation of the ISO C and C++ standards, but which would surprise many software programmers. It is therefore beneficial if the FMEA is executed by a team of engineers who have an in-depth understanding of the compilers’ requirements, architecture, design and implementation. For each identified failure mode one or more mitigation measures to reduce the risk must be provided.
The TARA methodology identifies and assesses cyber vulnerabilities and selects countermeasures to mitigate those vulnerabilities. The methodology is compatible with the requirements of ISO 21434.
The TARA workflow (Figure 2) uses system technical details to construct a cyber model of the system architecture. This provides a basis for searching the catalogue for plausible attack vectors. The Common Attack Pattern Enumerations and Classifications database can be used and the list of attack vectors is filtered and ranked according to assessed risk. The list of vulnerabilities is combined with mitigation mapping data from the catalogue to identify an initial list of countermeasures, which is filtered and ranked based on assessed utility and lifecycle cost, producing a mitigation mapping table.
Countermeasures are selected based on cost and the level of risk tolerance to create a solution effectiveness table that lists recommended countermeasures/mitigations and provides details on the effectiveness of each countermeasure over the range of vulnerabilities assessed. Information from other databases, such as the CWE (software and hardware weakness types) and CVE (disclosed cybersecurity vulnerabilities) can also be used.
The dynamic nature of cybersecurity means regular repetition of the above analyses is necessary.
The result of FMEA and TARA
Compiler-induced vulnerabilities can be classified as being related to standard vulnerability classes, side channel attacks, undefined behaviour and persistent state violations. The associated mitigations are cybersecurity-related requirements that must be implemented by the tool vendor. These include protection against stack-smashing attacks via compiler placed stack-canaries, measures to detect buffer-overflow, or provisions to support memory layout randomisation.
The tool user is required to meet generic coding guidelines and guidelines specific to the particular compiler toolset being used. The Motor Industry Software Reliability Association (MISRA) compliance is considered a minimum, and adherence to SEI CERT C/C++ coding guidelines provides more comprehensive prevention. The guidelines for a particular compiler toolset depend largely on the optimisation by the compiler vendor.
Some vendors claim that FuSa and cybersecurity requirements inhibit all optimisations applied by the compiler, while some compiler developers apply a very legalistic interpretation of the ISO C standard and consider compiler-induced cybersecurity risks as a side effect of the user’s insufficient understanding of the programming language.
The middle ground is held by those who believe that optimisations do not have to introduce FuSa and cybersecurity risks if, and only if, the compiler provides sufficient diagnostic information about the applied optimisations to make the user of the tool aware of possible consequences.
