TABLE OF CONTENTS
On the very next page, you should have an index so that the audience
interested in reading a particular portion of the report can easily skip
to that portion.
EXECUTIVE SUMMARY
As the name suggests, an executive summary is the portion that is
specifically addressed to executives such as the CEO or the CIO of
the company. The executive summary is the most essential part of a
penetration testing report; a good executive summary can make all
the difference between a good report and a bad one.
Since the executive summary is specifically written to address the
nontechnical audience, you should make sure that it’s presented in
such a way that it’s easily comprehensible. Following are some of the
essential points that you should take into consideration while writing
an executive summary.
■ Since executives are very busy, they have minimal time to invest
in reading your reports. Therefore you should make sure that
your executive summary is precise and to the point.
■ Your executive summary should start with defining the purpose
of the engagement and how it was carried out. Things such as
the scope should be defined but very precisely.
■ Next, you should explain the results of the penetration test and
the findings.
■ Following this, you should discuss the overall weaknesses in
general and the countermeasures that were not implemented that
caused the vulnerability in the first place.
■ Next comes the analysis part; this is where you should write
about the overall risk that was determined based upon our
findings.
■ And, finally, you should write about to what extent the risk
would decrease after addressing the issues and implementing
the appropriate countermeasures.
The following is an example of an executive summary that we wrote
for a customer. I would suggest you spend some time reviewing the
essential points discussed and compare them with the executive
summary that follows.
REMEDIATION REPORT
Next up we have the remediation report, which contains the overall
recommendations that once implemented would increase the security
of the organization. This is specifically an area of interest for the
management class, as they are the ones that are going to enforce the
security policies of an organization.
As mentioned earlier, these guys may or may not be technical;
therefore our remediation report should be very precise and easy to
understand. Things that could improve overall security such as
implementing SDLC, a firewall, and an intrusion detection system
should be recommended. The following is an example of how a
remediation report should look like:
Vulnerability Assessment Summary
Next, we have the vulnerability assessment summary, sometimes
referred to as “findings summary.” This is where we present the
findings from our engagement. Things such as the overall strengths
and weaknesses and risk assessment summary can also be included
under this section.
“A picture speaks a thousand words” is a brilliant quotation that all
of us remember from our childhood, don’t we? Behold, for now it’s
time to see the actual use of it. It always helps to include charts in
your report, which would give the audience a better understanding of
the vulnerabilities that were found. Security executives might be
interested in this portion of the report as they would need to enforce
the countermeasures.
There are different ways for representing vulnerability assessment
outputs in the form of graphical charts. Personally, I include two
graphs; the first one classifies the vulnerability assessment on the
basis of the severity and the second one on percentage.
Next, I include a “vulnerabilities breakdown” chart, where I talk
about the findings for a particular host followed by the number of
vulnerabilities that were found.
TABULAR SUMMARY
A tabular summary is also a great way to present the findings of a
vulnerability assessment to a customer. The following screenshot
comes directly from the “NII Report” and summarizes the
vulnerability assessment based upon the number of live hosts and
also talks about the number of findings with high, moderate, or low
risk.
Risk Assessment
Risk assessment as defined before is the analysis part of the report. It
is very crucial for the customer because they would want to know the
intensity of the damage the vulnerabilities are likely to cause;
similarly, the security executives would also want to know how their
team is performing.
RISK ASSESSMENT MATRIX
When we talk about risk assessment analysis in terms of a penetration
test, we compare the “likelihood of the occurring” and the “impact
caused by the occurring.”
The following is a “hazard risk assessment matrix” derived from
MIL-STD-882B; it’s an excellent method for demonstrating risk to
the customer. In the following matrix the “frequency of occurrence,”
that is, the likelihood of how often the vulnerability is occurring, is
compared with the four hazard categories “catastrophic,” “critical,”
“serious,” “minor,” and this is something you should definitely
include in your penetration testing report.
(From http://www.sms-ink.com.)
After including the risk assessment matrix, you should write a line
or two describing the total risk.
Based upon the comparison of the vulnerabilities that were determined, their likelihood
and their impact we conclude the overall risk is high and the risk percentage was
determined to be 82%.
Methodology
We have discussed a wide variety of methodologies and standards of
penetration testing, such as OSSTMM, NIST, and OWASP. I would
also like to include the methodology that was followed for
conducting the penetration test; though its inclusion in the report is
optional, it could add great value to your penetration report. In a
scenario where you have been asked to follow a certain standard,
talking about the methodology and its steps is a good idea.
The following is a screenshot from one of our penetration testing
reports where the NIST methodology was followed in order to
conduct the penetration test. Notice that we include the flowchart on
how the methodology works and explain each step precisely.
DETAILED FINDINGS
This is where you address the technical audience, specifically the
security manager and the developers; also, this is where you are
allowed to talk in depth about how the vulnerabilities were
discovered, the root causes of the vulnerabilities, the associated risks,
and the necessary recommendations.
Let’s now briefly talk about four essentials that should be included
in the “Detailed Findings” section.
Description
This is where you talk about the vulnerability itself; a brief
explanation should be provided in this section.
Explanation
This is the section where you reveal where the vulnerability was
found, how it was found, the root cause of the vulnerability, the proof
of concept, or the evidence of the finding.
Risk
This is where you talk about the risks and the likely impact that the
vulnerability carries.
Recommendation
This is where you address the developers on how to fix the
vulnerability; you may also include general suggestions to avoid that
particular class of vulnerability in future.
The following screenshot comes directly from one of our
penetration testing reports. Our finding was “DOM-based XSS”
vulnerability. In the “Description” section we discussed the
vulnerability. In the “Explanation” section, we talked about where the
vulnerability was found and what line of the JavaScript code is the
root cause of the vulnerability. We then talked about general risks and
the impact and finally the general remediations to avoid
vulnerabilities of a similar class.
0 Comments