Report Writing
A wise man once said, “If it’s not documented, it didn’t happen.” When it comes to computer security investigations, that phrase is the golden rule all practitioners should strive to follow. Writing accurate, complete, and readable reports that address the questions at hand and are completed in a timely manner is both very important and a major challenge. That challenge sometimes causes organizations to make poor decisions about documentation when an incident occurs. There may come a day, however, that the fate of an organization or individual lies with the content of a report. Because we cannot predict the future, all reports we write must meet a minimum set of requirements—no exceptions. When that day of judgment arrives and it involves a report you wrote, you will sleep well knowing that your report will stand up to scrutiny. In this chapter, we focus on sharing our lessons learned in report writing.
WHY WRITE REPORTS?
One of the first questions you may ask about report writing is why it’s even necessary. Sometimes the reason is straightforward—there may be legal or policy requirements, or perhaps your boss asked you to create a report. Other times, there may not be compelling reasons to write a report. However, we recommend you create a report any time you analyze evidence or respond to an incident, no matter how small or large, whether there were findings or not. Some individuals may question the usefulness of that approach, but we believe it is a core part of incident response and computer forensics. Let’s take a moment to elaborate on that stance.
At the basic level, our job is to examine evidence to answer questions. A legal or administrative process is usually where the questions originate, and those processes are typically sensitive and may have a significant impact on people’s lives. We need to do our best to ensure the answers are correct and that they are accurately and clearly conveyed to the intended audience. Some would consider this a basic definition of forensic science—and they would be correct. In that context, it could be considered negligent if we did not create a report.
There are other less serious but still very important reasons for creating reports. Writing reports forces you to think about what you’ve done. Sometimes documenting all the facts on paper helps you see connections, or even uncover mistakes, that you didn’t notice before. The exercise of creating documentation may be what helps you crack the case. You can also use the content of a report in more than one deliverable. For example, when you have documented findings, it is much easier to provide input to status updates, transfer knowledge, and perform training.
Some situations may require there be no written documentation. The most common is when legal counsel has a concern related to discovery. In those cases, the deliverable is usually a verbal report. Whenever your case involves legal staff, be sure to discuss reporting guidelines and deliverables prior to starting any work. Make the legal staff aware of your standard documentation procedures, so they have the opportunity to catch any potential issues at the beginning of a case.
Forensic and incident response reports are closely scrutinized. This puts extreme pressure on the report writers to “get it right.” Because it’s rare that the early stages of an investigation will uncover all relevant facts, we recommend that you label any interim reports you create as “DRAFT.” Otherwise, subsequent changes or additions may be viewed as incompetence or deceit on your part. |
REPORTING STANDARDS
Whether you are writing a report for one of the reasons listed in the previous section or you have your own reasons, you will need to establish reporting standards to help ensure you create quality reports. In this section, we list the high-level goals of reporting and provide specific recommendations that, in our experience, are effective in helping to accomplish those goals.
• Focused List and answer relevant questions. Avoid off-topic discussion. The main questions and their answers should be easily found; the reader should not have to put pieces of information together from different parts of the report. The high-level goal is to determine and meet the requirement or objective of the report.
• Understandable Write with your audience in mind and use the fewest words necessary to effectively convey findings. For example, if the report is primarily for C-level staff (such as a CEO or CSO), you must write the report so it will be understandable and useful to them. This may require you to write an executive summary or other sections that effectively convey your findings to that audience.
• Stick to the facts Present unambiguous and correct information. Avoid terms or phrases that can be easily misinterpreted or are subjective. Always double-check that your statements are supported by, and consistent with, factual evidence. Do not intermingle fact with opinion.
• Timely Complete reports within a reasonable time frame. During an incident, timely reports may provide information that helps to prevent serious damage to an organization. One of the best ways to ensure timely reports is to write as you go. Never wait until you complete your analysis to begin documenting your findings.
• Reproducible The results in a report should be completely reproducible by a third party. Include the information necessary for a third party to reproduce your findings. For example, you may report that you recovered 10 RAR files during an examination. A third party may not be able to reproduce your findings if you do not include details about how you recovered the files and what location on the disk they were found. The description does not need to be lengthy; you can simply state that you searched unallocated space for the standard RAR file header, the hex sequence 0x52 0x61 0x72 0x21 0x1A 0x07 0x00. If you know the case is sensitive and expert testimony is likely, be sure to take that into consideration—you may want to include more detail.
We will cover many individual recommendations in this chapter, but in general reports should be focused, accurate, and concise. In other words, a report should clearly answer the questions that were asked with as few words as possible. A forensic report is not a work of art, nor is it an intellectual competition. A forensic report is a factual report of findings, with any opinions clearly identified and supported by facts that are in the report.
We sometimes get feedback that our standards seem arbitrary, are too hard to follow, or even conflict with common knowledge. Although some of our recommendations are quite different from what you might be used to, they are certainly not arbitrary and are even shared by others in the same situation as us—writing lots of technical reports. One example of writing guidelines that we are particularly impressed with is the document titled “Improving Your Technical Writing Skills” by Norman Fenton at the School of Electronic Engineering and Computer Science at Queen Mary (University of London). Mr. Fenton’s document repeats many of the points we make, and adds a few more topics and contains a very helpful selection of examples.
GO GET IT ON THE WEB
We encourage you to read his document in addition to this chapter. Then work hard at adopting these guidelines—although it may be challenging, you will most certainly produce better reports because of it.
The style guidelines we discuss are not meant to be hard-and-fast rules that cannot be broken or changed. The main intent of the style guidelines is to increase the readability of a report. In some cases, the guidelines happen to do the opposite. It’s the author’s responsibility to recognize those situations and adjust accordingly. Specific style recommendations include:
• Write in active voice Sentences written using an actor-verb construct are usually more clear and concise. Passive voice versions of active voice sentences always require more words, which increases the burden on the reader. For example, the following active voice sentence is five words total: “The attacker stole the data.” If we convert the sentence into passive voice, it requires two extra words, making the sentence seven words long: “The data was stolen by the attacker.” Some report authors will attempt to make up for this by leaving out the actor and write “The data was stolen.” Although this is a shorter sentence, it is undesirable because it is less specific.
• Write in past tense A rule of thumb with investigative reports is to write in past tense. All of the events that you are documenting happened in the past, so it makes the most sense to use past tense.
• Use concise sentences We're not sure what the record is, but in some reports we’ve seen sentences with more than 40 words. If a sentence is in the 20-word range, you are entering the danger zone. Sentences with 30 or more words should probably be rewritten.
• Be specific Avoid stating “several files were present in the directory” if you know, or you can determine, the exact number. In general, avoid terms such as “numerous,” “many,” “several,” “a few,” or other count-related words because they are subjective. Use the number! Also, avoid splitting up simple facts just to make short sentences. For example, state “A file named kout.dat contained the keylogger output” instead of “The keylogger placed its output in a file. The file was named kout.dat.”
• State what you did, not what you couldn’t do When findings are negative, use statements that explain what you did and what the outcome was. Avoid statements such as “could not recover the file” or “unable to …” These phrases could be misinterpreted as an indication of incompetence if you don’t include why you were unable to do something. For example, instead of “the analyst was unable to recover the deleted file,” perhaps state something like “the operating system reused the deleted file’s space, making the deleted file unrecoverable.”
• Use transitions We’ve found that report reading is easier if you follow the concept of “say what you are about to say, say it, and then summarize what you said.” Basically, it’s easier for a reader to digest new information if you provide them with a lead-in. For example, instead of a paragraph that just lists a number of files found in a directory and describes what they are, perhaps begin the paragraph by saying that the paragraph will provide details on three files located in a particular directory. This style of writing usually makes reports much more readable.
• Use acronyms correctly Using acronyms is a good way to save space, but be sure to spell them out the first time you use them. Even “common knowledge” acronyms should be spelled out because the same acronym could represent more than one thing. For example, DFS could mean Distributed File System, but maybe it’s Discover Financial Services or Dynamic Frequency Selection. Also, be sure you spell out the acronym correctly—do your research. For example, DNS stands for Domain Name System (not Server or Service).
• Avoid jargon and ambiguous words The term “exfiltrate” is computer security jargon, and we avoid using it in reports. A more appropriate term is something like “data theft,” a term that everyone understands. We also avoid ambiguous words such as “compromised.” Stating that a system is “compromised” is about equivalent to a doctor saying that you are “sick.” You probably already knew that. If you plan to understand and treat the condition, you need to know specifics. Be sure to include those specifics in a report.
• Use names consistently Choose appropriate designations and use them consistently throughout your reports. If you decide to call a computer a “system,” switching between other terms may cause confusion. For example, you might use “host” or “node” in the place of “system.” Later in your report, you may need to discuss a tree data structure. In that context, the term “node” has a very different meaning.
• Avoid informal language Avoid using informal phrases such as “checked out” instead of “examined,” “attacker got more access” instead of “attacker increased their access,” or “seemed funny” instead of “was anomalous.” Reports are not e-mails or text messages to friends; they are formal documents that represent you and your organization.
• Clearly identify opinion Opinions are useful to include when you expect the reader might not have the experience to realize what the most likely explanation for a series of events is. Sometimes, the customer may directly ask for your opinion. When offering an opinion in a report, be sure you clearly indicate a statement is an opinion. Always support opinions with facts that are also included in the report, so the reader can see the basis for your opinion. Opinions without supporting facts do not belong in forensic reports.
 |
