When we speak of software security in the context of functional safety, this may seem incorrect at first, since it is primarily concerned with safety and thus with the possible impairment of life and limb. However, missing or insufficiently considered security can have a negative influence on safety.

The so-called "jeep hack" in the middle of the year was a particularly striking example of this. [1] The two security researchers Charlie Miller and Chris Valasek manipulated journalist Andy Greenberg's Jeep Cherokee in such a way that it was possible to control the vehicle remotely. They were not only able to operate infotainment and comfort functions, but also to influence the ride. For example, it was possible to disengage the transmission, thus making it impossible for the driver to accelerate further. Although the feasibility of such scenarios has been demonstrated before, prior physical access to the vehicle was always required, for example, to install a diagnostic connector in the vehicle or to carry out other manipulations. [2, 3]

Infotainment system hacked

Miller and Valasek needed only the IP address of the infotainment system installed in the vehicle and connected to the Internet in order to take over the vehicle via a vulnerability contained therein. To do this, they modified the firmware so that they could send messages from the infotainment system to the vehicle's ECUs via the CAN bus. A short time later, Andy Davis showed how attacks on vehicles could be carried out even without detailed knowledge of their connection data. Instead, the attack channel was additional services of the digital radio DAB, which are transmitted via a separate transmitter. [4]

In doing so, Davis exploited various vulnerabilities of different infotainment systems, such as security holes in graphics libraries in connection with slideshow images (MOT) or problems known from the field of web applications such as SQL injection and cross-site scripting (XSS) in connection with radio accompanying text (DLS).

There are several reasons for the increased awareness of security problems in the automotive environment in recent times. Vehicles are being equipped with an increasing number of comfort, infotainment and driver assistance systems, which increases the scope and complexity of the software used in the vehicle. In addition, interfaces for wireless communication are increasingly being installed, for example to access current traffic data while driving or to be able to start the vehicle's air conditioning system some time before the journey. Autonomous vehicles are in development and are taking on tasks that will determine the health and lives of the occupants.

Vulnerabilities due to new systems and interfaces

The additional interfaces and new systems represent potential attack vectors and are sometimes connected to systems that were originally intended only for operation by the vehicle's occupants. The life cycles of individual components can also differ greatly, so that at the beginning of a device's development it was not even foreseeable that it would later be used together with another device or interface. The developers of an ECU may not even be aware that their system will be used in an environment where it will receive messages not only from benevolent communication partners. Reasons for this can be either a lack of awareness of the problem on the part of the developers, but also an incomplete, unclear specification or a specification that changes in the course of development.

To avoid such problems, it is necessary to have both an overview of the overall system and to know the details necessary to identify potential hazards. However, the likelihood of having a single person in a project or development environment who has both overview and detail knowledge decreases with the size and complexity of the task. Therefore, another approach is to split the problem and assign multiple people to identify and counteract hazards.

ISO26262 - functional safety

This requires tools and procedures that ensure that all the necessary information is available to systematically assess the overall system and that no aspects are overlooked. In addition, it is difficult and expensive to ensure security for a finished product after it has been developed. It is therefore necessary to understand security as a component of the complete planning and development process and to integrate it into this process.

A recommended approach is to learn from methods from functional security. Here, a set of rules already exists that has proven itself in practice. From it, a procedure can be derived whose goal is to identify hazards and deal with them appropriately. [5]

ISO 26262, which defines functional safety in the area of motor vehicles, assumes the use of the V-model. Parallel to this approach, a corresponding process can also be modeled with a focus on security.

To obtain a complete overview of the possible hazards and risks, a hazard and risk analysis must first be performed. In contrast to the procedure in functional security, where the analysis starts with an item such as an electric window regulator, the security analysis begins with the data to be protected. An evaluation of the effects of a threat on integrity, availability and confidentiality is necessary with regard to the likelihood of the order. In functional security, this corresponds to the variables severity and exposure. The controllability considered in functional security is usually low in the security area, since very few users are likely to recognize a security threat or be able to deal with it quickly enough.

Based on the hazard and risk analysis, security goals can now be defined in parallel to the safety goals in functional security, which in turn lead to a specification of the security requirements for the data to be protected. After this concept phase, the technical specification and finally the implementation can follow in development. After completion of the overall system, validation follows, in which it is checked whether the specified security goals have been achieved and all possible risks from the underlying hazard and risk analysis have been dealt with.

Structured procedure ensures functional security

Formalizing this procedure in parallel with the functional security procedure ensures that security does not merely appear as an imprecise non-functional requirement in the specifications, but that documentation exists in which all security requirements are recorded in detail and in a structured manner. In addition, this makes it possible to determine the risk on the basis of which certain measures are to be taken. The systematic approach ensures that not only particularly conspicuous security aspects are examined, but the entire system including its dependencies.

