Using evidence effectively

getting the whole picture “Firewall vendors need to improve filtering capabilities to shore up their network when dealing with multiple Web services because when connecting these Web services up in various ways it's really hard to know whether or not a hole has been left which, when the next Web service is plugged in, will expose information and compromise it”, he added. Also, because Web services software consists of reusable components, when several are threaded together it is hard to know whether they all follow the same rules, or operate in the same environment or whether one might accidentally provide information externally. “So then the challenge is you need to apply policy, or provide guarantees that

you can do high level security functions like authentication in some consistent fashion, or determine that you can only get access to various types of transactions or records under different criteria. So large scale going forwards is challenge and the opportunity in this space is how to manage this set of Web services, is not the only issue but it is the most significant one. How do I provide a sufficient high level of security that my IT administrator or CIO is happy to say yes, Web services are safe to use so they can start deploying them. And there is still an amount of uncertainty in this space,” advised Nash. Microsoft’s Bell identifies establishing identity as probably being the biggest missing piece in the security puzzle.

“Who do you trust to determine, validate and issue identity? And that is as much a social issue as it is an engineering issue. It is a very complex social and legal issue which I think in time will need resolving, but I don't think it will hinder the scope of people's ambitions in 2003 and 2004 [because they can use UDDI]. Beyond that I can see people would be pushing the boundaries where we need to have made progress there.” Useful urls: www.microsoft.com/Web services www.oasis-open.org www.w3.org www.ws-i.org www.cbdiforum.com

GETTING THE WHOLE PICTURE

Using Evidence Effectively

are of use to us in characterizing the event and forming a conclusion as to the source:

Peter Stephenson

• Raw data collected from logs, intrusion detection sensors, etc. • Normalized and deconflicted data derived from the raw data. • A primary evidence chain corroborated by secondary evidence.

This is a good time to digress a little and consider how we may use the evidence we have collected, normalized and deconflicted. The presentation of evidence, especially complex evidence, requires a bit of art in itself. Most experts agree that the use of graphics is usually the best way to present technical evidence to a lay jury. In the past several issues we have performed some fairly complex tasks and those tasks, difficult in some cases for practitioners, may be completely incomprehensible to a jury. Among other tasks that we set for our- important, it is more difficult for the opposelves was the discovery of a complete sition to sow confusion when the EEDI end-to-end analysis of a set of events that, events are clear, the timeline fits and the eventually, resulted in a computer-related sequence of primary and secondary evicrime against some victim computer. dence all fits into a neat pattern. Timelines Assuming that the end-to-end digital make good visual displays as well, so the idea investigation (EEDI) is ready to present, of working from a timeline chart simplifies how should we do that? In my experi- things, both for the lay finder of fact and the ence, the best way to present EEDI evi- expert witness, and limits the likelihood that dence is the same as the easiest way (or the expert will make a serious misstep. ways) to visualize it from the perspective of the practitioner: in a sequence of events laid out on a timeline. What we have and what we There are a couple of reasons for this. need First, a lay finder of fact will have less difficulty understanding what you are trying to By the time we have completed our invesprove. Second, and perhaps more tigation we will have several things that

What we need falls into two categories: • An appropriate evidence chain that traces events from attacker to victim. • Proof that we have collected and managed our evidence appropriately. We have covered the basics on the first category and only need apply that to a timeline. Before we get to that, however, let’s examine the second one. In an earlier column I made reference to the basic framework developed by the Digital Forensics Research Work Shop (DFRWS). That framework is shown in Figure 1. The column headings show, clearly, the process while the contents of the columns depict elements of the digital investigative 17

getting the whole picture IDENTIFICATION

PRESERVATION

COLLECTION

EXAMINATION

ANALYSIS

PRESENTATION

Event/Crime Detection

Case Management

Preservation

Preservation

Preservation

Documentation

Resolve Signature

Imaging Technologies

Approved Methods