In the U.S. legal system, reports that contain opinion are considered “expert reports.” The author of such a report is considered an “expert witness,” and both the report and the report author must meet qualifications to be accepted by a court. The recommendations we provide in this chapter will help meet the reporting requirements, but are certainly not a guarantee. Most of us will be lacking in personal requirements, such as having recent publications and trial or deposition experience. Unless you are confident that you qualify, it’s probably best to avoid offering opinions in reports that will be part of a legal process. However, in some situations, those opinions might be what are needed to turn the case. If you believe a particular opinion is valid and critical to the case, and you are not comfortable or eligible to act as an expert witness, you should seek out assistance from a qualified expert. |
In addition to style standards, which are for content, there are also formatting standards. Formatting standards apply to the presentation aspects of a report, such as font, date representation, figures, and tables. The following formatting areas are the most common:
• Use consistent font and spacing Select a font and spacing that enhances readability, and enforce the standard in all reports. Using more than one font is OK, as long as the use is consistent, such as selecting a fixed-width font for figures or source code excerpts. Do not use obscure or unprofessional fonts, such as Comic Sans and KaiTi. Some report writers may want to use personal preferences, but forensic reports are not the place for individual creativity.
• Dates and times Pick a standard for representing dates and times and enforce it. Your choice should represent dates and times in a fully unambiguous format. We recommend that dates be represented as “Month DD, YYYY,” such as September 28, 2012. A representation such as “05/05/05” should never be used, because it could be interpreted in at least three different ways. We document all times in the UTC time zone, and in 24-hour “military” style (for example, 17:03:12 UTC instead of 5:03:12 P.M. UTC.) We strongly recommend against using local time zones or “civilian” style time with A.M. and P.M. notations, as these formats inevitably lead to problems with event correlation and time conversion. This formatting standard only applies to dates that you write—do not change dates that are a part of evidence or created by forensic tools, for example.
• Standardize metadata reporting Create tables or other standard formats to document metadata associated with findings. For example, if the examination discovers a relevant file, the file’s name, timestamps, path, MD5, and other metadata should be documented in the same exact format, to include the fields reported, every time.
• Use captions and references We use Microsoft Word to author reports, which has built-in functions to create linked captions and references. We place consistent captions at the bottom of all tables and figures, and create a reference to them within the narrative. The reference should explain the table or figure—don’t leave it up to the reader to determine what table you are discussing.
• Use tables and figures appropriately When you need to present findings consisting of multiple records with multiple properties, a table format is often the most effective. For example, a table is an effective way to present web browser history records. If you need to include excerpts of file content, consider using a figure that has a fixed-width font and a border around the figure. Establish standard formatting, including font, borders, and shading, for both tables and figures. Remember to include captions, and reference those captions within the report narrative.
• Use bulleted and numbered lists when appropriate Paragraphs that discuss a long list of items tend to be difficult to read. In some cases, converting the paragraph into a numbered or bulleted list will make the information more readable.
Report Content and Organization
You should develop a report template for each major report type your organization produces. If you are considering multiple templates, be sure there is justification for the additional overhead. Minor differences can often be addressed in template notes. At the company we work for, three common templates are used as part of an incident response: an overall incident template, a general analysis template, and a malware analysis template. Let’s discuss what the common structure is for an overall incident report, as well as for analysis reports. In this chapter, we place all analysis reporting—forensic examination, live response, malware, and so on—into a single category.
The overall incident template is for a report on an entire incident, and includes all the analysis or other reports that were created during the incident. Because an incident report should be useful to a broad audience, it contains high-level summaries, mid-level details and connections, and the detailed individual analysis reports. Incident reports tend to be more difficult and time consuming to put together. They are comprehensive documents that not only include the results of the investigation, but also remediation recommendations. The following sections are common in most incident reports:
• Title page and table of contents A title page is required for an incident report. The title page lists the affected organization, a brief description of the report that normally includes the incident number or name, the date published, and the name of the organization that performed the investigation. When required, the title page also includes caveats and protective markings such as “Privileged and Confidential.”
• Background The incident background should describe how the incident was discovered, what was discovered, what the response was, and list the goals of the investigation. The background is normally about two paragraphs long. The background should specify the duration of work, including a start and stop date, and who sponsored the work.
• Findings The incident findings should directly address the goals of the investigation in a very clear and brief manner. The findings should be summaries of the information presented in the mid-level findings section. Because these findings are part of what is considered the executive summary, they should be readable by a broad range of audiences. The incident findings are usually no more than a page long.
• Recommendations Recommendations are categorized into short term and long term. Short-term recommendations are the actions that are expected to resolve the current incident. They can be completed in a short amount of time and will remove the current threat. Long-term recommendations will enhance the overall security posture of the organization and help to prevent future incidents.
• Mid-level sections Mid-level sections are where the findings from multiple individual analysis reports are aggregated, interpreted, and summarized. Mid-level section names vary, but should generally relate to the investigative questions. The mid-level sections provide a “bigger picture,” but still include some technical details. Information in mid-level sections is directly supported by evidence presented in the individual analysis reports.
• Individual analysis reports Full analysis reports, such as forensics, live response, and malware, are included in this section. Analysis reports are the foundation for all findings in the incident report.
• Appendices The most common use for appendices is to include long listings and excerpts, such as log file content and file listings, that would take up multiple pages in the main body of the report. Any table or figure that exceeds one page tends to make a report more unreadable. An appendix is the perfect place to include those listings.
Analysis reports, such as forensic examinations or malware reports, focus on the results of examining a single source of evidence (for example, a hard drive or a set of log files). We perform many specific types of analysis, but most analysis reports take the same basic shape. For example, forensic examination reports and live response reports are very similar in structure. The main difference between the two is minor changes in section title names. One exception is malware reports, because they routinely contain very specific section names that are uniquely associated with malware analysis results. The following sections are common in most analysis reports:
• Title page and table of contents These optional sections are more commonly used in stand-alone or large analysis reports. A title page ensures the reader understands what the report topic is, and provides some level of protection against prying eyes from seeing the main findings. In larger reports, the table of contents helps the reader find what they are more interested in. Both contribute to a more professional report appearance.
• Background The background section for an individual analysis report should provide context for the item examined. The background should clearly describe what events lead the investigation to the evidence being analyzed. The background should also explain who collected the evidence, how you gained possession of it, and the high-level analysis goals. The background section is not used to document or refer to findings presented in the report.
• Findings The major findings in a report should be presented early in the report, and be very clear and brief. Each finding should include brief supporting evidence, backed up with further evidence in the details section of the report.
• Evidence examined As with any forensic or scientific report, the writer must include a listing of the items they examined. In computer forensics and incident response, we provide a listing of any evidence that was examined as part of the analysis.
• Timelines A timeline is an optional section you can include that is very useful in some reports. The timeline section normally consists of a table that lists major events in chronological order. The date and time are listed in UTC, along with a summary of the event and the source of the event knowledge. This timeline is normally included at the beginning of a report, so it is relatively brief—typically no more than one page. An easy way to condense multiple events is to summarize them. For example, if an attacker created 10 RAR files, listing each creation in a separate row will waste space. Rather, summarize by saying the attacker created 10 RAR files and provide the time span. However, if other events occurred during that time frame, it’s probably a good idea to break the RAR file creation up so you can properly list those other events.
• Analysis details The analysis details section of a report is where the “gory details” are documented. This section contains all the low-level facts and details discovered throughout the analysis that build up to and support the main findings. Three common formats we present findings in are chronological, categorical, and importance. A chronological presentation lists all findings in strict date order. Organizing by category is usually done by evidence source—such as the file system, event logs, or other source. Presenting by importance means listing the findings that had the greatest impact on answering the investigative questions first.
• Appendices Appendices in analysis reports are used for the same reasons as in an incident report.
QUALITY ASSURANCE
No matter how confident we are that we’ve written a good report, a quality assurance (QA) review always seems to identify issues. Establishing a QA process will help prevent your organization from delivering substandard reports. A comprehensive QA process includes a review for compliance with style, formatting, content, and technical accuracy. In most organizations, one or more individuals are assigned as report reviewers. The reviewer cannot be someone who wrote the report being reviewed. This process is sometimes referred to as “peer review,” and is often required in accredited forensic science laboratories.
 |
