Hi there SecurityStreet! As a Technical Proposal Writer for Rapid7, I get to do technical deep dives of Nexpose with our Engineering and Security Solutions teams. Lately I've had a lot of chances to describe the enhanced CSV exports we've added in Nexpose 5.2, but up until now I haven't gotten the chance to really show off their capabilities.
As Sean Blanton said in our first demonstration of the new CSV export capabilities, users are now able to draw up reports from virtually any of the data that Nexpose collects. This results in reports that are targeted toward specific risk assessment goals, better enabling each user to illustrate their take on the data. By putting the data in Excel, we can create pivot charts and tables that offer unique visual insights into risk that we might not have otherwise obtained.
What I found most interesting about parsing out the data in Excel is that users can layer data fields in different ways and perform calculations on data fields that are not possible in the standard vulnerability management model. Using the Excel form factor, equations can be easily inserted to produce new kinds of data. In my first report, I use Excel's capabilities to layer data to really show what sort of new context can be created around already obvious conclusions from the data; and in my second I use an equation to create an entirely new set of useful data.
Report 1 – Making the Simple Data More Powerful with Layering
WHO: Managers who need a broad perspective on their risk remediation game plan.
WHAT: This report layers data fields to sort vulnerabilities by the type identified, and within those categories, shows vulnerabilities by risk score as well as the number of exploits associated with them. Nexpose provides test results for each vulnerability check performed: “vulnerable” represents a vulnerability that has been confirmed using an exploit, and “vulnerable version” represents a version of the scanned service or software that is vulnerable. There are numerous other result codes Nexpose uses to provide in-depth information around what type of check was performed and what was found. This information is important to identify what type of vulnerabilities you are discovering.
WHY: This report is a different perspective on the data we look at every day – risk score and exploit count. It lays out which groups of vulnerabilities have been identified and uses simple sets of risk metrics to illustrate the risk posture of the asset group.
Report 2 – Using Differentials to Identify Newly Discovered Vulnerabilities
WHO: Engineers directly responsible for remediation of assets in the report.
WHAT: This report provides a newly created column, “New Vulnerabilities,” containing an equation that outputs whether or not each vulnerability was discovered in the most recent scan. It compares the Vulnerability Test Date column, which identifies the date the vulnerability test was run, with the Vulnerable Since column, which identifies when the vulnerability was first discovered. If these two fields are the same, the vulnerability must have been discovered in the most recent scan. The pivot table shows the maximum risk of any newly discovered vulnerability – as well as the number of exploits discovered for each vulnerability – and provides a list of these vulnerabilities.
WHY: This report fits in very well with the workflow security staff have established around remediating vulnerabilities. Often the most important vulnerabilities to remediate are whatever newly discovered vulnerabilities have been detected. This report allows security staff to quickly identify the most recent and unaccounted for vulnerabilities, enhancing defense capabilities.