Friday, December 04, 2009

Best Practices: What is 'best'?

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.

1 comment:

Roland said...

Ha,
great post! I've run into exactly the same situation on multiple occasians. One other common situation (for me, at last) is where all IT is outsourced, and no-one knows who owns the data you need.

"Logfiles? Well, youll have to ask the helpdesk." No wait, they get their information from firm X, who cannot give you any info because you're not authorised. Oh, and we don't know how you can get authorization, because there's no protocol for that.

By the time you finally get to the data, all the interesting bits (pun!) are already gone..