Vetillard Oracle Threatmodel

Threat Modeling for the Internet of Things
Eric Vtillard
IoT Product Management Group
September 2015
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 Oracles products remains at the sole discretion of Oracle.
Copyright 2014 Oracle and/or its affiliates. All rights reserved. |
Agenda
1
Definitions
Concerns and threats
Some countermeasures
Device and gateway security
Simple checklist
IoT Infrastructure Main components
IoT Service
Devices
Enterprise Apps
Gateway
Operators
Copyright 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential Internal
Safety vs. Security

Safety
Security
Protects against malfunction
Protects against attackers
Focus on quality
Principles
Coverage analysis
Detection, mitigation, reaction
Simplicity is better
Redundancy helps
Focus on robustness
Several defence layers
Principles
Coverage analysis
Detection, mitigation, reaction
Simplicity is better
Redundancy helps
Attack Surface Main components

Connectors
Messages
IoT Service
Devices
REST
API
Enterprise Apps
UI
Gateway
Operators
Attack Surface Specific to the Internet of Things

Connectors
Messages
IOT Server
Devices
REST
API
Enterprise Apps
UI
Gateway
Operators
Attack Surface Software Components
Messages
Devices
IoT Service
Framework
Framework
HW / OS
Cloud/Server
In the Press
Privacy
In 2015, a few car-related headlines
BMW Connected Drive hack sees 2.2 million cars exposed to remote unlocking (02/02)
Spying
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)
Remote
Control
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)
Theft
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 doesnt have the ID,

so lets protect it
Using DES
Well-known, fast algorithm
DES is broken, lets 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

Messages
Devices
Connectors
Attacking the network link, remotely
Any operation can be attacked
IoT Service
Enterprise Apps
Targeting admin operations can be good
A failure can affect many deployments
REST
UI
API Thinking like a defender
IoT framework typically not fully under control
Patching/update must be supported at all levels
Gateway
Operators
13
Attack Surface Device Low-level Software

IoT operating systems are not well protected
Older attacks may even work
Connectors
Messages
Maybe that the update mechanism is broken
Devices
Thinking like a defender

IOT Server
OS security configuration is important
Patching/update must be supported and secure
REST
UI
API
Enterprise Apps
Gateway
Operators
14
Attack Surface Attacking the Things and Gateways

Connectors
Messages
IOT Server
Devices
Gateway
Enterprise Apps
Thinking like
an attacker
REST
Things and
gatewaysUIare physically accessible
API
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
Operators
Otherwise,
make them tamper-evident
Include organizational measures to detect attacks
16
Compromising a Device
Compromise
a device
Add a
compromised
device
Duplicate
registration
of a device
Steal data
from another
device
Activate
without
registering
Steal data
from the
network
Insert device
in supply
chain
Replace an
existing
device
Add device
record in the
cloud
Modify an
existing
device
Modify the
devices
software
Replace
device
physically
Replace
device in
cloud
Modify the
devices
hardware
Reconfigure a
gateway
Tamper with
the device
externally
17
Compromising a Device Focus on Persistent Memory
Compromise
a device
Spy on the
persistent memory
Disclose
data
Disclose
Disclose system
applications
software
Tamper with
persistent memory
Tamper
with data
Tamper with
applications
Tamper with
system software
18

Spy on the
persistent memory
Disclose
data
Disclose
application data
Disclose
applications
Disclose
authent data
Disclose buffered
messages
Disclose server
verification data
Disclose
application data
Disclose device
registration data
Disclose system
software
10
Disclose
application
Disclose system
software
Disclose device
authent data
19

Tamper with
persistent memory
Tamper
with data
Tamper with
application data
Tamper with
applications
Tamper with
authentication data
Modify buffered
messages
Modify server
verification data
Modify
application data
Modify device
registration data
Tamper with
native software
10
Modify a stored
applications code
Modify system
software
Modify a stored
apps meta-data
9
Add an application
Modify device
identity
6
Modify device
authent data
20
Compromising a Device Server Authentication

