Wednesday, March 07, 2007

An Attempt at Live Response vs Traditional Forensics

There seems to be a great deal of confusion about live forensics versus traditional computer or dead forensics. I'm gonna try to explain it (at least as far as my opinion of it is) by comparing it to Police response to a murder.

Usually the first response to a murder is a patrol car. But even before they arrive, there are usually civilians on the scene disturbing, covering up or otherwise changing evidence either by just their presence or maybe even intentionally if they are the perp. Now in the CF world these "civilians" are the staff IT and others at our clients office. We all know that sometimes the worst enemies to our potential evidence is the employees at the scene.

The patrol car guys are like the IT guys at the client who have the responsibility of being first response to an incident. Their job should be to contain the scene, preserve the integrity of evidence and to identify people on the scene when they arrive. For the IT staff that means following a prepared script usually set up for incidents. But the emphasis is on preservation and containment.

The along come the detectives, whose main job everyone defines as investigative. But in a murder situation even the detectives start out in a preservation/containment mode. Their primary objective is to get all the evidence possible, identify all subjects on the scene, get statements, identify suspects etc. Their "investigation" starts later, once they have the necessary input or evidence, to investigate. This is us, the Forensic Analyst. Typically we think of our job as coming in, getting a dead image and heading back to the lab to "investigate".

BUT, and it's a big but, both the patrol guys and the detectives aren't going to watch a guy running off, or have a witness point out a suspect and not act to take him into custody or otherwise contain him. They aren't going to leave a loaded gun on the scene for someone to pick up. Sometimes the proper response to a murder requires making evidence acquisition secondary to capture of the suspect. Or if the victim isn't dead when they arrive they will trounce all over evidence to save his life. This is live forensics in action.

The police rely on training and "gut response" and experience to know when to go outside normal procedure in a situation. We must do the same. If the "crime" we are responding to involves running processes, memory evidence, network connections other vaporous information we must go outside "traditional" forensics and get it. Sure, it may get questioned in court, but if we have done our job and have documented our actions and their changes, we can get it accepted as valid evidence. Remember, the standard is the best possible evidence, not the ONLY evidence.

I know this doesn't do justice to the live forensics argument, but we gotta have a starting place and we have to convince our clients this is a viable and profitable forensic process.

Tuesday, March 06, 2007

Lessons from USAir??

Since I am in Charlotte NC, I am right smack in the middle of the USAir ticket kiosk fiasco. This morning I was being interviewed on the local News Talk radio, 1110 WBT, on the Charlotte's Morning News, about the Daylight Savings Time issue, when I was asked about US Air and what I would have done differently. My answer was, test the migration well before deploying it in production.

That being said, it made me start thinking about just how complex software is, how easy it is to break and just how easy it would be for someone to intentionally do damage that way. Now, this is fiction, but why couldn't a disgruntled programmer or admin at US Air have purposely sabotaged the code or the kiosk OS to cause this massive headache for the airline? The answer is obviously they could have. Now as a forensic analyst I have all kinds of tools and methods to go back and discover and prove such actions after the fact, but what is there out there that could prevent such a problem or even worse ones. After all this was just the reservation/ticketing system, not air traffic control or flight scheduling.

I am sure the IT folks from USAir are working around the clock and as hard and diligently as they can to solve this "glitch", but isn't this an ideal place for live forensics? Shouldn't there be an effort to get at crucial information that has already been installed and stored on these kiosks at the same time the "fix" effort is going on? When they fix it, most all of the previous install and evidence will be gone. This would be valuable if it was a simple code error or especially if it was malicious. Again, I'm not implying this is any kind of malicious act, I'm just using it as an example of the kind of problems malicious acts could cause.

I believe companies must get onboard with live forensic examinations. Too much valuable information that could go toward solving an incident or at least documenting a policy violation or a hole in procedures is being lost in the real world. Our infrastructure security and the security of corporate concerns is at risk. In the end, it is a matter of bottom line, and the expense is well worth it.