A Rubik's Approach: Casey Anthony Google Searches Overlooked & Lessons Learned

The buzz surrounding the Casey Anthony Trial has resurfaced (yet again), amid a media report relating to Google searches being overlooked by detectives on a computer that was primarily used by Casey Anthony. You can conduct your own internet search to read the various articles and stories published online, regarding this recent development. At the conclusion of the trial in the summer of 2011, one of the detectives assigned to this case provided an exclusive interview with Digital Forensic Source; regarding the trial and digital forensics, you can read the DFSource posts here.


Observations
(Disclaimer: Any information and/or opinions contained in this blog post should NOT be considered legal advice. As always, consult with an attorney at law for legal advice.)

Hindsight is always 20/20 and it is easy to sit back and play that Monday morning quarterback. The defense expert and fellow digital forensic examiner, Larry Daniel of Guardian Digital Forensics, stated that he did locate this evidence and it was brought to the defense team's attention prior to the trial. Regardless, of why investigators with the OCSO didn't find this digital evidence prior to the trial, the fact remains that our criminal justice system is an adversarial system. Generally, inculpatory evidence, such as these searches, is not required to be brought to the attention of the State by the Defense as the burden falls upon the State to prove its case, beyond a reasonable doubt.  If the State had located exculpatory evidence (i.e. Google searches that would prove innocence of the defendant), they would have been obligated to notify the Defense of this evidence. However, this can be open to interpretation and not always black & white. Rules of evidence vary by State.

Lessons Learned
And with great power comes great responsibility. As a lethal forensicator, are you asking yourself what lessons can be learned from this case? There are many takeaways in this case that you can apply to your DFIR workflow. Were you thorough and complete in your forensic methodology? Did a peer review your findings? Are you focused on being an objective digital fact finder in every forensic exam? Did you answer your original question posed, prior to initiating a forensic examination? Do you regularly reference an internal/external workflow chart or something similar to the SANS DFIR Poster [artifact analysis] to ensure your forensic examination is focused and targeting the necessary digital artifacts? The best DFIR and most powerful tool is the one that resides between one's ears. Forensic examinations are only as complete and thorough as the digital forensic examiner. We have all had the light bulb moment or have reached a roadblock where you make a quick phone call, send out an e-mail to one of the DFIR lists, or post a tweet to your DFIR followers; Moments later, you get your answer and think to yourself..."why didn't I think of that?" We've all executed a knockout in a forensic exam, and then we call upon a fellow forensic examiner for peer review. He or she then finds a few more artifacts that we may have missed and then you cannot understand why you missed the artifact. We all have the same or similar methodologies, yet our lens or instrument we use in conducting our exams vary, which is important to keep in mind. I am confident that the detectives/examiners in this case and with all the digital evidence mediums that were involved, looked the evidence and analyses over several times. If this was the only machine where an examiner forgot to complete Firefox browser analysis, then that one missed opportunity is all everyone remembers. And now a football analogy to put things in perspective, nobody remembers how many points a team puts up on the scoreboard or how badly they defeat their opponent. People remember the score at the end of the game. People also remember that game-winning field goal that a kicker misses, which costs their team to win the game. Everything else that happens during a game is non-memorable for the most part, but each play or each possession contribute to that final score and a W or L being added to your team's record.
 

A Rubik's Approach
In digital forensics, the dozens of other artifacts that the examiner found may be relevant, but that one artifact the examiner failed to obtain during their forensic examination is what then becomes relevant and what people (a jury) remember. So the question is, what are you doing to ensure your validated forensic findings that have been validated? Just as there are many ways to solve a rubik's cube, there are different ways to conduct a forensic examination and arrive at the same conclusive results (or at least we should). As forensic examiners, utilize an array of forensic tools to validate your findings. It doesn't matter if you prefer Windows-based vs Linux-based tools or commercial vs FOSS (Free Open Source Software) tools. Our results should be precise and reach the same conclusion. As we follow along in the scientific method are we stopping to think and try a different approach? For example, if the question I am trying to answer is did the suspect plug this Acme Corporation removable USB device into this machine? After I have conducted my analysis and conclude that the suspect did plug the Acme Corp. removable USB device into this machine, are you reversing your hypothesis? Ask yourself, what artifacts would support a hypothesis that the suspect DID NOT plug this Acme Corporation removable USB device into this machine?

As a digital forensic community, there were lessons and many takeaways from the Casey Anthony trial. Whether you have never testified in court and are looking for videos of actual courtroom digital forensic testimony, wanting to review a digital forensic report, or just wanting to view some of the artifacts released in this case, there is something for every digital forensic examiner to learn from in this case. A high profile, publicized trial, that also heavily relied upon digital evidence, bringing shortcomings, successes, and transparency of digital forensics into the public eye.

2012 Forensic 4cast Digital Forensic Awards-- Results

The 2012 Forensic 4cast Digital Forensic Awards were just streamed LIVE here at the SANS Digital Forensics and Incident Response Summit.


Computer Forensic Hardware Tool of the Year

• Tableau TD2

Digital Forensic Article of the Year

• Digital Forensics SIFT’ing: Cheating Timelines with log2timeline – David Nides

Phone Forensic Software Tool of the Year

• Cellebrite Physical Analyzer

Digital Forensic Podcast of the Year

• Cyberspeak

Digital Forensic Book of the Year

• Digital Forensics With Open Source Tools – Cory Altheide & Harlan Carvey

Computer Forensic Software Tool of the Year

• log2timeline

Digital Forensic Blog of the Year

• A Fistful of Dongles – Eric Huber

Phone Forensic Hardware Tool of the Year

• Cellebrite UFED

Digital Forensic Organization of the Year

• Consortium of Digital Forensic Specialists (CDFS)

Digital Forensic Examiner of the Year

• Cindy Murphy

For more information on the Forensic 4cast Awards click here. Hats off to Lee Whitfield for putting together another successful awards. Remember, these awards are 100% community driven with the nominees & winners voted on by the DFIR community. This year's awards alone had 4,000 votes!
If you are wanting to catch the remainder of the talks here at the #DFIRSummit checkout SANS' LiveStream (no parking as there are only 50 spots available).

Preview: #DFIRSummit 2012

SANS Digital Forensics and Incident Response Summit 2012 is just days away and begins June 26th. The pre-summit training courses began June 20th and are going on now. The agenda has been posted, as well as the speaker line-up. The 2012 Forensic 4cast Awards are at 9AM Central, Wednesday June 27th and will be streamed LIVE from the Summit (link will be posted later). Lee Whitfield posted to Twitter that the awards are secured, under lock and key in an undisclosed location.

I will be attending the Summit and looking forward to re-connecting with old friends and meeting new friends. Make sure that you follow us on Twitter @DFSource for live updates from the Summit. #DFIRSummit is the official hash tag of the SANS Digital Forensics and Incident Response Summit. 