Traceability

Traceability

Expert Testimony

Profile Detection

Chain of Custody

Approved Software

Validation Techniques

Statistical

Clarification

Anomalous Detection

Time Synch.

Approved Hardware

Filtering Techniques

Protocols

Mission Impact Statement

Complaints

Legal Authority

Pattern Matching

Data Mining

Recommended Countermeasure

System Monitoring

Lossless Compression

Hidden Data Discovery

Timeline

Statistical Interpretation

Audit Analysis

Sampling

Hidden Data Extraction

Link

Etc.

Data Reduction

Spatial

Recovery Techniques

Figure 1: Basic Framework for Digital Investigation process (DIP). As there is not yet a universally accepted model for conducting a digital investigation, we believe that the DFRWS model makes a good starting point. The first step in establishing that we have collected and managed our evidence is to establish that we have followed the guidelines of the Process. For example, how did we identify the event itself and begin the process of collecting evidence (Identification)? Did we maintain chain of custody, time synchronization, between various evidence sources (or, if not, can we account for the differences) so as to ensure that timelines are consistent and reasonable (Preservation)? Did we use approved hardware, software and techniques with properly trained evidence technologists to collect evidence, image hard drives, etc. (Collection)? How did we examine and analyse the evidence? And, through all of the examination and analysis did we preserve the chain of custody and is each step of our evidence chain traceable, both as evidence (corroboration) and technique (preservation)? If we perform the DIP appropriately the only debate is our interpretations of the evidence. Establishing that we followed the process, however, is fraught with challenges. The primary challenge is that the digital forensic discipline has yet to be brought into the realm of science. The 18

overarching concepts of scientific principles have only recently begun to be applied to the digital investigative process and we will, in a future column, discuss that aspect in detail. For now we will, simply, stay within the DFRWS process and make the assumption that such is sufficient for our purpose. Our next steps are to organize our chain of evidence into its logical order and present it as a coherent timeline. This is a good exercise for the investigator as well since it aids in ensuring that each step of the event is supported by evidence and that evidence is appropriately corroborated.

Developing the timeline and chain of evidence As we have been collecting, examining and analyzing evidence, we should have been developing a theory of how the attack took place. This is an opportunity to apply science as opposed to engineering. As Dr. Eugene Spafford puts it:

“Engineers build things and then create theories to explain them. Scientists create theories and then build things to prove the theories”.

We must, assuredly, take the later stance. We must, as seasoned investigators say, “go where the evidence leads”. We must create our theory of how the event occurred and use the evidence to prove our theory. If the theory doesn’t stand up to the evidence, we must change our theory. That sounds easy and sensible, but, in practice, it can be very difficult even for experienced investigators to abandon a pet theory when the evidence doesn’t support it. From a practical perspective you probably can expect to change your theory several times before it fits all of the facts. Once we have established the opening bit of evidence that indicates an event has occurred (Identification) we need to begin our evidence collection process. As each new piece of primary evidence falls into place, we must collect supporting secondary evidence. There will be gaps in our evidence chain, certainly at the beginning of the investigation, but, perhaps, as we near its end. That can pose problems and we will attack the whole issue of back tracing in a future column or two. As network technologists know, back tracing can be a very hard problem. Gathering and processing evidence requires that we maintain traceability. As I alluded to earlier, there are two aspects to traceability. First we must be sure that our

