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

  • Published on
    19-Jul-2018

  • View
    214

  • Download
    2

Embed Size (px)

Transcript

  • 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: https://www-fars.nhtsa.dot.gov

    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: https://www.youtube.com/watch?v=Yw5wtWAj3Mc

    https://www.youtube.com/watch?v=Yw5wtWAj3Mc

  • Software 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

    http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

    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: https://www.defcon.org/html/links/dc-archives/dc-23-archive.html

  • 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/

    So how was the Tesla hacked?

    16

    This Keen Laboratories hack was the second publicised attack on a Tesla

    https://www.wired.com/2015/08/researchers

    -hacked-model-s-teslas-already/

    https://electrek.co/2016/09/27/tesla-releases-more-details-on-the-chinese-

    hack-and-the-subsequent-fix/

  • 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 https://www.securecoding.cert.org/confluence/display/s

    eccode/Top+10+Secure+Coding+Practices

    https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practiceshttps://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

  • Computer 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: https://www.securecoding.cert.org

    IPA/SEC p12~ https://www.ipa.go.jp/files/000055265.pdf

    https://www.securecoding.cert.org/confluence/display/seccode/BB.+DefinitionsBB.Definitions-vulnerabilityhttps://www.securecoding.cert.org/confluence/display/seccode/MSC00-C.+Compile+cleanly+at+high+warning+levelshttps://www.securecoding.cert.org/confluence/display/seccode/MSC00-C.+Compile+cleanly+at+high+warning+levelshttps://www.securecoding.cert.org/confluence/display/seccode/MSC00-C.+Compile+cleanly+at+high+warning+levelshttps://www.securecoding.cert.org/confluence/display/seccode/MSC00-C.+Compile+cleanly+at+high+warning+levelshttps://www.securecoding.cert.org/confluence/display/cplusplus/VOID+Compile+cleanly+at+high+warning+levelshttps://www.securecoding.cert.org/confluence/display/cplusplus/VOID+Compile+cleanly+at+high+warning+levelshttps://www.securecoding.cert.org/confluence/display/cplusplus/VOID+Compile+cleanly+at+high+warning+levelshttps://www.securecoding.cert.org/https://www.securecoding.cert.org/https://www.ipa.go.jp/files/000055265.pdfhttps://www.ipa.go.jp/files/000055265.pdf

  • Architect 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

    https://www.securecoding.cert.org/confluence/display/seccode/STR02-C.+Sanitize+data+passed+to+complex+subsystemshttps://www.securecoding.cert.org/confluence/display/seccode/STR02-C.+Sanitize+data+passed+to+complex+subsystemshttps://www.securecoding.cert.org/confluence/display/seccode/STR02-C.+Sanitize+data+passed+to+complex+subsystems

  • Practice 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 you...

Recommended

View more >