by Paul Proctor | February 24, 2013 | Comments Off
I have the best job in the world. I get to speak to the best and the brightest IT risk and security officers every day to learn what works and what doesn’t. … I also get to speak to the other end of the spectrum. Here are a few doozies for the record books.
A textbook dashboard with no relevance.
I help our clients build effective dashboards with risk and security metrics tied to corporate performance goals. However, there’s always a starting point (I review their current dashboard) and this is a common failure. Many of them are works of art loaded with eye candy graphics and very important sounding metrics like “Attack surface increase quarter by quarter”. These are what I refer to as text-book perfect dashboards because they appear constructed by very highly paid consultants following a formula.
This is where it comes off the rails. I ask the author to tell me what decisions any of these metrics influence for the intended audience (IT execs, BoD, etc.). This is usually followed by a long silence and “… I see what you mean.”
You can avoid this failure by understanding what decisions your intended audience makes every day and relating their decisions to dependencies on IT and operational risks.
Reporting raw vulnerability numbers
This is my all-time favorite CISO fail. The CISO chose to report raw vulnerability numbers to their board of directors. They did this in the name of transparency and, in that spirit, chose not to turn off any of the scan categories. You can’t make this stuff up.
This small company discovered they had more than 70,000 vulnerabilities and the board’s reaction was to say “fix all of those and make it zero”. Because they had not tuned the scan it was showing them vulnerabilities for applications they did not even have! Net result, it was actually impossible to make the number zero… and they had to explain this their board. I swear, you can’t make this stuff up.
Please avoid this failure by abstracting all the technology out of your reports to the board. They don’t understand it and when you try to explain it, the best possible outcome is that they fall asleep. The worst possible outcome is they will misinterpret it and make your life a nightmare.
Attacking the infrastructure without warning to prove “it is weak”
This is sadly more common than it should be. Gung ho security officers who have bad working relationships with their counterparts in IT operations like to “show them a thing or two” when push comes to shove. In some extreme cases of this I’ve heard of critical business services going down during business hours.
You can avoid this by maintaining a good working relationship with IT operations and never, never do anything that puts business operations at risk. The fact that I’m even writing this just makes me sad…
A CEO who wants a “forceful” CISO to aggressively control people as a way of improving security
This last one isn’t a CISO failure, it’s a CEO failure. A large multi-national corporation had woken up to the fact that security was important. The trigger of course was a breach notification and a fine. When interviewing CISO candidates he explicitly said that he wanted someone to “kick butt and take names.” The emphasis was on the fact that security was going to be a mandate pressed down from the top.
For insight into the failure here, read numbers 2 and 3 on this list. Management by fiat does not work. Support from the top should not mean the ability to walk around and tell people what they can and can’t do. We know this now after 10 years of “Dr. No” and the negative impacts on security.
To avoid this failure embrace the modern risk-based approach to security that balances the need to protect the organization with the needs to run the business.
Do you have any failures to share? What have you learned?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.