getting the whole picture evidence collection, management and analysis techniques are traceable to approved techniques, using approved tools in the hands of an experienced and trained technician. Second, we must establish traceability through the evidence chain. If each piece of evidence does not lead logically to the next, we cannot establish a chain of events supported by facts. I have found that a good approach is to consider several plausible hypotheses for the event and discredit them until you reach a supportable conclusion. I have had up to a dozen plausible theories for a complex event. By applying the facts as they develop we winnow those theories down to what most likely happened. From a purely practical approach, I use a large white board and place the theories on one side and the facts as they develop on the other. Seeing the incident laid out in that manner makes it easier to support or discredit theories until you reach the end. Once we have established what we believe actually occurred, supported both by technical and non-technical evidence (remember, we include all types of evidence, forensic or not, in the DIP) we will, probably, have some sort of tentative timeline. Conducting an EEDI implies that you have the attacker, the victim and everything in between. As we has said, often you will have trouble establishing the “in between” using forensic techniques. In this case we revert to traditional investigation. Some months back a Canadian hacker calling himself “Mafia Boy” leveled a massive denial-of-service attack against the Internet. Because of the nature of the attack it is likely that he could have escaped detection indefinitely had he not bragged in a chat room about his feat. Investigators picked that up and conducted a simple, non-technical investigation, eventually, leading to Mafia Boy’s door. It then was possible to establish the technical details of the attack and fill in the “in between” resulting in a complete chain of evidence complete with timeline, primary and secondary evidence. Don’t expect the forensics to solve the crime alone. The presentation of the evidence to a finder of fact poses additional challenges.

While the specific process differs from country to country and, in the US, perhaps from jurisdiction to jurisdiction, there always are a few things held in common. First, you will not be dealing with experts in your field. Complex issues require complex solutions and these solutions, by themselves, will likely be beyond most juries and jurists. Make that assumption going in. Never allow yourself to be drawn into the deep technical details of the events when you are under examination. These will confuse judges and juries and allow reasonable doubt to creep in. When asked, for example, “How do you know that the event you are describing occurred?” it would be a risky response to dig into the technical issues that make up your evidence. A better response would be along the lines of, “We used approved techniques and tools to collect, preserve and analyze the evidence.” Keeping your presentation simple is far more effective than providing all of the technology you used to draw your conclusions. Remember that, more than likely, you will have a complete, detailed report and that will probably have been introduced into evidence. In the United States there is the potential for what is called a “Daubert Hearing”. This comes from the case of Daubert v Merrell-Dow Pharmaceuticals (509 US 579, 1993 ). There are four “Daubert tests” that the court may apply to the scientific techniques claimed in an investigation and the subsequent development of evidence:

However, even in the US, digital forensics has not reached the level of science where Daubert hearings are common. In other countries, such as the UK, such technical evidence may be presented to a neutral third party specialist for his or her expert testimony on its validity. In any case, reducing the investigation to a simple timeline and chain of evidence, supported by accepted processes such as the DFRWS model, is the best approach. One final note about timelines: they may depend for their credibility upon time synchronization between evidence sources. Since it is unlikely that you will find time synchronization between disparate evidence sources, you will need to establish the likely time gaps and be able to satisfy the court that your efforts are credible. There are several ways to do this and I leave it to the investigator to select the one appropriate to a particular investigation. Broadly, however, they fall into two categories:

1 Whether the theory or technique in question can be and has been tested. 2 Whether it has been subjected to peer review and publication. 3 Its known potential rate of error along with the existence and maintenance of standards controlling the technique’s operation. 4 The degree of acceptance within the relevant scientific community (may not be the only means to examine expert testimony as in Frye v. US). These Daubert hearings are conducted outside of the hearing of the jury and can be very technical in nature. This is where your technology will be examined by experts and you may present technical arguments.

Conclusions

• Synchronization of all times to a common source such as GMT. • Synchronization of all times to a selected time on a particular evidence source within the investigation. In either case you will need to establish the average difference (“delta”) between the times of each piece of evidence (logs, sniffer traces, etc.) and the standard you select

In this column we have seen how to take the evidence we have collected and apply it to a coherent chain of events depicted as a timeline. We have noted that we should keep our evidence presentation simple without being simplistic and we ended with a caution regarding time synchronization. In our next column we will begin the difficult task of back tracing.

About the Author Peter Stephenson is the director of technology services for QinetiQ Trusted Information Management, Inc. 19