Report Writing

I was responding to an email this morning, discussing what I'm including in my next book (or could include) with someone, and he brought up a subject that I hadn't thought of...there are no resources out there for writing reports. And we all know how much technical nerds and security geeks love to write reports.[/sarcasm mode=off]

My first thought on this was, well, everyone has different requirements. I mean, an internal security guy in an FTE position has different requirements for his reports than a consultant does (I've done both), and those are different from LE requirements.

As I started to think more about that, it occurred to me that there are some commonalities in how reports can/should be written, and that perhaps by addressing and discussing them, maybe we can clear up some of the mystery behind the topic.

Before we start, let me give you a bit of context. I started "learning" to write in the military, and the most consistent thing I wrote there were personnel reviews. I had to do a thesis in graduate school, and in addition to reports I've written as a consultant and in FTE positions, I've written numerous articles and a book. However, this does NOT make me an expert, so I don't claim to be. Based on my experience, I have developed a style of writing, and when I'm writing a report for a client, I'm still going to feel better if I have someone review it.

That being said, there are a couple of general guidelines I follow when writing my reports.

Follow the KISS principle
Does this mean you should put on a wild, skin-tight suit, paint your face with black and white makeup, and present your report to the client in heavy metal? No. KISS = Keep It Simple, Stupid. This is a well-known, and yet oft-overlooked principle. Julius Caesar followed this principle...what's simpler than "Veni. Vidi. Vici."? I mean...really. How much more simple can you get?

An slight modification of this principle was passed down to me by a commanding officer. He held regular meetings, and as the CommO, I represented a technical discipline. He told me that when it was my turn to talk about issues in my department, if I couldn't summarize the issue on a 3x5 card in 3 (but no more than 5) bullet statements, then I didn't know the issue well enough. And you know something...15 yrs later, that's still true.

Keep the audience in mind
Remember who you're going to be talking to. I've found this to be an extremely valuable thing to remember, whether I was doing pen tests, vulnerability assessments, or now, when I perform forensic analysis. IT guys are usually pretty technical but the thing about consultants is that many times, we're less general than IT guys. Forensic analysts can be even more technically focused, so spilling our grey matter out onto paper isn't going to do much more than confuse some IT guys...what do you think it will do to the IT managers?

I'm not saying IT guys are dumb...that's not the case at all. However, the reason guys like us (consultants, LEs, etc.) get called on-site is usually because the client doesn't have the skill set, nor do they have the time, to perform the work they're asking/paying us to do. So performing the work is only half the battle...the real challenge is to communicate the results (of an assessment or analysis) to the client in a way they can understand and use.

If you're sitting at home playing BuzzWord Bingo right now, put a marker over "value add".

That's our job as professionals. We provide "value add". Sure, we can image systems and dump spreadsheets and analysis in the client's lap, but why not simply tell them what we found?

Don't overwhelm the reader with technical information
This is a follow-on to the previous item. In knowing your audience and who's going to be reading the report, you don't want to overwhelm them with technical detail. For example, you can say "between these dates, these systems were subject to [un]successful XX attacks." You might even add "...a total of n times." That's much better than dumping a spreadsheet in the client's lap, with all of the data.

A good method of implementing this is to include an executive summary, something that someone at the management or senior management level can quickly read, and get an understanding of what went happened. The executive summary is best kept short, no longer than a page (unless absolutely necessary), and to the point. Follow that up with some technical detail, describing what happened, and the order in which it happened. Remember, when performing analysis, timeframes add context to what we do and see. The same thing is true for the client. Now, you don't need to give away your whole bag of tricks in this section, but you can and should provide some level of detail, so that your report has credibility. Finally, if you must provide the real down-in-the-weeds technical stuff, put it in a tabbed appendix, ordered by relevance.

If you don't know, and can't prove it, say it
This goes right along with Avoid speculation and too much interpretation, so I'm just going to combine the two. A lot of the reports I've read over the years having included too much of what can be referred to as "artistic license". A lot of really, really smart guys (every time I see this sort of thing, it's come from a guy, not a woman) like to show how smart they are, and many times will do so in their report. I'll give you an example. I've seen reports that will say things like, "the attacker was Russian." Well, how do you know that? Sure, you see in the logs that the attack came from an IP address assigned to the Russian Federation, and you may have found a binary file with Cyrillic characters in the name or strings in the file...but is that definitive? Do these two facts combine to make the original statement true? No, they don't.

One thing we're seeing a lot of in the media is the loss of sensitive data. In his BlackHat presentation, Kevin Mandia mentioned that clients are asking the question, "was sensitive data copied from the system?" Well, if you're looking at an image of a hard drive, what is your answer? In most cases, it's "we don't know, because there isn't enough information." Yes, you may see the sensitive data on the drive, and the last access times on the file(s) may correspond to when the intruder was on the system...but is that definitive proof that the data was actually taken?

Just this summer, the Veteran's Administration announced that they'd recovered a laptop that had been stolen...a laptop that contained a great deal of sensitive information. Media reports stated that the FBI had analyzed the laptop and determined that the data had not been compromised, yet the backlash in the public forums regarding this statement was incredible...and to some degree, correct. There are several ways, of varying technical sophistication, that could be used to copy the data from the hard drive without leaving obvious forensic artifacts.

So the point is, if you can't connect the dots, don't. There's an old saying that goes something like this..."it's better to keep your mouth shut and be thought a fool, than to open your mouth and remove all doubt." You may be able to fully justify your thought processes to yourself, and you may become indignant when a co-worker, team member, or even your boss calls you on them, but what do you think will happen when the defense attorney does it?

Well, I hope these meager thoughts have been helpful. What hints, tidbits, or pointers do you use when writing reports?