Prioritization Of Vulnerabilities Requires Proper Intelligence

With well over 170,000 known vulnerabilities published and over 21,000 new disclosures in 2017, organizations must make constant risk decisions. The longer a decision on the best course of action is put off, the longer it takes for a control or patch to be implemented, increasing the organization’s Time of Exposure.

Bottom line, there are a ton of vulnerabilities out there already. Record numbers were disclosed in 2017 just through Q3, and there are absolutely no signs of it slowing down in the future.

While vulnerability management may seem old hat to many, it is hard to argue that the game hasn’t changed. Organizations must ensure that they have an updated and robust program in place to prioritize issues, as they are disclosed.

There has long been debates over how organizations should actually prioritize vulnerabilities. Most organizations today rely on Common Vulnerability Scoring System (CVSS) as a way to try to help. CVSS creates a numeric representation for the risk of a vulnerability based on a formula that looks at the impact and exploitation requirements.

CVSSv1 was first released in February 2005 by the National Infrastructure Advisory Council (NIAC). This initial draft was not subject to peer review or reviewed by other qualified organizations. In April 2005, NIAC selected the Forum of Incident Response and Security Teams (FIRST) to become the custodian of CVSS for future development.

Feedback from vendors utilizing CVSSv1 in production suggested there were “significant issues with the initial draft of CVSS“. Work on CVSSv2 began in April 2005 with the final specification being launched in June 2007.

There has been quite a bit of concerns voiced about the implementation and usage of CVSS over the years, starting in 2013, when we at Risk Based Security published an open letter called CVSSv2 Shortcomings, Faults, and Failures Formulation.  In addition, Kenna Security, starting in 2015 conducted their own analysis and published material about the issues with CVSS. CVSSv3 was officially released on June 2015, and as we have documented in our blog series, there are still quite a few issues with the latest version.

As more companies embrace data analytics and hire data scientists, vulnerability prioritization has become a bigger focus, and it can be improved by adding additional metrics in conjunction with CVSS scores. We take great pride in the quality of our data in VulnDB and have been adding many additional metrics for our clients to assist in their prioritization efforts.

Last night, wording of a vulnerability that was newly published in CVE-2018-6888 caught our eye:

In looking closely at the description we see the following:

An issue was discovered in Typesetter 5.1. The User Permissions page (aka Admin/Users) suffers from critical flaw of Cross Site Request forgery: using a forged HTTP request, a malicious user can lead a user to unknowingly create / delete or modify a user account due to the lack of an anti-CSRF token.

While this description on the surface may seem normal, a single word caught our eye: “critical”.

Not only is using the wording “critical” an exaggeration of the severity of this vulnerability, it suggests there is insufficient vetting happening of new CVE descriptions. It is not customary to define the impact of a vulnerability in the CVE description and breaks with normal operating procedure for the past 15+ years.

If you search CVE for the word “critical”, you’ll find just 846 CVE entries that match. Almost every one of the matches are for “access to critical data” or similar wording, and very few have used it in the context of risk. Based on a quick parse, only three other entries use the word critical in the context of the severity of the vulnerability.

So, while MITRE has used the word “critical” in the past, CVE descriptions typically don’t provide any prioritization metrics; but in this case they have told anyone reading the description that this CSRF is a “critical flaw”.

When looking at NVD, where prioritization metrics are added for CVE IDs (in the form of CVSS scores), we can see that there is no further information to be had at this point.

When we look at the same Typesetter vulnerability in VulnDB, what do we see?

As you can see the CVSS base score is 4.3, and while there is an exploit publicly available, which we advise our clients to pay close attention to, as this significantly changes how vulnerabilities should be prioritized, notice that it is a vulnerability requiring user interaction (Context Dependent).

All in all, risk decisions are unique to each organization, but on the whole we do not see anything to suggest that this should be labeled a “critical flaw” as described by MITRE.

Since NVD has no data published on this vulnerability (hint: the last vulnerability they processed is from January 26, 2018, and yes, it is now February 12th), we aren’t able to see if their CVSS score concurs with the CVE description. You can take our word for it, or check some older CSRF vulnerabilities in NVD, but we expect they will find that this issue (eventually) isn’t critical as well.