How to write a penetration test report

Before we start writing any report, we need to ask ourselves the following two important questions:
Who will read the report?
What do readers expect from this document?

In the case of a penetration test report, readers are:
General director;
Head of Information Security Department;
Head of Information Technology Department.

The CEO pays for our security testing services and expects to see the main results in the report: is it possible to penetrate his company's network and what information can be obtained in this way.

The head of the information security department is interested in all aspects of the security testing:

What vulnerabilities and in which systems were found?
Can a potential attacker use them?
What information is available?
What hacking tools were used?
What needs to be done to close vulnerabilities?

The head of the department of information technology is interested in what his people will have to do to close the discovered vulnerabilities and whether this will affect the performance of information systems.

Writers

Having dealt with the needs of the readers of our report, let's think about our own.

Security experts should demonstrate in the report that:

work was performed in full in accordance with agreements with the customer;
the results of the security testing conducted are sufficient to confirm the conclusions made.

Now we can develop an appropriate report structure.

For your convenience, we are posting a report template that we have been using for several years in our courses on ethical hacking and whose structure is as described below.

Security Test Report Structure

Let's analyze the key elements of a security testing report.

Executive Summary Section

A section on one, maximum, two pages in which we write what and why we did, describe the main results and conclusions, provide key recommendations. We try not to use technical terms, since readers are the top management who does not always have good knowledge of IT.

Section "Project Description"
In this section, we describe what types of testing were conducted and with respect to which information resources. Detailing should be such that readers understand what is included in the project and what is left outside of it. If necessary, we can indicate the addresses of offices and even the names of people involved in the project on the part of the customer.

Section "Our approach"
Some ethical hacking experts do not like to describe their approach, citing their know-how. We recommend adhering to transparency in relations with customers and describe at least the basic steps of testing in accordance with the adopted security testing methodology.

A comparison of the stages of security testing with the identified vulnerabilities will be useful.

One of the important points during the security testing is the assessment of risks associated with the possible exploitation of vulnerabilities. If we are not guided by the customer’s methodology, but use our own assessment scheme, then it is better to describe it here.

Then you list

Tests

You can use tokens to list the test that you will perform against the application. Top 10 OWASPs are a good start. Of course, here you need to keep in mind the features of the assessment that you conduct.

Tools

You will use to perform tests. Remember to add “custom scripts” to the list if you need to write some kind of script for this task.

IP addresses

Another table with two or three columns: Tester, IP address, Zone (External / Internet, Internal / VPN). You can find out the IP address of the tested web application using the service: https://ip-locations.org/ or any other IP checker.

Application map

Remember how CEOs can't read text? Include an application image that describes the process and features of the application. You can also include a list of dynamic and static URLs.

Description of identified vulnerabilities

The main body of the security testing report will be descriptions of detected vulnerabilities. For audit reports, and the security testing report undoubtedly belongs to this category, the following information presentation structure is classic: finding - risk - recommendation.

The “monitoring” subsection describes which vulnerability was discovered, in which system, demonstrates the possibility of its exploitation with corresponding screenshots. Sometimes customers insist on sending them the logs of the tests performed, in this case it is advisable to indicate the tools used and provide a link to the corresponding file as a rule, it sends to the customer only in digital form.