Penetration Testing Reports - Special Pointers

A funny quote goes, “If confusion is the first step to knowledge, then I must be a genius”. Well, you do not exactly feel like a genius when you have a deadline to meet and no idea where a particular finding goes. Of course, ‘Penetration testing reports’ is not a popular item on your ‘things I like at work’ list. However, it is a necessary evil, if you may call it so – at least it brings you closer to the completion of the project.
A lot of organizations have a structured, automated reporting process. With the help of proprietary tools, inputs from different auditing and scanning utilities are converged into a single report within different categories. The tool then spews out a draft report in the desired format (XML/ PDF/ MS Word/ HTML). This report is tweaked by the security analyst and the project manager to reflect the exact findings in the desired order of importance and also to comply with other quality parameters.
Another set of organizations make reports without the help of proprietary tools, listing out findings under categories of different vulnerability types. This is done after collating results from scans and exploitation of possible vulnerabilities with different attack vectors.
Penetration testing reports largely adhere to a common reporting style unless your organization or client requires you to use their style guide. However, like any other activity-specific report, a penetration testing report too has its own detailing to be taken care of and both the approaches require special attention to the most vital aspects of writing for vulnerability reporting. These vital aspects can be classified into

Audience Identification: Penetration testing reports may be only for the internal audit team and/or the IT department (i.e., a technical audience), or for the management executives and the technical team. The report must always be drafted with the target audience in mind. For the technical audience, the writer can conveniently use jargon and skip detailed explanations of attack types. Some points to keep in mind for a technical audience:
1. The reader wants a quick glance at the vulnerability ratings as well as corresponding details with accurate referencing. So keep the report succinct and try to retain all data relevant to a particular finding in one location, preferably on the same page.
2. When you present the first finding, the reader expects a similar pattern for the remaining findings. So, follow a uniform pattern of vulnerability specifications. For example,
a. Risk Description
b. Risk Level
c. Affected IPs or URIs
d. Potential Damage / Corporate Loss
e. Recommendation / Remediation
For a non-technical audience – Executive management, IT Manager or Risk Manager, the jargon should be minimalistic and the vulnerabilities should be described from the user’s perspective such that it is simple to comprehend the vulnerability. For example, ‘a parameter manipulation on the order confirmation page of a shopping cart application’ may be re-worded to ‘Price Manipulation in XYZ shopping cart’. The idea is to familiarize the vulnerability. The managerial perspective looms at the macro-level. So they are concerned with the overall risk the sum total and individual vulnerabilities pose to the organization and how soon these vulnerabilities can patched. Thus one-glance reporting plays a key role here. Constructive use of pie-charts, 3-D bar graphs or simple tables with a good color-coding scheme may prove useful.
Structure Determination: Barring the common elements of a report (Executive Summary, Conclusions and Appendix), a typical penetration testing report at NII Consulting consists of two main components as part of the technical section. These are: Network-related Vulnerabilities and Web Application Vulnerabilities. As you may have noticed, the Network-related Vulnerabilities show the port scan status and service banner disclosures and the Web Application Vulnerabilities section provides tabular listing of the findings in the order or threat rating or risk level. The technical section can also be structured as per the approach of the penetration testing.
Classification of Findings: Another important aspect which determines the overall impact of the report is how you classify the findings. This decision overlaps with that of structure determination. Findings can be presented in the order of threat rating or can be classified under different attack categories. Cross-site scripting, SQL Injection, Parameter Manipulation – all can be classified under Insufficient Input Checks. Other such categorizations can sometimes help the client assign responsibilities for resolving issues to different teams.
Recommendations: Some important points to consider while writing recommendations:
1. Provide appropriate URL references if an upgrade or patch is recommended
2. Give the details – if an upgrade is needed mention the version to be upgraded to, if an XSS vulnerability exists don’t just write ‘data needs to be filtered’. Specify what kind of characters can be replaced.
3. You may also mention URLs for further reading on the vulnerability and other related vulnerabilities
These are only a couple of pointers needed to write a good report. A lot more goes into writing a penetration testing report that adds value.
On a light note:
Jane Watson, in her article, The Recipe for Good Reports, says

Some people write the same way as I learned to cook spaghetti.
When I was at university, I was taught a surefire way of cooking “perfect” spaghetti: Add noodles to a large pot of rapidly boiling water. When you think the pasta is about ready, use a fork to remove a strand from the pot. Flick the strand at the wall. If the noodle falls behind the stove, the spaghetti is not fully cooked. If it sticks to the wall, get ready to serve.
This is the same method some people use to write a report. They have a vast number of facts boiling in their minds, and they believe if they throw out enough of them, some will eventually stick in the reader’s mind.