Date
Maybe I’m being a bit pedantic but there seems to be a recursive loop somewhere here. The information security lifecycle tends to be quoted as:
countermeasures/protect -> detect -> respond

And of course everyone then breaks down the respond methodology down somewhere akin to:
prepare -> detect -> contain -> eradicate -> recover -> follow-up

That “d” word is pretty popular huh? I find it interesting that there’s not a lot of attention towards it. Especially in IR books. As a rule of thumb, they’ll spend the first chapter on the preparing stage, a section on explaining why IDS/detection is out of scope, a bit on containment, then 80% of the remaining book on eradication. (Which, incidentally, when did ‘detection’ become synonymous to just an IDS? Don’t you get calls when things ‘act wierd’?)
While it makes logical sense to have detect as a stage in the entire IR process, that doesn’t mean it doesn’t deserve at least a chapter on the subject. And don’t you dare make that subject about snort. Indeed, detection can be broken up into stages just like IR. Since I’ve yet to come across any in my own reading here is my own process:
discover -> prioritize -> investigate -> escalate -> follow-up

Once we get to ‘escalate’ the rest of the IR process takes over, notably containment. I guess everyone likes to talk about responding because there are results from it. Same goes to implementing an IDS system or setting up awareness to sysadmins and users. Has anyone taken the time to prioritizing/categorizing events? Finding valuable metrics? Reporting? Writing a detection book that’s absolutely not about technology but about managing the detection implementation? How about a magazine article? Am I simply ignorant to some de facto ‘standard’ on this?