On Writing DFIR Books, pt II

Part I of this series kicked things off for us, and honestly I have no idea how long this series will be...I'm just writing the posts without a specific plan or outline for the series. In this case, I opted to take an organic approach, and wanted to see where it would go.

Content
Okay, so you have an idea for a book, but about...what? You may have a title or general idea, but what's the actual content you intend to write about? Is it more than a couple of paragraphs; can you actually create several solid chapters without having to use a lot of filler and fluff? Back when I was actively writing books, this was something on the forefront of my mind, not only because I was writing books, but later I got a question or two from others along these lines.

In short, I write about stuff I know, or stuff I've done. Not everything I've written about came from work; a good bit of what I've written about came from research I'd done, either following up on something I'd seen or based on an idea I had. For example, during one period not long after we'd transitioned to Windows 7, I wanted to follow up on creating, using and detection NTFS alternate data streams (ADSs), and I'd found some content that provided alternate means for launching executables written to ADSs. I wanted to see if ADSs were impacted by scripting languages, and I added the results of what I found to the book content.

A number of years ago, I had access to an MSDN account, and that access was used to install operating systems and applications, and then to "see" the toolmarks or artifact constellations left behind by various activities, particularly identifying the impact of different applications and configurations. Unfortunately, the MS employee who'd provided me with the account moved on, and the license eventually expired, which was unfortunate, as I was able to see the impact of different activities not only with respect to the operating system, but also with respect to different application suites.

Sources of content can include (and in my case, have included) just about anything; blog posts, blog post drafts, presentation materials, the results of ad hoc testing, etc. 

Outline
Something I've learned over the years is that the easiest way to get started writing book content is to start with an outline. The outline allows (or forces) you to organize your thoughts into a structured format, and allows you to see the flow of the book from a high level. This also allows you to start adding flesh to the bones, if you will, seeing where there structure is and adding that content we talked about. It also allows you see where there is value in consistency, in doing the same or similar writing (or testing) in different locations in the book (i.e., "chapters") in order to be as complete as possible. A well-structured outline will allow you to see gaps.

Further, if you have a well-structured outline that you're working from, the book almost writes itself.