Compiler Tool Qualification for Functional Safety and Cybersecurity

Article By : Gerard Vink, TASKING

The automotive industry is characterized by three major trends: digitalization, connectivity, and highly automated vehicles. While safety processes are established and mature, each of these three trends requires the need for comprehensive cybersecurity processes. This article focuses on the management of compiler-induced cyber security vulnerabilities.

In 2020, the United Nations Economic Commission for Europe (UNECE) 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 European Union, the UK, and several countries outside Europe such as Korea and Japan this regulation is being incorporated into legislation for vehicle type approval rendering cybersecurity compliance as nonnegotiable for securing market access.

Gerard Vink

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. Likewise, demonstrating compliance with the ISO cybersecurity standard should protect OEMs and their suppliers from liability.

Compiler Qualification for FuSA

Compiler tool qualification for functional safety is a solved problem. The ISO 26262 standard devotes an entire 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 are provided to 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 ASILs, only the latter two methods are suitable. In the industry, the tool validation method is widely applied. Essentially, tool validation means using validation 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. In this case, the customer receives a certified compiler toolset and only needs to apply the guidelines from the safety manual to show that his 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 summarized as:

• Specifying the use case in order to define the requirements to be satisfied by the tool

• Selecting the appropriate tests to verify those requirements

• Performing the tests

• Analyzing the test results

• Generating the safety documentation

• Applying the guidance from the safety documents.

The downside of this latter approach is that there are quite a few hidden costs 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 for Cybersecurity

The ISO cybersecurity engineering standard (ISO 21434 section 5.4.7 Tool Management) specifies that “tools that can influence the cybersecurity of an item or component shall be managed”. A compiler can modify (optimize) the behavior 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 therefore the compiler affects the cybersecurity of the software.

Unlike the ISO FuSa standard, the ISO cybersecurity standard does not specify tool qualification requirements. No guidance is given as to what exactly “shall be managed” means. As such, this leaves a lot of room for interpretation:

• 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.

However, the ISO cybersecurity standard contains many references to the ISO functional safety standard. The proven tool validation method of the ISO 26262 standard is suitable for the qualification of a compiler toolset used in development of a cybersecurity regulation complaint software. In order to apply this method, the tool validation criteria for the development of cybersecurity related software need to be established.

Tool Validation Criteria for Cybersecurity

Analogous to the tool validation criteria for functional safety, the criteria for tool validation for cybersecurity can be specified as:

1. The validation measures shall provide evidence that the software tool complies with the specified cybersecurity requirements.

2. The cybersecurity risks that can be introduced by the software tool and their corresponding behaviors shall be analyzed together with information on their possible consequences and with measures to avoid or detect them.

3. The reaction of the software tool to anomalous operating conditions shall be examined.

To meet criterion 1, the cybersecurity requirements on the compiler toolset must be specified. The Mission Assurance Engineering (MAE) process developed by the National Cyber Security FFRDC (NCF), which is part of MITRE, can be used for this purpose. This process is compatible with the criteria from ISO 21434 chapter 15 Threat Analysis and Risk Assessment methods. If this MAE process is performed by the tool vendor and the results are described in the tools’ safety & cybersecurity documentation, then this eliminates the need for the tool user to perform a tool validation.

Criterion 2 must be satisfied by the tool user based on the guidance from the tools’ safety & cybersecurity manual. Finally, the tool user must assess the residual risk associated with his specific use case that remains after applying the guidelines.

To satisfy criterion 3, the tool supplier has to analyze the reaction of the software tool to anomalous operating conditions using the aforementioned Mission Assurance Engineering process. The findings are translated into guidelines and are included in the tools’ safety & cybersecurity manual. Analogous to satisfy criterion 2, the tool user must implement the provided guidelines and asses the residual risk for his use case.

Identification of cybersecurity requirements

The mission assurance engineering (MAE) process that is used to identify the cybersecurity requirements related to the compilation process is shown in Figure 1, it provides a analytic approach to:

• Identify the cyber assets most critical to mission accomplishment.

• Understand the cyber threats and associated risks to those assets.

• Select mitigation measures to prevent and/or fight through attacks.

Figure 1: The Mission Assurance Engineering (MAE) Process Framework.

TASKING implements this MAE process using a Failure Mode and Effects Analysis (FMEA) and a Threat Assessment and Remediation Analysis (TARA). Note that the purpose of these activities is to ensure the integrity of the tool user’s software, rather than the integrity of the compiler toolset. This is in line with the aim of ISO 21434 which is to address the cybersecurity perspective in engineering of electrical and electronic (E/E) systems within road vehicles where systems external to the vehicle are not within the scope of the ISO 21434 standard. 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.

