Is it time to stop talking about “software security”? I believe so – but not for the reasons you might think.
Let’s face it: we routinely underestimate the effect that language has on our perception of the world. This makes sense – we all like to think of ourselves as logical beings, swayed by indisputable facts and direct observations of the world, not words, images and fancy-pants rhetoric. Alas, there’s lots of evidence – anecdotal and otherwise – that just the opposite is true: the language that we use to talk about problems has a huge influence on our perception of those problems and even our willingness to devote resources to solving them.
Take the Estate Tax, for instance. First introduced in 1916, and often referred to as the “Inheritance Tax,” this progressive tax measure sought to curb massive, cross-generational transfers of wealth by assessing a tax on the value of an estate at the time of death. It was widely supported by a broad swatch of the American public for decades. That is, until fiscal conservatives succeeded in shifting the debate from what government could do for people to all the things government did wrong, and the nomenclature from “estate tax” to the “death tax.” At that point, support for the “death tax” dropped precipitously until, by the early part of the last decade, a strong majority of Americans – feeling themselves “overtaxed” -supported repeal of the tax on the wealthy, even though they would never be asked to pay it.
Even more recently, the topic of nomenclature became an issue at The Supreme Court, with conservative jurist Antonin Scalia wondering if the very name of The Voting Rights Act was the reason for its continued, bi-partisan poltical support. “Even the name of it is wonderful: The Voting Rights Act. Who is going to vote against that in the future?” he wondered from the bench.
While the wisdom of that reading of the Congressional record is questionable, there’s no question that what we call things influences our perception of them. In the software security world, I wonder if it has come time to put the term “security” to bed and to start talking, instead, about software “safety.”
The issue is this: “security” as a term isn’t doing the job we want it to. ‘Security’ as it is used in the context of software means the state of being free from dangers and threats. Software that isn’t secure is, we know, ‘insecure,’ meaning it is not free from danger or threat. It is vulnerable – susceptible to attack.
That’s all true, of course, but it also puts the focus on the external actor -the attacker. The software, we’re led to believe, is perfectly safe to use, but a bad guy might come along and smash it. That’s an unlikely event, but not impossible. Be warned.
In this paradigm, security is still considered more of a feature than an essential requirement of software. As Veracode has noted, pre-purchase assessments of security are rare. We expect software to do the job that we acquired it to do. If it is securely designed and deployed – that’s great, but generally not a requirement. And, as we know, most software users take such warnings with much more than a ‘grain of salt’ – try a pinch of salt – anyway.
How different the conversation would be if, instead of talking about software security, we talked about the ‘safety’ of software. You don’t consider safety a ‘nice-to-have’ in your automobile. It’s not satisfactory if your car can basically get you around, but might roll over if you take a turn too fast, or become hard to steer at high speeds. Far from it – we expect our cars to be “safe.” That means they should be engineered to perform flawlessly in expected road conditions and even hazardous conditions. They should also protect us from injury in truly adverse conditions – like collisions or serious accidents. We don’t buy Pintos anymore. Instead, with 65% of those surveyed listing “safety” as their top priority when buying a car, we buy Honda Civics – and largely because they’re safe.
Using the language of “safety” instead of “security” changes the terms of the discussion, just as changing the language from “estate tax” or “inheritance tax” to “death tax” changed the discussion from one about blunting the privilege of birth to one about being kind to the deceased. In the case of software, talking up ‘safety’ over ‘security’ means facing the unavoidable truth that our lives increasingly rely on the proper functioning of software, and that software that is improperly designed, or vulnerable to trivial attacks makes our lives susceptible to disruption and makes us less safe.
Talking about software “safety” means we stop making excuses – or carving loopholes for commercial software publishers. Exempting ourselves from the drama of zero days and emergency patches. We can simply say “Java isn’t safe. It’s dangerous software that Internet users should avoid using at all costs. Seek other options.” That’s, in essence, what companies like Apple have been saying with actions, rather than words. The company automatically blocked Java 7 on OS X systems that had it installed by blacklisting all current versions of the software until a fix for a critical hole was discovered.
But the language of “security” makes it hard to be decisive about such things. We’re constantly left waiting for another patch and hoping that this critical patch, just maybe, will do the trick. This, despite the advice of security experts like HD Moore, who have encouraged web users to consider Java more-or-less permanently vulnerable and to stop using it altogether. That patch isn’t coming. It’s time to make our peace with that and start putting a name to our problem.