Hoff pointed over to James McGovern who posted a list of 10 mistakes the CIOs consistently make that weaken enterprise security. I want to highlight a couple things. Take your time reading McGovern’s post, since it does seem a little muddled and sometimes packs 2 distant points into one bullet item (see: ostrich principle). In fact, I don’t necessarily agree with a few of these, as worded.

Use process as a substitute for competence – I see this in IT as well as security, and sadly, it is a natural business reaction to any little thing that goes wrong that costs the company more than $5. Someone put a can in the paper recycle bin on accident! We must investigate, formulate a new process, and ensure that this never happens again! Right… I am fine with improvement, but business too often gets ridiculous about this, covering up incompetence with processes. Carry this on for a few years, and you have lots of fluff and frustration and few real answers. Some would call this a “bigness mentality.”

A trend I see in McGovern’s post covers the superficiality of many security endeavors. Rather than actually making a difference or tackling root problems, many points he brings up deal with avoiding the problems, or implementing shallow fixes which aren’t fixes at all. Some people purposely do these things, but I feel that most of these are a symptom of a lack of empowerment and competence. Business must empower security professionals, but they must also get and train up competent professionals. Taking either leg away can result in the things McGovern is pointing out.

And some things I think could be better worded.

Putting network engineers in charge of security – This is pretty general, as I’m sure there are plenty of network engineers would could excel when managing more security than just the network. An inference from what McGovern has said is security practioners need to know everything. I think what McGovern is really trying to say is to make sure the people most qualified to secure XYZ are the people who know the most about XYZ. Network engineers can secure the network; application developers can secure applications. But finding someone to do them all is like trying to find that silver bullet box that will provide everything. Ok, so there are some all-stars out there who can get their hands in it all, but waiting to find them is not a practical expectation. Here’s a question, though: Let’s say you have a kickass, security-aware network engineer. If you put him in charge of security, what risk are you still leaving open? If your application gets pwned, can he still detect it, monitor it, maybe even limit the exposure? Perhaps. Will he be able to fix the application? Most likely not, but he can certainly be a huge part of the security team.

Hoff throws a few nuggets in as well.

Security is top secret, we can’t talk about what we do – This is natural to us security guys. We don’t like to tell people about our measures because then people can avoid them. If we utilize hidden cameras but talk about them, then an insider can just hide their face at the appropriate times to thwart identification. Likewise, we tend to think like attackers, which means talking about our security measures is something done from the negative side: by talking about ways to get around our security measures. It’s like defining brightness as the absence of dark properties; the strength of our security by how easy someone could cover the security camera. But that’s not how we really should be when asked twice about security. We should make our jobs transparent as much as security allows. A lot of our need to “align with business” is simply being transparent with our controls.