Writing a Penetration Testing Report

At the end of the day, the penetration test report is what is delivered to a client after performing the penetration test. For this reason, the report is really important. In this blog post I want to show you a good report writing methodology and I will share a sample report I have used in one of my pentest certification exams.

Sample Report

I have put an example report online, which I originally created for my certification exams. You can find the report here [0.5MB].

Other Ressources

You can find a very good white paper Writing a Penetration Testing Report on how to write good reports, which was published by SANS in 2010. A curated list of public penetration test reports released by several consulting firms and academic security groups can be found on GitHub of juliocesarfort: Public Penetration Test Reports. An example how you can use markdown to generate your reports shows noraj on GitHub: OSCP Exam Report Template.

Automated Report Generation

Besides using a report template, the report should be written as time efficient as possible. Using scripts to generate the report can help with this. Therefore, I recommend using a plain-text-formatting syntax like .tex or markdown. At least, it should be in a "programmable" format. The complex .xml format used by Microsoft Word will not make your life easier ;)

The most time must be spent into the section where all individual findings are presented. So, it is wise to first collect the vulnerabilities in a simple list (.csv), and then convert them to the right format so it fits the template (.tex/.md).

Quantity vs. Quality

Some companies out there think they will be paid per written page!? I think it's definitely not just about the length. A good report should summarize all findings adequately so the vulnerabilities can be reproduced. However, the information reported should be concise and accurate, as well. Your client will benefit more from a good risk assessment of each vulnerability and conclusive recommendations, instead of reading through a wall of text.

General Format

• Cover page
• Point of contact
• Project details
  • Project objectives
  • Scope of work
  • Period of testing
  • Test classification
  • Limitations
• Executive summary
• Technical report
• Appendix
  • Methodology
  • Risk evaluation

Cover Page

The first page shows the organization name, the project title and the version of the report. You can add an optional confidentiality statement.

Point of Contact

Defining a (Single) Point of Contact on both sides is very important, especially when information is time-sensitive and accuracy is important. A PoC helps to achieve a good "first call resolution rate". For example, hacking attempts have triggerd an alert while it is not clear if this is related to the penetration test. In this case, the system administrators have to speak to the penetration testers as soon as possible. Or imagine the penetration tester notices an outage of a system. This can be totally unrelated to the pentest. However, while the system is down it cannot be tested anymore.

Project details

Project objectives

Project objectives should characterize the main goal of the penetration test. This can mean testing for PCI DSS compliance. It is also a good practice to define protection goals of the confidentiality, integrity and availability of data (CIA triad).

Scope of work

List every network range, systems and applications that should be tested. You can also add what is explicitly excluded from the pentest. Also describe if there is a special focus on one of the protections goals. For example, it is worth mentioning that the recruiting system has special needs in the context of confidentiality.

Period of testing

The testing time frame should be mentioned not only due to accounting reasons. There are several more reasons:

• a penetration test only shows the current state of security. Changes to the infrastructures that were made afterswards can impact the security
• system administrators must be informed; after testing all the hacking attempts in the server logs can be identified as part of the penetration test
• system administrators must be prepared; all systems within the scope must be up during the testing period
• after testing all pentest-specific configurations must be rolled back, e.g., remove firewall whitelisting, enable WAF, enable alarming and disable user accounts (this can also be included as a reminder in the report)

Also include whether testing were performed 8h per day or in out of office hours.

Test classification

A good overview of the penetration test methodology was published by the German Federal Office for Information Security (BSI) in 2008: Study A Penetration Testing Model. In my opinion, this is a smart classification scheme, even though I added "grey box tests".

Limitations

I always like to point out that limitation statement. As the BSI states: "Thorough penetration testing is no guarantee that a successful attack will not occur." And I want to elaborate on this further by this sentence in the report: "There is no 100% security guaranteed, even if all findings are properly mitigated and recommended countermeasures are fully implemented." This is just what it is. Even though, penetration tests are one of the best measures I can think of to improve IT security.

Executive Summary

The executive summary is - as the name suggests - a summary written for management personnel. The use of technical terms should be avoided and the summary should be short and on point. It should not exceed more than one page.

Technical Report

In my example report, each finding is assigned to a unique number and title. Before describing the vulnerability, I like to have a "vulnerability header" that briefly shows the details of the vulnerability where I especially focus on its risk. The traffic light on the left indicates which risk was assigned to the vulnerability. The used color scheme should be intuitive. Next to it, we see the risk in textual form, additionally, and also what it is composed of (impact and likelihood). Mentioning the time when the vulnerability was found is a good practice. In this way the customer can reproduce the vulnerability in the log files. Of course, the finding is demonstrated with a proof of concept and remediation steps are described briefly.

Appendix

Methodology

As a professional service provider it is good to show that accepted methodologies are followed. The testing procedure must not be explained in detail. It even heavily varies depending on the actual pentest. But there is a standardized testing procedure that leads to reproducable results and ensures every aspect to be covered.

Risk Evaluation

Risk assessment involves actually two steps:

• identifying and analyzing potential risks (risk analysis)
• making judgments (risk evaluation)

The first step includes finding vulnerabilities and identifying bad architecture decisions. The next step is evaluating these findings based on your professional experience and knowledge (this is also what you are paid for!). A risk classification scheme can help here in terms of understanding and comprehensibility. I think in this section it is tolerable to explain the process of risk assessment more in-depth.

And yes, I'm aware that matrices with an odd number of columns/rows (e.g., 3x3 or 5x5) carry the risk of the decision more frequently "landing in the middle" according to the Implementation Guideline ISO/IEC 27001:2013 by ISACA. The important aspect is to present identified risks to decision-makers in a comprehensible way.