Tuesday, February 20, 2007

Digital crime scene walkthrough

I was recently fishing through myriad sites related to criminology and crime scene processing for criminalistics folks and decided to take a peek at the technical working group for crime scene investigation documents. I came across Crime Scene Investigation: A Guide for Law Enforcement on the FBI's site and decided to read a bit of it. Note that this is different than what the DOJ put out for electronic crime scene investigation. One of the more interesting sections in the CSI document is that not only are CSI's directed to conduct a "walk through", they are encouraged to do so. The principle listed in section 2 on page 20 states "the scene walk through provides and overview of the entire scene, identifies any threats to scene integrity and ensures protection of physical evidence". Compare that to traditional digital crime scene teachings that say "if it's off, leave it off. Don't do anything to modify the scene. If it's on then pull the plug and wait for the expert to arrive".

Locard teaches us that transference is a natural by-product of interacting with crime scenes and evidence. "real world" CSI's therefore modify the crime scene as they walk through it and process the scene and the evidence. The key to investigating a crime scene is to avoid or minimize the impact that an investigator has on the scene and its evidence.
The CSI doc states that an investigator should "Avoid contaminating the scene by using the established path of entry"...."Identify and protect fragile and/or perishable evidence. Ensure that all evidence that may be compromised is immediately documented, photographed, and collected".

What can we take away from this when it comes to computer related incidents? I take away that we need to make live investigations not only a bonus feature of incident response and forensics, but it needs to become a mandatory function in any investigation. Fact is, there is a lot of fragile and perishable evidence that can become compromised if we don't collect it while the system is live. By "following an established path of entry" I think we need to use a standard methodology of live investigation that minimizes the impact to a system or network. Is it ok to stick your USB key in to a system to collect live evidence? This, and other similar issues have been debated time and time again. In my personal opinion, the answer is yes, most definitely yes. Plug in a USB key if and only if:

It has been sanitized.
Your procedure is defensible.
You have documented the state of the system/network before you plug it in.
The evidence to be collected outweighs the changes you may make to the system
It is your last or best option.

The industry has identified the order of volatility for electronic evidence but this type of "live" evidence is not often collected and is rarely used to maximum effect.

Instead of pulling the plug, why not get every last drop of evidence from the victim system before you destroy it. By immediately pulling the plug investigators are compromising the very evidence that may solve the case. Harlan Carvey's concept that the chief surgeon arrives on the scene and promptly kills the victim in order to assess the nature of the evidence rings very true here.

At the very least we need to preview the system in question and conduct a digital walkthrough of the scene before we collect evidence from the primary source.

And now for a concept...
Digital walk through: the digital walk through provides an examiner with the opportunity to assess the victim system for potential sources of digital evidence that are relevant, and to overview the entire system, in order to identify any threats to data integrity and to ensure protection and collection of volatile digital evidence that would otherwise be lost.

Monday, February 19, 2007

Forensic Certifications

It's been a while since I gave this some thought but most recently I was considering the whole certification debate. A question I often ask myself is when did certifications become a status marker? Wasn't the idea to simply prove proficiency in a given subject? Some of the brightest in the field don't posses an EnCE, or the ACE . I read several forums where people ask "what certification should I get?". Almost immediately I ask myself, why would you need a certification? What exactly is being certified? That someone is proficient with a tool? Why not call them proficiency exams? That's really all they are. Does answering 70% of questions correctly actually certify you as a forensic examiner or an expert in your field? These "certifications" remind me of the buy a degree online websites where you can get your name on any diploma you want for a mere $80.

There are several certifications that are based on practical applications of forensic methodologies and processes. The CFCE is pretty rigorous as far as certs go. You actually have to examine something (several somethings in fact) in order to pass. The CCE forces people to pass three practicals in addition to a written exam. The SANS GCFA practical is optional now if you want to go for the gold level.

What's the point of all of this you might be asking..well here you go. Why don't we form two major governing bodies to certify individuals as digital forensic practitioners? One for the Law Enforcement side of the house, and one for the civilians. In addition these certifications need to be a heck of a lot more difficult. I know It's certainly not a likely scenario. After all, these certification box houses are making a killing off of people and guess what? Management is eating it up! There's no end in sight. I think I'll start a certification and call it MRABAPAT (Managed to Read A Book And Pass A Test). It can be yours for $2500.

In my honest opinion it's silly issues like this that hold back our profession. Science isn't about the letters after your name.

Saturday, February 17, 2007

Routine Activity Theory

In the 1970's Cohen and Felson developed a theory that attempted to explain environmental criminology. They called it Routine Activity Theory or RAT. RAT states that crimes are committed because of three main reasons.

1) Motivated offenders
I think this speaks for itself. There is something motivating the
offenders, be it money, power, ego, etc.

2) Suitable targets
In a criminalistic point of view, this would be the single female
walking in an unlit area, or a target of opportunity i.e, a person
being in the wrong place at the right time.

3) Lack of proper guardianship (lack of security and safety measures)
Again this speaks for itself. Tourists walk around unaware and
unprotected, people don't carry mace or tazers etc..

Let's apply this to incident investigations shall we? But before we dig right in...we should look at the proposed solution to the reasons listed above. The solution provided as part of the theory is something called target hardening. The idea is to make the target of the crime so unappealing that the criminal looks elsewhere to commit the crime. Sounds a little like IT security doesn't it?

This is commonly what IT security folks refer to as "defense in depth". Defense in depth or onion security is the idea that one layer of security will always fail to protect your systems, so you should create several layers of security to protect your critical and sensitive assets.

When it comes to incident response and forensics RAT is what may allow us to analyze our "crime scene". I tend to think we can use RAT to help identify the root cause of the incidents.

1) motivated offenders...
What would have motivated someone to compromise your system or network?
Establishing a motive is not only important to a case, but it can help establish the M.O. of the attacker. This could allow an investigator to profile the attacker in an attempt to apprehend them, or to locate other victim systems on a network. Is it an internal threat or external? Do they appear to know what they are doing?

2) Suitable targets
What makes a suitable target when it comes to computer systems? This is where threat modeling comes in to play. If organizations actually prepared themselves for incidents, our job as investigators wouldn't be as hard as it is. Threat modeling in my opinion should be a part of every organizational attempt to prepare for incidents. Know your weak spots, know what dominoes are likely to fall as a result of the first getting tipped over.

For the incident responder, when establishing likely attack vectors we don't need to conduct a full threat model(unless of course you have the time to), instead why not do what cops do? Establish relationships between the systems. What systems communicate with each other? How? Is there a routine to the communications? Is anything predictable?

Establishing relationships between the computers in an organization can help locate suitable targets. It could be that outdated apache server that's supposed to be protected by a firewall, or the MySQL server that allows remote root access. Regardless of what the root cause is, locating the potential source of an incident is the key to preventing it from happening again.

3) Lack of proper guardianship
This factor in the RAT theory can be used by incident responders to identify the locations with little to no, or completely wrong type of protection mechanism in a network. Is that firewall actually blocking anything? Are the antivirus clients up to date? Often times when called in to an incident we're given very little information about the specific configurations of a network or system. Typically, IT staff either don't know or won't tell because they are trying to protect their jobs. As incident responders we need to ascertain just what level of protection existed for suspected victim systems before they became victims or before they become victims in the future.

Routine Activity Theory, does it apply to Incident Response or Forensics? Thoughts?

Friday, February 16, 2007

Out of the gate

Guess it's time to add a new blog about forensics eh? In time I'll introduce myself, my work, and the intentions of this blog, but for now this is it.