Vulnerability Prioritization & the Magic 8 Ball

Source: olga Yastremska via Alamy Stock Photo

COMMENTARY

Last month marks 25 years of operation for the CVE (Common Vulnerabilities and Exposures) program, launched in September 1999. It’s difficult to imagine a world without CVEs. Much of the “vulnerability management” activities, before the CVE program became popular, relied on matching version numbers from remote scans and executing shady exploits found in dark places on the Internet to validate findings. We’ve come a long way when it comes to vulnerability tracking. Our journey has been fraught with peril, however, and we still have many challenges to overcome, including:

• Volume: To keep pace with the sheer number of CVEs being created each year, we’ve had to increase the numbering format and assign CNAs (CVE Numbering Authority), spreading the responsibility and making it difficult to be consistent.

• Date tracking: In certain circumstances, CVEs will be issued in the current year but with a previous year in the designation. Sometimes this is due to CNAs being pre-assigned CVEs for future use. However, this can make tracking and analyzing vulnerabilities in the CVE database by year inaccurate. This is rare but problematic, because it leads security practitioners to believe it’s an older vulnerability, and some may not pay attention to it.

• Free market: While there are some guidelines and barriers, for the most part, anyone can get a CVE issued. While it’s important we not limit the creation of CVEs to prevent people from trying to hide a vulnerability, the free-market concept has caused issues. There are recent reports of folks automating the process of creating CVEs — hundreds of them — based on previously fixed bugs in GitHub repositories.

While the creation of formal tracking for vulnerabilities was huge for the industry, it wasn’t until 2005 that we began to assign a severity rating using CVSS. This, too, is not without challenges, such as:

• Subjective scoring: Anyone can score a vulnerability using CVSS and publish the results. We need checks and balances. If the security researchers who found the bug believe the severity to be different from the vendor that created the software, we should be able to see both scores.

• It reflects only the vulnerability: While you can use CVSS to customize the score for your environment and take into consideration compensating controls, most users will just go by what has been published. Often, vulnerabilities are scored by the CNA that owns the software, and its incentives are not to score vulnerabilities on the high side.

• Multiple versions of CVSS: Since CVSS version 1 was released in 2005, three subsequent versions have been released through November 2023. A CVE entry scored with a previous version may not be updated to the latest version. CVSS scores should also be updated due to changes in the security research landscape or new information about the vulnerability. These changes, if they happen at all, can be difficult to track.

What Do We Do Now?

Given there are pros and cons to each of these programs whose intentions are to help organizations make informed risk-based decisions, how do we know what to patch first? Many will rely on one mechanism, likely CVSS, pick a magic number, and patch everything that scores above that magic number. The problem is this is a very limited view of the vulnerability world. Everything that needs to be patched will not have a high CVSS score, or even a low score for that matter. We can choose to follow one or more of the above frameworks, such as MITRE ATT&CK, CISA KEV, and EPSS. Following these individually can be tricky, and you’d miss pieces of the larger picture. If you only patched the CISA KEV, you’d miss out on select attacker techniques that don’t deal with vulnerabilities and CVEs. A blended approach isn’t a bad idea, but solely relying on guidance external to your organization is the equivalent of just shaking a Magic 8 Ball and using that as the guidance to patch.

What matters most when it comes to patching is the impact on your organization. My best advice is to identify the most critical parts of your business, tie that back to systems and applications, patch those first, and patch as much as you can on those systems.

Conclusion

Too often, I hear folks dismissing vulnerabilities that could be devastating for various reasons, such as “No one is attacking those vulnerabilities today,” “I am not the target of nation-state-level attacks,” and “An attacker would have to already be on the system.” None of these things matter when a clever group of attackers is determined to be successful. They will target every weakness in your attack surface: hardware, firmware, and software, from bare metal all the way to the cloud. Pre-operating system attacks could render a system permanently damaged or inoperable, such as if an attacker were to gain access to the baseboard management controller (BMC) and cause an infinite reboot loop. Through low-level firmware attacks, malicious actors can permanently damage the hardware. Attackers can utilize the Unified Extensible Firmware Interface (UEFI) to bypass OS protections, be persistent on the system (think of ransomware that just won’t go away), and allow attackers to be stealthy. At this point, every vulnerability is now available for exploit.

Remediating vulnerabilities is a complex process, and several factors go into the decision as to whether or not to apply a patch, or thousands of patches to thousands of systems. As complex as this task may be, it’s something we must continue to improve upon, or attackers will greatly benefit. Oh, and put down the Magic 8 Ball, please.

About the Author

Principal Security Evangelist, Eclypsium

Paul Asadoorian is the principal security evangelist at Eclypsium, focused on supply chain security awareness. Paul’s passion for security extends back many years, to the WRT54G hacking days and reverse-engineering firmware on IoT devices for fun. He co-authored the book WRTG54G Ultimate Hacking in 2007, which fueled the firmware hacking fire even more. Asadoorian has worked in technology and information security for more than 20 years, holding various security and engineering roles at a lottery company, university, ISP, independent penetration tester, and security product companies such as Tenable. In 2005, he founded Security Weekly, a weekly podcast dedicated to hacking and information security. Asadoorian is still the host of one of the longest-running security podcasts, Paul’s Security Weekly. He enjoys coding in Python, telling everyone he uses Linux as his daily driver, poking at the supply chain, and reading about UEFI and other firmware-related technical topics.