Vulnerability analysis/penetration testing (VA/PT) is an active process of identifying existing vulnerabilities and available exploits in a security implementation, to penetrate susceptible systems on the basis of this information. A penetration tester is considered a specialist -- engaged to not just get
A penetration test is useless, unless paired with a well drafted technical report. A good VA/PT report is one understood by all, and more importantly, outlines immediate risk mitigation measures. VA/PT reports must outline the test approach and results. It should also highlight vulnerability classifications and recommended measures, which should be documented to secure any high-risk setup.
The VA/PT report must have an introduction and a table of contents. These should include details such as the scope, project details, timeline, methodology, summary, results, and a conclusion. A report should contain the following sections:
- Executive summary: This is a brief test overview, prepared with the key management in
mind. It targets decision makers who want to know the issues and their consequences, without the
need for technical information. The executive summary should focus on building a proper business
case providing the details of, and impact of the findings -- along with remediation steps.
Graphical representation is an effective method for communicating the findings in a VA/PT
- Project scope: A VA/PT report should first define scope. The scope, in general, includes
details such as IP addresses/range (public facing or internal) and type of attack used (whether
social engineering, Trojan and backdoors were permitted, and any limitations thereof). The
methodology adopted (black, gray or white box) should also be explicitly mentioned in the scope. It
should also include an estimate of the number of attempted exploits and respective types.
- Result analysis: This is central to a VA/PT report. Result analysis gives a complete
picture of all identified vulnerabilities, severity, and recommended remedial action. This section
should not contain raw output from used tools. Rather, the specialist should provide an analysis in
a summarized format. The testing technician can choose to include snippets of code, used scripts,
parameters tampered with, evidence of privilege escalation, and gained access. Here is a
sample from the Cisco press book.
- Conclusion: The results section should be followed by a technical conclusion for the
complete exercise. It should be prepared considering a technical audience, and the present the
organization's security posture, depending on the analysis. The conclusion may also include such
vulnerabilities as were identified across all systems; for example, usage of old versions and
missing patches. The most important recommendations may be presented in points.
- Appendices: The appendix in a VA/PT report should include at least the following:
Output of vulnerability identification
2. Screenshots of active attempts
3. Evidence supporting proof of concept of active penetration
4. Evidence showing failures
Useful VA/PT report preparation tips
A VA/PT report should contain information of all tests carried out. Detail automated and manual scans, as well as conducted tests -- while noting any unusual behaviour with screenshots.
Creating a tracking sheet beforehand is a good practice, as this is akin to preparing an initial VA/PT report draft. It can track the exercise's progress. A tracking sheet can give an overview of the progress, and help better understand the work flow. Details of performed raw scans may be saved for future reference and proof.
Small steps go a long way in producing quality VA/PT reports. Practices like using spell check and highlighting the findings in screenshots help. When an attack is carried out, clearly illustrate the difference in flow between a normal user and an attacker. Do arrange the findings as per severity. If any issues have been fixed in the interim, screenshots confirming the same may be shown in the VA/PT report.
While finalizing the VA/PT report, crosscheck minutiae, and subject it to review at least once (by a senior technical expert or team lead). The report may also be sent to a quality assurance team to identify whether the report meets current industry standard or organizational requirements.
About the authors: Gaurav Srivastava is an information security consultant and trainer with more than six years of infosec experience. He is currently working as a consultant (project manager) at SISA. He is a Payment Card Industry Qualified Security Assessor (PCI QSA), who has successfully conducted more than 60 assessments. Gaurav has provided noticeable consulting services on PCI compliance, ISO27001 and HIPAA for leading M-Commerce merchants, IT companies, banks and BPOs.
Antriksh Shah is a security analyst and consultant from Goa. He is a member of open security community null, and a HoneyPot resource person for the Computer Society of India. He has worked with the Pune Police Cyber Cell.
(Compiled by Varun Haran.)
This was first published in May 2011