SIEMs versus Incident Response

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.

Beyond operational security

An observation. The detection and response to incidents is regarded as completely operational. I generally introduce myself as "leading a security ops team" as that conveys the right responsibilities to anyone I may be talking to. What are those operations?

• analyze alerts or escalations
  
• create documentation trails (chain of custody, incident tracking, etc)
  
• contain, eradicate, recover from any incidents
  
• repeat
  

Occasionally we have time to lift our head up and learn from an incident and close a hole large enough that it'll eliminate an entire class of threat or method of attack. This is always the goal as nobody wants to play whackamole; but it's not easy. Other responsibilities or projects always fill the voids quicker than they should. How do you meaningfully move past operations and into a tactical mindset? Some thoughts on this:

• parse through your incident tracking looking for trends (repeat offenders, categorization). Don't use this as material to feed your bosses but feed it back into the incident process and learn from it.
  
• Don't just look at alert data. This is NSM all over again. Or is it? NSM starts at the alert and moves well past that into session and full capture data. What if we complement NSM by also starting at full capture data and looking for items that should have alerted (true negatives)? I suspect NSM advocates would say this falls under NSM but it doesn't truely seem to be practiced.
  
• Part of the incident lifecycle is the lessons learned branch. In my experience this isn't done on minor severities (eg, the daily one-off infection). How do we lower the transaction costs of such lessons learned to be able to quickly capture these on an operational level?
  
• Drills are important, you must make time for them.
  

That's tactical, what about strategic?

We (as in any security response team) need to make it easier for outside teams to respond with us. This means automating toolsets that we can't run remotely and they don't have to think about. and it needs to be quick. If we rely on a support center then we must provide them tools to quickly do what we need them to do; not expect them to figure it out.
An outline of capability blind spots needs to be done. Any opportunity to fill such a blind spot should be evident and taken advantage of. Too often these opportunities are missed as action is not done quickly enough.
Our capability is valuable; apply it to other needs when applicable to show that value. Think of log reviews, bandwidth troubleshooting, data preservation or identification. This should stay tactical or strategic and not become an operational duty.
create the proper barriers to limit other responsibilities from eating away at NSM and response. The balance will always tip in favor of tangible results over operational monitoring and response.

shmoocon 2009 recap

Apparently people actually read my 2008 recap/rant. If you condone such activities then they will continue on.
I sat in fewer talks this year but walked the floor a bit more and met and hung out with folks instead. As always the event ran very smoothly. All the content was fresh and didn't include any rehashed topics from previous years; based on the number of talks this is a feat. Random thoughts:

• The Building Botnets talk was interesting; their SNMP smurf attack was clever and refreshing.
  
• I fell asleep during Beale's Middler talk. This was due to an overdose of sushi and isn't a reflection of his talk. Middler appears very hip and is a clever attack based on weaknesses that wifi's shared medium has introduced.
  
• Matt Blaze's keynote was okay though I was hoping for more. Certainly the talk was interesting and engaging, I simply hold keynotes to a higher standard. Especially keynotes which prevent me from having dinner until 9 o'clock in the evening.
  
• A group of us chatted up one of the colonels in dress uniform in Murphy's at 2AM. The group was fun and interesting; way more than the Amway gathering a few years back. And they can hold their liquor too.
  
• The poor kid who passed out near the garbage on the sidewalk as the party was ending was kind of sad. Luckily friends loaded him into a cab. It was unfortunate his head ended up on the cabbies lap, but i'm sure it'll make a great story if anyone tells him. I saw two others lose their stomachs. I was under the impression that geeks had high tolerances; Saturday night put this into question.
  

Sorry for the lack of links, visit shmoocon's site for more info. See everyone in 2010.

Red Team Journal

I have been accepted as a contributing editor for Red Team Journal. rtj focuses on the practice of red teaming, and I will be contributing my knowledge from an information security perspective.

I have been reading rtj for the last 5 months and have enjoyed their articles. I am looking forward to contributing as much as I can.

In the infosec realm red teaming is generally thought of as a pentesting role. But infosec as a field can not be narrowed down to a science and must have critical and imaginative thought behind it. As an ops guy I had to rewire my brain to think of possibilities, implications, and reactions while maintaining precision and speed. I was applying Boyd's OODA loop without knowing it existed. I discovered the OODA Loop in February of 2008; and it set me on a series of mental exercises that redirected my energy from a purely NSM mindset into something of a holistic response mindset that yet has a name. Merlin Mann's design pattern talk gives me hope that I can remove tools and products from the equation and focus on the inherent practice of monitoring and response. Finally, I hope my mindset as a digital native can raise questions as to older generational values versus data mobility and how it changes ideals such as privacy (it's lack of), open sharing, and information or news cycles. I hope working with the rtj will go further down these rabbit holes, and I can contribute interesting or new ideas to the community.
More to come.