Quality assurance, combined with good procedures, should help ensure that the content of one report does not find its way into another. This might sound a bit obvious; however, the technology that helps us can also hurt us. Most word processing software, such as Microsoft Word, embeds metadata and actual text from prior revisions of a document within the file. Even though you don’t see any sensitive information, it may actually be present. If discovered, that information could create serious problems for your organization. You should always start a report from a known clean template. You should also consider converting your document into a different format for delivery. For example, if your report is in Microsoft Word, you can convert it to an Adobe PDF. The QA process should include checking file metadata, such as total editing time. And finally, always research the document format you are using—determine how susceptible it is to this problem, and what you can do about it. These measures will help prevent embarrassing, and potentially costly, mistakes. |
SO WHAT?
We’ve all heard the phrase “It’s not what you say, it’s how you say it.” Report writing is arguably the most challenging aspect of incident response. We’ve seen all too many responders use screenshots to “explain” what an attacker did. It’s not your fault, though—most educational systems fail to educate people how to write correctly and effectively. However, without effective writing, you might lose the battle before it even starts. To help win the battle, we recommend that you constantly develop and refresh your skills by reading “Improving Your Technical Writing Skills” by Norman Fenton and The Elements of Style by William Strunk Jr. and E. B. White. Seek out assistance from sources that help you effectively communicate complex ideas in simple terms. We’ve also found that these quotes tend to help us the most:
• “If it’s not documented, it didn’t happen.”
• “Imagine that 20 years from now, someone asks you how you came to a conclusion. What would you write down now so you could answer them later?”
• “Imagine you are explaining what the Internet is to your grandmother. Have the patience and the compassion to help her learn.”
QUESTIONS
1. You analyze an image of a hard drive to locate deleted RAR files. You complete your analysis and do not find any deleted RAR files. Your boss tells you not to write a report. What would you do and why?
2. Explain why active voice is the preferred writing style of technical reports. Provide at least three clear examples that illustrate active voice versus passive voice.
3. Design two metadata tables that were not discussed in this chapter. Explain why you chose the layout and the fields you included.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.