Options:

Christof Ebert

Cyber Security Requirements Engineering

Hands-on guidance for developing and managing security requirements


Sophisticated functionality and ever-increasing perfection of embedded and distributed IT systems have been made possible through an increasing amount of interconnected components. Open interfaces, standardized platforms, and a variety of heterogeneous networks drive complexity and security risks. For any given system it is only a question of time before the resulting security vulnerabilities are systematically identified and exploited at the harm and expense of users and manufacturers. This article provides experience and guidance concerning how information security can be successfully achieved with a security requirements engineering perspective. Our experiences from embedded security in automotive, transport, and automation show that security is only successful with a systematic understanding and handling of security requirements and their interaction with functional requirements. Four requirements engineering (RE) related levers for achieving embedded security are addressed: security requirements elicitation, security analysis, security design, and security validation. We will show for each of these levers how security is analyzed and implemented. Only systematic and disciplined security requirements engineering will ensure that security needs are met end-to-end from concept to architecture to verification and test and – most relevant – operations, service and maintenance.

1. Cyber Security Requirements

Security is a quality attribute which interacts heavily with other such attributes, including availability, safety, and robustness. It is the sum of all of the attributes of an information system or product which contributes towards ensuring that processing, storing, and communicating of information sufficiently protects confidentiality, integrity, and authenticity. Cyber security implies that it is not possible to do anything with the processed or managed information which is not explicitly intended by the specification of the embedded system [1] [2].

To better illustrate evolving cyber security needs, we will look to modern automotive systems. Figure 1 shows the interaction of functions in their distributed networks being an essential part for our today’s modern infrastructures with their needs for safety and comfort. Besides the further development of innovative sensors like radar and camera systems and the analysis of the signals in highly complex systems, the connected cars will be a driving factor for tomorrow‘s innovation. Internet connections will not only provide the need for information to the passenger - functions like eCall, communication between cars, and car to infrastructure (vehicle2x) shows high potential for revolutionizing the individual traffic. This includes the improvement of the traffic flow controlled by intelligent traffic lights, warnings from roadside stations, or brake indication of adjacent cars. This builds the basis for enhanced driver assistant systems and automated driving. But the connection to the outer world also bears the risk for attacks to the car.

Figure 1: Car with remote connections

Figure 1 shows interworking for vehicle2x and external communication that are already available today or will become available in the near future. Each connection to the car has a potential risk for an attack, regardless whether it is wireless or wired - only the threat is different. The access through a connector is only possible for a limited amount of cars, whereas a far field connection can be accessed from anywhere in the world. But also near field connections play an important role, such as a tire pressure monitoring system, Bluetooth, and wireless LAN. Security and reliability of these connections will be essential for the acceptance and success of these systems. With the introduction of this technology precautions must be taken to increase the reliability and to reduce the vulnerability to the system.

Functional safety needs cyber security. Based on the specific challenges of cyber security, OEMs and suppliers have to realize an effective protection against manipulations of automotive electronic and electric (E/E) systems. Key points in the development of protected E/E systems are the proper identification of security requirements, the systematic realization of security functions, and a security validation to demonstrate that security requirements have been met. The following items need to be considered to achieve security in the car development process:

Based on our experiences in several client projects, we show which security engineering activities are required to create secure systems and how these activities can be performed efficiently in the automotive domain. In the following discussion, we want to examine each of these topics, the current activities, and provide suggestions concerning how to mitigate the security risks.
Traditionally automotive system and electronics requirements are function-driven. But, by defining functionalities alone, there is nothing said about the correlation of features which is where security risks typically show up (see our introductory example). We will start with explicit security requirements, as they have emerged in IT systems over time [1] [2] [3] [4] [6]:

Security requirements encountered in embedded systems development typically target its dependability. Such systems are embedded into a technical process; thus dependability is imperative to prevent failures of the technical process itself or its environment. Dependability demands that system functionality, determined by its functional requirements, is delivered correctly – considering feature correlations and disturbances from the outside. Besides accurate realization of the functionality, information needs to be correctly processed during operations of the embedded system, i.e. without being distorted during transmission or storage. Additionally to the need for correct information processing, embedded systems interact with real world objects, which means they are subject to real-time requirements of these real world objects. Information must not only be processed correctly, but also within determined time limits.
Both cyber security requirements and embedded systems’ reliability requirements have one thing in common: They aim to deflect unauthorized manipulation of information inside of computer systems – be it interferences with the system environment or intentional manipulations of unauthorized entities (i.e. attacks).

