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.


10:00 AM
Nathaniel Gleicher,
Nathaniel Gleicher,
Connect Directly
E-Mail vvv

The Big Lesson We Must Learn From The Dyn DDoS Attack

The vulnerabilities that make IoT devices susceptible to being used in a botnet also make them the perfect avenue into our data centers and clouds.

The recent distributed denial-of-service (DDoS) attack against DNS service provider Dyn, built of Internet-connected DVRs, video cameras, and other embedded systems, has focused the minds of security experts on the huge threat posed by Internet of Things (IoT) devices. It's the second recent massive DDoS attack, and it's the perfect lesson to make the "IoT threat" discussion concrete.

But the lesson isn't really about DDoS. Today's debate is dominated by the huge attack platform created by compromised IoT devices; chain together hundreds of thousands of connected cameras, and you can generate the largest DDoS attack the world has ever seen. But systemic IoT security flaws leave us vulnerable to many kinds of attacks. DDoS may be the least of our worries.

The same vulnerabilities that make IoT devices susceptible to being leashed into a botnet also make them the perfect points of entry into our data centers and clouds. To understand the scope of this threat, consider the range of embedded systems in use today — industrial and personal equipment that is now being connected to networks to make them smarter, more convenient, and more efficient. From GPS trackers to point-of-sale systems, connected light bulbs, manufacturing robots, and connected power supplies, more and more devices within organizations are exposed to the Internet. This exponentially increases the attack surface of organizations.

This threat isn't new. The hackers that breached Target back in 2013 got in through the firm managing Target's HVAC systems, then moved laterally to the point-of-sale system that they exploited to capture customer credit cards. And researchers at Black Hat have demonstrated vulnerabilities in the SCADA systems used to control oil rigs.

Despite this history, we're still seeing embedded systems produced with glaring security flaws. Case in point: October's massive DDoS attack was enabled in part by hundreds of thousands of connected video cameras shipped with default passwords. Why aren't we getting the message?

Part of the problem is that we've been building these devices (light bulbs, HVACs) for years,and we’ve never had to design them for this kind of security before. But even worse, these devices aren’t designed to be updated — who thinks of updating light bulbs? This means that even when a vulnerability becomes known, it can be incredibly difficult to patch because the systems aren't designed to be patched.

Those connected cameras that powered the recent DDoS? Well, even if users wanted to update that weak default password, the only way to do it would be to update their camera’s firmware, which requires a manufacturer update. And there's no established mechanism to do this.

It’s not as if we’re about to simply stop using connected systems to solve this problem — the efficiencies created by these devices are simply too great.

Defending our Systems
Instead, we need to begin defending IoT devices just like every other processor connected to our networks. You have to assume that attackers will get in at some point, monitor your IoT devices for compromises, and work to segment those IoT devices away from the rest of your network.

First, we've already seen intruders use IoT devices to move laterally through a data center to reach their real target. We can make this much harder if we use microsegmentation to shut down unnecessary connections between those IoT devices and the rest of the network. By limiting attacker movement, we greatly reduce the value of IoT devices as attack vectors, even if they could still be compromised.

Second, stopping the spread of diseases from our IoT patient zeros isn't enough. If you can't rely on these devices to remain secure by themselves, you can use security policy to create a new kind of visibility. By defining devices' legitimate operations, we can increase our ability to detect and respond when an attacker uses them in a way that breaks that policy.

Taking these steps is particularly challenging for embedded systems because they often run on stripped-down operating systems designed for maximum speed and minimum functionality. Unfortunately, this isn’t likely to change, because IoT consumers demand inexpensive solutions (remember, connected light bulbs must compete on price with normal light bulbs).

If directly monitoring embedded systems themselves will be challenging, we can still protect our networks by focusing on the devices to which they are connected. This won't eliminate intrusions, but it would help us respond and contain intrusions quickly and minimize the damage they cause. 

Ultimately, we must develop more secure IoT platforms, and customers can have some influence on this by choosing secure products and holding developers to account. But these are both long-term efforts. In the meantime, segmentation and visibility — both on IoT devices and on the devices they connect to — are our best tools for managing the threats created by the expanding attack surface of IoT devices. This will help prevent our devices from being subverted into criminal botnets and help intruders seeking to use them as a launchpad into our most sensitive systems.

Related Content:

Dark Reading's all-day virtual event Nov. 15 offers an in-depth look at myths surrounding data defense and how to put business on a more effective security path. 

As head of cybersecurity strategy, Nathaniel is responsible for thought leadership, public engagement, and overseeing Illumio's security technology strategy. Nathaniel is a regular speaker at leading industry events, and his writing has appeared in industry publications, the ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/22/2020
How an Industry Consortium Can Reinvent Security Solution Testing
Henry Harrison, Co-founder & Chief Technology Officer, Garrison,  5/21/2020
Is Zero Trust the Best Answer to the COVID-19 Lockdown?
Dan Blum, Cybersecurity & Risk Management Strategist,  5/20/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-05-27
A race condition was found in the mkhomedir tool shipped with the oddjob package in versions before 0.34.5 and 0.34.6 wherein, during the home creation, mkhomedir copies the /etc/skel directory into the newly created home and changes its ownership to the home's user without properly checking the hom...
PUBLISHED: 2020-05-27
JerryScript 2.2.0 allows attackers to cause a denial of service (assertion failure) because a property key query for a Proxy object returns unintended data.
PUBLISHED: 2020-05-27
JerryScript 2.2.0 allows attackers to cause a denial of service (stack consumption) via a proxy operation.
PUBLISHED: 2020-05-26
The boost ASIO wrapper in net/asio.cpp in Pichi before 1.3.0 lacks TLS hostname verification.
PUBLISHED: 2020-05-26
An issue was discovered in ssl.c in Axel before 2.17.8. The TLS implementation lacks hostname verification.