One of the things I dislike about being a security person is the stigma that "we are the people who say no or make it harder than it has to be." For many people, the security team is composed of people who just seem to live to make it harder. We don't let them use wireless, surf websites they want to go to, engage in social media activities, install applications, change their passwords, etc. etc. I get it. No one wants to be told what to do and sometimes the reasons we do things may not be readily apparent to everyone. But just because security is inconvenient sometimes is not a reason to scrap it. On the other hand, not all security has to inconvenient. There is a balance to be struck.
David Jeffers over at PC World has an article up about why convenience is the enemy of security. Jeffers's premise is: "tools that make your life more convenient also tend to make it less secure. Technologies that make you more secure are also generally inconvenient." Jeffers uses the case of passwords as an example. Enforcing strong password policies can be burdensome and, yes, inconvenient. Using biometrics like facial recognition and fingerprint match can be fooled. He advocates two-factor authentication as an alternative if it's not too inconvenient.
Let me make clear that I am not a big fan of passwords. I have written before this that I use a password manager because keeping track of strong passwords from all of the different sites we use is rapidly moving beyond the capabilities of the average human. I do think we need to come up with something better than passwords. I like facial recognition, for instance. I use it on my own laptop. Yes, as Jeffers says, nothing stops a person from using a picture of someone. For that matter, what stops someone from cutting off a finger or cutting out an eye to use it to fool fingerprint or retina recognition (we have all seen these tricks in the movies). At least with some facial recognition systems you need to move side to side, and I assume this would thwart someone using just a two-dimensional picture.
Think about it. If we went to facial recognition or perhaps voice or some other unique identifier, we could have convienience and security. If you want to add a second authentication factor, such as a cellphone texted pin, then great, the more the merrier. I do think people would much rather do that than remember an endless string of impossible passwords. We could have security and convienience, having our cake and eating it too.
But that is only password security. Why can't people use Facebook on the LAN or install software on their machines? I am not aware of any biometric magic that can help with that. There are of course other examples. Security, I'm afraid, is very much about balancing risk and reward. I disagree with David, though, not all tools that make your life more convenient also make it less secure.
The problem is that security is an afterthought with many of these tools. If security was built in from the design stage on, it would not be a case of feeling that security denied you from doing something or going somewhere.
If someone said I want to have a social network where people can share information in a secure manner and not be able to download anything malicous, and set out to design such a system, we security people would be out of jobs. But that is not the case. I have heard this first hand myself. A recent podcast I did with some security analysts from Securosis and some NoSQL database vendors proved that to be true. I was shocked that the NoSQL vendors admitted that security would be built in when their customers asked for it as a priority.
To me, this is the classic security versus convenience model. If, on the other hand, a NoSQL vendor (and I don't mean to pick on NoSQL vendors, this applies to all technology) said my solution has to be secure from the get go, not after something bad happens, it would change the equation drastically.
So is convienience the enemy of security? Not necessarily. If security is built in by design you really can have your security and convienience too.