Tamper with
persistent memory
Tamper
with data
Tamper with
application data
Tamper with
applications
Tamper with
authentication data
Modify buffered
messages
Modify server
verification data
Modify
application data
Modify device
registration data
Tamper with
native software
10
Modify a stored
applications code
Modify system
software
Modify a stored
apps meta-data
9
Add an application
Modify device
identity
6
Modify device
authent data
21
Oracle Internet of Things Cloud Service

IoT Cloud Service
Client Libraries & Gateway
Indirectly
connected
devices
Device
Virtualization
Oracle IoT CS
Gateway s/w
3rd party gateway

s/w with Oracle
IoT Client Library
Directly
connected
devices
IoT Cloud Service
Event Store
High Speed
Messaging
Stream Processing
Endpoint
Management
Enterprise
Connectivity
Oracle
Cloud
Services
BI & Big Data

Cloud Service
Integration Cloud
Service
Enterprise
Apps
Cloud or On Premise
Manufacturing
Service
Mgmt
3rd party
apps
Industry
Vertical Apps
Firewall
Mobile Cloud
Service
Transportation Asset Mgmt
Copyright 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential Internal/Restricted/Highly Restricted
22
IoT CS Ensures End-to-End Security
Trusted Devices
Security mechanism
provisions and manages
trust relationships with
devices
Uniquely assigned device
identities disallows reuse
of security credentials
across devices
Security Lifecycle
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
23
IoT CS Ensures End-to-End Security
Trusted Devices
Security mechanism
provisions and manages
trust relationships with
devices
Uniquely assigned device
identities disallows reuse
of security credentials
across devices
Security Lifecycle
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
24
From HTTPS to Man-in-the-Middle
HTTPS
Device
IoT
Service
25
From HTTPS to Man-in-the-Middle
HTTPS
Device
IoT
Service
26
Protecting against Man-in-the-Middle

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.
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, ).
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.
Stopping at some point

A The SEs security has been certified.
A The platforms security has been certified.
27
What if it isnt 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
How Oracle can help
Select an IoT infrastructure
Oracle IoT Cloud Service
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
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-sConnectedDrive-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-iotapps.html
31
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
2014 Oracle
and/or
its affiliates.
All rights
reserved.
Copyright
2015,Oracle
and/or
its affiliates.
All rights
reserved.
| |
32
Copyright 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential Internal/Restricted/Highly Restricted
33

Vetillard Oracle Threatmodel

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Vetillard Oracle Threatmodel

Diunggah oleh

Hak Cipta:

Format Tersedia

Threat Modeling for the Internet of Things

Safe Harbor Statement

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

Concerns and threats

Device and gateway security

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

IoT Infrastructure Main components

Safety vs. Security

Protects against malfunction

Protects against attackers

Attack Surface Main components

Attack Surface Specific to the Internet of Things

Attack Surface Software Components

In 2015, a few car-related headlines

A few unrelated headlines from 2014

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

In Practice: The BMW Hack

The list of vulnerabilities is rather long

One fix: The communication is now encrypted using HTTPS

The BMW Hack: Poor Decisions

Using the same keys

Keys need to be diversified

Only critical messages are encrypted

A secure channel protects against

Configuration data no tamper-proof Configuration data integrity is

Configuration data authenticity is

The vehicle ID is in error messages

Simplify diagnosis by having the data

A remote attacker doesnt have the ID,

Well-known, fast algorithm

DES is broken, lets mandate AES

No protection against replay attacks Same message, same action

A recorded message cannot have the

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

Very important to validate a design

Identify countermeasures to be added to the design

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

Attack Surface Between Devices and IoT Service

Attack Surface Device Low-level Software

Thinking like a defender

Attack Surface Attacking the Things and Gateways

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

Compromising a Device Focus on Persistent Memory

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

Compromising a Device Focus on Persistent Memory

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

Compromising a Device Focus on Persistent Memory

Compromising a Device Server Authentication

Oracle Internet of Things Cloud Service

3rd party gateway

IoT Cloud Service

BI & Big Data

Transportation Asset Mgmt

IoT CS Ensures End-to-End Security

Secure, managed state

Restricts types of IoT CS

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

IoT CS Ensures End-to-End Security

Secure, managed state

Restricts types of IoT CS

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

From HTTPS to Man-in-the-Middle

From HTTPS to Man-in-the-Middle

Protecting against Man-in-the-Middle