Convergence of Safety, Systems & Cybersecurity Bill StClair, Director, LDRA, US Operations

Convergence of Safety, Systems & Cybersecurity Bill StClair, Director, LDRA, US Operations

Agenda Nexus of Safety and Cybersecurity Separation and Connectivity Trends in Aerospace Cybersecurity Isn t Security Testing Different?

Nexus of Safety and Cybersecurity 3

Security as a Safety Issue For LDRA s core markets, Safety and Security can be considered as one: Sicherheit IEC 61508 adopts a risk-based approach introduces safety integrity levels [SILs] for specifying the target level of safety integrity for the safety functions to be implemented by the E/E/PE safety-related systems International standard IEC 61508-3 Functional safety of electrical/electronic/programmable electronic safety-related systems ISO 26262 provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved International standard ISO 26262 Road vehicles Functional safety Part 6: Product development at the software level If your Jeep is driven into a tree by a hacker, that is a SAFETY issue! 4

The Changing Face of Automotive Software Until recently, automotive embedded application were static, fixed function, device specific implementations Isolation has been a sufficient guarantee of security for many years, and practices and processes have relied on that status And then http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ 5

The Connected World of the IIoT Until recently, SCADA systems and the devices they controlled had little or no connection to the outside world Isolation has been a sufficient guarantee of security for many years, and practices and processes have relied on that status And then http://www.bbc.co.uk/news/technology-15817335 http://www.bbc.co.uk/news/technology-30575104 6

And so on Transportation Medical http://www.computerworld.com/article/2473402/cybercrime-hacking/pacemakerhacker-says-worm-could-possibly--commit-mass-murder-.html#tk.drr_mlt 7

How was the Jeep hacked? From Miller & Valasek s paper Remote Exploitation of an Unaltered Passenger Vehicle : Remote Attack Surface The following table is a list of the potential entry points for an attacker. While many people only think of these items in terms of technology, someone with an attacker s mindset considers every piece of technology that interacts with the outside world a potential entry point. In order to access the security critical systems, the hackers needed an entry point, and a vulnerability to get access from that entry point 8

How was the Jeep hacked? From Miller & Valasek s paper Remote Exploitation of an Unaltered Passenger Vehicle : there are no CAN bus architectural restrictions, such as the steering being on a physically separate bus. If we can send messages from the head unit, we should be able to send them to every ECU on the CAN bus. This combination of automotive networks (e.g. CAN) and connectivity compromises traditional assumptions 9

Separation and Connectivity 10

Separation through Hardware Separation of these different domains can be achieved in several different ways This example shows how separation is achieved through hardware in the Tesla Model S SOURCE: https://www.defcon.org/html/links/dc-archives/dc-23-archive.html 11

So how was the Tesla hacked? https://electrek.co/2016/09/27/tesla-releases-more-details-on-the-chinesehack-and-the-subsequent-fix/ This Keen Laboratories hack was the second publicised attack on a Tesla Infotainment system accessed via a vulnerability in the WebKit based browser, and manipulated via a malicious Wi-Fi hotspot Access to the instrument cluster via vulnerabilities in its Linux OS allowed activation of doors, windows, and wipers but provided no access to the safety critical braking system That required them to replace the gateway software with their own.perhaps using a privilege escalation vulnerability highlighted by Rogers and Mahaffey in the earlier attack? https://iotsecurityfoundation.org/is-the-tesla-model-s-robust-against-hackers/ https://www.wired.com/2015/08/researchers -hacked-model-s-teslas-already/ 12

How About Separation in Software? 13

Scales up to Automotive Virtualization promises both a reduced processor count, and domain separation in one highly configurable package (from Lynx O/S) https://hal.archives-ouvertes.fr/hal-01291361/document 14

Not just Lynx. https://www.windriver.com/products/operating-systems/virtualization/ https://www.ghs.com/products/rtos/integrity.html http://www.qnx.com/content/qnx/en/products/hypervisor/ 15

But No Guarantee As the Tesla example illustrates, separation is important but in isolation it is no guarantee of impenetrability Cyber-security depends on vigilance in every part of the development process, including Least Privilege development principles Secure coding techniques Security focused testing THAT S where LDRA comes in. 16

Significant Components in a Security Machine! Safety Dynamic Testing Hardware Security MILS (Least Privilege) Minimization of attack surface Security Hardened OS Boot Image Integrity Verification Domain Separation Secure Coding 17

Separation Technologies Separation Technologies have a big part to play. However, they are no silver bullet. The isolation of hypervisor domains is restricted only to the processor implementing the virtualization. Other bus masters in the system, such as DMA engines and Graphics Processing Units (GPUs), can bypass the protections provided by the hypervisor For them to be useful, there needs to be application code communicating BETWEEN the domains And hypervisors themselves are not infallible http://venom.crowdstrike.com/ 18

Trends in Aerospace Cybersecurity 19

As of Today

Aerospace Risk Management Process 21

Aerospace Security 22

23 Overview of MIL-STD-882E [MIL-STD-882E] identifies the Department of Defense (DoD) Systems Engineering (SE) approach to eliminating hazards, where possible, and minimizing risks where those hazards cannot be eliminated. The standard defines the system safety approach, including security, to be used in mitigating potential software contributions to functional hazards. From the normative text: 3.2.46, System/subsystem specification. The system-level functional and performance requirements, interfaces, adaptation requirements, security and privacy requirements, computer resource requirements, design constraints (including software architecture, data standards, and programming language), software support, precedence requirements, and developmental test requirements for a given system.

24 MIL-STD-882E System Safety Process

25 MIL-STD-882E Risk Assessment

26 MIL-STD-882E Risk Assessment

27 MIL-STD-882E Risk Assessment

28 MIL-STD-882E Software Assessment

SwCl Req. Arch. Des. Code Test ID Test 178C Req. Arch. Des. Code Test ID Test 29 MIL-STD-882E SwCl vs 178C Levels 1 A 2 B 3 C 4 D 5 E Legend: SwCl = Software Control Category Req. = Requirements Analysis Arch. = Architecture Analysis Des. = Design Analysis Code = Code Analysis Test = Safety-Specific Testing ID Test = In-depth Safety-Specific Testing 178C = DO-178C Software Level

Project Standards are Critical: Not Just Industry Standards Requirements Standards Safety Functional Software Hardware Design Standards System Software Hardware Coding Standards Software Hardware 30

Isn t Security Testing Different? 31

Traditional Security Market - Testing Reactive Coding Executable Testing No Guidelines No Risk Mitigation Mostly Agile Not Dependable Not Trustworthy (Malicious Logic) Not Resilient Performance Tests Penetration Tests Load Tests Functional Tests 32

Prevention is Better than Cure Proactive Process remains same, additional considerations need to be addressed Coding Testing Executable Security Risk Assessment Drives Security Guidelines Agile/V/Waterfall Code Reviews Functional Tests Structural Coverage (No Malicious Logic) Security Tests Dependable Trustworthy Resilient 33

Best Prevention for Safety, Systems & Cybersecurity Convergence- LDRA s PCD Stack for Aerospace