Keywords

1 Introduction

A key long-term trend is towards highly automated vehicles and autonomous driving which will have huge impact on road transport in the future. Besides comfort and enabling efficient road transport particular in cities even for people not being allowed or able to drive, another fascinating aspect to achieve a sustainable urban transport system is the chance to reduce considerably the number of vehicles required because they could be called on demand and after a drive do not occupy parking space for a long time because they will continue with their next order. This requires not only a considerable amount of functionality, sensors, actuators and control devices, situation awareness etc. but also integration into a new type of critical infrastructure based on communication between vehicles and vehicles and infrastructure, and regional traffic control centers to optimize traffic as a whole and not just locally in the environment of the vehicle. This connectivity results in additional risks because of security breaches being able to impact safety in a critical manner.

The paper will explain how the coordination of safety and security aspects are resolved in different domains and what is proposed e.g. by the Austrian committee to be taken up in the evolving ISO 26262 [1] standard Ed. 2.0., following related activities and considerations in IEC TC65 Ad hoc Group 1 (“Framework for co-ordination of safety and security”), IEC 62443/ISA 99 [2], ETSI TS 102 941:2012 (Intelligent Transport Systems (ITS); Security; Trust and Privacy Management) [3], SAE J3061 (Cybersecurity Guidebook for Cyber-Physical Automotive Systems) [4] and of the Information Technology-Promotion Agency (IPA, Japan: Approaches for Vehicle Information Security) [5].

2 Safety and Security: A “Systems-of-Systems” Challenge

Combined, these road transport systems form connected “systems-of-systems” with new challenges with respect to safety, security, performance and other dependability requirements. Functional Safety Standards for several domains based on the generic basic safety standard ISO/IEC 61508 [6] have evolved since 2000 when IEC 61508 Ed. 1 was completed. The automotive functional safety standard ISO 26262 Ed. 1.0 [1] was completed and published 2011 (parts 1–9) and 2012 (part 10).

The functional safety standards of the first generation did not tackle the challenges of highly connected “systems-of-systems”. Particularly the arising security issues were not considered at this time in context of safety. Security in an open vehicle system has become a new factor to be considered in system engineering and safety analysis.

IEC 61508 Ed. 2.0 [6], finished 2010, took as first functional safety standard into account that security may impact safety of a system. Therefore it requires consideration in the risk and hazard analysis phase, with accompanying measures to be undertaken in the following phases; particularly security has then to be reflected in the safety manual.

Although security engineering itself is excluded in the description of the scope of the standard, the standard states that it

…requires malevolent and unauthorized actions to be considered during hazard and risk analysis. The scope of the analysis includes all relevant safety lifecycle phases.

The notes definitely address IEC 62443 [2] and ISO/IEC TR 19791 [7] (Part 1, 1.2, k). Security is mentioned in multiple requirements for the safety engineering lifecycle. Security threats need to be considered in the Hazard and Risk analysis:

The hazards, hazardous events and hazardous situations of the EUC and the EUC control system shall be determined under all reasonably foreseeable circumstances (including fault conditions, reasonably foreseeable misuse and malevolent or unauthorized action). This shall include all relevant human factor issues, and shall give particular attention to abnormal or infrequent modes of operation of the EUC. If the hazard analysis identifies that malevolent or unauthorized action, constituting a security threat, as being reasonably foreseeable, then a security threats analysis should be carried out. (IEC 61508, Part 1, 7.4.2.3).

A security threat analysis should be conducted if a security threat is identified as a potential cause for a hazard. For guidance on security risks analysis IEC 61508 refers to the IEC 62443 series (Industrial communication networks—Network and system security) and to ISO/IEC/TR 19791 [7]. It is explicitly noted that malevolent or unauthorized action includes security threats. If security threats have been identified, then a vulnerability analysis should be undertaken in order to specify security requirements (IEC 61508, Part 1, 7.5.2.2).

Finally, Part 3 requires that all details about security should be included in the safety manual: “The following shall be included in the safety manual: (…) Details of any security measures that may have been implemented against listed threats and vulnerabilities.” (Part 3, Annex D 2.4).

