The art of writing penetration test reports

You close the lid of your laptop; it's been a productive couple of days. There are a few things that could be tightened up, but overall the place isn't doing a bad job. Exchange pleasantries with the people who have begrudgingly given up time to escort you, hand in your visitors badge and head for the door. Just as you feel the chill of outside against your skin, you hear a muffed voice in the background.

"Hey, sorry, I forgot to ask, when can we expect the report?"

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Sound familiar?

Ugh, the report. Penetration testing's least favorite cousin, but ultimately, one of the most important.

There are thousands of books written about information security and pentesting. There are hundreds of hours of training courses that cover the penetration testing process. However, I would happily wager that less than ten percent of all the material out there is dedicated to reporting. This, when you consider that you probably spend 40-50% of the total duration of a pen test engagement actually writing the report, is quite alarming.

It's not surprising though, teaching someone how to write a report just isn't as sexy as describing how to craft the perfect buffer overflow, or pivot round a network using Metasploit. I totally get that, even learning how the TCP packet structure works for the nineteenth time sounds like a more interesting topic.

A common occurrence amongst many pen testers. Not allowing enough time to produce a decent report.

No matter how technically able we are as security testers, it is often a challenge to explain a deeply technical issue to someone who may not have the same level of technical skill. We are often guilty of making assumptions that everyone who works in IT has read the same books, or has the same interests as us. Learning to explain pen test findings in a clear and concise way is an art form, and one that every security professional should take the time to master. The benefits of doing so are great. You'll develop a better relationship with your clients, who will want to make use of your services over and over again. You'll also save time and money, trust me. I once drove a 350 mile round trip to go and explain the contents of a penetration test report to a client. I turned up, read some pages of the report aloud with added explanations and then left fifteen minutes later. Had I taken a tiny bit more time clarifying certain issues in my report, I would have saved an entire day of my time and a whole tank of gas.

Diluted: "SSH version one should be disabled as it contains high severity vulnerabilities that may allow an attacker already on the network to intercept and decrypt communications, although the risk of an attacker gaining access to the network is very low, so this reduces the severity."

Clarified: "It is advisable to disable SSH version one on these devices, failure to do so could allow an attacker with local network access to decrypt and intercept communications."

Why is a penetration test report so important?

Never forget, penetration testing is a scientific process, and like all scientific processes it should be repeatable by an independent party. If a client disagrees with the findings of a test, they have every right to ask for a second opinion from another tester. If your report doesn't detail how you arrived at a conclusion, the second tester will have no idea how to repeat the steps you took to get there. This could lead to them offering a different conclusion, making you look a bit silly and worse still, leaving a potential vulnerability exposed to the world.

    Bad: "Using a port scanner I detected an open TCP port".

Better: "Using Nmap 5.50, a port scanner, I detected an open TCP port using the SYN scanning technique on a selected range of ports. The command line was: nmap –sS –p 7000-8000."

The report is the tangible output of the testing process, and the only real evidence that a test actually took place. Chances are, senior management (who likely approved funding for the test) weren't around when the testers came into the office, and even if they were, they probably didn't pay a great deal of attention. So to them, the report is the only thing they have to go on when justifying the expense of the test. Having a penetration test performed isn't like any other type of contract work. Once the contract is done there is no new system implemented, or no new pieces of code added to an application. Without the report, it's very hard to explain to someone what exactly they've just paid for.

Who is the report for?

While the exact audience of the report will vary depending on the organization, it's safe to assume that it will be viewed by at least three types of people.

Senior management, IT management and IT technical staff will all likely see the report, or at least part of it. All of these groups will want to get different snippets of information. Senior management simply doesn't care, or doesn't understand what it means if a payment server encrypts connections using SSL version two. All they want to know is the answer to one simple question "are we secure – yay or nay?"

IT management will be interested in the overall security of the organization, but will also want to make sure that their particular departments are not the cause of any major issues discovered during testing. I recall giving one particularly damming report to three IT managers. Upon reading it two of them turned very pale, while the third smiled and said "great, no database security issues then".

IT staff will be the people responsible for fixing any issues found during testing. They will want to know three things. The name of the system affected, how serious the vulnerability is and how to fix it. They will also want this information presented to them in a way that is clear and organized. I find the best way is to group this information by asset and severity. So for example, "Server A" is vulnerable to "Vulnerability X, Y and Z. Vulnerability Y is the most critical". This gives IT staff half a chance of working through the list of issues in a reasonable timeframe. There is nothing worse than having to work your way backwards and forwards through pages of report output to try and keep track of vulnerabilities and whether or not they've been looked at.

Of course, you could always ask your client how they would like vulnerabilities grouped. After all, the test is really for their benefit and they are the people paying! Some clients prefer to have a page detailing each vulnerability, with affected assets listed under the vulnerability title. This is useful in situations where separate teams may all have responsibilities for different areas of a single asset. For example, the systems team runs the webserver, but the development team writes the code for the application hosted on it.

Although I've mentioned the three most common audiences for pen test reports, this isn't an exhaustive list. Once the report is handed over to the client, it's up to them what they do with it. It may end up being presented to auditors, as evidence that certain controls are working. It could be presented to potential customers by the sales team. "Anyone can say their product is secure, but can they prove it? We can, look here is a pen test report".

Reports might even end up getting shared with the whole organization. It sounds crazy, but it happens. I once performed a social engineering test, the results of which were less than ideal for the client. The enraged CEO shared the report with the whole organization, as a way of raising awareness of social engineering attacks. This was made more interesting, when I visited that same company a few weeks later to deliver some security awareness training. During my introduction, I explained that my company did security testing and was responsible for the social engineering test a few weeks back. This was greeted with angry stares and snide comments about how I'd gotten them all into trouble. My response was, as always, "better to give me your passwords than a genuine bad guy".

What should the report contain?

Sometimes you'll get lucky and the client will spell out exactly what they want to see in the report during the initial planning phase. This includes both content and layout. I've seen this happen to extreme levels of detail, such as what font size and line spacing settings should be used. However, more often than not, the client won't know what they want and it'll be your job to tell them.

So without further ado, here are some highly recommended sections to include in pen test reports.

• A Cover Sheet

• The Executive Summary

A bad way to end an executive summary: "In conclusion, we have found some areas where security policy is working well, but other areas where it isn't being followed at all. This leads to some risk, but not a critical amount of risk."

A better way: "In conclusion, we have identified areas where security policy is not being adhered to, this introduces a risk to the organization and therefore we must declare the system as insecure."

• Summary of Vulnerabilities

• Test Team Details

• List of the Tools Used

• A copy of the original scope of work.

• The main body of the report

Getting the level of detail in a report right is a tricky business. I once wrote a report that was described as "overwhelming" because it was simply too detailed, so on my next test I wrote a less detailed report. This was subsequently rejected because it "lacked detail". Talk about moving the goalposts. The best thing to do is spend time with the client, learn exactly who the audience will be and what they want to get out of the report.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Final delivery

When a pilot lands an airliner, their job isn't over. They still have to navigate the myriad of taxiways and park at the gate safely. The same is true of you and your pen test reports, just because its finished doesn't mean you can switch off entirely. You still have to get the report out to the client, and you have to do so securely. Electronic distribution using public key cryptography is probably the best option, but not always possible. If symmetric encryption is to be used, a strong key should be used and must be transmitted out of band. Under no circumstances should a report be transmitted unencrypted. It all sounds like common sense, but all too often people fall down at the final hurdle.