Building Trust Internet of Things (IoT) Security

Internet of Things Devices as a DDoS Vector

As adoption of Internet of Things devices increases, so does the number of insecure IoT devices on the network. These devices represent an ever-increasing pool of computing and communications capacity open to misuse. They can be hijacked to spread malware, recruited to form botnets to attack other Internet users, and even used to attack critical national infrastructure, or the structural functions of the Internet itself (we give several examples from recent headlines in the Reference Section, below).

The problem this poses is what to do about IoT as a source of risk. This blog post includes reflections on events that came to light in recent weeks, sets out some thoughts about technical mitigations, and sketches out the boundaries of what we think can be done technically. Beyond those boundaries lie the realms of policy measures, which – while relevant to the big picture – are not the topic of this post.

Why are we exploring this issue now? Partly because of our current campaign to improve trust in consumer IoT devices.

And partly, also, because of recent reports that, as a step towards mitigating this risk, connected devices will be subjected to active probing, to detect whether or not they can still be accessed using default user IDs and passwords. Here is one such report, from the IEEE.

We believe active probing raises practical, privacy, and security risks which ought either to rule it out as an approach, or ensure that other, less risky options should always be considered first.

Remote devices: control, ownership, and responsibility

Much of the power of a distributed denial-of-service (DDoS) attack comes from the ability to recruit devices all over the planet, regardless of the physical location of the attacker or, indeed, the target. One countermeasure is to make it harder for a malicious actor to gain remote control of an IoT device.

Gaining control of a device involves (or should involve) authenticating to it as an authorized user. IoT devices that either have no access control, or have access control based on a default password, have little or no protection against such a take-over. It is therefore often suggested that an early step towards securing connected devices is to ensure that users replace the default password with one that is hard to guess.

This step, though, is not without obstacles. Users are notoriously bad at choosing and changing passwords, frequently choosing trivial ones if they bother to set passwords at all, and of course, sometimes not even realizing that they should set a password in the first place.

Consumers’ behavior might also be based on an assumption that their devices are safe. They might assume, by default, that their Internet service provider (ISP) or connected-home solution provider is not supplying a device that puts them at risk through poor security – just as they might expect the device not to catch fire in normal use.

Multiple stakeholders, expectations and requirements

As you can see, we already have a problem whose solution may require action by more than one stakeholder:

  • Device manufacturers need to design their products to require some form of access control, and to prompt the user to enable it
  • Users need to have the awareness and discipline to use the access control mechanism and, if necessary, remember and replace passwords when needed
  • Users may, under some circumstances, assume that “someone else” is taking care of keeping their devices safe and secure

And all this has to be done in ways that reconcile the triangle of requirements, from which, traditionally, you can “pick any two.” The resulting control must be:

  • Secure (otherwise it has missed the point)
  • Usable (if it is too hard to understand or inconvenient, users will ignore it)
  • Manageable (it must be possible to repair, replace or update the control without compromising the usability of the device, or the security and privacy of the user)

In the IoT context, two further issues must be addressed.

First, whatever the solution, it must be affordable. Otherwise, “secure but expensive” products will tend to lose market share in favor of “insecure but cheap” competitors, and the risk represented by insecure IoT devices will continue to grow.

Second, the process as laid out above has a flaw, namely, “that’s not where we’re starting from.” Connected devices with poor security are already widely available and deployed in vast numbers. In those cases, it’s too late for manufacturers to design security into the product, so we need to look for alternative means to mitigate the risk of IoT devices as a threat vector.

Choosing the appropriate intervention

If the device has simply been designed without appropriate security mechanisms, and without the means to add them once deployed, and if it presents a significant risk to people’s security or well-being, there’s little to be done other than try to withdraw it from the market. (For instance, in 2017 German authorities issued a ban against a connected doll, on grounds that it was a de facto surveillance device, and could also put children at risk.)

If already-deployed devices can be secured by user action, the question becomes one of deciding how this can best be achieved. We think there will be a range of options, some more appropriate to different kinds of connected device than others.

General public-awareness campaigns, aimed at informing consumers about the importance of good password practice, may be ineffective or insufficiently accurately targeted to be relevant; but how do we increase the accuracy of such messages without intruding on users’ privacy?

Is it acceptable to target the buyers of specific kinds of device, or specific brands? Should ISPs have the means (or a duty) to scan their networks for those devices and alert their subscribers to the potential risks? Should they even test devices on their networks to see if the default password has been changed? As a last resort, and given the potential threat IoT presents to critical national infrastructure, do even governments have a responsibility in such cases, and is it desirable for them to intervene, either directly or through the ISP?

