Writing Books, pt I

I mentioned in an earlier post that I felt as if I wanted to share my experiences after having written five books, and been a minor co-author on a sixth.

First, I wanted to share a bit about my history of how I got involved in writing books, just to give you some perspective. I didn't start writing books; instead, I started reviewing books and book proposals. This seemed like a great way to see what was up and coming in the industry, as well as to make a little mad money on the side (or, if the remuneration was books, to stock my library). At one point, I was working on a review and completely disagreed with something the authors stated with respect to NTFS alternate data streams; not only did I disagree with it, but I offered up some text of what I thought the section should say. In the end, the authors agreed and accepted my contribution.

When the book was published, the publisher asked the authors if they knew of anyone who might be interested in writing a book. My name was offered up along with several others, and I accepted...and began the process of discovery that has led me to this point.

Further, I do have a long history of writing, albeit not books. Like many of us, I have a public school education. 'Nuff said, right? I wrote in college. I wrote during my first career as a military officer. I wrote a thesis for my graduate degree. I have written a lot of reports since I got out of the military and began pursing a career in the information security field. I can't say that I've enjoyed all of the writing, but it does provide both breadth and depth to my writing experience. In every case, there's some bad stuff that I didn't like and leave behind, and in most cases, there are some gems that have really benefited me that I can trace back to some of that early experience.

What I'd like to do now is provide something of a process but really more of my experiences and what I've learned in the process of writing books. My hope is that someone will take a look at this and perhaps decide to pick up their pen, as it were, and put it to paper. I know that there are some really smart folks out there with some really good ideas that need to be shared, and writing a book is a great way to do that.

Why write a book?
The first thing you need to think about is, why do you want to write a book? Some folks I have met want to write a book so that home users know what to do to secure their systems, or the members of their church know more about the Internet in general. Personally, I wanted to take all that stuff I had laying around in different locations and put it in one place...yes, that's right, I use my own book as a reference. ;-) After my first book, I wanted to prove to myself that I wasn't a one-trick pony and that this was something I could do again.

If you're in a technical field, do not expect to get rich writing a book, or even several books..so that's not a reason to write a book. It just it's going to happen. The technical field does not have the market that other genres tend to enjoy; in fact, the more technical and narrowly focused your book, the more of a niche market you'll be focused on and the less likely you will be to really "score".

There can be a number of reasons to write a book...those that I've mentioned above are just some of them. However, if you don't have a good reason or a goal that you'd like to reach, what's going to keep you going through the process?

Choose a topic
So, what do you want to write about? Clearly, if you're reading this blog, then you're interested in technical topics, including incident response and/or digital forensics. Okay, that's a good place to start. Can you narrow it down...or should you? Sometimes, taking a broad brush approach is a great way to get started on a topic. I've found that focusing very narrowly has proven to be the way to go for what I'm writing about...the narrow focus being forensic analysis of Windows systems.

However, I don't think that this process is really specific to just technical books. I think a lot of my experiences in writing books can be applied to other areas/genres, as well...such as writing children's books.

Research the topic
Look online and at bookstores to see if there are any current books that cover your chosen topic. If there are, you would have to determine how you would differentiate your book from the others. Will your book be more up-to-date, will you provide a different perspective somehow?

If there aren't any other books or resources that cover what you're interested in writing about...you may be home free.

Another aspect of this research what will benefit you greatly is to take a look at other resources, and not just those related to your chosen topic. Look at books in your chosen genre that you've enjoyed reading, and try to determine what it is you really enjoyed about them. One early example that I found that I really enjoyed is sidebars, little snippets that usually appear on the page in a grey box that tend to pertain to what you're currently reading, even if only tangentially. I recently reviewed the Malware Analyst's Cookbook, and I really like the idea of "recipes".

Create a detailed outline
Before you begin writing your book, outline it. Yes, just like you learned in grade school...and you thought you'd never use that again, like math. Begin with a simple outline, and begin adding to it. This allows you to begin to organize your thoughts with respect to writing your book, and begin preparing for the questions you're going to eventually encounter, such as how many chapters your book will have, what topics it will cover, etc. When I've put together outlines, I've found that just the act of writing the outline has led me to the idea that my chapters need to be restructured to make better sense, and that I needed to add additional chapters, as well.

A detailed outline helps me to organize my thoughts, and see where I need to include images, charts, figures, tables, etc. Would an image here make really good sense, and would a table here that encapsulates and summarizes the last three paragraphs really be useful to the reader?

Adding detail to your outline will only benefit you in the long run. Having a detailed outline keeps you on-point and on-track, provides some structure to what you're doing while you're doing it, and can be very beneficial, particularly if you've taken additional notes and written down some choice phrases that you'd like to use.

Just so you know, both publishers I've worked with thus far have asked for this research and work (i.e., outline) to be done and submitted as part of a proposal before going forward. So, you're going to *have* to do the work, and as much as I didn't want to do it the first time, I found out that going through the process...I mean, really going through it, not just doing it to get it done...made a difference.

Seek review
Most of us in the technical field do not like to have our written matter (when we do it) reviewed. I know that. You know it, too. But know that as you begin going down this road, you're going to get tunnel vision and you won't see the forest for the trees. To use another cliche and score a hat trick, you'll be too far down in the weeds and you'll need a reality check. Find someone you trust to give you honest, thoughtful criticism. When I was writing my very first book, I got a lot of that kind of criticism from Jennifer Kolde, and I've used what I learned through our exchanges to try and improve my writing with each book. As much as you won't want to, it will only benefit you to find someone (or someones, plural) to take a look at your ideas and give you a reality check.

Know that it will suck
That's right...simply accept the fact that this will be hard. Why? If you choose to write a book, you're going to have to write, which means you'll be adding a new activity that is going to replace an old activity in your life. You may have to give something up...at least, in part. My lovely wife, God bless her, says that when I was writing my first book, she had no idea that I was writing a book. That was because I rarely gave up our dates during that process...instead, taking her to dinner or a comedy show served as a much needed break.

Also, the truth is, most people don't like to write, especially technical people. Case notes, reports, you name it...most technical folks simply do not enjoy the act of writing.

However, with a little (okay, a lot) prior planning, you can make the process of writing a book much easier.

Writing Books, pt III

At this point, if you're still following and reading this series, you're likely interested in writing a book, particularly (but not exclusively) in a technical field. Now that we're to the point where we've at least considered a publishing medium...or an actual publisher...let's talk about the actual writing.

Determine your audience and writing style
So, now that you have a topic, and your detailed outline, who are you going to be writing the book for? Who is your intended audience? In many ways, your audience can also dictate your writing style. Are you going write from/to a more academic perspective, or do you want to reach as wide an audience as possible? Do you want to sound more clinical, or do you want to be a bit more free flowing?

From my own perspective, I think that over the books I've published, I've progressed a bit and so far, I've received the most and best comments regarding the writing style with respect to WFA 2/e...keep your eyes out for the Registry book, as I think that you'll notice an improvement along those lines.

One of the best ways to determine your writing style is to read. Seriously. What books have you read that you really enjoyed reading? Now, think about why you enjoyed them? Were the characters authentic, did they seem real? Was the writing and its tone enjoyable and easy to digest, or did the author bore you to death (hey, you should read my master's thesis!)?

Also, what other things do you enjoy? When I was originally working with Syngress to publish WFA 1/e and we were working up the title, I immediately agreed with the publisher that if the title had "Windows" and "forensics" in it, I would immediately pull it off the bookshelf to take a look at it. That made sense to me, because that's exactly what I did when I went to the bookstore. From then on, I started to look at those things that I liked about certain books, or didn't like, and tried to emulate them. Over time, I've tried to add more of those things...sidebars, use cases, etc...that people have told me that they want to see more of, in most cases because I wanted to see more of them, as well.

As to the audience, I would like to reach a wide range of folks within the community. I find a lot of books that aren't specifically about IR and digital forensics to be very valuable (such as the Malware Analyst's Cookbook), so my hope is that besides those directly involved with responding to and analyzing Windows systems, others find my books useful as well. Within the community, I'm hoping to provide something useful or valuable to a wide range of analysts, from those new to the field (or just interested in it) to those who have been in a while, from active responders to those taking university or community college courses, to LE, etc. It's probably something of a lofty goal, I know, but that's the direction I'm going.

Be thorough in your writing
Deciding on your overall audience will also have an impact on the level of technical ability that you assume. For example, when describing a technique that uses an open source tool (say, written in Perl), how far do you want to go in explaining the tool? Do you want to go into detail explaining how to install Perl (or Python, or Cygwin, or whatever), or are you going to assume that reader can figure that out themselves?

Sometimes, writing "run the tool" (in magazines like 2600, you'll see 'run nmap' and little else...) doesn't often work very well. Providing a complete command line and relevant output from the command gives the reader something that they can hold on to. Many times, screen captures also help a great deal. However, the caveat about screen captures is that they have to be clear enough to see and understand...I've opened many books where I couldn't read the screen captures at all.

Also, when providing screen captures, be sure to specify what system or systems you're running the tool on, so that the output makes sense. I've met a LOT of folks who think that the major OSs that they have to address are Linux, MacOSX, and Windows. As someone who works with Windows systems, I'd strongly suggest to you that there's a major difference between Windows XP and Windows 7...but that's something to get into later. The fact of the matter is that in some cases, you're going to get different output based on a number of variables...version of the OS, version of Python or Perl installed, etc. Specify what you're working with when you write your book.

If something's important, it's okay to repeat it
Sometimes, this is the case. You don't have to repeat it verbatim, or even in the same chapter. If there's an important concept or technique that you've presented in your book, returning to it later in the book will help the reader see that its important, and perhaps even understand the importance.

When I was an instructor in the military, we'd do that...a lot. We had things that we did to signify to the (usually dozing) students that something was important. One really easy way to do this is to think about it when you're developing your outline, and find places where you can tie concepts or techniques together, where you expound or expand on something...and if you need to, highlight them on the outline in different colors. Some of us that talk about IR mention things like "Locard's Exchange Principle" (I do, and I know that Chris Pogue does, as well...)...so when you talk about it, find places in the book, such as during exercises or case studies, where you can clearly demonstrate the concept. If it's important, use it.

Be consistent
One of the things I learned about report writing that is also true in books is that you need to be consistent in how you write and present things. For example, lets say you're writing a report based on your analysis of three acquired images. When you discuss the analysis of the first system in your report, you describe the AV scans you ran, the Registry analysis you conducted, etc. Then for the second system, you first discuss AV log analysis, Event Log analysis, and you leave the AV scan results to the end and do not even mention your Registry analysis. The discussion of your analysis of the third system continues to be disjointed.

So, what do you think that the reader will walk away with after reaching the end of your report? Will she think that you did a thorough job in locating the malware? Not likely. It's more likely that she'll remember the inconsistencies, because the technical information you presented was lost in the "noise" of those inconsistencies.

The same can be said about writing books. Let's say you're writing a book on analyzing different image (JPG, TIFF, etc.) formats; providing a consistent structure for each image format will allow the reader to form comparisons and contrasts in their minds, whereas an inconsistent approach will leave the reader's mind similarly tangled and confused. Further down the road, the reader will have to search for important references in your book; however, if you've presented the material consistently, they're more likely to turn right to it, particularly if they're comparing information between two or more formats.

Getting Started
Regardless of the decisions you've made up until now, or how much discussion you've had with others about your ideas, nothing is going to actually happen until you start writing. That's right...write something. Anything. Because it's easier to change something that's already written, whereas if you're just sitting there starting at a blank page, you'll just keep staring...and that's hard.

When I was in the military and was writing fitness reports, I found it much easier to start early, consult my platoon commander's notes, and write something. I've found that 17 yrs later, the same things apply, and apply very well. As I develop my outline, I take notes...in a notebook, on stickie's, etc. I start pulling them all together, and start writing.

You're Not Gonna Be Perfect
What first comes out isn't pretty, and it may not be what I end up going with, but it's something to start with. When I was writing my first book, I sent chapter 1 in for review early on in the process...when it came back, I couldn't believe that I'd actually written what was there, and that it was only 8 pages! I really had to look at it, because in the process of working with one of the reviewers, I'd learned so much about writing from the other chapters that I had a hard time believing that I'd actually submitted what was in chapter 1! In the end, I ended up completely re-doing the entire chapter.

As much as you want what you're writing to be just right, understand that it's not going to be perfect. Sometimes, that becomes the excuse we use for not writing, or not submitting what we've written. Just know that it's not going to be perfect...but if you've put your best effort into it, it will be good and something that you can be proud of. Also, remember that in a group of people, you're never going to please everyone...keep that in mind. You're going to need a tough skin, because whenever you put something out there for public consumption, you're going to get positive as well as negative feedback...you're going to have critics.

All that matters is that you're doing this for the right reasons, and that at the end of the day, how do you feel when you look up at your bookshelf, or at the bookshelf at the bookstore (or on someone's iPad...) and see your book there?

Readin' and Writin'

Richard Bejtlich recently wrote an interesting blog post on reading, and followed that up with some answers to questions posted as comments to the first post.  In his first post, Richard discusses several types of reading; I tend to find myself reading mostly for information or entertainment, but when I'm writing a report or book, I will most often resort to a proofreading style of reading as I go back over what I've written.  Right now, my entertainment reading consists of a book on the life of George Washington and the ebook version of William Gibson's Zero History.

Many times, when I read for information, thoughts and ideas marinate and percolate, not just with respect to what I'm currently reading, but also including other sources...stuff heard in podcasts, other books or whitepapers read, etc.  For example, when I was reading Will Gragido and John Pirc's Cybercrime and Espionage, something that I read combined with work I'd done in the past...PCI breach investigations, and the QSA certification/re-cert classes I was required to pass...to ignite some interesting ideas.  So while I was reading, I would write down some notes, and then revisit those notes later after I'd finished reading, or even a day or two later.

Now, this a good place to transition from types of reading to types of writing.  One type of writing, such as note taking, is meant for personal information retention.  Often, we'll take notes and jot down little missives as a way to remind ourselves of something, or simply to document what we might have thought was a good idea at the time.  Another type of writing (documenting case notes, report writing, book writing, etc.) is meant more for transmitting information to others.  This style of writing will encompass a variety of forms, but for the most part the overall goal is to preserve and transfer information for others to use.

One method of writing I made great use of while I was in the military is illustrated in how I would write fitness reports ("fitreps"), the military term for "personnel evaluations".  I would start the fitreps several weeks out by consulting my platoon commander's notebook, and jotting down some notes to myself with respect to key elements I would like to highlight in the report.  Then I would set aside specific time for myself to revisit these notes over the next couple of days or weeks, allowing my thoughts to "marinate" and crystallize a bit.  By focusing for an hour or two each week, I could get the reports completed in a manner that I was very comfortable with, rather than rushing at the last minute and submitting something that I wasn't comfortable with and wasn't complete, and might have a detrimental effect on the Marine's career at some point in the future.  I'd actually seen the effect that poor planning and writing had on a Marine's career; one of my Staff Sergeant's was applying for the Warrant Officer program, and the selection committee had found a fitrep written on the SSgt in which the reviewing officer, a Marine Captain, had stated that the SSgt deserved to be awarded a medal...but never submitted a write-up for the medal.  In short, poor planning and execution could have a negative impact on someone's career later on down the road.