Similar concepts are now evolving in IEC 61511, Ed. 2, and ISA TR 840009. Just recently, work on defining harmonized IT security requirements for railway automation was started [8], with the goal to build on the well-known safety certification processes of EN 50129, EN 50159 and integrate security requirements based on IEC 62443 [2].

The initial concept to relate the rigor of security evaluation levels (EALs of Common Criteria) to the potential impact on safety (SIL level) did not find the necessary consensus. Now SLs (Security Levels 1–4) of IEC 62443 [2] seem to be more accepted by industry than the Common Criteria EALs.

In the preparation phase of IEC 61508-3 Ed. 3.0 (Software part), which started Nov. 20–21, 2014, in Frankfurt and was continued in Toulouse March 17/18, 2015, it was decided to look at the ongoing activities in ISO and IEC with respect to “security-aware safety” and to provide more mandatory and informative guidance on a coordinated approach to security in context of functional safety.

In IEC TC65 (Industrial-process measurement, control and automation) considerable concerns arose with respect to the safety impact of security issues in industrial automation systems, since many complex systems of that kind are becoming connected “systems of systems”, particularly by interaction based on wireless connectivity from sensors/actuators to complete plants, grids etc., in maintenance and operations. An Ad hoc Group (AHG1- “Framework towards coordination of safety and security”) was founded to look into the issue and provide recommendations how to handle the co-ordination of security issues in functional safety standards. The kick-off took place Oct. 28/29 2014 at VDE in Frankfurt. In the first meeting overviews were provided by several participants from Europe, Japan, China, US and Australia on ongoing activities and some research projects. E. Schoitsch from AIT provided an overview on several domains and the ARTEMIS projects ARROWHEAD, EMC2 and SESAMO which had in-depth work provided in the field of security-aware (security-informed) safety. The domains were not restricted to IEC standards areas but included also conceptual ideas from railways (EN 50126/28/29 and EN 50159), Airworthiness standards, Nuclear, Off-shore Platforms and Automotive (including pre-information from safety and security workshops e.g. at Fraunhofer IESE, ISSE WS at SAFECOMP 2014 Florence, ICCVE 2014 Vienna, ISSC Boston 2013 etc.).

The overall question to be discussed and recommendations to be given are: “How to manage safety and security—in cooperation, integrated, separately? How to certify critical industrial systems taking industrial Cyber-security into account?”

A short overview on standards’ approaches discussed is provided here:

  • Railways (DIN/VDE just updating EN 50129: Pre-standard DIN V 0831-104)—integrative approach (with IEC 62443, SL 1).

  • Airworthiness Standards: 3 security standards (DO 326A (E 202A) Airworthiness Security Process Specification; DO 355 (ED 204) Information Security Guidance for Continuing Airworthiness; evolving DO YY3 Airworthiness Security Methods and Considerations)—far reaching separation.

  • IEC 62859: Nuclear power plants—fundamental principles defined how to include cybersecurity without impacting safety.

  • IEC 61511/ISA TR 840009 (draft) proposes the Cyber Security Life Cycle to be integrated with Process Safety Management.

  • TC44, Safety of Machinery, electro-technical aspects: separation of safety and security already at requirements level, OEM (integrator) should be the only responsible, not the machinery manufacturer—not appreciated e.g. by ISA or most of the experts.

  • Example from off-shore facility: different safety and security levels at different parts of the facility assessed jointly, to be considered in allocation phase.

  • IEC 62443 (security levels SL 1–4) versus Common Criteria (ISO 15408, Evaluation Assurance Levels EAL 1–7): IEC 62443 the preferred standard for industrial automation.

The proposal from Austria (AIT) to ISO TC22 SC32 WG 08 presented at the ISO 26262 meeting at VDA in Berlin, Jan. 29/30, 2015, was set up by the authors after the kick-off meeting, taking up ideas as well as some concerns pro and con from AHG1 members.

3 Security and Privacy: An Additional Challenge in Open Safety-Related Systems

3.1 Security as Challenge in Open Safety-Related (Critical) Systems

