Avoiding IoT Design Flaws

We are all aware by now of the proliferation of IoT devices in the modern connected age.  However, where we continue to struggle is knowing how they are attacked, where the weak spots are, and how to take a risk-based approach to secure them. 

Devices before IoT were just that, devices. They ran on code and were made to address a specific purpose. Now, all of these devices are interconnected and communicate with each other via central control systems and services, exponentially increasing the attack surface.

Let’s first look at where IoT system vulnerabilities tend to occur:

• At the device level — Some IT leaders maintain that if they can keep attackers out of their network, they don’t have to worry about the security of individual devices. But it’s virtually impossible to keep attackers out of networks, especially when you accept the possibility that a single malicious employee, contractor, vendor, or customer could become an inside hacking threat. Even air-gapped systems are vulnerable when malware can jump the gap between systems, as famously happened with Stuxnet.
• At the software level — The largest attack surface for IoT devices is the software running on the devices and the servers they communicate with. IoT organizations might take a page from the software industry playbook that emphasizes constant software testing at all stages of design, implementation, and deployment. The most responsible software companies also ensure that security is built into their applications by properly training their developers, testers, and engineers before they write a single line of code.

When deploying a new (or enhancing an existing) IoT system, its security must be equal in priority to its functional capabilities. With that in mind, security needs and system vulnerabilities should be fully documented during the requirements, architectural, and design phases.

For IoT devices, the architectural phase is where functionality is split between hardware and software. For IoT systems as a whole, this could be where external security-related services are determined, such as Captcha, certificate services, or other forms of two-factor authentication. In addition to detailing how the IoT system meets requirements, this is also where various security-related support parameters are defined, e.g., parameterized user IDs, device IDs, passwords, tokens, certificates, sign-in times, and access rights. 

Below is a summary of high-level things to consider.  It is not meant as a comprehensive checklist, but rather to get you thinking about user and device capabilities and threats. 

User Access

• How can users access the IoT system?
  • Can they log into a cloud account or the IoT device directly?
  • Is there a mobile app that provides access?
  • What authentication mechanisms are in place?
• What are the user classifications? These classifications will affect what resources and services are accessible.
  • Which users can access which resources and services?
  • Who can make changes to info?
  • Which features and functions are available to each user role?
• What security screenings are required for each user?
  • Should passwords and/or pins be used?
  • Should electronic tokens or certificates be supplied?
  • Maybe dynamic Captchas can be factored in for determining whether an actual person is accessing the IoT system?

Device Access

• What types of devices can connect to the system? As with user access, determine the types of access extended to these external devices.
  • Can they query information?
  • Can they control certain features and functions?
  • Mobile device access allowed?
  • Which diagnostic tools are allowed?
  • What about external Cloud-based systems or previously unknown/new IoT devices?
• How can devices connect to the IoT system?
  • Wireless?
  • Wired?
  • Internet/IP?
• What is the device classification?
  • Can users make changes to information?
  • Can they control certain features and functions?
  • Can they grant other users or devices access to the system?
  • Can they Query info?
• For each external device, what type of security screenings are required?
  • Should electronic tokens or certificates be supplied?
  • Should dongles be physically connected?
  • How would they relate to user access?

Ensuring these questions are properly addressed during design will exponentially reduce risk out of the gate.