Priorities, CVEs, and CVSS

Even after processes are shored up, there will still be a need to prioritize what needs to be fixed next. Hopefully, with vetted and working processes backing up remediation efforts, this clean up will be manageable.

What to do next? Overwhelming operational areas with a giant list will only create a log jam. But, if we're focused on finding every weakness and trying to establish priorities, is that doing the same to TVM groups?



The temptation to say "Find everything!" is strong. Who wouldn't want to say they know all the flaws in their environment? In reality, vulnerability scanners can help to centralize intelligence about security weaknesses (especially from vendors), but it's hardly infallible. There are huge blind spots in most active vulnerability scanning solutions. Many InfoSec groups will consistently miss these blind spots in the deluge of information in the attempt to identify every weakness.

The first hurdle is in naming the enemy. Organizations struggle with the basics of threat modeling which is a necessity for assuring alignment between operational priority and security priority. If business leaders can't say whether reputation exposure, risk to consumers, loss of service availability, or data integrity impacts are more or less important, and they cannot be engaged to understand technical details from the security side, how will there ever be agreement about priority?

Defining a common language and rules of engagement with business and security teams will enable InfoSec groups to narrow focus to make remediation manageable with available resources.

Common language applies within security matters, as well. The effort to label vulnerabilities with a common lexicon that is understood across vendors is important. Vendors who eschew common reference formats in favor of arcane internal labeling systems designed to obfuscate the nature or presence of vulnerability work directly against information security and practitioners. While the concept of security through obscurity is still hotly debated in certain circles, refusing to use a common labeling mechanism makes tracking and remediation in mixed environments more difficult, which is always worse for security. Even if vendors release notifications only to subscribers or owners of the product, the lexicon by which these are able to be easily cross referenced with alerts from other sources is very valuable to informed TVM.

MITRE has attempted to address this with CVEs, CWEs, and CCEs. Adoption has been fairly wide, with open source communities and big vendors (like Microsoft) adopting CVEs for reporting, and with NIST archiving the CCE effort. Others, like the Center for Internet Security's Benchmarks also make reference to one or more of these.

But also consider the following:

• CVE reporting (and CVSS ranking) are voluntary. If the identifying vendor or finder does not report it under a CVE and provide a CVSS rank, there simply won't be one to use for prioritization. Many vendors (I'm looking at you, IBM) are expressly vague about the nature of weakness, making anything short of "patch everything right now" impossible for a security program. 
• Not every security weakness can be expressed in terms of a CVE. Default or weak passwords, poorly chosen configurations, or lack of encryption on a service that transmits sensitive data, for example, will not be expressed in terms of CVE, but something else (sometimes CCE or CWE if we are lucky).

But, what about priority? In many cases, the answer will be qualitative. Vendors provide some subset of information that will, hopefully, allow informed TVM pros to make judgments about what can and what can not wait according to the organizational risk tolerance and threat model. Unfortunately, this approach is very controversial. The difference in importance from professional to professional may be significant, and without public proof of concept, there is no way to actually know the impact in a given environment. These soft lines open the potential for charged political debate about security and operational budgets.

This debate has sent many in search of a qualitative approach that can be more uniformly applied and agreed upon. CVSS is likely the most well known solution, and it's a fair one. If organizations have a firm grasp on inventory and asset definitions, environmental and temporal metrics may compensate for many of the flaws in CVSS. But, seasoned TVM practitioners are well aware that not all these flaws are addressed by these measures. Many feel forced to use CVSS out of lack of other well known alternatives, acknowledging that the effort to make custom qualitative assessments for every weakness identified in a diverse environment is... time prohibitive - at best! To summarize the high points for those who are unfamiliar with CVSS, its chief hurdles are:

• CVSS pits vulnerabilities against other vulnerabilities in severity, but does not consider them within context of one another or the system on which they exist. Penetration testers will be first to tell you that chaining together several low or medium risk weaknesses will easily lead to full system compromise.
• Environmental metrics attempt to address this gap, but asset management and organizational threat models are seldom mature enough to leverage it properly.
• Vendors do not apply the rules of CVSS uniformly, resulting in overly inflated metrics. Consider how Microsoft treats C/I/A exposure as "Complete" for nearly every vulnerability instead of the more realistic "Partial" out of the assumption that every compromise will occur with an administrative privileged user. The threat vector is equally prone to be misapplied, for the same reason. Look at the FIRST guidance regarding Network vectors and then compare it to how Microsoft handles most Internet Explorer vulnerabilities as an example. It's respectable that some vendors assume "better safe than sorry," but this undermines the utility of qualitative systems like CVSS that are designed to make differentiation between exploits that require no user interaction, and those that do.

But, inside CVSS, this is valuable information to be had for TVM practitioners. Consider: wouldn't it make more sense for Remote Execution (Network vector) weaknesses to be higher in priority for Internet facing systems? Wouldn't it further make sense that anything with a known exploit is even more critical to fix? What about the impact as it applies to your organizational threat model? If downtime is no big deal, why put the same priority on denial of service weaknesses as you do on data integrity or confidentiality impacts?

Realistically, patching everything and making all configurations secure is ideal but often idealistic. Organizations compromise based on mitigations, resources available, and risk tolerance. TVMs job is to make that compromise the best compromise given all of the available data. Shifting TVM focus to enable organizations to institute, evaluate, and reinforce good supporting processes instead of using them to ticket every individual weakness for repair will get most organizations further into security. Then TVM can focus on more than patch auditing in order to get to smarter security, like protocol and configuration weaknesses that may not even show up in a scanner.