#DFIRSummit & Volatility Goodness:

• LiME & Volatility's new Android Memory Analysis
• SANS Summit Pre-Talk Teaser
• More Volatility Goodness

Unofficial 2012 Forensic 4cast Awards:

Lee Whitfield, Brian Moran, Cindy Murphy, and Tom Yarrish. delivered the unofficial Forensic 4cast Awards via Google+ Live Hangout. In case you missed it here are the results:

• Forensic dance of the year – Hal Pomeranz 
• Shiniest head in digital forensics – Rob Lee
• Wussiest punch in DFIR – Dave Kovar
• Forensic Tool of the year – Mark McKinnon
• Forensic beard of the year – David Cowen
• Best photoshop of Lee Whitfield – J-Michael Roberts, Brian Moran, Mark McKinnon
• Most confusing presentation – Hal Pomeranz
• Handsomest male forensicator – Joseph Shaw
• Prettiest female forensicator – Lee Whitfield
• The “Not Bad for an Old Guy” Award – Ovie Carroll
• Most unpronounceable name in forensics- Kristinn Gudjonsson

See you in Austin and make sure to follow the Summit happenings via our Twitter feed @DFSource and #DFIRSummit, the official hash tag of the Summit. 

Internet Evidence Finder vs NetAnalysis vs Cacheback

In a recent conversation that began on Google+ with several digital forensic professionals, how does Internet Evidence Finder version 5 stack up to some of the other commercial tools? After some discussion, I contacted JadSoftware and the company stated that they were in the process of completing internal testing on IEF v5 and comparing it to other commercial tools. JadSoftware stated they would provide our readers with those results to publish here to the blog (see below). In regards to NetAnalysis and CacheBack performing their own tests, they have been contacted at the time of this blog post. If NetAnalysis or CacheBack provides their own testing results then that information will be posted here.


Editor's Note: Digital Forensic Source does not endorse commercial digital forensic tools. This information is being shared as a service to the digital forensic community, and is being provided "as-is", the testing results completed by the vendor (JadSoftware). DF Source did beta test version 5 and provide feedback to the vendor. As always, conduct your own testing on your DF tools.


The browser testing results that were conducted by JadSoftware, and shared with Digital Forensic Source, are being posted as a service to the digital forensic community. These results have not been tested by Digital Forensic Source.

* Click Here for the Browser Forensic Tools Comparison Chart provided by JadSoftware

(For a listing of other files posted to the Digital Forensic Source, click here.)

Adam Belsher (CEO of JadSoftware) stated, "Some of our key differentiators include:

·Carving for IE, Chrome, Opera, and Firefox (Cacheback doesn’t do any carving and NetAnalysis is limited.)

·Single search for all artifacts (rather than having to do multiple searches)

·We search in more areas on the hard drive (i.e.  hiberfile.sys with decompression, pagefile.sys, live RAM captures etc.)

·We support more artifacts within the browsers (i.e. Chrome- top sites, credit card data, favicons etc.)"

Commentary: On a side note, thank you JadSoftware for following up on the inquiries in regards to IEF and how it is currently comparing to other commercial browser forensic tools. It is a great thing for the digital forensic community, when vendors respond promptly to the needs of examiners. As budgets continue to be a focus for governments, academia, and companies, digital forensic vendors that are truly service-oriented and driven by the requests of their customers (the forensic analyst), will be successful. Sharing information, research, tool testing, etc. benefits the entire digital forensic community.

DFIROnline: Connecting the DFIR Community (January Meetup)

DFIROnline is an opportunity to meet-up monthly (informally) with other DFIR practitioners. It is being held the third Thursday of every month @ 2000 hours ET. If you missed tonight's meet-up the archive will be posted soon. Props to Mike Wilkinson for taking the initiative to organize (organise for Lee Whitfield) DFIROnline.

Leave comments or feedback from tonight's meet-up. These informal meet-ups are a great idea and the digital forensics community was out in force this evening. Participation (# of attendees) tripled compared to the first DFIROnline meet up in December, which is archived and can be viewed here. Great presentations this evening by Harlan Carvey on "Malware Detection with An Acquired Image" and Eric Huber on "The Advanced Persistent Threat or: How I Learned to Stop Worrying and Love DF/IR". {Be a sheep dog!}

I enjoy watching Harlan present. He always delivers a practical (something that can be implemented now into your DFIR toolkit/processes) presentation, the DFIR analyst/investigator can understand and deploy immediately. Eric also delivered a great presentation on the APT...What it is and what it is not; drawing upon his knowledge of history, to demonstrate and define the APT. Make sure you catch the next DFIROnline meet-up on Thursday, February 16, 2012. 

Checkout the future line-up already scheduled for this year:

Feb 16 2012 Peter Coons and John Clingerman: Case studies in e-discovery  

                        Jon Rajewski     TBA

Mar 15 2012 Hal Pomeranz: Linux Forensics for non Linux users        

                        Corey Harrell: Ripping Volume Shadow Copies - Tracking User Activity

Remember to follow #DFIROnline hash tag on Twitter.

2012 Forensic 4cast DFIR Awards

The 2012 Forensic 4cast Digital Forensic Award Nominations are now open. Submit your nominations here. Nominations are for 2011 and the awards ceremony will be at the SANS Forensic Summit (June 26th & June 27th) in Austin, TX, presented by the British Texan and lethal forensicator, Lee Whitfield.
The awards started in 2009. In case you missed the first annual Forensic 4cast awards, you can watch it here or directly on uStream. As you can see the awards have come a long way, and have really evolved into a digital forensic community driven event. Lee is even required to wear pants when presenting the awards at the LIVE event, unlike the first awards ceremony! So, calling all digital forensic professionals to cast those nominations!
Once the nomination process is complete, the nominees will be posted on the Forensic 4cast website, where voting will commence leading up to the Forensic Summit. If you are deciding what you can do to give back to the digital forensics community, this is your calling! I am showing my support, just as Eric Huber's A Fistful of Dongles blog did, by nominating Kristinn Gudjonsson (Digital Forensic Examiner of the Year) and Log2Timeline (Computer Forensic Software Tool of the Year). Remember, the Forensic 4cast Awards are a community driven event. The nominees and winners are chosen by the community. Cast your nomination and tell a friend!


The categories are:

•  Digital Forensic Blog of the Year
•  Digital Forensic Article of the Year
•  Digital Forensic Book of the Year
•  Digital Forensic Podcast of the Year
•  Computer Forensic Hardware Tool of the Year
•  Computer Forensic Software Tool of the Year (Log2timeline)
•  Phone Forensic Hardware Tool of the Year
•  Phone Forensic Software Tool of the Year
•  Digital Forensic Examiner of the Year (Kristinn Gudjonsson)
•  Digital Forensic Organization of the Year

Forensic Course Review: SANS Forensics 558 (Network Forensics)

