Interactions Between Functional Safety and Cybersecurity

Even a cursory survey of electronic control units (ECUs) in a typical vehicle will reveal that the majority of these ECUs are safety-relevant. Whether it is braking, steering, propulsion, or battery management, there is barely a vehicle system where maintaining safety is not a primary objective. Whenever a system is subjected to safety hazards, a whole suite of engineering practices and methods is employed to achieve the required level of safety integrity. These practices aim to eliminate unreasonable safety risks that would lead to harming a human being while the system was in use. Engineering safety-critical systems that are also resilient to cyberattacks adds a new dimension to automotive engineering and are one of the main differentiating factors between automotive cybersecurity and information security. In addition to its focus on securing vehicle and user data, automotive cybersecurity is also concerned with eliminating...

A tale of two standards

ISO 26262 is the de facto safety standard for systematically eliminating unreasonable safety risks in automotive systems. It establishes a structured and uniform approach to managing safety risks throughout the development process, from the concept phase to decommissioning. The standard defines the required processes and guidelines over 12 parts and covers various aspects of the safety life cycle, such as management, development, production, and operation. The parts are organized into a hierarchical structure, with each part building upon the previous one to create a comprehensive safety framework.

Like its sibling standard from functional safety, the ISO/SAE 21434 standard was set up to guide automotive original equipment manufacturers (OEMs) and suppliers into adapting their existing engineering processes to ensure their products are free from unreasonable cybersecurity risk through a systematic approach. Comparing the two standards reveals a high degree...

A unified versus integrated approach

Both safety and security engineering approaches analyze risks, impose limitations on the system through design and implementation constraints, and produce protective measures. However, they do so by leveraging a unique set of methods, guidelines, and tools. While it is self-evident that a disjointed approach to safety and security engineering is inefficient and results in significant reworks, the choice between a unified and an integrated approach is not so obvious. Briefly, a unified approach is one in which the methods and work products become unified to address both aspects of safety and security. For example, the HARA would be extended to incorporate hazards originating from malicious events, the FMEA would be expanded to consider malicious causes of failure modes, and so on. Similarly, rather than producing a separate set of safety and security requirements, those would be unified to address both aspects of the system. This would continue throughout...

Establishing a foundational understanding of functional safety and cybersecurity

Implementing an integrated approach to safety and security engineering results in frequent interactions between safety and security teams. These teams analyze risk from different perspectives and are spread across different product life cycles, such as manufacturing, development, and testing. While the expectation is that neither team will become a full expert in the other’s domain, it is valuable for practitioners from each domain to be familiar with the terms, concepts, and general methods and tools available in each approach. This eases the conversation to help understand the areas of concern and why they are important from each perspective. Let’s look at an example where lack of a common understanding produces a real problem for a safety and security-critical system. During a safety analysis of a feature that controls how the system is booted, safety engineers discover that a rare corruption...

Extending the safety and quality supporting processes

A common challenge when introducing a cybersecurity management process is identifying how it can be integrated with existing processes.

To tackle this challenge, we must first assume that a quality management team exists that maintains the overall development life cycle – for example, by defining and maintaining a common engineering development handbook. There is usually also a safety engineering team that maintains a layer of safety practices on top of standard engineering practices. For example, there can be a process for managing requirements with safety overlays that describe expectations based on the ASIL of the system. The first hurdle is to determine how to adapt the quality and safety engineering process to account for cybersecurity activities. The natural step is to perform a gap analysis of ISO/SAE 21434 against the existing safety and quality engineering practices to determine how to integrate cybersecurity...

Creating synergies in the concept phase

The concept phase is where the security analysis begins. The aim is to map out the threats and choose the correct risk treatment decisions. As a result, a set of cybersecurity goals, claims, and requirements is produced. In this section, we will see how various security work products in the scope of the concept phase can be enhanced by considering inputs from the safety analysis, as well as the safety concept.

Item functions

