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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 6
Attack Surface – Main components
Devices
Operators
Enterprise Apps
Messages
REST
API
UI
Connectors
IoT Service
Gateway

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 7
Attack Surface – Specific to the Internet of Things
Devices
Operators
Enterprise Apps
Messages
REST
API
UI
Connectors
IOT Server
Gateway

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 8
Attack Surface – Software Components
Devices
Messages
IoT Service
HW / OS
Framework
Cloud/Server
Framework

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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?

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 13
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 14
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 16
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Compromising a Device – Focus on Persistent Memory
19
Spy on the
persistent memory
Disclose
data
109
Disclose
applications
Disclose system
software
Disclose system
software
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Compromising a Device – Focus on Persistent Memory
20
Tamper with
persistent memory
Tamper
with data
Tamper with
applications
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
softwareTamper with
application data
Tamper with
authentication data
6
Modify device
authent data
5
Modify device
identity
1
Modify buffered
messages

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Compromising a Device – Server Authentication
21
Tamper with
persistent memory
Tamper
with data
Tamper with
applications
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
softwareTamper with
application data
Tamper with
authentication data
6
Modify device
authent data
5
Modify device
identity
1
Modify buffered
messages

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
• 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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
• 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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 25
From HTTPS to Man-in-the-Middle
Device
HTTPS
IoT
Service
 

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 26
From HTTPS to Man-in-the-Middle
Device
HTTPS
IoT
Service

 




Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
❶ 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.

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
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

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. |

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