Last updated at Wed, 30 Aug 2017 19:53:52 GMT

In my last blog post I went in depth on Impact Driven Analysis and Response, an often-overlooked but very handy analysis option in Nexpose. Today I'd like to talk about another great option for analysis - filtering assets based on their discovered vulnerabilities by Vulnerability Category. We will use Filtered Asset search to take a focused look at a specific category: Default Account findings.

Default accounts are high significance findings with low effort remediations, making them an easy win for targeted analysis. We'll look at how to perform this analysis and the operational value of these easy wins for new and maturing vulnerability management programs.

[RELATED: Default Accounts Focus [VIDEO] | Rapid7 ]

Performing Default Account Analysis

Looking at Vulnerability Categories

A Vulnerability Category is simply a grouping of similar vulnerabilities based on common criteria.  A single vulnerability may belong to multiple categories, i.e. a Cisco default account finding may show up in the 'Cisco' category and the 'Default Account' category. You can view an interactive drill-down list of available Vulnerability Categories directly in your Nexpose Console. Just use this URL, substituting in the hostname for your console: 

https://localhost:3780/vulnerability/categories.jsp

We're going to focus on the Default Account category, but this same analysis technique can be used for any category. I recommend taking 10-15 minutes one day to look down that list and see what catches your interest.

Vulnerability Category Analysis - Filtered Asset Search

You can get to the Filtered Asset search feature using the Filter icon in the upper right of the UI or by selecting 'Dynamic Asset Group' in the Create mean at the top.

The Filtered Asset Search feature allows you to search for assets based on the specific Vulnerability categories for discovered vulnerabilities. Take a look:

You can save your search results in an Asset group (either Dynamic or Static) or as a dynamic RealContext tag for ongoing analysis. I would call this group 'Default Accounts' and add a corresponding red custom tag myself, but you can configure it how you like. If you configure a Dynamic Asset group, this list will automatically update with each new scan.

Targeted Reporting

In addition to searching for assets, you can filter reports by Vulnerability category as well.  In the 'Scope' section of the 'Create a report' view in Nexpose, there is a 'Filter report scope based on vulnerabilities' option.  You will see the ability to filter by Vulnerability Category - just select the 'Include specific' radio button and use the multi-select dropdown.

Responding to Default Account Findings

Why They're Significant

Default account findings are of especially high significance because they open the door for an attacker to directly access a system without the effort and risk of detection associated with executing an exploit. There's a reason default accounts are instant-fail findings for PCI compliance. Using standards-based metrics can be an effective way to help communicate this significance more broadly, for instance:

There will be some nuance to the impact for any given environment, but hopefully the above example helps demonstrate the scale of the significance for these findings.

Resolution

One of the great things about a default account finding is how easily you can confirm and remediate the finding. All that you need to do to confirm the finding is try to log in with the same credentials. In order to remediate the finding, you can either remove the default account or change the default password for the account.

This does, of course, assume the account is modifiable; if it's baked in to an embedded system, you would have to sort that out with the vendor and restrict all access to that particular service at a lower layer (i.e. firewall protection). Leveraging the CVSS score and the Nexpose Real Risk score associated with the finding may even help to communicate the significance of these findings to upstream vendors.

An Easy Win!

As we discussed above, default accounts are high significance findings with low effort to remediate.  This makes them a great option for organizations just starting their vulnerability management programs, or simply growing and maturing their existing process. Starting with targeted analysis lets you focus more time up front figuring out the practical operational details of your program, including: communication channels for remediation (i.e. report distribution, ticketing system integrations), organizational ownership for remediation, and managerial oversight.

Often these practical details create the biggest blockers to getting real security work done. By focusing on easy win findings at the beginning, you can help everyone involved with the program get comfortable with the workflow.

Custom Account Checks

One of the first questions people ask when they see this functionality is, "how can I add my own default accounts?" Often times developers will use common credentials for convenience during the development cycle with the intent of disabling those common credentials for production. Missing that last step can be a major problem though, and a diligent security team will want to validate that no in-house common credentials get used on production systems.

Good news - it is possible to create your own Default Account checks! You can write a custom vulnerability check for a default account using the instructions from the 'Default account checks' section of the Community site.

If you'd like an easier approach than writing custom vulnerability checks, you're not alone!  That idea has been suggested in our Idea Portal.  All you have to do is click here, log in with your customer (or employee) support credentials, and vote!