Addressing the Department Gap in IoT Security

People in departments outside of IT aren’t paid to understand IT security. In the world of IoT, we need to make it easy for those people to do the right thing.

So, Mr. IT professional, you suffer from your colleagues at work connecting all sorts of crap to your network that you’ve never heard of?  You’re not alone.  As more and more devices hit the network, the ability to maintain control can often prove challenging.  Here are your choices for dealing with miscreant devices:

  1. Prohibit them and enforce the prohibition by firing anyone who attaches an unauthorized device.
  2. Allow them and suffer.
  3. Prohibit them but not enforce the prohibition.
  4. Provide an onboarding and approval process.

A bunch of companies I work with generally aim for 1 and end up with 3.  A bunch of administrators recognize the situation and fit into 2.  Everyone I talk to wants to find a way to scale 4, but nobody has, as of yet.  What does 4 involve?  Today, it means an IT person researching a given device, determining what networking requirements it has, creating firewall rules, and some associated policies, and establishing an approval mechanism for a device to connect.

This problem is exacerbated by the fact that many different enterprise departments have wide and varied needs, and the network stands as critical to many of them.  Furthermore, very few of those departments reports through the chief information officer, and chief information security officers often lack the attention their concerns receive.

I would claim that the problem is that incentives are not well aligned, were people in other departments even aware of the IT person’s concerns in the first place, and often they are not.  The person responsible for providing vending machines just wants to get the vending machines hooked up, while the person in charge of facilities just wants the lights to come on and the temperature to be correct.

What we know from hard experience is that the best way to address this sort of misalignment is to make it easy for everyone to do the right thing. What, then, is the right thing?

Prerequisites

It has been important pretty much forever for enterprises to be able to maintain an inventory of devices that connect to their networks.  This can be tied into the DHCP infrastructure or to the device authentication infrastructure.  Many such systems exist, the simplest of which is Active Directory.  Some are passive and snoop the network.  The key point is simply this: you can’t authorize a system if you can’t remember it.  In order to remember it, the device itself needs to have some sort of unique identifier.  In the simplest case, this is a MAC address.

Ask device manufacturers to help

Manufacturers need to make your life easier by providing you a description what the device’s communication requirements are.  The best way to do this is with Manufacturer Usage Descriptions (MUD).  When MUD is used, your network management system can retrieve a recommendation from the manufacturer, and then you can approve, modify, or refuse a policy.  By doing this, you don’t have to go searching all over random web sites.

Have a simple and accessible user interface for people to use

Once in place you now have a nice system that encourages the right thing to happen, without other departments having to do anything other than to identify the devices they want to connect.  That could be as simple as a picture of a QR code or otherwise entering a serial #.  The easier we can make it for people who know nothing about networking, the better all our lives will be.

Removal of privacy protections harms service providers

Removing privacy protections harms consumer security AND service provider business prospects.

As the media is reporting, the administration has removed privacy protections for American consumers, the idea being that service providers would sell a consumer’s browsing history to those who are interested.  Over time, service providers have looked for new and novel (if not ethical) ways to make money, and this has included such annoyances as so-called “supercookies”.

Why, then, would I claim that removing consumer privacy protections will harm not only consumers, but telecommunications companies as well?

In the new world that is coming at us, our laptops, cell phones, and tablets will be a minority of the devices that make use of our home Internet connection.  The Internet of Things is coming, and will include garage door openers, security systems, baby monitors, stereos, refrigerators, hot water heaters, washing machines, dishwashers, light bulbs, and lots of other devices.  Many of these systems have been shown to have vulnerabilities, and the consumer does not have the expertise to protect these devices.  The natural organization to protect the consumer is the telco.  They have the know-how and ability to scale to vast quantities of consumers, and they are in the path of many of communications, meaning that they are in a position to block unwanted traffic and malware.

The consumer, on the other hand, has to be willing to allow the service provider to protect them.  Why would would consumers do that if they view the service provider as constantly wanting to invade their privacy?  Rather it is important the these companies enjoy the confidence of consumers.  Degrading that confidence in service providers, therefore, is to degrade security.

Some people say to me that consumers should have some choice to use service providers who afford privacy protections.  Unfortunately, such contractual choices have thus far not materialized because of all the small print that such contracts always entail.

What is needed is a common understanding of how consumer information will be used, when it will be exposed, and what is protected.  The protections that were in place went a long way in that direction.  The latest moves reverse that direction and harm security.

Yet another IoT bug

Miele could have benefited from MUD, as well as the experience of the Internet security community.

The Register is reporting a new IoT bug involving Miele PG 8528 professional dishwashers, used in hospitals and elsewhere.  In this case, it is a directory traversal bug involving an HTTP server that resides on port 80.  In all likelihood, the most harm this vulnerability will directly cause is that the dishwasher would run when it shouldn’t.  However, the indirect risk is that the device could be used to exfiltrate private information about patients and staff.  The vulnerability is reported here.

