electricfork.com: SIEMs versus Incident Response

SIEMs versus Incident Response

Posted Mar 23, 02:35 PM by ben

I attend several security conferences, webinars, and sales briefs a year. I am not an avid fan of SIEM technologies. To be clear: I am fairly unfamiliar with the various vendors, their value adds and differentiators. I know only from the various discussions I’ve had with them at said conferences, webinars, and sales briefs. I typically avoid these conversations, however sales folk are known to be persistent. I put this persistence to my advantage to see how the product may relate to my immediate needs. This is about the point I find the nearest soap box.
The value prop as I understand it: SIEMs let you quickly correlate and respond to an incident. Details be damned on how they achieve correlation; I want to know what happens once an incident is confirmed. Typically such a console event is treated as such; it’s an event. From there you may be able to fire off a Remedy ticket; or count how many events have been reviewed or escalated. Basic work flow stuff that may add a reduction in the amount of monitoring hours. Maybe.

NIST 800-61 states: prepare -> detect -> contain -> eradicate -> recover -> lessons learned. This is pretty basic stuff. SIEMs appear to solely focus on the second step. But their value prop is to allow you to more quickly respond (aka: contain, eradicate, recover) from an incident. This is the disconnect for me. I have more detections than I can shake a stick at and I don’t even own a SIEM. Funneling that through to yet another console that, in theory, gives a higher fidelity on the detection engine just isn’t a value. What would be a value? What is the series of questions I ask every SIEM vendor who corners me?

Once you have a true positive alert, then what?
Can I apply my incident schema to it? I have specific severities, categories, and other attributes that must be reported on. Don’t you dare give me generic classifications that mean near zero to my organization.
Can I report based on any response metrics? Response times? incident handlers? volume? reoccurring hosts or possibly related prior incidents?
Can it give me some hardcore incident analysis? Give me any several relevant data feeds; auto generated timeline capabilities would be very cool.
Can it track all efforts of containment, eradication and recovery? I need an authoritative post mortem for future reporting.
Can it track lessons learned and attach it per incident or collect aggregated lessons learned data?
Shit, can it do anything with aggregated data? If so, you’re highly advanced already!
Can it handle different escalation paths dependent on the scope or severity?

Zero of these features require outside platforms or partnerships; it’s simply adding more robust features than currently exist. I’ve only had brief conversations on this. Has anyone solved this? Is such an extension of SIEM an appropriate way to handle “response management”? Did I just invent a new term?

Response Management The ability to properly prepare and respond from an incident in a measurable, managed, efficient, and sustained fashion. Routine operations such as drills, escalation, post mortems, lessons learned, and aggregated mitigation summaries should be fed into tactical and strategic plans.

// :: brainstorming/ incident-handling