Victor at Carved Rock is the technical person that we're targeting.
Almost all of the detail in a finding is aimed at someone technical.
We'll have a description of the vulnerability,
something high level to help Chris see what this class
of vulnerability often looks like.
Then, we'll move on to the detail of the finding,
the first of our high‑level goals.
This gets across exactly how a vulnerability presented itself
during the test. For technical people, it's important that we
detail how to find and exploit it.
That means later on they can repeat the process and see if it's still a problem.
Importantly, a couple of months from now,
could you read this and repeat the problem? Remediation, our second
high‑level goal, so fairly important to get this right.
This should detail one or more ways to fix the vulnerability.
Often, there isn't just a single way to fix or mitigate a problem, and
an overlapping set of defenses are always helpful.
Finally,
it's good to add links to further information
should the readers want or need it.
This can be links to articles on remediation, but
can also be about education too.
Some readers will just want to fix things as quickly as
possible, but just in case they want to learn and discover
more, give them the resources to do that.
Now back to Kim's report. Right at the top of the finding, we've
got severity and risk calculations, so again,
some transparency, including a link. If they're interested, that will
give them lots of detail on how the score was arrived at. The risk is
likelihood multiplied by impact, as described earlier in the document.
We're keeping the color coding so at a glance it's clear how important
each finding is.
The description at the top focuses on what the vulnerability is.
We're telling technical people about the vulnerability in
general terms here. In this instance, we're talking about patches,
why patching late can be a problem and understanding what type of risks this
vulnerability brings. In the Detail section, we're talking technical on how
the vulnerability presents in this instance.
So here, we're saying we found this by doing port scans to
find a computer using SMB version 1, which is vulnerable to EternalBlue.
We're telling them what that means, so remote code execution, and we've got a
screenshot to prove that we did indeed have the ability to execute code on
that computer. Clearly telling the reader exactly where the finding is is
important. Notably in this case. Kim hasn't given the reader enough
information to reproduce this finding.
She has, however, given them enough to find it elsewhere.
The appendix with ports scans details using Nmap to find open ports. From
there, they could assess if SMB version 1 is in use or if patches are in
place. They don't need to use Metasploit to do that.
This last part of that paragraph, we're thinking
transparency again. We're talking about likelihood. In this
case, it's a very well‑known exploit.
It grants a remote code execution, so the impact is going to be high.
This all supports the scores that we've given at the top of the
finding. The description and detail hit one of our high‑level goals,
to detail the vulnerability. Finally, remediation, for our goal of
stating the mitigations. Here, we haven't just told Vincent that
patching should be done.
We've also mentioned that the operating system has reached end of
life. That wasn't part of this vulnerability,
but it is still useful.
Hopefully Vincent was already aware of this,
but there's no harm in adding it. Further to the remediation, we've
got a number of links. These all support what we've said in the
finding. We're giving the reader as much information as they want
to be able to understand this.
Looking at another finding, we see very similar things. Notably in this one,
we're highlighting areas of our screenshot.
We're making that image easy to consume by doing this.
We've also got some areas redacted. Kim doesn't know what's
going to happen to this document when it arrives at Carved
Rock, so to err on the side of caution, she's removed any passwords.
We've looked at findings in our report and seen some
important things come out of that.
The first is our three goals, detailing vulnerabilities,
stating mitigations, and highlighting risks.
We're also starting to see some other important things too. Transparency is
important to help the reader trust what we're seeing.
Unfortunately,
some pen tests have a tendency to inflate the importance of
findings, so having transparency is good. Readability too. The
report so far is by no means a wall of text.
We've used our words wisely and used titles to make it easy to read.
Finally,
there isn't a single best way to write your findings
or, indeed, your whole report.
If we've kept our goals in mind and added some readability and transparency,
then we've got findings that will be incredibly helpful to the customer.