Hacking Exposed Computer Forensics Blog

Showing posts with label milestones. Show all posts

Daily Blog #18: End of the milestones - 13 and 14 detailed

Hello Reader,
The DFIR Summit has come and gone and I've learned a lot. This post marks the end of the milestones series and I think the first series I've ever actually completed on this blog. I'll be honest when I first wrote out the milestone blog I wasn't sure what the reaction would be from you. I wasn't sure if you would be upset that I was trying to define your career progression or be happy to see a way forward that you may not have seen to continue to grow your skills and knowledge. I'm happy to say that all the feedback I've gotten so far has been very positive, so if you are upset with me, you have at least not let me know.

These are the final two milestones that I know of from my 14 years of experience in the field, if you can think of what comes next I'd love to hear it. Otherwise, I hope that in another year I'll look back and see what I need to add and just keep expanding this list as I also continue to progress and learn. There is no end to our journey, only the point where we decide to stop taking it.

Milestone 13 - You've developed your own data structures parsers and you begin looking into new data structures to make new tools.

This is a great time in your career. You have matured so far as an examiner that you are expanding the field of knowledge now to help the community at large, and possibly release a product that could lead to a better future. If you are thinking forward to when you hit this milestone with the idea that nothing new will be left to be discovered then I'm happy to say this is the last of your worries. Every new application, version, service pack, operating system version, file system, service, device, etc... that gets introduced into the market and is used by a custodian becomes ripe for new artifact discovery. There is still so much we don't know about the internals and data left behind through normal system usage both in cutting edge OS releases as well as historical OS artifacts that if you find the motivation to do so I believe you will find a new artifact that will set the community a buzz.

Now having said this, you don't have to find a new artifact to make a useful tool. Many times being able to take your perspective as a seasoned examiner and apply that knowledge to program logic will allow you to create powerful programs that let newcomers have a small portion of your wisdom encapsulated in a utility. Every time an experienced examiner becomes a developer the tools available for other developers become that much better because we know what we want and need. So if you've reached milestone 13, well done. I look forward to seeing your tools and hope you will let me know if I can help you in testing and validating your output.

Milestone 14 - You get the artifact bug and spend your free time thinking of what else might exist and start creating testing environments solely to find new artifacts.

This is where I am. I have the artifact itch, when I hear people talk about things that exist/don't exist/are capable of doing within the operating system I think of what parts of the OS are involved and what should exist. I then expand that thinking to what systems and artifacts relate to those parts of the OS and begin making a mental checklist of things to check to validate my theory. If my theory appears correct I begin looking into creating a prototype parser and begin testing to validate the results. Once validated I begin to blog about it and release alpha's for testing and suddenly begin to notice and think of other things to go check and test. The cycle just continues and it's very rewarding as you just continue your understanding and knowledge of why things exist and what you should be able to recover. At the same time you can continue to give back to the community that helped you get to this point.

If you've reached milestone 14 I'd like to invite you to email me, dcowen@g-cpartners.com, lets talk about your journey and I'd like to interview you for the blog. In addition I'd love to setup a mailing list of DFIR developers and artifact hunters so we can help each other moving forward.

That's all for the milestone series, I hope you push yourself forward to achieve everything you want to and ask for help when you need it!

Daily Blog #17: Milestones 11 and 12 detailed

Milestones 11 and 12 detailed - DFIR Blog Day by David Cowen

Howdy Reader,

It's day 2 of the DFIR Summit and after winning the award for "4:Cast award for Best Forensic Article of the Year" (woo!) it's time to write another blog! Today we will be continuing the milestone series which should be done this week. Yesterday we talked about milestones 9 and 10 and today we continue to Milestones 11 and 12, coming ever closer to the end of my defined career progression.

Milestone 11 - You've realized that to optimize your workflow you need to learn some basic programming.

Up to this point none of the milestones presented required anything but your knowledge of tools, artifacts, operating systems and file systems to progress. At this point though we have reached the level where you will have to cross the gap from user to developer.