As the IEEE article notes, in comments from the Information Technology Center of the University of Tokyo, a large-scale initiative like this increases the number of stakeholders who must play a role. It will probably involve the government, an approved technical institute, and ISPs. It may mean governments have to reconcile conflicts between the actions they wish to take, and laws relating to personal privacy, consent, or unauthorized computer access. Those decisions are, as we noted, beyond the scope of this post, except to note that they increase the difficulty of ensuring that the “active probe” approach is manageable, legal and safe.

Conclusions and Recommendations

We recognize that circumstances will vary, and different situations may call for different approaches. Here is an indication of the range of interventions we think can apply. This is not an exhaustive list, but it serves to show that many options are available, and several may be needed.

  • Security by design. If all IoT devices were well designed in the first place, their risk would be greatly reduced.
  • Secure lifecycle management. Good design includes the ability to manage deployed devices over their whole lifecycle, including secure updates to firmware/software, and secure decommissioning. (This could imply that some processes and protocols need to include a “consent” step.)
  • Lab testing of devices. Assess new devices against quality criteria for security and lifecycle management, and provide feedback to manufacturers. This could extend to include certification and trust-marks.
  • General awareness-raising campaigns (e.g., encouraging users to change default passwords).
  • Targeted awareness raising/call to action (this might be based on the results of lab testing, in the form of a manufacturer’s “recall” notice for unsafe products).
  • “Passive” device targeting (e.g., an ISP can detect traffic that indicates an unsafe device, and sends an out-of-band alert to the user suggesting remedial action).
  • “Active” device targeting (e.g., an entity scans for device types known to have a security flaw, and notifies the user with suggested actions).
  • “Active probe” (e.g., an entity probes devices remotely to identify those that still have default passwords).

As this rough list suggests, many alternatives can be considered before embarking on something as potentially contentious as an active probe – and of the options listed, active probing would require the most effort in terms of governance, management, privacy/ethical impact assessment, and safety measures. Here are just some of our concerns with the “active probe” approach:

  • Doing this (or even attempting to) without the knowledge and express permission of the device owner, irrespective of the motivation, is a technical attack on that device.
  • The device owner has no way to distinguish a malicious attack from an “authorized,” legitimate one, and might therefore react inappropriately to a legitimate probe, or fail to react appropriately to a malicious one. This may give rise to unintended and undesirable outcomes. For instance, if users are warned via a general announcement that “legitimate probes will be conducted overnight on Thursday of next week”, hackers might interpret that as an opportunity to launch their own attacks, in the knowledge that householders are less likely to react.
  • It could result in the creation of a large database of vulnerable devices, which would be both a target and an asset for potential attackers. Creation of such an asset should not be done without caution and forethought.
  • It is even possible that an active probe could infringe the sovereignty of another nation: for instance, is it acceptable for a country to probe the connected devices of foreign embassies on its soil, as part of an initiative such as this?

Overall, our view is that the active probe approach carries the highest risk of undermining users’ trust in the Internet, particularly by breaching the normal expectations of the device owners and users, concerning privacy, ownership and control. We conclude that actively testing device security by attempting to log in using well-known default passwords should be a last resort, in light of a specific, identified threat, and used only when other alternatives are not available or practical.

In deciding which of the interventions is appropriate (and successful intervention may need a combination of measures), we recommend applying established principles from other, related disciplines of IT governance:

  • Necessity: is there a less risky, less intrusive way to achieve the same ends?
  • Proportionality: is the desired outcome sufficient to justify the potential safety and privacy impact of the intervention?
  • Consent: has the individual’s informed consent been sought and knowingly, freely given?
  • Transparency: is it clear to all stakeholders what is being done and why?
  • Accountability: are the outcomes measurable? Is accountability for the outcomes clear – including negative outcomes if something goes wrong?

We recognize that insecure connected devices represent a substantial and growing threat, and one that needs an effective response. However, we also believe that response can and should be graduated, based on evaluation of a full range of options and application of established principles of good governance.

Recent examples of IoT as an attack vector

Other resources

IETF Improving Technical Security Open Internet Standards Technology

ISOC Rough Guide to IETF 99: Internet Infrastructure Resilience

IETF 99 is next week in Prague, and I’d like to take a moment to discuss some of the interesting things happening there related to Internet infrastructure resilience in this installment of the Rough Guide to IETF 99.

Simple solutions sometimes have a huge impact. Like a simple requirement that “routes are neither imported nor exported unless specifically enabled by configuration”, as specified in an Internet draft “Default EBGP Route Propagation Behavior Without Policies”. The draft is submitted to IESG and expected to be published as a Standards Track RFC soon.

