Computer Forensics

Craig Maloney writes "Many Slashdot readers know how to secure a network, and many know how to determine if a security breach has taken place. Fewer readers, though, would know how to handle a security breach if corporate assets were involved. How would you cooperate with law enforcement when a crime has been committed on a computer?" For more questions, and the rest of Maloney's review of Warren G. Kruse II and Jay G. Heiser's Computer Forensics, read on below. Computer Forensics author Warren G. Kruse II and Jay G. Heiser pages 392 publisher Addison Wesley rating 8/10 reviewer Craig Maloney ISBN 0201707195 summary A good reference for what to do when computer crime happens

How do you get the evidence off of a computer, ensuring that it's capable of withstanding a defense lawyer's scrutiny? Maybe you would just unplug the machine and put it in storage awaiting a detective's arrival, but is that what we should do? What if the evidence is on a production server that can't be simply unplugged and put into storage? What if that evidence is slowly being erased as files are created and deleted on that server? How do you help build the case against a computer criminal? Hopefully you'll never have to worry about computer crime in your home or workplace but if you do have to worry, Computer Forensics will be an asset to your part of the investigation.

Who is this book for? Computer crime isn't simple -- it can range from damage done by simple script kiddies to corporate espionage by disgruntled employees, as well as sophisticated, multi-homed attacks by skilled crackers. Computer Forensics tries hard to cover a lot of these areas. The book includes a chapter dealing with laptop hardware, as well as ones on data hiding and encryption, and further chapters on putting evidence together and dealing with law enforcement. While these topics may be of interest to the Slashdot crowd, Computer Forensics focuses more on broad topics of interest to computer detectives faced with getting up to speed quickly with computer crimes and computer evidence gathering.

Several chapters are downright boring for anyone who has a modicum of computer experience. Finding out where e-mail is stored on Windows and Linux machines, or understanding what a root-kit is and what it does will be pedestrian for many readers. Nestled away between the necessary-but-pedestrian topics, though, are some very useful tools. The authors use netcat with tar to copy files between machines without disturbing the modification times (something I would never have thought to use). Novice users will find a wealth of tools and examples in these chapters. The tools used in the book tend toward open source and free tools, and rely heavily on Linux as the Swiss Army knife for handling file systems and files without disturbing them. Any reader should be able to put together a decent set of tools from this book.

Making it all work

Putting together a good forensic kit is all fine and good, but making sure your evidence holds up to the scrutiny of some high-powered, high-priced defense lawyer is much more important. The last chapter of Computer Forensics gives a brief introduction to the criminal justice system. The authors touch on notifying law enforcement agencies, search warrants, probable cause, interviews, subpoenas, dollar loss guidelines, and testifying as an expert witness, among other legal topics. The appendices of the book have checklists, flowcharts, and an incident report form to aid investigation and evidence gathering. These are invaluable resources for the system administrator of any public machine who needs to deal with law enforcement.

Conclusion Thinking about dealing with courts and law enforcement may not be at the forefront of any administrator's job, but it is a reality any administrator needs to think of and be aware of. Computer Forensics will at least make administrators more aware of what their legal options are, and of the form in which gathered forensic data needs to be presented as evidence. Computer detectives will find a good, if not rudimentary example of what to look for when investigating a computer crime scene. This may not be the most comprehensive book on the subject of computer crime, but it will point you in the right direction to help investigate it should it ever happen to you.

You can purchase Computer Forensics from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

SecurityFocus

[ProfaneBaby]

The security focus mailing list dedicated to forensics is also good lurking, for those interested...

http://archives.neohapsis.com/archives/sf/forensic s/

Enterprise file forensics

[Anonymous Coward]

We use Dynacomm i:scan in our enterprise and it basically does all the forensic work for us. Kinda spooky the things it can report and notify on.

Re:Enterprise file forensics

[LordDracula]

If so, do you know if the results from these forensics tools are useful and/or admissible in court?

Admissibility is not so much tied to the specific tools (though this can be an issue; more on this later) used, but the methodology used.

DISCLAIMER: I am not by any means a forensics expert, but I am doing an independent study in computer forensics in college.

That said, many of the standard *nix tools are, in fact, acceptable for court use. For example, it is extremely unlikely that you will have a challenge presented in a courtroom questioning the integrity of your forensic duplications if you used 'dd' to make the images. At least, not on technical grounds--failure to document everything correctly and completely could wind up causing inadmissibility.

I'd strongly recommend Incident Response & Computer Forensics by Mandia and Prosise (of Foundstone, Inc.). This book has a LOT of technical information, and covers the aspects of evidence handling, documentation, etc. very well.

Looking at some of the tools listed in the Knoppix STD, I can say that many of them (like fatback, foremost, dcfldd, and cryptcat) are recommended tools in the Mandia/Prosise book. I've used each of these, and they are all definitely useful. If you're doing work that must stand up in court, however, make sure you document everything you do, and never, never write anything to your suspect drive! Doing so will not only risk losing evidence, but also invalidate the entire drive as evidence. All forensic analysis should be done on either a qualified forensic duplicate or full forensic duplicate.

Time sync all your computers

[uid100]

OS level Forensics are much easier if all your computers are set to the same time.

There is no (good) exuse for not at least NTP'ing all your servers.

Transfering for forensics

[Kalak]

Rsync will do this simply and efficiently, plus it can resume transfers and also tunnel through ssh.

Also you can pipe dd through gzip/bzip2 and netcat to give you a loopback mountable, unmodifiable image that you can look at in case you want to grab the whole drive before putting it in the evidence locker.

Re:Step 1

[towaz]

I would not just kill the machine yet either. As long as you document your findings and what you do to the system (with witnesses) you can do a few things first.

On the live system you can not trust anything so a cd or other media containing your tools statically compiled to investigate are needed.

you can use dd to make a bit for bit copy of ram, pipe this through netcat to your forensics box, or cryptcat is sensitive info is on the compromised machine.
A good idea would also be to calculate an md5 checksum for the image either side of the netcat pipe to verify its not messed up.

then run lsof to check what ports are open and by what applications and pull the plug out the wall on the compromised host.

then make sure boot priority in the bios does not boot the hdd in question and run knoppix or something like F.I.R.E and run md5 on the drive, pipe it to your machine with nc and then md5 that image.

I know i missed something but am on the phone so i guess will wait to get flammed :)

A 'thank you' from the SF forensics moderator...

[sczimme]

The security focus mailing list dedicated to forensics is also good lurking

I am the moderator of the SecurityFocus.com forensics list, and agree that it is a great resource. (Al Huger is listed in the info page as the moderator; he is actually the list owner.) The list is dedicated to discussion of technical forensics topics.

The SF forensics list archives are here. A general listing of SF mailing list archives is here. Those interested in subscribing to the forensics list (or other lists @SecurityFocus) can do so from the archive page.

Cheers!

Scott C. Zimmerman, CISSP