arduino, cloud, Embedded, IIoT, IoT, raspberry pi, Security

The “Internet of Things” or “IoT” as it’s affectionately known, has become one of the most prevalent buzzwords of 2016.  Almost everything you touch today is somehow associated with it. Everything from smart thermostats, security systems, refrigerators and baby monitors in your home, to fitness bracelets and watches on your wrist, are connected to the Internet now.  From clothing that use coloured LEDs to reflect your mood, to children’s educational toys, all have connectivity to “enhance your life experiences”.

With the race to bring new products to this evolving market, issues of both Security and Privacy are raised for consumers. At the low end of the spectrum, an attached IoT device could expose your WiFi configuration.  On the high end of the spectrum, your personal banking, and health information could be exposed. 

Depending on who you listen to, the analysts are saying that there will be between 25-30 BILLION Internet connected devices by the year 2020… just a short 4 years from now. (Cisco says 50 Billion!)




http://hpe-enterpriseforward.com/eiu-securing-iot/


Each one of these devices is a potential
Security or Privacy liability.

  • only 33% of organizations believe their IoT products are “highly resilient” against any future cyber security threats,
  • 48% of companies focus on securing their IoT products from the beginning of the product development phase.


http://hpe-enterpriseforward.com/eiu-securing-iot/



In the past year, we have seen:


Cisco: IoT Security Timeline

Who are these “Malicious People” and why do they want to wreak havoc with our Inventions?


IoT devices and systems are typically remote sensors or controls involved in managing a process of some sort. Whether it be collecting weather information for crop management, to sensor data for proper maintenance of an automobile, temperature and humidity information for building climate control, or bio sensors for monitoring a patients health, IoT devices manage a large amount of critical information.  Critical information that could potentially be considered Private and/or Confidential in nature. 

IoT PenguinBot
By the remote nature of these devices, they are also typically designed to be “low cost” and “low energy” battery operated systems.  Function and performance are the critical design success factors, while Security has not played a significant development role to date.  MOST current IoT devices are readily exploitable through several means. 

Oh, and did I mention that most IoT devices are connected (and trusted) in some way to logging, monitoring, and analysis tools deep within the corporate infrastructure?  Find a kink in this light armour, and you can sail right past the corporate security systems in place.

What type of attacker is interested in exploiting IoT devices?  We are finding that the IoT Threat Landscape is quite varied.  Everyone from cybercriminals to government entities, hacktivists, and even insiders have shown up to the game. It’s apparently hard to resist the low hanging fruit of an easily exploitable system, that could lead directly into the corporate infrastructure.  
From stealing sensitive data by hacking IoT devices, to facilitating denial of service against a third-party entity, there are plenty of reasons and opportunities to exploit a connected Internet of Things device.



 

So, as developers, what are we to do? 

How can we ensure that our products are secure from the beginning?  What aids do we have to guide us in creating a more secure, more private consumer product?

I’m glad you asked!  There are many initiatives currently to define the obstacles and opportunities to creating a secure Internet of Things ecosystem, but there ARE some guideline that you can follow.

First, from Cyber Security company I am the Cavalry, here is a snippet of sage advice:

Security:

  1. Secure by Default
    1. No default passwords shared between devices, or weak out of the box passwords.
    2. All passwords should be randomly created using a high quality random password generator.
    3. Advanced features used by small percentage of users should be turned off by default(VPN,Remote Administration, etc…)
  2. Secure by Design
    1. Firmware should be locked down so serial access is not available.
    2. Secure Ethernet (SE) or Trusted Protection Modules (TPM) devices should be used to protect access to the firmware and hardware.
    3. All GPIO, UART, and JTAG interfaces on the hardware should be disabled for production versions.
    4. NAND or other memory/storage mediums should be protected with epoxy, ball sockets (so the memory cannot be removedand dumped), or other methods to prevent physical attack. 
  3. Self Contained Security
    1. The devices should not rely on the network to provide security. Rather, the device’s security model should assume the network is compromised, and still maintain protection methods. This can be done with prompts to the user to accept handshakes between devices trying to access other devices on their networks.
    2. Communication between devices should be encrypted to prevent MiTM attacks and sniffing/snooping.
Privacy:
  1. Consumer PII not shared with manufacturers or partners.
  2. Usage data on individual consumer is never shared with partners or advertisers.
  3. Anonymous data for buckets of users on usage patterns is acceptable as long as it’s proven to no be traceable back to an individual consumer.
  4. Data collection policy, type of data collected and usage of data is clearly documented on site.



As well, I am the Cavalry has published the Five Star Automotive Cyber Safety Program, with the purpose of bringing the industry together to standardize on a security framework for connected devices.



According to their website:  
The OWASP Internet of Things Project provides information on:

Of interest in this discussion is the topic of “IoT Attack Surface Areas”. Each one of these boxes identifies specific threat vectors to IoT product development, as well as guidance and recommendations on remediating these concerns early in the development cycle.



