Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ryan Wilson - ryanwilson.com - IoT Security

600 views

Published on

A practical approach to managing the security of iot devices in your organization

Published in: Technology
  • Be the first to comment

Ryan Wilson - ryanwilson.com - IoT Security

  1. 1. IOT Security -- A practical guide Ryan Wilson, BCom, CISA www.ryanwilson.com - @ryansdwilson on twitter
  2. 2. Agenda 1. What is IoT? 2. Why should I care? 3. How is it affecting others? 4. IoT CMM - Basic Hygene Checkup? 5. Common Attack Vectors and Practical Mitigation Strategies 6. Questions
  3. 3. What is IoT anyways?
  4. 4. Any device on your network that isn’t a computer
  5. 5. Examples ● Building & Plant Automation (HVAC, PLC, SCADA, Thermostats) ● Sensors ● Print Servers / Printers / Scanners ● IP Surveillance Cameras ● Physical Access Control Systems & Intrusion Alarms, Intercoms ● Televisions/Displays, Audio Equipment, ● Video Game Consoles ● NAS - Storage Appliance ● Credit Card Payment Terminals ● [Routers, Firewalls, Switches, Wireless APs, Wireless Point to Point (Trango)] ● Facility Backup Generator ● WIFI enabled…..
  6. 6. What is so different about these devices versus traditional computers?
  7. 7. Why is this different from any other device? 1. Who is responsible for the device and the software running on it? a. IT? b. Manufacturer? c. Vendor? 2. Who makes the decisions about when the device software is updated? a. IT? b. Manufacturer? c. Vendor? d. No one? 3. How familiar are your resources with the technology stack? (BSD Microkernel, RabbitMQ & Zigbee versus Windows 10/ Ethernet TCP/IP)
  8. 8. Why should we care?
  9. 9. Why should we care? Rapid growth of device count Traditional IT security program tends to exclude (Anti-Virus, Active Directory, etc) Often introduced via Shadow-IT Generally poor security posture Often these devices control really important things Real, material hacks actively occurring
  10. 10. Impact of Compromise ● Compromise of device functionality - the device could be important! Vehicle computer, electricity, front gate ● Compromise of device data - data integrity vs data value. Consumption Meter vs Payment Terminals. ● Launch of attacks against others - Mirari Botnet Attack for example ● Launch point for attacks against your assets - Network Traversal/Pivot
  11. 11. State of the Union
  12. 12. 70% Of internet connected IoT devices contain critical vulnerabilities http://h30499.www3.hp.com/ t5/Fortify-Application-Security/HP-Study-Reveals-70-Percentof-Internet-of-Things-Devices/ba-p/6556284#.VHMpw4uUfVc
  13. 13. HP Study Reveals... 1. Privacy Concerns 2. Insufficient Authorization 3. Lack of transport Encryption 4. Insecure Web Traffic 5. Inadequate software update protection
  14. 14. Examples
  15. 15. Mirai botnet attack - Largest DDOS attack in history - Didn’t materially negatively affect device owners… that we know of - But, in many cases it was security infrastructure that was fully rooted/pwned!!! - Eliminated other malware from devices - Thought to be a test of cyber weapon capabilities - Vulnerable new devices connected to the public internet generally compromised in less than 10 minutes. Some in less than 60 seconds. Update - Friday Dec 2 - “New Mirai Worm Knocks 900K Germans Offline”
  16. 16. 1 week after DT Attack.... TR-064 (a.k.a., CPE WAN Management Protocol, or CWMP) is a widely used protocol many ISPs employ to remotely manage network routers. Its communication occurs on port 7547, to which remote commands are sent.
  17. 17. Finland A Distributed Denial of Service (DDoS) attack halted heating distribution at least in two properties in the city of Lappeenranta, located in eastern Finland. In both of the events the attacks disabled the computers that were controlling heating in the buildings.
  18. 18. Attack Knocks Out SF Transit System Fare Terminals The San Francisco Examiner responded to the address and got a response from the purported attacker who demanded 100 Bitcoins, worth approximately $73,000, to restore the systems.
  19. 19. Basic Hygiene Checklist / IoT CMM
  20. 20. Context - all too often... ❏ we jump to buying vendor solutions -- hint -- you don’t need to buy anything to secure your IoT devices. ❏ we have trouble communicating with management about risks ❏ we invest time, money and other resources into edge cases whilst neglecting the basics.
  21. 21. Level 0 - Do we care? ❏ Do we believe that IoT devices pose a risk to our organization?
  22. 22. Level 1 - Situational Awareness ❏ Do we have an inventory of what we have? ❏ Do we know if it is patched and has good passwords? ❏ Can we detect new devices when added automatically within a reasonable amount of time? ❏ Would we know if devices started making a new outbound connection they had not been making before?
  23. 23. Level 2 - Responsability ❏ Have we established responsibility for devices, patches and network privileges?
  24. 24. Level 3 - Mitigate Primary Risks ❏ Has the responsible party ❏ Set good passwords on devices ❏ Limited network access to required level ❏ Patched devices regularly
  25. 25. Level 4 - Operationalized Responsibility ❏ Has the responsible party developed a program for our IoT devices including the following functions ❏ Planning / Procurement ❏ Security / Configuration Standards ❏ Privacy / Data Issues ❏ Maintenance ❏ Monitoring
  26. 26. Common Attack Vectors & Practical Mitigation Strategies
  27. 27. If you walk away with two things from this talk 1. Does my Internet of Things device really need Internet Access? a. No Any : Any rules! 2. PASSWORDS! a. CHANGE THE DEFAULT PASSWORDS b. USE PASSWORDS c. USE GOOD PASSWORDS d. USE UNIQUE PASSWORDS on each DEVICE
  28. 28. Network Segmentation 1. Business justification for level of network access: a. Inbound? b. Outbound? c. Limited In/Out? d. Corporate network? e. Other devices on network segment? 2. Consider switchport level access controls a. Especially for devices in insecure areas. b. Beware of MAC address spoofing 3. Use NAC 802.1x if possible 4. Require VPN access into IoT segment - even from within office/LAN 5. Leverage on-device SDN / VPNs to avoid segmentation / any “internet” access
  29. 29. Passwords Passwords Passwords ● No password passwords ● Defaults or commonly known root/root admin/admin ● Backdoors (Trango) & others ● Same password on all devices. ● Domain admin passwords used out on devices
  30. 30. Passwords - What to do 1. Extend password policies beyond Active Directory to all devices. 2. Signed password policy from vendors regarding a. backdoors, b. unique passwords per client, c. Protocols for protection of passwords to clients devices 3. Test for defaults 4. Logging to detect use and/or attempts
  31. 31. Logging ● Do your devices log to a central, tamper proof, off-site location? Papertrail App $25 / month or setup Elastic Search & Logstash for free in your own DC ● Use saved search alerting to detect config changes, password failures, firmware updates etc.
  32. 32. Patches, Updates and Integrations ● Availability of patches versus device lifespan - ○ Will you be using that wifi light-switch in 20 years? ● Murky Responsibility Hierarchy for device patching IT? Vendor? Manufacturer? ● Functionality changes with updates -- Know anyone who “waits” to update their iPhone? ● Deep integration of IOT devices from multiple manufacturers makes coordinating firmware upgrades challenging and risky.
  33. 33. Vendor & Manufacturer Issues Traditional, offline device vendors are thrust into becoming cloud/IP/software companies. ● The lifetime of a product, if successful, will go far beyond that envisaged or desired by the vendor from a sustainment, maintenance and support perspective. ● Accessibility of a product’s control surface goes from standing in the same room to anywhere on the LAN or anywhere on the internet. ● Fixed capabilities and features transition to continuously expandable. (Tesla gets over the air updates versus my F150 that has trouble with my iPhone 7)
  34. 34. Vendor & Manufacturer Issues ● Backdoors, Vendor/Support Logons often shared across devices ● Security devices (Intrusion Alarm, Security Cameras, Access Control) installers don’t have IP/Cloud competencies. Diesel Generator repair man now firewall expert! ● A prominent intrusion alarm vendor in Canada accidentally revealed to me they use the same installer code on every alarm they install. Including gov, hospitals, prisons, banks. Same programing key as well. Key stored in plaintext. All we need is the public IP of any of their customers and we can remotely control the alarm.
  35. 35. Target - Data breach anyone? 1. Vendor’s (windows) workstations compromised via malware / RAT tools 2. Vendor’s RAT credentials stolen 3. Pivot from poorly segmented HVAC network to payment network
  36. 36. Vendor & Manufacturer Issues ● Data Leakage ○ How much of your data is the vendor/manufacturer entitled to? ○ What diligence did the vendor/manufacturer do on their staff and their vendors? ○ When you stop using the device do you get your data back? ○ How do you deal with right to be forgotten legislation by your customers when you don’t have access to the vendor’s systems? ○ Do you have an agreement with your vendor on what data they are allowed to keep?
  37. 37. Vendor Engagement / Procurement Questions? ● How long will they support the device with security updates? ● Are updates digitally signed? ● Encryption Cypher Quality? ● What vendor operated services to the devices depend on? ○ How are they secured? ○ What is their guaranteed lifespan? ● What remote access will you want / do you have to the devices? ● How is your remote access workstations/people secured? ● Written backdoor statement. ● Who will be responsible for this device? ● Do we accept the risk of needing to unplug the device if it becomes compromised?
  38. 38. Encryption...or lack thereof ● No encryption or digital signing of firmware updates ● Unencrypted communications (RTSP, SIP, HTTP admin consoles) ● Self-Signed Certificates ● Weak or outdated cyphers ● “What portion of your clients would you say use SSL between their DVR and IP Cameras” “You’re the first person I’ve spoken to that wants to enable SSL. Are you sure you want to spend all that bandwidth and CPU?” --Largest vendor of IP CCTV in the world.
  39. 39. Control/Programming Workstations ● Control workstation compromise. Often the “security workstation” or “card printer” is sitting in a closet or under the security guard’s desk. ○ Often not secured to domain standards ○ Vendor set the password when system was installed 8 years ago ○ Often running outdated and unpatched versions of windows subject to easy RAT tool installation. ● Lock up these devices physically (migrate to DC and use RAT/IPKVM tools if possible) ● Isolate workstations with in/out ACLs. Teamviewer and other tools are common and dangerous. ● Binary Whitelisting via Group Policy. Disable web browsers. ● Use Anti-Virus ● Leverage centralized directory on these machines
  40. 40. Discovery / Inventory ● Not even being aware it is there... ● Have a method to discover new devices on your network [alienvault, SIEM, dhcp etc] ● Establish a policy and inventory of non compute network connected devices in your organization ● Inventory should outline who is responsible for the device, patches, passwords and business justification for level of network access
  41. 41. Physical Compromise ● Often Serial/USB/JTAG firmware updates possible with physical access. No digital signature/secure boot / TPM module ● Simple substitution (common with payment terminals) ● Use of network jack in public area to traverse corporate network. Switch Ports in trunk instead of access mode. No VLAN ACLs. ARP Poisoning
  42. 42. Physical Security - Lessons from PCI ● Tamper Tape/Substitution detection. Hi I’m from the printer repair depot here for your annual imaging unit changeover. ● Detect switch port status change events on your switch infrastructure. Either a reboot or substitution. ● Fill USB/JTAG ports with glue ● Use Security screws! ● Record serial numbers! ● Unique Digital Certificates for mutual authentication
  43. 43. email@ryanwilson.com - 604.716.2222 www.ryanwilson.com - @ryansdwilson on twitter Thank you! Ryan Wilson

×