name: inverse class: center, middle, inverse layout: true <div class="header"><span>@unixbigot — Christopher Biggs — The Internet of Scary Things</div> <div class="footer"><span>#LCAConfidential Linux.conf.au Security and Privacy Miniconf Jan 2017</span></div> --- layout: true <div class="header"><span>@unixbigot — Christopher Biggs — The Internet of Scary Things</div> <div class="footer"><span>#LCAConfidential Linux.conf.au Security and Privacy Miniconf</span></div> --- class: center, middle template: inverse # The Internet of  .red[**Scary**]  Things ## .green[Tips to deploy and manage IoT safely] ### or, .orange[What you need to know about the coming Toaster Apocalypse] .bottom.right[ Christopher Biggs <br>.blue[@unixbigot] ] ??? G'day, I'm Christopher Biggs. I've been involved with embedded systems since my first professional role 20 years ago, and nowadays I'm a consultant specialising in the Internet of Things, which is the new name for embedded systems that don't work properly. I work with companies developing IoT devices to help them choose the right technologies and practices to build test and deploy their products. I've also worked in financial security, I spent six years trying to stop the high-schoolers of New South Wales from watching pornography in class, and I managed a department of developers working on websites and apps for internet gambling, so you could say I know a thing or two about shady people. Today I want to tell you how to defend yourself from your toaster. --- .left-column[ # Agenda ] .right-column.tight[ ### **The Bad**: * .red[**Risks**]: What you should worry about * .orange[**Faults**]: How devices expose risks * .yellow[**Causes**]: Which factors make faults likely ### **The Ugly**: * .teal[**Interlude**]: Pointing and laughing ### **The Good**: * .green[**Buying**]: Selecting well-behaved devices * .blue[**Deploying**]: Using defensive architecture to minimise risks * .purple[**Building**]: Design desiderata for the next generation * .pink[**The Future**]: Sanity on the horizon ] ??? Tom Eastman made a very good point yesterday about the key characteristic of IoT being that you are inviting a device into your home or office that you have absolutely no control over. You don't know what threats it enables, and you have no way of examining or updating the software on it. So, first I'm going to outline some risks of deploying IoT, and talk about how and why those risks arise. Then, pretty much for shits and giggles, I'll tell you about some particularly shameful devices I've encountered. Next I'll cover what you can do to select well behaved IoT systems, protect yourself from rogue devices, and if you're building products, I'll give some points to keep in mind to avoid ending up in the hall of shame. Finally I'll finish on a brighter note and tell you about some potential light at the end of the tunnel. The Future Of Open Source IoT. --- class: center, middle template: inverse # The Internet of  .red[Insecure]  Things ## What you need to understand about the Toaster Apocalypse ??? First, I want to examine what are the risks. Late last year one of these risks was thrust to our attention when major social media sites were brought down by a denial of service attack perpetrated by a botnet of compromised video cameras. But that's just the tip of the iceberg. A disturbing proportion of common IoT devices are easily hacked due to really quite bad security on the part of the vendors. --- .left-column[ #The Bad ## Risks ] .right-column.autodim.tight[ ## What Risks do IoT devices present? #### .pink[Nudie Shower Run] video leaks * Unauthorised **retrieval** of information from your devices * Targeted intrusion (papparazi, neighbours, stalkers, creepers) * Indiscriminate harvesting of images/video/audio * Drive-by pervs * Always-on microphones/cameras ] ??? So our first risk is unauthorised access to your devices. If the device is a video camera it's pretty clear what the concern is here. Embarrassment, exploitation, blackmail, burglary. The threats vary by who the perpetrators might be. First you have to worry about people who have a malicious interest in you in particular. If you're a celebrity, or you have a vindictive ex or a creepy stalker you have something to worry about. Second, much like we're seeing self-replicating malware that scrambles files and then ransoms them back, I wouldn't be surprised to see malware attempting to harvest video and then blackmail the subjects. Would you notice if you were getting up to a bit of "netflix and chill" and the camera in your smart TV turned on? Finally there's mass data collection, either by randos driving around sniffing for vulnerable devices, or by state level actors. Let's just say that it's a matter of record that the CIA is paying Amazon six hundred million dollars to build a cloud data centre for something. --- .left-column[ #The Bad ## Risks ] .right-column.autodim.tight[ ## What Risks do IoT devices present? #### Nudie Shower Run video leaks #### "Hey, who turned out the .yellow[lights]?" * Unauthorised **control** of your devices * Quadcopters broadcasting "lights out" * Vandals/Extortion/Terrorists * Medical device tampering * Theft of service/property ] ??? Our next risk is unauthorised control of your devices. A proof of concept was done recently where some folks managed to turn off home lighting by flying a quadcopter around a neighbourhood. You can bet someone's working on the same trick for your front door. Vandalism is an issue too. I don't want to see someone work out how to wreck every garage door opener in the city, or switch off all pacemakers in the room. In terms of commercial infrastructure it might be briefly funny if someone works out how to subvert autonomous computers into delivering free petrol at the pump, or free groceries at the self serve checkout, but it wouldn't be so funny if all the traffic lights went green at once. --- .left-column[ #The Bad ## Risks ] .right-column.autodim.tight[ ## What Risks do IoT devices present? #### Nudie Shower Run video leaks #### "Hey, who turned out the lights?" #### "Hey, who turned out the .red[entire Internet?]" * **Mass takeover** of devices * Distributed Denial-of-Service attacks * Bitcoin mining * Spam (email, web, audio, video, app) * Other compute theft ] ??? The risk we saw happen last year is mass takeover of devices. In that case a collection of 160,000 IoT cameras were subverted to perpetrate a DDoS against a major DNS provider, but there's other things you could do with a fleet of compromised devices. What if your TV started showing advertisements that you couldn't turn off, or your stereo informed you that your lights would swich off and on every 500 milliseconds until pay yay many bitcoin to make them stop. --- .left-column[ #The Bad ## Risks ] .right-column.autodim.tight[ ## What Risks do IoT devices present? #### Nudie Shower Run video leaks #### "Hey, who turned out the lights?" #### "Hey, who turned out the entire Internet?" #### "What do you mean the .purple[Nazis won]?" * IoT devices as a beachhead for **network intrusion** * Corporate espionage * Identity theft * Firewalls are *so over* - uPNP, Tunnels, SDNs * Malicious/compromised cloud actors * Untrusted updates or MiTM tampering ] ??? And of course there's plain old network intrusion. Most networks are set up to defend from outside threats, but what if you just brought a threat into the building. Most firewalls aren't good enough to prevent a device from tunneling traffic to the outside. In home networks devices can just use universal plug and play to tell the firewall to forward traffic right to them. You need to stop thinking of firewalls as dividing the scary internet from the safe lan. The monsters are inside the room. And if IoT devices rely on cloud services, then there's the risk of that service being compromised or impersonated to inject malware. --- .left-column[ #The Bad ## Risks ] .right-column.autodim.tight[ ## What Risks do IoT devices present? #### Nudie Shower Run video leaks #### "Hey, who turned out the lights?" #### "Hey, who turned out the entire Internet?" #### "What do you mean the Nazis won?" #### I wish I could just go back to the .blue[Ocean] * Management is **tedious** and entirely **manual** * Finicky set-up process * Junkware mobile apps * No tools to help with patch management * No infrastructure for vulnerabity alerts ] ??? You probably just want to bury your head in the sand right now, or if you're a slightly clearer thinker, you want to round up all your household devices, go down to the beach, and bury them under half a metre of wet sand. You've got every right to be despondent. Many devices on the market finicky to install, have low quality user interfaces, and no provision for maintenance. --- class: center, middle template: inverse # The Internet of  .orange[Incompatible]  Things ## How bad practices lead to risky devices ??? This is largely due to bad practices, and that's what I want to go into next. --- .left-column[ #The Bad ## Risks ## Faults ] .right-column.autodim.tight[ ## How everything old (and awful) is new again #### Poor security * **Malicious** devices ] ??? The security on some of these devices is just criminally bad. It makes me wonder if some of these devices are deliberately broken. But Hanlon's Razor says never ascribe to malice what can adequately be explained by stupidity. --- .left-column[ #The Bad ## Risks ## Faults ] .right-column.autodim.tight[ ## How everything old (and awful) is new again #### Poor security * **Malicious** devices * **Stupid** developers * Home-brew "crypto" * Weak algorithms * Strong algorithms used badly (follow .blue[@mjg59]) * Security by (only) obscurity ] ??? There's certainly enough stupidity to go around. If you've been following Matthew Garrrett's twitter or blog you'd have heard about his reverse engineering of various lightbulbs and power devices. He's finding really lame practices like XOR in place of encryption, or use of obsolete algorithms like MD5, or misusing AES in ECB mode with fixed messages and an easily calculated key. I've seen the same things in devices I've looked at, which we'll go into soon. --- .left-column[ #The Bad ## Risks ## Faults ] .right-column.autodim.tight[ ## How everything old (and awful) is new again #### Poor security * **Malicious** devices * **Stupid** developers * **Lazy** developers * open ports * default passwords * shell script CGI * opaque user interfaces ] ??? Then there's the problems due to laziness. Leaving debug access active in production devices. Hardcoding default passwords that can't be changed, using web servers that are vulnerable to command injection. Another thing I want to touch on is usability. I completely agree with Pia's point this morning that we as geeks owe it to our friends to design products that they can understand and use. It shouldn't take a 4 year engineering degree to operate a kettle. It's a fair trade, we geeks make the world a better place, and our more grounded friends remind us to eat. --- .left-column[ #The Bad ## Risks ## Faults ] .right-column.autodim.tight[ ## How everything old (and awful) is new again #### Poor security * **Malicious** devices * **Stupid** developers * **Lazy** developers * The 1988 **Great Morris Worm** was almost 30 years ago * yet the 2016 *Mirai* botnets used basically the same vector * the same mistakes over and over ] ??? I do want to point out that all this fail is not an intrinsic characteristic of IoT. I firmly beleve we can do better. We had the same problem in the 80s with unix systems. And again in the 90s when people connected PCs to the internet. And *again* in the naughties with broadband routers that you could break into with the network equivalent of a bent bobby pin. The common culprit here is you. Well, not you you, because you're here learning. But the enemy is us. --- .left-column[ #The Bad ## Risks ## Faults ] .right-column.autodim.tight[ ## How everything old (and awful) is new again #### Poor security #### Low interoperability * Everything talks to its own cloud service * Different apps for each device * Incompatible major frameworks (walled gardens) * Wemo, Hue, Apple, Google, Amazon... * Cloud dependence * Inability to compose services ] ??? There's another way IoT is like PCs in the 80s and that's fragmentation. Everything is different, there's no reuse of services and that means either you put more resources into building a good interface for each device, or you just build a crummy half-assed interface. Guess which they chose? Once again this is something that's fixable with the right industry action, and there is some glimmer of hope that that's starting. --- .left-column[ #The Bad ## Risks ## Faults ] .right-column.autodim.tight[ ## How everything old (and awful) is new again #### Poor security #### Low interoperability #### Limited maintainability * Owners have no way to learn of vulnerabilities * Updates are rare * Vendors potentially unreachable for parts/support/recall ] ??? Once you do get a device working, you've peaked, it's all downhill from here. Most devices have no update path, and in some cases there's not even any useful brand name identification. If there's a bug, you probably won't know. If you know, then there's probably no patch, and if you complain, there's probably no-one who cares. --- class: center, middle template: inverse # The Internet of  .yellow[Unmaintainable]  Things ## Market and cultural factors that lead to bad products ??? So, why did we get this mess. --- .left-column[ #The Bad ## Risks ## Faults ## Causes] .right-column.autodim.tight[ ## Why does everything suck #### Just Because * "Ninety percent of **everything** is crap" - T. Sturgeon, 1957 ] ??? Well for a start, every barrel has a bottom. Other markets have rubbish products too. --- .left-column[ #The Bad ## Risks ## Faults ## Causes ] .right-column.autodim.tight[ ## Why does everything suck #### Sturgeon was an optimist #### Short product cycles * Slap openwrt in a box * Cruft some shell scripts * Profit! ] ??? Next up, we're still in an immature industry, things are moving fast and the technologies that exist aren't appropriate for the new applications. This will change in time. --- .left-column[ #The Bad ## Risks ## Faults ## Causes ] .right-column.autodim.tight[ ## Why does everything suck #### Sturgeon was an optimist #### Short product cycles #### Fragmentation * Businesses want to lock-in users for a variety of dumb reasons * "Industrial IoT" and building automation are awful for this * "Not Invented Here" syndrome means no building on others' work ] ??? Fragmentation is a pain. We've got to get past everybody inventing their own wheel. Big incumbents have been awful at this, and I fully expect to see a number of them get swept away. --- .left-column[ #The Bad ## Risks ## Faults ## Causes ] .right-column.autodim.tight[ ## Why does everything suck #### Sturgeon was an optimist #### Short product cycles #### Fragmentation #### Security is Hard * Humans are bad at understanding the physics of crowds * A Mirai-vulnerable IoT device gets attacked in under 2 minutes (.blue[@ErrataRob]) * Shell scripts are near-impossible to harden ] ??? Security is hard, and many people just don't understand how hard. There are enough script kiddies and organised crime rings out there, and it's easy enough to scan for devices, that you can't rely on obscurity to protect you. It used to be said that an unpatched windows PC on the internet would be compromised in an average of five minutes. Well when Rob Graham did the test with an IoT device vulnerable to the Mirai botnet he measured 70 seconds. --- .left-column[ #The Bad ## Risks ## Faults ## Causes ] .right-column.autodim.tight[ ## Why does everything suck #### Sturgeon was an optimist #### Short product cycles #### Fragmentation #### Security is Hard #### Laziness * Threat surfaces are too large * Telnet is convenient for developers...and attackers * With the great power of Unix comes you-know-what ] ??? A big proportion of known vulnerabilities are in software that doesn't need to be there. It's easy to just install a complete distribution on a device and ship it without bothering to remove unnecessary parts, and this leads to vulnerabilities that could have been avoided. In fact, it's argable that there are better choices of OS than Linux for simple applications. --- .left-column[ #The Bad ## Risks ## Faults ## Causes ] .right-column.autodim.tight[ ## Why does everything suck #### Sturgeon was an optimist #### Short product cycles #### Fragmentation #### Security is Hard #### Laziness #### Market Incentives * Consumers want fast setup, no complications * Nobody is mandating standards for security or privacy * Market Disintermediation lessens need to maintain reputation ] ??? Finally there's almost no incentive to do better. If your IoT device gets turned into a botnet zombie, you probably don't even notice. If the buyer doesn't care, the vendor doesn't have to care. --- class: center, middle template: inverse # The Internet of  .teal[Awful]  Things ## True tales of terrible consumer goods ??? All right lets take a break from doom and gloom to point and laugh. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude ] .right-column.autodim[ ## Tales of awful devices #### Security cameras and the Mirai botnet * A number of products able to be trivially compromised * Device opens root telnet via uPNP * No way to permanently change password * Too-powerful devices ] ??? First I want to tell you about the Mirai botnet and its victims. Mirai actually attacked a number of devices using a list of about 50 different known default passwords. The most commonly attacked device was particuarly stupid because it had no way to permanently change the password. You could change it but it reset at reboot. These devices use UPNP to ask the firewall to open too many ports, and they contain too much software that didn't need to be there. Once you do break into some of these devices you've got all the tools you need on board to turn them into weapons. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude ] .right-column.autodim[ ## Tales of awful devices #### Security cameras and the Mirai botnet #### Random no-name camera * Self assigns IP and opens telnet port * No documentation of existence, nor of the password * Sellers don't understand product and have no influence with manufacturer * Video feed implemented by download-this-EXE * Some sort of RTSP but undocumented ] ??? Another camera that I looked at wasn't vulnerable to Mirai, but I still don't consider it fit for use. It has a telnet server listening on port 24, but the password isn't documented, and the seller wasn't able to find out what it was either. The web interface for this camera actually served up a windows EXE file that it expected you to run. It looks like the camera would serve standard RTSP if I can work out the URL, so none of this awfulness was necessary. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude ] .right-column.autodim[ ## Tales of awful devices #### Security cameras and the Mirai botnet #### Random no-name camera #### Low end broadband routers * Root the device by embedding a shell script in your SSID * Send a UDP packet to enable a telnet interface ] ??? Another tale of woe from a few years back, there was a low end broadband router that actually had more features than it exposed in its web interface. If you knew the right trick you could activate a telnet login and use the CLI to do useful things. If you sent a particular UDP packet it would start up a login server with a default password. But there was no way to turn that off, so any device on the network can attack your router. I saw this in the wild with malware that redirected your traffic through a proxy that inserted popup ads. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude ] .right-column.autodim[ ## Tales of awful devices #### Security cameras and the Mirai botnet #### Random no-name camera #### Low end broadband routers #### Lousy Mobile Apps ] ??? Last example, I've got a number of IoT devices that I bought just to see how bad they were. When you unpack one of these devices they tell you to search for a keyword on the app store and download the matching app. But thanks to appsquatters there's 50 matching apps. I found what I believe is the right one, and it doesn't work. And even for the devices that do have working apps, the apps are badly written and probably won't ever get fixed or updated. --- class: center, middle template: inverse # The Internet of  .green[Cheap]  Things ## Advice for selecting well-behaved devices ??? Okay, end of interlude, now I want to give you some constructive advice if you're selecting IoT devices. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ] .right-column.autodim.tight[ ## Selecting well behaved devices #### Return or bin unacceptable quality * Demand good security---apply evolutionary pressure to the market * Scan your network - You may not even realise your new toaster has WiFi * Port-scan devices ] ??? First accept that you will get some duds. It's a pain to return items but that's what I recommend if they're not up to standard. You need to start looking out for unexpected wifi devices. LG announced at CES just recently that they'll be putting wifi in every appliance they make from now on. So if you buy a new appliance, look for new wifi networks or devices. Once you install a new device, port scan it to see what services its offering. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ] .right-column.autodim.tight[ ## Selecting well behaved devices #### Return or bin unacceptable quality #### Look out for stupid setup procedures * IP-over-packet-length * "Download this .EXE" * Use this unsigned driver ] ??? Don't accept devices that ask you to do unacceptable things. If they want you to run untrusted software refuse. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ] .right-column.autodim.tight[ ## Selecting well behaved devices #### Return or bin unacceptable quality #### Look out for stupid setup procedures #### Favour "big 3" framework support * Curation is beneficial * Only one hole in your firewall * Unified management interface ] ??? If all this sounds too hard, avoid the no-brand products. If you stick to items that work with Apple, Google or Amazon frameworks then you'll probably have better luck. Another big advantage of a common framework is hopefully a common management interface, and only one hole in your firewall. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ] .right-column.autodim.tight[ ## Selecting well behaved devices #### Return or bin unacceptable quality #### Look out for stupid setup procedures #### Favour "big 3" framework support #### Demand support for open protocols * Interoperability is a competence test * Composability reduces reliance on vendor services ] ??? Look for devices that support MQTT or have another open interface. If the vendor has thought about providing this kind of access then they're likely to be a cut above the rest. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ] .right-column.autodim.tight[ ## Selecting well behaved devices #### Return or bin unacceptable quality #### Look out for stupid setup procedures #### Favour "big 3" framework support #### Demand support for open protocols #### Check if open-source firmware or clients exist * Repurpose devices to suit your own framework - "Sonoff" range of open-source power control * Firewall off remote access and build your own - HomeBridge gateway enables remote access to legacy devices - Node-RED can control many devices also ] ??? You can also google around and see what the open source community has done with the device. The Sonoff range of power control devices from Itead is one that I quite like. They publish the designs, and if you don't want to use their app then you can flash your own open source firmware. I've made mine interoperable with Apple Homekit so that I can have Siri control my lights. If it's been reverse engineered, and is supported by Homebridge or Node-RED then you can choose to restrict devices to talking to services that you control. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ] .right-column.autodim.tight[ ## Selecting well behaved devices #### Return or bin unacceptable quality #### Look out for stupid setup procedures #### Favour "big 3" framework support #### Demand support for open protocols #### Check if open-source firmware or clients exist #### Check reviews or teardowns * A handful of people are effecting change by pointing-and-laughing * Review gamification drives down quality * Positive reviews are often worthless * Negative reviews are generally valid ] ??? You should look at what other people have learned about devices. Again Matthew Garrett has savaged a few products that he's investigated. Amazon is also trying to encourage trustworthy reviews with limited success. On gadget sites, most positive reviews are meaningless, because people review the device without even testing it first just to get loyalty points. If they gave a negative review you can probably believe it. --- class: center, middle template: inverse # The Internet of  .blue[Unmaintainable]  Things ## Using defensive architecture to minimise risks of deploying IoT ??? Okay, so supposing you've found a device that you can purchase without wanting to slit your wrists, what next? --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ] .right-column.autodim.tight[ ## Defensive architecture #### Sandbox your devices * Use OpenWRT? Set up a dedicated Wifi network with filters * Use your guest network * Turn off or block uPNP ] ??? First, put IoT devices on their own network if you can. If you're using OpenWRT on your wifi router you can create a separate wifi network, and make that entirely separate from your lan. If you have a stock firmware, you might still have that option, and even on a low end router you can probably create a guest network that's outside your LAN firewall. Turn off support for opening firewall holes via universal plug and play on your IoT network. Unless you're a heavy user of voip or bittorrents, just turn it off everywhere. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ] .right-column.autodim.tight[ ## Defensive architecture #### Sandbox your devices #### Plan for breaches * Set a deny-by-default access policy on your IoT network * Minimise the damage a device can do with rate-limiting * Use a dedicated network with MAC whitelisting ] ??? Next, think about what would happen if a device went rogue. It probably only needs to access one or two services, so if you work out what they are, you can limit it to only that. Similarly, you can limit traffic volume, either by using openwrt traffic shaping, or the child protection features of consumer firmware. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ] .right-column.autodim.tight[ ## Defensive architecture #### Sandbox your devices #### Plan for breaches #### Monitor device behaviour * Track what's on your network and look for new/changed devices * Learn what ports/services a device needs * Look for changes in access patterns * Look for spikes in data volume ] ??? One you've installed some devices, you ought to check on them once in a while. Check the traffic stats on your router occasionally to look for anything hinky. We're starting to see consumer tools to help non-experts do this, more about that later. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ] .right-column.autodim.tight[ ## Defensive architecture #### Sandbox your devices #### Plan for breaches #### Monitor device behaviour #### BYO cloud: Use open-source hubs over crapware * Homebridge * Node-RED (alexa) * For surveillance --- Zoneminder, Motion et.al. ] ??? Once again, if you've selected the right device you're not locked into the vendor's bogo-cloud. There's an open source project called homebridge which makes legacy devices accessible to apple's home automation framework, so you can control them from your phone, or apple tv. If you're using amazon's Alexa framework then there's another open source project called Node-RED which lets you expose hundreds of different devices to the Alexa protocol. And for surveillance cameras, there's open source projects like Zoneminder and Motion that support a growing number of low end IP cameras, and basically take over the higher functions from the rubbish original firmware. --- class: center, middle template: inverse # The Internet of  .purple[Homemade]  Things ## Design desiderata for building your own IoT products ??? I want to change tack now and give some advice for developing IoT devices. Basically it's get someone else to do the hard parts for you. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ] .right-column.autodim.tight[ ## DIY Cloud #### Apple HomeKit (and Homebridge) * Cons: curated and NDAd up the wazoo * Pros: curated and NDAd up the wazoo * At least provide a bridge * Designed for composability ] ??? One choice is apple's homekit API. Typically for apple you've got to jump through a lot of hoops to get their stamp of approval, but also that means that your product stands above the herd. If you're not going to go the route of official apple support, do consider making a module for homebridge which is an unofficial back door. Apple does the right thing by not putting too much intelligence in devices, but rather letting you compose them with a hub. If you have an apple tv you can setup so that when this sensor activates, then some other thing happens. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ] .right-column.autodim.tight[ ## DIY Cloud #### Apple HomeKit (and Homebridge) #### Amazon Alexa and AWS IoT * Excellent security built in * You (sort of) don't have to write a user interface * Standard protocols ] ??? It looks like its less of a hassle to work with amazon, but the drawback is that the amazon hub technology, the echo and the echo dot are only on sale in the US and the UK at the moment. I've been really impressed by the attention to security in amazon's framework, and it's built on the MQTT protocol so you can have your own devices talk to amazon's cloud service. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ] .right-column.autodim.tight[ ## DIY Cloud #### Apple HomeKit (and Homebridge) #### Amazon Alexa and AWS IoT #### OCF uPnP and SDP profiles * Devices self-describe their capabilities * Devices can discover each other * Reference implementation of a framework ] ??? In the open source world, there's been a bit of consolidation, with two or three projects joining forces as the Open Connectivity Foundation. They are defining a set of device profiles to allow us to reason about the capabilities of devices, and for devices to discover each other. This builds on the good parts upnp and service location protocol. They have a reference toolkit called iotivity which has apis in C, C++ and Java. Not the languages I would have chosen. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ] .right-column.autodim.tight[ ## DIY Cloud #### Apple HomeKit (and Homebridge) #### Amazon Alexa and AWS IoT #### OCF uPnP and SDP profiles #### No-app setup * Maintaining an app is a lot of work * Provide simple web setup * Provide an API * Decentralise ] ??? Anyway moving on, don't please don't rely on a mobile app for setup. Sure you can make one, but provide some way to do installation with an API or a web interface. The people installing a thousand sensors in a new facility will thank you. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ] .right-column.autodim.tight[ ## DIY Cloud #### Apple HomeKit (and Homebridge) #### Amazon Alexa and AWS IoT #### OCF uPnP and SDP profiles #### No-app setup #### Support MQTT * This is the glue that binds the IoT together * IRC for robots * Open-ended extensibility * Support client-certificate auth ] ??? Similarly, support MQTT as an option. This is a message bus technology that is designed to be very lightweight. If you speak mqtt you can interoperate with amazon, and node red, and a lot of other automation frameworks. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ] .right-column.autodim.tight[ ## DIY Cloud #### Apple HomeKit (and Homebridge) #### Amazon Alexa and AWS IoT #### OCF uPnP and SDP profiles #### No-app setup #### Support MQTT #### Long term support * Make devices self-documenting * Provide updates or GTFO * Don't be lazy and stupid ] ??? On device support, recognise that everyone will lose the instructions. Put a copy of the instructions in the device, or a least a link. You need to decide what the support life of the device is going to be. I want you to strongly consider building in a fail-safe mechanism, so that if there's a critical flaw that you can't fix, owners can disable features to mitigate it. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ] .right-column.autodim.tight[ ## DIY Cloud #### Apple HomeKit (and Homebridge) #### Amazon Alexa and AWS IoT #### OCF uPnP and SDP profiles #### No-app setup #### Support MQTT #### Long term support #### Avoid the "hack-in-a-box" * Don't just ship a miniaturised Unix PC * Security awareness training * Automate your build pipeline for dev/prod/test firmwares ] ??? Last piece of advice for developing products, recognise that an IoT device is different from a PC. Limit what software you put on the device. This can be inconvenient for development, so automate it. Make sure that you build a debug, test and production version of each release rather than just shipping all the debug tools where malware can make use of them. --- class: center, middle template: inverse # The Internet of  .pink[Shiny]  Things ## How the next generation of IoT frameworks will improve the situation ??? Almost finished, the last thing I want to go into is the light at the end of the tunnel. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim.tight[ ## Future trends and tools #### Standards * BITAG (Google, Intel, Microsoft et.al) * Open Connectivity Foundation * Bruce Schneier weighs in ] ??? Various groups in the industry have recognised we need to get serious and are doing things There's a mob called the broadband internet technology somethingorother which got google and intel and microsoft and others on board to produce a recommendation on best practices. Basically, they agree with what I've been telling you today, their recommendation boils down to "don't be lazy and stupid". I've already mentioned the Open Connectivity Foundation and I approve of the work they're doing. Finally, Security Guru Bruce Schneier has been writing about IoT recently. He thinks we need stronger regulation in the market. This has the potential to go badly wrong, but I think if it were essentially an extension of radio emissions testing to include core best practices for internet security, I could get behind that. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim.tight[ ## Future trends and tools #### Standards #### Google Android Things * Very new, but promising * Standard device profiles * Curated device program * "Weave" framework for discovery and management ] ??? Big news recently is that google shipped a developer preview of their android things toolkit. I've had a look at this, and it's not really ready for prime time yet, it only supports a limited set of devices, lightbulbs, tvs and switches at this time. But the technology stack looks promising. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim.tight[ ## Future trends and tools #### Standards #### Google Android Things #### Apple Homekit * (Too?) strongly curated * Good composability * Remote access via home gateway * Standard security camera interface * Legacy devices via homebridge ] ??? I've told you about apple's offering in the space, and I won't repeat too much of that. One more thing that's good is that they have a standard camera interface, so if your camera supports apple either directly or via homebridge then you can throw away the bundled interface and control your camera using a homekit app, or voice. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim.tight[ ## Future trends and tools #### Standards #### Google Android Things #### Apple Homekit #### Amazon Alexa * Very open (even BYO device) * "Echo" hardware only on sale in USA and UK * Extensible (eg Node-RED) * Ecosystem is collection of small(ish) parts * Privacy concerns: TLA-compatible? ] ??? Amazon's framework is good, but there's been some concern about how much it listens to. Testing appears to show that it only communicates with the internet when you speak the magic word, but given the united states track record I'd be cautious about the possiblity of a back door. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim.tight[ ## Future trends and tools #### Standards #### Google Android Things #### Apple Homekit #### Amazon Alexa #### Open Connectivity Foundation IoTivity * Discovery and management * Multi language support (but not the right languages) * Steep learning curve ] ??? Iotivity is one to watch too, but I'm not in favour of implementing IoT projects in C or Java, I do hope they widen their language base. I really don't want to come across as a language snob here, but to write secure software in C you have to be really careful. Even experts stuff it up. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim.tight[ ## Future trends and tools #### Standards #### Google Android Things #### Apple Homekit #### Amazon Alexa #### Open Connectivity Foundation IoTivity #### Resin.io * Open source * Linux and Docker based * Device management and update * More aimed at enterprise/industrial than consumer ] ??? I want to throw one more framework into consideration and that's resin.io. They're open source, and they've got some really good tools. The gist of this platform is that you write in whatever langauge you want and push your code to a repo on their site, and they compile it and wrap put it in a docker container that is sent out to your devices. The devices all maintain an openvpn connection back to their cloud, so you can monitor their status and do remote upgrades or reboots or shutdowns. The drawbacks are that it only supports three particular single board computers, and it's really more aimed at enterprise use than consumer grade stuff. But if you're doing a project that fits within those parameters, you should definitely check it out. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim.tight[ ## Future trends and tools #### Standards #### Google Android Things #### Apple Homekit #### Amazon Alexa #### Open Connectivity Foundation IoTivity #### Resin.io #### Consumer IDS * Track and manage what's on your network * Alert on rogue devices * Fing app, and FingBox device (fing.io) * Ubiquiti UniFi and AmpliFi (ubnt.com) ] ??? I want to shout out to some technologies that will help consumers. Fing is a mobile app for scanning your network. They're also about to ship a little hardware device that you install and it monitors your network and the traffic. Basically its an intrusion detection system for networks without a sysadmin. I think it's a great idea. There's also an offering from Ubiquiti that's a little more high-end but does nice stuff. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim[ ## Missing pieces #### Network access policy framework * "Anything the client initates is OK" doesn't scale to IoT * Devices need to self-describe ] ??? Okay home stretch here. What's missing. I think we need to move beyond letting every device connect to whatever it wants. I want to see the device profiles from OCF and Google include a network access policy that says what the device is allowed to do. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim[ ## Missing pieces #### Network access policy framework #### Initial network authentication * There's no good solution here * A standard is needed ] ??? There needs to be a secure and scalable way to let devices onto your network. Something analogous to DHCP for getting a wifi password. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim[ ## Missing pieces #### Network access policy framework #### Initial network authentication #### Vulnerability alerting * How to get the word out to device owners * Directory-based solution (a-la SPF) * SDP "I am a vulnerable device" ] ??? We need to work out how vulnerability alerting will extend to IoT. I can tell you I'm never going to get any of my relatives to subscribe to Bugtraq. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future ] .right-column.autodim[ ## Missing pieces #### Network access policy framework #### Initial network authentication #### Vulnerability alerting #### Patch distribution * I really like resin.io * Centralised is bad, however * Again, standardisation would be great ] ??? And when we find a vulnerability, we need to get patches out to devices. There's a few frameworks that have done great work here, but I think a common standard is needed. --- class: center, middle template: inverse # The internet of  .silver[Friendly]  things ## Conclusion: What have we learned, how to learn more ??? OK quick recap. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future # Coda ##   ] .right-column.bulletsh4[ ## Recap #### Immature industry brings Confusion, Faults, Risks #### Buyers: Choose devices with care #### Installers: Deploy Defensively #### Coders: Don't be Lazy and Stupid #### Frameworks: Here comes the cavalry ] ??? Things are pretty awful, but that's not unexpected. If you choose devices with some care, you can install them in such a way to mitigate many risks. If you're building devices, you can do the right thing. And its going to get easier over the next year as the new frameworks mature. --- .left-column[ #The Bad ## Risks ## Faults ## Causes # The Ugly ## Interlude # The Good ## Buying ## Deploying ## Building ## Future # Coda ##   ] .right-column.small.tight.bulletsh4[ ## Resources, Questions ### Links #### Android Things developer preview - [developer.android.com/things](https://developer.android.com/things/index.html/) #### Node-RED - [nodered.org](https://node-red.org/) #### Homebridge - [github.com/nfarina/homebridge](https://github.com/nfarina/homebridge) #### IoTivity - [openconnectivity.org](https://openconnectivity.org/resources/iotivity) #### resin.io - [resin.io](https//resin.io/) ### About me #### Christopher Biggs - Twitter: .blue[@unixbigot] - Email: .blue[christopher@biggs.id.au] - Hire Me: http://christopher.biggs.id.au/ ] ??? I hope you've found that useful, and if not, I'll meet you at the beach with my shovel. I'm currently working with a number of companies to guide their products and practices, so get in touch if you need my help. Thanks for listening.