IoT Security – It’s in the Stars! 16_9 v201605241355

1UL and the UL logo are trademarks of UL LLC © 2016

IoT Security – It’s in the Stars!

Andrew JamiesonUL Security Oompa Loompa

[email protected]

@andrewrjamieson

Opinions are my own and may not reflect any official stance from UL

v201605241355

2

Does this stage make me look fat?(How much do you think I weigh?)

How are we able to objectively assess weights?

3

1kg ‘prototype’: Platinum–iridium alloy

39.17 mm in both diameter and height,

with edges that have a four-angle

(22.5°, 45°, 67.5° and 79°) chamfer

(Defined in 1889)

4

How do we measure ‘security’?

How do we test ‘security’?

We need to define a level of

acceptable risk through some

form of methodology

How existing security evaluations do that?

5

Defining Security Evaluation

Externally defined riskIndividually defined risk

Formalised methodology

Informal methodology

Common

Criteria /

ISO15408

ISO13491

FIPS140-2

PCI PTS

Common Criteria / ISO15408

FIPS140-2

ISO13491

PCI PTS

Penetration Testing

/ 34

6

Defining Security Threats

Three ‘types’ of security problems – Security DIY

• Deliberate

• Back-doors, remote data transmission, etc

• Ignorant

• Poor security settings / configurations

• May be done for ‘ease of use’, or simply lack of security knowledge

• Yet to be discovered

• Undiscovered / unreported vulnerabilities in software used

• May be entirely new types of attacks, or just problems in existing code

that have not been found yet

Code review

Pen testing

Prayer!

How do we currently address these problems?/ 34

7

Security evaluations

1) Take time

2) Cost money

3) Always fail

How does this fit with IoT?

8

Defining the Internet of Things (IoT)

• Devices are becoming ‘smarter’

• Processing elements are getting cheaper and better

• Vendors are differentiating their products based on

functionality

• Everything is getting ‘connected’

/ 34

9

IoT – What’s the Problem?

• Design Prototype Production cycles getting shorter

• Compresses ability to do testing, and remediate vulnerabilities

• Customers don’t have the necessary tools / skills to differentiate

products based on security

• They may say they care, but they vote with their wallets

• New vulnerabilities are released all the time

• Remember security DIY!

Product vendors don’t have any incentive to spend additional time /

money building security into products

... and even less incentive to patch once products are shipped

/ 34

10

• Why not pentesting / code review?

• Cost / time issues will prevent wide uptake

• Does not scale:

• Pentesting is a point in time solution

- Does not address on-going security

• Security evaluation is inherently subjective

- Do you choose the gold dress pentester

or the blue dress pentester?

• The value is not exposed to the customer

- How do you shop?

IoT – Why Isn’t it Fixed Already?

That’s a lot of pentesters!

/ 34

11

IoT – Why Current Solutions Don’t Work

$500

$750

Without additional information,

which one do you choose?

What if one is more secure?

How would you know?

How much would you care?

/ 34

12

IoT Security is primarily a commercial

problem, that prevents suitable

technical solutions from being applied

13

IoT – What is the Solution?

• Need to address commercial problems commercially

• Create the incentive for the vendor to build in security

• Inform customers to make purchase decisions about security

• Provide methods for vendors to understand and value security

... All within a framework that allows for rapid product

development and release, with as little cost and time

overhead as possible! (Easy!?)

When faced with a seemingly insurmountable problem, I always

refer to the oracle that is Battlestar Galactica .../ 34

1414(And look to the stars for salvation)

15

Have been used to change consumer purchase behaviour in the past...

Why not for security?

Star Rating Programs

/ 34

16

How do you compare different products, different architectures and

different security requirements objectively? Without (costly) code

review / pentesting (of every release)?

How do we compare across such diversity?

Security Star Rating - Problems

/ 34

17

Defining IoT Security Metrics

Keep it simple, stupid!

• Devices can be defined by three things

- Interfaces (Input / Output)

- Processing attack surface

- System architecture

• The more interfaces, and larger attack surface, the less secure a system

can objectively be considered

• Specifics of the architecture either help or hinder

security (changing the ‘vulnerability surface’)

• Then we ‘just’ need to wrap

metrics around this process!

How do we define the metrics?

} Vulnerability Surface

Computing

System / 34

1818

We make them up!

19

Metric – Logical Security Posture (LSP)

• Based on a points system

• Points are assigned for security features the system has

• Points are deducted for increasing attack surface

- Logical and physical interfaces, OS type, processor architecture

• Most computing vulnerabilities have similar root causes

• Lack of randomness where needed

• Default configurations / passwords / cryptographic keys

• ‘Over privileged’ (and vulnerable) code

• Insecure updates and communication methods

• Little to no logical protections – security is just not thought about

Let’s look at ‘interfaces’ as an example/ 34

20

Drilling down into the Lumps of LSP

• Every interface is doing you damage

• Each protocol supported increases the attack surface

• Running the code at lesser privilege reduces the vulnerability surface

- But it’s a bit more of a PITA, so a lot of vendors don’t do this

• For the LSP we assign negative points for each logical interface

• If != lesser privilege to assets / root, multiplication factor is applied (x4)

