Secret sauce and sentencing? Say it isn’t so!

Could you spend a long time in prison due to a software bug and not have the right to examine the software? Possibly.

One of the things that we in technology understand is that we make mistakes, a truth we don’t like to admit to customers. What happens, however, when a mistake can lead to tragic consequences?

Yesterday’s New York Times reports about a case that the U.S. Supreme Court may soon hear, involving a man who received a six year jail sentence, in part due to a computer program. The software known as Compas was supposedly developed by Northpointe Inc. (although a search seems to redirect to a Equivant) to provide a risk assessment of a person’s reentry into society. Such a data-driven analysis is vaguely reminiscent of the movie, Minority Report. In this case, the defendant Eric L. Loomis was not allowed to examine the software that assessed that he was a significant risk to the community, even though at least one analysis showed that the software may be programmed with some form of racial bias. The company argues that the algorithm used to make the sentencing recommendation is proprietary, and so should not be subject to review, and that if they release their algorithm to scrutiny they will essentially be giving away their business model, and they may have a point. Patents on such technology may be flimsy, and they eventually do come to a halt. To protect themselves, they make use of another legal tool, the trade secret, which has no fixed term of protection.

One can’t say that a mistake is being made in the case of Mr. Loomis, nor can one authoritatively state that the program is formally correct. The Wisconsin Supreme Court argued creatively that much like college admissions, so long as the software is one input combined with others, the software can be used. Is it, therefore, any different from a potentially flawed witness giving evidence? The question here is whether those who wrote the software can be cross-examined, to what extent they may be questioned, and whether the software itself can be examined. Mr. Loomis argues that to deny his legal team access to the source is a violation of his 14^th Amendment right to due process.

We know from recent experience that blind trust in technology, and more precisely, those who create and maintain it, can lead to bad outcomes. Take for instance the over 20,000 people whose convictions were overturned because a chemist falsified hair analysis results, or other examples where the FBI Crime Lab just flat got it wrong. Even Brad D. Schimel, the Wisconsin attorney general, conceded before the appeals court that, “The use of risk assessments by sentencing courts is a novel issue, which needs time for further percolation.” But what about Mr. Loomis and those who may suffer tainted results if there is a software problem?

While the Supreme Court could rule soon on the matter, they will only have very limited avenues, such as permitting or prohibiting its use. Congress may need to get involved in order to provide other alternatives. One possibility would be to provide the company some new intellectual property protection, such as an extended patent with additional means of enforcement (e.g., higher penalties against infringement or lower thresholds for discovery) in exchange for releasing the source. Even if they do, one question would be whether or not defendants could then game the system so as to score better on sentencing. How great a risk that is we can’t know without knowing what the inputs to the algorithm are.

It is probably not sufficient for the defendant and his legal teams to have access to the source, precisely because more research is needed in this field to validate the models that software like Compas uses. That can’t happen unless researchers have that access.

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.

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.