I was fortunate last week to attend SANS Network Forensics (FOR-558) taught by Paul Henry during SANS Chicago 2011 event. Overall, I would give this course four and a half (4.5) out of five (5) stars and highly recommend it to any #DFIR practitioner. Of mention, fellow forensicator, friend, and blogger, Ken Pryor, also attended FOR-558 and I am sure he will have a review posted over at the Digital Forensics blog soon. As with any SANS event, the "SANS fire hose effect" began the morning of day one. Before diving deep into FOR-558, I would like to thank Mr. Paul Henry. Paul is a great instructor, bringing his many years of experience to the classroom, and an expert in all facets of InfoSec and Digital Forensics (Paul, you rock!).

Day One: Covert Tunnels 
Day One we hit the ground running capturing network traffic utilizing tools like tcpdump, which is pre-compiled right from the SNIFT (SANS Network Investigative Forensic Toolkit) workstation that is issued to FOR-558 students. We went through network protocols and the layers of the OSI Model starting with DHCP, MACs, and quickly moved into capturing and filtering data packets utilizing the SNIFT workstation. We then moved into network tunneling of encapsulated data packets, which was cool! We even dissected an ICMP Tunnel .pcap using tcpdump, Wireshark, and a hex editor. The afternoon of Day One was spent on hands-on labs looking at covert ICMP and DNS tunnels. We also went through a quick *nix command-line refresher, since we would be working primarily from the command-line on our SNIFT workstation for the entire week. I quickly learned how important | grep | and other Linux command-line tools would be during the labs and capstone investigation.

Day Two: Deep Packet Analysis
Day Two was focused on forensic methodology, collecting evidence, and deep packet analysis, which was full of wireshark, tshark, ngrep, ssh, scp, tcpxtract, oftcat, pcapcat, networkminer, and smtpdump to name a few. Day Two we spent a lot of hands-on using Wireshark reviewing packets from an OFT (OSCAR File Transfer). During these lab exercises, it also reiterated anomalies in Wireshark (and other forensic tools) on how data is parsed and presented to the GUI. Validate, validate, validate! Day Two could have been an additional half-day with all the lab exercises.


Day Three: Firewalls, IDS, Proxies, and Data Reconstruction 
Day Three was full of analysis on firewalls, routers, IDS, Splunk and Log analysis, and full content reconstruction from packet captures and proxy caches. The morning of Day Three, I had some networking issues with my MBP and VmWare Fusion 4, so Paul was gracious enough to let me utilize his machine for the labs and by the afternoon, I had the networking issues with my system corrected. Through these lab exercises I learned a ton of information about iptables and firewall rules, which aided me during the capstone investigation, as I was tasked with analyzing all the firewall log entries for my team. We also looked at snort, splunk, and squid cache in our afternoon lab exercises. The file carving exercise from squid cache was pretty darn cool (Note: Those of us whom were "forensicators" really enjoyed the file carving exercises that were integrated into the labs). Day Three could have also been an additional half-day with all the lab exercises.

Day Four: Network Forensics Unplugged
Day Four was 802.11 and was my favorite day of FOR-558. We spent the day discussing WAPs with lab exercises on acquiring and analyzing data. The lab exercises were great and tied everything together for the week to gear the class up for the capstone investigation on Day Five.

Day Five: Capstone Investigation
Day Five was our final/capstone investigation. We were broken up as a class into 4-5 person teams. Without revealing too much about the capstone, it drove home a concept that often we as forensic analysts overlook. If you work a case from just one angle, you can overlook other indicators that may lead down an opposite path, where you locate other forensic artifacts that may support/refute your hypothesis. Maintain focus on the goal of your digital forensic examination, but be prepared to change your hypothesis, if necessary. Always have a Plan B, Plan C, and so forth, when Plan A doesn't go as strategized. Objectivity, during your forensic examinations, will ensure you are looking at the digital evidence through a broad lens. As with any digital forensic examination, have a plan, establish chain of custody, take good case notes, include supporting artifacts, and complete a solid, easily understandable report. All of which were important during the capstone, but also during any digital forensic examination/investigation.


Conclusion
In summary, FOR-558 was a great course. The data carving techniques that we use in everyday forensic examinations are symmetrical to network forensics. I'm giving the course a four and a half (4.5) star review because more time is needed for lab exercises. After speaking with several attendees, they also felt more time was needed on lab exercises. If you decide to attend FOR-558 or any SANS Forensics course, make sure that you practice the labs in the evenings and on your own time, as it will aid in retaining the course material. I found this very helpful on the evening of Day Three. As forensic practitioners ("forensicators") we like to get our hands dirty and tear things apart (per se) to learn the process, and understand what the output from the parsed data is showing us. The lab exercises rocked; however, more time is needed to really drill down into the data and learn the concepts.
Having primarily a forensics background and listening to Paul discuss some of his DF/IR engagements, reiterated the importance of the lab exercises we were doing, and it made it easy for me to relate to the command-line kung-fu with my own present and past cases. After attending any course, the real learning takes place when the course is over and the analyst returns to his/her everyday routine. Just like any learned skill, if it is not used then it will fade. FOR-558 is no different and I highly encourage anyone working in digital forensics or the network realm to complete FOR-558. If you enjoy the command-line and learning through hands-on labs then FOR-558 is for you!
 The lab exercises and course material give the student practical application immediately, plus you get the SNIFT VM, supplement exercises, VMs, and puzzles.
Speaking of puzzles, checkout the ForensicsContest.com for network forensic puzzles. Puzzle #10 is due 11/22/11 (11:59:59PM UTC -11) and one cool thing about these puzzles, are the forensic tools that have been developed as a result of solving these forensic puzzles (i.e. oftcat, pcapcat, etc.). Now head on over to ForensicsContest.com and maybe you'll solve the puzzle. :)

No hard drive? No problem. Network Forensics to the rescue.

Img2Txt.pl (beta forensic tool)

If you followed the Casey Anthony murder trial or my DF Source interview with Detective Sandra Osborne of the Orange County Sheriff's Office, the chloroform searches were a hot item of discussion and evidentiary value during the Casey Anthony Trial. Part I and Part II of my interview with Det. Sandra Osborne.

