The State of IR

I blogged recently about an InformationWeek article in which Kevin Mandia was quoted; part of that article and one of his quotes is:

One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM...

Like others in the IR arena, I'm sure Kevin and his guys are seeing this more and more...the IR activities performed by the on-site IT staff is often very knee-jerk, and little thought is given ahead of time to the questions that need to be answered when you've been compromised or p0wned. Whether the IT folks are doing wide-spread scanning (and filling log files), local scanning at the console (with destructive A/V scans), or simply killing processes and deleting files, these activities are making it difficult for follow-on IR/CF work to be effective.

Not being one to simply say, "hey, you're wrong!", and not offer some alternative or solution, here's my take on what needs to be done...

First, and most importantly, senior management needs to take security (in general, and IR/CF specifically) more seriously...and not just on paper. Back in the day when I was doing mostly vulnerability assessments and pen tests, some organizations actually had IR policies in place and wanted to test them. So they'd contact my employer and have a pen test scheduled...without telling the IT staff. That way, you could see how they'd react.

Right now, senior management (CEO, Board of Directors, shareholders, etc.) are primarily focused on uptime and accessibility...after all, without those, where does revenue come from? Now, let's assume that when planning for these, they brought security folks in at the ground floor so that not only was everything accessible and available, but more secure, as well? Okay, that's not reality...but guess what? Security doesn't have to break stuff. No, really. Honest. Measures can be put in place to prevent and detect issues (to include security incidents) without breaking your current system setup.

Also, senior management should invest in their IT staff, through training, job progression, etc. I've seen some really bright, conscientious folks leave the IT arena because they were tired of being the back-office behind-the-scenes folks who got none of the credit and all of the blame. Along those lines, if you send some of your folks off to training, get them certified, and don't provide any avenue for advancement, they'll find someone who will. That's kind of a wasted investment, isn't it? I saw this in the early '90s at a trucking company that first trained some of the IT staff in SmallTalk, and as soon as the project they were on was completed, they all migrated to the local bank, advancing their positions and salaries. When I was involved in the Java training in the mid-90s, the same exact thing happened.

Second, to paraphrase Agent Mulder, "the tools are out there." The licenses for many of the available freeware tools state that you can run the tools as much as you want, as long as you own or administer the systems (be sure to check, either way). So, grab a CD, put the tools and a simple batch file on it, and include one argument...the directory to send the output of the tools to. This can be a thumb drive, USB-connected external HDD, or mapped drive. When something happens, fire up the batch file, and capture that valuable volatile data.

Don't know what tools to use, or where to get them? Check out my first book, or look for my next one coming this spring. Or watch this blog.

Don't know what the data you've collected is telling you? Check out my first book, or look for my next one coming this spring. Or watch this blog.

The bad guys are getting more and more sophisticated, so the level of training and knowledge of the good guys needs to narrow the gap.