If you think about it, 2016 was a year that will forever change the way many people think about cybersecurity and some fundamental best practices.
After the attacks on Dyn shook the Internet in October, many organizations will forever deploy redundant DNS services or providers. Further, people now use 1 Tbps as their high watermark for DDoS protections and more organizations are adopting hybrid DDoS protections.
Not long after the Dyn attack, there was a congressional hearing on the state of Internet of Things (IoT) security and its threat to the Internet. Among others, the Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) have both recently published IoT security guidelines. The FTC even sued manufacturer D-Link, claiming they had insufficient protections built into their devices.
Earlier this year, I presented some technical research on the Mirai botnet at NANOG 69 in Washington DC, and I also joined a panel to discuss IoT security. Half of the panel members represented service providers and manufacturers, and the other half represented policy and regulation interests. The consensus of the panel was that we clearly have a huge threat, but how to address the issue is even more difficult.
For example, in an open market, price will often drive product sales. If an average consumer is deciding on which IoT device to buy, as long as that device will meet their needs, many consumers will often buy the lowest cost device.
A home printer is a perfect example of this. The buyers don’t think about the security aspects of it, or how to update it later on (if that’s even possible). Many times, the way a manufacturer can create the least expensive device is by relying on components from other manufacturers. That’s what happened in many cases with the Mirai attacks – exploited devices used components from third party manufacturers, so they didn’t even know about the vulnerabilities.
I have listened to some very smart ideas on how to address the issue, from requiring manufacturers to obtain a certification for sale, to using a policy-based framework that controls what devices are allowed to do in a network, perhaps similar to 802.1x. Eventually, there will be a solution, and I’d love to see manufacturers voluntarily adhere to whatever standard is adopted, but this fix won’t happen any time soon.
So until then, the problem persists: whose responsibility is it to stop IoT attacks?
In some respects, we all have a role in it, but this also won’t fix the problem. Only a certain population of end users will know enough about the issue or care enough about it to stop the problem. So we can’t count on users to fix the problems.
Manufacturers do need to give careful thought to the issue and they do need to employ mechanisms that allow for upgrades, patches, and fixes. However, we really can’t expect to hold manufacturers accountable for these kinds of issues today if they have demonstrated reasonable efforts to secure their product, which itself would even be hard to govern.
Attackers are innovative and they’re constantly looking for exploits of common technologies and protocols. Yes, leaving telnet running by default and having hard coded root-level credentials that can’t be changed is a horrible idea. But it’s also an extreme example and the issue won’t always be so black and white. Can you hold manufacturers whose devices participate in SNMP or NTP reflection attacks accountable too? Of course not.
A government or standards-based certification for IoT devices isn’t practical in the near term. In fact, if there are costs associated with achieving these certifications, such regulations could hinder innovation and very likely be a barrier of entry for startup companies. This is appropriate in some cases like where personal health or safety can be at risk, but DVR systems and printers, for example, have no need for an enforced standards certification. In the end, I don’t think that the general public would care enough to buy something where this is the differentiator. These type of certifications would really just need to be adopted voluntarily by the manufacturers as a best practice.
I’m not saying that device manufacturers are off the hook. They absolutely have a responsibility to deliver a product that is safe, protects their customer’s privacy, and is a properly behaved network device. But if we know anything in cybersecurity, we know that exploits and vulnerabilities are often hiding just around the corner. It just isn’t reasonable to expect that every IoT manufacturer will always have a way to patch or update any device ever produced.
So who is left? Who should be accountable when devices participate in attacks on the Internet?
The answer is the service provider of the customer who is participating in the attack. The organization that is being paid to provide access to the Internet by an end user should absolutely have the responsibility of ensuring their customer isn’t participating in abusive activity. Not only are they profiting from connecting their customer to the Internet, but they also have the knowledge of how to handle abusive activity and the ability to stop it – something that the average Internet user never will. They have visibility into the user’s traffic, so they can see when users are misbehaving. Most residential users will never have this insight or knowledge of the topic.
As you can imagine, this idea isn’t popular in parts of the service provider space. There are costs to this kind of work (even to simply answer the phone) and those costs can erode revenue. But there’s also precedence. When spam originates from a customer’s network, the service providers address it with the customer – even if it takes a few abuse complaints before it happens. If someone is abusive, the security team usually handles it.
Make no mistake, service providers do care about having responsible customers and as I’ve stated above, they do take action. But it’s time that ISPs give more thought to how to ensure their customers are not participating in these attacks. Spam and things like protocol reflection attacks are a little bit easier to fingerprint and block. Staying ahead of zero-day attacks and the traffic patterns that accompany them is a whole different challenge. Behavioural technologies are really the only way to take on this challenge. Otherwise, a service provider’s response can only be based on postmortem analysis or abuse complaints.
Most of my career has been in the technical and operations side of the Internet service provider space, so I certainly understand the business impact here. But I also know that service providers are best suited to address this problem. Maybe it’s adding behavioural technologies to existing CPE, or maybe it’s taking a different look at flow data and building processes around new anomalies that are detected. But no other entity will have the insight to customer traffic and the knowledge of how to contain abusive traffic as a user’s service provider. Now they just need the motivation.
Original post appeared on Radware Blog
Ron Winward is a Security Evangelist for Radware.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.