The Report

Being a pen tester is a cool job, we get to break into companies (with permission), steal stuff, and then tell them how we did it. Many testers focus on the cool hack, or getting domain admin, or finding SQL injection flaws because that is the exciting part of the job. These make up the stories that are used in convention talks for years.

When the engagement is complete, we now have to deliver the one thing the client paid for: The Report. No one talks about the rad report they delivered on time that met the clients expectations at a conference. Report writing can be a chore compared to everything else we do, but it is the lasting impression we leave with the client of the quality of work we performed. The client doesn’t see the hours we spend sifting through scan results looking for a foothold, the attempts to exploit that are successfully stopped, or the recon needed to social engineer a spearphish. They see: The Report.

The Report is where we have to illustrate to them the effort we put in and show them both the bad and the good of the engagement. The Report is what we exchange with them for the payment. Our reports have several sections, each with an audience and a goal that we want to communicate.

The Executive Summary
The title of the first section makes it pretty clear as to who the audience is: The Executive. This is the section of the report that will make its way to the C-level executives. Typically this is the person who want just a few questions about the test answered, “how did we do?” and “what are the risks to the business?”

They want concise answers that are non-technical in nature. While this is the first section of the report it is also the “bottom line”. What was positive and negative about the test? What were the critical finding that with put my business at risk?

The Narrative
This is the section of the report that the writer can tell the tale of the test. This the place the story for the security conference talk is born. Start with the beginning of the test. While that sounds obvious, it can be harder to do after days of testing when you are finally getting around to The Report. Use this section to track what you tried during the test and whether or not it worked. If something you tried didn’t work, tell the client why in this section. Make this section interesting to the reader by including details and use screenshots to illustrate your point. Remember be though yet brief, we still have more of The Report to write.

Findings and Recommendations
We are now in the technical section of the report; what was found, what is the risk, how it was found, and what are possible ways to remediate it. Your test may have a list of findings that you found during the run of the engagement, but what is the risk of each of those findings to your specific client? Based on the needs of your client, we triage each finding, typically putting them into a risk category of either high, medium or low.
Within each finding, no matter the risk category, we need to outline certain details to effectively communicate what we have found.

Provide the details of the vulnerability or finding, explaining in detail the technology that is being leveraged. Describe the risk the finding poses to the organization using both accurate technical language and context to the clients system. The contextualizing of the risk should show the potential impact of the finding factoring in the likelihood and the possible impact.

If you were able to exploit the finding, show the proof to the client with screenshots and a description so they can replicate the finding. This is an opportunity to teach the clients staff how to see a finding from a different perspective. Seeing the exploit and the steps taken to leverage the finding can assist in understanding the recommended remediation.

It is a mistake to assume that the client can just fix the finding because it has been explained. Adding a recommendation for remediation specific to the finding and the exact system the client is using increases the value of the report and will help the IT staff resolve the issue quickly.

Strategic Guidance
During the course of the test you get a feel for the weakness in an organization at a high level or you see systemic issues that are highlighted by the findings. Make suggestions for things like security focused developer training or implementing multi-factor authentication. As the testers, we are looked to as the expert, and we see the systems differently than most day to day IT professionals. We need to leverage that to affect change at a macro level.
I doubt that The Report will ever become the headline grabbing event that an exploit or a named vulnerability can become. But with each well written report another brick is added to the professional reputation as a penetration tester in the eyes of your clients.