A patchwork quilt of IoT security

Opinion
Feb 2, 20175 mins

Individual, small pieces can give us a strong IoT security fabric

quilt
Credit: Omaopio

The Internet of Things (IoT) presents a security threat. A key point of my last article is that manufacturers do not have the right incentives. But all is not lost. With a little ingenuity, we can make a quilt of independent pieces that can nevertheless turn out to offer good security coverage.

The term “patchwork quilt” is often used pejoratively to describe something that is made up of an assortment of other parts. Yet it is worth remembering that a well-made quilt is still functional, durable and beautiful. And quilts are often made collaboratively in quilting bees. We need this sort of approach to network security.

+ Also on Network World: How we got our tattered IoT insecurity blanket +

Part of the reason that IoT devices represent such a security threat is because we do not treat all networks as though they’re part of the global Internet. When consumer internet access first took off, each computer was effectively part of the ISP’s network, directly connected via modem. By contrast, in homes and small businesses today, there is a small network with multiple devices. But because of the historical service model, those small networks do not operate as though they are part of a network of networks.   

In most corporate and service-provision networks, only some systems have access to the Internet. You do not want your company’s personnel database computer sending traffic to a random computer somewhere in the world. Indeed, if you discover such a traffic pattern, it is a good sign there is a problem. Professional network managers look after these networks to ensure traffic flows where it should, and nowhere else.

Home networks are different because they are mostly unmanaged. Most of us just want to be able to use the network and do not want to spend a lot of time maintaining it. That means the facilities of these small networks need to be managed automatically.

We have been in a similar position before. When residential broadband first took off, the gateways had terrible security. Attackers often had no problem taking control, rather like in today’s IoT devices. This problem is not completely solved, but it is far less acute than it used to be because ISPs had an interest in fixing the problem. ISPs started bundling wireless gateways and other similar functionality into the customer premises equipment (CPEs) for their customers. The gateways that people get from their ISPs today are often carefully configured to improve security. ISPs insisted on those improvements as part of their contract to buy the equipment.

A similar thing could happen with IoT. Suppose IoT devices could advertise their capabilities and what traffic they expected to send, using something like the Manufacturer Usage Description Framework. A gateway in the network would be able to tell what sort of traffic could be expected from the device—and could block other kinds of traffic, thereby preventing devices from becoming part of an attack. A device that the gateway did not know would not be able to talk to the rest of the Internet, just like a company’s database server for personnel records.

Devices that do not offer this facility would appear “broken,” and consumers would quickly learn to buy only devices that worked as expected. Vendors would realize they need to make devices that work this way or face customer support costs, dissatisfaction and returns. ISPs could include the functionality in the gateways they ship to customers, since most gateways already include a firewall function anyway.

The whole system would align the incentives correctly: Consumers want things that work, vendors want to avoid recalls and returns, and ISPs do not want their networks to be sources of attacks on the rest of the Internet. And, of course, this sort of functionality would be just as useful in large, corporate networks where IoT devices penetrate. Manually managing firewall rules for millions of devices is not something any IT staff can do.

The challenge of IoT security regulations

Some will argue that there are too many players involved and that it will take too long to get the incentives lined up—that regulation is the only choice. But regulation also takes time, and on the Internet, the regulatory regime will need to include almost every country or else it is unlikely to be effective. It is hard to believe that getting all the governments in the world to cooperate would be easier than using commercial pressure.

A quiltmaker takes many small components and stitches them together into a greater whole that is much more useful than the small scraps of fabric that make it up. By treating small, unmanaged networks as first-class participants in the network of networks, we can reduce the threats that come from millions of mostly unmanaged devices that the IoT provides. Yet we can get the benefits that come from automating our world by connecting more devices to the Internet. By taking lessons from quilters, we can be sure we build better networks.

A fellow at Dyn, Andrew Sullivan has worked in the tech industry since 2001, when he was part of the group that launched the new top-level domain (TLD) information. He has been active in the Internet Engineering Task Force (IETF) for about a decade and previously served as co-chair of the DNS Extensions working group and SPF Updates working group. He was appointed to the Internet Architecture Board (IAB) in 2013 and named chair in 2015. An activity of the IETF, the IAB offers a broad view of the overall Internet architecture and also functions as the IETF’s interface to external parties.

At Dyn, Andrew began as the company’s director of labs, charged with getting the Labs up and running to work on next-generation Dyn technologies and leading the company's efforts in Internet standards and policy development. After that, he became Dyn’s director of DNS engineering, leading the team responsible for improving Dyn's DNS service offerings. Following that, he was named the company’s principal architect, charged with designing and reviewing proposals for Dyn’s hardware and software systems with expert knowledge on Internet protocols and policy. He later became Dyn’s director of architecture, managing and directing the Dyn architecture and labs groups and reporting directly to the CTO. In that position, he designed and reviewed proposals for all of Dyn’s technical systems. In March of 2015, when he became IAB chair, he was named a Dyn fellow, concentrating on the architecture of Internet systems. On a daily basis, Andrew works on Internet standards, protocols and policy. He also serves as a guide for the company’s technical staff when questions arise.

Andrew holds a bachelor's degree from the University of Ottawa and a master's degree from McMaster University, both in philosophy.

The opinions expressed in this blog are those of Andrew Sullivan and do not necessarily represent those of IDG Communications Inc., or its parent, subsidiary or affiliated companies.

More from this author