Hello everyone, it’s been a while since my last post (sometimes you get stuck in the corporate loop). As you must have guessed from the title, today we’re going to get a little non-technical and talk about what constitutes a good penetration testing report and how you can improve writing one.
This topic is helpful to anyone who is actively engaging in penetration tests and writing the reports, as well as to someone who is reviewing it prior to submission.
1. Know Your Audience
The number one mistake when writing a report is that, sometimes we as penetration testers misunderstand the objective of the report. I’m sure you would have conducted a fabulous penetration test discovering a lot of loopholes, poor configurations and simple passwords.
All this is GOOD! Don’t get me wrong, but if you report this as is to someone in executive management, they’re probably going to miss the point you were trying to make.
This is tip number #1, know your audience. Once you know who’s gonna read the report it makes your job easier on deciding how to present your findings.
- Executives and Top Management would be interested in knowing the impact, the business risks and loss to CIA of information in case of a potential breach.
- Head of Department personnel who would possibly be getting their teams to mitigate the vulnerability, would be more interested in knowing how the attack was performed, what mis-configurations where targeted, etc.
- And lastly, the team members who would actually be mitigating the vulnerability would be interested in a step-by-step reproduction of the exploit, which would help them understand and map the key loopholes which need immediate resolution and so on.
In such a situation, you would possibly need two sets of reports, one targeted to the executives, and one which would be circulated with the HODs and their teams.
2. Now for the Content
Keeping the above point in mind, your content will vary in an executive report as compared to a technical one. Below are a few tips, that will help you write a better report.
|Highlight the Business Impact of the Vulnerability Found.|
|Have summary chart right on the first page / slide which will be highlighting the vulnerabilities found (count) and their risk scores across the estate|
|Provide a brief description of the issue you found.|
|Highlight the highest risk asset and lowest risk asset, along with a GAP analysis of the oldest missing patch / newest missing patch.|
|Avoid being too technical about the issue.|
|Avoid overstating or understating a vulnerability.|
Depending on who’s going to view / work with this report, some of the following points may be applicable.
|Highlight technical details, for example: attack vector, ease of exploitation, etc.|
|Highlight the impact|
|Provide an in-depth detail of the vulnerability found, this may include a step-by-step exploitation of the vulnerability.|
|Additional information, for example: the mitigation, reference links are all very helpful.|
3. Format and Template
This may sound trivial and unimportant, but if your report is unorganized and not presentable. It may cause some trouble.
There is no absolute way to format or write a presentable report. However, the below essentials can might help you build a custom template for yourself:
- Cover Page with precise details – Name of the report, date, author, owner, version, etc.
- Table of Contents: Allowing for smooth navigation of the report and giving the reader an idea of the content.
- Scope & Objective: Allocated time, number / list of target servers, etc.
- Progress Chart: Success rate (success/total), completion rate. Estimated time taken, etc.
- Summary: A brief highlight of the nature of the findings, along with the approach taken, top used tools, top vector & vulnerability used, etc.
- Detailed write-up for the technical reports, with POC image items as well as precise highlighting for emphasis.
- Mitigation: Steps to fix the vulnerability and its relevant reference items.
- Additions / Miscellaneous: This may include port scan details, additional information gathering, social engineering items and other steps that may have been taken to perform a successful exploit
Additionally maintain the same font as well as sequential sizing for every heading, title and sub-title, etc.
That’s all my thoughts on writing a penetration test report. In no way this is to serve as an absolute guide to writing a report, but it is meant to serve as a guideline on what should be included. This may highly vary based on report requirements outline by your organisation.
Thanks for reading 🙂
Leave a Reply