Every time I am preparing for testimony at deposition or trial, I ask the attorney I am working for whether I should make it “easy” or “hard.” Even very experienced attorneys examining a technical witness often ask the wrong question. In a recent exchange during cross-examination at trial, the issue was whether the opposition’s client had altered a hard drive, rendering it inaccessible by a prior computer forensics expert. The opposition attorney first asked about a particular type of disk encryption. In the follow-up question, the attorney changed the hypothetical and did not specify the supposed encryption mechanism. When he confronted me claiming I had changed my answer, I simply explained that no, he had changed the question. When dealing with technical testimony, seemingly minor details in how the question is asked can alter the answer you receive.
If you ask questions regarding a particular folder in a non-Windows environment and describe it with “backslash” instead just “slash,” you may get an unexpected answer. In a transcript of the deposition of a system administrator I saw, an attorney did not initially pick up on the confusion of the technical witness. In other operating systems, like Linux, the folder paths use the keyboard character that leans to the right instead of the backslash, which leans to the left. The witness, as a technologist, could not answer the question as it was asked. Being an inexperienced witness, he did not explain properly the source of his problem. When I am providing expert testimony and encounter such an issue, I fall back on the instructions I got from the attorney defending my deposition: I could simply explain that the examining attorney probably meant forward slash in the folder path and proceed to answer the question with that assumption. But if it is a more adversarial situation, I may simply say I cannot answer the question as asked.
Slash versus backslash is a simple example; most often, technical issues surrounding computer forensics revolve around interpreting more difficult issues. When was a file created? Was data transferred out of a company’s environment? Was a destructive program installed and when? Keying off an expert’s wording in a report or declaration or listening to how a witness describes a technical issue may help you be better prepared to examine that technical witness. Picking up on the fact that a witness calls an item of evidence Windows event logs for a print server will avoid any stumbling when the witness gives a negative answer when asked about his review of print logs. Essentially you would be referring to the same thing, but to a technologist, event logs are not the same as print logs. Writing an expert report or providing technical testimony, a non-technologist can understand and still being accurate are always a challenge. At some point, however, a technical witness has to err to the side of being technically correct rather than oversimplifying an issue for an examining attorney to understand.
Since I left the government in 1999, I have worked on hundreds of civil litigation cases as a consulting expert. I have provided declarations, affidavits and expert reports for over 200 cases. I testify in a handful of cases each year. However, I do not know at the outset which cases will ultimately involve testimony regarding the computer evidence we review. The tools we use, the protocols we follow and the results we report must always stand up to scrutiny by an opposing expert or examination by an opposing attorney. In opposing other experts, I look for instances where the data they reviewed does not support their conclusions. Often it is a bit of a tug-of-war with the client attorney to stick to the opinions we can support and not overreach.
I worked computer intrusion cases as the case agent and the technical lead. If you were fortunate enough in your investigation to trace the bad activity back to a fixed location, you still had to document who was at the keyboard. In a case involving a dispute over the publication of defamatory statements using an anonymous, free web-based email account, the opposing expert traced certain email messages to a wireless access point. Although the opposing expert had done good work in the analysis it took to get to that point, his mistake was identifying in his report who had sent the message without sufficient data to support that conclusion. He did not put the purported sender of the email at the keyboard, so his testimony was weakened.
In the last article in this series, I will explore how to decide if your computer expert is a good fit. I will explain how, as the field has grown, we now frequently encounter practitioners coming into computer forensics from various specialties. Your expert may have IT experience, law enforcement computer forensics experience, corporate computer security or other technical experience. Make sure your testifying expert has experience in the specific technical issues pertinent to your case.
As I write this, I have been preparing for the deposition of an opposing expert designated to testify about the creation of a document originating in a Linux environment central to a matter. Linux is a popular alternative to the Windows operating system for servers and occasionally workstations in certain, usually development, environments. As I reviewed his resume and the example cases he listed, I realized he seemed to only have worked on issues involving Microsoft Windows. In assisting my client for examination of this expert witness, I wrote a series of questions reviewing the expert’s work experience geared to eliciting information about what I expected to be his lack of Linux experience. As it turned out, the opposing expert was de-designated at the last minute. The opposing attorney must have realized the same weakness I did.