I received the following comments from Allen Wheeler (a Systems Engineer with Troll Systems) today via email, and with his permission, I wanted to share his comments with you:
I just wanted to tell you how impressed I am with how thoroughly you cover the methods covered in your book. Usually when I pick up a book like this I’m prepared for more questions than when I started but that’s not the case with Windows Forensic Analysis. It’s elegantly worded and easy to follow which is hard to find when it comes to technical books. I read for about 8 hours straight yesterday on a trip back from the east coast and I still didn’t want to put it down. As a long time Windows user, you’ve helped fill in a lot of blanks and I feel like I’ll have a lot more flexibility and power by employing many of your tools and techniques as a Systems Engineer who spends a lot of time in this OS. Thank you!
Allen also posted a review of WFA 2/e on Amazon. Thanks, Allen, for your words, and for feeling led to reach out and share your thoughts, not just with me, but with others!
3 comments:
With such a glowing review - and the others, looks like I'm going to have to buy this book now! LOL
I'm half-way though chapter 3 and I'm loving the book thus far. It's bringing back some fond memories - lol.
The book is extremely well-written. Definitely beyond my expectations. If someone hasn't done Windows forensics before, the detailed explanations of how and why to do things, and the examples, will increase their knowledge by leaps and bounds.
I'm jotting down my thoughts as I'm going through each chapter, which I'll send to you after I'm done reading the book. I'm sure you've probably thought about all of these things, but I'll send them to you anyway.
I have a few questions and comments at this time if you don't mind:
Have you spent much time doing network forensics? How about content/executable reassembly from non-encrypted/encrypted packets?
I'm thinking that a companion book on networks forensics specifically for Windows forensics will address some of the issues you raise with respect to live forensics, post shutdown forensics and post activity forensics. I'm really a big advocate of full-time packet capture systems at the perimeter and interior of a network. Network session playback forensics is an awesome capability with respect to piecing together missing pieces of the puzzle.
Have you given some thought to writing a guide to forensics preparedness?
Given that compromise is inevitable, there are a lot of "after the incident has occurred forensic gotchas" that people can avoid if they knew how to properly instrument themselves in the first place. One example that comes to mind is a bank that has a multi-server Web load sharing setup, such that if a compromise is suspected, they can move that server off to the side in isolation (no new connections), while the other servers take care of the servicing customers.
Anyway...
Good job on the book. I'm looking forward to reading the rest of it.
Cheers :)
Have you spent much time doing network forensics?
Yes, some...but it's not often that I have had an opportunity to use it in conjunction with disk forensics. Most of the cases I've dealt with since 2002 have been after-the-incident cases...in fact, for 3 1/2 years on the IBM ISS team, none of the engagements I worked involved packet captures of any kind. In all (and I mean ALL) cases, we received a call b/c a customer had received a call, and had been compromised for some time...anywhere from 3 months to 2 yrs. I worked an engagement recently where we were able show signs of compromise going back over a year and a half.
Have you given some thought to writing a guide to forensics preparedness?
Yes, but I'm not sure how well received it would be. I'm aware of folks who are selling forensic preparedness as a service, and from what I'm being told, the business isn't doing as well as it could/should. The simple fact seems to be that most organizations simply do not want to invest the time, effort and resources into incident preparedness, and seem to be content to hear from guys like me, "we couldn't determine that b/c you didn't have logging enabled, nor did you have a firewall that was logging..."
That just seems to be how it is.
Thanks for your comments. I'll be happy to answer any other questions you may have.
Post a Comment