2. Security Requirements Engineering

2.1 Case Study

In this section, we will examine key elements of security requirements engineering, specifically requirements elicitation and security requirements analysis. As an example, we utilize the simplified functionality of an automotive embedded control unit (ECU) that controls the automatic opening and closing of the roof of a convertible. Security impacts are manifold with this example, from getting access to the car and its contents to inserting a safety hazard to the driver if the roof opens during driving. The top level functional requirements are presumed to be (the abbreviation FR denominates functional requirements and SR security requirements):

Additionally, two top level safety requirements are supposed:

2.2 Security Requirements Elicitation

The first step is to establish the security objectives. When considering above requirements, it becomes clear that the detail level of such information is not sufficient for security analysis. Possible security threats emerge from unauthorized information gathering and manipulation. To judge these possible attack vectors, more detailed knowledge of the embedded system being analyzed is required. To discuss security threats, the communication transactions of the system must be known as well as the effect of these transactions. Knowledge of the communication technology to be employed is equally important, because different communication standards imply different vulnerabilities, where an attacker can mount an attack. The same holds true for determination of security threats against device software. The distribution of functions on different devices is to be known as well as underlying hardware details. The device hardware constitutes, which (hardware) interfaces can be used by attackers and if stored information can be deleted or modified.

To conduct the security analysis, we assume the following system situation. The ECU receives the following information to execute its functionality: “open roof button pressed”, “close roof button pressed”, “vehicle velocity”, and “obstacle detected”. The following information is sent by the ECU: “roof completely opened” and “roof completely closed”. All information is received or sent via the embedded network, implemented by bus systems such as CAN and Flexray, which are controlled by the AUTOSAR base software. The ECU actuates the roof motor by controlling the electric current to the motor. Obstacles are detected by a smart sensor, which is also connected to the CAN bus. The system functionality is realized as software on one microcontroller inside the ECU. The microcontroller features internal non-erasable memory. Figure 2 describes the system.

Figure 2: Assumed system layout

2.2. Security Analysis

To understand vulnerabilities and determine security risks we apply misuse cases. Similar to use cases, misuse cases show a specific way to use a system. Misuse cases describe sequences of events that, taken together, lead to a system doing something that is not intended or even unwanted. Misuse cases that imply an unacceptable risk are taken to deduce concrete security requirements which are subsequently translated into functional requirements. Here is additional concrete guidance: Each identified security requirement must be linked to at least one functional requirement that is linked to design artifacts and test cases and monitored until closure – from design to validation and service.

Hazard Analysis. In this section, we will discuss the possibilities of an attack on the convertible’s roof. First, the information that is received by the roof ECU and used to act accordingly are to be considered. Second, the ECU software program, which implements the ECU functionality, needs to be regarded. Both information entities, transmitted via communication systems or stored as a program, can, in principle, be tampered with by an attacker.
Different transmitted information is used by the roof ECU:

As depicted in section 3, there are different ways to attack communication. The network, which is used to transmit information concerning the roof ECU, shows vulnerabilities against all these ways of attack. Thus, the following functionalities need to be considered to protect such distributed communication:

The program controlling the ECU is verified by means of checksums, making it difficult for an attacker to change it. Attack paths thus need to consider software updates starting from the code creation and its validation up to its delivery in a repair shop anywhere in the world. Determining attacker motivation is difficult in the given case. Generally, it seems unlikely in the example, that someone would manipulate functionality as the one depicted above. However, we will look into possible impacts of manipulations to determine which protection functionalities need to be realized and which can be disregarded.

Risk Assessment. Possible hacker motivations may include curiosity or sabotage. Thus, we quantify attacker motivation with “3”, meaning a medium motivation to attack.

Because of the high degree of publicity of bus specifications, its vulnerabilities to attacks, and the availability of hardware/software tools for manipulation, attacker capabilities need to be judged at least to be “4”, meaning the attacker possesses advanced capabilities to manipulate the bus.

