Wisconsin
Lawyer
Vol. 81, No. 2, February
2008
Thinking Outside the "Business Records" Box: Evidentiary
Foundations for Computer Records
The foundation for introducing computer-generated records into
evidence is different than that for the familiar business records
exception, but it is not necessarily more difficult. Read how the
process works, establishes authenticity, and produces reliable results.
Sidebar:
by Timothy M. O'Shea
he "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.
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.
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.
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.
Foundational Checklist
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.
Conclusion
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.
Endnotes
Wisconsin
Lawyer