As a community, I don't think that we do enough reading or writing.  By reading, I mean really reading for comprehension, and by writing, I mean really writing to convey some sort of information.  Too many times, I see questions being asked in online forums, and the response that is received has no correlation to the question; it's as if whomever had read the question had only read every third or fifth word, and just answered another question all together.  Also, we all see emails and posts to list servs and forums that would benefit greatly from spellcheck or just a review for grammar.

It all comes down to thought processes.  One simple way to expand our horizons is to read something, and when we do, put more thought than just "neat!" into what we're reading.  Another way to expand and develop ourselves professionally is to write more for public consumption.  When you read something, do you think critically about what you're reading?  Or do you simply accept it without question because the person writing it is someone that you or others consider to be an "expert"? 

If you think that something you've read is a good idea, why do you think that?  Is it because it would be (or would have been) useful to you in some way?  How so?  Can you articulate that?

Ultimately, what we do ends up in some sort of written form.  When we perform analysis, many times the end result is a report to someone...our boss, a customer, etc.  The way we provide value through the reporting process is to think critically, and provide a clear, concise description of our findings to the customer, in a manner that they can understand and use. 

So how do we go about doing this?  A lot of us read...even it's 140 characters or less at a time, we tend to read stuff, right?  So what do you do at that point?  Do you simply retweet, or do you use that as the beginning of a blog post?  If you are writing a blog post, are you simply providing a link to what you read, or are you writing a description of how the information was impactful or meaningful to you?

There a lot of opportunities out there.  For example, look at what Corey's done over at the Journey into IR blog, with his exploit artifacts posts.  This is just one example of what can be done.  Regardless of the route you choose to take, or the path you choose to follow, reading something within the community (book, tweet, blog post, etc.) and not taking the opportunity to think critically about what was read and to open a discussion on the topic, sharing your thoughts with others...all of this is simply a missed opportunity.

Soft Skills: Writing

Writing. 

Like math in middle school, this is one of those subjects that we pushed back on, telling ourselves, "I'll never have to use this...", and then quite shockingly finding that it's amazing how much writing we actually do. However, are we doing it well, given the particular circumstances of the writing? We "write" on social media, not being too overly concerned about things like grammar, spelling, or even word choice, falling back on the old, "...you know what I meant...", or blaming auto-correct for the miscommunication.

I'll be the first to admit, I'm not an "expert" at writing, nor am I "the best". But I will say that I am intentional in my writing, and this is something that's led me to...not been the result of...maintaining a blog, and publishing several books, with others in the hopper.

Writing is a necessary skill that many who need to, do not intentionally engage in, and of those who do, very few accept criticism or feedback well. For myself, I have a long history in my career of having to write, which stated in college in the mid-to-late '80s. I was an engineering major, and my English professor said that I wrote "like an English major". To this day, I still don't know what that meant, because I was constantly switching verb tenses in my writing, which was reflected in my grades. 

While on active duty, I had to write, and because it was the military, there was feedback..it was part of what we did, so there was no getting away from it, shrinking back and retreating when someone had recommendations. It started in training, with things like operations orders, and continued out "in the fleet", progressing into JAG manual investigations, fitness reports, pro-con assessments, etc. There was all kinds of writing, and there was a LOT of feedback, whether you wanted or liked it, or not.

Another thing that was clear about the writing in that environment was that not everyone received the same feedback, and not everyone took the feedback they received the same way. Very early on in my career, I learned some "truths" about writing fitness reports, particularly from knowledgeable individuals. I reported to my first unit in May 1990, and not long after, a CWO-2 named "Rick" returned from a promotion board at HQMC. He was able (and willing) to act as a confidant and mentor, particularly given not only his longevity in service, but also based on his very recent experience. He not only shared what he'd learned throughout his career, but also the insights he'd learned from the recent promotion panel. I was able to take what I learned from Rick, and use it going forward, but just a couple of years later, I had a SSgt who was applying for the Warrant Officer program, who had some fitness reports written on him that included questionable statements, statements that stood out as being starkly and glaringly counter to what I'd learned.

What I learned on active duty served me very well in the private sector, the biggest lesson being, "...don't get butt hurt when someone says something...". Look beyond the "how" of what's said, to the "what". Don't get so wrapped in the "you were mean to me" emotional response that you miss the gem hidden beyond that will get you over that hump, and allow you to be a better writer. Look beyond your own initial, visceral, emotional response, and closely examine the "what".

Now, if you're posting to social media, you may not care about grammar, spelling, punctuation, etc. It may not matter, and that's fine. If you're not trying to convey a thought or idea, and you're just "sh*t posting", then it really doesn't matter if the reader understands what you're trying to say. 

But what about if you're filling out a ticket, or reporting on an investigation? What if you're actually trying to convey something, because it's "important"? Now, I put the word "important" in quotes, because throughout the passed two decades, I've talked to more than a few in the DFIR community who haven't really grasped how important their communication is, how what they are sharing in a ticket or in a report is actually used by someone else to make a decision, to commit resources (or not), or to levy a fine or punishment. Many analysts never see what's done with their work, they never see corporate counsel or HR, or a regulatory body using what they've written to make decisions.

I've also seen far too many times how a simple, "...what does this mean?" or "...can you clarify which version of Windows you're working with..." is wildly misinterpreted and internalized as, "I'm being called out unfairly."

What Can I Do?
So, what? So, what does this all mean to you, the reader, and what can you do? What I'm going to share here are some of the lessons I've learned over the past three decades...

The first step is to recognize that we can all get better at communicating, and in particular, writing. So, start writing. Comment on posts (Twitter, LinkedIn) rather than simply clicking "Like". Did you like a book you read? Write a review. Ask someone a question about a book they read or about a post they wrote or recommended. 

To get better at writing, it's best to read. If you read something that you enjoyed reading, consider why you enjoyed it. Was it the content itself, or the writing style? If it was the writing style, try emulating that style. Is it more formal, clinical, or perhaps more conversational? Consider what works for you, what do you enjoy, and how can you make that part of how you write.

Do not assume any response or feedback you receive is intended to be negative. Yes, I get it...this is the Internet, and there is a lot of negativity, and when you encounter that, the best thing to do is ignore it. But when you receive feedback on something, particularly when it's sought out, don't immediately assume that it's negative, or that you've done something profoundly wrong. Instead, recognize the negative feelings you're having, take a deep breath...and look beyond those feelings and really try to see the "what" beyond the "how". Look for what's being said, beyond how it's being said, or how it makes you feel.

Writing DFIR Books: Questions

Based on my Writing DFIR Books post, Alissa Torres tweeted that she had a "ton of questions", so I encouraged her to start asking them.  I think that getting the questions out and asked now would be a great way to get started, for a couple of reasons.  First, the Summit is a ways away still, and it's unlikely that she's going to remember the questions.  Second, we don't know how the panel itself is going to go, so even if she did remember her "ton of questions", she may not be able to ask all of them.  Third, it's likely that some questions, and responses, are going to generate further questions, which themselves won't be asked due to time constraints.  Finally, it's unlikely that everyone is going to see the questions and responses, and it's likely that other panelists are going to have answers of their own.  So...I don't really see how someone asking their questions now is really going to take anything away from the panel that Suzanne Widup is putting together...if anything, I believe strongly that getting questions and answers out there now is going to make the panel that much better.

So, I scooped up some of the questions from her tweets, and decided to answer them via a medium more conducive to doing so, and here are my answers...

Forensics research is constantly in a state of new discovery. When does one stop researching and start writing?

