Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

02:00 PM
Andrew Howard
Andrew Howard
Connect Directly
E-Mail vvv

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

Both development and evaluation teams have been ignoring security problems in Internet-connected devices for too long. That must stop.

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:

  • Basic hygiene issues: Default or no password, unnecessary active services, unpatched operating systems, etc.
  • Encryption challenges: No encryption or poor use of encryption, home-brewed cryptography, poor key management, exposed secret keys, reuse of secret keys, etc.
  • Unprotected software: No protection of software against download or reverse engineering, which can lead to intellectual property or key exposure.
  • Unauthenticated message passing: Devices follow any network commands, regardless of sender.
  • No secure update mechanism: Device firmware can't be securely updated to mitigate new security threats.
  • No physical security: Open a device, connect directly to main bus, and gain privileged access to system functions.

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:

Andrew Howard is Chief Technology Officer for Kudelski Security, trusted cybersecurity innovator for the world's most security-conscious organizations. Prior to joining Kudelski Security, he led the applied cybersecurity research and development portfolio at the Georgia Tech ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in GitHub Enterprise Server that allowed authenticated users of the instance to gain write access to unauthorized repositories via specifically crafted pull requests and REST API requests. An attacker would need to be able to fork the targeted ...
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user with the ability to fork a repository to disclose Actions secrets for the parent repository of the fork. This vulnerability existed due to a flaw that allowed the base reference of ...
PUBLISHED: 2021-03-03
An improper access control vulnerability was identified in the GitHub Enterprise Server GraphQL API that allowed authenticated users of the instance to modify the maintainer collaboration permission of a pull request without proper authorization. By exploiting this vulnerability, an attacker would b...
PUBLISHED: 2021-03-03
A remote code execution vulnerability was identified in GitHub Enterprise Server that could be exploited when building a GitHub Pages site. User-controlled configuration of the underlying parsers used by GitHub Pages were not sufficiently restricted and made it possible to execute commands on the Gi...
PUBLISHED: 2021-03-03
Pug is an npm package which is a high-performance template engine. In pug before version 3.0.1, if a remote attacker was able to control the `pretty` option of the pug compiler, e.g. if you spread a user provided object such as the query parameters of a request into the pug template inputs, it was p...