Tuesday, December 15, 2009

Incident Prep, part deux

I've mentioned incident preparation before, and recently blogged on best practices, which was sort of a result of one of the comments to my first Incident Prep blog post. Specifically, the comment stated:

After having read the title I was really looking forward to this post, hoping I could compare our "CSIRP" against one you suggest - or at least making sure we've covered all the "must dos" and avoided the common traps...

So, this is that follow-up post...or one of them...that Anonymous asked about.

First, a couple of things...I can't suggest an online CSIRP example, per se, because there aren't many posted out there. However, I know absolutely NOTHING about Anonymous's infrastructure, so how can I recommend anything? Really? Ask me to recommend a good lunch, I know a wonderful carnivore-heaven/BBQ place nearby...but you may get there and say, "hey, I'm vegetarian!" Dude...you never said anything.

To address the other questions...again, knowing NOTHING about Anonymous's infrastructure or organization...the "must dos" are to have a CSIRP, and the common traps are to not have a CSIRP.

If you have a CSIRP and need a gap analysis, or if you need a CSIRP, here are a couple of things I can suggest to get you started...but again, these are all really dependent upon your organization, it's internal structure, as well as geographic, political and cultural considerations:

1. Is your organization subject to any legislative or regulatory oversight? Think HIPAA, PCI, etc. If so, start there. The PCI DSS v1.2, paragraph 12.9, has some information that specifies what a CSIRP should encompass, and is a good place to start...actually, for just about anyone, not just organizations subject to PCI. But the standard caveat applies...if it's associated with the PCI DSS, it's only a start.

2. CERT.ORG has an entire section on CSIRT Development.

3. Look at what you already have in place. Do you have a disaster recovery/business continuity plan? How about response plans for medical emergencies or in the event of workplace violence?

4. Keep in mind that a CSIRP is a communications plan, outlining who does what and when, in the event of an incident. Consider this...during CPR training, trainees are told to point to someone and say, "Call 911!" If there's a crowd gathered 'round and you just say, "would someone call 911?", what're the chances someone will do so? It's a good bet that everyone in the crowd will be thinking that someone else will do it...so you need to designate response staff. Think Star Trek, only without the dudes in red shirts.

Finally, and perhaps most importantly, if you're considering hiring outside consultants to assist with CSIRP development, you have to understand that this is NOT a drive-by service. What this means is that you cannot expect to hire someone to come in and drop off a CSIRP for you...at least, not without spending 6-9 months as a member of your staff. Why is that, you ask? Consider what I've said in previous posts...what is considered best practice for one organization may be completely undoable to another. It takes work, but ultimately your organization will have to take ownership of the CSIRP...after all, it's yours; your data, your infrastructure, your CSIRP.

No comments: