IoT
5/10/2017
02:00 PM
Andrew Howard
Andrew Howard
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Cybersecurity Must Be an International Effort
Kelly Sheridan, Associate Editor, Dark Reading,  12/6/2017
NIST Releases New Cybersecurity Framework Draft
Jai Vijayan, Freelance writer,  12/6/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security: 2017
A look at the biggest news stories (so far) of 2017 that shaped the cybersecurity landscape -- from Russian hacking, ransomware's coming-out party, and voting machine vulnerabilities to the massive data breach of credit-monitoring firm Equifax.
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.