Penetration Testing Report

Once the penetration testing is concluded the client should receive the findings. The tester has a responsibility to the client to present the findings. This can be seen as an opportunity to explain why time and money spent on the testing were wisely spent. Findings should come in the form of a written report explaining the services provided, the methodology adopted, the testing results, and possible solutions and recommendations. Note that the final report is often the only tangible evidence that a client will receive from the penetration testing process.

Report should be carefully planned and written during the course of the testing. Four development stages can be identified:

Report Planning

Information collection

Writing the first draft

Review and finalisation

Report Planning

The Report Planning should include the following phases:

Report objective

Time

Target Audience

Report classification

Report distribution

The report objective focuses on the main points of the penetration test. They should explain the reasons for conducting the testing and the benefits.

Time refers to how long the testing will last and when it was performed. Penetration testers need to inform the client the timing of the test for several reasons. For instance, an organisation may need to make sure some key IT staff is available during the test in case something goes wrong (i.e. server crash). Sufficient time to perform the testing and write the report should be allocated.

Penetration testing reports usually have several target audiences. The following target audience characteristics should be considered:

Their need for the report (i.e. operational planning, resource allocation, approval)

Position in the organisation.

Knowledge of the report topic (i.e. purpose),

Responsibility or authority to make decision based on the report.

Personal demographics (i.e. age, alliances, attitudes).

Report audiences include Information Security Manager, Chief Information Security Officer, Information Technology Manager and technical teams.

A Penetration Testing Report has sensitive information such as servers IP addresses, applications information, system vulnerabilities, threats, exploits and more. As a result, it should be considered to be in every high rank of confidentiality e.g. TOP SECRET and the report should be dealt with accordingly. The report classification will be based on the target organisation information classification policy.

Once the report is concluded it needs to be delivered to the client. This is a phase that need to be executed carefully and should be addressed in the scope of work. The penetration tester has an ethical (and often legal) obligation to keep the details of the report confidential.

The number of copies, the format (paper or electronic) and the delivery procedure should ensure that the report only arrives to the right person and at the right time. Hardcopy should be printed in a limited number and with the name of the receiver. Software copies should be delivered safely and encrypted with a secure key that only the client knows. Any other evidence of the testing should be destroyed.

Information collection

Collection of information to be used on the report is obtained during the actual penetration test. Saving the outputs and information gained from tools and research will ease the report writing Information could include: traffic captured, scanning results, vulnerability assessment, snap shots of findings, Exploits (if any) and more.

During the collection of information, a first draft of the report should be started. At this stage the tester should not be concerned about editing and proofreading. Once a first draft of the report is completed, it should be peer reviewed by members of the penetration testing team.

Report sections

A report should have a hierarchical structure to support different levels of details. The report should include several independent sections:

Executive Summary

Detailed report

Raw Output

Together, these sections will form a complete report, but each piece should function as a stand-alone report.

The executive summary is a brief overview of the major findings, which should not exceed two pages in length and only include the most important points of the penetration test. The executive summary needs to be addressed to nontechnical management so that they can understand the findings and their implications. It should not include technical details and jargon. If vulnerability and exploits were discovered, the executive summary needs to focus on explaining how these findings impact the business. Links and references to the detailed report should be provided. In case any interested client wants to review the technical nature of the findings.

The detailed report should include a comprehensive list of results including the technical details. The audience includes IT managers, security experts, network administrators, etc. In most cases, this report will be used by the technical staff to understand the details of what your test uncovered and how to address/fix the issues.

A ranking system should be included to explain the highest ranking vulnerabilities first. It’s crucial to present the issues that pose the most danger to the client’s network. This makes your penetration test easier to read and allows the client to take actions on the issues that present the highest risk. Tools like Nessus or Nexpose provide the user with a default ranking system, which could be used as a starting point.

The final portion of the report should be the technical details and raw output from each of the tools. The output raw data belongs to the client and it is important that they have access to it. When custom tools are used to perform a penetration test, owners may not want to divulge details of them. However, in most cases, it is required to provide the direct output of the tools.

If there are concerns about disclosing the specific commands used to run proprietary tools, the raw output should be sanitized to remove those commands and manually delete any other sensitive information. Raw data may not be an actual component of the report. It could be used as separate document.

Tools report engine

Tools such as Nessus or Nexpose are capable of creating a report based on the results of a vulnerability scan. Limited as it does not include reference of other tools used during the process. The report needs to flow as a single document. Using predefined report from Nessus, and other tools may cause the penetration test report appear disjointed and unorganised.

References

[1] - P. Engebretson, The Basics of Hacking and Penetration Testing: Ethical Hacking and Penetration Testing Made Easy, Syngress 2nd Ed., 2013.