Failure mode and effects analysis (FMEA)

The Failure Mode and Effects Analysis (FMEA) is used to identify the potential cybersecurity risks that the compiler toolset can introduce into the user’s software. The mission objective of the compiler tool can be defined as: the behavior of the software being compiled shall meet the user’s intentions under both normal conditions and under cybersecurity attack conditions. Note that the ISO C and C++ language specification provides large freedom to compiler engineers to apply transformations on the software that are correct based on a legalistic interpretation of the ISO C and C++ standards, but that would surprise many talented software programmers. Therefore it is beneficial if the FMEA is executed by a team of engineers that 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.

Threat Assessment and Remediation Analysis (TARA)

The Threat Assessment and Remediation Analysis (TARA) from MITRE is a methodology used to identify and assess cyber vulnerabilities and select countermeasures that are effective to mitigate those vulnerabilities. This methodology is compatible with the requirements of ISO 21434.

The TARA workflow shown in Figure 2 can be summarized as follows. System technical details are used to construct a cyber model of the system architecture, which provides a basis for searching the catalog for plausible attack vectors. For our purposes the Common Attack Pattern Enumerations and Classifications (CAPEC) database is used as catalog. Subsequently the list of attack vectors is filtered and ranked based on assessed risk, producing a vulnerability matrix. The list of vulnerabilities is combined with mitigation mapping data from the catalog to identify an initial list of countermeasures, which is filtered and ranked based on assessed utility and lifecycle cost, producing a mitigation mapping table.

Figure 2: TARA assessment workflow.

Subsequently countermeasures are selected based on cost and level of risk tolerance. Finally, a solution effectiveness table is created which lists recommended countermeasures/mitigations and provides details on the effectiveness of each countermeasure over the range of vulnerabilities assessed. In addition to information from the CAPEC catalog, information can be retrieved from other databases, such as the CWE catalog of software and hardware weakness types and the CVE catalog of disclosed cybersecurity vulnerabilities.

Due to the highly dynamic nature of the cybersecurity domain, a regular repetition of the above analyses is necessary.

The Result of the FMEA & TARA

The aforementioned analyses show that compiler-induced vulnerabilities can be classified as being related to standard vulnerability classes, side channel attacks, undefined behavior, and persistent state violations. The associated mitigations are either cybersecurity related requirements that must be implemented by the tool vendor or requirements that shall be satisfied by the tool user.

Requirement to be implemented by the tool vendor are for example: protection against stack-smashing attacks via compiler placed stack-canaries, measures to detect buffer-overflow, or provisions to support memory layout randomization.

Requirements to be met by the tool user relate to generic coding guidelines and guidelines specific to the particular compiler toolset being used. MISRA compliance is considered a minimum, adherence to the SEI CERT C/C++ coding guidelines provides more comprehensive prevention against cybersecurity-related risks. The guidelines for a particular compiler toolset depend largely on the optimization philosophy that is applied by the compiler vendor. Some vendors claim that FuSa and cybersecurity requirements inhibit all optimizations applied by the compiler. At the other end of the spectrum, 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. At TASKING, we believe that optimizations do not have to introduce FuSa and cybersecurity risks if, and only if, the compiler provides sufficient diagnostic information about the applied optimizations to make the user of the tool aware about possible consequences.

Conclusion

We have described a systematic methodology to qualify a compiler toolset as suited for the development of software that must meet ISO 21434 criteria.

The methodology is based on the MITRE Mission Assurance Engineering Process. TASKING applies this methodology to ensure that its compiler toolsets are fit for purpose.

The combination of both an FMEA performed by engineers with expert knowledge of a compiler’s design and implementation, and a TARA based on cybersecurity knowledge obtained from public databases, are complementary.

Both analysis result in cybersecurity related requirements that must either be met by the tool supplier by supporting additional facilities in the toolset, or that must be met by the tool user by applying the guidance from the safety and cybersecurity documentation that comes with the tool.

A tool qualification performed by the compiler vendor increases the quality of the analysis related to compiler-induced cybersecurity vulnerabilities. For the tool user, it avoids the need to acquire tool specific competences and knowledge, and results in cost and lead-time reduction.

About the Author

Gerard Vink is Industry Specialist Product Definition at TASKING. He studied mechanical engineering and computer science and has long-term experience with the development of tools and processes for (embedded) software development. In his spare time, he likes to race motorcycles and was Dutch champion in the RC1000 class in 2019.

Comments are closed.