2. 2
Does this stage make me look fat?
(How much do you think I weigh?)
How are we able to objectively assess weights?
3. 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. 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. 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. 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
8. 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. 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. 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. 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. 12
IoT Security is primarily a commercial
problem, that prevents suitable
technical solutions from being applied
13. 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
15. 15
Have been used to change consumer purchase behaviour in the past...
Why not for security?
Star Rating Programs
/ 34
16. 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. 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
19. 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. 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. 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. 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. 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
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
Multiple unpatched /
unmitigated vulns
/ 34
24. 24
Star Rating Example
• Let’s assume the same kernel / SSL versions
Specification RoutD RoutY
Operating System Linux Kernel 3.18.23 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 WolfSSL v3.9.0
(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
External interfaces at same privilege
level as assets (minus points)
/ 34
25. 25
Star Rating Example
• Let’s assume the same kernel / SSL versions
Specification RoutD RoutY
Operating System Linux Kernel 3.18.23 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 WolfSSL v3.9.0
(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
Default authentication
credentials (minus points)
/ 34
26. 26
Star Rating Example
• Let’s assume the same kernel / SSL versions
Specification RoutD RoutY
Operating System Linux Kernel 3.18.23 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 WolfSSL v3.9.0
(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
Predictable RNG with no
entropy control (minus points)
/ 34
27. 27
Star Rating Example
• Let’s assume the same kernel / SSL versions
Specification RoutD RoutY
Operating System Linux Kernel 3.18.23 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 WolfSSL v3.9.0
(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
Non-secure interface(s) with no
ability to disable (minus points)
/ 34
28. 28
Star Rating Example
• Let’s assume the same kernel / SSL versions
Specification RoutD RoutY
Operating System Linux Kernel 3.18.23 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 WolfSSL v3.9.0
(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
No commitment to FW updates
(automatic 0 star fail)
/ 34
29. 29
Star Rating Example
• What are the Star Ratings for RoutD and RoutY?
Specification RoutD RoutY
Operating System Linux Kernel 3.18.23 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 WolfSSL v3.9.0
(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
Star Rating 0 Stars 4 Stars (Until 2018)
For the period
of FW updates
/ 34
30. 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. 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. 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