Ecosystem Access Control Device
Memory		 Device Physical
Interfaces		 Device Web
Interface
Device
Firmware		 Device Network
Services		 Administrative
Interface		 Local
Data Store
Cloud Web
Interface		 Ecosystem
Communications		 Vendor Backend
APIs		 Third Party
Backend API’s
Update
Mechanism		 Mobile
Application		 Network
Traffic



 IoT Security != Device Security


Attack Surface Vulnerability
Ecosystem Access Control
  • Implicit trust between components
  • Enrollment security
  • Decommissioning system
  • Lost access procedures
Device Memory
  • Cleartext usernames
  • Cleartext passwords
  • Third-party credentials
  • Encryption keys
Device Physical Interfaces
  • Firmware extraction
  • User CLI
  • Admin CLI
  • Privilege escalation
  • Reset to insecure state
  • Removal of storage media
Device Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
Device Firmware
  • Hardcoded credentials
  • Sensitive information disclosure
  • Sensitive URL disclosure
  • Encryption keys
  • Firmware version display and/or last update date
Device Network Services
  • Information disclosure
  • User CLI
  • Administrative CLI
  • Injection
  • Denial of Service
  • Unencrypted Services
  • Poorly implemented encryption
  • Test/Development Services
  • Buffer Overflow
  • UPnP
  • Vulnerable UDP Services
  • DoS
Administrative Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Security/encryption options
  • Logging options
  • Two-factor authentication
  • Inability to wipe device
Local Data Storage
  • Unencrypted data
  • Data encrypted with discovered keys
  • Lack of data integrity checks
Cloud Web Interface
  • SQL injection
  • Cross-site scripting
  • Cross-site Request Forgery
  • Username enumeration
  • Weak passwords
  • Account lockout
  • Known default credentials
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Third-party Backend APIs
  • Unencrypted PII sent
  • Encrypted PII sent
  • Device information leaked
  • Location leaked
Update Mechanism
  • Update sent without encryption
  • Updates not signed
  • Update location writable
  • Update verification
  • Malicious update
  • Missing update mechanism
  • No manual update mechanism
Mobile Application
  • Implicitly trusted by device or cloud
  • Username enumeration
  • Account lockout
  • Known default credentials
  • Weak passwords
  • Insecure data storage
  • Transport encryption
  • Insecure password recovery mechanism
  • Two-factor authentication
Vendor Backend APIs
  • Inherent trust of cloud or mobile application
  • Weak authentication
  • Weak access controls
  • Injection attacks
Ecosystem Communication
  • Health checks
  • Heartbeats
  • Ecosystem commands
  • Deprovisioning
  • Pushing updates
Network Traffic
  • LAN
  • LAN to Internet
  • Short range
  • Non-standard

As stated earlier, this is starting guidance on what to look for when building out your Internet of Things Security Framework.  For further ideas and guidance, please read the references below. 

Good luck, and happy coding.


Resources:

OWASP: Top 10 IoT Security Issues
OWASP Top Ten IoT Security – Infographic
OWASP: IoT Security Guidance
RSA Conf: Mapping the IoT Attach Surface Areas
ARSTechnica: “Internet of Things” security is hilariously broken and getting worse
ARSTechnica: Police body cams found pre-installed with notorious Conficker worm
ARM.COM: From Sensor to Server, ARM drives the Internet of Things 
Texas Instruments: Internet of Things – Opportunities and Challenges 
DEFCON 23: IoT Attack Surface Mapping
HPE: Securing the IoT
Capgemini: Securing the Internet of Things
Globe and Mail: Internet of Things a playground for hackers
Globe and Mail: The Future is Smart – Why privacy must be baked into the Internet of Things
https://www.iamthecavalry.org/
IamtheCavalry: Five Star Automotive Cyber Safety Program
https://www.theguardian.com/technology/2015/nov/26/hackers-can-hijack-wi-fi-hello-barbie-to-spy-on-your-children
http://www.computerworld.com/article/2476599/cybercrime-hacking/black-hat-nest-thermostat-turned-into-a-smart-spy-in-15-seconds.html
https://www.exploitee.rs/index.php/Exploiting_Nest_Thermostats
http://www.theregister.co.uk/2016/01/12/ring_doorbell_reveals_wifi_credentials/
Embedded: Security framework for IoT devices
NIST Releases Draft Framework on the Internet of Things
Online Trust Alliance: IoT Trust Framework
WolfSSL: Embedded SSL Library for Applications, Devices, IoT, and the Cloud
http://www.bankingexchange.com/news-feed/item/5770-5-hacks-into-your-internet-of-things-devices
https://www.helpnetsecurity.com/2016/05/09/internet-of-fail/
Cisco: IoT Threat Environment
https://blog.knowbe4.com/worlds-most-famous-hacker-kevin-mitnick-iot-is-exploitable
http://krebsonsecurity.com/2016/02/this-is-why-people-fear-the-internet-of-things/






Leave a comment