Manufacturers expect that it will be very simple to provide Internet services on their devices.  To them, initially, they think that it’s fine to slap a transceiver and a simple stack on a device and they’re finished.  They’re not.  They need to correct vulnerabilities such as this one.  They apparently have no mechanism to do so.  Manufacturers such as Miele are experts within their domains, such as building dishwashers.  They are not experts in Internet security.  It is a new world when these two domains intersect.

We need MUD

And yes, Manufacturer Usage Descriptions would have helped here, by restricting communication either to all local devices or to specifically authorized devices.

MUD sliding along

Your chance to try and chime in on Manufacturer Usage Descriptions, a way to protect IoT devices.

You may recall that I am working on a mechanism known as Manufacturer Usage Descriptions (MUD).  This is the system by which manufacturers can inform the network about how best to protect their products.  The draft for this work is now about to enter “working group last call” at the IETF.  This means that now would be a very good time for people to chime in with their views on the subject.

In the meantime, MUD Maker has also been coming along. This is a tool that generates manufacturer usage descriptions.  You can find the tool here.

MUD isn’t meant to be the whole enchilada of IoT security.  Other tools are needed to authenticate devices onto the network, and to securely update them.  And manufacturers have to take seriously not only their customers’ needs, but what risk they may impose on others, as Mirai reminded us.  Had MUD been around at the time, it’s possible that Mirai would not have happened.

Learning from the Dyn attack: What are the right questions to ask?

The attack on DNS provider DYN’s infrastructure that took down a number of web sites is now old news.  While not all the facts are public, the press reports that once again, IoT devices played a significant role.  Whether that it is true or not, it is a foregone conclusion that until we address security of these devices, such attacks will recur.  We all get at least two swings at this problem: we can address the attacks from Things as they happen and we can work to keep Things secure in the first place.

What systems do we need to look at?

  • End nodes (Cameras, DVRs, Refrigerators, etc);
  • Home and edge firewall systems;
  • Provider network security systems;
  • Provider peering edge routers; and
  • Infrastructure service providers (like DYN)

In addition, researchers, educators, consumers and governments all have a role to play.

Roles of IoT

What do the providers of each of those systems need to do? 

What follows is a start at the answer to that question.

Endpoints

It’s easy to pin all the blame on the endpoint developers, but doing so won’t buy so much as a cup of coffee. Still, thing developers need to do a few things:

  • Use secure design and implementation practices, such as not hardcoding passwords or leaving extra services enabled;
  • Have a means to securely update their systems when a vulnerability is discovered;
  • Provide network enforcement systems Manufacturer Usage Descriptions so that the networks can enforce policies around how a device was designed to operate.

Home and edge firewall systems

There are some attacks that only the network can stop, and there are some attacks that the network can impede.  Authenticating and authorizing devices is critical.  Also, edge systems should be quite leery of devices that simply self-assert what sort of protection they require, because a hacked device can make such self-assertions just as easily as a healthy device.  Hacked devices have recently been taking advantage of a gaming mechanism in many home routers known as Universal Plug and Play (uPnP) which permits precisely the sorts of self-assertions should be avoided.

Provider network security systems

Providers need to be aware of what is going on in their network.  Defense in depth demands that they observe their own networks in search of malicious behavior, and provide appropriate mitigations.  Although there are some good tools out there from companies like Cisco such as Netflow and OpenDNS, this is still a pretty tall order.  Just examining traffic can be capital-intensive, but then understanding what is actually going on often requires experts, and that can get expensive.

Provider peering edge routers

The routing system of the Internet can be hijacked.  It’s important that service providers take steps to prevent that from happening.  A number of standards have been developed, but service providers have been slow to implement for one reason or another.  It helps to understand the source of attacks.  Implementing filtering mechanisms makes it possible for service providers to establish accountability for the sources of attack traffic.

Infrastructure providers

Infrastructure upon which other Internet systems rely needs to be robust in the face of attack.  DYN knows this.  The attack succeeded anyway.  Today, I have little advice other than to understand each attack and do what one can to mitigate it the next time.

Consumers

History has shown that people in their homes cannot be made to do much to protect themselves in a timely manner.  Is it reasonable, for instance, to insist that a consumer to spend money to replace an old system that is known to have vulnerabilities?  The answer may be that it depends just how old that system really is.  And this leads to our last category…

Governments

The U.S. CapitolGovernments are already involved in cybersecurity.  The question really is how involved with they get with IoT security.  If the people who need to do things aren’t doing them, either we have the wrong incentive model and need to find the right one, or it is likely that governments will get heavily involved.  It’s important that not happen until the technical community has some understanding as to the answers of these questions, and that may take some time.

And so we have our work cut out for us.  It’s brow furrowing time.  As I wrote above, this was just a start, and it’s my start at that.  What other questions need answering, and what are the answers?

Your turn.



Photo credits:
Capitol by Deror Avi – Own work, CC BY-SA 3.0
Router by Weihao.chiu from zh, CC BY-SA 3.0
DVR by Kabel Deutschland, CC BY 3.0
Router by Cisco systems – CC BY-SA 1.0