If there’s a theme in my recent postings, it’s that I’m turning into a curmudgeon; complaining and ranting and shaking my head. I’ll get over it, I’m sure! Just…not yet!

There are so many levels to security, it’s sick. You can talk about microscopic security (in an SMB) or macroscopic (global/universal). Web App or Network or OS. Data or device. High risk/value, low risk/value. Skiddies, APT. General users or highly technical admins. Your customers or your company’s customers. And on and on and on…. It’s crazy. It’s liable to always be the monkey[wrench] chuckling from around a blind corner that keeps poking holes in any sort of best practices or standards or commonality amongst any of them. At some point, you have to get back to the basics and starts making your Laws. You will be breached. No single answer is The Answer. Staff is key. Users are a big weakness. Security vs convenience. The point of business is not digital security. Secure Enough. And so on…

And sadly, for almost every Law, we can come up with, “Yeah buts.” Maybe the Best Practice is that there is no universal Best Practice? Yeah, that will make every executive roll their eyes and find a new consultant/partner/manager/tech. I still have this nagging feeling that our problem is one that is not just at odds with users and convenience, but fundamentally at odds with business and management; that the last 50 years of digital technological development is still dashing a century of business acumen in the face; that they’re just not all that compatible without painful change, much akin to the RIAA/MPAA/newspapers and their painfully changing businesses. Or maybe not. Maybe we’re (IT that is) just an underswell right now, that we’re just heaving up against the older guard of business…like a rolling wave (a slooow one)…that will recede back down in the future? Possible…though it doesn’t help that business keeps dragging IT (and thus security) back into the core business in ways that aren’t very smart or far-seeing. It’s like a heaving wave pushing up against your inflatable raft, while also turning up the wave pool dial and splashing your own face with more water, both sick of it and yet insatiably wanting more. Like McDonald’s fries.

Rafal Los published a post the other day that sparked some of these thoughts of mine, not directly, but just through his tone, really. His post titled, The Path of Least Resistance, went into some not-new, but good thoughts:

…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.

It’s important to remember this applies not only to “users” but also to technical persons, even in fact the administrators creating these policies/processes! We routinely know security processes and routinely ignore them in order to get the *real* immediate issues taken care of. A user needs to reset their password. You know the user, so do you take the time to go through proper procedure or do you pursue the positive feedback that comes from quickly helping the user get on with their life/job? If your boss finds out about either case, which one will get *him* in trouble quicker, and thus which one will get reflected in *your* next professional appraisal? I’d suggest we almost always reward Getting Things Done rather than inconveniencing anyone with process. Even the best customer service stories taught in generic management classes espouse breaking rules to solve problems and send customers away happy.

You can’t do that in security unless you are an expert and can make risk decisions quickly and accurately. Otherwise you should follow process; it’s there to help security in situations where the involved actors aren’t sure what is risky or not. And, by that very nature, will always add inconvenience (or other resources).

Even the most simple concepts of “risky” behavior vs “non-risky” behavior involves negative cost, whether we’re talking security or even safety. I really wonder if there are very many examples where doing something securely is easier (less costly) than doing it insecurely, when simply in the moment and ignoring resulting costs/benefits.

Rafal Los goes on to talk about creating software more securely:

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.

Now, one can look at this and mistakenly say, “Well, let’s just make it really hard to make insecure software. You have to jump through hoops, sign documents, put your pay on the line, and so on if you want to do something that is less secure (assuming you even know what secure means, which you likely don’t if you even have this problem). That way making it less secure is harder!

I doubt that’s what Rafal was going at, but I’m not sure you can simplify making things more secure from the start. I mean, it’s always going to be *easier* to write simpler, less secure code, right? Accepting raw user input will always be easier than accepting user input after a scrubbing routine. Even the pseudo-code for that illustrates the extra steps, yeah?

Maybe I’m still thinking inside the box. 🙂 If I think of any situations where it is less costly to do some more secure, I’ll post a follow-up.