Daily Blog #10: Milestone 7 and 8 detailed

Hola Reader,
    Another day, another blog! Day 10 and so far I'm enjoying this. It's nice to post regularly and get good feedback. If you are a returning reader, hey there buddy hope you are enjoying the new daily format. If you are a new reader, welcome! I have 342 of these blogs left so you came just in time! Today the milestone series (there are three days of these left, and conveniently three days left this week!) continues with milestones 7 and 8 which I believe are exciting times in a digital forensic examiner's progression.

Milestone 7 - You master re-creation testing.

    Many people are confused when I talk about re-creation testing, and it's something we do a lot in my lab when we encounter certain situations. What is re-creation testing you ask? It's attempting to reliably reproduce an artifact or an observed state in a forensic image through controlled testing. This usually happens in a virtual machine but you can also do it with a fresh install of the operating system if you believe a virtual machine may inhibit proper results. Here is a list of situations where I consider re-creation testing:

• An artifact has been recovered that will not parse correctly,
• An application is performing out of the ordinary in a way that effects the normal forensic data it leaves recoverable,
• You encounter an unknown application and need to understand possible artifacts,
• You find a new artifact and you need to validate its meaning,
• You need to test a new tool,
• You need to test how an artifact changes on different versions of the same artifact or application,
• An opposing expert has issued an opinion that you are unsure of, and you need to test to see if you can agree or disagree with his findings,
• You find a system cleaner or wiper and need to see what signs of use it leaves behind.

    In order to do re-creation successfully you need to have a test plan, an expected result and good test environment

• A test plan - This can be as simple as 'install X application and see what registry keys it creates', to as complicated as 'virtualize the enterprise network and determine what is recorded when X occurs'. Your test plan needs to state what version of the operating system and application you are planning to test. This will normally be the versions found on the forensic image you are attempting to recreate.
• An expected result - You should use your understanding of the forensic process and the operating system to predict what will happen. This is important as the test results will increase your knowledge and it gives you direction in your testing.
• A good test environment - Many times people will get the suspect system booted into a virtual environment to better understand what was occurring on the system. I think doing this is great for understanding more about how your suspect's systems were configured/operated but it is not a good way to do re-creation testing. The goal of re-creation testing is to test for your expected result in a controlled environment. This means you know all the software/service packs/configurations for the system you are testing and whatever the custodian left behind in his original system will not throw you off.

    Re-creation testing is how you go beyond what you've been trained on, read about, seen presented on a conference, and into your own tested and verified facts. The documentation of this testing will become the basis for your opinion and the defense of your results. As you take on more challenging cases where the activity your seeing may be unique to your environment and no blog, book, or person can help you, re-creation testing is where you turn for help.

    This is a big topic and one I plan to follow up with a better framework/example for testing in the coming weeks. If you are currently working to achieve this milestone here is some advice; I know it seems hard and a time sink right now, but the better you get at this the better your results will be. It's easy for an opposing expert to argue against probable outcomes and conjecture, it's very hard to disprove documented test results!

Milestone 8 - Your processes and workflow become not only understandable, but accepted by 3rd parties.

    This milestone is all about the maturity of your process. You understand your workflows well enough, and the types of cases you typically work, to create a repeatable process of artifacts to check and their meaning. The major reason to do this is to allow others you bring in to collaborate on investigations follow the workflow you've verified to create reliable results as they work their way through the first milestones.

    The other major purpose is documenting and defending your process when it is questioned by third parties. This can come in the face of whomever is requesting your work; auditors, regulatory agencies or opposing expert witnesses being a few examples.

    Documenting your processes and workflows take time, but you will better for it and if you are able to do it in a group setting you will likely be able to pool together knowledge for a better end result.

    That's all for today's post, as I write these milestones I see more places where I feel dedicated blogs are necessary to really explain my experiences and learned lessons so you can avoid making my mistakes. Glad I have 342 more of these to fit those in!