Upload
eric-vetillard
View
2.455
Download
2
Embed Size (px)
Citation preview
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
10 9
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 software Tamper 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 software Tamper 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