Incident Response Pre Planning Return On Investment

Published: 2009-09-02. Last Updated: 2009-09-02 19:39:58 UTC
by Chris Carboni (Version: 1)
6 comment(s)

I had an interesting conversation the other day with a good friend regarding the merits of having specific incident response plans for common types of incidents.  My argument was (is) that by having plans for specific types of incidents thought out in advance and pre-planned (mail server DoS for example) you can recover from the incident much faster and lessen the impact of the incident.  His counter argument was that writing all those plans and getting them approved is too much work to justify the small amount of time he says would be saved in recovery.  After all, you know what you're going to do, right?

What do you think?  Is it a small amount of time?  Does it depend on the size of the organization?  The value of the asset?  What criteria do you use to determine what specific scenarios you have written plans for?

 

Christopher Carboni - Handler On Duty

Keywords:
6 comment(s)

Comments

First of all I would avoid using the dreaded term "ROI" for anything related to security. Security is insurance against loss, not a way to gain more revenue.

So the question really becomes, "what will protect against the most loss, writing out response plans for specific incidents, or just responding to the incident and using the time you would be writing out those plans to do other security activities?"

My guess is that for those companies with a small IT security staff the answer would be to "just respond".

However, if you have a system where the setup is large and complicated, it may well be worth it to have the incident response plan to quickly identify and respond to the incident.

It is a case where each system needs to have an analysis of the merits of having a specific, written response plan.

Nathan Christiansen

Sep 2nd 2009
1 decade ago

I think partly it depends on how specific the "you" in "you already know what you're going to do" is. If it's just you, personally, who knows what to do, what happens if you're unreachable when the DoS happens? I've always thought that business continuity should not depend on any single person not getting hit by a bus. ;)

David Brodbeck

Sep 3rd 2009
1 decade ago

If you mean, by respond, what actions you plan to take to give your company a way to be working again. Then this should be in some sort of plan. For example, getting an offsite data center up with a recent set of data, etc.. However, the actual steps you plan on taking to foil some massive DDOS on your DNS infrastructure, I think the possible number of risks are too great. Also, going down one path may lead you down another, maybe in unanticipated ways. I do not think you want to be bound by some document that may not have anticipated this vector properly. I think you may also run the risk of running a checklist to deal with a situation that calls for some analysis.

Jim Kelly

Sep 3rd 2009
1 decade ago

Interesting debate.

There is at least one example of a standard (the PCI-DSS requirements 12.9.1 and 12.9.5) that requires specific incident pre-planning.

Certainly, each organisation must assess the value of burning scarce resources in doing such pre-planning.

One example where it proved worthwhile is back in the early days of phishing - I was working for an organisation highly likely to be phished - so the security team sat down together and formulated a plan. We figured out what we could do, how we could do it and who needed to be involved (marketing, fraud, the e-commerce team etc). Buy-in to the plan was obtained by all (after a few tweaks of course) and when the first phishing attack hit it was handled swiftly and without fuss or major disruption. No quarrels, no fuss, just dealt with.

Don' think of it as just incident response either - it is team-building (because you are brainstorming ideas with the team), it serves as a form of internal training for younger security team members, builds communication between teams within the organisation and gets them thinking about security. And of course, not forgetting the ability to respond to an incident quickly. and to minimise the impact (isn't that why fire-fighters practice a range of firefighting and rescue techniques? Regularly?)

fosm

Sep 3rd 2009
1 decade ago

Having a response that includes a non-computer-oriented plan is the most important thing here.

You have to assume that there will come a time when getting the computers up and running will not happen immediately. Those include a viral infection on the network that would make it impossible and other conditions like floods, severed fibers, etc.

Several Hospitals in Great Britain have had these situations occur recently and know exactly what must be done to continue work. It is also required by most US State Governments to have a plan for all systems down that works. It usually includes a lot of legwork and paper trails.

This mindset needs to be implemented in any organization, even if their primary focus is Internet-based applications. Sometimes the keyboard needs to be replaced :-)

so, in conclusion, yes you do need a recovery plan, but not the type you are thinking about!

-Al

Al Thiel or YourDataCenter.com

Sep 3rd 2009
1 decade ago

In any organization, you would like for things to be repeatable and duplicatable. A written plan ensures that regardless of who is available (including the "new guy") can handle the situation. This ensures that any policies or specific procedures are also follows, including those that may be required to collect information for any potential investigation.

BCP/DR must be planned to be effective. Plan your work and work your plan.

Mike

Sep 4th 2009
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives