forensics - computer forensics guide 11-01

7/29/2019 Forensics - Computer Forensics Guide 11-01

1/4

ITL Bulletinsare published by theInformation Technology Laboratory(ITL) of the National Institute ofStandards and Technology (NIST).Each bulletin presents an in-depthdiscussion of a single topic of significantinterest to the information systemscommunity. Bulletins are issued onan as-needed basis and are availablefrom ITL Publications, NationalInstitute of Standards and Technology,100 Bureau Drive, Stop 8901,Gaithersburg, MD 20899-8901,

telephone (301) 975-2832. To beplaced on a mailing list to receivefuture bulletins, send your name,organization, and business address tothis office. You will be placed on thismailing list only.

Bulletins issued since June 2000

Mitigating Emerging HackerThreats, June 2000

Identifying Critical Patches withICAT, July 2000

Security for Private BranchExchange Systems, August 2000

XML Technologies, September 2000

An Overview of the Common CriteriaEvaluation and Validation Scheme,October 2000

A Statistical Test Suite for Randomand Pseudorandom NumberGenerators For Cryptographic

Applications, December 2000

What Is This Thing CalledConformance?January 2001

An Introduction to IPsec (InternetProtocol Security), March 2001

Biometrics Technologies For Highly

Secure Personal Authentication,May 2001

Engineering Principles forInformation Technology Security,June 2001

A Comparison of The SecurityRequirements for CryptographicModules In FIPS 140-1 AND FIPS140-2, July 2001

Security Self-assessment Guide ForInformation Technology Systems,September 2001

November 2001

Continued on page 2

COMPUTER FORENSICS

GUIDANCE

By Gary E. Fisher, Software Diagnosticsand Conformance Testing Division,Information Technology Laboratory,National Institute of Standards andTechnology

Introduction

NISTs Information Technology Labo-ratory has two ongoing researchprojects in computer forensics: theNational Software Reference Library(NSRL) project and the ComputerForensics Tool Testing (CFTT) project.Funded through NISTs Office of LawEnforcement Standards (OLES) by theNational Institute of Justice (NIJ), theFederal Bureau of Investigation (FBI),the Department of Defense Com-puter Forensics Laboratory (DCFL),the Department of Justices TechnicalSupport Working Group (TSWG), andNIST, these projects are designed toprovide research into the efficient andeffective use of information technol-ogy applied to computer forensics.

The NSRL provides a set of reference

data that can be used to reduce thenumber of files that have to bereviewed or examined during aninvestigation. This can significantlycut down on the amount of timerequired to gather and verify evidencein crimes involving computers.

The objective of the CFTT is to pro-vide a measure of assurance that thetools used in computer forensicsinvestigations produce accurateresults. Since the computer forensicsarena is relatively new in terms ofcomputer history, there are few stan-

dards available to define how thesetools should operate and perform. Thetask of the CFTT is to develop specifi-cations and test methods for thesetools. The results provide the informa-tion necessary for users to makeinformed choices about acquiring andusing computer forensics tools.

ThisITL Bulletin presents some of theresults of the work on these twoprojects and provides recommendationson how the results can be applied.

The National SoftwareReference Library Project

A single desktop computer can con-tain 25,000 to 100,000 stored files. Alarge percentage of these files areprogram executable files, library files,compressed files used to install appli-cations, operating system files, etc.On a specific computer, these filescan make up from 25 percent to 95percent of the total number of files.Reviewing these files for evidence cantake hundreds of staff-hours. In most

cases, these files do not contain evi-dence, but without some automatedprocess to assist in the review pro-cess, an investigator must review eachfile and make that determination.

The objective of the NSRL is to pro-vide a foundation for automating theexamination process by separatingthese files into those that are relevantto the investigation and those that arenot. This is accomplished by comput-ing a unique identifier for each filebased on the files contents. Theseidentifiers can be used as file signa-

tures or fingerprints for the associ-ated files. The identifiers can then becompared to entries in a database ofknown fingerprints. If a files finger-print matches one in the database, itis a known file and can be eliminatedautomatically from examination. If thefingerprint does not match anythingin the database, then the file isunknown and should be examinedfurther. How this process is accom-plished is described below.

