This document provides a summary of an IoT security presentation. It discusses what IoT devices are, why they pose security risks, and how others have been affected by IoT compromises. The presentation then outlines a basic IoT security checklist and covers common attack vectors like weak passwords, lack of encryption and patching, and physical security issues. It emphasizes the importance of inventory, segmentation, strong unique passwords, logging, and engagement with device vendors on security responsibilities and practices.

1. IOT Security -- A practical guide
Ryan Wilson, BCom, CISA
www.ryanwilson.com - @ryansdwilson on twitter

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. What is IoT anyways?

4. Any device on your network that
isn’t a computer

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. What is so different about these devices
versus traditional computers?

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. Why should we care?

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. 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. State of the Union

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. HP Study Reveals...
1. Privacy Concerns
2. Insufficient Authorization
3. Lack of transport Encryption
4. Insecure Web Traffic
5. Inadequate software update protection

14. Examples

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

19. 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.

20. 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.

21. Basic Hygiene Checklist /
IoT CMM

22. 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.

23. Level 0 - Do we care?
❏ Do we believe that IoT devices pose a risk to our organization?

24. 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?

25. Level 2 - Responsability
❏ Have we established responsibility for devices, patches and network privileges?

26. Level 3 - Mitigate Primary Risks
❏ Has the responsible party
❏ Set good passwords on devices
❏ Limited network access to required level
❏ Patched devices regularly

27. 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

28. Common Attack Vectors &
Practical Mitigation Strategies

29. 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

30. 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

31. 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

32. 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

33. 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.

34. 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.

35. 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)

36. 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.

37. 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

38. 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?

39. 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?

40. 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.

41. 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

42. 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

43. 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

44. 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

45. email@ryanwilson.com - 604.716.2222
www.ryanwilson.com - @ryansdwilson on twitter
Thank you!
Ryan Wilson