Finally, a very brief set of tips to squeeze just a little
more efficiency out of the reporting process.
The first is to avoid anything complicated in your reporting. Lots
of complicated formatting, front changes, and rules about exactly
how things look can add complexity.
Report writing can be time consuming enough without having too many
rules about how it should look. Avoiding complexity saves time and
leaves less room for mistakes. By all means, use your own style on a
report, but do keep it simple. Documenting vulnerabilities as you find
them, this is a little less about the report itself and more about what
you do as you're testing.
If you're anything like me,
then you get the urge to vaguely document findings as you get them
and interrupt your testing as little as possible.
This always fails me. At the end of the test,
I write up the report and always see things I forgot to get
and then need to recreate. When you get a finding, document
it right then. Get evidence, screenshots,
all of the details, write it up ready for the report.
You will not regret it at the end of the test.
Sometimes a pen test will involve multiple testers, and that can
complicate things a little. Luckily, you read the last tip and
document your findings as you go.
When the other tester finds a vulnerability,
they can look at your findings and make sure there aren't duplicates.
Be very aware that good communication is a difficult thing.
When you're working with other testers,
you need to put in the effort to communicate what you're
doing and the vulnerabilities that you found. It will make
the whole process go more smoothly.
If you're using something like PwnDoc,
then it will be very easy to see findings already associated with the test.
In this module,
we've really looked at how to refine the process of reporting. We've
seen our templates can help us to improve our efficiency, and we've
looked at using automation. It's very easy to spend a lot of time
writing custom wording. As much as possible, we want to take wording
that we create and reuse it.
The more reports you write, the more you'll see common pieces of text being used.
It's also important that we don't let using templates and
automation make it easy for errors to creep in. These things help
us to do a good job, but if we're not careful,
it's still easy to make mistakes.
We need to keep quality in mind.
So that's it.
In this course,
we've looked in depth at pen test reporting, the end product of a pen
test. We've covered the goals of a report, to detail the vulnerabilities,
state the mitigations, and highlight the risks. To reach these goals, we
need to keep our stakeholders in mind.
That means communicating both technical details, as well as non‑technical,
such as likelihood, risk, and impact. A good pen test needs a good report.
If you want more,
then there are other great courses on Pluralsight
that might help. In particular,
there's a whole learning path named Communications for Technologists,
which has a number of courses dedicated to written communications.
If you've got any questions on pen testing, security in
general, or comments on this course, and I'd love to hear them,
just leave a message in the course discussion area or catch me on Twitter.
I'm @dGav_JL.
Thanks for watching.