đ Join Us Every Wednesday at 9:00PM ET (see our latest events on LinkedIn)
Table of Contents
Introduction
When it comes to learning pentesting it is easy to focus solely on just studying the technical details; but, the âactualâ deliverable in a penetration test is the report. You could be an absolutely phenomenal security engineer but if youâre unable to communicate what you did, how you did it, why itâs important, and how the client can fix it; nobody will be able to understand your skills. Taking the time to write a quality penetesting report and hosting it on your own Github or blog is an excellent way to stand out from the crowd when it comes to applying for positions as well; for a deeper discussion into this idea please reference the page below.
How To Structure A Report
There is no singular ârightâ way to do it, if you look at a dozen reports from a dozen different security vendors youâll likely see a number of different approaches. Some are extremely simplistic and it makes you wonder if they just ran an automated scanner like Nessus and handed the output to the client. Others, (Like GoVanguard Securityâs) are highly tailored and customized to the specific needs of the client. A great discussion about understanding the needs of clients can be found here.
At a minimum, Iâd recommend the following structure and sections be included in any report:
- Introduction - This section should be brief but detailed and should cover
- What is being tested (scope at a high level)
- Testing dates
- Objectives of the test
- What standards the testing is being done to (i.e, PTES, OWASP, etc)
- <Optional> - Executive Summary
- Methodology - This section can go into more detail about how the test will be conducted from a high level (perhaps explaining the Mitre ATT&CK framework, if thatâs what youâre using) as well as a description of how risks will be scored in the report
- Detailed Scope and RoE considerations - While in the introduction you may say âXXX company contracted GoVanguard Security to perform external penetration testing between the dates of 1 January, 2022 and 18 January, 2022â this would be more detailed in providing the exact scope of what applications, IPs, or URLs were provided by the client for inclusion into the test. For RoE considerations, if there are any specific restrictions it is okay to call them out. An example could be that you were testing a production environment so running aggressive automated injection tools like SQLMAP was considered out of scope and manual injection testing was utilized instead.
- Narrative - This is your opportunity to showcase all the things you tried that worked, and the things that did not work. Think of this section as showing your homework. The more thorough it is, the more confidence the reader will have in the level of detail and due diligence you took when testing. This should be written at a level that can be understood by even non-technical folks.
- Risk Details - This is the section where you will detail each âfindingâ in the report, specifying the potential impact to the client, and providing remediation recommendations. This section tends to be written with more technical details for the clientâs engineers to be able to triage and fix the issues that you found. A good structure for each risk would be:
- Name & level of risk
- Summary of the risk
- Evidence
- Remediation Recommendations
- References
- List of affected endpoints
- Conclusion - Summarize the overall security posture of the organization, identify the biggest risks and implications
Top 5 Tips For Writing A Good Report
- Proofread it VERY well. Consider utilizing something like grammarly to assist with this. Typos and grammatical errors in a formal report is an easy way to diminish your credibility.
- Take the time to learn how to write professionally. For many of us it has been years since writing so formally and considerations like active versus passive voice, what tense the narrative should be written in, what tone to take in each section all play an important role. Consider brushing up on professional writing skills; here are some great and inexpensive courses on Udemy for technical writing.
- Focus on why risks are important and what the impact to the business is. Executives are not interested in theoretical risks or overly technical jargon, keep the recommendations practical and specific.
- Donât write a hit piece. The goal of a pentest report is to accurately portray the attack surface of whatever youâre testing, not to make their Blue Team look like they were asleep at the wheel.
- Customize your remediation recommendations to their specific environment. Make sure your recommendations arenât so general that they are useless; and make sure the recommendations match the technology they are using. For example, donât provide documentation on how to fix SonicWall if theyâre using Cisco Meraki.
