The Alexiou Principle

One of the most common mistakes I see made by computer forensic investigators of all levels of experience, Law Enforcement, and Corporate, is the lack of a clear direction. They know there is "bad guy" stuff out there somewhere, so they go attack it without first establishing an investigation plan. In my experience, this methodology NEVER yields solid results, and ALWAYS leads to confusion, wasted time, and questions going unanswered. As forensic investigators using such absolute terms like "never", and "always" is a NOGO, but in this case I find that it's true. Please comment you have experienced the contrary.

In the spirit of coming to you with solutions and not problems, I would like to share the investigative theory that I use and that have been proven to work EVERY time..."The Alexiou Principle". Named after its creator Mike Alexiou, the Alexiou Principle states four questions for the investigator to answer:

1. What question are you trying to answer?
2. What data do you need to answer that question?
3. How do you extract that data?
4. What does that data tell you?

Every case has a question - in fact most cases have multiple questions. Regardless of what the circumstances are, there is something you are trying to answer. I encourage my team to make sure these questions are clear with their customers to ensure that expectations have been set appropriately on both sides. Few things are worse than coming to what you believe to be the conclusion of an investigation and have the customer ask you, "What about X"? and you're all, "What? We never discussed X"! To avoid this hammer out the questions the client wants to have answered and review it with them! That way, they know what you are going to do, and more importantly, YOU know what the expectations on you are! I also encourage my team to log their questions in their Case Notes. Doing this not only helps them to keep track of what it is exactly that they are doing (preventing scope creep and analysis paralysis), but it also allows them to track what the answers to those questions are and how they came about finding those answers (making the writing of their final reports SOOOOOO much easier).

Once you have established what it is that you are trying to answer, it's time to figure out what data is going to give you the answers you are looking for. Depending on the question and the operating system there are likely several places that you will need to look. The key here is being able to phrase precisely and clearly what it is that you are looking for. For example, I have worked several cases involving AS/400s. Now although my first job out of the Army was as an AS/400 administrator, that was more than 10 years ago and I was only in that role for about six months. So any knowledge I had about the AS/400 or Z/OS is totally gone (probably replaced by important facts like which restaurants have the best bread pudding, and how to help my daughter hold a "proper" tea party)! But who cares!? Not me IF I can either ask the customer's admin, or I have Internet access. Say for instance I wanted to know user activity on an AS/400. A quick search on the web showed me that I would need to check the DSPSECAUD to see if security auditing was activated, and then I could display the audit journals by running DSPJRN JRN(QAUDJRN). I know that is kind of an obscure example, but you get the idea.

Once you have identified your data, you need to extract it. How you do this is really up to you and will depend greatly on your case, the evidence you have on hand, the data you have already collected, and the tools in your toolbox. I won't go much more into this question, because I think it's pretty self explanatory. The one thing I will say is that you should treat this question like a when we did math problems in like 5th grade. SHOW YOUR WORK. State in your notes and in the final report that you extracted data X, Y, and Z for the purposes of BLAH.

Finally, and most importantly (in my opinion) is what the data tells you. Some common mistakes investigators (including myself!) make are jumping to conclusions about the data, misinterpreting the data, or forcing the data to fit into their theories. When you are looking at your data and think you have an answer, go back to your notes and outline the process you just took to get there. Seriously, this takes all of 3 minutes, but will prove to be invaluable to your case. I will state my question, indicate where the data exists, indicate how I extracted that data to include the tool(s) and version(s), and what I believe that data is telling me. Once I have all of that information written down, I will read it over a few times to make sure it says what I want it to say (as opposed to simply being the first thing I wrote down - which is often nothing more than a series of jumbled thoughts and comments). Then I show it to a buddy and ask him if it makes sense. A peer review of your conclusions is a great tool you can use to ensure you are not making incorrect assumptions, or misinterpreting data. Then you would repeat this process for every question you have been asked to answer by your customer.

If this seems really easy to you, that's because it is. Too many investigators introduce unneeded complexity into their investigations by not focusing and having a clear investigation plan. Maybe these people think they need to make things seem complex so that they appear to be smart, or like "real" pros...seasoned and hard core? I don't know, in my opinion having an attitude like that is counter productive and a huge waste of time.

Being a good investigator has nothing to do with how many $5 words you can throw out, or how many years of experience you have! It's about figuring out what happened! I promise you, if you apply the Alexiou Principle and go into your cases with a PLAN, you will be a better investigator, regardless if this is your first case or your 500th.