For people who have never programmed before this seems like an insurmountable task, my advice to you is to put your goals into perspective and reduce the scope of the problem you are trying to solve.

Why do you need to learn how to program? This is usually the most common question I'm asked when I bring up this point and argue its necessity. This is my answer; if you want keep growing as an examiner and become more efficient in your process while reducing frustration you will have to learn how to automate your tool execution.

This will start being as simple as batch scripts that kick off a series of one off tools in your process (prefetch, reg ripper, journal parser, lnk parser, etc...), saving you time and allowing more blog reading while things run.

Once you've achieved the batch script automation you'll start thinking about how to improve it by adding some basic decision trees allowing the batch script to run additional processes depending how a previous artifact exited or what other files exist in a directory.

Once you've made this first progression from "series of commands executed in order", to "commands executed and some program logic decides what will happen next" you've made an important step into becoming a developer.

It’s that first step that will, over time, drive you towards bridging the gap from scripting to programming as you continue to explore new things you can add to your scripts that will make your life easier. That is what learning to program is about, making your life easier by letting the programming logic you wrote once to perform the same repetitive actions and simple analysis for you one hundred times over. Once you reach the limit of what batch scripting will do for you it's time to expand into more functional programming languages.

You might choose to go to a scripting language like perl (clearly the right choice), autoit script (Hi Joakim) or python (also cool) while others will make the jump to C++/C#/Java, etc... There is no wrong answer here on where you start and where you progress to - as long as your transition does not overwhelm you.

My advice would be that if the structures necessary to write your program are more complicated than your program code then you might want to take a step back to a simpler language until you need the functionality provided by a more advanced language.

The purpose of this milestone is not to make you a developer full time. It is to make you a better examiner by automating parts of your analysis/processing/reporting that don't require you to apply the knowledge you have to make a decision. Instead of just doing repetitive tasks that keep you confined to your keyboard you will be able to switch focus to other tasks and become more productive and informed!

Milestone 12 - You've found enough deficiencies in the tools you use that you begin to write your own.

At this point you've developed enough automation code to become a decent DFIR developer. You start reading the code in some of the open source tools you use to try to better understand what and how they do what they do. You think about submitting changes to fix problems you find in your work.

Over time you may find that if the tool would only work by doing X instead of Y or reported in Z format it would be so much more useful to you, and instead of trying to rewrite someone else's tool you write one from scratch yourself to learn more.

What language you write your tool in does not matter, what matters is that you have found a real world problem to solve with your programming abilities that will propel you forward. Nothing helps you become a better developer than having a problem you really care about to solve.

The more of these problems you find to solve the better a developer you will become. Your program's needs will continue to define your choice of language and libraries and there is so much example code and data structures out there to help you! It's not important if what you are writing has been solved 100 times before by a multitude of tools, what matters is that you successfully create your own version of that tool which solves your unique need.

This is a huge step in your progression as you begin to recognize unknown artifacts in your re-creation testing and analysis and can start doing your own analysis to find them, which is covered in the next milestone!

Tomorrow we finish the milestones series and see which topic from my list looks more appealing to write about.

Daily Blog #16: Milestones 9 and 10 Detailed

Milestones 9 and 10 Detailed by David Cowen - Hacking Exposed Computer Forensics Blog

Howdy Reader,
                       It's day one of the SANS DFIR Summit here in Austin, Texas. Matthew and I are speaking this morning and I'm hoping the technical crowd here is awake enough at 9am to give us all the questions they have! Today we continue the milestone series which I hope to finish up this week before we move next week to new topics. We will be detailing milestones 9 and 10 which is pretty far along your progression as we near the end of the milestones I've documented so far. If you can think of others please let me know.