This specification intends to limit the impact of misbehaving networks by requiring the explicit configuration of both BGP Import and Export Policies for an External BGP (EBGP) session such as customers, peers, or confederation boundaries for all enabled address families. When widely deployed, this measure should reduce the occurrence of route leaks and some other routing misconfigurations.

Speaking of route leaks, there are still two proposals addressing the route leak problem. Now both are IDR WG documents: “Methods for Detection and Mitigation of BGP Route Leaks” (, and “Route Leak Prevention using Roles in Update and Open messages” ( The first approach uses a so-called RLP Route Leak Prevention field to inform upstream networks and lateral peers of a “leaked” route. Another one leverages the BGP Open message to establish an agreement of the (customer, provider, complex) relationship of two BGP neighboring speakers in order to enforce appropriate configuration on both sides. Propagated routes are then marked with a flag according to agreed relationship allowing detection and mitigation of route leaks.

In the area of RPKI and BGPSEC a recently chartered SIDR Operations Working Group (SIDROPS) has taken over the technology developed in SIDR WG and is focused on developing guidelines for the operation of SIDR-aware networks, and providing operational guidance on how to deploy and operate SIDR technologies in existing and new networks. The first of such guidelines was just published and will probably be discussed during the WG meeting: “Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties” ( Being a relying party is not an easy job – one has to comply to dozen of RFCs, from protocol specifications to best practices – and this document attempts to outline a set of baseline requirements imposed on RPs and provides a single reference point for requirements for RP software for use in the RPKI, as segmented with orthogonal functionalities:

  • Fetching and Caching RPKI Repository Objects
  • Processing Certificates and CRLs
  • Processing RPKI Repository Signed Objects
  • Delivering Validated Cache Data to BGP Speakers

The IDR WG continues working on the proposal “Making Route Servers Aware of Data Link Failures at IXPs” ( When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes a means for the peers to verify connectivity amongst themselves, and a means of communicating the knowledge of the failure back to the route server. There was quite some discussion on the mailing list about whether communication of failures back to the RS is necessary. I imagine this discussion will continue during the WG session.

It seems the OPSEC WG will discuss another attempt at addressing the source IP spoofing problem. A draft “Enhanced Feasible-Path Unicast Reverse Path Filtering Anti-spoofing” ( proposed a method that does not have the drawbacks of the existing modes of Unicast Reverse Path Filtering (uRPF) – strict, feasible and loose. Apart from implementation issues and a potential performance hit, uRPF presents risks of dropping traffic by an ISP implementing it. These were the major obstacles in the way of its deployment and protection against IP-spoofed traffic.

DDoS attacks are a persistent and growing threat on the Internet. And as DDoS attacks evolve rapidly in the aspect of volume and sophistication, more efficient cooperation between the victims and parties that can help in mitigating such attacks is required. The ability to quickly and precisely respond to a beginning attack, communicating the exact information to the mitigation service providers is crucial.

Addressing this challenge is what keeps the DDoS Open Threat Signaling (DOTS, WG busy. The goal of the group is to develop a communications protocol intended to facilitate the programmatic, coordinated mitigation of such attacks via a standards-based mechanism. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. Specifications outlining the requirements, architecture and the use cases for DOTs are maturing and will be discussed at the meeting.

To summarize – there is important work underway at the IETF that will hopefully lead to a more resilient and secure Internet infrastructure.

Related Working Groups at IETF 99

SIDROPS (SIDR Operations) WG
Monday, 17 July, 15:50-17:20, Congress Hall III

GROW (Global Routing Operations) WG
Monday, 17 July, 17:40-18:40, Congress Hall III

IDR (Inter-Domain Routing Working Group) WG
Thursday, 20 July, 09:30-12:00, Congress Hall III

DOTS (DDoS Open Threat Signaling) WG
Thursday, 20 July, 15:50-17:50, Berlin/Brussels

OPSEC (Operational Security) WG
Wednesday, 19 July, 13:30-15:00, Berlin/Brussels

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Building Trust Improving Technical Security Internet of Things (IoT) Open Internet Standards Technology

The Internet of Things as an Attack Tool

Akamai has published its Q4 2016 State of the Internet/Security report As always, an interesting read and an opportunity to look at trends in attacks.

Not all trends are up and to the right. As the report states, Q4 2016 was “the third consecutive quarter where we noticed a decrease in the number of attack triggers”. Still, “the overall 2016 attack count was up 4% as compared to 2015”. Also, the volume and number of “mega-attacks” is on the rise.

And of course, there was the Mirai malware recruiting poorly secured devices connected to the Internet. The Mirai-based botnet produced the largest-ever DDoS attacks, with volume peaking at 623 Gbps. That drew a lot of media attention to the dark side of the Internet of Things (IoT), calling for action before it is too late.

Let us look at a few trends playing out in this area.

First, the IoT. Lacking an agreed definition, there is a tendency to call anything connected to the internet, except conventional computers, an IoT device. Not trying to craft yet another definition, an important question is what makes these new types of connected devices different from the ones that were connected in the past? In the context of DDoS attacks I can only think of the three:

Increased number. Twenty years ago, a household would have a home router and one or two computers connected. Then the smartphone revolution came and significantly more devices were added: gaming consoles, smartphones and tablets. Now with the ability to easily connect anything there is a potential that the number of connected things per household, but also in other areas, such as industrial systems and “smart” environments, will increase in orders of magnitude. And since any device is potentially vulnerable, that increases opportunities for an attacker.

Limited user interaction. Smart objects are designed to operate autonomously, in the background, without requiring user intervention and offering a limited user interface (if there is one at all). That means that the user won’t administer the device – install updates, monitor its performance, scan for malware and clean it up. But quite frankly, this does not happen much with computers and smartphones either. The difference is that in the latter area the industry has matured and consolidated, realizing the need and offering proven security solutions without relying on a user.

Constrained. On one hand, that means that implementing security functions is more difficult, but on the other – malware has to deal with the same constraints. As recent attacks showed in the context of a DDoS, we should be more afraid of unconstrained devices such as home routers and set top boxes. Such devices have presented a threat since 2003, when a software flaw in Netgear cable modems cased a DDoS attack on the University of Wisconsin, USA. Also, many of these unconstrained devices are always on – another useful feature for a bot.

Increasing complexity, expanding code base, larger attack surfaces as new users and devices are connected to the Internet, less reliance on the user as the Internet has become a commodity – these are general trends related to growth and development, not just an IoT revolution.

The report seems to confirm this: “While there were plenty of IoT-fuelled DDoS attacks in the fourth quarter, none of the fourth quarter’s attacks over 300 Gbps were IoT-based. The Attack Spotlight looks at the botnet that generated the top 3 largest DDoS attacks and delves more deeply into the largest attack this quarter, a 517 Gbps attack with signatures from the Spike DDoS toolkit.”

Another interesting trend highlighted in the report is related to competition for resources: “Our examination of the use of ntp reflection as an attack amplifier last quarter suggests that new attack types peak shortly after they appear. But as these attacks gain in popularity, competition for the resources needed to make them begins. While the number of attacks goes up, the size of individual attacks is pushed down, as there are fewer resources available for each of the botnets.”

What does this mean?

I think that if we talk about DDoS attacks and botnets we must build on more than two decades of experience dealing with this phenomenon. So far three strategies have been applied with relative success:

1. Making the edge more secure

The frightening trend here is that many device manufacturers put features and price on top, and security at the bottom of their priority list. That also includes absence of a software or firmware update mechanism. This creates a long-lasting vulnerability at the edges.

A positive trend here is that the standards development and open source communities are putting a lot of efforts into designing building blocks and ready-to-use solutions in this area. Last year the IAB organised a workshop, “ Internet of Things (IoT) Software Update (IoTSU)”, where participants discussed the software/firmware update mechanisms. A BoF to further work in this area is scheduled for the IETF 98 meeting in Chicago from March 26-31: “A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) BoF”. Significant efforts are being put into building IoT frameworks, some of which are open source, like AllJoyn by the Open Connectivity Foundation (OCF), and some of which are closed, such as HomeKit by Apple.

2. Detection and disinfection

A good example here is the ” Anti-Bot Code of Conduct for Internet Service Providers” outlining five areas where ISPs can take action and help reduce end-user bots. These are: Education, Detection, Notification, Remediation, and Collaboration.

Users can also take responsibility and keep their home networks clean. This is more and more in their own interest – from performance degradation to privacy and even physical threats as the IoT penetrates our material life. Developments like SENSE from F-Secure can provide households with necessary tools.

3. Mitigation

Botnets usually rely on so-called Command & Control (C&C) servers to get instructions for their operation. Disabling the C&C server effectively means disabling the botnet. For example, this approach was successfully applied in mitigating the Conficker botnet.

Interestingly, there is no (at least not that I have found) mention of this approach when addressing the Mirai botnets. Given that the source code has been released, tracing and taking down C&C servers should be easier.

Does the IoT change this?

The emergence of the IoT makes addressing the issue more challenging, but so is the growth of the Internet in terms of bandwidth and number of connected users. That makes it more important to re-inforce and foster the approaches that worked.

It is true that the IoT brings new challenges and threats, and at different scale. Imagine cars colliding without reason, or smart cities getting the time of day wrong, or power plants misreading parameters of the reactor. What could make these nightmares materialize themselves are vulnerabilities of the components, not only devices, but also communication links and protocols, software, apps, etc. And the question is – how do we secure these systems? A common approach is based on holistic risk assessment. But this is a topic for another post.

So, does the IoT bring a radical change to the DDoS attack landscape? If it does, which of the current approaches in addressing botnet issues and DDoS mitigation work and which do not? What new approaches are required? We welcome your thoughts, opinions and ideas here in the comments.

Improving Technical Security

Holiday DDoS Attacks: Targeting Gamers (Plus Five Things You Can Do)

Over the past few years, a new tradition has emerged, the Holiday DDoS Attack.

While distributed denial of service (DDoS) attacks happen throughout the year, some of the highest profile attacks occur during the holidays, when the most users will be impacted. Attackers may target online shopping sites to disrupt pre-holiday gift buying. Or they may attack voice over IP services, like Skype, which are used to talk to family members over the holidays. But gaming networks are most often targeted by DDoS attacks, as the end of year holidays usually bring many users online who are eager to try out their new games and systems. In December 2014 and 2015, both Sony’s PlayStation Network and Microsoft’s Xbox Live gaming networks experienced outages as a result of DDoS attacks, leaving users unable to access or play their games online.

On 23 December 2016, Steam, a digital distributions platform and multiplayer network for PC gaming, went offline for several hours. A group of hackers took credit for the outage, claiming they downed the service through a DDoS attack. Valve Corporation, the developer of Steam, did not publicly identify the cause of the outage. When the outage occurred, Steam was in its first day of its annual Winter Sale, which could have produced a large increase in legitimate traffic that could have overloaded their systems, but a DDoS attack is far more likely.

In each of these cases, thousands of average Internet users inadvertently contributed to these DDoS attacks through the participation of their unsecured and infected devices.

While DDoS attacks are annoying for the users impacted, they are incredibly expensive for the companies attacked. According to a study by Incapsula, a web security company, DDoS attacks cost companies an average of $40,000 an hour. For the Steam attack, the cost was likely much higher. The Winter Sale produces some of their largest revenues of the year. The attack’s timing just days before Christmas may have caused Valve Corporation to lose customers, who may have opted to buy their gifts from other companies when they could not access the Steam website. Some users may have lost some confidence in Steam, worrying that the attackers may have also stolen private customer data such as their billing information, and moved to a different service.

DDoS attacks work by flooding systems with seemingly legitimate traffic. The systems are overloaded, leaving legitimate users unable to access them. Since differentiating between illegitimate and legitimate traffic is difficult, DDoS attacks are hard to defend against. Defenders can attempt to block spoofed traffic, provision more bandwidth to counteract the increased traffic, or use other mitigation techniques.[1] However, if the DDoS attack is large enough, and especially if it is made up of unspoofed traffic from many sources, it can be difficult to mitigate. For this reason, DDoS attacks have become the weapon of choice for attackers looking to gain notoriety during the holiday season.

While it can be hard to mitigate a large DDoS attack, everyone can take actions to prevent them. DDoS attacks rely on networks (botnets) of infected devices (bots) to create the massive amounts of traffic necessary to overload systems. Without large numbers of bots, it is much harder for attackers to create large amounts of traffic, making attacks easier to mitigate. We can all take small actions to ensure that our devices do not double as bots. DDoS attacks can only truly be stopped if everyone does their part and protects their own devices. Until that happens, the holiday DDoS attack will remain a threat for years to come.

Five actions to protect your devices from becoming bots:

  1. Create and use strong passwords for all your devices. Do not use the default. This is especially important for smart devices, routers, and other devices with which you may not interact directly.
  2. Update your devices! Software is often patched to remove known vulnerabilities, greatly strengthening your defenses.
  3. Monitor your devices. If a device is acting strangely, investigate it. One example is bounced email messages. If email messages are not reaching their destination, your device could be infected and sending spam as a part of a botnet.[2]
  4. Run anti-virus scans and use other security tools to find and remove malicious software.
  5. Be careful to avoid infecting your devices. Avoid opening suspicious emails, attachments, or risky websites. Some anti-malware services include website security checks.


[1] Spoofed traffic is Internet traffic that is forged to look like it is from another source.
[2] For more specific tips for fighting spam, see our Anti-Spam Toolkit users page.