Your IoT Baby Isn't as Beautiful as You Think It Is

There is a hilarious episode of Seinfeld in which Jerry and Elaine stand over a crib to get a glimpse at their friend's new baby. The little cherub isn't exactly beautiful, and Jerry's reaction to the seemingly ugly baby is priceless.

My reaction to the majority of Internet of Things-enabled products I see when meeting with product managers who think their "baby" is beautiful isn't much different. In almost every case, the baby is indeed very ugly — and by that, I mean horribly insecure. (I even had the same reaction to one product although the product manager was so proud of it that he got a tattoo to commemorate its launch!)

To be fair, building a secure product is difficult. From mitigating physical security attacks to securing thousands of lines of application code, it's no easy task. Furthermore, now that many physical products are connected to the Internet, these security concerns are exacerbated. That refrigerator is no longer just a refrigerator; it's also an IoT device, and its vulnerabilities are exposed to hackers.

Yet nine out of 10 product teams I meet believe they have security under control or believe their product will never be attacked because it is uninteresting, or even boring, to attackers. "What attacker cares about my Internet-connected toothbrush?" I heard earlier this year. You might be surprised how many do. It doesn't help that, more than ever before, products are increasingly storing more information on consumers and their habits. For these reasons alone, boards of directors are starting to pay attention. The recent action by the FTC against D-Link has been an eye-opener for many.  

Blatant negligence by device manufacturers, such as easy-to-guess default administrative credentials and unpatched underlying operating systems, are unlikely to be tolerated by regulators or the market much longer. Over the past several months, cameras have been in the news often. The Mirai botnet took advantage of this negligence to enable huge distributed denial-of-service attacks. As an example, unprotected remote access capability was found in over 80 Sony IP cameras, many of which were involved in those attacks.

There are several common themes I've heard while talking with hundreds of developers over the last few years. They are utilizing commodity hardware, a hardened operating system like Android, and public cryptography; the product has been evaluated by an internal company penetration testing team; and, last but not least, there is nothing to see here. "Short of zero-day vulnerabilities, we have nothing to worry about," is what many people say and truly believe.

My experience says they are often very wrong, and they're creating huge liabilities for their companies. And even if they are right, it's almost certain that a zero-day vulnerability will be released during a product's lifetime. What is the plan for when that happens? Will the product have additional hardware safeguards that can mitigate the vulnerability? Or will the company have a secure update mechanism to allow for fast deployment of mitigations?

Yes, it's possible to design an extremely secure product, but it's critical to discuss the fallacy of secure product design. A few PhD-level security experts can design an extremely secure Internet-connected toothbrush. It will check your plaque against others in your neighborhood securely in near real time. The problem comes at implementation time. Although a product designer may be using commodity components and follow best practices, the devil is in the implementation details. Did every developer follow every design specification? Were all the cryptography algorithms properly executed? Was every third-party library verified for security? In a huge system, probably not. 

[Check out the two-day Dark Reading Cybersecurity Crash Course at Interop ITX, May 15 & 16, where Dark Reading editors and some of the industry's top cybersecurity experts will share the latest data security trends and best practices.]

And evaluating a product is just as difficult as securing it. For physical devices, the use of a red team simply isn't enough. Red teams tend to evaluate the interfaces and focus their energy on the outer defensive layers. Products demand deeper assessment, often requiring a lab setting, to fully ferret out vulnerabilities. For example, physical products are potentially vulnerable to network-based attacks, which red teams are good at finding, but they also could be open to physical attacks, which red teams typically aren't as good at uncovering. Product makers must be asked about what happens when someone opens up one of their products and extracts the software or, if it exists, the private key. Many simply have no idea, and that can only lead to major problems down the road.

When looking at Internet-enabled products, the following are the top security concerns companies should look at:

IoT device manufacturers must deliver capability fast on devices that are low power and don't have significant processing capability. Because speed is often the enemy of security, a solid device security strategy is paramount for anyone building a device. That strategy must include robust technical mitigations, secure development techniques, and both internal and external product security reviews. By taking this approach, instead of hordes of ugly babies on the market, we'll see many more beautiful ones, which should lead to a significant reduction in hacks in the years ahead. 

Related Content: