Threat Modeling for the Internet of Things

Threat Modeling for the Internet of Things

Eric Vétillard IoT Product Management Group September 2015

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

2


Agenda

1

2

3

4

5

Definitions

Concerns and threats

Some countermeasures

Device and gateway security

Simple checklist

3

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 4

IoT Infrastructure – Main components

Devices Enterprise Apps

Operators

IoT Service

Gateway


Safety vs. Security

Safety

• Protects against malfunction

– Focus on quality

• Principles – Coverage analysis

– Detection, mitigation, reaction

– Simplicity is better

– Redundancy helps

Security

• Protects against attackers

– Focus on robustness

– Several defence layers

• Principles – Coverage analysis

– Detection, mitigation, reaction

– Simplicity is better

– Redundancy helps

5


Attack Surface – Main components

Devices

Operators

Enterprise Apps

Messages

REST API

UI

Connectors

IoT Service

Gateway


Attack Surface – Specific to the Internet of Things

Devices

Operators

Enterprise Apps

Messages

REST API

UI

Connectors

IOT Server

Gateway


Attack Surface – Software Components

Devices

Messages

IoT Service

HW / OS

Framework

Cloud/Server

Framework


In the Press

• In 2015, a few car-related headlines – BMW Connected Drive hack sees 2.2 million cars exposed to remote unlocking (02/02)

– DARPA Hacks GM's OnStar To Remote Control A Chevrolet Impala (02/08)

– US Senate Report: Automakers fail to fully protect against hacking (02/09)

– Hackers take control of Jeep on the highway (August)

• A few unrelated headlines from 2014 – Hackers had struck an unnamed steel mill in Germany (Jan)

– U.S. government probes medical devices for possible cyber flaws (Oct 14)

9

Privacy

Spying

Theft

Remote

Control

Physical

damage

Murder?


In Practice: The BMW Hack

• A lab has been able to remotely open a BMW car

– Reverse engineering the ConnectedDrive feature to identify vulnerabilities

– Exploiting the vulnerabilities identified through an attack path

• The list of vulnerabilities is rather long – The same keys are used in all vehicles

– Some messages are not encrypted

– Configuration data is not tamper-proof

– The crypto algorithm used (DES) is outdated and broken

– The software does not include protection against replay attacks

• One fix: The communication is now encrypted using HTTPS

10


The BMW Hack: Poor Decisions

Poor decision Safety reasoning Security reasoning

Using the same keys Simple process No complex infrastructure

Keys need to be diversified A key needs to be broken on every car

No systematic encryption Only critical messages are encrypted A secure channel protects against reverse engineering

Configuration data no tamper-proof Configuration data integrity is protected by a checksum

Configuration data authenticity is protected by a cryptographic checksum

The vehicle ID is in error messages Simplify diagnosis by having the data A remote attacker doesn’t have the ID, so let’s protect it

Using DES Well-known, fast algorithm DES is broken, let’s mandate AES

No protection against replay attacks Same message, same action A recorded message cannot have the same effect when replayed

11


Threat Analysis Thinking like an attacker

• Very important to validate a design

– Identify the key assets and their flows

– Analyze how security protections can be bypassed

– Consider vulnerabilities as opportunities

• Identify countermeasures to be added to the design

– And loop again on the analysis

12


Attack Surface – Between Devices and IoT Service

Devices

Operators

Enterprise Apps

Messages

REST API

UI

Connectors

IoT Service

Gateway

Thinking like an attacker • Attacking the network link, remotely • Any operation can be attacked • Targeting admin operations can be good • A failure can affect many deployments

Thinking like a defender • IoT framework typically not fully under control • Patching/update must be supported at all levels


Attack Surface – Device Low-level Software

Devices

Operators

Enterprise Apps

Messages

REST API

UI

Connectors

IOT Server

Gateway

Thinking like an attacker • IoT operating systems are not well protected • Older attacks may even work • Maybe that the update mechanism is broken

Thinking like a defender • OS security configuration is important • Patching/update must be supported and secure


Attack Surface – Attacking the Things and Gateways

Devices

Operators

Enterprise Apps

Messages

REST API

UI

Connectors

IOT Server

Gateway

Thinking like an attacker • Things and gateways are physically accessible • I can steal one and reverse engineer it • I can then attack another one • Denial-of-service or tampering may be options

Thinking like a defender • Make devices (at least partly) tamper-proof • Otherwise, make them tamper-evident • Include organizational measures to detect attacks


Compromising a Device

17

Steal data from another

device

Duplicate registration of a device

Activate without

registering

Add device record in the

cloud

Insert device in supply

chain

Add a compromised

device

Modify the device’s software

Modify an existing device

Modify the device’s

hardware

Tamper with the device externally

Replace an existing device

Compromise a device

Steal data from the network

Reconfigure a gateway

Replace device

physically

Replace device in

cloud


Compromising a Device – Focus on Persistent Memory

18

Compromise a device

Tamper with persistent memory

Tamper with data

Tamper with applications

Tamper with system software

Spy on the persistent memory

Disclose data

Disclose applications

Disclose system software



19

Spy on the persistent memory

Disclose data

10 9

Disclose applications



Disclose application

Disclose application data

1

Disclose buffered messages 2

Disclose application data

3

Disclose server verification data 4

Disclose device registration data 5

Disclose device authent data

Disclose authent data



20


Tamper with data


Tamper with native software

2

Modify application data

3

Modify server verification data 4

