Pen Test Reporting

Reporting Tips

Vulnerabilities should be checked to ensure the content (including risk scores) are relevant for the assessment. The blocks/issues are foundations to work from and should be improved upon where possible to add value.
Dont copy stock issues from tools like Nessus.
The executive summary should be written for a non-technical audience – this takes a bit of practice but try to avoid technical lingo as much as possible. You want to ensure that you include a good overview of the assessment results; What the issues are, what an attacker can do with them, what the business risks are and what you recommend the client should do to remediate the issue (root cause etc).
Ensure you’re confirming issues raised by any VA solutions and evidencing the results.
Try to read the report and make sure that sentences are complete (not missing words), grammar is correct and formatting is consistent. Double check there aren’t any rogue placeholders.

Report Data Normalization

Data normalization is a term often associated with databases. In this sense, the database designer is looking to create a cohesive set of data that reduces data redundancy and increases data integrity. Sometimes your data might be presented to the client in a database, so this makes perfect sense. If you are instead creating a document in a text format or other non-database format, you still want to apply those same principles of reducing redundancy and increasing integrity. For example, data from disparate sources that describes the same event can be consolidated to reduce confusion.

Also, the report is likely to be read by a variety of audiences. This might include board members, end users, and technical administrators. They all need to be able to read through and understand your findings and recommendations. So, you need to target your reports to account for these differences. There might be sections for executive summaries for those who only need a high-level understanding. There might be links to more technical information that end users might find too confusing. Essentially, you want to normalize data in the report to make it as clear to the target audience as possible, all while minimizing extraneous information that just contributes to the noise.

Report Structure

You can create a report that includes all of the information from your testing. A typical pen test report includes the sections identified in the following table. These sections can then be pulled together in various combinations depending on the audience. Within the sections you can also have subheadings containing more detailed content that would be better suited for one audience or another. If this is stored in a repository of some sort, the pieces needed for each audience can be pulled into a report designed specifically for that audience.

Report Section	Description
Executive summary	This is typically one or two paragraphs that summarize the content of the entire report, created after the report has been written. It should state the tasks that were conducted during the testing. It should identify the methodology that was used to conduct the tests. It should end with the high-level findings and suggested remediation for those findings. It should end with a conclusion statement such as, In conclusion, the network, systems, and processes have been found to be <insecure/secure>.
Methodology	This section describes the activities performed to conduct the testing. It should include steps that can be independently repeated so that findings can be validated.
Findings and remediation	This section is often presented as a table that identifies the vulnerability, the threat level, the risk rating, and whether the vulnerability was able to be exploited. It should also include the steps needed for remediation of the vulnerability.
Metrics and measures	Metrics are quantifiable measurements of the status of products or processes. An example of a metric related to pen testing is the criticality of vulnerability findings. This metric can be expressed on a scale, like 1 to 10. Measures are the specific data points that contribute to a metric. Using the same criticality metric as an example, the measures might be something like the percentage of hosts susceptible to a particularly critical vulnerability, the total number of critical vulnerabilities found throughout the client’s assets, etc. Metrics and measures are important to include in a report because they demonstrate to the client quantifiable data about the test’s findings.
Risk rating	The risk rating levels can include more granular levels of likelihood and impact than what is shown in this graphic, but this is a basic idea of how risk rating works. You will need to assign quantitative values to the risks so that you can accurately assign a risk impact and a likelihood that the risk will occur. The risk rating is the intersection between the likelihood of an event occurring and the impact it will have if it does occur.
Conclusion	This section wraps up the report. It should include a general summary statement about failures (and successes), with supporting evidence that can be written in a sentence or two. It should also include a statement of the pen test goals and whether those goals were met. You can get more specific about potential attacks and what assets such an attack could leverage. Identify the areas most likely to be compromised and recommend that those be dealt with as soon as possible.
Supporting evidence	Any supporting evidence, or attestation of findings, should be attached to the report. This might include printouts of test results, screenshots of network activity, and other evidence you obtained during testing.

Risk Appetite

The amount of risk an organization is willing to accept, or its risk appetite, must be determined by each organization. Risk appetite refers to the amount and type of potential vulnerabilities and threats the organization is willing to tolerate and endure. This is another balancing act as the organization determines how much risk they are willing to endure versus how much it would cost to mitigate the risk and the difficulty of implementing mitigation strategies.

