BackBox NVM helps manage the entire vulnerability lifecycle, with differentiated capabilities along the way. The purpose of this post is to highlight the lifecycle and BackBox unique differentiation.

It’s inspired by this image of how a CVE gets created:

There are three steps in the vulnerability lifecycle:

1. Assessment
2. Application
3. Action

Assessment

The two main questions to ask at this stage of the lifecycle are:

What is this new vulnerability?

How bad is it?

Many solutions will deliver the CVEs into the product. These CVEs come from the NIST database and are available to everyone. However, the CVE isn’t all the information available about the vulnerability. There’s other information such as whether or not the vulnerability is known to be exploited (which comes from CISA, not NIST).

BackBox enriches the CVE with additional information from CISA, the vendor, and other online communities to help you understand more about the vulnerability and its potential for disaster. This enrichment has always been important (and differentiating) but has become more so as NIST have themselves stopped enriching CVEs.

Once enriched, the vulnerability is scored. Unlike the CVSS score, our risk score is based on the enriched CVE information (like whether a vulnerability is being exploited, how easy it is to exploit, and whether the affected device is internet-facing).

In summary, assessment involves CVE enrichment and dynamic risk scoring (meaning as information about the CVE changes, the risk score is adjusted… unlike the CVSS score which is determined at the time of CVE publishing but not updated).

Application

Does this vulnerability apply to my network?

One simple question, but a lot of implications.

We map vendor, product, and version of your inventory against each CVE to determine at a high level if the CVE might apply.

As mentioned above, but worth repeating, based on whether or not a device is internet-facing, the risk score is adjusted to reflect that additional risk. The risk score therefore is both based on the severity of the CVE, the information gathered in enrichment, AND your network architecture. Again, differentiating from simply mapping a CVE against inventory.

To be clear, CVEs have a risk score, as do devices based on the CVEs, enrichment data, and position of the device in the architecture.

Search can be used to determine if specific configuration parameters affected by the CVE are in use or apply to your devices. For example, recently Cisco had a CVE related to http-server. Search would have been used to find all the relevant devices from the pool of vendor/product/version impacted that had http-server turned on.

If a CVE is determined not to apply, BackBox NVM has tools to help mark CVEs as irrelevant to help teams manage their exposure. CVEs that are marked irrelevant are removed from the risk scoring calculation to help network engineers focus on the vulnerabilities that impact their network.

Which leaves us one final question.

Action

What are my options if a CVE applies to my network?

Here again is where a lot of competitive solutions fall down. Those products are informational. They’ll point out devices and CVEs, and then create a report. BackBox will help you mitigate or remediate the fix.

Generally speaking, the way to remediate (permanently fix) a vulnerability is to do an OS update. However, often the update isn’t available when the CVE is first published, or there simply isn’t time (or team capacity) to complete the OS update right away. That’s when mitigation (temporary fix) comes into play.

In both cases, OS updates or configuration mitigation, automation comes into play as the way to protect the network at scale. A solution that can’t automate the fix is only a partial solution.

Is there a problem

For major vendors / CVEs BackBox often releases an automation within about 48 hours that helps customers determine if they’re vulnerable. This automation will do two things:

1. It will look for the specific configuration parameters that are vulnerable and let you know if you’re exposed (or safe).
2. It will allow you to mitigate the vulnerability by turning off the vulnerable features.

Using our Cisco example from earlier in this post… we released an automation that looked to see if http-server were enabled, and gave customers the option to disable it.

Which begs the issue… if a feature is turned on, it’s probably needed. Clearly, turning off a needed feature should be a temporary fix.

A permanent fix

The permanent fix is the OS update, when it’s available from the vendor. And, BackBox of course simplifies OS updates with automation as well. (Read about how Edafio, a US Service Provider, saved about 70 hours a month by automating updates.)

Summary

It’s worth summarizing this vulnerability lifecycle for simplicity.

A new CVE is posted. BackBox enriches the CVE with relevant data, gives the CVE a risk score (that’s updated daily if any information about the CVE changes), and maps the CVE to inventory.

Using search, network engineers can look at specific vulnerable configuration parameters and determine if they’re exposed. They can automate mitigation right away to turn off vulnerable features and protect the network.

CVEs that are “irrelevant” can be marked as such, so that risk scores reflect the actual risk on the network.

Finally, once the vendor releases an OS update with a patch to the vulnerability, BackBox simplifies the update process with automation to make it easy to permanently protect the network. Once the update is in place, any mitigation actions that were taken can be undone through automation to turn features back on now that they’re safe to use again.