Let’s face it: Vulnerability management is not what it used to be a decade ago. Actually, it is not what it used to be a couple of years ago. Vulnerability management is one of those ever-evolving processes. Whether it is because of compliance mandates, board demands, an overall desire to reduce risk, all of these objectives or none, almost every organization is taking a new look at their vulnerability management program. Although too often, they may only focus on scanning for existing vulnerabilities, which could yield a long list of issues without context or priority.

Please do not misinterpret that statement. Scanning is an important part of any vulnerability management program, and not just for traditional infrastructure. Cloud environments should also undergo scanning and vulnerabilities should be remediated regularly. Scanning, however, should walk down the aisle in holy matrimony with vulnerability ranking, ensuring teams are patching the most impactful issues first.

According to IBM X-Force Red’s vulnerability scanning data, about 1.7 million vulnerabilities are reported by scanners in each client’s environment. Out of those 1.7 million, 16 percent have associated public exploits. That means an attacker could exploit up to 272,000 of those vulnerabilities at any moment in time. And, as you have probably heard ad nauseam, it only takes the exploitation of one vulnerability for an attacker to compromise an entire organization.

How can security teams quickly find which of those vulnerabilities have associated public exploits? And out of that pool of vulnerabilities, how do they know which ones to fix first?

The screenshot below, which comes from an initial scan for vulnerabilities, shows the challenge. Even if you cannot see the specific Common Vulnerabilities and Exposures (CVE) numbers, you can still see the list is endless. How can anyone decipher what the data means and which actions to take next?

Figure 1: Vulnerability scan results prior to ranking of the issues detected in the scan (Source: IBM X-Force Red)

Scan, Then Rank!

Hence, the importance of ranking. Without ranking, that possible list of 1.7 million vulnerabilities produced by one scan is just a giant heap of CVEs. The findings are not actionable. Instead of giving the report’s recipients answers, the sheer amount of issues listed merely stresses them out, all while the most dangerous vulnerabilities may be left to stick around even longer, exposing sensitive assets to a motivated attacker.

You may be thinking, “I do rank. I prioritize our scan findings based on the assigned CVSS scores.” As I described in more detail in a prior blog post, ranking vulnerabilities based on the Common Vulnerability Scoring System (CVSS) alone is not enough, because the CVSS was never meant to be used on its own for prioritization. To briefly recap, the CVSS provides a technical score for the severity of a vulnerability, however, it lacks contextual information that is specific to each organization’s environment. In other words, it does not include key risk factors such as the value of the exposed asset to the organization or if the vulnerability can be exploited by attackers.

If ranking — based on those kinds of risk factors — is not subsequent to scanning, security leaders may find themselves wasting time on minimal risk vulnerabilities, false positives, stewing, not knowing where to start with remediation, or manually trying to figure out which vulnerabilities matter most.

Wed Scanning and Ranking in Your Environment

As you most likely know from the countless number of vendor pitches in your email inbox, different security companies have their own “secret sauces” designed to help manage vulnerabilities. But if you are not ready to purchase yet another solution, the best first step for your vulnerability management program is to understand your assets.

Which assets matter most to your organization, and what kind of data do they touch? Once you identify those basics, you can narrow the scope of your scan to only those assets. That may make it a bit easier to identify vulnerabilities exposing the most critical assets — those that, if compromised, may cause the most pain.

Rank Like an Attacker

X-Force Red, IBM Security’s team of hackers, believes in ranking through the eyes of an attacker. After every scan — whether it’s on a cloud or traditional IT environment, internet of things (IoT) or web application, host, container, or anything and everything else — the findings must be inputted into a ranking engine that factors in attacker-minded information. For example, can the vulnerability be readily exploited? Is a public exploit available? Oftentimes, many vulnerabilities on the list are not being exploited by attackers, which diminishes their immediate viability.

Scanners provide an enormous amount of data, and ranking enriches that data so it is actionable for reducing risk. The two should forever live in symbiosis.

To learn more about X-Force Red’s vulnerability ranking, check out how a security leader reduced the number of critical vulnerabilities in his environment by 60 percent in just four months.

More from Software Vulnerabilities

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…