 |
| 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 |
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)
No comments:
Post a Comment