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 CISOs Need a Security Reality Check
Joel Fulton, Chief Information Security Officer for Splunk,  6/13/2018
Cisco Talos Summit: Network Defenders Not Serious Enough About Attacks
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2018
Four Faces of Fraud: Identity, 'Fake' Identity, Ransomware & Digital
David Shefter, Chief Technology Officer at Ziften Technologies,  6/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-8030
PUBLISHED: 2018-06-20
A Denial of Service vulnerability was found in Apache Qpid Broker-J versions 7.0.0-7.0.4 when AMQP protocols 0-8, 0-9 or 0-91 are used to publish messages with size greater than allowed maximum message size limit (100MB by default). The broker crashes due to the defect. AMQP protocols 0-10 and 1.0 a...
CVE-2018-1117
PUBLISHED: 2018-06-20
ovirt-ansible-roles before version 1.0.6 has a vulnerability due to a missing no_log directive, resulting in the 'Add oVirt Provider to ManageIQ/CloudForms' playbook inadvertently disclosing admin passwords in the provisioning log. In an environment where logs are shared with other parties, this cou...
CVE-2018-11701
PUBLISHED: 2018-06-20
FastStone Image Viewer 6.2 has a User Mode Write AV at 0x005cb509, triggered when the user opens a malformed JPEG file that is mishandled by FSViewer.exe. Attackers could exploit this issue for DoS (Access Violation) or possibly unspecified other impact.
CVE-2018-11702
PUBLISHED: 2018-06-20
FastStone Image Viewer 6.2 has a User Mode Write AV at 0x00578cb3, triggered when the user opens a malformed JPEG file that is mishandled by FSViewer.exe. Attackers could exploit this issue for DoS (Access Violation) or possibly unspecified other impact.
CVE-2018-11703
PUBLISHED: 2018-06-20
FastStone Image Viewer 6.2 has a User Mode Write AV at 0x00402d6a, triggered when the user opens a malformed JPEG file that is mishandled by FSViewer.exe. Attackers could exploit this issue for DoS (Access Violation) or possibly unspecified other impact.