Am I Really Vulnerable? Gut-Checking Bug Risk

Whenever a new software vulnerability hits the headlines, the tendency among cybersecurity pros, security analysts and teams is to think the worst; that the bug could have a big impact on organizations and even lead to a breach or ransomware attack that impacts the company.

These days, who could blame them for thinking that way? Ransomware attacks have become seemingly commonplace and in the past few years, the most notable attacks have affected thousands of vulnerable organizations and users.

In December, for example, security researchers found a zero-day vulnerability that involved arbitrary code execution in Log4j, a Java-based logging utility that is part of the open source Apache Logging Services. Just last week, researchers discovered the Spring4Shell vulnerability in the Spring Core enterprise framework. Though not as widespread as Log4j, it highlights the increased frequency and ubiquity of these kinds of flaws.

Experts called the Log4j vulnerability one of the biggest and most critical discovered in recent years, and the incident has opened up the world’s eyes to the reality that major vulnerabilities exist in open source code. New software vulnerabilities are constantly emerging, and one of the biggest challenges with vulnerabilities today is the fact that there are so many of them.

A cybersecurity advisory on the top routinely exploited vulnerabilities, jointly released by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), Australian Cyber Security Centre, United Kingdom’s National Cyber Security Centre and U.S. FBI in July 2021, noted that, in 2020, bad actors readily exploited recently disclosed vulnerabilities to compromise unpatched systems.

The number of recorded vulnerabilities in 2021 was just over 20,000, according to the National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD). The total was up nearly 10% from the previous year, and the most ever recorded for any year since the database launched.

Cutting Through the Vulnerability Noise

NVD rated a large majority of recent vulnerabilities as being medium or low severity, which illustrates the point that not all vulnerabilities need to be treated with the same urgency. The fact is, not all vulnerabilities have the same impact. Some can be harmless while others present a significant risk because of how and why they are exploited.

Organizations need a way to identify the most serious software bugs before bad actors can take advantage of them. The key to successful vulnerability management is to prioritize those flaws that need to be fixed immediately while relegating less risky ones to the back burner. And, in fact, some vulnerabilities pose no risk at all and require no patching—so they can be ignored. Knowing what and when to patch means security teams can ensure they are laser-focused on the software flaws that really matter, and work on mitigating them as quickly as possible.

Vulnerable? Strategies for Smart Patching

Validating the severity of vulnerabilities and prioritizing which should be addressed first are key components of a smart vulnerability risk management strategy. To help with this, organizations need to apply some sort of risk and severity logic.

First, you need to be able to identify them. More organizations are looking to the Software Bill of Materials (SBOM) for visibility into vulnerabilities. An SBOM is a formal record containing the details and supply chain relationships of all the various components used in creating a software product.

Because software providers often build products by assembling open source and commercial software components, an SBOM enumerates these components. They can help organizations identify and avoid vulnerabilities in reused components in their own developed software as well as software purchased from outside the organization.

With the visibility the SBOM offers, vulnerability scanners can work in tandem to discover all potential vulnerabilities in the environment and provide a clear list that can be matched to Common Vulnerability Scoring System (CVSS) scores, a free and open industry standard for assessing the severity of security vulnerabilities. Teams use CVSS to calculate the severity of vulnerabilities they or others discover, or prioritize the remediation of vulnerabilities they’ve discovered in their software.

But even with this list, security teams are left to wade through the mountains of data and must figure out what to do with all the discovered vulnerabilities. In most cases, the workload ends up being too large for the team. That’s where prioritization comes in—and why it is critical to have the tools to identify which vulnerabilities are actually exploitable. The mere presence of the vulnerability does not mean it is a threat to your environment. Teams should seek ways to reveal which vulnerabilities within the environment are loaded to memory and therefore exploitable, and which are not loaded to memory and pose no risk.

Once vulnerabilities are prioritized, teams can take steps to fix vulnerabilities, such as deploying a sustainable patch management program or process. Patch management that focuses on only exploitable vulnerabilities frees teams from the burden of a patch backlog.

Prioritizing Leads to Time Saved And Better Security

Security staff and budgets are tight and how time is spent is critical. The ability to find, assess, and mitigate vulnerabilities has never been more important, given the level of risk organizations face today and the importance of software in driving digital business. Organizations need to develop a strong vulnerability management strategy that incorporates prioritizing vulnerabilities and using the available tools and processes as effectively as possible.