In the past, vehicles were separate units that occasionally interact with other road users in a physical manner only, the responsibility and ability to control the vehicle was totally with the driver (Vienna Convention on Road Traffic, 1968). The “connected car”, may it be with other vehicles or infrastructure in its environment, with highly automated up to autonomous driving changes considerably the original approach to safety and responsibility and occasionally of liability. Now the system is transformed into a system of systems with wireless connectivity. This makes the system to an open system, vulnerable because of multiple access points from inside and outside the system.

Vehicles rely now on seamless data exchange and information flow. The increased connectivity and interaction gives rise to new hazards. Hazards and their causes, faults and vulnerabilities are no longer restricted within a single vehicle, and no longer under full control of the driver. Due to connectivity, vulnerabilities and faults from a single vehicle can propagate further, leading to hazards affecting multiple vehicles at once. A malicious attacker might exploit vulnerabilities or tamper exchanged data, causing hazards on a multiple vehicle level, comparable to mass collisions because of bad weather and road accidents. The change of the infrastructure from a passive system to an active system makes it susceptible to security threats which lead to additional safety hazards. For example, an attack on a traffic control system [9] might cause vehicle crashes. Since connected vehicles form a connected system of systems, safety and security must be ensured not only on the sub-system but also on combined system level.

Experimental analysis demonstrated that particularly such open vehicle systems have increased attack surfaces and potentials, allowing misuse and manipulation of in-car systems. Potential manipulations include controlling vehicle sound system, stopping the engine while the car is still running, or jamming the brakes. The targets of the attacks include Bluetooth connection for user devices, long range connection over cellular networks for telematics, in-car Wi-Fi access points, and maintenance access points. In case situation awareness and V2V and V2I/I2V are becoming an important factor in automated driving and traffic management, the attack surface increases even more. The motivation of the attacker rises considerably because of the wide-spread deployment and public interest, and potentially political impact, as road traffic is an important part of our society and life (somehow a “pr/marketing” effect for the successful attacker). Therefore, from a safety engineering point of view, security breaches are new causes for hazards at the vehicle level. With an open system we cannot regard a vehicle system to be safe unless the security of the system is assessed and assured.

3.2 Privacy and Its Conflict with Safety and Security

Connected and cooperative transportation systems generate and exchange a large amount of data, particularly to receivers not always known to the driver at the moment data are generated and sent, and it is difficult to estimate what could be derived from the “big data” concerning personal issues. While tampering with these data could cause hazards, eavesdropping on the communication and unauthorized access to stored data (or even misinterpreted data used by authorized organizations) could breach participants’ privacy. An arising challenge is the conflict between privacy and safety and security [10]. To ensure safety, vehicles need to make the information related to their position and movement available to all, as often as possible. For security reasons, certain identity information needs to be included in the exchanged data, enabling verification and ensuring data integrity. For privacy, anonymous communication is preferred, and position and movement data should be exchanged as little as possible in order to restrict location tracking and profiling.

General contradictions between different dependability and security attributes are elaborated in [11]. Dependability in this context includes other attributes as well, e.g. reliability, availability, maintainability, performance attributes, sometimes even sustainability, resilience etc. Public acceptance of such systems as described here requires trust in the system, including not only static assurance as done by safety assessment and certification but also run-time assurance because particularly security requires regular updates because of new security breaches arising whereas safety would require rather “never touch a certified system”. Systems-of-systems on the other hand have to be adaptive because of their nature—which also requires a dynamic approach to safety in certain cases (“run-time certification”). These aspects have been described in [12] as an approach evaluated in the EMC2 project. It was also presented as a possible recommendation to the IEC 61508-3, Ed. 3.0 preparation team for the “security-aware safety” challenge. As a result of these considerations and work described, an integrated approach is needed to resolve these conflicts.

4 Consideration of Security Concerns in ISO 26262: A Proposal

