Integrated Development of Safety and Security Requirements

Reprinted from Technical Papers on the Development of Embedded Electronics by Vector

Christof Ebert, CEO of Vector Consulting Services GmbH and a professor at the University of Stuttgart
Eduard Metzker, Solution Manager for Cyber Security at Vector Informatik GmbH

Today, the systematic development of safety requirements is essential in developing embedded systems. Due to the growing number of functions and interfaces to backend and cloud services, the consideration of safety in conjunction with security is becoming increasingly more important. However, a universal approach is lacking in this field. This article presents a method for integrated, semi-formal development of safety and security requirements. The advantages of this ‘requirements-engineering-methodology’ for safety/security are illustrated by the example of an ADAS (Advanced Driver Assistance System), and the potential of tool support is demonstrated.


Requirements for Safety and Security

Cloud services, such as emergency systems, which are essential for survival are being paralyzed. Hackers are penetrating into train control systems and causing malfunctions. Industrial systems are being sabotaged by trojans. Implanted medical devices are being manipulated via the diagnostic interface, causing them to fail in their tasks. Who has not seen such headlines? The sabotage of critical infrastructure is not only the goal of terrorists, but unfortunately increasingly the doing of misguided professionals as well. The one wants to demonstrate the helplessness of our society, while the other is seeking personal power. Increasing numbers of embedded systems are becoming critical to safety. Compromised software can lead to the failure of critical functions. An insulin pump, like the type implanted in many people, can be manipulated by an informed hacker to deliver the incorrect dosage – with potentially lethal consequences. It is high time to not only derive safety requirements from software errors and random malfunctions, but to also focus specifically on attacks related to the security of information.

Functional safety and information security are becoming more intertwined. Functional safety requires reliable and secure information, whether it involves vehicles, medical equipment or industrial automation. The focus here is on requirements for security and verifiable, systematic and universal requirements engineering. The goal of integrated safety and security development is to limit the risk of hazardous situations to an acceptable level by developing functions that can react as robustly as possible to equipment and human errors as well as external attacks. This article shows how functional safety and information security can be successfully implemented in such systems from the perspective of requirements engineering.

In German, the word “Sicherheit” has two meanings. “Sicherheit” means the absence of danger. The use of a product or function must not endanger the health or well-being of the user or the environment. The producers and hence the developers of a function must assure that this function is available when it is needed. Equally important is assurance against unnecessary execution of functions. Here, a list of measures can contribute toward preserving the desired functionality under various constraints. Related monitoring actions assure proper execution. This is known as “functional safety”. The absence of danger also implies trust. I can trust that a message from a sender really originates from that sender. Or I might want to transmit a message and be certain that no one can alter it. This specific aspect of safety represents the subject area of “security”. It relates to the integrity, authenticity and trustworthiness of information, which is why it is referred to as information security.

The fundamental meaning of quality in relation to a system is that the system provides the functions expected of it [1]. When safety and security are interlinked, this classic definition is extended to include the meaning that the system does not provide any other functions that are not expected of it – because of failure, human error, equipment malfunction or malicious attack. In this article, we will use the concepts of “safety” and “security” to better distinguish the semantics and thereby the different methodological approaches. In the future, functional safety will no longer be sufficient without “information security”. This is reflected in two important trends: constant growth in the networking of functions and the development of increasingly more autonomously acting diagnostic and assistance systems. Both of these trends are generating a growing number of potentially safety-relevant functions. A relatively new trend that can be identified is the growing trend toward networking vehicle functions with backend services by automotive manufacturers or IT cloud services. This networking opens up entirely new services and business models such as retrofitting functions by software update or communication between devices, e.g. IT and automation engineering in Industry 4.0. This linking of differing components and their networks with open, external networks increases the potential for security-related threats.

In requirements engineering, the dependencies and mutual interactions between safety and security requirements must be viewed in a methodically clean and systematic way. The described interrelationships are visualized in Figure 1.

Figure 1: Requirements engineering identifies mutual interactions and dependencies of safety and security
Figure 1: Requirements engineering identifies mutual interactions and dependencies of safety and security

