Forensic engineering (FE) practice is affected by the increased involvement of computer technology and computer-resident evidence (80+% and rising). This has a significant impact on most forensic engineering practice specialties. Specific recommendations and guidelines are provided to assist the forensic engineer in adapting his or her practice to this technology.
Forensic Engineering, Electronically Stored Information (ESI), Computer Evidence
INVOLVEMENT OF COMPUTERS AND FORENSIC PRACTICEJust as modern life is increasingly dependant on computers & software - both obvious and hidden - forensic engineering practice is also affected.1 One example of this is the fact that over 80% of all evidence is now computer-resident in some or all of its existence. In fact, the recently updated Federal Rules of Civil Procedure (FRCP) have created a new term - ESI - for Electronically Stored Information. This cumbersome term accommodates the fact that some digital storage media (e.g., DVDs) are optical but the processes used to create it and access it are still electronic. An earlier NAFE paper2 treats the impact of the new FRCP in more detail.
Examples of impacts on FE practice:
Some aspects of litigation involving computers & software
- Since evidence is largely computer-resident, computer tools and some software skills are required for even basic understanding. These may be as simple as word processors, spread-sheet (SS) programs and email client applications, but the needed skills may be insufficient when large volumes or legal maneuvers from opposing lawyers become a factor.
- Some of the computer-resident evidence may require highly specialized skills and complex software not readily available. A common example is when essential design documents are contained in AutoCAD files which can only be fully examined with the AutoCAD software by an experienced specialist. Similarly, the computational basis for designs in many, if not most engineering specialties, are dependent on the use of complex software toolsets such as those offered by the MathWorks company. Modern FE practice can expect to encounter this type of evidence at any time.
- ESI evidence handling must respond to the fact that the data itself is effectively invisible without computer assistance. This fact imposes new burdens on the preservation of evidence from accidental or deliberate corruption of the content. The courts have also established rules for chain of custody practices and use of fully qualified software tools, but these are not consistently enforced because of their unfamiliarity. This problem can be viewed as "Software - CSI" as in the popular TV show.
ESI Evidence - Software-CSI
- The new Federal electronic evidence rules are mandatory after 12/01/2006. This effectively establishes the rules for all courts with some local variations.
- The sheer volume of computer-resident evidence may require automated support. It is not unusual to be presented with gigabytes or more of data in various forms. This translates to tens or hundreds of thousands of artifacts - documents, emails, project records, SS files, etc. Sometimes it is presented in a room full of boxes of paper, which is often just a means of harassment by the opposing lawyers. Conventional means of treating this volume of data manually are not effective.
- Often, the key evidence is computer resident but may be deleted, fragmentary or available only in archived records. The FRCP supplies guidelines for dealing with this type of evidence. This historical sequence is often best expressed in a time-line diagram which shows both the sequence and the parallel series of events which can be an important way of showing causeeffect relationships. An example of a diagram which expresses several different sequences on a common time-line is shown in the Chronology of Issues diagram.
- Increasingly, important parts of large projects contain computer-intensive components such as individual embedded controllers, networked control systems in large building HVAC systems, power management, etc. If this component system can be critical to the larger system, the software specialist for that field may be required to establish inter-disciplinary obligations for computer-intensive interfaces.
- Evidence handling is separate from e-discovery. Evidence handling procedures preserve and protect the invisible evidence and apply to both sides.
- E-discovery is the electronic version of what the client lawyer will demand from the other side in the course of litigation. It is often true that the wording of the subpoena which spells out the discovery demands should contain specific technology details which define the needed data in a manner which is unfamiliar to the lawyer. The FE may need to educate client counsel about this specialized evidentiary data.
- The FRCP has a newly-required procedure that the two parties must follow before seeking direction from the court. E-discovery often involves complex types of data and the court expects a good-faith effort to resolve discovery details before seeking court assistance.
FE PRACTICE - DOING THE WORK
Dealing with Gigabytes
Making technology issues understandable to the court
- Size matters. The engineering of a large-scale project always involves different technology. Building a ten-story building must be treated differently than a simple addition to a one-story residence.
- Finding the critical evidence in gigabytes (i.e. billions of characters) of data is the key initial step but usually consists of an on-going process. This process catalogs and organizes the data in a manner which facilitates automated support for key word searching, timeline construction, graphical exhibits, etc. Often the document catalog is maintained in a SS file so that various searching and sequencing processes can be employed to identify relationships. SS applications also support many forms of graphical representations to facilitate preparation of courtroom exhibits.
- Often the printed evidence is scanned into PDF files and then OCR converted to enable electronic searching of the content.
- This organized data is then analyzed in order to identify the key facts relevant to the dispute.
Example Wording for E-Discovery Subpoena
- Making technology issues understandable to the court is typically more difficult with computer-resident evidence because of its volume and complexity.
- The forensic engineer must ultimately make the resulting opinion understandable to the court. This is termed "teaching the court", which is particularly important for jury trials.
- The teaching often consists of two elements -
- Establishing a technology foundation by defining and explaining selected technical terms and critical issues which must be understood to some degree.
- Constructing a narrative which explains the historical sequence of events in order to provide a context for the selected technical facts defined in the 1st step. This historical sequence is often best expressed in a time-line diagram which shows both the sequence and the parallel series of events which can be an important way of showing causeeffect relationships. An example of a diagram which expresses several different sequences on a common time-line is shown in the Chronology of Issues diagram.
- The teaching is often aided by the use of familiar analogies. For example, translate a complex technical event into a similar business transaction.
- Separate a 2 - 5 page Summary Opinion from the fully substantiated Analysis report with annotated references. This avoids MEGO (My Eyes Glaze Over) before the critical points in the opinion are assimilated. The availability of the detailed Analysis then provides the necessary proof without losing the reader in the details.
Client counsel will incorporate the following language as he sees fit in his discovery subpoena but the FE must ensure that the language includes any specialized data relevant to the technology issues.
Example Case Summaries
- Produce all information relating to Project X for the dates XX to YY
- Relevant information includes all project staff email communications inclusive of attachments for the period specified. Email is to be produced in native file format whenever available.
- "All information" includes any data with relevance to the dispute and includes databases, specialized design or project history data, etc.
- Produced data is to be provided in native file format in accordance with the FRCP.
- If ESI, metadata must be included and all relevant contextual data (such as file format, date created, and date last modified) must be included for specialized files.
- The expert team analyzed project records from a failed software development which supported insurance policy rating and issuance for an underwriter client. The system was intended to replace several legacy processing systems with an integrated system implemented with modern web-based technology. US-based supplier employed off-shore software developers and then the USA-based portion of the supplier failed to adequately manage the off-shore developers and maintain system quality. The result was that the system was virtually unusable because of critical content errors in policies and constant breakdown. Late in the dispute, a key document was discovered by the team's structured data management process which documented a confidential internal technical review by the opponent's senior staff. This document supported the main points in our expert opinion and had been overlooked by both sides. This key document was incorporated into the written opinion and presented to the opposing legal team for the first time during our expert deposition.
- Reviewed discovery and operational data from large-scale railroad operations in support of a disputed air quality management district regulatory ruling. The new ruling was alleged by the railroads to be unduly burdensome and might compromise safety of operations. Analysis showed that the reporting required by the new regulations was available from existing operational data collections. Demonstrative examples using last minute sample data from both railroads showed that the regulatory reporting could be readily accomplished at minimal cost and impact, and could even result in substantial fuel savings. Opinion was defended by deposition and testimony in Federal court.
- Analyzed project records and derivative content of large software system developments used in banker client's operations. Dispute involved issues of ownership of software developed and/or enhanced by subcontractor who was the opposing party. Analysis revealed that the disputed software was largely derivative of earlier systems used by the bank which predated subcontractor's involvement. Also found clear evidence of improper submission by subcontractor to the US Copyright Office of client's software. Testimony was given in deposition and in two days of courtroom testimony before a jury.
- Analyzed history of accident, examined pleadings, records and depositions relating to an industrial accident on a large-scale, computer-controlled dredge. Insured was a control systems/software developer contracted by dredge operator who is a co-defendant in suit to compensate for injuries suffered by worker. Analysis showed that a significant contribution to the computer control failure leading to the accident was incomplete software testing practices by the predecessor software developer combined with poor design choices in the control wiring between the dredge's subsystems.
- Computer technology is involved in most litigation.
- The trend is that this will increase over time.
- Some computer skills will be required in most cases requiring forensic engineers.
- Dealing with the complexity usually involves a variety of computer toolsets
- some requiring specialized expertise.
- Organize the data produced.
- Establish structures supported by automated toolsets.
- Interpret the meaning.
- Teach the court.
- Cosgrove, John, Software Engineering and Litigation, Encyclopedia of Software Engineering, Volume 2, Second Edition, John Wiley & Sons, Inc. December 2002
- Cosgrove, John D., Forensic Engineers and the New Federal Rules Regarding Electronically Stored Information (ESI), Journal of the National Academy of Forensic Engineers (NAFE), vol. XXIV, No. 1., June, 2007
- Margaret Chock, PhD, M. I. B. Chock, LLC
John Cosgrove, P.E., has been a software engineer for over 40 years and a self-employed consultant for more than 30. His specialties include forensic engineering, project management, software architecture, real-time critical systems, and hardware-software interfaces.
©Copyright - All Rights Reserved
DO NOT REPRODUCE WITHOUT WRITTEN PERMISSION BY AUTHOR.