Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Internet Of Sieves

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.

C65347082fd2c5ec7c783f214e2d49e0?s=128

Zach Lanier

May 23, 2017
Tweet

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
  6. None
  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