Internet of Sieves: Data Loss Prevention in the Age of IoT Zach Lanier, Principal Research Consultant Atredis Partners LiveWorx 2017 Kelly Lum Flatiron Health 

First - RIP Sir Roger Moore (1927 - 2017) 

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 

Agenda 

Agenda ● DLP Overview ● Attack Surfaces ● Issues ● Solutions and Recommendations ● Conclusions ● Q&A 

No content

DLP Overview 

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 

Typical DLP Architecture 

Typical DLP Architecture 

Typical DLP Workflow (Example: Trend Micro) 

Attack Surfaces 

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 

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? 

Issues 

IoT Ecosystem 

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? 

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 

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? 

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 

Solutions and Recommendations 

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 

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 

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) 

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 

Conclusion 

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 

Questions? [email protected] https://twitter.com/quine [email protected] https://twitter.com/aloria