• Factors reducing the vulnerability surface (eg assets in TEE, interfaces

disabled by default) add positive points / reduce the multiplier

• Gives vendors a clear guide that more interfaces are bad

- And running them at high privilege is even worse ...

Why yet another attack costing method?!/ 34

21

LSP vs CVSS vs (CC/PCI) JIL Costings

• Why not just use CVSS / JIL costings?

• These are for costing / evaluating the level of actual vulnerabilities

- Vulns should be patched in systems anyway

- They don’t help with determining the (potential) level of security of a system

• LSP helps inform the vendors on how to make their systems more secure

- Provides clear incentives for them to implement better security

• CVSS / JIL costings require detailed analysis / pen testing

- LSP is designed to be simple enough to self assess if required

- Reduces eval costs and time-to-market impacts

Let’s look at an example

/ 34

22

Star Rating Example

• Two Linux based systems

• Basically the same in terms of WiFi support, features, etc

• Let’s call them RoutD and RoutY

Specification RoutD RoutY

Operating System Linux Kernel 3.10.17 Linux Kernel 3.18.23

FTP server Root privilege Separate user privilege (Disabled by default)

Credentials Admin / Password Device unique printed on serial number sticker

VPN Based on OpenSSL v1.0.1

(root, hardcoded default cert)

Based on WolfSSL v3.9.0

(User privilege, no default cert, disabled by default)

Random number

generator

/dev/urandom

(no seed, not stateful)

/dev/random

(seeded at manufacturing, stateful between boots)

Web Interface Over HTTP, exposed on

WAN

Over HTTPS, WAN access disabled by default

FW updates? No commitment For 2 years, updates cryptographically authenticated

(McRoutface)

/ 34* Note: Greatly simplified list of interfaces / features

23

Star Rating Example

• Let’s take a closer look at RoutD …

• Probably not a fair / useful comparison

• Let’s try to make it more even





VPN Based on OpenSSL v1.0.1




Random number

generator

/dev/urandom


/dev/random



WAN



Multiple unpatched /

unmitigated vulns

/ 34

24

Star Rating Example

• Let’s assume the same kernel / SSL versions





VPN Based on WolfSSL v3.9.0




Random number

generator

/dev/urandom


/dev/random



WAN



External interfaces at same privilege

level as assets (minus points)

/ 34

25

Star Rating Example










Random number

generator

/dev/urandom


/dev/random



WAN



Default authentication

credentials (minus points)

/ 34

26

Star Rating Example










Random number

generator

/dev/urandom


/dev/random



WAN



Predictable RNG with no

entropy control (minus points)

/ 34

27

Star Rating Example










Random number

generator

/dev/urandom


/dev/random



WAN



Non-secure interface(s) with no

ability to disable (minus points)

/ 34

28

Star Rating Example










Random number

generator

/dev/urandom


/dev/random



WAN



No commitment to FW updates

(automatic 0 star fail)

/ 34

29

Star Rating Example

• What are the Star Ratings for RoutD and RoutY?









Random number

generator

/dev/urandom


/dev/random



WAN



Star Rating 0 Stars 4 Stars (Until 2018)

For the period

of FW updates/ 34

30

Star Rating Example

• So is RoutY more secure than RoutD?

• Yes – through good configuration and design

• Even though both do the same thing, and have no current vulns

- And we can objectively demonstrate this without costly pentesting

• Does this mean RoutY is secure?

• No! Will still need patching, but the vendor has committed to that

• Not meeting this commitment means reduced ratings into the future

• Does this mean RoutD will be compromised / vulnerable first?

• Not necessarily – the star rating is about levels of resistance

- ‘More secure’ does not mean ‘will not fail’

• But that’s why we need patching. How to ensure this?/ 34

31

Follow-Up Service (FUS)

• On-site inspection to ensure devices are still OK to bear the UL mark

• Performed at least quarterly

• Failure to meet requirements means loss of UL logo

• Not just done by UL though – an industry-wide thing

• We can do something similar for IoT Security Star ratings

• Stars are issued based on ‘number of years secure’

- “4 Stars until 2018” is different from “5 Stars until 2015” !

• Vendors must patch systems during that time

• FUS services validate this, and if it is not done right: No soup* for you!

(*Note: References to “soup” should not be taken literally)

/ 34

32

IoT Security – It’s in the Stars

• Most people are not security engineers

• They can’t differentiate products based on security

• Security is hard - Which makes it costly & time consuming

• Commercial problems need commercial solutions

• Insurance is a great market change driver

- But they need metrics so that they can assess risk

• Markets don’t respond well to instant changes

- A step function from insecure secure is a non-starter / not possible

- Security is not binary; how much security are you willing to pay for?

• We need metrics to assist with purchase decisions

• Encourage vendor buy-in of costs for in-field security problems

- Require an active bug bounty program for 5 star security/ 34

33

IoT Security – It’s in the Stars

34

Thank you!

/ 34

[email protected]

@andrewrjamieson

IoT Security – It’s in the Stars! 16_9 v201605241355

Documents

Transcript of IoT Security – It’s in the Stars! 16_9 v201605241355