Prove it via Self-Assessment

Serious about IoT Security? Prove it via Self-Assessment
Ian Smith, IoT Security Director, GSMA
15th March 2017 - Smart IoT London
[email protected]
Welcome to London Docklands
2
Image © ExCeL London
A Little Bit of History
3
Image © Google, Infoterra & Bluesky
1855 - Royal Victoria Dock Opened….
First Dock in London To:
• Accommodate large steam ships
• Use hydraulic power to operate its machinery
• To be connected to the national railway network
CONNECTIVITY - CAPACITY - EFFICIENCY
Leading to 125 years of commercial success…
4
But Connectivity Brought New Risks….
….Just Like the IoT is Doing Today
5
Image © Google, Infoterra & Bluesky
Introduction to the GSMA
GSMA IoT Security and Privacy Resources
Security
Principles &
Processes
Security
Guidelines
Security
Checklist via
Self-Assessment
Evaluate Technical Model
Security by Design
Privacy by Design
End to End
Review Security Model
CLP.11
Cradle to Grave
Assign Security Tasks
Review Component Risk
Implementation
Ongoing Lifecycle
CLP.12
CLP.13
CLP.14
IoT Security
Self-Assessment
IoT Security
Self-Assessment
CLP.17
CLP.19
Process
Checklist
7
IoT Security Guidelines for the Whole IoT Ecosystem
Security Challenges
IoT Security Model
Risk Assessments
Privacy Considerations
Examples
Security
Over 200
Pages of Generic Advice and Recommendations
Principles
To Secure Devices, Service Platforms and Networks
3 ‘Worked’ Examples – Wearables, Personal Drone and Automotive
Security
Risk and Privacy Impact Assessments
12 Principal Attack Models
Guidelines
85 Detailed Recommendations
IoT
Security
IoT Security
Self-Assessment Process andSelf-Assessment
Checklist
Self-Assessment
Detailed Control
All freelyStatements
available for download at:
www.gsma.com/iotsecurity
Process
Checklist
8
IoT Secirity Applicable to All Type of Services
Security
Principles
Transport
Security
Guidelines
Security Challenges
IoT Security Model
Risk Assessments
Privacy Considerations
Examples
Agriculture
Detailed ControlIndustrial
Statements
Health
IoT Security
Self-Assessment
Smart Homes
IoT Security
Self-Assessment
Energy
Process
Checklist
9
Focuses on The Key IoT Challenges
SecurityHow to ensure:
IDENTITY
Principles
AVAILABILITY
Ensuring constant connectivity
between Endpoints and their
respective services
Authenticating Endpoints,
services, and the customer or
end-user operating the Endpoint
Security Challenges
IoT Security Model
Risk Assessments
Privacy Considerations
Examples
PRIVACY
Reducing the potential for harm
to individual end-users.
INTEGRITY
Ensuring that system integrity
can be verified, tracked, and
monitored.
Security
Ensuring that system
can beand
verified,
tracked, and
monitored
inintegrity
services
devices
that
are
Guidelines
LOW
COMPLEXITY
LOW POWER
Detailed Control
Statements
Low processing capability.
Small amounts of memory.
Constrained operating
system.
No permanent power supply
Possibly permanent, but
limited power supply.
LONG
IoT Security
LIFECYCLES
Self-Assessment
PHYSICALLY
IoT Security
ACCESSIBLE
Self-Assessment
Requires cryptographic
design that lasts a lifetime.
Manage security
vulnerabilities which
can’t be
Process
patched within the endpoint.
Access to local interfaces
inside the IoT endpoint.
Hardware components and
interfaces
potential target
Checklist
10
of attackers.
IoT Security Critical Recommendations
For IoT Service Platforms
•
5.1 Implement a Service Trusted Computing Base
•
5.2 Define an Organizational Root of Trust
•
5.3 Define a Bootstrap Method
•
5.4 Define a Security Infrastructure for Systems Exposed to the
Public Internet
•
5.5 Define a Persistent Storage Model
•
5.6 Define an Administration Model
•
5.7 Define a Systems Logging and Monitoring Approach
•
5.8 Define an Incident Response Model
•
5.9 Define a Recovery Model
•
5.10 Define a Sunsetting Model
•
5.11 Define a Set of Security Classifications
•
5.12 Define Classifications for Sets of Data Types
Security
Principles
Security
Guidelines
Detailed Control
Statements
For IoT Device Endpoints
•
6.1 Implement an Endpoint Trusted Computing Base
Security Challenges
•
6.2 Utilize a Trust Anchor
IoT Security Model
•
6.3 Use a Tamper Resistant Trust Anchor Risk Assessments
•
6.4 Define an API for Using the TCB
Privacy Considerations
•
6.5 Defining an Organizational Root of TrustExamples
•
6.6 Personalize Each Endpoint Device Prior to Fulfilment
•
6.7 Minimum Viable execution Platform (Application Roll-Back)
•
6.8 Uniquely Provision Each Endpoint
•
6.9 Endpoint Password Management
•
6.10 Use a Proven Random Number Generator
•
6.11 Cryptographically Sign Application Images
•
6.12 Remote Endpoint Administration
•
6.13 Logging and Diagnostics
•
6.14 Enforce Memory Protection
IoT Security
IoT ROM
Security
•
6.15 Bootloading
Outside of Internal
Self-Assessment
Self-Assessment
•
6.16 Locking Critical Sections of Memory
•
6.17 Insecure Bootloaders
•
6.18 Perfect Forward Secrecy
•
6.19 Endpoint Communications Security
Process
Checklist
•
6.20 Authenticating an Endpoint Identity
11
IoT Recommended Privacy Considerations
•
•
Security
Principles
Provides recommendations to
Security Challenges
IoT Security Model
Risk Assessments
Privacy Considerations
Examples
Promotes IoT Privacy by Design
ensure IoT service providers:
–
–
–
–
–
Have a privacy compliance process.
Identify sources of personal data.
Have processes to protect personal
data.
Understand lawful intercept
responsibilities.
Protect the privacy of user data.
Security
Guidelines
Detailed Control
Statements
IoT Security
Self-Assessment
IoT Security
Self-Assessment
Process
Checklist
12
IoT Security Self-Assessment Checklist
A flexible approach to IoT Security Evaluation
Security
Principles
Structured
Security Challenges
IoT Security Model
Risk Assessments
Privacy Considerations
Examples
Security
Guidelines
Referenced to
Guidelines
Concise
Detailed
Control
Questions
Statements
IoT Security
Self-Assessment
IoT Security
Self-Assessment
Process
Checklist
13
A Flexible IoT Security Framework is the Key
Security
Principles
Security Challenges
IoT Security Model
Risk Assessments
Privacy Considerations
Examples
FLEXIBILITY
Security
Guidelines
Detailed Control
Statements
IoT Security
Self-Assessment
IoT Security
Self-Assessment
Only flexible IoT security and privacy processes and recommendation can address
the huge diversity in IoT services that will come to market in the next few years
Process
Checklist
14
Security Self-Assessment Realising Real Value……
•
Led by the Port Authority of Seville and
Telefónica, the Tecnoport 2025 project uses IoT
solutions to improve the efficiency of transport
and logistics in South West Spain.
•
This case study is shows how, using the GSMA
IoT Security Self-Assessment scheme,
important security issues were resolved and
new security measures were implemented.
www.gsma.com/connectedliving/securing-port-future/
IoT Security Self Assessment:
www.gsma.com/connectedliving/iot-security-self-assessment/
IoT Security Guidelines:
www.gsma.com/iotsecurity
The GSMA also publishes a huge amount of IoT resources on our Website:
Go to: www.gsma.com/connectedliving
16
See: https://en.wikipedia.org/wiki/2016_Dyn_cyberattack for more information
IoT Security Case Study #1 - The Dyn Cyberattack
What happened?
The Dyn cyberattack took place on October 21, 2016, and involved multiple denial-of-service attacks (DoS attacks) targeting
systems operated by Domain Name System (DNS) provider Dyn which made major Internet platforms and services unavailable
to large swaths of users in Europe and North America. Services affected included: Airbnb, Amazon, Netflix, PayPal & Twitter.
What was the cause?
The distributed denial-of-service (DDoS) attack was accomplished through a large number of DNS lookup requests from tens of
millions of IP addresses. The activities are believed to have been executed through a botnet consisting of a large number of IoT
devices - such as printers, IP cameras, residential gateways and baby monitors - that had been infected with the Mirai malware.
With an estimated load of 1.2 terabits per second, the attack is, according to experts, the largest DDoS on record
What was the vulnerability that was exploited?
Devices infected by Mirai continuously scan the internet for IoT devices. Mirai then identifies vulnerable IoT devices using a
table of common factory default usernames and passwords, and logs into them to infect them with the Mirai malware.
Infected devices will continue to function normally, except for occasional sluggishness, and an increased use of bandwidth.
Which Recommendations in the GSMA IoT Security Guidelines would have prevented this?
Some key recommendations taken form GSMA document CLP.13:
• Section 5.10 – How should I Implement Secure Remote Management
• Section 6.9 – Endpoint Password Management
17
See: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ for more information
IoT Security Case Study #2 - The Jeep Cherokee Hack
What happened?
In 2014 security researchers Charlie Miller and Chris Valasek successfully demonstrated a remote attack on the safety critical
functions of a Jeep Cherokee whilst it was being driven by a journalist at 70mph on a freeway. This led to Fiat Chrysler to recall
1.4 million vehicles for a security patch to be applied – incurring huge cost and brand damage in the process.
What was the cause?
Miller and Chris Valasek exploited a chain of security vulnerabilities to perform this attack. Firstly they performed a brute force
attack to connect to the on-board Wi-Fi within the vehicle. Using this connectivity they hacked the Linux based ‘head unit’ which
in turn allowed them to alter the firmware of a microcontroller which has access the vehicles internal communications network
(CAN bus). With access to the CAN bus they could interfere with safety critical functions such as the vehicles braking system.
What was the vulnerability that was exploited?
Tthe key vulnerabilities were the provisioning of weak Wi-Fi access credentials, communications ports being left open, lack of
authentication on communications channels and lack of protection for firmware updates
Which Recommendations in the GSMA IoT Security Guidelines would have prevented this?
Some key recommendations taken form GSMA document CLP.13:
• Section 5.6 - How do I Disallow Tampering of Firmware and Software
• Section 6.8 – Uniquely Provision Each Endpoint - to strengthen the WiFi password
• Section 6.9 – Disable Debugging and Testing Technologies – To disable unused communication ports.
18
See: http://iotworm.eyalro.net/ for more information
IoT Security Case Study #3 - Philips Hue Lightbulb Attack
What happened?
In November 2016 security researchers successfully demonstrated a viral attack on Philips Hue lightbulbs that could potentially
be used to cause to disrupt a city’s power grid.
What was the cause?
The researchers flew a drone, loaded with malware, around a city. The drone discovers and communicates wirelessly with any
Philips Hue lightbulbs that are nearby (within ~350 meters) and infects them with a malicious ‘worm’. Once the worm is installed
this triggers a chain reaction with each infected lightbulb infecting the other lightbulbs in its local area. The malware can cause
all the bulbs to switch off, causing a blackout, or to switch on and off in synchronization causing disruption to the power grid.
What was the vulnerability that was exploited?
Two vulnerabilities were exploited. Firstly the researchers found a bug in the lightbulbs implementation of ZigBee wireless
communication protocol which allowed the ‘untrusted’ drone to ‘join’ with a lightbulb from very long range. Secondly they found
the lightbulbs use a global key to encrypt and authenticate new firmware updates allowing the ‘worm’ to be injected.
Which Recommendations in the GSMA IoT Security Guidelines would have prevented this?
Some key recommendations taken form GSMA document CLP.13:
• Section 5.5 - How do I Disallow the Ability to Impersonate Services or Peers?
• Section 5.6 - How do I Disallow Tampering of Firmware and Software
• Section 5:10 - How should I Implement Secure Remote Management?
19