NIST has been collecting softwarefrom various sources over the past 18

months. This software is recorded asthe original source for known files andstored as a permanent part of theNSRL. The software in each package isstored on CD, diskette, magnetic tape,or other electronic storage medium.For example, one CD may contain afull implementation of an operatingsystem. Another may contain a newerversion of the same operating system.Other packages contain database


2/4

2 November 2001

management software, photo editors,word processors, image libraries, net-work browsers, compilers, accountingpackages, and many other types ofsoftware. The concept is to collect asmany different examples, versions, andupdates of software as possible in

order to generate file signatures for asmany known files as possible.

Each file within a package, whichmay contain many thousands of indi-vidual files, is fingerprinted by pass-ing the file through a program thatcomputes a hash code. A hash code isa large number computed from theentire string of bits that form the file.The hash code is computed in such away that if one bit in the file ischanged, a completely different hashcode is produced. To minimize thepossibility that two different files may

generate the same hash code, a suffi-ciently large hash value is computed.

The primary hash value used in theNSRL Reference Data Set (RDS) is theSecure Hash Algorithm (SHA-1) speci-fied in Federal Information ProcessingStandard (FIPS) 180-1. SHA-1 is a 160-bit hashing algorithm, meaning thatthe hash value derived from the algo-rithm is 160 bits in length. The proba-bility that two different files willproduce the same SHA-1 value is 1 in1080, a very small probability. Several

other standard hash values also arecomputed for each file. These includeMessage Digest 4 (MD4), MessageDigest 5 (MD5), and a 32-bit CyclicalRedundancy Checksum (CRC32).These allow the SHA-1 values to becross-referenced by other products

that depend on different hash values.Additionally, this further ensures thatno two files will have the same set ofhash values. The hash values, filename, file size, and information iden-tifying the source of the file are storedin the RDS. A separate, parallel, andindependent process is used to vali-date the results of the primary RDSimplementation. This ensures that thehashes computed can be verified toidentify specific files in the RDS. Onceverified and validated, the RDS iswritten to a master CD, duplicated,and distributed through NISTs Stan-

dard Reference Data Office as SpecialDatabase #28 (http://www.nist.gov/srd/nistsd28.htm).

When a computer hard disk, CD, orother storage medium becomes part ofan investigation, the files stored on itcan be fingerprinted using SHA-1,MD4, or MD5 through separate soft-ware that may be acquired from othersources. These fingerprints can be com-pared to the known file fingerprints inthe RDS. Those files that have matchinghash values can be discarded from theinvestigation without further examina-

tion; those that do not match the data-base should be examined further.

Uses of the Reference DataSet

There are several ways in which theRDS can be used depending on thegoal of the investigator. Foremost isthe highlighting of unknown files ona subject computer. Appropriate soft-ware can provide a list of files fromthe subject computer with file signa-tures that do not match any signaturesin the RDS. An investigator can then

review each of these unknown filesfor evidence while discarding theknown files without having to reviewthem. In test runs, the RDS has identi-fied between 40 percent and 95 per-cent of the files on subject computersas known files, thus reducing theamount of time required for review.

Organizations are looking at the RDSfor other purposes. For example, theRDS can be used in intellectual prop-erty investigations to find pirated soft-ware on a specific computer. If thepirated software is on the computer,i.e., a specific file or set of files exists

on the computer, hash values of thosefiles will match known files in theRDS.

Alternately, a perpetrator may try tohide a pornographic image by renam-ing it as a nondescript operating sys-tem file, e.g., renaming a .JPG imageas an .EXE file. The hash valuederived from the image will not matchthat from the known operating systemfile and will thus be uncovered.

Additionally, the RDS can be used tofind camouflaged software, such asexecutable files with changed names

that may blend in with other datafiles, e.g., a .EXE file renamed with a.JPG extension. A hash value of thecamouflaged file will still match theRDS since the files contents were notchanged, only its name.