Matthew Seyer  (part of Richland College's digital forensics program) has created a perl script called Img2Txt.pl [beta], which extracts text from images using the program tesseract. After running Img2Txt.pl the extracted text can be indexed and used for reference for keyword searches. Matthew was inspired to write this script from watching the digital forensics of the Casey Anthony Trial. Matthew has created a YouTube video on how his {beta} script works and he even uses an image presented during the Casey Anthony Trial during the demo.

During a conversation with Mr. Seyer, "I think the best way that this script can be used as of now is to extract out all image files with EnCase and preserve the folder structure, then run the script on the root folder of the extracted images. The script should preserve the folder structure of the images and copy the text to the output folder; the text files are named the same as the image in the same folder just with a .txt added to it. You can then index the output folders and search for keywords with your tool of choice. This was the quickest way of keeping track of what image it came from that I could think of on the spot."


Matthew stated, Img2Txt.pl has not been peer reviewed or tested (this is where you come in). This tool is in beta and Matthew is looking for feedback from the digital forensic community and is releasing this tool via DF Source. Please give it a test drive and provide feedback. While this tool is in its beta stage, with DF community support it has the possibility to bring context to digital forensic investigations and how we approach keyword searches, pulling text from images, indexing the text, and then integrating text data into keyword searches. (Disclaimer: As with any digital forensic tool, you must test and validate your findings. YMMV)

Visit the Img2Txt.pl page for more information on this beta digital forensic tool.
Img2Txt-v1.0Beta.pl (hosted on DF Source)

Contact Matthew Seyer
About Matthew Seyer

Exclusive: An Interview with Sandra Osborne Part II (UnCut)

Detective Sandra Osborne providing expert testimony in Casey Anthony Trial

Brad Garnett of the Digital Forensic Source blog, had the recent opportunity to interview Det. Sandra Osborne of the Computer Crimes Squad for the Orange County Sheriff's Office. Det. Sandra Osborne provided expert testimony, on behalf of the State of Florida, during the Casey Anthony Trial. This is a detailed and in-depth interview. We discuss an array of issues with Sandra; including but not limited to, her law enforcement career, digital forensics, the Casey Anthony Trial, and digital forensics in the courtroom. This is Part II of our series with Detective Sandra Osborne.

Author's note: This series takes you deep inside the workings of a large law enforcement agency, through the lens of a forensic examiner; sharing her experiences and reflections in what the media is calling, "the trial of the century", Casey Anthony Murder Trial. It was great to interview Sandy and spotlight the career of a fine law enforcement and digital forensic professional. In regards to the Casey Anthony Murder Trial, this interview focuses on the digital forensics and the expert witness testimony. For readers that have never testified in court as a witness, you should take a lot away from this interview. For the reader that has provided expert witness testimony or has testified in a legal proceeding regarding digital evidence, you should also take something away from this interview. This interview is "uncut"; Det. Osborne discusses some issues that were stipulated and agreed upon that never made it to trial. 


* Read Part I of DF Source's interview with Det. Sandra Osborne here.


DF Source: Sandra, I'd like to move into discussing the Casey Anthony trial and digital forensics in the courtroom. Earlier you mentioned, that you were recently responsible for the block of instruction covering courtroom testimony during the IACIS basic course in Maitland, Florida. You further mentioned that you would be revamping that instruction block, due to your recent experiences in the courtroom. Let's discuss those recent experiences. In particular, I'd like to shift right into the Casey Anthony trial. First, from reviewing your Computer Forensics Report , there were several different pieces of digital evidence (i.e. computers, digital cameras, cellular phones, removable media devices, etc.) that were submitted to your computer crime lab for examination. Please provide a brief overview of how you became involved with the digital evidence in this case?

SO: When I became involved with the Casey Anthony case in July of 2008, I had been assigned to the computer lab for about a year. I had never formally worked a homicide examination but I had some practice conducting exams on all kinds of other cases. I happened to be working later in the day than usual when one of our missing person's detectives, asked me how late I could stay. That's never a good question! She told me they were working an active missing child case on a 2 year old and that they would be submitting a laptop computer and a cell phone to us later that evening after they secured a search warrant. Of course, I offered to stay as late as they needed me to. I figured this one was an easy one and that it wouldn't take long to get what the detectives needed. A phone number or two, maybe some text messages to some friends or the nanny and we would locate the child and be done. I received both items sometime around 9pm. I was notified that the search warrant was signed and I was good to go for the exam. I cranked up EnCase, threw the hard drive onto my FRED / Tableau write blocker and starting imaging. I chose to image instead of preview because something told me I would need to eventually anyway. Meanwhile, I attempted to process the phone with the CelleBrite, but no luck. I think all I got that first time around was the phone contact list. Paraben's Device Seizure wouldn't connect at all. That was the extent of the cell phone / mobile forensics software I had at my disposal at the time. I believe I gave the CelleBrite report and the phone back to the detective to peruse through to see if there was anything of interest to them. I wasn't yet briefed about the case, other than the child's mother (Casey) was being less than truthful about the location of her daughter Caylee. I knew we were looking for a nanny, Zani, Zenaida, or something similar. There were hundreds of numbers, but Zani was not one of them. The family was unsure about the exact date they actually saw Caylee last. They knew it was family gathering on Father's Day, but they couldn't decide when that was exactly (unbelievable!). The family digital camera (submitted a day or two into the investigation), revealed a video of Caylee and her great grandfather at the nursing home on June 15, 2008 at about noontime. I don't believe Casey was there at that gathering. That is how we knew what exact date to start our timeline.

Page 6 of Det. Osborne's Computer Forensics Report

Over the next few weeks, about 11 cell phones and 7 computers, all from various sources, were submitted; as well as, several digital cameras and a thumb drive. In every situation, the focus was on finding Caylee. I would spend the next 8 months or so combing through this data one file and keyword search at a time.

DF Source: Do you feel there are forensic artifacts that may have been important to add into your report, that were left out due to relevance or stipulated upon, during one of the many pre-trial hearings? Anything you would like to have added or introduced as evidence at trial?

SO: At the time I completed the first report, we were still looking for a live Caylee. We had not yet recovered the remains. Thousands of tips and leads were pouring in and we had all we could do to keep up. I was searching the case file every day for new information based on the tips/leads coming in. Any findings were reported by me. The missing persons' squad conducted follow-up leads on "Internet detectives" who were calling in tips, sightings, premonitions, and visions from God telling us where to look for Caylee. At one point, the "Cat Lady" gave us her two-cents on where she envisioned we would find her. There are plenty of unemployed folks online who actively search for cases like this to "help" investigate. One website that hosts web sleuths had reports and information before we did! Crime-line tips from citizens were pouring in as well. I searched the computers for anything and everything that Casey may be associated with; such as, Universal Studios, night clubs, shot girls, social websites, email, etc. I found lots of stuff, much of it not worth reporting, but nothing that led us to Caylee.
Needless to say, we were also very busy accommodating all the requests from detectives wanting to know if we found this or that on any of the computers. As detectives gathered physical evidence and testimony from witnesses, they inquired as to whether or not anything could be found on any of the computers. This case became a media frenzy so quickly; because of, the families' requests from the local and national media for help; the town went crazy. Masses of people from all over, took days off work to search and work on this case.
We had two local police officers get fired over their relationship with this girl. I know at least one of our deputies was dishonest when detectives interviewed him and he said he barely knew Casey. I found chat between their two screen names that told us otherwise. He was fired and this evidence did not get entered at trial, although it is in my report. The second officer worked for the Orlando Police Department and is no longer employed as a law enforcement officer.
The information I included in this first report covered any files of interest to the detectives with an emphasis on the files created, accessed or written during the 31 days that Caylee had not been reported missing. This included many graphics and videos of Caylee, Casey partying at clubs, My Space IM, AIM Logger chat, Casey’s Cupid.com profile and similar items. It became very clear very early on in my investigation that members of this household spent a lot of time on the Internet. The IE history alone covered 4.5 years, from 2004 to July 2008. I felt I provided detectives with everything relevant to what they requested. From the looks of the HDD contents, it seemed the computers were used very rarely for academic study or Word processing. It was apparent to us as well that someone began dumping loads of files from the desktop computer right about the same time we began investigating this case. We believe that’s why the deleted Mozilla Firefox MORK database was so intact when we got the computer. There were 9,075 records in one deleted Internet history record. There’s only one way that could happen. It was dumped and we shut down the box.
Detectives honed in on July 16, 2008 rather quickly into the investigation. I'm not sure how or why they did, but they asked me to conduct a timeline that showed the use of the computers for that day. The original timeline I conducted was through the functionality of EnCase. I set the program to look at July 16 and July 17, 2008 and provide an indicator of the computer's activity during those 48 hours. EnCase gathers the information for the timeline by the file system dates and times; created, accessed, modified and deleted. EnCase then shows which files were active during that time. What I didn't realize at that time (but I know now) is that this was not the best approach. My timeline showed large gaps of time where it seemed there was no activity at all on the HP home computer. Therefore, I reported those gaps in time to detectives. They were working off the presumption that large gaps of time away from the computer could possibly mean that was the time frame when something may have happened to Caylee. I looked very closely at July 16th again just as the trial was starting. I filtered all the files on the HP computer to show only the 24 hours for that day. I sorted every file first by creation time and then by accessed time. What I learned was that the temporary Internet files were being accessed and created during some of those large time gaps when I thought nothing was going on. What I didn't think about in 2008 was that the index.dat files are stored in a database (hence the file extension .dat - DUH!). The EnCase timeline function reported the MAC times for the database itself and not for the individual records it contains. So, while the user is accessing the Internet, the index.dat file is not being updated the whole time it is in use. What I discovered was an AIM Logger chat (not about Caylee), lots of MySpace activity and local files being created and accessed to the desktop\pictures\shotgirls folder during the times I thought there was nothing going on. This activity goes on all day, from just before 0800hrs with a break for lunch time for about an hour and a half. At 1330hrs or thereabouts, the activity picks up again, after everyone has gone to work. What that means is that someone is one the computer from 0756hrs until 1146 hrs on the 16th of July, 2008. George (Casey’s father, Caylee’s grandfather) testified that Caylee and Casey left at about noon. The computer activity stops at 1146 hrs, right on time. George leaves for work; Cindy (mom) is already at work earlier that day. The same type of Internet and local file activity resumes after 1330 hrs, when everyone is supposed to be gone. The AIM logger chat was between two users who identified themselves in the chat by name; Casey and the other user. The MySpace appeared to be Casey’s as did the shotgirls photos. Casey was dating a DJ at a local night club at this time and although she didn’t work at the club, she promoted the local talent there and “hired” girls to work the bar serving shooters. So, it makes sense that she would be researching the clothing the girls should wear. There were many pictures in this folder, some of which were created/downloaded from MySpace that day that Caylee went missing. I was prepared to testify about this new information as soon as Mr. Baez announced in his opening statement at trial that the baby drowned in the family pool the morning of July 16, 2008. Well, the computer tells us a story that indicates either this traumatic event never happened or the computer user ignored the crisis completely.
There is a lot I would like to have added to my testimony at trial. Many hearings were held before the trial and some of them were to determine what evidence would be allowed and forbidden. Much of the evidence I included in my reports, was either stipulated to or not allowed. Sgt. Stenger did quite a bit of work with Photo Bucket.com obtaining the information about Casey's account, where she logs in from, all the pictures uploaded to the site, etc. None of that evidence made it in. All the party pics were taken by a professional photographer and uploaded during the 31 days Caylee was missing. There were other IM sessions, emails, blogs, and chats with friends all throughout those 31 days that didn't make it to trial. Not much of Casey's conversations were about Caylee.
I provided detectives all the email, pictures, blogs, Internet History, TIFs and the timeline I could find. I did look in the Volume Shadows for restore points during the times of interest, but found nothing more than I had already found.

DF Source: From watching your testimony during the trial, we know that you used EnCase as your primary forensic tool for analysis. What other forensic tools did you utilize? From 2008 to just prior to the start of the trial in May of 2011, were there any new forensic tools that you were able to implement into your forensic analysis capabilities, of digital evidence relating to the Casey Anthony trial?

SO: EnCase was the first automated forensic software I learned how to use, so that is what I feel most comfortable using. Getting an EnCE certification was the second thing I did after CFCE. I imaged all the digital evidence in this case using either EnCase or FTK Imager.
I did some work with FTK version 1.3 and then 1.8. I like the indexing feature, even if it does take forever on the front end to complete. The live searches are so much easier when you need a quick response.  I looked at all the email and attachments with FTK. I mounted the image file as an emulated disk and used Net Analysis to examine the Internet history, cookies, and temporary Internet files.
The majority of the exam work was done with EnCase. Many of the keyword searches and the email was worked in FTK, the Internet records were analyzed with Net Analysis and CacheBack. Those are the only tools I used for this one. I must say that I wish I knew then what I know now about forensics and how to stay on track with a huge, media frenzy case. I would approach the examination differently, with more experience and detail.

DF Source: Sandra, Let's move into the chloroform searches. You stated that you used Cacheback and NetAnalysis for internet history analysis. Recently, we've seen both companies issue a press release regarding these discrepancies in the output as it relates to processing the MORK database in early versions of Mozilla's Firefox browser. There have been several blog postings and articles from various sources supporting one tool over the other. Can you share additional information with DF Source readers to add context to the chloroform searches?

SO: As a result of conducting a keyword search on the Anthony's home computer for "chloroform", I found several hits within a deleted Mozilla Firefox Internet history record. I recognized the data as being from an Internet record, but that is all I could tell from the data. My sergeant found the beginning of this very large record and recognized the MORK header as an old Firefox database. He was able to carve out the entire database, which consisted of over 9,000 records (we've since learned this after the confusion at trial). He worked with that data from there.
Sgt. Stenger was not very familiar with this old database, so he enlisted the help of John Bradley, the creator of CacheBack. Mr. Bradley was asked to verify that this was in fact a MORK Mozilla Firefox Internet history database. CacheBack is a great tool for parsing Firefox (and other records) and rebuilding web pages. The class John gave us a few years ago here in Orlando was very intense and informative. He knows IE, Firefox, Chrome, and Safari very well. Because this record had been deleted, Sgt. Stenger named the file  history or Header.dat (I think) and imported it into CacheBack and into Net Analysis. Net Analysis reported many of the records but not all of them. It did, however report the page visit count for the sci-spot "chloroform" search in Google as "1" where CacheBack interpreted the page visit cout incorrectly at "84". From what I understand about the MORK database, if a web page is visited only once, the page count is left at "0" and will not increment to "1" until the second visit. This was apparently the case with the sci-spot "How+to+make+chloroform" google search page. Because the page visit count was only "1", the byte value for that was null. CacheBack did not interpret that data correctly, so it went down the database list of records until it came to a page visit count it recognized. That happened to be the MySpace.com page with a visit count of "84". Consequently, CacheBack inserted the "84" into where it thought that value should go; in the sci-spot page visit count. CacheBack also did not return the correct number of records in this large database.
Craig Wilson, creator of Net Analysis, submitted a very detailed explanation of how the MORK database works. You can read it at http://blog.digitaldetective.co.uk/2011/07/digital-evidence-discrepancies-casey.html. Both Mr.Wilson and Mr. Bradley have re-evaluated their tools as a result of this misunderstanding. Both, now report the correct number of records in the deleted history at 9,075.

