Show the boss on Wednesday

Published: 2011-06-24
Last Updated: 2011-06-24 14:38:51 UTC
by Stephen Hall (Version: 1)
1 comment(s)

I wrote a diary a while back about process maturity called Countdown to Tuesday, using peoples patching processes as an example. I want to use this diary as a catalyst to understand how people tell their boss, or indeed their CxO level managers how well, or badly they are doing with security response.

Incident Response is a classic example of where your ability to respond needs to be measured, and your success or failure at doing the response presented to the powers that be.

Given that we have some key steps during our incident lifecycle, we can look at gathering data, performing analysis and then producing reports based on that data. The SANS incident response lifecycle is based on PICERL short for Preparation, Identification,. Containment, Eradication, Recovery and Lessons learned.

So when your incident response process is triggered, we have clearly entered the identification phase. But how do you keep track of when you enter containment, or Eradication, or indeed Recovery.

If you could measure between when an incident happened, and when it was identified you have a metric which shows how good your security monioring is. If you come up with the metric of how quickly you go from Identification to Containment you can then show how well your team is working. If you can work out your mean time to achieve something then you can identify and focus in on steps in your process where it went wrong, or didnt operate effectively. You can trend, and produce further statistics showing the cost of the incident if your business has an average cost for being unable to do business.

But we're getting ahead of ourselves here. How do you record this information? Drop me a note via the contact form, and i'll add it to my next diary on how you could do it using free tools, some scripts, and allow you to produce statistics you'll want to present.




1 comment(s)


There is another important metric for measuring monitoring: number of incidents initiated by notification from a third party. This ranges from external orgs notifying your org to ops teams notifying security teams.

Also, I really think that the containment metric relies so heavily upon the monitoring abilities of the org that it's really not necessary. That is, containment is usually held up by waiting on enough monitoring info to know what to contain. Air-gapping systems/re-imaging is a simple enough activity that it doesn't really warrant a metric. Metrics showing how long it takes to identify and locate a system are important, and CxO's need to know why spending money on asset tracking programs is important.

Diary Archives