Software Security for the Connected Car - IPA ? Software Security for the Connected Car ... Automated

  • Published on

  • View

  • Download


Software Security for the Connected Car Ian Hennell, Operations Director Agenda 2 Cars are Getting Safer The Changing Face of Automotive Software Principles of Least Privilege and ISO 26262 Summary and Conclusions Secure Coding 1 2 3 4 5 Agenda 3 Cars are Getting Safer The Changing Face of Automotive Software Principle of Least Privilege and ISO 26262 Summary and Observations Secure Coding 1 2 3 4 5 Is software in cars a problem? 4 Cars are Getting Safer! 1994 17.3 Fatalities per Billion Miles 2014 11.4 Fatalities per Billion Miles 2004 14.8 Fatalities per Billion Miles 2024? 5 Statistics for the US. SOURCE: 40716 Fatalities 2358 Billion Miles Travelled 42836 Fatalities 2890 Billion Miles Travelled 32675 Fatalities 2890 Billion Miles Travelled Advances across all aspects of design 6 SOURCE: is the Champion of Safety! 7 Automatic emergency braking (AEB) Automated Parking Blind-spot warning (BSW) Rear cross-traffic warning Rear Automatic Emergency Braking (Rear AEB) Lane-departure warning (LDW) Lane-keeping assist (LKA) Adaptive Cruise Control Electronic Stability Control Adaptive Headlamps Tyre Pressure Warning (TPWS) Anti-Lock Braking (ABS) Forward-collision warning (FCW) The Civil Aerospace Industry is justly proud of its safety record. But how fair is the comparison with the automotive sector? Boeing 787: 6.5 million lines of code Flown by highly trained, skilled individuals Highly controlled airspace, monitored via a cohesive international system Modern Car: > 20 million lines of code Driven by Joe Public On the open road, with no overriding monitoring or guidance system In short, the automotive software industry is performing brilliantly. But there is a new challenge to face Road v Sky? 8 Agenda 9 Cars are Getting Safer The Changing Face of Automotive Software Principle of Least Privilege and ISO 26262 Summary and Conclusions Secure Coding 1 2 3 4 5 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 10 From Miller & Valaseks paper Remote Exploitation of an Unaltered Passenger Vehicle: In order to access the security critical systems, the hackers needed an entry point, and a vulnerability to get access from that entry point How was the Jeep hacked? 13 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 attackers mindset considers every piece of technology that interacts with the outside world a potential entry point. From Miller & Valaseks paper Remote Exploitation of an Unaltered Passenger Vehicle: This combination of automotive networks (e.g. CAN) and connectivity compromises traditional assumptions How was the Jeep hacked? 14 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. Separation of different domains can be achieved in several different ways This example shows how separation is achieved through hardware in the Tesla Model S Separation through Hardware 15 SOURCE: 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? So how was the Tesla hacked? 16 This Keen Laboratories hack was the second publicised attack on a Tesla 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 What can be done? 17 Agenda 18 Cars are Getting Safer The Changing Face of Automotive Software Principle of Least Privilege and ISO 26262 Summary and Conclusions Secure Coding 1 2 3 4 5 ISO 26262 to the rescue? ISO 26262 Sub-system ASILs No Separation? ASILs mean nothing? ISO 26262 Compromised? 19 Provides An automotive-specific approach to determine integrity levels (ASIL) Each Subsystem assigned ASIL proportionate to risk But if high risk applications can be compromised by low risk applications Are all ASILs effectively reduced to the lowest in the system? What is Least Privilege? 20 40-year-old concept (Saltzer and Schroeder) Per-subject and per-resource flow-control granularity No subject needs to be given more access than that required to allow the desired flows Saltzer, J.H. and Schroeder, M.D. The Protection of Information in Operating Systems. Proceedings of the IEEE 63(9):1278-1308. 1975 Multiple Independent Levels of Security 21 MILS system architecture is founded on the principle of Least Privilege Employs one or more separation mechanisms Separation Kernel Partitioning Communications System Physical Separation Maintains assured data and process separation. Authorizes information flow only within a particular security domain or through trusted monitors Access control guards Downgraders Crypto devices Such an approach restores a high level of separation between sub-systems with differing ASILs MILS principles address the compromises inherent in automotive networks by establishing separation between different domains But they do not address vulnerabilities within each sub-system The down side of connectivity is that automotive systems are now vulnerable to the aggressive attacks witnessed by so many other industries Sub-system vulnerabilities 22 Agenda 23 Cars are Getting Safer The changing face of automotive software Principle of Least Privilege and ISO 26262 Summary and Conclusions Secure Coding 1 2 3 4 5 Secure Coding The Challenge of Secure Code Development Distributed Denial of Service (DDoS) attack Mirai Source Code 25 The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library The bug was a missing bounds check before a call to memcpy() that uses non-sanitized user input as the length parameter. An attacker can trick OpenSSL into allocating a 64KB buffer, copy more bytes than is necessary into the buffer, send that buffer back, and thus leak the contents of the victim's memory, 64KB at a time Heartbleed Bug 26 Request: Response: Heartbeat 27 SSLv3 Record: Length: 4 Bytes Heartbeat Message: Type Length Payload Data TLS1_HB_REQUEST 1 Byte SSLv3 Record: Length: 4 Bytes ` Type Length Payload Data TLS1_HB_RESPONSE 1 Byte Heartbeat sent to victim: Victims response: Heartbeat 28 SSLv3 Record: Length: 4 Bytes Heartbeat Message: Type Length Payload Data TLS1_HB_REQUEST 65535 Bytes SSLv3 Record: Length: 65535 Bytes Heartbeat Message: Type Length Payload Data TLS1_HB_RESPONSE 65535 Bytes secret data, passwords, Dealing with such issues requires security to be considered throughout the software design process, along with other metrics such as performance, cost and power What is Secure Code? 29 Dependable Survivable Trustworthy LDRA has ample expertise to advise on how to do that LDRA Standards Experience & Pedigree 30 Professor Mike Hennell Bill St Clair Shan Bhattacharya Member of SC-205 / WG-71 (DO-178C) formal methods subgroup Member of MISRA C committee and MISRA C++ committee Member of the working group drafting a proposed secureC annex for the C language definition (SC 22 / WG14) Member of SC-205 / WG-71 (DO-178C) Object Oriented Technology subgroup Member of FACE Consortium Technical Working Group Conformance Verification Matrix Subcommittee Member of FACE Consortium Integration Workshop Standing Committee Cybersecurity Assurance Testing Task Force LDRA Standards Experience & Pedigree 31 Dr Clive Pygott Liz Whiting Chris Tapp Member of ISO software vulnerabilities working group (SC 22 / WG 23) Member of MISRA C++ committee Member of the working group drafting a proposed secureC annex for the C language definition (SC 22 / WG14) Member of MISRA C committee language definition Chairman of MISRA C++ committee Member of MISRA C committee language definition Secure Coding CERTs Top 10 Secure Coding Practices Emergency Readiness Team CERT 33 Validate Inputs Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05] Heed compiler warnings Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A]. Use static and dynamic analysis tools to detect and eliminate additional security flaws CERTs Top 10 Secure Coding Practices 34 Source: IPA/SEC p12~ and design for security policies Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set Keep it simple Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex CERTs Top 10 Secure Coding Practices 35 Default deny Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer 74, Saltzer 75] Adhere to the principle of least privilege Every process should execute with the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges [Saltzer 74, Saltzer 75] CERTs Top 10 Secure Coding Practices 36 Sanitize data sent to other systems Sanitize all data passed to complex subsystems [C STR02-A] such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem CERTs Top 10 Secure Coding Practices 37 defence in depth Manage risk with multiple defensive strategies, so that if one layer of defence turns out to be inadequate, another layer of defence can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment [Seacord 05] CERTs Top 10 Secure Coding Practices 38 Use effective quality assurance techniques Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions [Seacord 05] Adopt a secure coding standard Develop and/or apply a secure coding standard for your target development language and platform CERTs Top 10 Secure Coding Practices 39 Secure Coding Standards and References The databases that track known security vulnerabilities and exposures are another source of help. For many years now, all recorded exploits and vulnerabilities have been captured in a variety of databases, including: CVE Common Vulnerabilities & Exposures ( OSVDB Open Source Vulnerability Database ( SANS Institute - SysAdmin, Audit, Network, Security ( OWASP - Open Web Application Security Project ( Tracking Security Vulnerabilities 41 By analyzing the specific vulnerabilities and exploitations in the previous set of databases, it has been possible to trace these to common weaknesses in code and/or applications CWE (, targeted to developers and security practitioners, is a formal list of software weaknesses that: Serves as a common language for describing software security weaknesses in architecture, design, or code Serves as a measuring stick for software security tools targeting these weaknesses Provides a common baseline definition for weakness identification, mitigation, and prevention efforts Common Weakness Enumeration - CWETM 42 IPA/SECCWE is a common misconception that MISRA is just for safety-related not for security-related projects In April 2016, MISRA released MISRA C:2012 Addendum 2: Coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 C secure coding rules It shows which of the 46 C Secure rules are covered by the MISRA C:2012 guidelines There are no additional guidelines within the document just tables to identify which of the existing guideline(s) cover the issues related to each C Secure rule MISRA C:2012 43 MISRA C:2012 Addendum 2MISRA C ISO/IEC TS 17961:2013 C MISRA C:2012 Amendment 1 Additional security guidelines for MISRA C:2012 Includes 14 additional guidelines, to improve the coverage of the security concerns highlighted by the ISO C Secure Guidelines, particularly in the use of "untrustworthy data MISRA safe and secure MISRA C:2012/AMD1 44 MISRA C:2012 Amendment 1 MISRA ESCR 45 The IPA/SEC ESCR language guide to coding practices was formulated by the Software Engineering Centre of the Japanese Information-Technology Promotion Agency The coding practices are designed to assist in the production of consistently high-quality source code, regardless of the skills of individual programmers The guide focuses on attributes that enable a quality model to be met by enforcing corresponding coding conventions, drawing on: Japanese experience of software development for embedded systems Best practices from MISRA C:2004 Indian Hill C style and coding standards GNU coding standards IPA/SEC ESCR C Coding Standard, Second Edition 98 Rules for developing safe, reliable and secure systems By Robert C. Seacord The CERT C Coding Standard 46 CERT C C 47 CERT C C : Memory Management 48 CERT C sufficient memory for an object CERT C : Rule MEM35-C 49 The parameter has not been checked! MEM35-C. not access freed memory Non compliant: Compliant: CERT C : Rule MEM30-C 50 The memory that this pointer points to, has been freed! MEM30-C. CERT C : Expressions 51 (EXP) : a null pointer is not de-referenced Non compliant: Compliant : CERT C : Rule EXP34-C 52 What if malloc returns NULL? EXP34-C. null Compliance 53 : Heartbleed Bug 54 MEM35-C. Coding Testing Secure Code Following the Top 10 Secure Coding Practices will mean adding additional defensive software But there is a need to test that this defensive software works However, how do we know when we have done enough testing? Test 57 It helps define how much testing is enough testing It is mandated by the ISO 26262 standard The more coverage we obtain, the higher will be the confidence that no code remains that will do something unexpected when it is deployed Why Structural Coverage? 58 With Structural coverage, we can easily see which parts of the code have not been tested Any code that is not executed is potentially a serious risk Visualisation 59 Depending on the ASIL of the project, there are different types of Structural Coverage that need to be achieved, for example for ASIL D: Statement coverage Branch decision coverage Modified Condition / Decision Coverage (MC/DC) Structural Coverage 60 -Dynamic Coverage AnalysisP24 Coverage can be measured via: System testing, where the whole application is executed and exercised with many combinations of inputs. As the code executes, the structural coverage is captured. Some defensive code will be inaccessible during normal operation, so it is generally impossible to get 100% coverage. (Method recommended in the Top 10 Secure Coding Practices) Unit Testing, which takes the code out of its usual context and creates a harness to call it. Inputs are specified, and outputs are verified. As the code executes, the structural coverage can be captured. Unit testing is often used to obtain coverage for the parts not exercised by the system test. Measurement Methods 61 Dynamic Analysis 62 Unit testing can complement the coverage Unit Testing 63 Combined Coverage 64 Fuzz Testing 65 Most of the dynamic testing discussed so far aims to show an ability to fulfil requirements CERT recommends that Fuzz testing is also deployed, which involves providing invalid, unexpected or random data as inputs The aim is to provide evidence of robustness, whether the application is under hostile attack, or simply handling an unusual set of circumstances. Fuzz Testing 66 Agenda Cars are Getting Safer The Changing Face of Automotive Software Principle of Least Privilege and ISO 26262 Summary and Conclusions Secure Coding 1 2 3 4 5 67 Summary and Conclusions 68 Automotive Software has a safety record to be proud of. However, the advent of integrated car networks and the connected car places a new emphasis on security, which is essential to retaining that record. Adequate separation between different domains is essential if ISO 26262 is to remain relevant, especially with regards to applications of differing ASILs. The adherence to Least Privilege principles will help make that happen. Connected systems need multiple measures to become secure the Swiss Cheese model Secure coding practices and the automation of validation, verification and test all go to ensure that secure code can be developed and proven as cost effectively as possible. Q A & Any Questions 69 .com Need more information? Contact Us 70