Two stakeholders.
What does that mean for the report?
It means we have two quite different things to get across.
We've got the non, or at least less technical side of the report.
This is for our manager, Chris, and perhaps other less
technical people in the business too.
For this audience,
we need to get across what the vulnerabilities mean to the business.
How much risk do they present, and at a high level,
how can the business protect itself from them?
We'll talk about this more in a later module. For the technical side, Vincent,
the security engineer, wants depth of information in order to
understand and fix, or at least mitigate vulnerabilities.
Without that depth, vulnerabilities may not get fixed effectively.
We need to get this right.
That means we have three things that absolutely must be in the report.
First, we need to detail what problems were found. That covers
largely technical details about a vulnerability.
Then, there's mitigation. How should the business respond
now that they know those problems exist?
This is, again, mostly technical,
but some mitigations can be more aimed at the business,
such as increasing training.
Finally, we need to highlight the risks.
This one is useful for the non‑technical audience and is more about
how the business should respond to the test results.
Before we think more about the detail of the report, we need to
consider Kim. Kim rates reports in a way that makes sense to her and
conform to the requirements of the business she works for,
Globomantics. Every pen tester is different.
Every business is different.
This means every report is different too.
By keeping the high‑level goals in mind and writing a
report that communicates effectively, Kim's reports give
customers exactly what they need.
Kim's report is only one way of doing it.
How you meet those high‑level goals is up to you,
as long as you're communicating effectively. Keep that in mind as we
continue. Before going into more detail, what structure does Kim's report
take? First, it has details about the test, so what was being tested and
why. Then, we've got useful information.
This section helps the reader understand how the report
works, so hopefully nothing is confusing.
Then there are summaries,
an executive summary for non‑technical people and a summary of
the vulnerabilities that were found too. The findings are
typically the biggest part of the report, and this details any
vulnerabilities that were found.
Finally,
there are appendices, further details about testing
that should be useful to the reader.
We'll go into all of these as we go through the course,
but for now, we're looking at findings