Would you want your cousin using a connected oven?

Recently my cousin installed a smart oven into her home. It is top of the line. She wrote on social media that it texted her to tell her that it needed to clean itself, which it did before her second cup of coffee. How cool is that?

I immediately feared for her safety. Here is a slightly edited version of what I wrote to her:

IoT is a nice convenience, but there are a few things you should know. First, I guarantee that there are vulnerabilities in the device, even if some have yet to discover them. This is true for *any* connected device. Those vulnerabilities may be exploited at some point. What will happen then?
First, it’s possible that attacker could simply disable the oven. They probably won’t do this unless they are able to communicate with you. But since the oven seems to be sending you messages, it’s possible that they will do this and ransom you to re-enable it. (If that happens, don’t pay.)
Whether or not you can control the oven from the app, don’t think for a moment that hackers won’t be able to gain that level of control. That presents a far more serious risk: a fire, especially if the hackers are able to detect that the cooking temp is supposed to be 350, and turn the thing up to broil or clean.
The other thing that will happen is that the oven will attack other Wifi-enabled devices in your house or elsewhere. If you have a Wifi-enabled thermostat, maybe it will attack that. Some of those devices have cameras and microphones. The attackers aren’t going to be nice about what information they collect. They’re out to make money or worse.
Will any of this happen? Yes – to many people. Am I being paranoid? Maybe a little. Appliance manufacturers may know how to make excellent oven mechanisms, refrigerator compressors, stove top elements, etc, but they generally know very little about Internet security and their risks. Even those who know a lot get it wrong all the time, simply because we’re human.
And so are you gaining any great convenience by having the Wifi turned on, apart from a 5:30am wake up call to let you know that it needs to clean itself? If yes, you have a trade off to make. If not, just disable its darn Wifi.

This is how I feel about technology and the ones I love. Presumably you have some of those. There are definitely times when IoT is necessary, and when convenience is probably worth the risk. But consumers really need to think about this long and hard, and we professionals need to provide them a decent decision framework. I’ll talk about that next.

RFC 8520 on Manufacturer Usage Descriptions Released

Today the RFC Editor released RFC 8519 (the ietf-acl model) and RFC 8520 (Manufacturer Usage Descriptions). The ACL model provides for a programmatic YANG-based interface that is flexibly extensible. Manufacturer Usage Descriptions (MUD) extend this model so that manufacturers are in a position to request the network’s assistance.

MUD’s declarative model for manufacturers to describe to customers what network resources their devices are designed to use. No guessing games are required. Manufacturers use simple abstractions to describe what access a device needs, such as a domain name for cloud-based service, or same-manufacturer or my-controller for local devices.

Even when one doesn’t use automated tools, there is benefit to manufacturers in writing MUD files. A study by the University of New South Wales found that IoT devices often conflict with enterprise network policies, and that this goes largely unnoticed by administrators who don’t understand the needs of those devices. What we can say is that if manufacturers do a little bit of work, they and our customers can both derive a whole lot of value from the network.

A fair amount of software already exists for MUD, including the NIST MUD Manager, and the tools built by CIRA, not to mention Cisco’s open source version, and osMUD.org, and commercial versions built by Yikes! and Cisco. Google has implemented a MUD manager as for build management. And of course you can build your own MUD file for your device by going to https://www.mudmaker.org.

MUD is part of a nutritious meal, but it is not the whole meal. Manufacturers should always use best coding practices, and update firmware and software promptly when they learn of vulnerabilities and exploits

Next Steps

It’s time for manufacturers to implement! Protect your devices with MUD!

Ain’t No Perfect. That’s why we need network protection.

If Apple can blow it, so too can the rest of us. That’s why a layered defensive approach is necessary.

When we talk about secure platforms, there is one name that has always risen to the top: Apple. Apple’s business model for iOS has been repeatedly demonstrated to provide superior security results over its competitors. In fact, Apple’s security model is so good that governments feel threatened enough by it that we have had repeated calls for some form of back door into their phones and tablets. CEO Tim Cook has repeatedly taken the stage to argue for such strong protection, and indeed I personally have friends who I know take this stuff so seriously that they lose sleep over some of the design choices that are made.