The simple answer is that you're going to have to stop researching and start writing at some point.  It's up to you to decide, based on your topic, what you want to address, your outline, your schedule, etc.  The best advice I can give about this is to write the book the way you'd write a report...you'll want to be able to explain to a client (or anyone else) how you reached your conclusions 6 months or a year later, right?  The same holds true for the book...explain what you were doing in your research, in a clear and concise manner.  That way, if someone comes to you with a question about a new discovery after the book is published, you can discuss this new information intelligently.

Publishing Timelines
One thing to keep in mind about writing books is that the book doesn't immediately go to print as soon as "put down your pen". Rather, once you've completed writing the manuscript, it goes into a review process (separate from the technical review process) and the proofs are then sent to you for review. Once you approve the proofs and send them back, it can be 2 or 3 more months before the book is actually available on shelves.  So, the simple fact is that a published book is always going to be just a bit behind new developments.  However, that doesn't make a book any less valuable...there are always new people coming into the field, and none of knows everything, so a well-written book is going to be very useful, regardless.

If new research disproves something that you wrote, does it work against you later as an expert witness?

With respect to this question, writing a book is no different from conducting analysis and writing a report for a client.  Are you going to write something into a report that someone working for the client is going to disprove in a week or two when they read it?  If you found during your analysis that malware on the system had created a value beneath the user's Run key in order to remain persistent, are you going to say in your report that the malware started up each time the system was booted?  No, you're going to say that it was set to start whenever the user logged in, and because you did a thorough analysis, which included creating a timeline of system activity, you're going to have multiple data points to support that statement.

That is not to say that something won't change...things change all the time, particularly when it comes to DFIR work, and particularly with respect to Windows systems.  However, there's very likely going to be something that changed...some other application was installed on the system, some Registry value was set a certain way, a patch had been installed that modified a DLL, etc.

If you've decided to do "research" and add it to your book, do the same thing you would with a report that you're writing for a client.  Describe the conditions, the versions of tools and OS utilized, etc.  Be clear and concise, and if necessary, caveat your statements as necessary.

When I was writing the fourth edition of Windows Forensic Analysis, I wanted to include updated information regarding Windows 8 and VSCs in chapter 3, so I took what was in that chapter in the third edition, and I ran through the process I'd described, using an image acquired from a Windows 8 system...and it didn't work.  So, I figured out why, and was sure to provide the updated information in the chapter.

Something else to keep in mind is that most publishers want you to have a technical reviewer or editor, someone who will be reviewing each chapter as you submit it.  You can stick with whomever they give you, and take your chances, or you can find someone you know and trust to hold you accountable, and offer their name to the publisher.  This is a great way to ensure that something doesn't "slip through the cracks".  Like a report, you can also have someone else review your work...submit it to peer review.  This way, you're less likely to provide research and documentation that is so weak that it's easily disproved.

As to the part about being an expert witness, well...as Alissa said before, "forensics research is constantly in a state of new discovery".  I've never been an expert witness, but I could not imagine an attorney putting an expert witness on the stand to testify based on research or findings that are five years old, or so weak that they could be so easily disproved.   I mean, I'd hardly think that such a witness would qualify as "expert".

You all have to address time management as well - how did you juggle paid work/full-time job with book writing?

Short answer: you do.

Okay...longer answer:  This is something you have to consider before you even sign a contract...when am I going to write?  How often, how much, etc?

I learned some useful techniques while writing fitness reports in the Marine Corps...one being that it's easier to correct and modify something than it is to fill empty space.  Write something, then step away from it.  When I wrote fitreps, I'd jot some bullets down, flesh out a paragraph, and step away from it for a day or so.  Coming back to it later would give me a fresh perspective on what I was writing, allowing my thoughts to marinate a bit.  Of course, it also goes without saying that I didn't wait until the last minute to get started.

Something that I've recommended to folks before they start looking at signing a contract to have a book published is to try writing a couple of chapters.  I will provide a template for them...the one that I use for my publisher...and have them try writing a chapter or two.  I think that this is a very good approach to getting folks to see if they really want to invest the time required to write a book.  One of the things I've learned about the DFIR community, and technical folks as a whole, is that people really do not like writing...case notes, reports, books, etc.  So the first hurdle is for a potential author to see what it's like to actually write, and it's usually much harder if they haven't put a good deal of thought into what they want to write, and they haven't started by putting a detailed outline together.  Once something is ready for review, I then offer to take a look at it and provide feedback...writing a book, just like a report, isn't about the first words you put down on paper.  Then the potential author gets to see what that part of the process is like...and it's like having to do 50 push ups, and then being told to do them over because 19 of them didn't count.  ;-)

So far, good questions.  Like I said, I think that getting some of these questions out there and answered now really doesn't take away from the panel, but instead, brings more attention to it.  And it appears that Suzanne agrees, so keep the questions coming...

Addendum:  Shortly after I tweeted this blog post, Corey Harrell tweeted this question:

What's the one thing you know now that you wish you knew writing your first book?

That it's so hard to get input or thoughtful feedback from the community.  Most often, if you do get anything, it's impossible to follow up and better understand the person's perspective.

Seriously...and I'm not complaining.  It's just a fact that I've come to accept over the years.

Most folks who do this sort of thing want some kind of feedback.  When I taught courses, I had feedback forms.  I know other courses, and even some conferences, include feedback forms.  It's this interaction that allows for the improvement of things such as books, open source tools, and analysis processes.  I'm a firm believer that it's impossible to know everything, but by engaging with each other, we can all become better analysts.  The great thing about writing a book, in this context, is that I've taken the first step by putting something out there to be scrutinized.

One of the things I've found over time is that my books have been and are being used in academic and training (government, military) courses.  This is great, and I really appreciate the fact that the course developers and instructors find enough value in my books to use them.  When I have had the chance to talk to some of these instructors, they've mentioned that they have thoughts on what could be done...what could be added or modified in the book...to make it more useful for their purposes.  When I've asked them to share their thoughts, or asked them to elaborate on statements such as "...cover anti-forensics...", most often, I don't hear anything.

Now and again, I do hear through the grapevine that someone has/had comments about a book, or specific material in one of my books, but what I've yet to see much of, beyond the reviews posted on Amazon, is thoughtful feedback on how the books might be improved.  That is not to say that I haven't received it...just recently I did receive some thought feedback on one of my books from a course instructor, but it was a one-shot deal and it's been impossible to engage in a discussion so that I can better understand what they're asking.

Had I known that when writing my first book, I would've had different expectations.

Blogging

I caught an interesting thread on Twitter last week..."interesting" in the sense that it revisited one of the questions I see (or hear) quite a bit in DFIR circles; that is, how does one get started in the DFIR community?  The salient points of this thread covered blogging (writing, in general) and interacting within the community.  Blogging is a great way for anyone, regardless of how long you've been "doing" DFIR, to engage and interact with the community at large.

Writing
Writing isn't easy.  I get it.  I'm as much a nerd as anyone reading this blog, and I feel the same way most of you do about writing.  However, given my storied background, I have quite a bit of experience writing.  Even though I was an engineering major in college, I had to take writing classes.  One of my English professors asked if I was an English major, saying that I wrote like one...while handing back an assignment with a C (or D) on it.  I had to write in the military....fitreps, jagmans, etc.  I had jobs in the military that required other kinds of writing, for different audiences.

Suffice to say, I have some experience.  But that doesn't make me an expert, or even good at it.  What I've found is that the needs of the assignment, audience, etc., vary and change.

So how do you get better at writing?  Well, the first step is to read.  Seriously.  I read a lot, and a lot of different things.  I read the Bible, I read science fiction, and I read a lot of first person accounts from folks in special ops (great reading while traveling).  Some of the stuff I've read recently has included:

