How to Structure a Pen Test Report
Your pen test report should come from a combination of the tools you use (some generate reports) and your own written work to explain overall health of the environment. A pen test report comprises any sections outlined in the scope of the project, but this list shows sections that commonly appear:
• Executive Summary: The executive summary briefly summarizes all of the key details of the report. It will speak to the reader in a way that lets them know what steps were taken, what the report ultimately found, and an overview or highlight of next steps, which might include recommendations.
• Tools, Methods, and Vectors: This section covers the tools you used and the methods you chose to conduct the pen test. In addition to providing a general outline or narrative of your ethical hacks, also detail the paths you took with detailed step-by-step attack patterns and selected vectors.
• Detailed Findings: This is where you will list all security risks, vulnerabilities, penetration points, threats, and concerns. Include the technical aspects of each finding in detail.
• Conclusion: This section of the report reiterates the executive summary but with a focus on the next steps.
• Recommendations: Although your job is ultimately to do the pen test and assess the health of the organization's overall security posture, you might be additionally responsible for providing guidance on ways to improve the security. If so, put those in a separate section and be as detailed as possible.
• Appendix: Include this section for charts, logs, and any information that falls outside the project scope but which you think could be helpful.
This list shows how some penetration test reports are structured to give you a starting point. Your company may have specific ways in which they would like you to report, or you can find other examples online that can give you more ideas to choose from.
Executive Summary
The first part to consider in your penetration test report is your Executive Summary. A summary becomes an executive summary when you conduct a summary response in an organization that is likely read by the executive leadership staff.
For those of you who work in penetration testing and other technical fields, many times you have very little time to speak with and meet with senior executives so think of the executive summary as an elevator pitch. You need to very quickly and concisely talk to your goals, outcomes, and provide a high-level view of key findings. Keep details for the body of the report, not in the summary.
Overall, the goal of the summary is to let the reader know what steps were taken, what was ultimately found, and next steps. If these are the details of a pen test, an executive summary might look like what's shown below:
A companywide issue with all Apache web servers that can be accessed remotely without a required patch (more suited for the body in findings).
You have or had a goal to identify whether your company-wide web architecture was secure for the upcoming holidays because the company relies on the integrity of these systems to be profitable in the fourth quarter.
This (as noted) is only a suggestion; however, it fits all audiences. I didn't get into details about patches, vendors, systems names, technical jargon or any other albeit important, but unnecessary information for the executive summary. Those details can be added into other sections and appendices.
Another one of the biggest items to consider for the executive summary is scope. This should read very clearly in the first part of your report. The pen test report covered that a scan was needed and completed. The pen tester didn't get into what vectors were chosen, tools used, methods and so on. The pen tester had to identify the web architecture because that was in scope. The pen tester didn't have to scan every part of and pen test the entire enterprise's technical footprint.
The scope of the pen test was to identify whether security posture was high on the web architecture, and that's what the pen tester included in the summary.
Tools, Methods, and Vectors
This section of the report is where you can get more detailed, covering the tools that were used, what methods were chosen to conduct the pen test, paths taken, attack patterns, vectors selected. You can also write a general outline or narrative of the ethical hacks.
The following image shows an example. You can either detail or map the specifics of what paths or vectors you took, what tools you used, and any specific methods of attack. This can be considered the attack narrative.
This image shows an example of what this section may look like.
Depending on the length and complexity of the pen test, this section can continue on with a step-by-step (or hop-by-hop) layout of the attack narrative and how certain information was found based on the assessment. The specifics here can really help to build a technical map for other teams you might collaborate with to address the risks.
You should always assume other technical teams (with permission of course) may be reading your report to help mitigate the risks. You are the pen tester, but the system administrator will likely be the one who needs to patch the DNS server that's providing zone transfers. The report findings may need to go to the SQL database administrator (or developers) who can help to fix the DBs to stop injection. These folks work with the risk register to close out the items prior to retest.
Detailed findings
All security risks, vulnerabilities, penetration points, threats, and concerns with a list of all technical aspects of each finding are provided in detail. This is the part of the report that allows you to really dig deeply into the specifics of your findings.
If you were able to penetrate a specific port and IP address combo or thwart a router's security, all that should go into detailed findings. You can also use the notes created and the tools report and audit output for help building your main report.
The biggest difference between this section and the one previous is that this is where you can place the items identified and outcomes from the attack narrative. In this example, you may want to use the Metasploit audit logs to show all the vulnerabilities identified.
You may want to show the specifics of the logs (in minute detail) where you found the zone transfer issue. You should show all details; however, if it seems to be too much information, you can choose to summarize for the sake of brevity. Be cautious so you don't remove information that is needed for your report.
It's these details that allows the technical teams to not only fix what you found in the pen test, but also identify any and all other issues that may be (or not) relevant to the conducted pen test. For example, your goal (in scope) may have been to protect web architecture, but the technical teams found that all of the Windows Servers are missing critical patches that help mitigate other issues that the tools may have found.
You don't want to overwhelm anyone, confuse the report, or stray too wildly from the goal/scope, but you're beholden to inform those of any and all security infractions you identify along the way. Cover those details that fall outside the project's scope in the appendices.
Conclusion
The Conclusion section takes everything you compiled into your report and succinctly wraps it up with a focus on next steps if any. Repeating what you wrote in the executive summary can be okay, as long as you switch the focus to next steps. You can of course outline next steps in the body or anywhere else in the report, but the conclusion at the end should take one last look at next steps holistically and purposefully.
As you can see, the next step is to do a retest to ensure that any documented changes, fixes, risk avoidance, or compliance items were handled and done so correctly. A retest will prove that.
Recommendations
As a pen tester you may need to supply some help to those who need it depending on the scope of the project or the size of the company. Smaller organizations may require you to help fix what you found and if you can, add this to your report. You can create a separate section or add it into the detailed findings.
As you will see, the detailed findings, appendices, and recommendations can be repurposed and reorganized based on what you need for your report. You could have a recommendations list in your appendix.
TIP
Recommendations should be made if they're in scope. Not all pen testers
are required to recommend how to fix the items they found in the pen test. Should you know
how to fix the items you have identified? If you want to learn more about security and how
to be a better pen tester than the answer is yes, but it doesn't mean that it needs to be
in the report you submit.
If it is in scope then you should by all means create a list of items you believe that the company or organization should do to mitigate the risks you have identified.
Appendix/Appendices
Many reports might have extra information that may or may not be fully relevant to the scope or goal of your pen test and report. Place such information at the end of the report in an appendix or appendices (if you have multiples). Other information that can go here may be port charts, maps, full audit, or tool logs and other items that can be helpful to those using or reading the report.
About the Book Author
Robert Shimonski is an ethical hacker and a professional IT leader who has led numerous efforts to architect, design, strategize and implement enterprise solutions that must remain secure. Rob has been involved in security and technology operations for over 25 years and has written his books from the trenches of experience.
More Network Security Articles:
• Man in the Middle Attack
• Implementing a Secure Password Policy
• Why Become a CISSP?
• Essentials of Endpoint Device Backup
• What Roles Do Firewalls and Proxy Servers Play in Network Security?
• The Role of Security Penetration Testers
• Handling Rogue Access Points
• Prevent Hacking with Password-Cracking Countermeasures
• How to Secure Your Small Business Network
• Avoid Hacks by Rogue Wireless Devices