Milestone 9 - You master more than one operating system's artifacts.

    This milestone may sound simple and you may think it should have been listed much earlier in the order. I can appreciate this view point as you are thinking knowledge of an artifact equates to mastery which in my opinion it does not. Mastery in the context of this milestone reflects have all of the knowledge mentioned in the prior milestones ingrained in your memory for a second operating systems. You feel at home with your suite, tools, artifacts and native tools in both platforms allowing you to quickly triage a wider range of systems and scenarios.

    Your need to achieve this milestone will depend on your operating environment. If you work in a company that has a standard ecosystem that is strictly enforced this may not come about for quite some time. If however your company starts brining in a second operating system to the environment, or has legacy operating systems in the environment, you will need to work towards this milestone in order to handle the incidents that will arise. In my lab we handle work from a wide variety of companies and individuals as we provide our services to the public. Our need to keep up with multiple operating systems and their artifacts changes as computing trends change and we are always trying to keep up.

    Achieving this milestone is an important mark in your career, allowing you to start seeing similarities between operating systems, their fundamentals, artifacts created, and data stored. Once you begin seeing artifacts as human created software design decisions you can use that view point to find similar artifacts in other operating systems. Understanding at this level also allows you to better predict outcomes and actions recorded for your recreation testing.

Milestone 10 - You understand how file systems store data and can run tests to determine behavior.

    This was an important moment in my career. I was confident in my understanding of artifacts, I could recreate scenarios and I could explain in layman's terms why artifacts were created in the first place. What I could not fully explain until that point was how and why the underlying file system stored and accessed data and metadata. This milestone is not just about file system data structures; you can read Brian Carrier's excellent book to get your mind filled with those. This milestone is about a deeper understanding of what user activities effect the file system in different ways, leaving different files in different states depending on the actions they took.

    A great example of this milestone is the matrix of timestamps that Rob Lee shows in FOR 508 and can be seen below.

No one individual artifact created the above conditions seen above, rather its the interaction between the operating system, the application and the file system that lead to these resulting states. Since these resting states are static and reproducible they become powerful tools for your analysis in understanding more of what the file system reveals to you regarding a users activities.

You can extend this concept to none file system generic activities such as how certain applications create files, and how the file system stores them. A great example of this is Outlook's handling of attachments. When a user opens an attachment within Outlook it will extract the data to a temporary directory (the location will vary on the version of windows/office) and then reset the $STDINFO to the date of the email.

Understanding how the file system stores this data and the fact that other timestamps exist then let you do two things:

Match the $STDINFO time to the email the attachment came from in case the same attachment name exists in two emails.
Use the $FILENAME time to determine when the attachment was viewed.

There is more to this and I plan to write up a post in the near future dealing the interactions Outlook has with the file system and the facts it reveals, but this is a good summation of it to illustrate the importance of this milestone. The more you understand how the file system and it's metadata is set and what is normal the faster you can expand your investigation beyond the artifact and develop a broader picture of a users activities!

We will continue the milestone series tomorrow, if you are at the SANS DFIR Summit please come say hi!

Also Read:

Daily Blog #10: Milestone 7 and 8 Detailed

Milestone 7 and 8 detailed by David Cowen - Hacking Exposed Computer Forensics Blog

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!

Also Read:

Daily Blog #9: Milestones 5 and 6 Detailed

Hello Reader,
It's day 9 of the Zeltser blog challenge and day 2 of vacation. As I write this I'm looking at the waves roll into the sand so you'll excuse me if I might be brief, the surf is calling (as are my kids).

In today's post we resume explaining the milestones of progression of the digital forensic examiner. We've covered up to milestone 4 in prior posts and we are now approaching a level of maturity in your progression as we explain milestones 5 and 6.

Milestone 5 - You become less about the tool and more about the artifact.

The more experienced an examiner you become the less dependent on your tools you become. As you get thrown into more time sensitive situations you begin to carry a thumb drive of one off tools that quickly triage artifacts to help you identify facts, actors and threats without the need of the dongle. In some cases you can find and interpret the artifact without a tool at all! That isn't to say that you won't keep your dongle protected tool suite, you just will use it when you need the convenience and additional functionality it provides.

