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.

Should Uber require a permit for testing?

The Wall Street Journal and others are reporting on the ongoing battle between Uber and state and local governments.  This time it’s their self-driving car.  Uber announced last week that they would not bother to seek a permit to test their car, claiming that the law did not require one.  The conflict took on a new dimension last week when one of Uber’s test vehicles ran a red light.

Is Uber right in not wanting to seek a permit?  Both production and operation of vehicles in the nearly all markets are highly regulated.  That’s because  auto accidents are a leading cause of death in the United States and elsewhere.  The good news is that number is falling.  In part that’s due to regulation, and in part it’s due to civil liability laws.  I’m confident that Uber doesn’t want to hurt people, and that their interest is undoubtedly to put out a safe service so that their reputation doesn’t suffer and their business thrives.  But the rush to market is sometimes too alluring.  With the pace of technology being what it is, Uber and others would be in a position to flood the streets with unsafe vehicles, possibly well beyond their ability to pay out damages.  That’s when regulations are required.

There are a few hidden points in all of this:

  • As governments consider what to do about regulating the Internet of Things, they should recognize that much of the Internet of Things is already regulated.  California did the right thing by incrementally extending the California Vehicle Code to cover self-driving vehicles, rather than come up with sweeping new regulations.  Regulations already exist for many other industries, including trains, planes, automobiles, healthcare, electrical plants.
  • We do not yet have a full understanding of the risks involved with self-driving cars.  There are probably many parts of the vehicle code that require revision.  By taking the incremental approach, we’ve learned, for instance, that there are places where the vehicle code might need a freshening up.  For instance, self-driving cars seem to be following the law, and yet causing problems for some bicyclists.
  • IoT regulation is today based on traditionally regulated markets.  This doesn’t take into account the full nature of the Internet, and what externalities people are exposed to as new products rapidly hit the markets.  This means, to me, that we will likely need some form of regulation over time.  There is not yet a regulation that would have prevented the Mirai attack.  Rather than fight all regulation as Uber does, it may be better to articulate the right principles to apply.  One of those is that there has to be a best practice.  In the case of automobiles, the usual test for the roads is this is whether the feature will make things more or less safe than the status quo.  California’s approach is to let developers experiment under limited conditions in order to determine an answer.

None of this gets to my favorite part, which is whether Uber’s service can be hacked to cause chaos on the roads.  Should that be tested in advance?  And if so how?  What are the best practices Uber should be following in this context?  Some exist.

More on this over time.

Time to end the war on the network

Edward SnowdenWhen Edward Snowden disclosed the NSA’s activities, many people came to realize that network systems can be misused, even though this was always the case.  People just realized what was possible.  What happened next was a concerted effort to protect protect data from what has become known as “pervasive surveillance”.  This included development of a new version of HTTP that is always encrypted and an easy way to get certificates.

However, when end nodes hide everything from the network, not only can the network not be used by the bad guys, but it can no longer be used by the good guys to either authorize appropriate communications or identify attacks.  A example is spam.  Your mail server sits in front of you and can reject messages when they contain malware or are just garbage.  It does that by examining both the source of the message and the message itself.  Similarly, anyone who has read my writing about Things knows that the network needs just a little bit of information from the device in order to stop unwanted communications.

I have written an Internet Draft that begins to establish a framework for when and how information should be shared, with the idea being that information should be carefully shared with a purpose, understanding that there are risks involved in doing so.  The attacks on Twitter and on are preventable, but it requires us to recognize that end nodes are not infallible, and they never will be.  Neither, by the way, are network devices.  So long as all of these systems are designed and built by humans, that will be the case.  Each can help each other in good measure to protect the system as a whole.

Photo of Edward Swowden By Laura Poitras / Praxis Films, CC BY 3.0

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.


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.


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…


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

iPhone TouchID doesn’t protect you from the government

FingerprintIt’s a common belief that Apple has gone to extraordinary lengths to protect individuals’ privacy through mechanisms such as Touch ID, but what are its limits?  Today Forbes reported that a U.S. attorney was able to get a warrant for the fingerprints of everyone at a particular residence for the express purpose of unlocking iPhones.

Putting aside the shocking breadth of the warrant, suppose you want to resist granting access to an iPhone.  It is not that hard for someone to force your finger onto a phone.  It is quite a different matter for someone to force a password out of your head.  Apple has gone to some lengths to limit certain forms of attack.  For instance, the Touch ID generally will not authenticate a severed finger, nor will it authenticate a fingerprint copy.  Also, Apple doesn’t actually store fingerprint images, but rather hashes of the information used to collect fingerprints.  Note that if the hashing method is known, then the hash itself is sensitive.

For those who care, the question is what length someone is likely to go to gain access to a phone.  Were someone holding a gun to my head and demanding access to my phone, unless it meant harming my family, I’d probably give them the information they wanted.  Short of that, however, I might resist, at least long enough to get to have my day in court.  If that would be your approach, then you might want to skip Touch ID, lest someone simply gets rough with you to get your fingerprint.  The problem is that Touch ID cannot currently be required  in combination with a pass code on iPhones and iPads.  Either suffices.  And this goes against the a basic concept of two-factor authentication.  Combine something you have, like a fingerprint, with something you know, like a pass code.