Internet Of Sieves

Enterprise-wise, Data Loss Prevention (DLP) has often been a means of "keeping honest people from doing dumb things". However, the advent of the Internet of Things and its rapid proliferation is straining the effectiveness of DLP. Sophisticated, embedded devices are permeating enterprise and home networks. Attack surfaces and data exfiltration opportunities are increasing in lockstep. The shortcomings of IoT security have been well covered, but there has been very little discussion on how to instrument and monitor the channels used by IoT devices in an effort to prevent data loss. In this talk, we will point out some of the possibilities for data exfiltration in various IoT products and the current (and possibly future) state of the art in defending against this problem.

Transcript

1. Internet of Sieves: Data Loss Prevention in the Age of IoT Zach Lanier, Principal Research Consultant Atredis Partners LiveWorx 2017 Kelly Lum Flatiron Health
2. First - RIP Sir Roger Moore (1927 - 2017)
3. About Us Zach Lanier • Security Staff Engineer at Flatiron Health • Heads the data security program, working across the organization to architect secure systems and business practices • Professor of Application Security at NYU Tandon School of Engineering • Formerly: reverse engineering, pentesting, code auditing in government and finance • Built out the Tumblr “blogs over HTTPS” initiative • Principal Research Consultant at Atredis Partners • Conducts highly technical security assessment, research, reverse engineering, and attack simulation engagements • Old-hat network, web, app, mobile, embedded, IoT, etc. security research / pentester type • Co-founder, BuildItSecure.ly (a [sadly now defunct] IoT security research collaboration) • Co-author, “Android Hacker’s Handbook” (Wiley, April 2014) Kelly Lum
4. Agenda
5. Agenda • DLP Overview • Attack Surfaces • Issues • Solutions and Recommendations • Conclusions • Q&A
7. DLP Overview
8. Data Loss Prevention • Aims to ensure users / employees don't accidentally or deliberately leak sensitive data ◦ “Keeps honest people from doing dumb things” • Used to be a hot-button topic • Panacea to solve all data leakage woes • Data breaches and “files falling off the back of a digital truck” spurred DLP
9. Typical DLP Architecture
10. Typical DLP Architecture
11. Typical DLP Workflow (Example: Trend Micro)
12. Attack Surfaces
13. DLP Attack Surface • Admin panel ◦ Typical OWASP Top 10 issues • Client <-> server communications ◦ Not adequately encrypted ◦ Flawed/ missing authorization • Parsing errors ◦ File parsing ◦ Network traffic analysis • HTTPS MitM ◦ Often buggy and weakens encryption protocols used
14. IoT Attack Surface • Administration ◦ Web panel: Typical OWASP Top 10 issues ◦ Poorly secured APIs/interfaces • Client <-> server communications ◦ Not adequately encrypted ◦ Flawed/ missing authorization • Device firmware ◦ Often not properly hardened ◦ Hard to update / log / audit • “Networkability” ◦ Do you have to punch a hole in your firewall for the device to work?
15. Issues
16. IoT Ecosystem
17. Endpoint Presence/Visibility • Mix of proprietary and commodity/open source operating systems and supporting software • System resource limitations ◦ Storage ◦ CPU ◦ Memory ◦ Power • OEM/Vendor support for third-party code may be lackluster ◦ Could be for security reasons (e.g. code signing, controlled ecosystem, etc.) ▪ "Walled garden" sadfsadfsadf Magic DLP Agent Code How do you get this... Running on these?
18. Network/Protocol Support Examples: • Infrastructure: 6LowPAN, IPv4/IPv6, RPL • Identification: EPC, uCode, IPv6, URIs • Comms / Transport: WiFi, Bluetooth, LPWAN • Discovery: Physical Web, mDNS, DNS-SD • Data Protocols: MQTT, CoAP, AMQP, Websocket, Node • Device Management: TR-069, OMA-DM • Semantic: JSON-LD, Web Thing Model • Multi-layer Frameworks: Alljoyn, IoTivity, Weave, HomeKit Source: Postscapes Source: Prismtech
19. Network/Protocol Example Scenario • An IoT device gets compromised (attack vector is irrelevant) • Attacker observes that ports 1883/tcp (MQTT) and 8883/tcp (MQTT over SSL) are allowed outbound • They use MQTT as a mechanism for exfiltrating whatever they observe on the network (files, credentials, etc.) to, say, AWS... • How would you detect/stop this?
20. Multiple Components • IoT device itself ◦ Again, lack of endpoint inspection • Mobile devices/applications ◦ Compromised / lost / unpatched devices ◦ Direct comms to the device ◦ Comms through insecure service/ middleware • Cloud services ◦ Out of control of consumer ◦ Limited (if any) introspection • Supporting devices (e.g. hubs and bridges) ◦ Outdated firmware
21. Solutions and Recommendations
22. Endpoint/Device • Ease of patching ◦ Automated patching is hard implement ◦ Manual patching is expensive for the user • Secure defaults ◦ E.g. robust authentication, protection of data-in-motion and at-rest, etc. • Logging and auditing options
23. Network • Behavioral traffic analytics ◦ "Does this device typically talk to these hosts/networks?" ▪ Could be augmented with AI/ML ◦ Terminating SSL/TLS will likely break many connections/devices that follow "best practice(s)" • Really the only layer where DLP/inspection can be applied to IoT right now
24. Network-layer Solutions • Network Intrusion Detection Systems could be adapted for DLP-esque purposes ◦ Snort ◦ Bro IDS ◦ Suricata ▪ Some efforts related to IoT exist, but not necessarily DLP-centric • e.g. https://github.com/decanio/suricata-IoT/ (though seems to be unmaintained) • Senrio Insight (commercial) ◦ Enumerates, categorizes, and monitors device behavior on the network • Pwnie Express' IoT offering (commercial)
25. Platform/Service • DLP for SaaS/cloud already exists ◦ But is fairly nascent and may not necessarily apply to services for IoT ◦ Numerous commercial vendors, but also Google Cloud DLP API + AWS-integrated DLP offerings ▪ Be mindful of permissions/authorizations
26. Conclusion
27. Conclusion • Vendors/OEMs ◦ Provide interfaces for device instrumentation/security monitoring (where possible) • Developers ◦ Take advantage of security and monitoring features of the target platform(s) -- if they're there ▪ Lean on vendors for this! • Customers ◦ Segment IoT and ICS devices and monitor those networks accordingly ◦ Education is not enough ◦ Avoid “security fatigue” ◦ Ask/ research educated questions about security before purchasing
28. Questions? zach@atredis.com https://twitter.com/quine george.sims@jukt-micronics.com https://twitter.com/aloria