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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-13
Buffer overflow in a subsystem for some Intel(R) Server Boards, Server Systems and Compute Modules before version 1.59 may allow a privileged user to potentially enable denial of service via local access.
PUBLISHED: 2020-08-13
Uninitialized pointer in BIOS firmware for Intel(R) Server Board Families S2600CW, S2600KP, S2600TP, and S2600WT may allow a privileged user to potentially enable escalation of privilege via local access.
PUBLISHED: 2020-08-13
Improper initialization in BIOS firmware for Intel(R) Server Board Families S2600ST, S2600BP and S2600WF may allow a privileged user to potentially enable escalation of privilege via local access.
PUBLISHED: 2020-08-13
Unprotected Storage of Credentials vulnerability in McAfee Data Loss Prevention (DLP) for Mac prior to 11.5.2 allows local users to gain access to the RiskDB username and password via unprotected log files containing plain text credentials.
PUBLISHED: 2020-08-13
Out-of-bounds write in Kernel Mode Driver for some Intel(R) Graphics Drivers before version may allow an authenticated user to potentially enable denial of service via local access.