In the previous section, we learned that the Nessus report captures a lot of details about each vulnerability report. At times, when you are engaged as a consultant for a Vulnerability Assessment report, you may not want to use the report generated by Nessus to share with the client since it has a lot of details about each vulnerability; this can be well understood by and useful for a security consultant, but not for an end customer who just needs to understand what the vulnerability is and what needs to be done to fix it. Another case may be that you want to showcase the report in a different format provided by the client; for that, you need to customize the report accordingly.
It is completely up to you what parameters you want to include in your Vulnerability Assessment report. A default report generated by Nessus is pretty good and comprehensive. It might happen that you also need to see ease of exploit in the report or maybe the effort required to fix the vulnerability. What to include and what not to include in the vulnerability report is totally up to the person who creates the report and the organization's requirement. You are required to customize the reports accordingly.
Customization can be done by removing specific fields from the default Nessus report and adding extra fields into it that you need in addition to the default fields. If you are required to create the report in the Microsoft Word format, you can copy and paste from the default reports generated by Nessus.
I recommend the following format for generating an impressive report:
- Report front page:
- Name of the client
- Assignment or project name
- Report submitted by
- Document information page:
- Document title
- Version
- Author's name
- Reviewer's name
- Approver's name
- Document change history with dates
- Document distribution list
- Document data classification
- Header and footer on each page with data classification, page number, document name, logo of organization, and so on
- Executive summary:
- A brief about the Vulnerability Assessment project with its scope
- The vulnerabilities count with severity segregation
- The graphical representation of critical, high, medium, low, and informative vulnerabilities with their count
- The IP/vulnerability count graph
- A table with the name of the vulnerability, risk rating, business impact, and link to details in the same report
- Details section:
- Critical risk vulnerabilities
- Name of the vulnerability
- Vulnerability description
- Business impact
- Affected IP or application name
- Artifact of exploit (optional)
- Mitigation/recommendation
- Prerequisite to mitigation
- Patch name, if applicable to mitigate
- Vulnerability reference links
- CVE references
- Nessus plugin information
- Exploitable with (Metasploit, core impact, CANVAS, and so on)
- Implementation steps
- Implementation cost
- Implementation complexity
- Roll-back steps if mitigation is not successful
- High-risk vulnerabilities
- Same fields as mentioned under critical risk vulnerabilities
- Medium-risk vulnerabilities
- Same fields as mentioned under critical risk vulnerabilities
- Low-risk vulnerabilities
- Same fields as mentioned under critical risk vulnerabilities
- Informational vulnerabilities
- Same fields as mentioned under critical risk vulnerabilities
- Critical risk vulnerabilities
A penetration test report is a little different from the Vulnerability Assessment report. A penetration test report should also include a section on how to exploit the vulnerability with the evidence showing how it was exploited.