You have come to understand that the underlying magic that you first experienced in milestone 1 was always contained within the artifact and not the tool itself, and the tool was just interpreting the data for you. The most important part of this milestone is how efficient you can become now. Once an investigation is requested you can ascertain which artifacts will contain data that responds to your inquiry, allowing you to get back results faster and with less random keyword searching.

Milestone 6 - You understand what's normal and what's missing for multiple versions of the same operating system.

This milestone may be one of the harder to achieve with so many variants in production and what normal means in your environment. However, the benefits to understanding what's normal in your environment will help you quickly zero in on what was left behind for you to find. Being able to know what's normal includes:

Which services should be running.
Where those services should be running from.
What user the service should be running as.
What log errors are normal.
What logging is turned on by default.
Which artifacts get created by default.
What gets created when a user logs in via different methods.
Where data created through user activity will exist by default.
Knowing the default locations of application artifacts and system logs/registries.
What applications are installed by default in your environment.

The benefits are many, but include:

The ability to create your own custom white-list of hashes so you can focus only on that data created by your user.
The ability to spot what artifacts the user deleted when trying to cover their tracks.
Being able to quickly spot malicious processes trying to hide in plain sight.
Being able to quickly spot out of place directories or logs, showing the user has a high degree of sophistication and you should no longer trust the system defaults.
The ability to quickly bring out relevant data you have committed to heart in the prior section.
The ability to find anomalous log ins and accesses to a system.
The ability to correctly estimate what data you should expect to exist before you begin your investigation so you can manage the expectations of those requesting work from you.
The ability to quickly identify user installed applications that need to be researched before being examined.

This is an important milestone and the mark of a senior examiner, but you still have so much more to learn! Tomorrow we will continue the milestone series while I think up what this week's Sunday Funday will be!

Also Read:

Daily Blog #5: Milestones 3 and 4 detailed

Hello Reader,

The conversation from these posts is continuing in the comments and I'd like to ask you to consider joining us. While I enjoy sharing my perspectives we would all benefit from hearing yours as well. Whether you are just getting started or you've been doing this longer than I have, I would hope you would consider providing your experiences with these milestones and what is different in your professional achievements.

That said today's post will focus on milestones 3 and 4 as we continue up the ladder of skill and sophistication as a digital forensic examiner.

Milestone 3 - You look beyond your tool.

This is a moment of apprehension for many examiners. You've been well trained on your tool of choice and you might have heard some excellent marketing people explain to you the importance of using only tools like theirs which courts welcome with open arms. However, you also now know that other people are starting to find artifacts your tool does not yet support and you are you realizing you are missing evidence because of it. The development cycle for a major forensic suite is long, so it’s not that your tool of choice doesn't want to integrate every artifact that examiners unearth on a daily basis, it just has to be prioritized into their development schedule before they can implement it.

You also begin finding limits to the efficiency your tool of choice is providing, whether it's how its presenting data for you to review/export, to how it's handling a support artifact you want to get more data out of, or get things done faster and your tool isn't keeping up. Now is the time when you start looking at the ever widening range of other tools out there. Some examiners gravitate to another large suite tool, for instance many users of TCT, FTK and EnCase will use one of the other three to fill in a gap in functionality. Some users will gravitate to the purity of X-ways in a hope to get deeper into guts of forensics, while others will look to augment their tools abilities with tools that fill a gap like IEF. What's not important is what additional tool (commercial or open source) you adopt into your process but the fact that you've opened yourself to doing so and gotten over the fear of non-vendor created tools. This is an important step and one of many decisions you'll make of what tool to use and whose output to trust as you continue to improve.

Not all tools are made equal and eventually you may end up like me, with a license of almost every tool because each one handles X better than the others. I'm not going to tell you it’s cheap, and don't think I get anything for free (although I am willing to!), but as your case load grows you'll find that the work justifies the expense.