The client’s key stakeholders need to determine their risk appetite by answering questions such as:

What losses would be catastrophic to the organization?
What processes, technology, or other assets can be unavailable and still enable the organization to function, and for how long?
What assets, processes, information, or technology must be available at all times, and cannot be made public or be accessed by unapproved persons?
Are there any circumstances that could result in personal harm to anyone dealing with the organization, be it employees, customers, business partners, or visitors?

Your pen test report should account for the client’s risk appetite. For example, you can determine the level of risk a vulnerability poses by using the standard “Probability x Impact” formula. Then, you can compare the result of this assessment to the organization’s risk appetite and determine whether or not the risk falls within the accepted tolerance level. You can do this in a number of ways, including visually through charts and graphs. This will help the client organization better understand the impact of a risk than if you had simply quantified the risk without regard to the client’s appetite.

*Graphing an organization’s risk appetite*

Report Storage

Because pen test reports contain highly detailed information about the areas that are vulnerable to attack, you and the client will both need to take precautions to prevent the reports from falling into the wrong hands. If possible, store the reports on a secure server and don’t pass the report via external drives. Within the client organization, the file system should be secured so that only the appropriate personnel are able to view the details of the full report. There are likely some parts of the report that need to be made available to additional personnel. For this reason, consider storing reports in repositories where pieces and parts of the report can be secured with varying levels of access.

In addition to access control, encrypting the reports in storage will go a long way toward making sure unauthorized parties cannot read them and glean sensitive data. You also need to determine how long to store the report for in order to minimize the risk it poses. Discuss with the client the expected storage time for the report.

To help maintain document control of stored reports, you should consider implementing the following components in the reports.

Component	Description
Cover page	The cover page typically includes the name of the report, the version and date, the author (either the name of the person or the organization that is conducting the testing), and target organization name.
Document properties	This might be just in the electronic version of the document, or it might be printed as a table in the document. In either case, it typically includes the document title, version number, author of the report, and date of the last revision. It might also include other fields such as the names of the pen test team members, names of those who have accessed and viewed the report, approver name if stored in a system that allows documents to be approved or rejected (such as SharePoint), and document classification information (as determined by the testers or target organization as defined in the SOW).
Version control	This is typically implemented as a table to track changes made to the report. The tracked information includes a description of any changes that are made, who made the changes, the date of the change, and the updated version number (it might be a full version increment or a “point” version, again based on the terms defined in the SOW).

Report Handling

The following are some best practices for the secure handling of reports:

Maintain the confidentiality of reports and their contents.
Maintain the integrity of reports and their contents.
Ensure reports are always available to the relevant audience.
Ensure reports are secure in transit across a network.
Minimize the transmission of reports across a public network like the Internet.
Ensure reports are secure in storage.
Protect reports and their contents from accidental disclosure.
Maintain audit logs for users accessing reports.
Maintain a chain of custody when transferring ownership of reports.
Maintain version control for changes to reports.

Report Disposition

Report disposition is the formal process of transferring the report to the care or possession of the primary authorized recipient. You are giving the report over to the client, at which point they become responsible for the report and its contents.

The report disposition should include all documentation, multiple copies (possibly printed and electronic), and acknowledgments and sign-off by the recipient. It should be up to the client’s authorized recipient to distribute copies. If others request copies from the pen test team, the team should refer them to the authorized recipient.

At this point, after you have given over the report, you should move (not copy, but move) your copy to a backup storage location and remove it from your active work area. This will help protect the data if someone were able to attack your systems and gain access to the data.

Note: “Disposition” can also refer to the general tone of the report or the approach that it takes.

Guidelines for Writing and Handling Reports

When writing and handling reports:

Normalize data to reduce redundancy and increase integrity.
Consider including the following sections in your report:
Executive summary
Methodology
Findings and remediation
Metrics and measures
Risk rating
Conclusion
Supporting evidence
Work with the client to determine their risk appetite.
Write your report to speak to the client’s risk appetite.
Determine the file format for the report, such as Microsoft Word, OpenOffice, or HTML documents.
Determine where the report will be securely stored.
Follow best practices for securely handling the report.
Determine how formal hand-off of the report will happen between your pen testing team and the client.