Systematic examination and subsequent validation also require roles such as Security Manager and Security Assessor to perform these activities, as the Safety Manager and Safety Assessor do in functional safety. As a result, the topic of security is not merely managed "on the side" by the developers, but rather there are clear contact persons who follow the topic on a permanent basis. The required overall view with simultaneous consideration of the security-critical details is achieved by first considering the complete system and then the relevant components in separate work steps.

One of the main reasons why systems that initially appear secure turn out to be insecure in practice are subsequent changes that unnoticed either add new hazards or reduce the effectiveness of already implemented treatments of hazards. To prevent such effects, it is necessary to re-examine the overall system for potential hazards when changes are to be made to subsystems or use cases change. In functional security, fault tree analyses are used to model hazards and their probabilities. Analogously, an attack tree analysis can be performed in the area of security. [6]

The attack tree provides a formal method for identifying hazards, evaluating them and documenting them. Since it is possible to look at individual branches instead of the entire tree, clarity is maintained even in complex systems. The introduction of applicable and documented processes in the development of security-relevant products in the automotive environment is particularly advisable in view of the legislation initiated in the USA under the impression of the "Jeep hack". Edward Markey, Senator for the US state of Massachusetts, has proposed the so-called "SPY Car Act of 2015". [7]

Legislative obligations coming

The proposed legislation would require car manufacturers participating in the U.S. market to secure networks and control units in vehicles in such a way that manipulation of the kind described in the example above is not possible. It also contains data protection rules and measures that lead to greater transparency with regard to the security standards required by the manufacturers. Violations of the security regulations are punishable by fines. At about the same time, the Auto ISAC (Information Sharing and Analysis Center) was formed under the umbrella of the Alliance of Automobile Manufacturers, to which German automakers and their U.S. subsidiaries also belong. [8] Its goal is to collect information about potential security threats and make it available to its members. A look at the future of the automobile shows that this makes sense. The German Association of the Automotive Industry (VDA) expects 80% of all new cars worldwide to be delivered with an interface to the Internet as early as 2017. [9]

In summary, it can be said that many methods of functional security can also be usefully applied in the planning and development of systems that are to meet high security requirements, and that they also offer added value compared to development that is disorganized in this respect. Likewise, tools already exist in the area of security that can be usefully embedded in a framework such as that offered by functional security, in order to be able to address the special requirements of security.

LITERATURE REFERENCES
[1] Greenberg, A.: Hackers Remotely Kill a Jeep on the Highway – With Me in It. Stand: 21.07.2015; http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/  (Abgerufen: 12.10.2015)
[2] Koscher, K.; Czeskis, A.; Roesner, F.; P. Shwetak; and Kohno T.; Checkoway, S.; McCoy D.; Kantor, B.; Anderson, D.; Shacham, H.; Savage, S.: Experimental Security Analysis of a Modern Automobile. IEEE Symposium on Security and Privacy, Oakland, CA, USA, 16.-19. Mai 2010
[3] Checkoway, S.; McCoy, D.; Kantor, B.; Anderson, D.; Shacham, H.; Savage, S.; Koscher, K.;Czeskis, A.; Roesner, F.; Kohno, T.: Comprehensive Experimental Analyses of Automotive Attack Surfaces. USENIX Security Symposium, San Francisco, CA, USA, 10.-12. August 2011
[4] Davis, A.: Broadcasting Your Attack: Security Testing DAB Radio in Cars. Black Hat USA 2015; Las Vegas, NV, USA, 1.-6. August 2015
[5] Klauda, M.; Schaffert, M.; Lagospiris, A.; Piel, G.; Kappel, S.; Ihle, M.: Weichenstellung für 2020 – Paradigmenwechsel in der E/E-Architektur. In: ATZelektronik 02/2015, S. 16-22
[6] Schneier, B.: Attack Trees. Stand: 01.12.1999; http://www.drdobbs.com/attack-trees/184411129 (Abgerufen: 12.10.2015)
[7] Markey, E: SPY Car Act of 2015. https://www.congress.gov/bill/114th-congress/senate-bill/1806/all-info (Abgerufen: 12.10.2015)
[8] Auto Alliance: Automakers Announce Initiative to Further Enhance Cyber-security in Autos. http://www.autoalliance.org/index.cfm?objectid=8D04F310-2A45-11E5-9002000C296BA163 (Abgerufen: 12.10.2015)
[9] Wissmann, M.: Auftaktpressekonferenz IAA, Frankfurt, 14.09.2015