I know what you're thinking..."What?!?"

As a consultant, many times I will be asked, "what are 'best practices'?" or "can you give us 'best practices'?" Well, I've often thought...what ARE 'best practices'? When I look around at best practices for various things...CSIRPs, IR, etc....I find that many times, the publicly available best practices are based on a particular technology or a particular corporate culture, and will simply not be best or even work at all for a particular customer environment.

Here's an example that I look at, because I have seen it so many times...you're a corporate security person, tasked with some level of incident response. You work for the CISO, and the corporate IT department (which includes the SOC) is nowhere in your management chain. The data center is either in another part of the building, or in another building nearby. During IR activities, you may need to obtain data (could be anything in the IR triad...network captures, data from devices, or host-based data, which includes memory and images) from systems managed by the SOC.

What are best practices for this type of situation? Truth be told, you can come up with any best practice, and I can come up with at least one real-world example or reason, and possibly more, why it simply won't work.

So, one best practice might be to immediately go to the data center, take the affected system off-line, and acquire an image of the hard drive via a write-blocker. As the IR guy, do you have access to the data center? In many cases I worked, this would be a big "no". Can you take the affected system off-line? Again...no. The system may be critical, may be RAID, or may be boot-from-SAN. Do you have money to purchase write-blockers? Again...in many cases, no.

The next approach might be to cultivate relationships with the SOC staff and get them to help you. This works sometimes, but it's usually best effort, not best practice. Does the SOC staff have the ability or training to assist you? Sure, plugging in an external HDD and running FTK Imager to obtain a live acquisition might sound easy, but try doing it when it's not part of your job, you aren't trained for it, and your manager/boss is screaming at the team to get stuff done that's already overdue.

Okay, what about pre-deploying a solution? That might work, but remember, you don't own the systems in the data center, so installing some sort of agent, not to monitor, but to allow you to collect data might not be something that you can do...at least not easily. And we all know what happens when the tasks pile up...anything related to security gets popped off the stack.

I once supported an organization in which the CIRT had NO access to anything in the infrastructure...they didn't even have admin access to their own systems. IF something was flagged and IF the CIRT received notification of it, then they had to ask the NOC staff to collect information from the affected system(s). This amounted to running a single tool against the systems...not a batch file of tools, just one single tool...and more often than not the data wasn't returned in anything close to what you might consider timely.

Sometimes, best practices don't turn out to be usable practices at all. When considering best practices, we need to look beyond just the technology and take geographical, political, and cultural considerations into play.

I know it's been a while since I've posted, but work has been really keeping me busy...that's an excuse that we all use, but that's my story and I'm stickin' with it!

So, I've been talking to a number of different folks recently, having discussions during my travels to and fro about incident response and computer forensics. Many times, the issue of "best practices" has come up and that got me thinking...with no specific standards body governing computer forensics or incident response, who decides what "best practices" are? Is it FIRST? After all, they have "IR" in their name, and it does stand for "incident response". Is it the ACPO Guidelines that specify "best practices"?

Well, the easy answer (for me, anyway) is that "it depends". Funny, haha, I know. But in a sense, it does. "Best practices" depend a great deal on the political and cultural makeup of your organization; I've seen places where the incident response team has NO access to the systems, and must request data and information from the network operations staff, which has their own daily tasks and requirements.

But all that aside, we can focus on the technical details of responding to Windows systems. When we say "best practices", we can specify the information we need to get in order to properly assess the situation/incident, how to go about getting it (retrieve it locally, remotely, via live acquisition, via post-mortem exam, etc.), and in what order to retrieve that data (the ACPO Guidelines specify dumping the contents of physical memory last, rather than first...), etc.

For example, we know that during live response, anything we do is going to leave an artifact. So, why not specify what data you're going to collect and the method by which you're going to collect that data? Then determine the artifacts that are left through testing, and document your procedure and artifacts (hint: things like batch files and scripts can constitute "documentation", particularly when burned to CD), and implement that procedure via some means (ie, batch file, script, etc.).

One of the questions that invariably comes up during discussions of live response and "best practices" is, can data collected via live response be used as evidence in court? I would suggest that the answer is, "why not?" After all, an assault victim can be treated by EMTs, operated on by a surgeon, and cared for in a hospital, and the police can still collect evidence and locate and prosecute the perpetrator, right? It's all about documentation, folks.