(see file CacheBack errors 7.19.11.pdf) 

The Internet history from the Anthony's home computer, deleted or allocated, was submitted to the defense in the form of the evidence files via the discovery process. Defense had the raw data, as well as the .csv and .xls files containing the deleted Firefox records, as of October 2008. I know of at least 2 forensic examiners hired by the defense that did not raise any issue. That being said, the CacheBack report was created sometime after October, 2008. I'm not sure when Mr. Bradley finished working with Sgt. Stenger on the records. It was, however turned over to the defense as soon as they were finished with the report. Again, nothing was disputed from the defense examiners.
During the trial, Sgt. Stenger was asked to testify about the CacheBack report, specifically the "84" hits on the sci-spot page. He testified as to what the report said was the page visit count of "84". John Bradley was also asked about the "84" page count, to which he testified that he did not create the report (Sgt. Stenger did), but that the CacheBack reported that the sci-spot page was reportedly visited 84 times. Nothing more was said for several weeks. Defense brought Sgt. Stenger back to the stand later to challenge the CacheBack report. Mr. Baez walked Sgt. Stenger through the report and asked several questions  to dispute the "84" count. Mr. Baez basically concluded that CacheBack mis-interpreted the data and that the "84" count actually belonged to the MySpace page. Obviously, Mr. Baez had been contacted by a forensic expert to come up with the conclusions he did; but nontheless, his conclusions proved to be correct. As a result of the testimony provided, Mr. Bradley re-evaluated the way CacheBack interpreted the database and realized that it was incorrect. He worked non-stop to correct the errors and reported it immediately to Sgt. Stenger and the prosecution. At some point, the data was provided to Craig Wilson. Net Analysis has also been re-evaluated and is now interpreting the data correctly.
Neither Sgt. Stenger nor John Bradley were brought back to the stand to testify about this issue. It is not up to the witnesses to dictate the course of the trial. It was the position of the prosecutors that the CacheBack issue had been visited, revisited and corrected. Mr. Baez made his point in court and Sgt. Stenger conceded the fact that the report appeared to be incorrect. In response, Mr. Baez's closing statement was that the Computer Evidence was fraudulent. They are upset because the prosecution didn't apologize to them for the mistake. To validate more then 9,000 records that were carved from UC is literally impossible, especially since we can't recreate the scenario. I am curious to hear from others about how the validation of the tools used with this particular record could have been performed. If the creators of the tools didn't know about the errors, then I'm not sure what more could have been done at that time and with the information we had. It is unfortunate these "bugs" in the software were discovered during such a public event, however mistakes happen. It is not unusual that examiners catch mistakes in all kinds of software. We see it every day on the list serves. It's just not pleasant to be on the losing end of the mistake. The bottom line is and always has been, validate, validate, validate WHEN YOU CAN and seek several opinions when in doubt.

