Security Theater

by Krishna on January 12, 2010

Bruce Schneier (the author of “Applied Cryptography” and other books) explains why security theater (where security measures do not do much to improve real security) has its benefits:

Tamper-resistant packaging for over-the-counter drugs started to appear in the ’80s, in response to some highly publicized poisonings. As a countermeasure, it’s largely security theater. It’s easy to poison many foods and over-the-counter medicines right through the seal — with a syringe, for example — or to open and replace the seal well enough that an unwary consumer won’t detect it. But in the ’80s, there was a widespread fear of random poisonings in over-the-counter medicines, and tamper-resistant packaging brought people’s perceptions of the risk more in line with the actual risk: minimal. […]

We make smart security trade-offs — and by this I mean trade-offs for genuine security — when our feeling of security closely matches the reality. When the two are out of alignment, we get security wrong. Security theater is no substitute for security reality, but, used correctly, security theater can be a way of raising our feeling of security so that it more closely matches the reality of security. It makes us feel more secure handing our babies off to doctors and nurses, buying over-the-counter medicines and flying on airplanes — closer to how secure we should feel if we had all the facts and did the math correctly.

The relation to the business world is “management theater”. There are these tons of management processes that don’t do anything to improve the success of the project or prevent its failure. Instead, they are to reassure stakeholders that “proper” management is in place.

The lesson from Bruce’s article is that even though we may want to throw all of such processes out the window, they may actually have an use. Instead of customers becoming tense and worried, and upper management trying to micro-manage the project, some of these processes may convey that the project is truly under control and the project team can be trusted. It can also reduce finger-pointing and place emphasis on improving items that hinder the project.

The tricky thing is to know what process to keep in and what to take out. What Bruce’s article suggests is to ask stakeholders or understand them to see what keeps them comfortable. For example, they get project updates in a specific format at regular intervals. Or the build, testing and deployment process is done in a specific way and is visible to them. The customer may not even read the report, but the fact that they have it keeps them happy.

Comments on this entry are closed.

Previous post:

Next post: