Security Benchmarking, Going Beyond Metrics: Communications Strategies
The simple fact is that most folks senior security folks came from the technical side of the house. They started as competent (if not studly) sysadmins or security administrators, drew the short straw, and ended up with management responsibility. But very few of these folks ever studied management, gone through management training, or done anything but learned on the job. This creates a situation where senior security folks spend a lot of time doing stuff, but not enough time talking about it. The huge disconnect is inadequate communication of both success and failure up and down the management stack to key security stakeholders. In fact, the Pragmatic CSO methodology originated largely to help technical folks figure out how to deal with their management responsibilities. The inability to communicate to key stakeholders will absolutely kill a benchmarking program because benchmarking entails ongoing incremental effort to gather metrics, as well as to compare against benchmarks and perform analysis. The benchmark must provide additional value, which must be communicated in order to make the effort worthwhile. As we all know, nothing really happens by itself. You need to build a systematic communications/outreach effort to leverage the benchmark data, specifically targeting a number of constituencies important to the success of any security practitioner. Let’s dig into how that’s done, because it’s a critical success factor for any benchmarking initiative. Understanding your audience The first rule of communications is to do it consistently and repetitively by telling them what you are going to say, saying it, and then telling them what you just said. It sounds silly, but given today’s over-saturated environment where the typical C-level exec has the attention span of a 2-year-old, you don’t have a choice. Effective communications requires more than just talking a lot – you need to tailor your message to the audience. This is something security folks have always stunk at. If you’ve ever uttered the words “AV coverage” or “firewall rules” in a management meeting you know what I mean. Senior management If there is one thing you should appreciate about senior management, it’s that they are fairly predicable. Their interests involve things that directly impact revenues/expenses. Period. They don’t want to know the details of how you do something unless it’s off the rails. They want to know the bottom line and whether/how it will impact their ability to get paid their full bonus at the end of the year. So we focus on incident data and budget efficiency. They want to know whether incidents have impacted availability and thus cost them money. They need to know about disclosures, with an eye towards brand damage. And they need to know how you do relative to peers – if only make themselves feel better that their competitors probably won’t be getting those bonuses this year either. Getting time with senior folks is challenging. So you’ll be doing well if you can get quarterly face time to go through the metrics/results/benchmarks. At a minimum you need to make your case annually ahead of budgeting, but that is not really frequent enough to get sufficient attention to successfully execute on your program. Finally, how can benchmark data help you with these folks? You can use the fact that in terms of overhead functions most senior managers are lemmings – if everybody else is doing it (whatever it is), they will be likely to follow suit. It’s an ugly job, but someone has to do it. CIO Odds are you report in through the technology stack, which means you’ll spend some time with the CIO. This is a good thing, but keep in mind that the CIO’s primary goal is to look good to senior management. We all know that security issues can make him/her look very bad. So we can focus on what interests senior management: incidents and budget efficiency. But with the CIO you should add high-level operational trending data, which highlights issues and/or shows progress on efficiency. Given the spend on security, the CIO needs to pay attention to and increase efficiency. How often should you be communicating with the CIO? Hopefully monthly, if not more often. We know it’s hard to book time around golf outings with the big systems, storage, and networking vendors. But you still need access and face time to make sure there is a clear understanding of where the security program is and what needs to be addressed. Benchmark data helps substantiate the need for specific projects/investments, driven either by peer group adoption or efficiency/effectiveness gaps. Again, your opinion about what’s important and needed is interesting, but not necessarily relevant. Having data to substantiate your arguments makes the discussion much easier. IT Ops teams Brown stuff tends to flow downhill, so your pals in IT ops tend to focus on looking good to the CIO. You need their support to execute on any kind of security program, because ops can make it protection difficult, and that would be a problem for you and the CIO. But ops isn’t interested in the same things as senior managers. You need to focus those discussions on areas where changes or activities depend on operational resources. As with all things operational, it’s about increasing efficiency and reducing error, so we want data which highlighting issues, gaps, and/or areas to improve. Ops folks may not appreciate being told they may need to do things differently. This is another place where benchmark data can be your ace in the hole. By showing relative performance and ability to execute on operational processes, the data substantiates your arguments and helps avoid you having to go back to the CIO to complain “Ops sucks and makes our life hard!” and hoping the CIO will make them play nice. Security team As valuable as benchmark data is for telling a better story to stakeholders and key influencers of the security program, the benchmark data is also a key management tool for your own security team. We all want our groups to work better and improve continuously – as we
