Security Metrics: A Beginner’s Guide. Part 3
Table of Contents
Implementing process improvements
Another area to focus on for security metrics would be to sort of look around and figure out what’s broken and what needs fixing. A few areas that I’ve broken this down into are the process area and the technology area. And I actually think that in some cases process improvements are overlooked. I think that in security we have tendency to perform our best practices and our daily or weekly or quarterly activities and to sort of assume that, you know, we’ve always done them, we should always do them.
But what I’m proposing here is asking some questions about how we should make that better. You know, understanding for maybe an important process for your business – is that process defined? Has it been documented? Have the people who are involved in performing that process agreed to the steps, and does everyone agree to the same steps, and who should be performing them? Are those steps performed consistently? Are the SLAs that are outlined being adhered to? So these are some questions you can use for your own program to determine if there are processes that you might want to consider zeroing in on.
A few examples include things like a policy exceptions process, a vendor assessment process, a vulnerability management process, business continuity assessments – any of these regular activities that we perform trying to see if maybe one of them is broken and needs fixing.
Thinking technology-wise
Another area is technology. If you have, for example, a security technology deployed and you’ve got malware detection, how much coverage do you have for your security technology? Are you only performing malware detection technology scans at your headquarters? Is it international, if you have international offices? You know, what are those areas where there are gaps? Where do you have holes in your program that you want to address? And also, as far as non-security technology goes, what type of data is stored or transferred or processed in that technology? And is it adequately protected? Is that an area that’s maybe broken and needs some fixing?
And then an obvious one is any audit findings. So, if you’ve had third parties come in to perform audits and they’ve identified gaps in your program, developing metrics in that area is also a good place to start.
What’s basic? What’s expected? What’s new?
A few more questions to ask, in case you haven’t already come up with a bunch of security metrics ideas – and I hope that you have, although I recommend starting with one or two instead of starting with ten all at once – is what’s basic, you know, what some of those basic 101 functions that might not exist in your program today? What’s expected? So, if you were to talk to an executive at your company, and they’ve been reading The Wall Street Journal or watching ABC News or watching the daily show or something like that, and something having to do with security has come up, they might ask you about it. You could develop security metrics in order to either explain why their concern is not an issue or to explain how well you’re taking care of it. And finally, for those of us who have everything covered – what’s new? What are you newly developing that you might want to be able to tell a story about?
Practical advice
So now we’ll quickly go through some practical advice with regards to “I’ve been there, I’ve done that, and if I could go back and tell myself to do this differently – this is what I would tell myself.” First, I recommend that you fix processes before you automate them. It doesn’t make sense to automate a broken process.
The process that we have here is you start with a broken manual process, and then maybe some security vendor who is selling some sort of flow-tool comes to you and says: “Hey, I can make your life easier if you take that manual process and you automate it in my tool.” Sometimes that can seem very flashy and very glamorous and you want to do it right away, and so you think: “Alright, I’m going to automate this process, and then I’ll fix it.” So, I’m here to tell you that that’s not the right way to go. What I recommend instead is, if you have a broken manual process, I recommend that you fix it while it’s still manual. And then when you choose to take that automation step and maybe you’re hiring developers or consultants to help you build that automated process, you’ll already have a working system and you’ll save yourself some time and money.
Another area that I want to give some advice about is key messages for key audiences. So you can develop your security metrics program, but I would recommend that you keep in mind who you are telling these stories to; who is reading your security metrics report; whether they are reading it; whether they understand it. Here are a few questions that you can ask yourself before you go into a meeting with, for example, your CEO, your CFO, your chief technology officer. And what I have here is sort of a list of people that you might meet with, who are either sponsors or stakeholders in the information security program, and what different types of metrics they might be interested in.
And if you look at this – a chief financial officer, for example, would be very interested in understanding the justification for the investment in your security program: how much money are you spending this year, and how many people do you have on your team? They might be interested in looking at benchmark data from peer companies who are in the same industry or line of businesses you are in, and understanding what their security investment has. However, a chief financial officer is probably going to be less concerned with something like patch and vulnerability management, which might be a more appropriate conversation topic for a CTO, chief technology officer.
Lessons learned
And a few last lessons learned. One is to be very clear about defining your goals. To go back to the marathon example that we discussed, if I had just woken up one day and decided: “I’m going to run a long way at some point in time,” I might not have gotten to 26.2 miles in a couple of months. More than likely I would have sort of strayed from my initial goal and I might not have been as focused. And so I think part of being very efficient with security metrics is to clearly define your goals.
Report immediately
Another one that’s so important that I decided to put a star on it is to start reporting right away. So, what I recommend is that you begin to show your process owners and your stakeholders in whatever security metrics you choose to pursue – start showing them the data right away, even if it’s not perfect. What I found is that if you start showing people data and they see that it’s wrong, they’re more incentivized to fix it than if you’re sort of hiding away in the corner trying to fix it yourself. I think that if you show it upfront to a limited audience, then that can actually drive getting clean, accurate data for your program.
Have patience
And lastly, be patient and be purposeful. You are going to be talking to a lot of different people as you go through your program – lots of stakeholders, lots of people who are involved in these processes. And along the way you may encounter some bumps in the road, you may pick up rocks and find some messy stuff underneath there that you’re going to need to clean up. But my recommendation to you is to sort of take that – sounds very cheesy – as an opportunity. If you discover something that was wrong that didn’t realize before, that’s also your opportunity to fix it, and I think that’s another advantage of security metrics.
Resources on security metrics
I’m going to close today’s session with mentioning a few resources that you can check out. Betsy Nichols, Lynn Terwoerds and I have written “Security Metrics: A Beginner’s Guide” book with McGraw-Hill. It is available on Amazon.com, so if you are interested I recommend you check it out. I also recommend the Center for Internet Security and the Cloud Security Alliance as great organizations where you can talk to people who are interested in security metrics, figure out what the industry standards in this area are becoming. Securitymetrics.org is also a great resource, points to the agendas and the dates and times for the MetriCon conferences. So, I recommend that you check all these resources out. And with that, that’s concluding our talk for today. Thank you very much for your time!
Also Read:
Posted in: News
Leave a Comment (0) ↓