Expected files may be missing if theydo not show up in the known fileslist. This may indicate that files weredeleted to cover up illegal activity andmay prompt the investigator to pursueother means of investigating the filesystem.

The project website is http://www.nsrl.nist.gov.

Who we are

The Information TechnologyLaboratory (ITL) is a major researchcomponent of the National Instituteof Standards and Technology (NIST)of the Technology Administration,U.S. Department of Commerce. Wedevelop tests and measurementmethods, reference data, proof-of-concept implementations, andtechnical analyses that help toadvance the development and useof new information technology. We

seek to overcome barriers to theefficient use of informationtechnology, and to make systemsmore interoperable, easily usable,scalable, and secure than they aretoday. Our web site ishttp://www.itl.nist.gov/.

ITL Bulletins Via E-Mail

We now offer the option of deliveringyour ITL Bulletins in ASCII formatdirectly to your e-mail address. Tosubscribe to this service, send an e-mail message from your business e-mail account to [email protected] withthe message subscribe itl-bulletin,and your name, e.g., John Doe. Forinstructions on using listproc, send amessage to [email protected] with themessage HELP. To have the bulletinsent to an e-mail address other thanthe From address, contact the ITLeditor at 301-975-2832 [email protected].


3/4

November 2001 3

The Computer ForensicsTool Testing Project

The sister project of the NSRL, theCFTT, is designed to provide a meansfor users to determine if a specificcomputer forensics tool meets theirneeds. NIST has taken on the task ofdefining a framework for testing com-puter forensics tools. The frameworkentails defining a means for

I classifying the functional character-istics and user requirements for dif-ferent types of tools;

I specifying the details of these func-tional characteristics and require-ments; and

I defining tests that can be used todetermine if these tools meet therequirements.

Organizations can test the tools basedon these requirements and the testsdefined in the framework, andthereby have a measure of the capa-bilities provided by each tool.

As a side effect of this work, the com-puter forensics arena will also have ameans for defining different sets oftool requirements in a standard frame-

work. This framework will allow dif-ferent subject area focus groups towork in specific domains withoutduplicating effort.

Initial work on the frameworkfocused on the classification of toolsby functional capabilities. Similar or

related types of functionality weregrouped to form broad classifications.The capabilities required in a classifi-cation were defined by focus groupsof technical experts and practitionersthat use specific types of tools.

There are two focus groups atpresent: disk imaging and writeblocker. Other focus groups areplanned in the future. The tasks ofthese focus groups are to produce adetailed specification of each func-tional classification and to review testassertions based on the specification.

NIST then defines and prototypes testmethods and test cases that can beused to exercise relevant functions ofvarious tools purporting to providethe functionality required. At eachstep in the process, the set of require-ments, test assertions, test cases, andprocedures is distributed to subjectarea experts and posted to the CFTT

website (http://www.cftt.nist.gov) forcomment and peer review. Testresults will be published by theNational Institute of Justice.

Summary

The NSRL and CFTT are two projects

based on collaboration among agen-cies to bring the effective and efficientuse of information technology to thecomputer forensics arena. The NSRL isdesigned to save resources by auto-mating tedious and labor-intensivecomponents of computer forensicsinvestigations. The CFTT is aimed atdocumenting tool capabilities in a rig-orous manner. This should result inimproving the quality of these tools. Itwill give the law enforcement commu-nity confidence in, and a measure of,assurance in the results of computer

forensics tools used in investigations.

Disclaimer: Any mention of commercialproducts or reference to commercial orga-nizations is for information only; it doesnot imply recommendation or endorse-ment by NIST nor does it imply that theproducts mentioned are necessarily the bestavailable for the purpose.


4/4

PRSRTSTD

POSTAGE&FEESPAID

NIST

PERMITNUMBERG195

.S.DEPARTMENTOFCOMMERCE

ationalInstituteofStandardsandTechnology00BureauDrive,Stop8900aithersburg,MD20899-8900

fficialBusiness enaltyforPrivateUse$300

ddressServiceRequested

forensics - computer forensics guide 11-01

Documents