If you notice I've mentioned a lot of commercial tools in this post, please do not consider that an endorsement of commercial tools only or a slight towards free and open source tools. I'm trying to make sure this post is relevant to the largest segment of readers. Substitute any tool name you want in this post and the point still remains valid. In my work we use everything we can get our hands on that creates reliable, verifiable output.

Milestone 4 - You get certified with a vendor neutral certification.

Some examiners who have been in the field a long time may deride my focus on certifications for the new examiner, and that's OK. I didn't get a forensic certification until last year and I'm just now in the process of getting a vendor neutral certification (if I ever find the time to finish!). However, we are the exception to the rule as we started doing computer forensics prior to there being any certifications available to non-law enforcement examiners. That being said, for those of you who aren't cynical forensic veterans, certification is something that more employers, attorneys and judges are looking for. We discussed in Milestone 2 vendor certification and what it skills it actually demonstrates. In Milestone 4 we are looking at certifications not tied to a specific product but towards a provable set of skills, processes, and knowledge in your ability to analyze and report your findings.

There are many vendor neutral certifications out there these days; CCE, GCFE/GCFA, CFCE, etc... and which one is right for you will depend on many things such as;

Are you law enforcement? (CFCE)
Do you have a good training budget? (GCFE/GCFA)
Are you looking to join an accredited lab? (CCE)

These are not hard rules, you could get all three and more if you choose to, but it's a decent elimination criteria for you. I will tell you that overall in my opinion that the CCE is winning. Why? They made a partnership with ASCLD to be recognized as a proficiency test for accredited lab operation. (https://www.isfce.com/ASCLD.htmL)

While I and many other people are not looking forward to lab accreditation being forced on us (the day to day paperwork is painful), the partnership bestows a large amount of credibility on the certification and I do plan to obtain it now.

So I've talked about getting a vendor neutral certification and which to get, but why should you get one? This is what I believe is the important point that many miss. Your vendor certification is great for showing your competency and ability to explain the results your tools show you, but as we just discussed in the prior milestone you've grown beyond your tool. You do not have a certification in these other tools and for many tools there is no certification to be had, so beyond your own ability to demonstrate the tools reliability it’s nice to have a third party body that is attesting to your skills and ability through a written and practical test. These certifications focus more on your ability to understand artifacts, analyze evidence, and write concise reports that find and explain what they have left for you to find.

If you feel some kind of animosity towards certification programs in general I would advise you to swallow your pride and seriously consider it. While some people, Andy Rosen for example, have enough experience, education and documentable achievements/software/tools/reports behind them to be able to escape this type of scrutiny the rest of us do not. I've been doing forensics for 14 years (this December), written books, created tools, spoken at conferences, taught classes, etc... and I will tell you that I still feel that I need certification now as more judges and attorneys are looking for some way to judge an experts base competence. I'm seeing more depositions' transcripts where attorneys are asking for certification as a way to judge the reliability of reports and understanding of processes/artifacts, and this is especially important when the opposing expert has certification and you do not.

Tomorrow is Saturday and according to Lenny Zelster he would post interesting reading and quotes on weekends. That sounds pretty good to me so I'll follow the same and look to post the next part of this series on Monday.

Also Read:

Daily Blog #4: Milestones 1 and 2 Detailed

Hello Reader,
In my last post we talked about the milestones and optional achievements you can look forward to in your forensic career. This post will go into detail on what it takes to achieve milestones 1 and 2.