The Finishing School (Dick Couch) - I've read almost all of the books Mr. Couch as published

Computer Forensics: InfoSec Pro Guide (David Cowen)

Do Androids Dream of Electric Sheep (Philip K. Dick)

I've also read Lone Survivor, American Sniper, and almost every book written by William Gibson.

Another way to get better at writing is to write.  Yep, you read that right.  Write.  Practice writing.  A great way to do that is to open MSWord or Notepad, write something and hand it to someone.  If they say, "....looks good..." and hand it back, give it to someone else.  Get critiqued.  Have someone you trust read what you write.  If you're writing about something you did, have the person reading it follow what you wrote and see if they can arrive at the same end point.  A couple of years ago, I was working with some folks who were trying write a visual timeline analysis tool, and to get started, the first thing the developer did was sit down with my book and walk through the chapter on timelines.  He downloaded the image and tools, and walked through the entire process.  He did this all on his own accord and initiative, and produced EXACTLY what I had developed.  That was pretty validating for my writing, that someone with no experience in the industry could sit down and just read, and the process was clear enough that he was able to produce exactly what was expected.

Try creating a blog.  Write something.  Share it.  Take comments...ignore the anonymous comments, and don't worry if someone is overly critical.  You can ignore them, too.

My point is, get critiqued.  You don't sharpen a knife by letting it sit, or rubbing it against cotton.  The way to get better as a writer, and as an analyst, is to expose yourself to review.  The cool thing about a blog is that you can organize your thoughts, and you can actually have thoughts that consist of more than 140 characters.  And you don't have to publish the first thing you write.  At any given time, I usually have half a dozen or more draft blog posts...before starting this post, I deleted two drafts, as they were no longer relevant or of interest.

Writing allows you to organize your thoughts.  When I was writing fitness reports for my Marines, I started them days (in some cases, weeks) prior to the due date.  I started by writing down everything I had regarding that Marine, and then I moved it around on paper.  What was important?  What was truly relevant?  What needed to be emphasized more, or less?  What did I need to take out completely?  I'd then let it sit for a couple of days, and then come back to it with a fresh set of eyes.  Fitreps are important, as they can determine if a Marine is promoted or able to re-enlist.  Or they can end a career.  Also, they're critiqued.  As a 22 yr old 2ndLt, I had Majors and Colonels reviewing what I wrote, and that was just within my unit.  Getting feedback, and learning to provide constructive feedback, and go a long way toward making you a better writer.

I included a great deal of my experiences writing reports in chapter 9 of Windows Forensic Analysis Toolkit 4/e, and included an example scenario (associated with an image), case notes and report in the book materials.  So, if you're interested, download the materials and take a look.

One of the tweets from the thread:

it's a large sea of DFIR blogs and could be very intimidating to newbies in the field. What can they offer that is not there