Effects of attacks depend on the information to be manipulated. Misuse cases related to the functional requirements presented result in malfunctions that may be inconvenient but are essentially harmless. A forged request to open or close the roof would result in the opening or closing of the roof, without the driver requesting this operation. Here we have a security requirement with clear safety impacts. If the messages containing information about vehicle velocity or obstacle detection are manipulated, the roof could be opened at high speed or the closing roof would not be interrupted despite an obstacle in the path of the roof. Both incidents can result in the mentioned effects, so the cost effect is assigned to be “5”, resulting in a risk priority number of 60.

Assuming an acceptable residual risk of 50, one would define the following security requirements:

We see that dependability requirements are a good starting point to identify relevant security requirements and to guide elicitation of further functional requirements that will mitigate security risks. The same technique as outlined here can be applied for other scenarios – always starting with attacker motivation or functional risks due to the system architecture. Our guidance: Do not limit exposure to known incidents and defects as some textbooks suggest. Security analysis is not a checklist approach. It has to consider attack motivations of persons thinking differently than the usual engineer. However, utilizing an engineering approach, we can more easily identify vulnerabilities in our architectures.

The results of security risk and hazard analysis starting with asset identification to misuse, abuse and confuse cases and the entire security protection scheme should be well-documented. It is of utmost interest to understand the approach specifically when modifications are made at a later point. Form a legal perspective complete and maintained documentation is necessary for governance and compliance reasons. Security threats and resulting damages impact the safety of products and the integrity of private data, and are thus directly endangering the financial health of a company. Our guidance: Document the security case similarly to the safety case by means of a ALM/PLM environment such as PREEvision [5]. Maintain the related documentation and enhance it with regression test scenarios for future updates.

3. Relevance and Outlook

Security is thus of growing relevance to all industry areas. Embedded systems increasingly utilize networked software components based upon standardized open architectures. Due to their long life-time within changing environments, different versions and configurations are combined in different variants over time with software or hardware upgrades.
Currently used concepts, such as proprietary subsystems, the protection of components, firewalls between components, and the validation of specific features are insufficient to ensure security at the systems-level [6]. Intelligent attack scenarios evolve from different directions, such as attacks on unprotected networks, introduction of dangerous code segments through open interfaces, changes to configurations, and prove that security has to become a topic throughout the entire organization and with high management attention.

Systematically ensuring security from requirements to service of vehicles:

Security requires an end-to-end RE perspective. This article with its many practical examples demonstrates that security of automotive embedded systems can be achieved with clear and systematic focus and limited extra effort on the basis of disciplined RE. Security engineering in embedded systems must start with a clear focus on security requirements and related critical quality requirements, such as safety, footprint, or performance and how they map to functional requirements. Embedded software suppliers and integrators first define the key functional requirements. These requirements are then analyzed for security risks and impacts. Security requirements are expanded into further functional requirements or additional security guidelines and validation steps. RE security concepts are subsequently and consistently (i.e. traceable) implemented throughout the development process. Finally, security is validated on the basis of previously defined security requirements and test cases.

We showed how security RE is mastered along the entire system life-cycle. Many security attacks are the result of poorly managed software updates and uncontrolled complexity growth. Architectures, systems, and protocols must be developed with security in mind (i.e., design for security). Competences have to be developed around security engineering, and employees have to be trained how to design, verify, and sustain security throughout the product’s life-cycle. Only with continuous measurements on their effectiveness the value of security measures improves.

Traditional embedded software engineering ignored security for various reasons, such as having isolated components, dealing with heavily constrained resources, and being unable to handle the computational overheads. Today, however, embedded security is in the foreground due to safety, legislative, and intellectual property concerns [6].

With our described product life-cycle oriented security RE, the good news is that in contrast to internet security, securing embedded systems is likely to succeed in the next five years. By doing so, embedded system suppliers and integrators are increasingly in a position to allow marketing and selling security as part of an overall quality concept. It will help to master liability risks and to ultimately increase revenues.

References and Literature



Christof Ebert

Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to improve product strategy and product development and to manage organizational changes. A trusted advisor for companies around the world, member of industry boards, he lectures at the Universities of Stuttgart and at the Sorbonne in Paris. He authored several books including the popular “Systematic Requirements Engineering”. Contact him at christof.ebert@vector.com