IoT Security Part I
Syllabus
This module will cover the following
• IoT security in context: importance and role of devices
• Threat modelling
• End-to-end security
• Security provision in hardware, software, and networks (overview)
2 © 2020 Arm Limited
IoT security in context
Why security is critical in IoT
Context:
• Billions of connected devices already deployed, used increasingly more to collect personal information (medical IoT, wearables, smart homes) and serve critical services (automotive IoT, energy distribution)
Challenges:
• System heterogeneity (sensing, computation, actuation, communication)
• Complex interactions (systems of systems, emergent behaviour)
• Hundreds of new types of devices appear monthly, software evolving continuously
• Many devices in use after vendors discontinued support/went into liquidation
But, hang on, what is security anyway? ….
4 © 2020 Arm Limited
Quick Introduction to Cyber Security
Confidentiality
Integrity Availability
✓
5
Quick Introduction to Cyber Security, Privacy
Confidentiality
Privacy
✓
Integrity
Availability
✓
6
Quick Introduction to Cyber Security, Privacy and Trust
Confidentiality
✓
Trust
Integrity
Availability
✓
7
Quick Introduction to Cyber Security, Privacy and Trust
Confidentiality
✓
Trust
Integrity
Availability
✓
8
Lots of things have gone wrong already
IoT has followed a (sadly) typical pattern:
1. New exciting technology built and deployed without much/enough/any security
2. Security researchers warn about potential problems
3. Attacks actually seen “in the wild”, for fun or profit
4. Providers, users, governments scrabble to retrofit security, fix behaviours, change law
Recently there is more talk of “building security in”, “privacy by design” and “security by design” so maybe lessons are being learned…
Q. Why do you think this pattern of ”bolting on” security has often repeated?
9 © 2020 Arm Limited
IoT Botnets and PDoS: Mirai and Brickerbot (2016-)
Mirai targeted Internet-connected devices with default usernames and passwords and open Telnet ports. Mainly routers and IP cameras.
It was used in a massive DDoS attack on Dyn DNS provider in 2016, generating huge traffic volume (1Tbps), impacting many high-profile websites.
Brickerbot attempted to permanently destroy IoT devices similarly, by logging in and running harmful commands. Allegedly was intended to stop damage of Mirai.
10 © 2020 Arm Limited
Open Sesame! Smart locks and talking dolls (2017 PoC)
Fun proof of concept shown by National Cyber Security Centre in 2017:
• WiFi enabled talking Doll Cayla is hacked
• She gives command “open sesame” to a
voice assistant…
• Which is connected to a smart lock on the front door
Q. What’s the new/unusual security issue in this example?
See https://www.bbc.co.uk/news/av/technology-38966285
11 © 2020 Arm Limited
Threat Modelling
Threat modelling
Structured analysis of security in a system
Goals:
• Identify threats: risks of damage to assets caused by security failures and attacks
• Risk modelling: estimate severity (cost of damage) and likelihood, for each threat
• Design mitigations: prevention or response actions
• Prioritize implementation of such mechanisms
Various methodologies can be used:
• Generalised methods: Attacker models, Microsoft STRIDE, Attack Trees
• Taxonomies of threat-types: Open Threat Taxonomy
• IoT specific processes: ENISA or OWASSP
13
© 2020 Arm Limited
Terminology reminder
14 © 2020 Arm Limited
Attacker models
An “attacker model” is an attempt to characterise the capabilities of a category of attackers. Can be precise and technical or a higher-level characterisation.
Some attackers are more capable than others or have more resource available: • “Script kiddies” just playing around
• Organised criminals with funds to buy botnet access • Nation state adversaries
Some capabilities are restricted by what access an attacker has: • Physical proximity: Bluetooth or WiFi snooping
• Cleaner cupboard access: connect to heating & power interfaces
Q. Why are attacker models useful?
15 © 2020 Arm Limited
and it is difficult to know where to start. To begin, a tool is needed to both build the
model and run analysis against it. One example is SecurITree, a capabilities-based
Attack trees
attack tree modeling tool built by the Canadian company Amenaza (the Spanish
word for threat) (http://www.amenaza.com/). Building an attack tree is perhaps bIedsetad:ecsocnrisbiedderwpirthocaesismopflberexakminpgles.ystem from an attacker’s point of view, top-down.
Suppose an attacker wishes to accomplish the overarching goal of re-directing an Unmanned Aircraft Systems (UAS), that is, a drone, while in flight. The following
• Starting from a high-level goal, decompose in stages (a form of planning). diagram shows the top-level activities of the attack tree to accomplish this:
• Construct an AND-OR tree showing combinations and alternatives.
Redirect UAS
Redirect UAS
Corrupt Navigation Spoof GPS Spoof Ground Control Database Station
Unmanned Aerial System example from Practical Internet of Things Security, You will notice the two well-known logic operator symbols for AND (smooth and
16 © 2020 Arm Limited
Russell & Van Duren, Packt Publishing Ltd 2016.
rounded top) and OR (pointy top). The root node, entitled Redirect UAS represents
the end objective and is made up of an OR operator. This means that any one of its
Attack trees
Vulnerabilities, Attacks, and Countermeasures
Expanding the Exploit Transitive Trust subtree gives us the following image: Tree is refined to get to leaves which then can be considered for points of defence.
Exploit Transitive Trust
Access network by abuse of transitive trust
Establish presence on GIS Services network via DMZ trust
Corrupt Navigation Database
Compro DB Server
Plant Malware
Trick administrator
Establish malicious connection
Load Malware via
Bribe / blackmail vendor
Modify GIS Tables (SQL)
Man in the middle attack on
Acquire black market
Obtain DMZ beachhead
Connect Physically
This drawing style indicates open nodes yet to be refined, and uses logic symbols for AND/OR. Traditionally, AND nodes are Windictahteoduwtitghoaninargcbientwtoeendcehtiladieldgoens. eYovuecraynanlsowdreit,eithtebtreceotemxtueasllyawpitphanrienndetntehdalisttcinadriceatfiunglntohdoetuypgeh. t
and consideration goes into developing an effective, usable attack tree. In summary,
17 © 2020 Arm Limited
trees have subtrees that can be very simple or complex. Typically, the more complex
Identifying vulnerabilities which may be exploitable
Gather detailed knowledge about end-to-end system architecture and the key building blocks Understand how information flows between blocks, in what order, and based on what conditions Identify potential breaching points of each building block
Establish trust boundaries that is the component most likely to be compromised first
Reflect on plausible attack scenarios and incentives an attacker may have to tamper with a system
18 © 2020 Arm Limited
Threat and vulnerability taxonomies
Open Threat Taxonomy
The confidentiality, integrity, availability (CIA) triad applied across different threat groups
1. Physical threats (incidents or actions that could lead to system damage, destruction, or theft – e.g., natural disaster, cooling/ventilation failure, vandalism)
2. Resource threats (failure of information system due to disruption of resources required for operation – e.g., communication services, external storage, power supply)
3. Personnel threats (deliberate or accidental actions of humans involved in the management/interactions with a system that may harm the system; damage as a result of social engineering that leads to system authentication compromise)
4. Technical threats (actions by an attacker that could harm the information system)
Threats are numbered in each of these groups, and given a ranking 1-5, higher ranked
threats are suggested as being more likely to apply in general.
20 © 2020 Arm Limited
Open Threat Taxonomy, v1.1 (2015)
Technical threats
• Credential discovery, e.g., via sniffing (TEC-007), brute force (TEC-008), pre- computational attacks (TEC-011)
• Escalation (TEC-013) or abuse (TEC-014) of system privileges
• Cryptanalysis (TEC-019)
• Denial of Service (DoS) (TEC-021)
• Manipulation of data in transit (TEC-023) or capture of data in transit via different methods (TEC-024 – TEC-026)
• App exploitation via input manipulation (TEC-031), code injection (TEC-033), fuzzing (TEC-037), reverse engineering (TEC-038).
The taxonomy lists 41 technical threats, 14 physical, 13 resource and 7 personnel.
21 © 2020 Arm Limited
Q. Why do you think there are so many more technical threats than other kinds in this taxonomy?
ENISA IoT threat taxonomy (2017)
See: Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures
22 © 2020 Arm Limited
ENISA’s impact survey of IoT attacks and vulnerabilities
• The severity of attack kinds was ranked as Medium, High, or Crucial, based on interviews with IoT experts
• Weighted average of responses, based on a five-step scale (0 – no importance; 5 – crucial importance)
• Impact varies depending on use cases
For a much more detailed vulnerability scoring mechanism,
see CVSS at https://nvd.nist.gov/vuln-metrics/cvss
23 © 2020 Arm Limited
3.5 and 4 out of 5 represent high-importance threats, and values over 4 out of 5 represent crucial- n
e c
ce threats. Values below 3 out of 5 represent low-importance and no-importance threat, but it noted that no threat got that rating. Moreover, it can be seen that the average impact is rated as
ENISA’s impact survey of IoT attacks and vulnerabilities
e the value of the average impact is 3.7 out of 5.
Sensitive data leakage / modification of information
5 4,2 4
3,0 1 0
Attacks on privacy 3,5 Exploit Kits
Weak passwords
Eavesdropping
3 Counterfeit by malicious devices 2
4,D2 DoS
Network outage
Impact
Impact average
4,1
3,6
4,0
3,1 4,1
Malware
3,3
APTs
Figure 10: Threat impact weighted average
Q. Why do you think APTs and Network outage were ranked low impact?
24
© 2020 Arm Limited
OWASP Internet of Things Recommendations
OWASP – Open Web Application Security Project
Helping stakeholders understand security
Top 10 things to avoid
1. Weak, guessable, or hardcoded passwords
2. Insecure network services
3. Insecure ecosystem interfaces
4. Lack of secure update mechanism
5. Use of insecure or outdated components 6. Insufficient privacy protection
7. Insecure data transfer or storage
8. Lack of device management
9. Insecure default settings
10. Lackofphysicalhardening.
•
•
OWASP IoT project groups different community- led initiatives to strengthen security into three categories: Seek & Understand, Validate & Test, and Governance.
Identifies ten key things to avoid from a security perspective when building, deploying, or managing IoT systems.
25
© 2020 Arm Limited
OWASP IoT Attack Surface
Ecosystem Access Control (implicit trust, enrolment security, lost access procedures, etc.) Device memory (cleartext usernames/passwords, encryption keys, etc.)
Device physical interfaces (firmware extraction, privilege escalation, reset to insecure state) Device web/admin/cloud web interface (SQL injection, XSS, account lockout, 2FA, etc.) Device firmware (hardcoded credentials, sensitive info disclosure)
Device network services (injection, DoS, poorly implemented encryption, buffer overflow, etc.)
26 © 2020 Arm Limited
OWASP IoT Attack Surface
Local data storage (unencrypted data, lack of integrity checks)
Update mechanism (updates encrypted/unsigned, update location writable, etc.)
Mobile application (implicitly trusted by cloud, user enumeration, transport encryption, etc.)
Third parties (device information/location leaked, unencrypted PII)
Backend APIs (inherent trust, weak authentication, weak access control)
Ecosystem communication (health checks, heartbeats, deprovisioning)
27 © 2020 Arm Limited
Example IoT system
Example: Fitness tracking system
29 © 2020 Arm Limited
Example: Fitness tracking system
Packet sniffing, DoS, code injection
30 © 2020 Arm Limited
Example: Fitness tracking system
Packet sniffing, DoS, code injection
Packet sniffing, protocol reverse engineering
31 © 2020 Arm Limited
Example: Fitness tracking system
Packet sniffing, DoS, code injection
Packet sniffing, protocol reverse engineering
User impersonation, fake measurements injection, exfiltration
32 © 2020 Arm Limited
Example: Fitness tracking system
Packet sniffing, DoS, code injection
Packet sniffing, protocol reverse engineering
User impersonation, fake measurements injection, exfiltration
Service impersonation, malware injection
33 © 2020 Arm Limited
A good exercise
Based on this setting and the attack steps shown:
1. Develop three different attacker models for capabilities of different potential attackers.
2. List the assets that should be protected from malicious damage in/by the system.
3. For at least two assets, consider specific threats against them and threat actors who might pose the threat (i.e., attackers conforming to one of the attacker models).
4. For at least one threat, consider the goal of an attacker to achieve damage as the root of an attack tree. Develop the tree to consider possible ways to achieve the attack.
Free lunch attack tree example as an AND-OR tree and as indented text (used in some tools):
Free Lunch
OR + Get legit customer to buy you lunch
+ OR + Promise to pay back later
+ MiM attack
AND + Tell customer ..
+ Go to counter ..
+ Wave at customer
34
© 2020 Arm Limited
+ “Eat-n-run” …
Overview of security provisions
End-to-end Security
So-called “End-to-end” guarantees are in some ways our best hope:
• End-to-end authentication: receiver can determine sender and vice-versa
• End-to-end message confidentiality: only receiver can learn sender’s message
• End-to-end message integrity: intermediate relays, proxies, switches, can’t alter msg
More subtle issue is actually what constitutes the endpoint: identities may only be meaningful at the application layer.
Moreover, the end-to-end guarantees are meaningless if the ends themselves are vulnerable to exploit. Security provisions need to be made across the stack, covering hardware, software, networks and where they join.
Q. And what else?
36 © 2020 Arm Limited
Hardware security
Hardware security addresses questions such as whether:
• sensitive data can be protected at rest and during use?
• boot sequence is not corrupted even if app software attacked?
• device is protected against physical or electronic snoop/attack?
• the device cannot be cloned/replicated?
It might not be possible to make device completely safe against all attacks, yet damage can be limited through several approaches.
37 © 2020 Arm Limited
Software security
Software security addresses questions such as whether:
• applications have implement authentication, authorization?
• apps & libs are free from vulnerabilities to unexpected inputs?
• keys and sensitive data are treated carefully?
• isolation is provided between different threads/apps?
Again, the aim is to achieve a reasonable level of security against the most common and most damaging kinds of attack.
38 © 2020 Arm Limited
Network security
Network security addresses questions such as whether:
• network protocols are free from security design flaws?
• security CIA properties are provided and on what layer?
• can eavesdroppers learn from metadata, traffic patterns?
• is isolation provided between different network flows?
Some aspects are easier to protect than others. Hiding the very existence of a communication can be tricky.
39 © 2020 Arm Limited
Mitigating risks across the IoT stack
Strengthen security across the entire end- to-end system
Hardware (attackers should not be able to compromise device via direct physical access)
Software (secure and tamperproof firmware)
Encrypted channels (data never exchanged in plaintext)
Service semantics (communication robust to DoS, replay attacks, account hijacking, etc.)
40 © 2020 Arm Limited
Summary
We gave an introduction to security for IoT
• IoT security in context
• sheer number of global devices and criticality of data or physical things they manipulate • modern view: Cyber Security, Privacy and Trust in concert
• previous failures of security in IoT
• Threat modelling
• basic concepts, attacker models and attack trees
• taxonomies of IoT specific threats and vulnerabilities
• Security provision in hardware, software, and networks • idea of end-to-end security provision
• overview of questions and concerns
41 © 2020 Arm Limited
45 © 2020 Arm Limited