John DiMarco on Computing (and occasionally other things)
I welcome comments by email to jdd at cs.toronto.edu.

Mon 04 Mar 2019 12:04

Externality and Information Security
It was a hot midsummer weekend, and I was traveling back to Toronto with friends. We were on the expressway (the name here in Ontario for the sort of road that Americans call freeways and Brits call motorways). Traffic was very slow: a classic traffic jam. After about thirty minutes, we reached the cause of the problem. It was not a collision. Nor was it highway construction. Instead, by the side of the roadway, a minivan was parked, back gate open, and a family was having a picnic on the nearby grass. I don't know if they realized they were causing a traffic jam, but they were. People had slowed to look, which caused traffic behind to slow too, and because of the traffic volume, this led to a traffic jam over a considerable distance.

I don't know why the family having the picnic had chosen that spot for it, and I don't know whether they realized the problem they were causing. But their picnic went on, unaffected by the traffic problems they were causing. In other words, the traffic jam was not their problem. It was an externality, something causing a negative effect not felt by those who cause it.

Externalities happen in life all the time. Large organizations (companies, countries, institutions) suffer significantly when their decision-makers make decisions that are good for themselves but not good for the organization. Rules to make this less likely are put in place: rules against bribery, rules concerning conflict of interest, rules imposing due process. But rules only work to a certain extent: there are plenty of situations where the rules are followed yet still externalities happen. Moreover, rules come with costs, sometimes significant ones. Rules may be necessary, but they are not sufficient, and they need to be accompanied by buy-in.

Let's consider traffic again. Driving is governed by all sorts of rules. Some of these rules work well: at traffic lights, go when the light is green, stop when it is red. Rarely broken, this rule makes traffic work in dense situations where otherwise there would be chaos. Most of the time, this rule is followed even in the absence of external enforcement. When enforcement does occur, it is well regarded: hardly anyone will argue that a person running a red light is a safety hazard and should be ticketed. In practice, you can stand for hours beside a busy traffic signal in a typical Ontario city, and despite the absence of police presence, not find a single driver running a red light.

Sadly, other driving rules don't work quite so well, such as speed limits on expressways here in Ontario. These limits are often broken, with some following them and others not. Often, on an uncongested expressway, unless enforcement is likely (i.e. police is present) there will be some people driving over the speed limit. Enforcement is viewed cynically: speeding tickets are often viewed more as revenue generation than as a safety measure. Obeying speed limits is often viewed by drivers as an externality: not my problem, unless there is a police officer around to make it one. In practice, at any place on any uncongested Ontario expressway, you will be hard-pressed to find a five-minute period in which no passing driver has exceeded the speed limit.

I have been thinking a lot about information security lately. In information security, we have a situation similar in many respects to driving. Just as driving is a matter of traveling safely, information security is a matter of computing safely. When we compute, we may be processing information that is sensitive, confidential, private. Harm can occur when it is exposed. Steps need to be taken to ensure that it is not: persons handling information will have to handle it securely. But do we want this process to look like speed limits? Or traffic lights? I think the answer is clear: if we want information to actually be secure, we want good security practice to be followed like the rules for traffic lights are followed: broadly and consistently, without the need for the constant threat of enforcement.

In recent years, an information security profession has arisen. The increasing demands of the profession have made it increasingly rare that an information security professional has spent much time actually running a substantial IT operation. Certifications abound, and a multiplicity of complex and large security standards have been created, each requiring professionals to interpret. A great deal of money is being spent on information security. Much of this is good and necessary: information security needs attention, codification, dissemination, and championship. But the professionalization of information security comes with big risks, too: the risk that information security will become the responsibility only of specialists, the risk that these specialists will come up with all-encompassing codexes of security standards to impose, the risk that these standards will be treated as externalities by IT practitioners, the risk that the information security profession will respond with enforcement, and hence the risk we will find ourselves in the expressway speed limit situation with respect to information security.

The fact is, information security is an aspect of good IT practice: if an implementation is not secure, it is broken, just as much as if it were not reliable. Security is the responsibility of all IT practitioners: it needs to be internalized, not externalized.

For this to happen, it is important that information security rules be simple and understandable, to ensure buy-in. Just as traffic light rules address the obvious risk of traffic accidents, so should security rules address clear risks in a visibly appropriate way. In most cases, it's not so important that rules be part of a comprehensive codex that addresses all possible areas of risk: the more complex the rule and the more extensive the system of rules, the more likely it will all be treated as an externality. What we really want are not rules for their own sake, but genuinely secure IT.

If we want secure IT, we need to recognize that there is another potential externality at work. Genuine information security and the good of the information security profession may not always align. Just as expressway speed limits employ more police than traffic lights, an enforcement approach will employ more information security professionals than an internalized one. But the internalized approach is what gives us secure computing. This is not something that can be left to the information security profession alone. To get there, we will need collaborative effort from all of us, particularly those with long experience running substantial IT operations. We will all need to make a true commitment to a practical approach, one that seeks to make computing genuinely more secure in the real world.

/it permanent link


Blosxom