12:20 PM -- You just have to love Slashdot. Whatever you may think of the site itself, it is a great discussion-starter, attracting everyone from jokesters to critics to the most passionate on any subject. When something you've written is posted to Slashdot, you'd better get ready to answer a lot of message board postings.
Yesterday was no exception, when a kind reader managed to Slashdot my short primer on security incident response. (See What to Do When Your Security's Breached.) That little posting has already resulted in more than 150 comments from readers, most of them security professionals. These comments were all over the map, and I'm not sure I'll ever have time to respond to them individually -- but collectively, they paint a pretty good picture of the "conventional wisdom" on incident response.
What's interesting about that wisdom is that there really isn't anything conventional about it. Even among security professionals, there's still a lot of disagreement on what to do in the event of a security breach. While many of the commenters on the story seemed absolutely certain that their responses were correct, a number of them were diametrically opposed to each other.
One group of respondents criticized the story for recommending incident response steps that were too obvious. My favorite was the guy who compared the story to advising a burned person to put ice on his wound -- and was subsequently flamed by half a dozen first-aid-savvy readers who explained that one should never put ice on a burn.
It seems to me that security incident response is a lot like that little exchange among Slashdot readers. When a breach occurs, people think they know exactly what to do (it's common sense, right?) and are subsequently faced with a raft of reasons why "common sense" might be a poor choice.
For example, several Slashdot readers objected to the notion that an IT organization might consult an incident response team before deciding how to handle a breach. "Keep the idiot suits out of it!" scowled one reader. But several readers subsequently posted responses that described positive experiences with incident response teams and said they would never do it any other way.
Similarly, there were a number of readers who advised their peers to pull the plug first on all affected systems and ask questions later. However, their postings were quickly followed by replies from other readers who said they lost critical forensic data -- and the possibility of capturing the attacker -- by pulling the plug too quickly.
And in many cases, reader responses exposed a cold, hard truth: No matter how hard you plan or rehearse, you might not be ready for the breach that finally hits your company. There are so many variables that it's impossible to prepare for every scenario -- but many readers who had suffered through an incident said they were happy they had at least tried.
The fact is that there aren't any pre-ordained processes that will work flawlessly in the case of any security incident. But there are some basic steps that companies can take to get themselves ready, and those are the steps that are outlined by experts in the story. They might be obvious or imperfect, but they're a good starting point. And it looks like there are some folks out there who could use them.
Now, if you'll excuse me, I'd better go. I've got some Slashdot replies to make.
Tim Wilson, Site Editor, Dark Reading