Based on the considerations and work presented before, Austria (particularly elaborated by the authors of this paper) prepared a short proposal for the ISO 26262 (ISO TC22 SC32 WG08) standardization meeting at VDA in Berlin. This was particularly under the aspect that many other standardization groups in different domains and the top-level group of TC65 have taken up the challenge arising from increasingly connected rather open systems and systems-of-systems. It was argued that automotive is even more affected than e.g. rather closed systems with smaller attack surface and of less opportunity or motivation to attack like railways. “Connected Car”, “Car on the Internet”, V2V and V2I (vehicle to infrastructure) communication, highly automated driving and—in the end—autonomous driving, are no longer unrealistic developments, so the basic automotive functional safety standard should not ignore these facts when developing Ed. 2.0, which includes many other issues as well, not only busses, trucks and motor cycles.

David Strickland, Chief Administrator for the National Highway Traffic Safety Administration (NHTSA), stated:

…electronics systems are critical to the functioning of modern cars, and are becoming increasingly interconnected, leading to different safety and cyber security risks. (…) With electronic systems assuming safety critical roles in nearly all vehicle controls, we are facing the need to develop general requirements for electronic control systems to ensure their reliability and security.

For a better understanding of our proposal, we look at key elements of ISO 26262. The standard [1] is an adaption of the generic safety standard IEC 61508 [6] for road vehicles. The system development according to ISO 26262 starts with the item definition. An item is a system or a combination of systems that realizes a function at the vehicle level. The next step is the hazard analysis and risk assessment. Results of the hazard analysis are the Safety Goals and the corresponding Automotive Safety Integrity Levels (ASIL). In the functional safety concept the safety goals are assigned to architecture elements and the means are defined (fault detection, fault mitigation, transitioning to a safe state or fault tolerance). Then the system development starts. The Safety Goals in the functional safety concept are refined and the technical safety requirements are specified. In the system design, the technical safety requirements are allocated to hardware and software. Common Criteria (ISO/IEC 15408) [6] is an international standard for information technology security evaluation. It defines the process for the specification, implementation, and evaluation of security-critical, high-assurance systems. Common security requirements on a class of devices or systems can be specified as a Protection Profile. The known use of Common Criteria in automotive domain is its application to the assessment of security of in-car digital devices, but rather not safety allocated parts. In the industrial automation domain and in functional safety standards like IEC 61508 (and related ones), IEC 62443 is preferred since it addresses the system and not only devices.

IEEE 1609.2 [13] specifies methods to secure messages in IEEE 802.11p wireless communication, an amendment to IEEE 802.11 standards for wireless vehicular communications.

A gap analysis shows that there are clearly several gaps in current standards for addressing safety and security of connected vehicles. The standards are fragmented and incomplete, typically assuming that the “blind spots” are covered by others.

For example, in ISO 26262, security as a risk factor is not included. It is explicitly stated that every other system is presumed to be functioning correctly (ISO 26262, Part 3, 7.4.2.2.2) and only malfunctions in the analyzed item are considered. While “reasonably foreseeable misuse” is mentioned in the risk assessment (ISO 26262, Part 3, 7.4.3.7, similar as in IEC 61508, but IEC 61508 is drawing conclusions with respect to malicious misuse as well), it assumes misuse (e.g. a reckless driver) without malicious intention (e.g. a hacker). While the effect of failures on other items is considered through the interface definition, this stops at the vehicle boundary. This means that ISO 26262 views hazards and causes only on a single vehicle level. The cause for a hazard lies in a malfunction of an item. Hazards caused by malicious interactions between items or manipulations from the outside are not considered. In addition, safety-critical communications with external entities is also not considered. Another main issue is that there is a lack of standards addressing safety and security in a joint way. There are no links between different applicable safety engineering standards and security engineering standards in the automotive domain. While there are security requirements for different implementations of V2X, there is no coherent approach for including security on a system of systems level, and rather not in context of safety.

The automotive security standards approaches mentioned in the introduction, namely

  • ETSI TS 102 941:2012 (Intelligent Transport Systems (ITS); Security; Trust and Privacy Management) [3],

  • SAE J3061 (Cybersecurity Guidebook for Cyber-Physical Automotive Systems) [4] and of the

  • Information Technology-Promotion Agency (IPA, Japan: Approaches for Vehicle Information Security) [5],

are focusing only on partial aspects of the issue: ETSI on communication security, SAE and IPA Cyber-security on security aspects, but not on the interplay between both, safety and security.

The automotive industry faces a few unique challenges for transforming research results into standards and economical productions while integrating safety and security. There is a strong separation between OEMs as system integrators and suppliers. The development is distributed. The elements in ISO 26262 such as “Safety element out of context” and “Development Interface Agreement” support this distribution. Standards must support this distributed structure. Not only security but also other aspects like privacy requirements must be considered as a new factor for safety standards. Private and sensitive information such as locations and vehicle routes needs to be protected. Conflicting requirements for privacy, safety, and security (and maybe other dependability requirements) need to be solved in the design phase.

The proposal presentation in Berlin at the last ISO TC22 SC32 WG08 meeting January 29/30, 2015 included not only the motivation, but also the most important examples from the before mentioned TC65 AHG1 kick-off meeting for the “Framework towards coordination of safety and security”.

The proposal left open, of course, the details which approach should be taken, although a more integrated approach was preferred by the proposer (AIT, Austria). The proposal looked like:

  • Cyber-security should be included as an risk factor to be considered during hazard and risk analysis

  • If necessary appropriate security measures should be implemented, e.g. include recommendations for fitting security standards into ISO 26262 Ed. 2.0

  • Include a requirement consolidation phase to resolve potential conflicts and coordinate safety and security requirements

  • Validation of safety concept should consider security concept

  • Security has to be considered throughout the whole (safety) life cycle—recommendations to be included where appropriate

Several countries (e.g. Japan, Germany, France, Austria) reacted positive and some pointed already out which approach they would prefer (e.g. from IEC 62859, Nuclear, which provides detailed requirements for coordinating safety and cybersecurity without affecting the safety requirements (“Safety first”)). There were several objections as well, particularly since some time ago in a meeting the issue was decided not to take up in the safety community because of missing knowledge and experience in security. A small subgroup was defined which should look into the issue again.

Here I want to cite an article from the (UK) Safety-critical Systems Club Newsletter, Sept. 2014, Robert Oates and David Banham (Rolls Royce) on “Safety and Security”: “High-integrity systems engineers will need to expand their skills!”.

5 Conclusions

Connected, highly automated or even autonomous vehicles, communicating with the infrastructure as well, have to be safe and secure. This requires for reasons of public acceptance and licensing standards which allow certification. They have to consider safety not only in an isolated context but under security threats as well. The system “vehicle” is becoming part of a “system of systems”, safety and security need to be integrated at the vehicle level and the system engineering level. This is an enormous challenge and already taken up by other standardization committees for generic as well as domain specific standards, mainly in extending existing, established standards according to these new challenges, sometimes in starting to create complementary standards to cover the gaps. They provide interesting examples for automotive industry.

IEC 61508 Ed 2.0 (2010) has already provided a first approach by integrating security requirements. Security threats are to be considered during hazard analysis in the form of a security threat analysis. If such security threats have been identified, a vulnerability analysis should be undertaken to specific security requirements. Details should be included in the safety manual. In the preparation phase of Ed. 3.0 further requirements and guidelines are planned for a more thorough treatment of safety and security coordination.

In the Avionics domain, the approach was to impose special conditions on type certificates for specific aircrafts. Now Standards are developed for the specification of processes, methods and instructions for continued airworthiness security.

Railways plan to integrate IEC 62443 security requirements into the domain specific safety standards (EN 50129, EN 50159) so that only one certification for both concerns (“security aware/informed” safety) should be required for lower SLs (security levels).

The automotive industry needs to define a standardization approach which combines safety and security engineering. Conflicting requirements for privacy, safety and security (and maybe other dependability attributes) need to be resolved at design time. Security concerns can be integrated in ISO 26262 for a combined safety and security standard, or ISO 26262 can be coupled to one or more corresponding security standards with a definition of a joint process on system level. There are several options which have to be discussed among stakeholders, but the issue has to be taken up seriously.