As we saw earlier, the first step in performing a TARA in the concept phase is to define the item by listing its functions, the boundary at which those functions interact with the rest of the vehicle, and the environment in which the item operates. When performing a TARA for a safety-relevant system, many of the safety artifacts can be easily leveraged or adapted for security analysis.

The functions of the item serve as a valuable resource for grasping its objectives. Understanding the objectives of the system is...

Finding synergies and conflicts in the design phase

During the design phase, cybersecurity controls and requirements from the concept level are refined into technical security requirements and architectural elements and interfaces at the software and hardware levels. The refined security and safety requirements need another round of harmonization so that synergies can be identified and conflicts can be eliminated. In this stage, synergies are easier to identify as the mechanisms become more concrete due to requirements being allocated to the components of the architecture. When safety and security objectives overlap, a common strategy is to leverage security mechanisms to satisfy a safety objective and vice versa.

Leveraging safety and security mechanisms

As mentioned previously, safety and security objectives overlap in three main areas:

• Achieving freedom from interference
• Protecting data integrity
• Detecting and recovering from availability faults or attacks
...

Secure coding practices versus safe coding techniques

Similar to the design principles, coding guidelines between safety and security have a high degree of correlation. Both safety and security engineering approaches aim to reduce code complexity to prevent defects and vulnerabilities. They both require the usage of language subsets to avoid risky features of the programming language that can introduce unexpected or unwanted behavior. This can be enforced by using static code analysis tools based on MISRA C, CERT C/C++, and AUTOSAR C++. Normally, the toolchains support the safety and security guidelines, allowing the developers to check for all coding rule violations in a single run. When it comes to defensive coding techniques, there is a high degree of overlap between several such techniques:

• Input validation requires all inputs from external sources to be validated to ensure they conform to the expected formats, ranges, and data types. This can help prevent working on implausible...

Synergies and differences in the testing phase

Verification testing takes place at multiple stages of the development process, starting with the unit level, then the component level, and ending at the system level. A system developed according to ISO 26262 is expected to achieve a high level of quality assurance through testing rigor in proportion to the system safety integrity level. These test methods reinforce the quality argument of the system by verifying the correctness of the unit design and implementation, and the ability of the integrated system components to achieve the system objectives. One example test method defined by safety engineering is boundary value and equivalence class-based (BVEC) testing. BVEC testing involves testing the software system with values that are at the boundaries of the input domain or just outside of it to detect improper software responses. BVEC testing aims to identify any errors or exceptions that occur at the boundary values of input domains...

Summary

This chapter explored the similarities and differences between safety and security engineering approaches, highlighting the importance of taking an integrated approach to these two disciplines. First, this chapter focused on the process impacts and the need to extend existing safety and quality processes to satisfy the cybersecurity engineering approach. We then discussed the unique areas of each domain, emphasizing the need to increase safety and security literacy to understand how safety engineering focuses on identifying and managing risks that prevent accidents, while security engineering focuses on identifying and mitigating threats that prevent intentional harm. Conflicts between safety and security can arise, and this chapter presented strategies for resolving these conflicts. Similarly, many areas of synergies were explored throughout the concept, design, implementation, and testing phases. Several examples were shown in which safety reinforces the security properties...

References

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• [1] T. Novak, A. Treytl, and A. Gerstinger, Embedded security in safety-critical automation systems, in Proceedings of the 26th International System Safety Conference (ISSC 2008), Vancouver, Canada, 2008, pp. S.1–11.
• [2] L. Piètre-Cambacédès, Des relations entre sûreté et sécurité, Télécom ParisTech, 2010.
• [3] G. Stoneburner, Toward a Unified Security-Safety Model, Computer, vol. 39, no. 8, pp. 96-97, 2006.
• [4] D. P. Eames and J. D. Moffett, The Integration of Safety and Security Requirements, in Proceedings of the 18th International Conference on Computer Computer Safety, Reliability and Security, London, UK, UK, 1999, pp. 468-480.
• [5] B. Hunter, Integrating Safety And Security Into The System Lifecycle, in Improving Systems and Software Engineering Conference (ISSEC), Canberra, Australia, 2009...