DF Source: The Anthony trial was a very high profile trial that centered around the digital evidence in the prosecution's case. I think the entire digital forensics community can learn from this case, and review tool validation processes and see what can be changed. What are your thoughts?

SO: I've been thinking alot about tool validation lately. In the Anthony case, I didn't work with the deleted firefox records. I just located the "chloroform" search hits in unallocated space and exported Internet history out to Net Analysis. I was still very new to CFE and didn't know what I was looking at. I didn't know how to run CacheBack at the time either, so I let my Sgt. handle all that. I had enough to do working with everything else. Now, I understand what happened, but then I didn't. We have validated CacheBack and Net Analysis many times and we use both these tools regularly. Should it become the standard to test and validate every software tool every time I use it? EnCase, FTK, X-Ways, Linux tools?
In the Anthony case, we were dealing with an old MORK database created  around 2004 or 2006 I think. We didn't know how to manually decode it. That is why we use the brilliant tools that are out there. In order to validate ANY tool, I would have had to manually decode the MORK database to verify the values being returned for each field. There were 9,075 records in that deleted history file. But for the sake of this discussion, let's say we just needed to decode only one record of interest. I would still have to manually decode the record to verify that the software is rendering the data correctly. Why would I need to software if I knew how to manually decode it?  Even if I validated Net Analysis and CacheBack earlier that same day on some other database, would it have rendered THIS MORK database correctly? Probably not.
To accurately validate a piece of software so that it is "evidence specific", you really should test it on the exact version of the software you will be using. You can only do this by manually decoding the values and then comparing what the software tool returns back to you in the form of a report; or, recreate the scenario using the exact same software that created the problem. In the case of allocated files, you could boot the image into LiveView or into a VM session or VOOM maybe, and work with it as the user would have seen it. In this case, we had deleted Firefox records.
Aside from the obvious record validation that should have been done in the Anthony case, I'm not sure what the proper protocol should be anymore. I am reluctant to dump all the history into one report now, and say that it is accurately reporting all the records that exist on the hard drive. How do I know? Must I manually decode every piece of data that I plan to call evidence to verify it? I would have to know how to dismantle every database and application out there (I suppose I could work in WinHex and forget the other tools).
I am really curious to know what other examiners are thinking about their tool validation procedures. I have received emails from friends that have said their labs are reviewing their policies, as a result of our experiences. This is probably a very good thing for all of us to do, I just don't know how far tool validation needs to go. If I knew how to reverse engineer Yahoo! Messenger chat sessions, I wouldn't need the Super decoder to decrypt and report it for me. So here we are......?

DF Source: Sandra, I know we've discussed privately how you have grown professionally as a result of the Anthony trial. Personally, I took a lot away from your testimony during the Anthony trial. I know I've said it once, twice, and then some, but fantastic job to you and Sgt. Stenger. What advice do you have for forensic examiners in the field that have never testified in a legal proceeding regarding digital evidence? Preparation really starts once you come in contact with the digital evidence; Regardless, if it is in a lab environment or in the field.