Milestone 1 - Your tool defines your workflow.

    When most of us get our first job as digital forensic examiner it's through an employer where we are transitioning roles and not after graduating with a degree in computer forensics, though, that is now a possibility! Without a 4 year foundation in digital forensics backing you up, you and your employer look to make an investment in your career by purchasing a forensic suite and a training package to learn how to use it.

    When you first receive training on how to use a forensic suite, no matter which one, you are amazed at what is suddenly possible. The ability to recover deleted files, carve long deleted data, determine a users activities and all the rest of the data you gain from the tools ability to parse computer forensic artifacts empower you in your first investigations. You are content at this point by what your tool is able to do and what you have been trained to do with it.

    So let me be clear because as people grow in their experience in skills they begin to look back at this time with disdain at their former selves. There is nothing wrong with your results at this point, any evidence that you find in your investigation is still good evidence. At this stage in your career though you may be missing evidence, not because the tool is faulty but because you have not yet learned all the artifacts that exist. You may miss evidence at this point that can add more to your findings, with the worst possibility being you miss evidence that would have revealed more about whatever the focus of your investigation was.

    In this milestone you also chase the most red herrings as you are still learning to understand what is possible, what the system records, and what's relevant in your investigations. If you are in this milestone I would encourage you to move on to other milestones as quickly as you can. While the results of tool are correct, you are missing artifacts and a bigger picture of the actions of those you are investigating. The only thing you can do to move forward is to get more experience and depending on your budget go to non-vendor training, conferences or read blogs and white papers to start educating yourself on what exists outside of your walled garden.

Milestone 2 - You get certified on your tool.
    This is an important milestone in your career, outside of kudos from those who you give your reports this is your first external validation of your skills and abilities as a digital forensic examiner. What is important to remember at this point is what your vendor certification means. It means that you have shown skill and knowledge in how to perform an examination using their tools. It is not a reflection on your overall knowledge of what is possible and your total capabilities. Many people see a vendor certification as an end point in their credentials and I would encourage you to think outside that box.

    Let me be clear, there is great value in a vendor certification. Many attorneys are getting smart and asking experts if they are certified in the tools they use as a way to judge competency in the results those tools produce. Being able to pass a written test that shows your knowledge of how the tool works, and the ability to successfully retrieve known artifacts through a practical test is great. You're not done though and if your organization views this as 'being done' in your professional path at this point you should stop and think about what their intentions to grow your skills are.

    Once you obtain this certification you'll likely join a mailing list with other certified professionals who can ask each other questions outside of the public view. This is good but remember that there is no confidentiality on those emails and they can be quoted against you in the future. Consider always subscribing and replying from a non-work email address that does not contain your name so your past statements don't come back to haunt you. You have plenty of time to show people how smart you are, you just may not be as smart as you think you are at this point.

    The other great perk of this milestone is the normal requirement for continuing education anually. This provides a great justification for your employer to pay for you to go to conferences and other training in order to keep the certification. Most employers like having a certified employee as it allows them to show competence to those that are receiving your reports.

    I'll end this daily blog entry by saying, I'm constantly amazed on new artifacts and research that is revealed everyday. Digital Forensics is a science, never forget that, and we have to stay up to date with it to be the best scientists we can be.

Also Read:

Daily Blog #3: The Progession of the Digital Forensic Examiner

The Progession of the Digital Forensic Examiner by David Cowen

Hello Reader,
I've been asked these questions many times; "What does it take to become a 'real' digital forensic examiner?", and "What will it take for me to achieve a higher level of understanding and ability?" If you can create verifiable results in any tool that another examiner can recreate and successfully defend your findings I consider you to be a real digital forensic examiner.

If you want to know what it takes to grow and become a better digital forensic examiner I decided to make the following list of milestones and optional achievements that an examiner can use to judge their place in their own digital forensic knowledge progression.

Now this list is just for digital forensics, I don't know enough about the IR world to make a similar list. The list of milestones is not a linear path either, its met as a series of goalposts you can achieve in any order. The purpose of this post is not be judged on what you have not done, but rather to help you see what you can do in your continuing career as a digital forensic examiner.

There is truly no ending point as the amount of data we can continue to research and understand grows on a daily basis! My plan is to expand this list into a series of posts that explain each milestone, what it takes to achieve it and how it benefits you. For those of you who want to join me in the overachiever club feel free to do all of them! Otherwise, pick the milestones that mean the most to you and your current needs and make a plan to succeed.

