Democracy in America is under attack

Washington Crossing the Delaware, Emanuel Leutze (American, Schwäbisch Gmünd 1816–1868 Washington, D.C.), Oil on canvas, American — Washington Crossing the Delaware

On this day, July 4th, 1776, our founders gave birth to a democracy through great strife that other societies have envied and about which they have dreamed. Today, that democracy is under attack.

Thomas Jefferson had lifted some words from John Locke to declare that-

We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness
The Declaration of Independence

Embedded in the very notion of democracy is that there should be strife, in terms of choices voters may have. It was this choice the founders made, and it was this choice the founders gave us. Its basis was and remains consent of the governed. Back then, white male landowners could vote. It took more strife, The Civil War, to establish that all men could vote; where America turned in on itself, but ultimately reaffirmed that government must be, as Lincoln so aptly said, “of the people, by the people, for the people”. And it took yet more strife for women to achieve the right to vote, and yet more strife to those rights.

With false claims of “voter fraud” one party seeks to silence people’s right to vote. This has been tried before. The dreadful Supreme Court decision this past week amounts to license for Jim Crow Laws to rise again. Consent of the governed means that all who are governed must have a vote, in order for the government to be legitimate and accepted.

By imposing more and more voting restrictions, governments of such states such as Arizona, Texas, and Georgia are doing nothing more than removing their own legitimacy. This too will not stand. A tyranny cannot stand, as England discovered.

Should I have that IoT device on my home network?

Yesterday I wrote about my cousin’s smart oven, and the risks of having it networked. Does this mean that you should have no IoT devices in your house? If not, how should you decide which ones are worth connecting? Here are three questions you might want to ask.

Does connecting the device to your network offer you any perceptible value?

Sometimes the answer is going to clearly be “yes”. For example, if you are taking a vacation in the middle of the winter in some cold place, you might want to know that your home’s heater broke down before your pipes froze. Having a thermostat configured to alert you to this fact might prove very useful. On the other hand, if you are in a place where such a concern is unwarranted or you would have no reason to worry about such things, maybe that same device does not need connectivity.

Will the device function correctly without connectivity?

Don’t expect an Amazon Echo to function, for instance. There is a reason why a great many IoT manufacturers are requiring Internet connectivity for their devices: the more intelligence they can move into their servers, the less intelligence is needed in the device itself, making it cheaper to build. If you are going to have a function like this in your house, this is actually an environmentally friendly way to go. Fewer parts require fewer resources used to build and to later dispose. But if a device does function properly and fully without Internet connectivy, why plug it in?

Does that device need continuous Internet connectivity?

You are unlikely to connect and reconnect your television every time you want to watch a video, but maybe you only need that thermostat connected while you are on vacation, for instance, or maybe an appliance needs a firmware update via the Internet. Occasionally connecting a device may make sense. However, take care: if you only plug in devices while you are on vacation, someone may be able to notice that and choose that time to break into your home.

Some Internet routers have the ability to block devices at certain times. Typically this is used to limit children’s access. However, one can also use these filters for other purposes. The problem is that this is nearly as annoying as having to deconfigure devices themselves. I’ll discuss this more in the near future.

Think before you buy!

The risk to your home and your privacy is real. Realistically, however, you will have some IoT devices in your house. Think about what value you derive from them, and what can go wrong if they are attacked before you buy.

New Paris Cyber-Accord: Nice words. What comes next?

The accord and Macron’s words are a bit “aspirational”.

Recently France has taken the initiative to produce what they call The Paris Call for Trust and Security. This call has garnered signatures of some 57 countries and and several hundred companies and organizations (including that of my own employer).^* What President Macron and others have recognized is that there is a risk of both state and non-state actors interfering in the lives of everyday people, possibly causing them great harm.

Every day provides a new example of why protection of our institutions is necessary. This video was made some time ago. We’d like to think that security of our infrastructure has improved, but Marriott proved us wrong last week, with over half a billion customer records having been stolen.

The Paris Call seems to address itself to these sorts of civilian attacks, which to me is appropriate. In particular, it focuses on the following areas (I’m condensing just a bit):

Protection of critical infrastructure,
Protection of electoral processes (Gee, I wonder who that is aimed at),
IPR protection,
Tools development to prevent the spread of malware,
No hack-backs, where people attempt to take the offense as a either a defense or a means of deterrence,
Acceptance of international norms of behavior.

The Call does not create or call for the creation of any new mechanism to pursue these points, but rather the use of existing mechanisms. Instead, what we appear to be witnessing is the creation of a voting bloc inside existing multilateral and multi-stakeholder processes, as well as a non-binding commitment among the signatories themselves to pursue these principles. It’s all motherhood and apple pie until we understand what the actual instantiation of these principles means. Does it mean, for instance, an end of free software in order to protect content providers? Will it require content publishers to actively protect all rights of copyright holders, even if those holders are unknown?

Also, should these principles apply equally to civilians and the military ? Let’s take for example the Stuxnet attack, where some state actor attacked Iran’s nuclear weapons facility. Should that attack have been prevented by these principles? To what end? Helping Iran gain an offensive nuclear capability? If the choice was a cyberattack against a military installation versus a physical attack, where people would surely die, I’ll take the cyber attack any time.

There is another big topic that isn’t covered. Right now governments are all struggling with how to handle cross-border law enforcement. That is- if someone in Jurisdiction A hacks into or uses a computer in Jurisdiction B to attack a person in a third Jurisdiction C, who can reasonably ask Jurisdiction B for the data? This is a massive topic that the Council of Europe has been attempting to address for years. These are knotty issues, because of the limitations on the powers of each country relating to search and seizure.

In short, while this is nice text, it doesn’t seem to me to accomplish much on its own.

It does seem to be a slap at Russia and China, two notably absent countries. Three other notably absent countries are the U.S., Israel, and Iran. Coincidence? I think not.

^*The views of my employer surely vary from my own today.

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.

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.