Does your security team rely too much on common vulnerability scoring system (CVSS)?

We recently shared an experience from a network segmentation project during which we discovered a technical vulnerability affecting Cisco’s Firepower Threat Defense firewall line. The firewall, itself, was not the problem, but, under specific conditions that are not uncommon in many environments, it allowed access through the firewall to systems it was meant to protect. In other words, the firewall rules that were supposed to be in place were no longer operating as defined.

Following the discovery, Cisco disclosed the bug. At first, we were surprised that Cisco’s Common Vulnerability Scoring System (CVSS) score was lighter than we expected. The fact is, Cisco did calculate the score appropriately according to the Common Vulnerability and Exposures (CVE) scoring method – the standard procedure for critical vulnerability scoring designed to help technology and security teams prioritize remediation activities based on understanding of the severity of a security vulnerability.

Why CVSS scores don't paint an adequate picture of security posture

After further consideration, we recognized the problem is that the CVE scoring method focuses on the equipment in isolation. It doesn’t consider how the equipment operates in a broader business or security context. As a result, technology and security teams that rely solely on a CVSS score don’t necessarily have an adequate picture of security posture and may, in fact, be elevating risk to their organization.

For example, an environment may delay system patches for 60 days, due to issues with downtime. This was a factor in the Equifax breach: High-priority servers in the company’s demilitarized zone (DMZ) couldn’t be taken down for patching in order to maintain full availability to consumers. Instead, the organization relied on compensating controls, one of those being the firewall. If a firewall has a vulnerability that reduces protection for those unpatched systems, the risk is significantly higher than may be perceived.

I like to use the image of a lowered boom gate, which is in place to stop traffic at a controlled point in order to verify that it is authorized to proceed to a sensitive destination beyond the gate. While the gate works properly, the lack of surrounding fence to enforce traffic through the boom gate resulted in a system wide security failure even when the boom gat may be operating as designed. In this image, with snow on the ground, it is easy to see from the tracks on either side that cars simply drive around the gate to get to the controlled facility.

How to use CVSS scores as a tool, not as a primary input for decision making

Many companies rely on CVSS scores to determine when (or when not) to patch or to approve exceptions based on compensating controls. It is important to understand the limitations of the CVE scoring system and not rely solely on a rating provided by a vendor. For one thing, the scoring process itself is extremely complex. It involves three types of metrics, each with subcategories. There are several alternative ways to score each metric. A calculator produces the CVSS score based on the metrics and scoring approaches selected. Our analysis has found that adjusting metrics within the CVE calculator for how a tool impacts the systems it is supposed to protect could change CVSS score, signaling a far greater risk than the score may otherwise have indicated.

I’m not suggesting the ratings are wrong; they are typically correct for the equipment as designed. Rather, it is the scoring system that is flawed – or better stated, not sufficient on its own. In the Cisco case I mentioned at the outset, Cisco’s CVSS score is based on the risk and likelihood that its firewall is compromised, which is “medium.” That score does not consider the risks of access caused by issues in the wider system hosts that the firewall is protecting, which in this case could be much greater. It assumes that the rest of the network is secure based on other controls, which is often a poor assumption.

Security teams need to evaluate every patch that the organization chooses not to apply against the compensating controls you think are operating effectively and ask yourself – what if it doesn’t, then what risk am I exposed to. And when a new vulnerability comes out, especially related to a control system like a firewall, the team needs to re-evaluate all of the compensating controls to determine the full risk exposure of not patching – not making the business decision solely on the impact to the firewall itself.

So, if you rely upon the CVSS scores as a primary input for making decision around critical security patching and when to apply other compensating controls, make sure you are not lulling the organization into a false sense of security. In doing so, you may be putting the organization at far greater risk than you realize.