SO: Thank you again for your compliments. They are well received, I assure you. You are correct when you say your preparation for court starts once you come in contact with the digital evidence. I like to think that your prep starts from the minute you began your career as a forensic examiner.

The most important document you will write when preparing for court (second only to your forensic report) is your curriculum vitae, a/k/a fancy resume. All of your education, training, certifications, and expertise are detailed in this document. Any time an expert works on a case and is expected to testify, a CV must be submitted with your report(s) for discovery. This is counsel's first impression about you professionally. The judge will read your CV long before he/she meets you. It is the judge’s job to decide whether or not you will be permitted to testify as an expert. With a well written CV, the judge will make an informed decision about your training and qualifications and decide that you are, in fact, an expert.
Being in the hot seat is never fun (unless you just like pain), but it doesn’t have to be stressful. With a little practice, you can overcome much of the self-induced stress that goes along with testifying. Several of the questions that are always asked are who you are, what you do, and what are the training and qualifications for being a computer examiner. The first two are easy, but the last one can be a bit tricky. If you have never read your agency policy for your job description, that’s a great place to start. If you belong to any computer forensic organizations, they most likely have a description of what the job entails. I like to describe my job as my A.R.E.A.A. of expertise. Computer forensics is the Acquisition, Reconstruction, Examination, Authentication, and Analysis of data stored on electronic media. Depending on the formality of the situation, I may say something like, “My job as a computer forensic examiner is to assist detectives with the handling and processing/examination of digital and electronic evidence.” These statements are short and to the point. You can build from there, if asked.
Another question you will be asked is, “Describe for us any certifications you have and what did you have to do to obtain those?” This one requires some practice. My primary certification is through IACIS, so I will offer this explanation of their CFCE. As a CFCE candidate, I attended a 72-hour course of classroom-style instruction which consisted of both lecture and practical exercises designed to teach basic concepts of computer forensics. Following that, I completed a series of four practical problems led by a coach / mentor who peer-reviewed my work. Upon successful completion, I was required to examine an evidence file designed to simulate a computer / crime scene scenario. This portion is completed without the assistance of a coach / mentor. Finally, I passed a 100-question technical knowledge examination with a score of 80% or higher. To maintain this certification, I am required to maintain a minimum of number of continuing education hours every year and I must re-certify my competencies every 3 years.
This may sound like a lot of information, but if you can deliver this one to a jury or to counsel with confidence, everything else you say afterward will come easy. From here, you will begin talking about the facts of your case. I can’t help you there except to say document your work well and study it like your job depends on it.
The only thing I was thinking as I prepared to testify in the Anthony trial was that I couldn’t afford to embarrass my agency and I didn’t want to embarrass the membership of IACIS. When I was in the police academy in 1990, I remember one of my trainers telling the class that every call for service you handle in the field will either positively or negatively reflect on every other cop that follows you. He said, “Don’t make me follow your bad call!” I don’t know about you, but I’ve followed a few “bad calls” in my day and that’s never fun. I don’t want to be that person, so I train and practice. I considered very seriously the implications of being on a national stage and how my performance would be viewed by anyone interested. I am not very experienced in the field of computer forensics compared to yourself and many of your readers. I studied my own testimony and picked it apart. I could have said some things better, but when you’re up there under pressure, you perform how you train. There’s always room for improvement.
I encourage you to consider yourselves teachers. Most likely, you are already teaching someone about what you do every day you go to work. You teach your co-workers every time you explain what you did to extract evidence in a case. You teach your bosses the importance of maintaining certifications and training (or whatever) every time you have to beg for more money. You teach the jury about your job and how to properly handle digital evidence every time you testify. Instead of having the mindset that you are being “grilled” about your work product, take that opportunity to "teach" your audience about your profession and how you handled the evidence in the case. It helps to be on the offensive side of the field instead of constantly being on the defensive. Even during cross examination, which is designed to be controversial and combative, you can still “instruct” the opposing counsel instead of merely answering their questions in a defensive posture. How you view the court process will have a direct effect on how you behave in that environment. Practice makes perfect!

DF Source: This next question is several, encompassing a central theme of courtroom testimony. What did you do to prepare yourself for your testimony? It was clear during your testimony that you had a large case file that you were able to reference during the trial. Can you explain how technology may or may not have aided you during your expert testimony? Juries like to see, hear, and touch things. Did the prosecution having any exhibits covering your testimony that were not allowed to be entered as evidence?