Modify device registration data

7

Modify a stored application’s code 8

Modify a stored app’s meta-data 9

Add an application

10

Modify system software Tamper with

application data Tamper with

authentication data

6

Modify device authent data

5

Modify device identity

1

Modify buffered messages


Compromising a Device – Server Authentication

21


Tamper with data


Tamper with native software

2

Modify application data

3

Modify server verification data 4

Modify device registration data

7

Modify a stored application’s code 8

Modify a stored app’s meta-data 9

Add an application

10

Modify system software Tamper with

application data Tamper with

authentication data

6

Modify device authent data

5

Modify device identity

1

Modify buffered messages


Oracle Internet of Things Cloud Service

Oracle Confidential – Internal/Restricted/Highly Restricted 22

Device Virtualization

High Speed Messaging

Stream Processing

Endpoint Management

Event Store

IoT Cloud Service

Enterprise Connectivity

Integration Cloud Service

BI & Big Data Cloud Service

Oracle Cloud

Services

Mobile Cloud Service

3rd party apps

Industry Vertical Apps

Enterprise Apps

Cloud or On Premise

Manufacturing

Transportation

Service Mgmt

Asset Mgmt

Firewall

Oracle IoT CS Gateway s/w

3rd party gateway s/w with Oracle IoT Client Library

IoT Cloud Service Client Libraries & Gateway

Indirectly connected

devices

Directly connected

devices


• Security mechanism provisions and manages trust relationships with devices

• Uniquely assigned device identities disallows reuse of security credentials across devices

23

IoT CS Ensures End-to-End Security

Trusted Devices Non-Repudiation

• Enforces authentication prior to communication with any device or enterprise software, enabling proof of origin of data

• Transport level security for all communication to ensure data integrity

• Secure, managed state transitions to control access from devices

• Restricts types of IoT CS operations that device and other principals can perform in a given state

Security Lifecycle


• Security mechanism provisions and manages trust relationships with devices

• Uniquely assigned device identities disallows reuse of security credentials across devices

24

IoT CS Ensures End-to-End Security

Trusted Devices Non-Repudiation

• Enforces authentication prior to communication with any device or enterprise software, enabling proof of origin of data

• Transport level security for all communication to ensure data integrity

• Secure, managed state transitions to control access from devices

• Restricts types of IoT CS operations that device and other principals can perform in a given state

Security Lifecycle


From HTTPS to Man-in-the-Middle

Device

HTTPS

IoT Service


❶ Protecting the keys (even public)

Q What if the attacker modifies my certificate?

A Keep the public key in a Secure Element and have the Secure Element verify the signature.

❷ Checking code authenticity

Q Am I sure that no attacker changed the code?

A Add a cryptographic checksum, and check that the signature comes from the right person.

27

❸ Adding hardware-based security

Q What if the attacker removes my checks?

A Use a secure boot mechanism based on a hardware-based mechanism (TPM, TEE, …).

Protecting against Man-in-the-Middle

Stopping at some point

A The SE’s security has been certified.

A The platform’s security has been certified.


What if it isn’t Possible?

Explore alternatives

– Use tamper-resistant hardware

– Use tamper-evident hardware

– Define security procedures

– Use physical security

Example: in a factory

– Thoroughly check devices (including software) before installing them

– Make sure that every device is covered by a security camera

– Instruct security staff to regularly inspect devices for unusual

28


That Was a Threat Model

• We went through several steps

– Defining assets to be protected

– Defining potential attack means on these assets

– Defining countermeasures, and then countermeasures on the countermeasures

– Thinking about the implementation

• This Threat Modeling process can be made more formal – It is an essential work in an IoT deployment today

– Many vertical/industry/customer-specific aspects to the threat model

29


Putting in Practice in Gateways and Devices

What needs to be done

• Select an IoT infrastructure

– Manage device identity, credentials, lifecycle, communication, policies

• Select a device platform

– Robust hardware / OS / Robust development framework

• Select a trusted hardware – Markets with high – security insurance

needs & unprotected physical devices

How Oracle can help

• Oracle IoT Cloud Service

– State-of-the-art security and strong integration with enterprise services

• Java ME/SE Embedded

– A guarantee of strong and secure apps on your infrastructure

• Java Card – To ensure that your trusted hardware

can evolve over time

30


A few References

• An accessible and useful book on threat analysis

– http://threatmodelingbook.com/

• Details on the BMW hack

– http://m.heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive-2540957.html

• Scaring yourself with potential issues – https://www.dropbox.com/s/oh6xrb7chgoks4j/internetoffails.pdf?dl=0

• A few really good recommendations

– http://www.esecurityplanet.com/network-security/6-tips-for-developing-secure-iot-apps.html

31

http://threatmodelingbook.com/

http://m.heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive-2540957.html



















https://www.dropbox.com/s/oh6xrb7chgoks4j/internetoffails.pdf?dl=0

http://www.esecurityplanet.com/network-security/6-tips-for-developing-secure-iot-apps.html















Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | 32

Summary

• Start by thinking like an attacker

– What is “tempting” in my system? • To who? Why?

– How can my system be attacked? • Which components provide an opportunity

• Then think like a defender

– Identify your weaknesses • What is wrong? What may not be right?

– Find proper countermeasures

• Work with all stakeholders

– For devices, gateways, frameworks • Vet their security and their integration

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |

Threat Modeling for the Internet of Things

Software

Transcript of Threat Modeling for the Internet of Things