Incident Response

Canadian expat, published info sec author and Bermudan beachcomber, Andrew Hay recently posted a question over at Michael Santarcangelo's Security Catalyst Community Forums asking about a framework for incident response for a bank of several hundred employees.

I gave my answer largely based on Ed Skoudis' outstanding SANS Security 504: Hacker Techniques & Incident Handling course.

I won't rehash that answer here, but I will provide some additional insights. I mentioned in my post that I used to work in info sec on a large, unprotected higher ed network. Enterprise uniformity was non-existent. The academic freedom that makes universities vibrant and interesting makes life hell for info sec personnel. If managing developers is herding cats, running an info sec program in higher ed is like being the poop-scooping clown at the back of the cat herder's parade. Hm, need a better metaphor.

Given the nature of our environment and the constraints placed on info sec, incident response was a regular activity. During my time working in academia, I responded to hundreds of incidents, thank you Blaster, Sasser, Zotob and the countless number of postcard.gif.exes.

If you're creating incident response policies and procedures, you want to be careful that they are not overly specific. Since incidents vary widely, you don't want to be constrained by a short-sighted plan that didn't account for this specific incident. If your plan states you won't pull the plug on a system without approval of the system's owner and an incident is occurring where plug pulling is needed, but the owner is unreachable, you're damned if you do and damned if you don't. Your policies and procedures need the right amount of flexibility.

If you're an info sec manager, you'll want to run interference for your incident response team. Send your IR folks out in pairs or larger teams. While one person works the incident at the keyboard, another can talk to the system's owner or the manager of the affected department. The handler at the keyboard is going to need to concentrate and that can be difficult with people walking all over you.

On a technical note, if you're going to image the system(s) in question, by all means make an image of the RAM for later analysis. There's more and more evidence of malware that remains memory resident only and if you don't grab the contents of RAM, you may not find all the evidence you need from a hard drive image only.

There's much more to be said about IR. It's a big and constantly changing field requiring practitioners to stay current.