They must be made manageable by an integrated approach to developing and verifying requirements. Currently, this is handled rather unsystematically, because industrial standards for safety and security are still very much treated in isolation from one another. In this article, we want to present an integrated, systematic approach in the framework of requirements engineering. First, excerpts of the methodology for safety requirements are described in section “Developing and Verifying Safety Requirements”. We intentionally restrict this to the creation of functional safety requirements, because early phases have a large effect on the rest of the process. They form the foundation for an integrative approach to security requirements that is presented in section “Developing and Verifying Security”. Section “Case Study: ADAS System” illustrates an integrated approach based on the example of an ADAS (Advanced Driver Assistance System). The potential for tool support is discussed in section “Potential for Tool Support”.

Developing and Verifying Safety Requirements

First, the limits of the system under consideration are set, and its basic functions are described. In addition, relevant operating scenarios are defined. In threat and risk analysis, hazardous events are derived from the basic functions and potential malfunctions. This involves quantifying a hazardous event’s risk level – also known as the Automotive Safety Integrity Level (ASIL) – under consideration of the relevant operating scenarios. For each relevant hazardous event, safety requirements known as safety goals are identified, which are still relatively roughly defined. In the design steps that follow, the safety goals are broken down into functional safety requirements and allocated to elements of the system design that are responsible for implementing the requirements. Together they make up the functional safety concept. All other process steps for safety, such as quantitative and qualitative safety analysis, are beyond the scope of this article. In the next section, we supplement this methodology with procedures for developing and verifying security requirements.

Developing and Verifying Security Requirements

After the basic system functions have been defined, they are used as a foundation for identifying protective assets and their owners [2]. An example of an asset for vehicle owners is that their personal privacy cannot be violated by third parties evaluating their movement profiles. In threat and risk analysis, the assets are used as a basis for identifying attackers who would have the potential to execute a malicious action at an attack point in the system and therefore represent a threat to the asset. The risk is a function of the attack potential and the severity of the threat. The owners of the assets want to reduce the risk of threats to an acceptable level by implementing suitable security goals. These interrelationships are shown in Figure 2.

Figure 2: Interrelationships in threat and risk analysis
Figure 2: Interrelationships in threat and risk analysis

In subsequent design steps, the security goals are broken down into functional security requirements and allocated to elements of the system design that are responsible for implementing the requirements. Together they form the functional security concept. Analogous to the approach taken for safety, all further security process steps that take place are beyond the scope of this article. Figure 3 shows, in simplified form, security activities in the context of their relationship to the overall process and to safety activities.

Figure 3: Shared view of safety and security requirements
Figure 3: Shared view of safety and security requirements

Case Study: ADAS System

A sub-system of an ADAS (Advanced Driver Assistance System) for an automobile is used as an example in the following. This sub-system is a lane departure warning assistant that warns the driver before the vehicle leaves the driving lane. If necessary, it makes a steering intervention to steer it back into the lane. The system has a number of sensors for acquiring the surroundings and a number of actuators for performing driving interventions and for notifying the driver. The prescribed system structure is shown in Figure 4.

Figure 4: Rough system structure of ADAS (sub-system: lane departure warning assistant)
Figure 4: Rough system structure of ADAS (sub-system: lane departure warning assistant)

This example illustrates similarities and differences in the development of safety and security requirements in early phases.

Due to its direct effects on vehicle dynamics, the system must set requirements for functional safety, e.g. avoid unintended steering or braking maneuvers. Networking of very different information sources in the sensor fusion process – such as radar and camera systems and various ECUs in the vehicle – requires careful verification of measures against external attacks. These requirements mutually influence each other in their methodical implementation and must therefore be developed together. We want to demonstrate this based on the described methodology.

Identifying Basic Functions and Deriving Safety Goals

In the context of system definition, the basic functions are first identified, and safety goals are derived in the framework of hazard and risk analysis.

In the lane departure warning example, one of the functions identified is the following function F1: “The lane departure warning assistant automatically initiates a steering intervention after detecting that the vehicle is leaving the lane and after a warning time has passed.” One of the operating situations identified as relevant to the lane departure warning system is the following situation designated BS1: “Driving on country roads, oncoming traffic, speed > 50 km/h.” In the framework of hazard and risk analysis, malfunction FF1 was identified for F1: “Counter-steering is executed, but in the wrong direction.” Hazardous situation H1 results from the interplay of F1, FF1 and BS1: “A collision with oncoming traffic occurs.” To assess the relevance of H1, the analysis utilizes the criteria of probability of occurrence (O), degree of severity (S) and controllability (C). Safety goal SG1 is defined to avoid H1: “Avoid implausible steering intervention of the lane departure warning system.”

Identifying Assets and Deriving Security Goals

In the framework of system definition, the assets worth protecting are first identified, and security goals are de-rived in the framework of threat and risk analysis.

In the asset definition process, one of the assets defined is A1: “The lane departure warning system behaves within its specification.” Asset owner B1 is the vehicle manufacturer. Attacker AT1 is an experienced hacker. An attacker of this type typically has the basic abilities needed to perform reverse engineering of hardware and software and to install its own malware via remote interfaces which then communicates with the rest of the system. AT1 can perform the malicious action FA1: “Suppress messages to actuators when departing from the driving lane by manipulating functional software.” The identified attack point AP1 is manipulation of the ADAS system software by an unauthorized software update. The attack potential of the attacker is assessed based on multidimensional criteria. These criteria include the attacker’s knowledge of the system, the attacker’s technical resources, and the time needed to execute an attack. The attack on the asset leads to threat T1: “The vehicle behaves like a system that is shutoff without the driver being aware of it. This could lead to accidents for which the automotive manufacturer is blamed.” The severity of this threat can now be assessed based on various security relevant criteria. They include the threat’s potential for violating safety goals as well as the threat’s potential for operative and financial damages to asset owner B1. To counteract the threat, security goal SCG1 is derived: “Protective SW and HW security mechanisms must assure that software and configuration parameters for the lane departure warning system cannot be falsified or delayed without this being recognized.”

Table 1 provides an overview of the similarities and differences in determining safety and security requirements. After deriving the safety and security goals, further refinement to the functional and technical requirements level is possible. In each phase, it is advisable to mirror the requirements by allocating them to the (preliminary) functional and/or technical architecture.

Table 1: Comparison of approaches for determining safety and security requirements
Table 1: Comparison of approaches for determining safety and security requirements

Potential for Tool Support

In classic tool chains such as those used in system development today, the processes described in sections “Developing and Verifying Safety Requirements” and “Developing and Verifying Security” are very fragmented. Requirements development, functional design and safety and security analyses are performed with various tools, wherein the interfaces often do not permit loss-free exchange of information.

For instance, ensuring the consistency of safety and security goals and the requirements derived from them over the entire life cycle can only be accomplished with great effort. One step toward an integrated safety and security concept and an advantageous refinement of requirements is allocating safety and security goals to the preliminary architecture. The advantage here is that it is possible to track requirements to the concept level very early on. This also permits early detection and resolution of potential contradictions and conflicts between safety and security requirements in system elements. To achieve this, it is advantageous if tools are able to support requirements development and system design in an integrated way. This is enabled by graphic visualization of the allocation as shown in Figure 5. Such types of visual representation make it easy to recognize contradictions quickly.

Figure 5: Allocating safety goals to system elements
Figure 5: Allocating safety goals to system elements

In Figure 2, we show the interrelationships between security goals, malicious actions and assets. Such interrelationships are easy to formalize in integrated tools in order to perform pattern-based consistency checks and recognize gaps and insufficiencies in requirements. If this occurs while requirements are being developed, this offers the potential for reducing the effort required for manual reviews.

Summary and Outlook

Requirements engineering for safety-critical systems must include the systematic development and evaluation of requirements for functional safety and information security simultaneously. The previously established separation of these concepts, treating them as two disciplines – each with its own standards and approaches – is no longer acceptable, because this approach overlooks dependencies and mutual interactions. A separated approach is also inefficient, because many of the functions need to be acquired multiple times. Methodological processes for assuring consistency, traceability, verification, modeling and test orientation should be applied together. A semiformal specification of safety and security requirements, together with suitable tool support, makes a contribution toward managing complexity and effort.

Literature

  1. Ebert, C.: Systematisches Requirements Engineering (“Systematic Requirements Engineering”). Dpunkt-Verlag (“Dpunkt Publishers”), Heidelberg, Germany, 5th complete-ly revised edition, 2014. Ebert, C.: Systematic Requirements Engineering (Chinese). Chinese Translation, ISBN: 978-7-111-43986-8, Huazhan Publishing Group, Shanghai, 2013. Systematic Requirements Engineering
  2. CCRA, “ISO/IEC 15408: Common Criteria for Information Technology Security Evaluation,” 2012.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: