Writing DFIR Books
Suzanne Widup (of Verizon) recently asked me to sit on an author's panel that she's putting together, in order to make the rounds of several conferences. I won't be available for the panel at CEIC, but David Cowen will be there...be sure to stop by and see what he, and the other panel members have to share about their experiences.
I thought I'd put together a blog post on this topic for a couple of reasons. First, to organize my thoughts a bit, and provide some of those thoughts. Also, I wanted to let folks know that I'll be a member of the author panel at the SANS DFIR Summit in Austin, TX.
How did I get started?
Several years ago, a friend asked me to be a tech reviewer for a book that he was co-authoring, and during the process, I provided some input into the book itself. It wasn't a great deal of information really, just a paragraph or so, but I provided more than just a terse "looks good" or "needs work". After the book was completed, the publisher asked my friend if they knew of anyone who wanted to write a book, and he provided three names...of the three, I was apparently the only one to respond. From there, I went through the process of writing my first book. After that book was published, it turned out the publisher had no intention of continuing with follow-on editions, and our contract provided them with the right of first refusal, which they did, and I moved on to another publisher.
Why write a book?
I can't speak for everyone, but the reason I decided to write a book initially was because I couldn't find a book that covered the digital forensic analysis of Windows systems in the manner that I would've liked. Like many in the DFIR community, I've had notes and stuff sitting all over, and in a lot of cases, those notes were on systems that I no longer have; over time, I've upgraded systems, or installed new OSs. Writing a book to use as a reference means that rather than rummaging all over looking for something, I can reach up to my bookshelf, open to the chapter in question and find what I'm looking for.
What goes into writing a book?
A lot of work. Writing books for the DFIR community is hard, because there's so much information out there that is constantly changing. Even if you pick a niche to focus on, it's still a lot of work, because historically, our community isn't really that good at writing. People in the DFIR community tend to not like to write case notes and reports, let alone a book.
For most, the process of writing a book starts with an idea, and then finding someone to publish the book. Once there's interest from a publisher, the potential author starts the process of putting the necessary information together in the format needed by the publisher, which is usually a proposal or questionnaire of some kind. If the proposal is accepted, the author likely receives a contract spelling out things like the timeline for the book development, page/word count, specifics regarding advances and royalties, etc. Once the contract is signed, the writing process begins. As the authors send the chapters in, they are subjected to a review process and sent back to the author for updates. Once the manuscript...chapters, front- and back-matter, etc...are all submitted, the proofs are put together for the author to review, and once those are done, the book goes to printing. The time between the author sending the proofs back and the book being available for shipping can be 2 - 3 months.
I'm not saying that I agree with this process...in fact, I think that there is a lot that can be done to not only make the entire process easier, but also result in better quality DFIR books being available. However, my thoughts on this are really a matter for another blog post.
How do you decide what to put in the book?
When you feel like you would like to write a DFIR book, start with an outline. Seriously. This helps organize your thoughts, and it also helps you see if there's enough information to put into a book. Preparation is key, and this is true when taking on the task of writing a book. I've found over time that the more effort I put into the outline and organizing my thoughts ahead of time, the easier it is to write the book. Because, honestly, we all know how much folks in the DFIR profession like to write...
What do you get from writing a book?
It depends on what you want from writing a book, and what you put into it. For example, I started writing books because I wanted a reference, some sort of consolidated location for all of the bits and pieces, tips and tricks that I have laying around.
First, let me clear something up...some people seem to think that when you write a book, you make a lot of money. Yes, there are royalties...most contracts include them...but it's also really easy to sit back and assume what the percentages are and what the checks look like, and the fact is that most people that think like that are wrong. I've had people ask me why I didn't include information about Windows Mobile Devices in my books...either for full analysis or just the Registry...and they've suggested that I make enough money in royalties to purchase these devices. If you think that writing a book for the DFIR community is going to make you enough money to do something like that, then you probably shouldn't start down that road. Yes, a royalty check is nice, but it's also considered taxable income by the IRS, and it does get reported to the IRS, and it does get taxed. This takes a small amount and makes it smaller. I'm not complaining...I have engaged in this process with my eyes open...I'm simply stating the facts as they are so that others are aware.
One thing that you do get from writing a book, whether you want it or not, is notoriety. This is especially true if the book is useful to folks, and looked upon favorably...they get to know your name (the same is also true if the book ends up being really bad). And yes, this notoriety kind of puts you in a club because honestly, the percentage of folks who have written successful DFIR books is kind of small. But this can also have a down-side; a lot of people will look at you as unapproachable. I was told once during an interview process that the potential employer didn't feel that they could afford me...even though we hadn't talked salary, nor salary history...because I'd written books. I've received emails from people in the industry, some that I've met in person, in which they've said that they didn't feel that they could ask me a question because I'd written books.
What I get from writing books is the satisfaction of completing the book and seeing it on my bookshelf. I've actually had occasion to use my books as references, which is exactly what I intended them to be. I've gone back and looked up tools, commands, and data formats, and used that information to complete exams. I've also been further blessed, in that some of my books have been translated into other languages, which adds color to my bookshelf.
Book Reviews
Book reviews are very important, not just for marketing the book, but because they're one way that the author gets feedback and can decide to improve the book (if they opt to develop another edition).
Book reviews need to be more than "...chapter 1 contains...chapter 2 covers..."; that's a table of contents (ToC), not a book review, and most books already have a ToC.
A review of a DFIR book should be more about what you can't get from the ToC. If you review a restaurant on Yelp, do you repeat the menu (which is usually already available online), or do you talk about your experience? I tend to talk about the atmosphere, how crowded the restaurant was, how the service was, and the food was, etc. I tend to do something similar when reviewing DFIR books. The table of contents is going to be the same regardless of who reads the book; what's going to be different is the reader's experience with the book.
When writing a book review and making suggestions or providing input, it really helps (the author, and ultimately the community) to think about what you're suggesting or asking for. For example, now and again, one of the things I've been asked to add to the WFA book is a chapter on memory analysis. Why would I do that if the Volatility folks (and in particular, Jamie Levy) have already put a great deal of effort into the tool documentation AND they have a book coming out? The book is currently listed as being 720 pages long...what would I be able to provide in a chapter that they don't already provide in a much more complete and thorough manner?
Now, I know that not everyone who purchases a book is going to actually open it. I know this because there are folks who've asked me questions and knowing that they own a copy of the book, I've referenced the appropriate page number in the book. But if you do have a book, and you have some strong feelings about it (whether positive or negative), I would strongly encourage you to write a review, even if you're only going to send it to the author. The reason is that if the author has any thought of updating the book to another edition, or writing another book all together, your feedback can be helpful in that regard. In fact, it could change the direction of the book completely. If you share the review publicly, and the author has no intention of updating the book, someone else may see your review and that might be the catalyst for them to write a book.