Pages

Friday, March 16, 2007

Thoughts on Incident Response/Management

Others have recently posted their thoughts on incidents and incident response (1, 2), and since this is an IR blog, of sorts, I thought I'd throw my hat into the ring, as well.

I don't really have a list of thoughts on IR, per se...its more a case of one thought from which all others spring. Basically, that is that organizations really need to start taking a proactive approach to Incident Response and Incident Management.

Incidents are going to happen. We can take that as a given. The days of joy-riding on the Information Superhighway are about over...there's simply too strong a profit motive these days. Why get a copy of BO2K onto a system and open and close the user's "cup holder", when you can quietly collect the contents of Protected Storage, capture keystrokes as the user logs into his online banking site, etc.

So what do you do? Well, first off, senior management needs to take this "security thing" seriously and treat it like a business process, not an ad hoc thing that you scramble to implement when you need it, and then drop it (cut the budget) when you don't. Walk around headquarters one day and look at the finance department...or marketing...or Ops. HR. All of these are business processes that you need to run a successful company. But how did you know that? Did someone tell you? Or did you suddenly see the need? Either way, people have been saying for years that you need to have security, and if you don't recognize the need simply by reading the paper everyday...

At some point, someone's going to throw up their hands, throw a huge budget at security, hire a bunch of (the wrong) people, and then proclaim security a failure. It doesn't work! Sound familiar? Is that how you would run your Finance Department? How about Payroll?

This security thing is really simple. Start by looking at your assets...what are you trying to protect? Is it sensitive personal data (a la CA SB1386)? Are we talking about critical systems, applications, or data...or some combination?

Once you've identified the assets, look at the threats. But keep in mind that this is no longer seige warfare, where you watch in wonder while barbarians pound at your gates...or your firewall. We're well into what the United States Marine Corps refers to as "manuever warfare". We're facing a battle with no defined front lines; ingress points include web browsers, rogue WAPs, etc. Have an assessment done, and if the result is "pay us a ton of money to fix it", then you may need to ask for your money back! In all infrastructures, there are things that can be done that don't cost money, but do have an inherent cost...things like cultural and political changes, changes in how you do things (ie, communal Admin/root accounts, etc.).

Train your people and hold them accountable. You're not going to hire an IR staff and keep them in a room with "break glass in case of emergency" written on the door. However, a great deal can be accomplished by training your current staff in how to manage and respond to incidents. Designate some personnel as incident responders, with a suitable manager, and get them some training. Even if they are familiar with handling some incidents, the best training is functional and hands-on. Have regular refresher training in the form of incident response exercises...maybe even coordinate that with an unannounced pen test.

In fact, here's a great way to go about the whole thing. Get your folks the training they need to be tier 1 incident responders. This means that there are come tasks that they'll be able to handle, like EMTs. Then, seek out a professional response firm, and keep them on retainer so that they're available should you call, and then can be on-scene and paid on a per-incident basis. This kind of approach has is a win-win, particularly if the professional responders are the ones who are training and working with your team...they get to know and trust each other, and there's a great deal of knowledge transfer that goes on.

Where this kind of thing breaks down is when the responders are held accountable for something, and senior management isn't. Security (in general) and incident response are business processes, folks, and need to be thought of and treated that way.

BTW, one of the links in the first line of this post is to a fairly new blog: ForensicIR. Welcome aboard!

No comments:

Post a Comment