SO: I actually did a lot to prepare for this case. The Anthony case spanned a period of three years. After the initial surges of “find all evidence” requests, I frequently went back into the case file to satisfy subsequent requests by detectives.
There were three prosecutors assigned to the case; each had their own job to do. The prosecutor handling the computer evidence was Linda Drane-Burdick. She is NOT a computer person. She is still learning how to use her new Blackberry. She is, however, a quick study and she is very capable of grasping concepts unfamiliar to her. Several evidence hearings were held in the weeks prior to the trial going live. Once we had a sense of where the defense was going with their arguments, we were able to formulate a plan to counter attack. Linda met with Sgt. Stenger and me four times prior to trial to discuss strategies and to formulate the questions she should ask to illicit the proper answers. She gave us her angle of attack, and we gave her the questions she should ask to get the right responses that she wanted. We wrote our own script based on the evidence she wanted to present. There were a few unrehearsed questions asked on direct, but not many. The cross examination is a different story!
One new thing that we did do was at the prompting of Lt. Dan Purcell of the Seminole County Sheriff’s Office; he offered to play the role of consultant to the prosecutor at trial. He was allowed to sit in on our strategy meetings and he sat near the prosecutor’s table at trial to help her interpret technical points. This strategy came in handy during cross examination. Mr. Baez showed me a print-out of a picture that came from an ex-boyfriend of Casey’s computer. Baez said the ex-boyfriend saved the picture of a woman sitting at a dining table and a man standing behind her. He was holding a white cloth and was reaching around her face apparently to hold the cloth over her face. The caption was “Win Her Over with Chloroform”. I had searched for that graphic on this persons’ computer during the course of this investigation but didn’t find it. Mr. Baez asked me why I didn’t find the word “Chloroform” anywhere on his computer during my searches when clearly the word was there in that graphic. I explained why sometimes we don’t find files that once existed on the hard drive (the usual deleted, overwritten stuff). He asked the question in such a way that I was not permitted to explain further and he cut me off with “No further questions.”  Linda didn’t know the answer to that question, so she didn’t know how to clarify the point on re-direct. Lt. Purcell was able to formulate a question for her right on the spot which then allowed me to explain to the jury that the word “chloroform” in that graphic is a result of the colored pixels imbedded in the graphic file and not because of text that was typed into a document.
The nature of computer evidence is such that it is not practical to print out everything. The mountain of paperwork would have been huge. As a result, much of what I wanted to show the court was on CD/DVD. This is where you and your prosecutor have to get together to discuss what you will be presenting and how it will be presented to the jury. The fancy courtroom we were in has audio / visual equipment that allows the operator to display the computer screen to the judge, the clerk, the podium, the witness and eventually to the jury once the judge allows its submission to the jury. Any reports, spreadsheets or pictures were simply opened from the disk and displayed on the monitors. Other types of evidence were displayed by laying it on an overhead projector table and then displayed through the computer screens. I found this to be a good way of viewing items without having to handle them and it saves time not having to wait for the jury to examine the item individually, one after the other.
One of the first things I did was create a chronological timeline of everything I did, start to finish. It was simply a Word doc that started with “June 15, 2008 – Compaq laptop computer and Nokia Cell phone belonging to Casey Anthony submitted to me in the lab by [name].” I then listed the main evidence I found in that evidence item. This document was a living, breathing document of my involvement along the way in condensed form. I referred to this often during my three times on the stand. Plus, it helped me refresh my memory right before the trial. It was a good way to study.
Much of the evidence I documented in all my reports was either not allowed at trial or was stipulated to by counsel in the hearings before trial. There were emails, pictures, documents and web pages in my first two reports that I never got to talk about. I conducted a very specific time line of computer events for June 16, 2008 and submitted two reports regarding that evidence that I never got to testify to. Defense counsel stated that Caylee drowned in the family pool on the morning of June 16, 2008. The home computer shows a user (“caseyomarie”) logging into AIM Chat beginning at 0756 hours and chatting with “whiteplayboi” until 0806 hours. They called each other by name during this chat session; “whiteplayboi” referred to the other user as “Casey”. Meanwhile, Firefox and MySpace were launched and pictures were downloaded and saved two folders deep into the “Shot Girls” folder on the users’ desktop. Casey claimed to be a self-appointed “shot girl” manager for the night club where her boyfriend works. All these pictures were of scantily, clad women wearing barmaid or cheerleader outfits. Other local files were accessed during the time frame of 0756 and 1146 hrs that day. There were no significant breaks in the user activity time, which indicated that the user stopped using the computer long enough to handle a family crisis, such as your child drowning in your pool. As an expert, I would have been permitted to state my opinion about this user activity to the jury. If asked, I would have stated that my opinion is that one of two things occurred; 1) either the user of the computer completely ignored the family crisis or 2) that crisis didn’t happen. I believe the jury would have been able to see through that smoke screen. It’s not often, if ever, that we get to say who is actually sitting at the keyboard, but that’s about as good as it gets.
The first picture I included in my first report was of a cartoon caricature. The graphic displays a young girl, maybe 2-3 years old, staring upward at a teddy bear hanging by a noose around its neck. The caption says, “Why do people kill people just to show people that it’s not nice to kill people?”  I can’t say where this picture came from, but it was saved to the users’ desktop during those 31 days we were looking for Caylee. I found this file rather relevant; Mr. Baez disagreed. I was not asked about this graphic at trial, much to my chagrin.

Page 11 of Det. Osborne's Computer Forensics Report

I have not spoken with the attorneys, since the verdict. Jeff Ashton’s last day with the prosecutor’s office was the day the verdict was rendered. He’s been waiting for the trial to be over, so he could retire. He’s put in his 30+ years and was ready to retire. Of course, the media made it sound like he was a bad sport and quit because he lost; not true. He stayed on longer than intended to finish working this case. I know that all the evidence was discussed at length by counsel and the judge prior to the trial. It was decided that we would not be permitted to overkill the “bad girl” bashing, so I think a lot of the evidence was either not allowed by the judge, because it was too prejudicial, or it was stipulated to by both parties. I’m not sure what the jury was permitted to see other than what was published to them in court, but it is clear they didn’t review much, if any, evidence during deliberations. They simply didn’t have time and they returned their verdict within hours of closing arguments.
Sgt. Stenger was asked to conduct a live demo search of a spreadsheet during one his trips to the stand. The technical computer operator in the courtroom actually did the search, so all Sgt. Stenger had to do was direct him where to go inside the document, but this was highly unusual. When you are used to working the mouse yourself, you know how hard it is to watch someone else do it for you. Live demos that have not been rehearsed are a bad idea. Fortunately, this one turned out rather well, but Sgt. Stenger wasn’t happy about it.
Jurors are typically not technical people. The evidence you present must be easily understood and over simplified or else you will lose their attention. We had one juror on our panel that had some IT experience and we picked him out right away. If my testimony in the Anthony case seems very elementary, that’s because I had to talk in language that my prosecutor understood and that translates to language that the jury can follow. It seems counterintuitive to not dazzle the court with all your brilliance, but they don’t want to hear it, honestly, and they won’t understand all the techno-speak. Keep it simple and in terms that they can relate to and you will be more successful.

DF Source: What advice do you have for the digital forensic student or new digital forensic examiner?

SO: My advice is never, ever work late in the lab. Nothing good could come of it.

#1. Complete any unfinished education or degrees in progress as soon as you can. I have 4 classes to go to get my BA. I really don't like the fact that I only have a 2 year degree to come to court with. Git R'Dun!

#2. Compile a CV that you are proud of.  Practice testifying with it and bring it with you every time you go to a deposition or to court. Provide a copy to your prosecutors as well. I have provided a paper that I wrote that explains how to complete a CV.

#3. Read and study your agency policy describing your job description. Also read the description from the certifying body where you received your forensic certification. Practice this for testimony; it works! If you aren't certified, I strongly suggest you check into it. I know some people are opposed to belonging to a single organization and they float around. That's okay, but consider what your resume sounds like to a lay person who doesn't know you or your profession. Also consider your opponent who will be making every attempt to discredit your training and qualifications. If your studies and work product have never been peer reviewed by another computer forensic professional, than how do you know your work product is good and who will speak up for you, if you don't belong to any professional organizations? Even with minimal credentials, I was able to explain to the court that I successfully completed a rigorous certification process that tested and validated by knowledge, skills, and abilities in the computer forensics arena.

#4. Take your work seriously and study like your livelihood depends on it. Do work that you are proud of and learn from yours (and others) mistakes. No one knows everything there is to know about this work. We must depend on each other to share information and work together. As cops, we tend to be loners, but this is different. We network together and share our findings with others.

#5. Take every opportunity to teach others about what you do. It will help solidify your own knowledge and you will become very comfortable testifying as well.

• Computer Forensics Report (08-069208 Case Report.doc)

• Press Release regarding CacheBack from State Attorney's Office (CacheBack errors 7.19.11.pdf)

• White Paper Curriculum Vitae (submitted by Det. Sandra Osborne) cited from http://jobsearch.about.com/od/cvsamples/a/cvtemplate.htm ; “Cirriculum Vitae Template”, by Alison Doyle, About.com Guide)