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?
No comments:
Post a Comment