Forensic Discovery
Security luminaries Dan Farmer and Wietse Venema wrote one of the first vulnerability scanners (SATAN) almost 10 years ago; SATAN was the precursor to ISS Scanner, Retina and nmap. Venema wrote such well-known security applications as the TCP Wrapper program and the Postfix mail server. Farmer and Venema's new book Forensic Discovery is a valuable book that grounds a computer-savvy reader in the world of digital forensics.
An image of a pipe by artist René Magritte is on the cover with the caption Ceci nest pas une pipe. ("This is not a Pipe.") The picture demonstrates that an object exists on many planes; the simple recognition of the picture initiates the belief that we are seeing something, but it is only known in representation. Surrealist painting and digital forensics coalesce in that the digital forensic investigator must think broadly and unconventionally in order to reconstruct an incident, all the time keeping in mind that often what initially seems obvious is neither real nor correct.
The material in the book is an outgrowth of a one-time seminar the authors gave in 1999 on digital forensics and analysis. At the seminar, Farmer and Venema rolled out The Coroner's Toolkit (TCT), a collection of tools for gathering and analyzing forensic data on a Unix system. TCT is heavily referenced throughout the book.
The book initially seems thin, at just 198 pages, but there is no filler and the information is presented in a fast and furious manner. Part one of the book comprises 35 pages and is an introduction to the foundations of digital forensics and what to look for in an digital investigation.
Part two (chapters 3-6) is the nucleus of the book, which quickly gets into low-level details about file systems and operating system environments. While other forensics books focus exclusively on the discovery and gathering of data; Forensic Discovery adds needed insight on how to judge the trustworthiness of the observation and the data itself. Again, the idea is that not everything is as obvious as it may initially seem. An effective investigation often requires intense analysis, where meaningful conclusions take time.
Chapter 4, "File System Analysis," notes that while computers have significantly evolved since their inception, little has changed in last 30 years in the way that file systems actually handle data.
Chapter 5, "Systems and Subversion," is particularly interesting as it deals with system startup and shutdown, from a forensics perspective. The chapter shows that there are thousands of possible opportunities to subvert the integrity of a system without directly changing a file during startup and shutdown. A crucial decision that must be made during an incident is whether to shut down the system or let it remain on-line. There are advantages and disadvantages to each approach, and the book details them.
Part three (chapters 7-8) is about the persistence of deleted file information. The authors' research reveals that data can be quite resistant to destruction. The book shows that a huge amount of data and metadata can survive intended deletion as well as accidental damage.
Forensic Discovery is unusual in that other books on forensics are often nothing more than checklists and step-by-step instructions on what to do during an incident. Forensic Discovery provides a broad framework on the nature of data and how it can be recovered for forensic purposes. By understanding the underlying operating system, the act of analyzing and dealing with a security breach becomes much easier.
The book's target reader is anyone who wants to deepen his understanding of how computer systems work, as well as anyone who is likely to become involved with the technical aspects of computer intrusion or system analysis. The topics are too advanced, to make it the right book for the novice system administrator. For the technical reader, though, Forensic Discovery is one of the best computer security books published in the last year. The value of the information is immense, and the extensive experience that the authors bring is unmatched.
You can purchase Forensic Discovery from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
My problem with the CSI-type shows is that forensics analysts are more like Quincy, who rarely, if ever, interviewed a suspect or a witness, and got in major trouble when he did.
The "examiners" on CSI do everything except commit the crimes, give parking tickets and prosecute the suspects. If I could do half of what one of them does, I'd be an unstoppable law enforcement agent!
Meow. Now!
Well, maybe. The issue is password protection. If "they" have access to your computer early on, and they almost certainly would, they can put in a keyboard sniffer to snatch your password -- and there goes the safety afforded by your encryption, no matter how robust the algorithm itself may be. There are ways around this, but I've rarely seen them discussed, much less implemented.
Encrypted filesystems do no good if the filesystem is still mounted and the investigator has root access somehow. i.e. they've seized your computer while it's powered on (possibly along with your UPS if it's a desktop) and supoenad (or tortured out of you) your passwords.
With a decent encryption method, you can almost guarantee that the data is secure. The better the encryption is, the larger the server farm/super computer they need to crack it. Although, it can be seen as contempt of court if you are required by law to give them the keys used to encrypt it and you fail to do so. Just because the data is unreadable by them doesnt mean they cant put you in the slammer.
I especially hate it when (this seems to predominate on CSI, but I've seen it on other shows as well) they "digitally enhance" security camera video to identify an attacker, read a license plate, etc. Usually, I can overlook it for the sake of the plotline every now and again. But, the final straw came for me a few weeks ago on CSI when they had an ATM security cam and the pulled a reflection off of the pupil of the third person in line and enhanced it to ID the criminal (second in line) who was facing away from the camera. They literally took a single grey pixel from the video and "enhanced" it to a beautifully rendered, studio-lit 8"x10" black and white portrait of the criminal.
And, oh yea, if you put deer feces into an NMR, it's not going to spit out a graph with a bunch of peaks on it and print below the graph: "deer feces". On the other hand, I'm not sure which is worse...when they do that with the NMR, or when they NMR identifies 50 compounds in a sample, all with names like "n-methyl hydride deoxynitrate", and the CSI goes, "Oh, yea, those are the major components of plumber's grease that was used between 1970 and 1978 in the Western United States." They might as well have the NMR spit out a graph with a caption: "The bus driver did it! The motorcyclist was only his *accomplice*."
Then, of course, there's the small issue of unlimited budget. If real CSIs solved crimes like they do on TV, they'd be spending somewhere between $15M and $50M per case. :-)
but have you considered the following argument: shut up.
CSI is laughable in how little it reflects reality. If you want a more relistic TV-based view on forensics, try the Discovery channel show "The New Detectives". It's still going to gloss over a LOT of details (it's TV) but rarely do they present something patently wrong as fact, as happens all the time on CSI.
3 131/csifacts.htm
For more info on CSI's lack of attention to detail try this site:
http://www.angelfire.com.nyud.net:8090/jazz/jboze
For starting out. (Will they have Phishing For Dummies next?)
One line blog. I hear that they're called Twitters now.
Security luminaries Dan Farmer and Wietse Venema wrote one of the first vulnerability scanners (SATAN) almost 10 years ago; SATAN was the precursor to ISS Scanner, Retina and nmap. Venema wrote such well-known security applications as the TCP Wrapper program and the Postfix mail server.
SATAN was also known as SANTA to those sensitive to sacrilegious references. Also, it's TCP Wrappers.
This poster is totally incorrect. I have served as a computer forensic expert in both civil and criminal cases, and can tell you this poster does not understand the process. For example, the prosection and defense may find an impartial examiner or use two examiners and make two copies of the seized disk or disks. Forensic tools with copy capabilities such as EnCase will make a bit-for-bit copy (including non-allocated sectors, file slack space, etc) of the disks and perform an MD5 checksum over the contents.
I now perform my work on the copy. Any results I obtain can be demonstrated in court, as can the fact that the MD5 hash is the same and that my disk is still identical to the other party's copy.
If chain of evidence is maintained, I should get the disk as it was when it was seized. Once I have it and copy it, it is effectively tamperproof, because of two persons each having a copy, the MD5 hash, additional checksums built into EnCase copy structures AND the fact that we can always recompare our copy to the original to determine it is still bit for bit.
The scientific validity of computer forensic methods can be subjected to a Frye or Daubert hearing, where scientific experts can defend the method. EnCase has already been through these hearings and no credible argument has been advanced against its validity.
If you competent defense counsel or civil counsel, this should not be a concern.
Robert Morris Sr. once told an audience that cryptanalysts in real life follow the rule "look for plaintext, it shows up in the darnedest places".
F'rinstance: suppose you're in the Middle East but you've carefully stored all your images of women without veils onto an encrypted volume. Suppose you looked at them one day. JPEG files typically open into a web browser. No matter how encrypted your stash was, the images are still sitting in the browser cache.
Today's crypto is as strong as your passphrase(*). Could that passphrase have somehow gotten swapped out? Then anyone who can open your swap file can get the contents of your encrypted volume.
(*) *IF* it's implemented correctly. You can take a perfectly good crypto algorithm and completely wreck its security by using a bad source of random numbers (Netscape), reusing keys (Venona), reusing initalization vectors (WEP), or any of many other errors.