"The path of least resistance and least trouble is a mental rut already made. It requires troublesome work to undertake the alternation of old beliefs.” --John Dewey
Anyone who's ever watched water rushing down the side of a hill can attest to the fact that water really doesn't care about obstacles, or which direction you want it to flow.
Water will find a path of least resistance, a way to flow which causes it the least amount of toil, and push its way through down to where it wants to go.
Turns out... users, managers, developers and pretty much everyone who is a 'customer' to the security profession is in the exact same boat (pardon the pun).
So working off that supposition it's not a stretch to consider that when confronted with a complex, convoluted, and difficult set of security processes and controls users often find ways around them without too much fanfare.
Once these ways are discovered, they proliferate in the organization and become staples with the employees... as people figure out how to get their work done, meet their ends while avoiding the ugly hoops security makes them jump through.
So on it goes... and seeing this the security team gets angry, and the emotional response is to scold and put up an even more rigorous and complex process to make sure it's absolutely unavoidable this time... but like the water, the users will find a way.
On this spiral goes, with time and energy wasted while no real end is achieved for the security folks. Why?
You'd think the answer is pretty simple ... security processes are too complex ...right? Yet we collectively as security professionals continue to expend time and energy into building complex systems, processes and procedures only to find them circumvented.
The answer to this quandary is simple ...or rather -simplicity.
I know this isn't something novel to read on this blog, or coming from me -but Software Security Assurance efforts have to make producing and releasing more secure software more simple than releasing less secure software.
If you still see the world in black/white, you're probably going to want to stop reading right about now... otherwise continue.
There are a few things you're going to have to make your peace with, when it comes to this 'easier to be more secure than less secure' concept... first is in the phrasing.
It should be common sense by now, but you're not going for 'secure' anymore... you're going for more secure than what you have now. You're trying to reach a state of secure enough as opposed to a state of secure.
Below are some of the things you need to come to grips with, if your patch, the more secure path, is to be the one your users take:
1. Understand you're going for more secure, not 'secure' ...there is a huge difference not only in terminology but in approach and goals
2. Baby steps - start your SSA program with things that are simple, and have relatively low impact on the user (and unfortunately on security as well)
3. Evolution vs. Revolution - make small changes for the better (more secure), over time, impacting productivity and existing process as little as possible
4. Cooperation with users and developers is important, so it wouldn't hurt to walk a mile in their shoes
5. Known when to stop - meaning you should be prepared to say "we're at a reasonable risk scenario"... we can stop now.
That last one is tricky, right? I mean, how many of us are comfortable with the fact that within even 3 years of kicking off a program we'll be anywhere near our goal of good enough... anyone?
Remember that risk is tailor-made to fit your business, and your business evolves over time as markets grow/shrink and organizational structure and purpose changes.
Just remember, above all else - make your path the path of least resistance ...otherwise don't be too shocked when the water flows around your well-built formal security bits.
Cross-posted from Following the White Rabbit