Let's break this down a bit.  Yes, there are a lot of DFIR blogs out there, but as Corey tweeted, The majority of the DFIR blogs in my feed are either not active or do a few posts a year.  The same is true in my feed (and I suspect others will see something similar)...there are a number of blogs I subscribe to that haven't been updated in months or even a year or more (Grayson hasn't updated his blog in over two years).  There are several blogs that I've removed, either because they're completely inactive, or about ever 6 months or so, there's a "I know I haven't blogged in a while..." post, but nothing more.

There's no set formula for blog writing.  There are some blogs out there that have a couple of posts a month, and don't really say anything.  Then there are blogs like Mari's...she doesn't blog very much, but when she does, it's usually pure gold.  Corey's blog is a great example of how there's always something that you can write about.

...but I'm a n00b...
The second part of the above tweet is something I've seen many times over the years...folks new to the community say that they don't share thoughts or opinions (or anything else) because they're too new to offer anything of value.

That's an excuse.

A couple of years ago, one of the best experiences in my DFIR career was working with Don Weber.  I had finished up my time in the military as a Captain, and Don had been a Sgt.  On an engagement that we worked together, he was asking me why we were doing certain things, or why we were doing things a certain way.  Don wasn't completely new to the DFIR business, but he was new to the team, and he had fresh perspective to offer.  Also, his questions got me to thinking...am I doing this because there's a good reason to do so, or am I doing it because that's the way I've always done it?

One of the things that the "...I'm a n00b and have nothing to offer..." leads to is a lack of validation within the community.  What do I mean by that?  Well, there's not one of us in the field who's seen everything that there is to see.  Some folks are new to the field and don't have the experience to know where to look, or to recognize what they're seeing.  Others have been in the field so long that they no longer see what's going on "in the weeds"; instead, all they have access to is an overview of the incident, and maybe a few interesting tidbits.  Consider the Poweliks malware; I haven't had an investigation involving this malware, but I know folks who have.  My exposure to it has been primarily through AV write-ups, and if someone hadn't shared it with me, I never would've known that it uses other Registry keys for persistence, including CLSID keys, as well as Windows services.  My point is that someone new the community can read about a particular malware variant, and then after an exam, say, "...I found these four IOCs that you described, and this fifth one that wasn't in any of the write-ups I read...", and that is a HUGE contribution to the community.

Even simply sharing that you've seen the same thing can be validating.  "Yes, I saw that, as well..." lets others know that the IOC they found is being seen by others, and is valid.  When I read the Art of Memory Forensics, and read about the indicator for the use of a credential theft tool, I could have left it at that.  Instead, I created a RegRipper plugin and looked for that indicator on cases I worked, and found a great deal of validation for the indicator...and I shared that with one of the book authors.  "Yes, I'm seeing that, as well..." is validating, and "...and I'm also seeing this other indicator..." serves to move the community forward.

If you're not seeing blog posts about stuff that you are interested in, reach out and ask someone.  Sitting behind your laptop and wondering, "...why doesn't anyone post about their analysis process?" doesn't inherently lend itself to people posting about their analysis process.  Corey's post about his process, I've done it, Mari's done it...if this is something you like to see, reach out to someone and ask them, "hey, could you post your thoughts/process regarding X?"

As Grayson said, get out and network.  Engage with others in the industry.  Reading a blog is passive, and isn't interacting.  How difficult is it to read a blog post, think about it, and then contact the author with a question, or post a comment (if the author has comments enabled)?   Or link to that blog in a post of your own.

Not seeing content that you're interested in in the blogs you follow?  Start your own blog.  Reach out to the authors of the blogs you follow, and either comment on their blogs or email them directly, and share your thoughts.  Be willing to refine or elaborate on your thoughts, offering clarity.  If you are interested in how someone would perform a specific analysis task, be willing to offer up and share data.  It doesn't matter how new you are to the industry, or if you've been in the industry for 15 years...there's always something new that can be shared, whether it's data, or even just a perspective.

Blogging is a great way to organize your thoughts, provide context, and to practice writing.  Who knows, you may also end up learning something in the long run.  I know I have.

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.  

On Writing (DFIR) Books

After sharing my recent post regarding my next book, IWS, one of the comments I received via social media was a tongue-in-cheek reference to me being a "new" author.  I got the humor in that right away, but it also got me to thinking about something that I hadn't thought about in a while...what it actually takes to write a DFIR book.  I've thought about this before, at considerable length, because over the years, I've talked to others who have considered going down that path but for whatever reason, were not able to complete the journey.

Often times, the magnitude of the endeavor can simply overwhelm folks.  In some cases, events turn out to be much less easy to manage than originally thought.  In one instance, I was once asked for advice from a friend...he and two co-authors had worked through the process of establishing a contract for a book with a publisher.  It turned out that after the contract was signed, the team was assigned an editor, who then informed them that there was an error in the contract; they needed to deliver twice as many words than were previously stated, with no extension on the delivery date.  Needless to say, the team made the decision to not go forward with writing the book.

To be honest, one of the biggest challenges I've seen over the years is the disparity between the publishing company and their SOP, and the authors.  It took me a while to figure this out, but the publishing company (I can't speak to all publishing companies, just the three I've been associated with...) look to objective measures; word counts, numbers of chapters, numbers of images or figures, etc.  I would think that schedules are pretty much universal, as we all deal with them, but some publishing companies are used to dealing with academia, for whom publishing is often an absolute necessity for survival.  For many of those within the DFIR community who may be considering the idea of becoming a published author, writing a book is one of many things on an already crowded plate.

The other side of the coin is simply that, in my experience, many DFIR folks do not like to write, because they're not good at it.  One of the first company's I worked with out of the military had a forensics guy who apparently did fantastic work, but it took two other people (usually) to turn his reports into something presentable for review...not for the client, but for someone on our team to review before sending them to the client.  I recognize that writing isn't something people like to do, and I also recognize that my background, going back to my time on active duty, includes a great deal of writing (i.e., personnel evaluations/fitness reports, JAG manual investigations, etc.).  As such, I approach it differently.  I documented that approach to some extent in one of my books, providing a chapter on...wait for it...writing reports.  Those same techniques can be used in writing books.

I've been with essentially the same publishing company (that's not to say the same editor, and I haven't worked with the same individuals throughout) since my second book (Elsevier bought Syngress), so needless to say, I've seen a great deal.  I've gone through the effort (and no small amount of pain) and trials to get books published, and as such, I've learned a great deal along the way.  At the same time, I've talked to a number of friends and other folks within the DFIR community who've expressed a desire to write a book, and some who've already demonstrated a very good basis for doing just that.

Sometime ago, in a galaxy far, far away, I engaged with my editor to develop a role for myself, one in which, rather than writing books, I engaged with new authors as a liaison.  In this role, I would begin working with aspiring authors in the early stages of developing their ideas, and help them navigate the labyrinth to getting a book published.  I basically sat down and asked myself (after my fourth or fifth book had been published), "what do I know now that I wish I'd known when writing my first book?"  Armed with this information, I thought, here's a great opportunity to present this information to new authors ahead of time, and make the process easier for them.  Or, they may look at the scope and range of the process, and determine that it's not for them.  Either way, it's a win-win.

Also, and I think that this important to point out, this was not a paying position or role.  There are significant cultural differences between DFIR practitioners, and a publisher of predominantly academic books, and as such, this role needed to be socialized on both sides.  However, before either editor could really wrap their heads around the idea, and socialize it with the publishing company, they moved on to other adventures. 

As such, I figured that a good way to help folks interested in writing a book would be to provide some initial thoughts and advice, and then let those who are interested take it a step or two beyond that.

The Idea
All books start with an idea.  What is the basis for what you want to write/communicate?  When I started out with the Windows Forensic Analysis books, the basic idea I had in mind was that I wanted to write a book that I'd want to purchase.  I'd seen a number of the books that were out there that covered, to some extent, the same topic, but not to what I saw as the appropriate depth.  I wanted to be able to go to a bookstore, see a book with the words "Windows" and "forensics" on the spine, and upon opening it, have it be something I'd want to take to the register and purchase. 

Something else to consider is that you do not have to have a new or original idea.  I wrote Windows Registry Forensics because there was nothing out there like it.  But I wrote Windows Forensic Analysis because I wanted to take a different approach to what was already out there...most of what I found didn't go into the depth that I wanted to see.

When I was employed by SecureWorks, I authored a blog post that discussed the use of the Samsam ransomware.  Kevin Strickland, a member of the IR team, took a completely different approach in how he looked at some of the same data, which ended up being one of the most quoted Secureworks blog posts for the entire 2016 year.  My point is that it doesn't always take an original idea...sometimes, all it really takes is a different way of looking at the same data.

Structure Your Thoughts
It may not seem obvious, but structuring your thoughts can go a LONG way toward making your project an achievable success.

The best way to do this, that I've found, is to create a detailed outline.  Actually write down your thoughts.  And don't think you have to do it all at once...when I wrote personnel evaluations in the military, I didn't do it one sitting, because I didn't think that would be fair to my Marines.  I did it over time...I wrote down my initial thoughts, then let them marinate, and came back to them a day or two later.  The same thing can be done with the outline...create the initial outline, and then walk away from it.  Maybe socialize it with some co-workers, discuss it, see what other ideas may be out there.  Take some of the terms and phrases you used in your outline, and Google them to see what others may be saying about them.  You may find validation that way, like, "yeah, this is a good idea...", or you may find that others are thinking about those terms in a different way.  Either way, use time to develop your ideas. I do this with my blog posts. Something to realize is that the outline may be a living document; once you've "completed it", it will likely change and grow over time, as you grow in your writing.  Chapters/thoughts may be consolidated, or you may find that what you thought would be one chapter is actually better communicated as two (or more) chapters.  And that's okay.

What I've learned over the years is that the more detailed your outline is, the easier it is to communicate your ideas to the publisher, because they're going to send your idea out to others for review.  Much like a resume, the thought behind your outline is that you want to leave the person reviewing it no other option than to say, "yes"...so the clearer you can be, the more likely this is to happen.  And the other thing I've learned is that the more detailed the outline, the easier it is to actually write the book.  Because you're very likely going to be writing in sections, it's oh, so much easier to pick something back up if you know exactly where you left off, and a detailed outline can help you with that.

Start Writing
That's right...try writing a chapter.  Pick one that's easy, and see what it's like to actually write it.  We all have "life", that stuff we do all the time, and it's a good idea to see how this new adventure fits into yours.  Do you get up early and write before kicking off your work day, or is your best time to write after the work day is over?

Get someone to take a look at what you've written, from the perspective of purchasing the finished product.  We may not hit the bull's eye on the first few iterations, and that's okay. 

Reviews
Get your initial attempts reviewed by someone you trust to be honest with you.  Too many times over the years, I've provided draft reports for co-workers to review, and within 15 minutes received a just "looks good".  Great, that makes me feel wonderful, but is that realistic for a highly technical report that's over 30 pages long?  In one particular instance, I rewrote the entire report from scratch, and got the same response within the same time frame, from the same co-worker.  Clearly, this is not an honest review.

In the early stages of writing my second book, I had a reviewer selected by the publishing company, and I'd get chapters back that just said, "looks good" or "needs work".  From that point on, I made a point of finding my own reviewer and making arrangements with them ahead of time to get them on-board with the project.  What I wanted to know from the reviewer was, does what I wrote make sense?  Is it easy to follow?  When you're writing a book based on your own knowledge and experience, you're very often extremely close to and intimate with the subject, and someone else how may not be as familiar with it may need a bit more explanation or description.  That's okay...that's what having a reviewer is all about.

At this point, we've probably reached the "TL;DR" mark.  I hope that this article has been helpful, in general, and more specifically, if you're interested in writing a DFIR book.  If you have any thoughts or questions, feel free to comment here, or send them to me.

Wait...There's More...

Tools
Mari posted to her blog again not long ago, this time sharing a description of a Mac artifact, as well as a Python script that implements her research and findings, and puts what she discussed in the hands of anyone using it.

Yes, Mari talks about a Mac artifact, and this is a Windows-based blog...but the point is that Mari is one of the very few members of the DFIR community who does something like this; identifies an artifact, provides (or links to) a clear description of that artifact and how it can be used during an examination, and then provides an easy-to-use tool that puts that capability in the hands of every analyst.  While Mari shared that she based the script off of something someone else shared, she found value in what she read and then extended the research by producing a script.

Speaking of tools, Pasquale recently posted to the SANS ISC Handler's Blog regarding something they'd seen in the Registry; it's a pretty fascinating read.

Report Writing
I recently ran across James' blog post on writing reports...it's always interesting to hear others thoughts on this particular aspect of the industry.  Like everyone else who attended public school in the US, I never much liked writing...never really got into it.  But then, much like the justifications we try to use with math ("I'll never use this..."), I found that I ended up using it all the time, particularly after I got out of college.  In the military, I wrote JAGMAN investigations, fitness reports (I still have copies of every fitrep I wrote), and a master's thesis.

Writing is such an important aspect of what we do that I included a chapter on the topic in Windows Forensic Analysis 4/e; Mari included a mention of the report writing chapter in her review of the book.  After all, you can be the smartest, best analyst to ever walk the halls of #DFIR but if you can't share your findings with other analysts, or (more importantly) with your clients, what's your real value?

As James mentioned in his blog post, we write reports in order to communicate our findings.  That's exactly why I described the process that I did in the book, in order to make it easier for folks to write clear, concise reports.  I think that one of the biggest impediments to report writing right now is social media...those who should be writing reports are too impatient to do so because they're minds are geared to immediate gratification of clicking "Like" or retweeting a link.  We spend so much time during the day feeling as if we've contributed something because we've forwarded an email, clicked "Like" on something, or retweeted it that our ability to actually communicate with others has suffered. We may even get frustrated with others who don't "get it", without realizing that by forcing ourselves into a limitation of 140 characters, we've prevented ourselves from communicating clearly.
Think about it.  Which would you rather do?  Document your findings in a clear concise report to a client, or simply tweet, "U R p0wned", and know that they read it when they click "Like"?

Look, I get that writing is hard, and most folks simply do not like to do it.  It usually takes longer that we thought, or longer than we think it needs to, and it's not the fun, sexy part of DFIR.  Agreed.  However, it is essential.  When we write the report, we build a picture of what we did and what we found, with the thought process being to illustrate to the client that we took an extremely comprehensive approach to our analysis and did everything that we could have done to address their issue.

Remember that ultimately, the picture that we paint for the client will be used to as the basis for making critical business decisions.  Yes, you're right...we're not always going to see that.  More often than not, once we send in our report to a client, that's it...that's the final contact we have with them.  But regardless of what actually happens, we have to write the report from the point of view that someone is going to use our findings and our words as the basis for a critical business decision.

Another aspect of report writing that James brought up is documenting what we did and found, for our own consumption later.  How many times have we seen something during an examination, and thought, "oh, wait...this is familiar?"  How many times have we been at a conference and heard someone mention something that rang a bell with us?  Documentation is the first step to developing single data points into indicators and threat intelligence that we use in future analysis.

WRF 2e Reviews
Speaking of books, it looks like Brett's written a review of Windows Registry Forensics 2/e up on Amazon.  Thanks, Brett, for taking the time to put your thoughts down...I greatly appreciate it.

Writing Books, pt IV

Okay, by now, you've probably/likely decided to write that book, and that you've opted to do so through a publisher to get it on the bookshelves and onto Kindles and other ereaders. Remember, this isn't the only way to get something published, but it is one of the only ways to get your book published and have someone else take care of getting it on shelves and in front of your intended audience through Amazon, etc. Your alternatives include self-publishing through sites like Lulu.com, or simply writing your "book" and printing your manuscript to a PDF file, rather than a printer. There are advantages and disadvantages to each approach, but we're going to go with the assumption that you'll be working with a publisher.

Working with the publisher
When you're working with the publisher, don't set your expectations (at all, or too high) of what that's like ahead of time. Remember, the publisher's staff are people, too, and may be working with multiple authors. You very likely won't be the only author that they're working with, nor the only schedule. In addition, remember that in the current economy many people are wearing multiple hats in their jobs...so the editor you're dealing with may not get your email because they're traveling or at a book show. I've worked with staff who, in 2009/2010, do not have remote access to their email (can you imagine that??), so I won't hear back from them for weeks at a time.

While working with the publisher, I've had editors and even editors assistants changed part way through the writing process. The result was that chapters that I had sent in for review could no longer be found. I know this sounds like a bit much, but keep track of what you send in, when, and to whom. This can really help...particularly in instances where you have to resend things.

One of the things I've run into several times is that I've submitted what I thought was everything...DVD contents, revised chapters, etc...and asked the staff I was working with if everything was received, and if I needed to provide anything else. I'd been told, no, that's everything...only to be contacted three weeks later and told that something else was needed (review the proofs, provide a bio, etc.). The key to this is to see what's in other books, and keep a list of what you've provided...have you written a preface yet? A bio? How about that acknowledgment or the dedication page?

In short, be flexible. Focus on meeting your schedule in the contract. If you're not going to meet the schedule for some reason, do the professional thing and let them know ahead of time. Don't worry about what anyone else does or is doing. In the long run, it'll help.

Working with reviewers
When you're working with reviewers, keep in mind what their role is in the process. They're generally there to review your work, so don't take what they say or comment on personally.

There are generally two kinds of reviewers...those who do the grammar, spelling and formatting review for the publisher (they tend to work for the publisher), and those who are supposed to review your work from a technical perspective, to ensure that it's accurate (although why you'd put that amount of time into writing something that is completely off base, I have no idea). Generally speaking, whatever the grammar/spelling reviewer suggests is probably advisable to accept. However, this won't always be the case, particularly when you've written a turn of phrase that you really want to use, or are using acronyms specific to your field. I remember that I had an issue with the acronym "MAC"...did it refer to file "MAC" times, or to a NIC's "MAC" address? Kind of depended on the chapter and context.