And yet this last week, we learned of a vulnerability that was as easy to exploit as to type “root” twice in order to gain privileged access.

Wait. What?

Ain’t no perfect.

If the best and the brightest of the industry can occasionally have a flub like this, what about the rest of us? I recently installed a single sign-on package from Ping Identity, a company whose job it is to provide secure access. This simple application that generates cryptographically generated sequences of numbers to be used as passwords is over 70 megabytes, and includes a complex Java runtime environment (JRE). How many bugs remain hidden in those hundreds of thousands of lines of code?

Now enter the Internet of Things, where manufacturers of devices that have not traditionally been connected to the network have not been expert at security for decades. What sort of problems lurk in each and every one of those devices?

It is simply not possible to assure perfect security, and because computers are designed by imperfect humans, all these devices are imperfect. Even devices that we believe are secure today will have vulnerabilities exposed in the future. This is one of the reasons why the network needs to play a role.

The network stands between you and attackers, even when devices have vulnerabilities. The network is best in a position to protect your devices when it knows what sort of access a device needs to operate properly. That’s your washing machine. But even for your laptop, where you might want to access whatever you want to access, whenever you want to access it, through whatever system you wish to use, informing the network makes it possible to stop all communications that you don’t want. To be sure, endpoint manufacturers should not rely solely on network protection. Devices should be built with as much protection as is practicable and affordable. The network provides an additional layer of protection.

Endpoint manufacturers thus far have not done a good job in making use of the network for protection. That requires a serious rethink, and Apple is the posture child as to why. They are the best and the brightest, and they got it wrong this time.

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:

Prohibit them and enforce the prohibition by firing anyone who attaches an unauthorized device.
Allow them and suffer.
Prohibit them but not enforce the prohibition.
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.

Pew should evolve its cybersecurity survey

Pew should evolve the questions they are asking and the advice they are giving based on how the threat environment is changing. But they should keep asking.

Last year, Pew Research surveyed just over 1,000 people to try to get a feel for how informed they are about cybersecurity. That’s a great idea because it informs us as a society as to how well consumers are able to defend themselves against common attacks. Let’s consider some ways that this survey could be evolved, and how consumers can mitigate certain common risks. Keep in mind that Pew conducted the survey in June of last year in a fast changing world.

Several of the questions related to phishing, Wifi access points and VPNs. VPNs have been in the news recently because of the Trump administration’s and Congress’ backtracking on privacy protections. While privacy invasion by service providers is a serious problem, accessing one’s bank at an open access point is probably considerably less so. There are two reasons for this. First, banks almost all make use of TLS to protect communications. Attempts to fake bank sites by intercepting communications will, at the very least produce a warning that browser manufacturers have made increasingly difficult to bypass. Second, many financial institutions make use of apps in mobile devices that take some care to validate that the user is actually talking to their service. In this way, these apps actually mark a significant reduction in phishing risk. Yes, the implication is that using a laptop with a web browser is a slightly riskier means to access your bank than the app it likely provides, and yes, there’s a question hiding there for Pew in its survey.

Another question on the survey refers to password quality. While this is something of a problem, there are two bigger problems hiding that consumers should understand:

Reuse of passwords. Consumers will often reuse passwords simply because it’s hard to remember many of them. Worse, many password managers themselves have had vulnerabilities. Why not? It’s like the apocryphal Willie Sutton quote about robbing banks because that’s where the money is. Still, with numerous break-ins, such as those that occurred with Yahoo! last year^*, and the others that have surely gone unreported or unnoticed, re-use of passwords is a very dangerous practice.
Aggregation of trust in smart phones. As recent articles about American Customs and Border Patrol demanding access to smart phones demonstrate, access to many services such as Facebook, Twitter, and email can be gained just by gaining access to the phone. Worse, because SMS and email are often used to reset user passwords, access to the phone itself typically means easy access to most consumer services.

One final area that requires coverage: as the two followers of my blog are keenly aware, IoT presents a whole new class of risk that Pew has yet to address in its survey.

The risks I mention were not well understood as early as five years ago. But now they are, and they have been for at least the last several years. Pew should keep surveying, and keep informing everyone, but they should also evolve the questions they are asking and the advice they are giving.

^* Those who show disdain toward Yahoo! may find they themselves live in an enormous glass house.