Milestone 1 - Your tool defines your workflow.

This is where most examiners start, they get access to one tool (it doesn't matter what tool TCT/Encase/FTK/Xways/Prodiscover/SMART/etc..), they get some kind of training and their abilities are defined by what their tool suite can do.

Milestone 2 - You get certified on your tool.

You've learned enough about your tool and the artifacts it parses to show competency through certification.

Milestone 3 - You look beyond your tool.

You've found the limits of your tool and discovered there are additional artifacts that would help your investigation, you start using other tools in your investigations to augment your main suite.

Milestone 4 - You get certified with a vendor neutral certification.

You realize that your vendor certification is great for showing competency in using their tool, but it does not represent your skills of the overall forensic process.

Milestone 5 - You become less about the tool and more about the artifact.

You start memorizing where all your favorite artifacts are that you use in your investigations, you start comparing tools to see which gives you output you like the most.

Milestone 6 - You understand what's normal and what's missing for multiple versions of the same operating system.

You've done enough investigations and testing now to be able to spot what's missing and let the users attempts to hide their actions guide your investigation.

Milestone 7 - You master re-creation testing.

You are a virtual machine master easily testing new artifacts and hypothesis to create defensible results.

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

You've moved your ideas away from tools and to operating system versions, states and artifacts to the point that any other examiner can replicate your work with any tool.

Milestone 9 - You master more than one operating system's artifacts.

You've moved beyond the first operating system you learned about and started the quest to learn more about other operating systems artifacts.

Milestone 10 - You understand how file systems store data and can run tests to determine behavior.

You've moved beyond the artifact to the underlying operating system and file system for a deeper understanding.

Milestone 11 - You've realized that to optimize your workflow you need to learn some basic programming.

Frustrated by how many separate tools you have to run and combine, you start to write your own scripts to stitch them together.

Milestone 12 - You've found enough deficiencies in the tools you use, you begin to write your own.

You've learned the artifacts, you've read the white papers, now your ready to get the output in just the way you want it by writing your own version.

Milestone 13 - You've developed your own data structures parsers and you begin looking into new data structures to make new tools.

You have moved beyond just recreating other peoples tools into creating your own! The digital world is your forensic oyster!

Milestone 14 - You get the artifact bug and spend your free time thinking of what else might exist and start creating testing environments solely to find new artifacts.

The sheer number of possibilities has taken hold of you and you realize you've found a career for life.

The following are listed as Optional Achievements.

Why optional? Not every position where you will be doing computer forensics will put you in the position to be able to do all of these, but they are nice moments in your career that others will notice.

Optional Achievement 1 - You submit an affidavit/declaration to the court

Optional Achievement 2 - You get appointed as a fact witness

Optional Achievement 3 - You get appointed as an expert witness

Optional Achievement 4 - You submit an expert report to the court

Optional Achievement 5 - You are accepted by a court as an expert

Optional Achievement 6 - You've contributed a plugin to a tool

Optional Achievement 7 - You've written a white paper on a forensic artifact

Optional Achievement 8 - You start a forensic blog

Optional Achievement 9 - You present research at a forensic conference

Optional Achievement 10 - You write a book on forensics

Optional Achievement 11 - You release a tool

Optional Achievement 12 - You find a new forensic artifact!

Disagree with me? Think I missed something? Want to do more with this? Comment below, lets talk.
In the following days I'll be writing a post per milestone to expound on what I mean and how you can determine if you've achieved it.

Also Read:

Milestones 13 & 14 - Detailed

Milestones 11 & 12 - Detailed

Milestones 10 - Detailed

Milestones 8 & 9 - Detailed

Milestones 7 & 8 - Detailed

Milestones 5 & 6 - Detailed

Milestones 3 & 4 - Detailed

Milestones 1 & 2 - Detailed