As far as your technical reviewers go, that's another story. There's no reason that you have to accept any of their proposed changes, or follow what their comments say. Hey, I know that's kind of blunt, but that's the reality of it. In every book I've worked on, to my knowledge, the technical reviewer has had no prior contact with me, my book proposal, or my thought process prior to getting my draft chapters. Therefore, they are missing a great deal of context...and in some cases, their comments have made little sense when you consider the overall scope and direction of the book.

For some reason, the publishing process seems to be something of a maze of Chinese walls. You get an author who's writing a technical book, working with a publisher who knows publishing, but not the subject that's being addressed. One person reviewing the book and working for the publisher knows spelling, grammar, and formatting, and that's good...but often times, the technical reviewer may not know a great deal about the subject being addressed, and knows nothing at all about the author, the goals and direction of the book, or much in the way of overall context. In my mind, this is just a short-coming of the process, and something that you need to keep in mind. I've worked with a LOT of folks with respect to writing technical reports, and there are generally two things that most folks do with suggested changes and comments...they either accept them all unconditionally, or they delete and ignore them. I would suggest that when you are going through the document that you receive back from the technical reviewer, make your changes and add your own comments to theirs, justifying your actions. Then save the document, copy it, and (if it's written in MSWord) run the copy through the document inspection process, accepting the edits and removing comments. That way, you have a clean copy to send back, but you also have a clear record of what was suggested and what you chose to do about it.

Another thing to keep in mind is that people have varying schedules...if you submit a couple of chapters and you feel that you aren't getting much in the way of a review, or one that's technical, get in touch with the editor and request someone else. Or, suggest someone to them up front...after all, if you really know the subject that you're writing about, you will likely know someone else in the field who (a) knows enough about it to review your work, (b) has the time to do a good review, and (c) has the interest in working with you. I've had folks offer to review my work completely aside from the publisher...that's okay, too, but it also means you may submit a chapter and not hear back at all. Remember, in the technical field, you don't make enough money to support yourself writing books, so neither writing nor reviewing books is a full-time job, and people have day jobs, too.

Working with co-authors
Writing a book as the sole author can be tough, as it is a lot of work...but I think that writing a book as multiple authors, particularly when none of the authors ever actually sit in a room together, is much harder. There are a lot of decisions that need to be made and coordinated ahead of time, and continually revisited throughout the process. Again, writing books in this field is NOT a full-time job...as such, people's day jobs and lives tend to take precedence. Family illness, holidays, vacations, etc., all play a role in the schedule that needs to be worked out ahead of time.

Another thing to consider is that someone has to take the lead on tone...or not. You need to decide early on what the division of labor will be (split up chapters or sections), and whether or not you feel it's important to have a single tone throughout the book. There will be times when it makes sense to have a single tone, and there will be other times when it's pretty clear that you aren't going to have a single tone, as the various authors take the lead on the chapters for which they have the most expertise in the subject matter.

Providing Materials With Your Book
I'm one of those folks who writes some of my own code, and I tend to create my own tools, whether they be a batch file or a Perl script. As such, it's helpful to others if I make those tools available to them in some manner, and this is often done by putting those tools on a CD or DVD included with the book. I think that a lot of times, this increases the value of the book, but it can also be a bit difficult to deal with...so how you provide the materials is something to consider up front. Another item that a lot of folks find interesting and very valuable is "cheat sheets"...if you list or explain a process in your book, and it covers a good portion of a chapter, it might be a good idea to provide a cheat sheet that the reader can print out (perhaps modify to meet their own needs) and use. How you intend to provide these, and other materials (i.e., videos that show the viewer how to do something step-by-step, etc.) is something that you need to consider ahead of time.

The point is that if there are materials you're going to refer to in your book, you have to figure out ahead of time how you're going to provide them. In my experience, there's two ways you can do this...provide the materials on the DVD that comes with the book, or provide them separately. I have usually opted to provide the materials on a DVD, but after having written a couple of books, I think I'm going to move to something completely separate, and provide the materials online.

I have decided to do this for a couple of reasons. One is that there's always someone out there who ends up purchasing a copy of the book that mysteriously doesn't have a DVD. Or they loose the DVD. Or they leave it at home or at work, when they need it in the other location. Then there's the folks who purchase ebooks for their Kindle or other ereader, and never got the email that says, "...go here to download additional content." Or they did, but the publisher modified their infrastructure so now the instructions or path aren't valid. And, of course, there's always the person who's going to contact you directly because they want to ensure that they have the latest copy of the materials.

My thinking is that a lot of these issues can be avoided if you choose a site like Google Code or something else that is appropriate (and relatively stable/permanent) for hosting your additional materials. That way, you can control what's most up-to-date and not have to rely on someone else's schedule for that. You can refer to the actual tools (and other materials) in the book, so that having the book itself makes the tools more valuable, but by providing them on the web, you can include "here are the absolute latest, newest, most up to date copies" on the page where the reader will go to download those tools.




Self-Marketing
Blogging is a great way to get started and get the feel for writing, without the constraints of editing (and things like spelling, grammar, etc.). Face it, some folks don't take criticism of any kind well, and don't put a great deal stock in checking their own spelling and grammar...so blogging is sort of a way to get into writing without having someone looking over your shoulder. It's also a great way for some folks to realize how important that sort of thing is.

Blogging is also a great way to self-market your book, prior to and following publication. It's a great way to start talking about the book, to answer questions that you get about your book and materials, address errata, etc. In some ways, a blog can also lay the groundwork for a second edition, or even just for your next effort, as you get feedback, read reviews, post new ideas, etc. For example, if you start to see that your book on forensic analysis is linked to another blog on malware reverse engineering, with that author making comments about what you've written (positive or negative), that could be a good indicator for you...what do you need to improve on, expand on, and what were you dead on with in your book?

Take the lead on marketing your book. Present the publisher with ideas, and take the lead on getting the word out there (assuming that that's what you want). When WFA 2/e was coming out, I was excited because this was the first book in a new direction that Syngress was going, something that was exemplified by the new cover design. That summer, the SANS Forensic Summit was going to be in Washington, DC, and I was attending as a speaker. As I looked more and more into the conference, and who was speaking and attending, I counted almost half a dozen Syngress authors who would be there, all of whom had the work "forensics" in their book title. I contacted the publisher to find out if they'd have a bookstore...I thought, between sessions I could answer questions about the book. Well, it turns out that they had NO PLANS for a bookstore!! I thought (and said to them), you've GOT to be kidding me! Here's a conference with "forensics" in the title, and all these authors of "forensics" books will be there...to me, it was a total marketing coup. The short story is that the editor was there with books on a table and it was a huge success for everyone.

Final Thoughts...
And now, some final thoughts as I close out this series of posts.

I hope that in reading these posts, you've enjoyed them and at the same time gotten something out of them. I tend to take something of a blunt approach, in part because I don't want to sugarcoat things for someone who's considering writing a technical book. Yes, it is hard...but if you know up front what you may be facing, you're less likely to let it slow you down. One of the hardest things about writing books is that you're rarely, if ever, face-to-face with anyone from the publisher's staff when discussing your book. In fact, you're rarely face-to-face with anyone throughout the process.

One of the misconceptions a lot of folks who have never written a book have about authors is that they retain some modicum of control over what happens with the book once it's submitted to the printer. Nothing could be further from the truth. When WFA 1/e was released by Syngress, a PDF version of the book was available...for the first couple of weeks, it was provided with each copy of the book purchased through the Syngress web site. After that, it was available for purchase. Later, Syngress was purchased by Elsevier, a company out of Europe that produced all e-format versions of its books EXCEPT PDF. The author's role in any of that, particularly in the availability of a PDF version of their book, is zero. And I say that only because there's nothing less than zero.

Another misconception that I've run across is that most folks think that book authors have access to endless resources, or that somehow, the publishing company will provide those resources. This simply isn't the case. When I submitted the proposal for the Registry forensics book, all of the reviews came back saying that I needed to include discussion of the use of commercial tools, such as EnCase and FTK. Well, the short answer was "no"; the long answer was that I neither have access to, nor have I been able to obtain a temporary license for either...and none of the reviewers was offering such a license. In all fairness, I will say that I was offered a temporary license to one of the commercial tools, but by the time that offer was available, I was too far into the writing process to go back and add that work and material into the book. I would have been particularly time consuming because I don't use those tools regularly. Anyway, my point is that when I have written my books, I tend to do so based on my own experiences, or those interesting experiences that others have shared. I tend not to write about ediscovery, because I've never done it. I likely won't be writing about Registry analysis of a Windows-powered car or Windows 7 phone, because I neither own nor have access to either, nor do I have the tools available to work with either. Like most authors, I don't have access to massive data centers for testing various operating systems and application installations across numerous configurations.

Keep in mind that your book is not going to be everything to everyone. You're going to have critics, and you're also going to have "armchair quarterbacks". You're going to have people who post to public forums that you "should've done this...", and not once have a good thing to say about your work. You're going to have folks who will email you glowing commendations for what you've done, but not post them publicly...even when they purchased your book based on a publicly-posted review. Don't let any of this bother you. One of my good friends who's also written a book has received some not-so-glowing criticism, to which he's responded, "...come see me when you've published a book." In short, don't let criticism get you down, and don't let it be an obstacle that prevents you from writing in the first place.

Finally, I want to say once again that writing technical books is tough. It's tough enough if you're a single person and not at all used to writing. If you're married (particularly newly married) and/or have small children, it can be logarithmically harder, and it will require even more discipline to write. However, it can also be extremely rewarding. Seeing your work published and sitting on a bookshelf is very rewarding. Think about it...you've completed and achieved something that few others have attempted. If you've put the effort in and done the best you can, you should take pride in what you've done...and don't let the little things becomes insurmountable obstacles that prevent you from even trying.