Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

IoT Ten

IoT Ten 

“At least today, with the one public IoT software platform we looked at, which has been around for several years, there are significant design vulnerabilities from a security perspective,” said Atul Prakash, University of Michigan Professor of Computer Science and Engineering. “I would say it’s okay to use as a hobby right now, but I wouldn’t use it where security is paramount.”

According to the vendor, “We’ve built an open platform that lets any product or service connect with SmartThings to improve the lives of millions — a full stack, protocol agnostic, platform for orchestrating connected devices and web services, built for inventors and partners.” Third-party developers have contributed more than 500 apps.

Prakash and Earlence Fernandes, doctoral students in Computer Science and Engineering, created a SmartApp that masqueraded as a battery level monitor. It eavesdropped on a new PIN code being set for a door lock and sent that PIN in a text message.

They also demonstrated turning off “vacation mode” and that any SmartApp could set off a fire alarm by injecting a message. “The access SmartThings grants by default is at a full device level, rather than any narrower,” Prakash said.

Samsung’s IoT woes are by no means exclusive. Serious security flaws have been found in connected cars, medical devices, and a growing number of home and office products. A security flaw in one device has the potential to impact millions of people, but what really should frighten consumers is the cumulative effect.

The root cause of this problem is obvious: As vendors rush to create competitive IoT products, they are ignoring thirty years of collective cybersecurity experience. They are, in effect, providing new meaning to George Santayana’s words from 1906, “Those who cannot remember the past are condemned to repeat it.”

Foundational cybersecurity concepts, such as least privilege, system integrity controls, and the need for security testing were formally published in 1985. Thirty-two years later, they appear in virtually every text on the subject. While genuine implementation errors do happen, many IoT flaws more closely resemble negligence.

While by no means an exhaustive list, IoT vendors and consumers should consider the following:

  1. Security requirements must be formally identified and included in all phases of product design, operation, and maintenance.
  2. Security testing is essential. Every vendor understands the need to test products prior to general availability. Positive and negative security test cases are essential and vendors should seriously consider engaging an independent third party.
  3. Vulnerability scans and basic penetration tests often reveal known flaws in IoT products. In many cases these flaws can be remediated by making simple configuration changes and applying available patches.
  4. IoT design must assume that the network to which the device is connected is untrusted. The concept of trusting the local network is fundamentally flawed, as proven by Supervisory Control And Data Acquisition (SCADA) device exploits. Placing an IoT device on a LAN behind a firewall is an additional layer of security, not a primary security control.
  5. Access control and privilege management must occur as close to the IoT device as possible, preferably within it. It is tempting to simplify IoT device design and implement controls in the cloud. For example, a thermostat might be designed to connect to a cloud service and trust it implicitly; relying on the cloud service to authenticate users and enforce access rights. This scenario places too much trust in the cloud service and increases the risk of large-scale compromises.
  6. Application frameworks that allow third-party components require strong, granular, permission-based controls. Users must review clearly stated permissions prior to them being granted. Global “do anything” permissions should not be allowed.
  7. Connection to a cloud service should be optional. It is true that many consumers want their IoT devices accessible from everywhere. Android and IOS apps that control IoT devices are incredibly popular. But in the future, as the IoT footprint expands, not everyone will wish to use this functionality. It should be possible to turn off network connectivity or use IoT devices and their accompanying apps on the LAN or via a VPN without a cloud service.
  8. Mobile and web applications for IoT devices must be considered untrusted. Developers often assume that Android, IOS, and javascript applications will execute exactly as designed and make only predictable API calls to the IoT device or cloud application. This fails to take into account the fact that attackers will reverse engineer applications, modify them, and make direct API calls.
  9. IoT devices must include strong integrity controls, including software signing and verification. While it may be tempting to allow experimenters to upload custom firmware, the same mechanism that allows the owner of a device to upload custom firmware could allow an attacker to upload firmware that compromises the device. In most cases, the security risk of allowing anything other than official, signed software to execute far outweighs any perceived benefit. Vendors seeking to be “open” should achieve this goal through a properly designed and documented API.
  10. IoT vendors should assume the software and firmware in their IoT devices and apps will be extracted, decompiled, documented, and published. Legislative attempts to prevent this are not effective. Hidden functionality, unofficial APIs, and other non-public information will become public and be exploited by criminals.

Imagine a neighbourhood in which lights, heat and air conditioning, locks, intrusion and fire alarms, garage doors, cars, entertainment systems, and refrigerator temperature controls are all Internet connected. Then imagine the chaos of an attacker taking control of them. Our society is heading closer to that reality every day without considering the implications.

Have a security question you’d like answered in a future column? Email

Related posts