- [Speaker] The findings and recommendations section
in the penetration report is the meat of that report.
The information that is provided there
will be used to move forward with the remediations
and the mitigations of the issues that you found
in the environment that you tested.
And you already know that
the executive summary, it's where the,
very high level information about the findings
are actually documented
and not too technical.
So again, remember that you actually have to
keep in mind your audience.
Now, for instance,
if you're compiling a report
for a web application penetration testing
your ultimate audience for this section
and I'm talking about the remediation section
will likely be the development engineer
who are responsible for creating
and maintaining the application that is being tested
or the Info Sec
or information security team that is responsible
for that application.
Now you will therefore want to provide
a sufficient amount of information for them
to be able to
one, recreate the issue in the lab
or in their environment
and identify exactly where in the coat
you actually need to apply a patch and
what changes have to be made.
So let's say you actually found
SQL injection flow during the penetration testing.
In the report,
then you actually need to provide the actual HTTP request,
the response that you actually used to uncover the flow,
what were the actual input vectors
for that SQL injection.
And you also need to provide proof
that this is actually an exploitable flow
and not a false positive.
Now, ideally, if you're actually able to exploit the
SQL injection flow,
you should also provide a screenshot of
showing the results to the exploitation
and also recommendations
on how to actually fix the issue
and best practices on how to actually not only mitigate them
but probably, teaching those development engineers
or the Info Sec team how they can actually
find those vulnerabilities in a systematic way,
outside of a traditional pen testing engagement.
Now another best practice is
that you have to remember that this information can be
of course, very sensitive.
So if there's sensitive information from
an exploited database
then you should redact the screenshot
in a matter that is actually sufficient
to limit the sensitivity.
Now I have over 100 real life penetration testing reports
of course, sanitized reports in my GitHub repository.
These reports are from many different security companies.
You can review them and learn from them,
use them as a reference on how you can actually
write your penetration testing reports
and include mitigations and recommendations
and how you should structure the report
in an effective manner.