It’s been a tough week (think: windows domain DNS corruption), so I wanted to poke at something and not spend too much energy. Happily, I came across two nice entries by Ben Tomhave. The first is “3 Common Ways Security Fails People.” Sounds like fun, and I’ll go over each of the 3 points with my Devil’s Advocate robes on. I could rename these as the Neutrality Robes, or Robes That Keep Overzealous Ideas Checked Into Reality.

1) It [security] gets in the way. Well, duh. And that’s just going to be the way it is. A firewall gets in the way of traffic. A castle wall-n-moat get in the way of open wandering. I do actually like the points Ben makes here, but ultimately we are dooming ourselves if we let ourselves (and others) think that security needs to not be in the way. But yes, people who want to do things will find ways to do them. And that’s not the fault of security as much as the fault of the people finding ways around security. Just this week I had a developer using a writable file location set up for purpose X, and he decided he wanted to start writing application logs somewhere. So he picked that spot that he knew he could write to, which added an undocumented use to a location otherwise used for just one thing. Thankfully we talked about it and his need was only temporary so I allowed it, but that’s the kind of thing security runs into, and always will.

2) It makes life more difficult. Well, yeah. If you want a more secure house, you make the rounds to ensure the windows are locked, garage door is down, and alarm set. God forbid that is annoying. This wouldn’t be the case at all if a) shit worked, and b) people weren’t human. I made the comment on the blog post example that perhaps Ben was in the wrong for accessing OWASP Google Apps with a non-standard account, rather than blaming security for making his life difficult. Security is a compromise and a give-and-take [risk]. That goes both ways.

3) It doesn’t understand what’s important. I hear this enough that I’m kinda sick of it, but it’s a good point. Again, though, this goes both ways. If what you’re doing isn’t in the best interest of what’s important in the business, and security calls you on it, don’t blame security. And don’t yell at security for everything that doesn’t go your way. Yes, people do that.

The second article is similar in tone: “3 Uncommon Solutions for the 3 Common Problems.” I also like this article, but I haven’t taken off my robes yet…

1) De-Operationalize “Security” – I understand the spirit of this point: get security inherent in the way operations works. But I’m not sure this ever really properly works without oversight of some degree. First, when push comes to shove and I have to do task A to satisfy a customer or do task A with a dab of security B on top, when I already have an overflow of things I need to do to satisfy business/customers, I’ll do A and attend to B later when I have time. Operations will *always* get in trouble for not doing A, but will rarely get in trouble for pushing off security B. This is the same concept for coding. You can assign a variable a value quite easily, but to assign that variable in a secure, scalable, documented way takes more effort and knowledge. This is why I will agree that operations needs to do security, but the pressures are never really there to make sure security is as important as accomplishing the goal. If customer pressures Admin to open the firewall in an insecure way, what do you think that admin will do when part of his job appraisal is based on customer service and peer feedback?

I could even tackle the idea that security is everyone’s problem. While certainly a requirement in a blended approach, I’ll take technological controls over human decision-making any day. At least from a strictly security perspective.

2) Elevate “Security” to “GRC Program” I’m not going to tackle this because I’ve never worked in a situation like this. It’s a bit of a sideways step to my experiences. In the brief mention in this article, it just seems like another silo and something for people to point fingers at. It also feels like it will still depend on all the operational people and technical managers to filter up enough accurate knowledge for potentially non-technical GRC managers to make decision upon. I’d rather just have one layer of experts (security team), but again, this isn’t my reality.

3) Understand the Business – I’m losing mental momentum after my long week by now, so I don’t have much to say that is useful. I agree with the concept, but I don’t necessarily like the idea that regulations are distracting. Difficult and annoying, sure, but I’m not sure how any of them go against what a business wants, other than being a cost center. This may just be an illustration of the break between auditors (and external security) and their rigid interpretations of regulations and very un-agile recommendations to meet them for every business.