'

Threat Modeling for the Internet of Things

Понравилась презентация – покажи это...





Слайд 0

Threat Modeling for the Internet of Things Eric Vétillard IoT Product Management Group September 2015


Слайд 1

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


Слайд 2

Agenda 1 Definitions 2 Concerns and threats 3 Some countermeasures 4 Device and gateway security 5 Simple checklist Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 3


Слайд 3

IoT Infrastructure – Main components IoT Service Devices Enterprise Apps Gateway Operators Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 4


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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) Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Theft Physical damage Murder? 9


Слайд 9

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


Слайд 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 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 11


Слайд 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 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 12


Слайд 12

Attack Surface – Between Devices and IoT Service Messages Devices Connectors Thinking like an attacker • Attacking the network link, remotely • Any operation can be attacked IoT Service admin operations can be good Enterprise Apps • Targeting • 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 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 13


Слайд 13

Attack Surface – Device Low-level Software Thinking like an attacker • 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 Server IOT • OS security configuration is important • Patching/update must be supported and secure REST UI API Enterprise Apps Gateway Operators Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 14


Слайд 14

Attack Surface – Attacking the Things and Gateways Connectors Messages IOT Server Devices Gateway Enterprise Apps Thinking like an attacker REST UI • Things and gateways are 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 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal 16


Слайд 15

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 device’s software Replace device physically Replace device in cloud Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Modify the device’s hardware Reconfigure a gateway Tamper with the device externally 17


Слайд 16

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


Слайд 17

Compromising a Device – Focus on Persistent Memory Spy on the persistent memory Disclose data Disclose applications Disclose system software 9 Disclose application data Disclose application Disclose authent data 1 Disclose server verification data 2 4 Disclose application data Disclose system software 3 Disclose buffered messages 10 Disclose device registration data 5 Disclose device authent data Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 19


Слайд 18

Compromising a Device – Focus on Persistent Memory Tamper with persistent memory Tamper with data Tamper with applications Tamper with native software 7 Tamper with application data Tamper with authentication data 1 3 Modify buffered messages Modify server verification data 2 4 Modify application data Modify device registration data 10 Modify a stored application’s code Modify system software 8 Modify a stored app’s meta-data 9 Add an application 5 Modify device identity 6 Modify device authent data Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 20


Слайд 19

Compromising a Device – Server Authentication Tamper with persistent memory Tamper with data Tamper with applications Tamper with native software 7 Tamper with application data Tamper with authentication data 1 3 Modify buffered messages Modify server verification data 2 4 Modify application data Modify device registration data 10 Modify a stored application’s code Modify system software 8 Modify a stored app’s meta-data 9 Add an application 5 Modify device identity 6 Modify device authent data Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 21


Слайд 20

Oracle Internet of Things Cloud Service IoT Cloud Service Client Libraries & Gateway Indirectly connected devices IoT Cloud Service Device Virtualization Oracle IoT CS Gateway s/w Event Store High Speed Messaging 3rd party gateway s/w with Oracle IoT Client Library Directly connected devices 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


Слайд 21

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


Слайд 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 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 24


Слайд 23

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


Слайд 24

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


Слайд 25

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 SE’s security has been certified. A The platform’s security has been certified. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 27


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

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 and/or its affiliates. All rights reserved. | Copyright © 2015, OracleOracle and/or its affiliates. All rights reserved. | 32


Слайд 31

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


Слайд 32


Слайд 33


×

HTML:





Ссылка: