Download - Software Security for the Connected Car - IPA · Software Security for the Connected Car ... Automated Parking Blind-spot warning ... C++ committee Member of the working

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



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


32675 Fatalities


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





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 & Valasek’s 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 attacker’s mindset considers every piece of technology

that interacts with the outside world a potential entry point.

From Miller & Valasek’s 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





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


The changing face of automotive software



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

`


TLS1_HB_RESPONSE 1 Byte

Heartbeat sent to victim:

Victim’s response:

Heartbeat

28

SSLv3 Record:

Length: 4 Bytes

Heartbeat Message:


TLS1_HB_REQUEST 65535 Bytes

SSLv3 Record:

Length: 65535 Bytes

Heartbeat Message:


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

CERT’s 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+Practices

https://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

CERT’s 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-vulnerability

https://www.securecoding.cert.org/confluence/display/seccode/MSC00-C.+Compile+cleanly+at+high+warning+levels




https://www.securecoding.cert.org/confluence/display/cplusplus/VOID+Compile+cleanly+at+high+warning+levels



https://www.securecoding.cert.org/

https://www.securecoding.cert.org/



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


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]


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


37

外部に渡すデータは渡した先で問題を起こさないように加工する

https://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]


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


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 (cve.mitre.org)

OSVDB – Open Source Vulnerability Database (osvdb.org)

SANS Institute - SysAdmin, Audit, Network, Security (www.sans.org)

OWASP - Open Web Application Security Project (www.owasp.org)

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 (http://cwe.mitre.org), 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/SEC共通脆弱性タイプ一覧CWE概説：

https://www.ipa.go.jp/security/vuln/CWE.html

http://cwe.mitre.org/




There 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 2は、セーフティを目的にするMISRA 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ガイドラインに、安全な

コード実装のための新しいルールを追加

セキュアでないコーディングの例とその取り扱いルール

http://www.fuji-setsu.co.jp/files/MISRA_C_2012_AMD1.pdf





IPA/SEC 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

http://www.ipa.go.jp/sec/softwareengineering/std/emb-escr.html

IPA/SEC ESCR は適正なコーディン

グの作法を実施するための品質規範となる品質特性を焦点にして策定





CERT® 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 コーディングスタンダード

https://www.jpcert.or.jp/sc-rules/






CERT C

47

CERT C コーディングスタンダード






CERT C : Memory Management

48

CERT C メモリ管理

https://www.jpcert.or.jp/sc-rules/c-mem00-c.html











Allocate sufficient memory for an object

CERT C : Rule MEM35-C

49

The parameter has not

been checked!

MEM35-C. オブジェクトに対して十分なメモリを割り当てる











Do 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) : https://www.jpcert.or.jp/sc-rules/c-exp00-c.html

https://www.jpcert.or.jp/sc-rules/c-exp00-c.html









Ensure a null pointer is not de-referenced

Non compliant:

Compliant :

CERT C : Rule EXP34-C

52

What if malloc

returns NULL?

EXP34-C.

null ポインタを参照しない










Checking Compliance

53

ツールでルール違反を自動検出

http://www.fuji-setsu.co.jp/products/LDRA/TBsecure.html





MEM35-C : Heartbleed Bug

54

MEM35-C. オブジェクトに対して十分なメモリを割り当てる

http://www.jpcert.or.jp/sc-rules/c-mem35-c.html

ツールでルール違反を自動検出









Secure 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 Analysisについて：以下資料P24～

http://www.fuji-setsu.co.jp/files/LDRA_TechnicalDescription.pdf





Structural 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





Secure Coding

1

2

3

4

5

67


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?

[email protected]

Contact Us

70 富士設備 http://www.fuji-setsu.co.jp/products/LDRA

Download - Software Security for the Connected Car - IPA · Software Security for the Connected Car ... Automated Parking Blind-spot warning ... C++ committee Member of the working

Top Related