Adding new vulnerabilities: a thought on the Germanwings crash

I saw some interesting commentary on last week’s Germanwings crash. According to investigators, when the pilot left the cockpit (presumably to use the lavatory), the first officer locked the cockpit door and began a slow and intentional descent into the side of a mountain. The captain attempted to regain entry to the cockpit, but the first officer never opened the door. Locking cockpit doors, which were a reaction to the September 11 hijackings, have three settings: unlocked, locked, and really locked. The “really locked” does not allow even authorized users in unless someone on the inside opens the door.

The person, whose name I failed to note, remarked that the locked door is what enabled this crash to happen. In the wake of 9/11, we protected the flight crews from passengers through allegedly better security screening and locked doors. At the same time, we’ve taken away the ability for passengers to protect themselves from the flight crew. (In the U.S., regulations require someone else, either another pilot or a cabin crew member, to sit in the cockpit while a pilot is out, presumably for this reason.)

150 people were killed because the captain was able to be locked out of the cockpit. If the “really locked” setting weren’t available, it’s hard to say what might have happened. The flight crew may have scuffled with the same end result, but I think the most likely scenario is that the first officer would have never attempted this in the first place.

So where am I going with this? IT seems to have a particular affinity for aviation. We’re both relatively new, both complex, and both generally smooth-running with the occasional spectacular failure (fortunately for IT, we’re far less likely to have our failures result in death, at least currently). Both industries have a love for checklists and trying not to fail in the same way twice.

The Germanwings tragedy can be a lesson for IT. By solving one vulnerability, an entirely new one was introduced. This is hardly a new lesson, we often talk about fixing one bug to introduce others. The important thing is to consider this not at the code level, but at the design level. When thinking about software or systems, it’s important to think about what a change that seems like a great idea might have really undesirable effects.