electricfork.com: Beyond operational security

Beyond operational security

Posted Mar 16, 01:46 PM by ben

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.

// :: brainstorming/

Comment

Commenting is closed for this article.

This work by http://electricfork.com is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

about

charmsec

I lead an information security ops and response team. This site is a collection of interesting notes and brainstorms on the protecting from, detecting of, and responding to badness. You can read more about me or my site here.

You can subscribe to my blog via rss , or if you're looking for older items check out my archive of previous posts.

I organize a small infosec meetup in baltimore called charmsec. If you are looking for charmsec details you probably want to go here.

RSS