Adrian Lane posted what is so far the best blog post of 2011 with, “The CIO Role and Security”. If you read the first 5 paragraphs and can’t find any way one of those situations applies to you, then I dare say you’re not working in security (and I might argue you’re not even working in IT!). I love the point that either you’re Getting Things Done for the company, or you’re going to be shown the door, security-be-damned.

I have “just” 4 thoughts to discuss/add.

First, if I were to formulate any one argument “against” this posture, sometimes those groups throwing out ideas/projects really don’t know security and they just don’t have the knowledge to put it in, and therefore they look to the security geek or CIO/CSO to inject their expert opinion. Of course, this is often done in a non-direct, smarmy-feeling way by looking like a deer-in-the-headlights when asked about security. It would be better to just flat out grow some balls and ask directly for help/guidance. Moving a step further, I’d then say Adrian addresses this in his 2nd bullet, but also the people brainstorming these ideas need to take the blinders off and think a little bit about the whole picture, or at least accept it when someone else does their thinking for them.

Second, Adrian’s post applies not just to the C-level role, but also mid-managers and even the techs in the trenches. *Especially* in the SMB world where quite often, it is low-level tech to low-level tech where projects get communicated. Where any sort of getting in the way of projects is a surefire way to start eliminating potential allies for your long-term advancement in that company. Adrian’s point about security adding complexity will always make me wince when I read it, like some mysterious childhood-borne tic/fear. My addition of complexity just might be compensation for your lack of foresight and critical thinking, eh? (Not an uncommon issue, as I will always draw the analogy of risk-based decisions by typical daily drivers on the road. The ability to think beyond 1 move or 5 seconds is rare…really, you nearly cut me off and bottom-out your front bumper to pull into that turn-off…when there is no one behind me and waiting 5 seconds would have been a tense-free situation? Fuck you.)

Third, this is one of the biggest things I like about compliance regulations like PCI. It gives otherwise powerless/underappreciated security advocates a rather firm way of saying, “No,” by having something else say no. I’ve long called this “security by bowling bumpers,” i.e. fine, we’ll let you wildly toss the bowling ball down the lane, but these bumpers are going to give you finite boundaries on where the ball can go.

Fourth, pick your fights. Some projects can probably be seen right away as never going to fly, maybe because of some other reason. Others may be visible and obvious enough that you either need to start getting on board and live with it, or start moving on. There are always initiatives that are bad risk-based decisions, overall, but sometimes you just gotta let it go.

As a parting thought, I think low-level techs and mid-managers make far more risk-based decisions that anyone likes to admit, because they automatically do the cost, risk, ROI dance pretty quickly in their heads up front; maybe not in a way that can satisfy accounting/CFO, but in a way that is pretty accurate if heavily scrutinized; and few get any recognition for it. If you’re a manager and you have an employee who exhibits this skill, please nurture them and keep them close.