not protectively marked iaac: “internet of things” 16/11/12
TRANSCRIPT
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
IAAC: “Internet of Things”16/11/12
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Originator Control
This is an unpublished work created in 2012, any copyright in which vests in Labelled Security Limited. All rights reserved.The information contained in this document/record is proprietary to Labelled Security Limited unless stated otherwise and is made available in confidence; it must not be used or disclosed without the express written permission of Labelled Security Limited which may be given by contract. This document/record may not be reproduced in whole or in part in any form without the express written consent of Labelled Security Limited.
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
About Me
•“Just another maverick British inventor?”
–Technical advisor to some Very Nice People in central London...–multilevel / cross-domain security advocate and solution architect-designer-builder–threat and adversity model developer–ex Sun Microsystems•Sun UK's “Mr Security”•co-inventor of Adaptive Security
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Agenda•The New Landscape•Constraints•Threats and Modelling•Opportunities: IPv6•Opportunities: Simplifying the Stack•Trusted Computing•Conclusion?
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
The New Landscape
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
The New Landscape•Every “thing” Connected•...well, sort of–not necessarily all the time•resilience in the face of connectivity loss–proxies (and NAT, but NAT may go away)•Wildly nonlinear•“The” Internet of things?–one, or many?•Can “connected” be taken as a given?–“needs power” = “needs network”?
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
The New Landscape•Networking...–more self-organising, than static–more wireless, than wired (probably)•...and, therefore, flatter–meshes - opportunistic and speculative comms–how to segregate? (crypto? inverse-square?)–how to do assurance?–how might an IL6 lightbulb need to differ from an IL0 lightbulb?–“all speakers can be mics”
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Constraints•Embedded systems, capability and power...–low power consumption•low memory•very small storage capacity•low clock rate•A different software engineering mindset–skills are still “niche”–power outages (and crashes) are normal operation
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Constraints•Different hardware and software platforms–VxWorks, QNX, INTEGRITY etc...•...and languages–Erlang, etc•...and patchability–medical systems: need for re-certification means you get to patch once every 5 years!•...and operation continuity requirements–some things “just can't go down”
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Constraints•Mesh networks...–speculative forward connectivity•lots of duplicate packets•encourages information disclosure–timeouts cease to be meaningful•RTTs could be measurable in weeks!–being “out in the digital sticks”–time gets to be even more relative•can't rely on NTP
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Constraints
•Crypto–low memory•ECC–low power•“balances of crackability”–key management: oh boy...•distribution and storage•verification, renewal and revocation•all on massive scale
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Threats and Modelling•Set your Time Machine for 1995...•“SCADA” is a Dirty Word...–Stuxnet, Duqu, Flame, etc–Shodan•Physical tampering•Security through Obscurity•“Unexpected” connectivity•Industrial Safety models needed–...as well as the usual CIA, STRIDE, etc•Available examples
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Mitigation•Rate of config change is itself a significant risk!•Device-centric approaches to mitigation:–bastions and proxies–device replacement–in-place software update / patching–novel approaches (eg Abatis)–properly appliantised systems: root “beyond use”•Anonymisation and context obscuring•Physical resilience, Trusted Computing–attested boot, system measurement...
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Opportunities: IPv6•Biggest technology update in Internet historyLooks scarier than it is (eg 2001:0db8:85a3:0000:0000:8a2e:0370:7334)
–if IPv4 is “a.b.c.d”, for IPv6 carry on until you get to “p”•“Goodbye, NAT” (well, you still have FE80::, FECx::)
•Intrinsic IPsec (IPv4 implementation was a backport)
–IKE still a horror•New peer-based address self-assignment mechanism (addr duplication risk?)
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Opportunities: IPv6
•Is the address space really big enough?
–Plenty of “addresses per square inch of Earth's surface” (3x10^21, apparently)–but subnetting and self-assigned addressing schemes are wasteful of address space–site-local FECx:: helps, but...•Is the new limit actually TCP/UDP ports?
–still only 65536 of them• IPv4 / IPv6 translation and interop, for first few years–see CloudFlare
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Opportunities: IPv6•Traps and / or Opportunities
–Hofstadter•numbers in addresses as descriptive vocabulary•eg http://www.mitre.org/work/tech_papers/2012/12_0928/•mapping advertised services to address vocab–Address allocation “lumpiness” an issue?•https://www.cs.columbia.edu/~smb/papers/v6worms.pdf
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Opportunities: Simplifying the Stack
•Satirical axiom: "Every problem in computing can be solved, by adding another abstraction layer"•Counter-axiom: "...except security, where every abstraction layer is another opportunity for Something To Go Wrong".•Further counter-axiom: "All protocol refactoring does, is move the same problems to different parts of the stack, while introducing new ones via added complexity" (see “Muffett's 1st Law”)•So, final axiom: "Hiding complexity is papering over the cracks. Lose the complexity, where possible".
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
There's Too Much Here!
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Opportunities: Simplifying the Stack
•Reducing network protocol proliferation–“If 'The Network is the Computer', right now it looks like a VAX”•cut duplication, drop as much complexity as sensible, make popular protocols fulfil multiple duties•make remaining protocols do double-duty where feasible•twisting existing things to new purposes...
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Opportunities: New Standards
•Requirements for IoT network protocols:–Configuration–Command and Control–Reporting and Alerting–Querying–Audit•...are we done? (well, there's ID for Billing...)–https and ssh cover all but Reporting and Alerting...–but see key management
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Trusted Computing
•Physical key security•Integrity checking–hardware measurement–boot attestation•Secure crypto key management–typically slow and low-capacity–...but see ARM TrustZone•(changes other “rules”, too)•So, when we have a huge, flattish, dynamic Internet filled with a “sea of TPMs”...?
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Trusted Computing and Identity
https://blogs.oracle.com/davew/entry/identity_unbound
NOT PROTECTIVELY MARKED
NOT PROTECTIVELY MARKED
Conclusion?
•New ways of thinking about networks–and platforms–and protocols–and partitioning / segmenting–and identification / billing–and crypto (especially key management)•Many of the rules for bigger, static systems don't work•It's going to be exciting•Novel(ish) Failures Will Happen