The "sniffer" log in the Rock County hacker case had me stumped. I could not use the business record evidentiary foundation to get the log admitted at trial, because the log was created in response to a series of computer attacks and not as part of day-to-day regularly conducted activity. Without the log, however, my prosecution case wasn't going anywhere. As described below, my resolution of the evidentiary problems in this case gave me a clearer understanding of how to lay sturdy, accurate foundations for the admission of computer-generated records.
This article addresses the foundation for records - like the sniffer log - that are created in whole or part by a process rather than a person. This category of records is much broader than most litigators appreciate: for example, bank records, telephone records, and even many business transaction records are created at least partly by a computer process. Here is a commonplace example of a record created by a process rather than a person: the cash register's computer, not the grocery store clerk, totals your purchases, figures the tax, and prints the time and date on your receipt. As explained below, records created by a process do not implicate the hearsay rules at all. Rather, laying the evidentiary foundation for such records requires a description of the reliability of the process. A comprehensive foundation checklist for computer-generated records accompanies this article. Although this case was prosecuted in federal court, the evidentiary points contained in this article apply to both the Wisconsin and the federal systems.
The Rock County Hacking Case
The hacker had worked in the computer support department for a large Rock County, Wis., parts distributor. The hacker was fired after his bosses figured out that he was the source for the serious computer malfunctions that only occurred when he went home for lunch. The hacker's bosses likened him to a firefighter who torches buildings to increase his chances for heroism, because the hacker would return from home and immediately fix the knotty and seemingly inexplicable computer glitches that had stumped his colleagues.
Foundational Checklist for Admitting as Evidence Records Created by a Process
To demonstrate authenticity for process-generated records, the proponent is required to introduce evidence that describes a process or a system used to produce a result and to show that the process or system produces an accurate result. How much detail the proponent should provide depends on the complexity or familiarity of the record at hand. The foundations for many computer-generated records will not require the proponent to cover each point noted in the comprehensive checklist below.
1) The improbability that the records have been altered, which may include:
the chain of custody for the evidence;
the internal and external security built into the system and the security procedures in place;
how changes in the database are recorded and how this information shows that the records have not been altered;
how the records were produced, in particular whether the records were printed or relied upon before litigation; and
if the records were obtained pursuant to a forensic process, an explanation of how the records were duplicated and analyzed.
2) The completeness of the record:
how the data is input into the computer – whether complete data was fed into the process (for example, check kite or tax record analysis);
processing – what the computer and program are asked to do; and
output – how the record is retrieved from the computer.
3) The reliability of the computer program and equipment:
whether the program and equipment are used routinely;
absence of prior problems;
ability of hardware/program to detect errors;
whether the equipment is regularly checked;
whether the program and equipment produce a testable result; and
- whether the output is routinely verified:
- automatically as part of the program;
- by a complementary system that would not work if errors occurred in the program or equipment producing the proposed record; or
- by other external controls.
By 9:30 on the morning that the hacker was fired, corporate security guards had escorted the newly-unemployed hacker, cardboard box of personal effects in hand, to his car. Simultaneously, the computer support supervisors disabled the hacker's computer system passwords. In less than an hour, however, the hacker was back in his ex-employer's computer system. Over the next 10 days, the hacker used his former colleagues' passwords to repeatedly hack his ex-employer's computer system: intercepting email, deleting critical databases, and turning off the virus protection system.
To identify the intruder, one of the hacker's former colleagues installed a sniffer program to monitor traffic through a certain system port - a computer communication channel - that the hacker had used to mount his attacks. The sniffer program created a log - analogous to a surveillance video - to record activity through the port. It worked. The hacker returned to the same port to resume his attacks against his former employer's computer system. The sniffer program recorded the hacker's commands to the computer system and the computer's automatic responses to those commands. The sniffer program also captured the hacker's Internet Protocol address. The address information showed that the hacker was using an Internet connection associated with the hacker's home. A search warrant executed at the hacker's home resulted in the recovery of a networked computer system. After a careful analysis by computer forensic experts at the Wisconsin Department of Justice (DOJ), the hacker was indicted in federal court and his case was set for trial. Confronted by the discovery of damning evidence that the hacker had hidden in a "virtual machine" - in this context, a file hiding a separate operating system with associated programs - within his computer, the hacker pleaded guilty on the eve of trial. The district court sentenced the hacker to federal prison and ordered him to pay full restitution.
In addition to the evidentiary aspects, three practical considerations concerning this case should be noted by lawyers who advise business clients. First, by calling law enforcement, the parts distributor was able to specifically deter the hacker - at a minimum, during his prison and supervision terms. Second, the local police and the Wisconsin DOJ forensic experts proved effective during the investigation, the computer seizure, and the analysis. Third, all press releases in the case were issued after consulting with the parts distributor's corporate counsel. These factors resulted in the business being accurately portrayed as a good corporate citizen and in accountability for the hacker.
The Foundation Used for Computer Records
Many courts have categorically determined that computer records are admissible under the hearsay exception for records of regularly conducted activity - more commonly known as the business records exception - without first asking whether the records are hearsay.1 This view, however, is changing as litigants and courts better understand how different types of computer data are created. As explained below, computer-generated records are not hearsay at all. As a result, the familiar business records foundation is an inadequate basis for introducing these records.2 True business records within the hearsay exception are records made reasonably close in time to the recorded event, by a person with knowledge of the regularly conducted business activity, so long as it was regular practice of the business to make that report.3 Thinking of computer-generated records as hearsay starts a person off on the wrong foot. Such records are not created by a person, but by a computer process, and so are not hearsay at all.
Three Categories of Computer Records
Three types of records are stored in computers: 1) those that record assertions of persons (hearsay); 2) records resulting from a process (nonhearsay); and 3) records that are mixed or partially hearsay. Examples follow.
Hearsay. These are records in computer storage that contain assertions, such as a personal letter, a memo, accounting records, and records of business transactions input by persons (for example, hotel or airline reservations taken over the telephone).
Nonhearsay. These are records created by a process that does not involve a human assertion, such as telephone toll records, cell tower information, global positioning system (GPS) data, automated teller machine (ATM) and electronic banking records, Google search logs, and log-in records from an internet service provider (ISP) or Internet newsgroup. Although human input - dialing a phone number or punching in a PIN - triggers some of these processes this conduct, as explained below, is a command to a system, not an assertion.
Mixed Hearsay and Nonhearsay. These records are a combination of the first two categories, such as email containing both content and header information; documents in which the dates of file creation, last modification, and last access are important; chat room logs; and spreadsheets with figures that have been typed in by a person, but the columns of which are automatically totaled by the computer program.
The three categories require different evidentiary foundations. When sorting out the foundational requirements, the first question is whether the record, in whole or in part, implicates the hearsay rules.
The Hearsay Rule
Wis. Stat. section 908.01 provides that "`[h]earsay' is a statement, other than one made by the declarant while testifying at the trial or hearing, offered in evidence to prove the truth of the matter asserted."4 A "`statement' is (a) an oral or written assertion or (b) nonverbal conduct of a person, if it is intended by the person as an assertion."5 The main point here is that the hearsay rules apply to statements made by persons, not machines.
Timothy M. O'Shea, U.W. 1991, has been a prosecutor in the U.S. Attorney's Office in Madison since 1991. He has been the designated Western District of Wisconsin computer crime prosecutor since 1995 and has been senior litigation counsel for the office since 2002. O'Shea's views do not necessarily reflect the official position of the U.S. Department of Justice.
The Wisconsin Rules of Evidence do not define assertion. However, the Wisconsin Court of Appeals has held that "an `assertion' as used in Wis. Stat. § 908.01(1) means an expression of a fact, condition, or opinion."6 Hearsay is considered unreliable for three reasons: 1) By definition, hearsay statements cannot be effectively cross-examined to test perception, memory, bias, character, and so on. 2) Hearsay statements are not made under oath. 3) The trier of fact - the judge or the jury - cannot observe the declarant's demeanor to determine credibility.
Nonhearsay records, the second category of records described above, do not record human statements but instead are the result of a program designed to process information.7 Thus, these records are not hearsay because either there is no person involved8 (for example, GPS tracking) or the human conduct is nonassertive (dialing a phone number or punching in a PIN at an ATM).9 As a result, the foundational issues do not relate to hearsay concerns - whether the declarant was truthful, biased, or has lousy eyesight or other perception problems - but instead to whether the computer equipment and software were functioning properly.10 These are questions of "authentication" under Wis. Stat. section 909.01. For readers who practice criminal law, it is worth noting that since such records are not statements of persons, the confrontation clause, and by extension Crawford v. Washington, are not implicated.11
If the Business Records Exception Ain't Broke, Why Fix It?
Since the second category of records listed above - those created without a human assertion - are not hearsay, use of the business records foundation is incorrect and inadequate. When litigants have been successful, however, introducing phone records, computer-generated receipts, cell tower data, and other computer-generated records by employing the tried, true, and simple business records foundation, they may be reluctant to conduct more accurate but also more probing inquiries into the reliability of the computer and programs.
However, as attorneys and courts learn more about computers and computer records, they will reasonably question whether particular computer records are hearsay and whether those records should be admitted solely under the business records exception. Moreover, even records falling under the business records exception are subject to challenge if the circumstances "indicate lack of trustworthiness."12 Litigants should expect that as courts learn more about computers and computer records, they will require foundations that demonstrate the reliability of the computer and the programs that created the records.13 Besides the obvious benefit of getting the records into evidence, a more informed foundation explaining what the computer or program does likely will help the finder of fact to better understand the soundness and relevance of the records.
Records in the third category described above - records that combine hearsay and nonhearsay - require that the proponent lay a foundation that establishes both the admissibility of the hearsay statement and the authenticity of the computer-generated record.
The accompanying checklist is for records that are created by a process. Admissibility of evidence is always conditioned on a showing that the matter is what the proponent claims it to be.14 To demonstrate authenticity for process-generated records, the rule requires one to introduce "[e]vidence describing a process or a system used to produce a result and showing that the process or system produces an accurate result."15
How much detail the proponent should provide depends on the complexity or familiarity of the record at hand. For example, a grocery store receipt, a bank statement, or a phone bill likely will require a very simple foundation, while more explanation likely would be needed for a log showing a hacker attack or cell phone tower data that gives information about the route a cell phone user took between cities. While the foundations for many computer-generated records will not require the proponent to cover each point noted in the checklist, the goal is for the checklist to be comprehensive.16
The concern with a comprehensive checklist is that the reader might be left with the incorrect impression that it will be very difficult to get computer-generated evidence admitted at trial. That is wrong for three reasons. First, as noted above, although the checklist is comprehensive, most electronic evidence will not require a litigant to explore every point. As with other issues of authenticity, a litigant need only produce sufficient evidence to support a finding that the evidence is what its proponent claims it is.17 After meeting this threshold, opposing arguments go to the weight, not the admissibility, of the evidence.18 Second, a challenge to authenticity of the computer-generated evidence must be based on specific concerns - mere speculation and unsupported theories will not preclude admission.19 Third, to establish the authenticity of the evidence, it often will suffice to have a lay witness testify to his or her familiarity with the computer process that produced the record and its reliability.20 One need not call a computer expert every time one wants to introduce computer-related evidence.
The checklist for computer-generated records is intended to show the reliability of the process and by extension, reliability of the information that the litigant hopes to introduce in evidence.
There is a clear conceptual overlap between the authenticity of the computer-generated information and the trustworthiness of business records produced by persons. The point with both is to show that the process employed works and produces a trustworthy result. Litigants likely will be reluctant to move away from the comfortable and familiar business records foundation. However, thoughtful analysis of the computer-generated records, and the questions necessary for admission, will show that the evidentiary foundation for introducing those computer-generated records will be different than that for the business records exception, but in the end, not necessarily more difficult.