Vulnerability Management Goes Much Deeper Than Patching

Mon, 08 Apr 2024 00:00:00 +0000

In 2016, the Large Hadron Collider in Switzerland fell prey to a vicious and devastating attack. The bad actor exploited a vulnerability that researchers at CERN had never considered–small furry animals.

Yes, the Large Hadron Collider, the pinnacle of scientific achievement, was shut down by a weasel. The cunning critter infiltrated their systems (crawled into one of their tubes) and executed a targeted attack (chewed up a power cord). Research into the Higgs-Boson was delayed for weeks while they got systems back online.

Which was exactly what the weasel wanted. [Source]

Now, in 2024, CERN is more concerned about an increasingly common (and far less adorable) style of attack: ransomware. In a January blog post, their computer security team wrote that “the base question is not ‘if’ but ‘when’ CERN will be subject to a ransomware attack.”

While CERN knows (better than most) that it’s impossible to protect against every threat that weasels its way into your systems, their plan to guard against ransomware gangs hinges on good old fashioned vulnerability management tactics.

And they’re not alone. The concept of vulnerability management has been around for a while, but in the last few years it’s been steadily gaining momentum and interest, in part due to tougher laws and compliance standards.

But for this wave of investment in vulnerability management to actually translate to better security, it has to go deeper than check-box compliance. And that starts with establishing a shared definition of what vulnerability management actually means.

What Is Vulnerability Management?

Vulnerability management is the continuous process of analyzing systems for flaws that might make them vulnerable to attack, and then managing those vulnerabilities.

Vulnerability management vs risk management
Vulnerability management is a segment of risk management (to the point that many of our sources use the terms interchangeably). But the general agreement is that vulnerability management is more specifically focused on the IT and cybersecurity risks posed to an organization, while risk management includes physical and other categories of threat.

But forgive us while we open a taxonomical can of worms. Because the word “vulnerability” is used to mean a few things when it comes to computing.

Somebody call Brené Brown.

The National Institute of Standards and Technology (NIST) defines Vulnerability as: “Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.”

“Vulnerability,” by this definition, would encompass an intimidating number of weaknesses that attackers could exploit. Unmanaged devices, shadow IT, employees’ unpatched Minecraft mods, end of life software…you get the idea. All of these things, and more, could let bad actors compromise your systems.

But when people use the word in the context of a “vulnerability database,” like the “Common Vulnerabilities and Exposures” (CVE) program, they’re talking about something very specific.

In their case, they’re referring to what NIST would instead define as a Software Vulnerability: “A security flaw, glitch, or weakness found in software code that could be exploited by an attacker (threat source).”

Software vulnerabilities generally fall under the umbrella of patch management.

Patch management is the process of applying updates that vendors release to close up code flaws that they’ve found in their software. It’s sometimes considered to be a subset (note, not the entirety) of vulnerability management.

For the purposes of this article, when we’re referring to the patchable style of vulnerability, we’ll use the term “software vulnerability.” But when we talk about vulnerability on the whole, we’ll be taking a broader view on the wide range of issues that can let bad actors breach systems.

It’s important to make this distinction; the CVE, and the practice of vulnerability management, started in the 90s. Back then, there weren’t nearly as many remote workers to account for, and “cloud” was just a word for those puffy things in the sky. IT teams could manually patch most vulnerabilities as they trickled in.

But since then, the number of software vulnerabilities that the CVE lists per year has increased by 3100%. Meanwhile, bad actors have tons of new avenues (like phishing, sim-swapping, etc.) to compromise systems. When you’re looking at a modern business with hundreds or even thousands of applications and endpoints, vulnerabilities could pop up just about anywhere.

The way we work has changed, and as IT and security teams have struggled to keep up with the pace of patching, they’ve struggled even more to broaden their scope and account for systemic vulnerabilities.

The NIST framework

In an attempt to help bring some order to the chaos, 2014 saw the introduction of the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF). It sought to lay out successful techniques to help owners and providers of critical infrastructure “identify, assess, and manage cyber risk.”

“Critical infrastructure,” like “vulnerability,” is a pretty broad term. Hospitals and manufacturers, for example, work at different scales and manage different types of data; the framework needed to be able to serve a variety of tech and organizational needs.

The NIST framework wasn’t designed to be an instruction manual. Instead, it’s meant to provide a flexible structure for cybersecurity programs, with the understanding that different companies and services have different needs and demands to keep data secure.

It’s a classic “overused movie quote” situation. [Source]

After some serious deliberating, NIST arrived at a framework with 5 core functions. In the briefest summary possible, they were:

Identify: Understand your company’s assets and their vulnerabilities.

Protect: Secure those assets and lower their risk from attack.

Detect: Have systems in place to alert your teams to signs of compromise.

Respond: Have systems in place to contain attacks when they happen.

Recover: Have a way to recover data and systems that are lost or compromised.

The NIST framework is a loose–but reasonable–way to better understand the objectives that need to happen for your vulnerability management program to work.

Vulnerability Management For Compliance

In a 2021 survey of cybersecurity leaders, only 33% said that vulnerability management was “very important” to their organization. That’s an especially troubling statistic, since 77% also said that an IT security vulnerability had impacted their business that year.

However, in a similar 2023 survey, 50% of respondents said that their organization’s vulnerability management program had support from leadership to “a large/great extent.”

The problems of vulnerability management have been mounting for decades, so why is it suddenly starting to get the attention it deserves?

While we’d love to say it’s because CEOs recognized the rising costs and frequency of cyberattacks, it’s only partially that. The other force driving companies to step up security is compliance.

Uncle Sam wants companies to reduce vulnerabilities. And he wants it done pretty sharpish. The Biden administration has made its National Cybersecurity Strategy a major priority, and this push from the top has driven more than a few recent updates to vulnerability management compliance requirements.

Here’s a non-comprehensive sampling of some recent compliance changes:

Payment Card Industry Data Security Standard (PCI DSS)

Long ago, in the year 2004, five major credit card companies (Visa, Mastercard, Discover, JCB, and American Express) combined forces. Why? They were sick of losing money to credit card fraud.

They came up with security compliance standards that they would apply to any company that processed or stored consumer credit card data.

The first version, among other guidelines, mandated that compliant companies “maintain a vulnerability management program” (the requirements vary depending on the company’s scale).

The most recent update came in March, 2022, in the form of version 4.0. This includes several updates to their vulnerability management guidelines:

Companies now need to explicitly state how frequently they re-evaluate system components that were previously defined as “not at risk for malware.”

The frequency of malware scans must now be explained in the company’s risk analysis guidelines.

Anti-malware solutions must now include the ability to scan or analyze when removable electronics are connected.

Processes or mechanisms must now be in place to guard against phishing attacks.

These, and other changes, are becoming assessment requirements on March 31, 2025.

ISO 27001 and 27002

ISO 27001 comes to us from the International Organization for Standardization (ISO). Despite their confusing abbreviation system, ISO standards are a source of truth for various international industries.

ISO 27001 and 27002 were made to create a standard around information security management systems (ISMS). ISO 27001 establishes the requirements, and ISO 27002 establishes the objectives and practices to achieve those requirements.

They were first published in 2005, and the latest update to the standards came in 2022. A lot of these updates regard ISO changing and condensing their terminology around their old requirements. But there are some notable new additions. As a sample:

Organizations need to maintain a level of threat intelligence around current and future cyberattacks.

Companies should maintain a policy that deletes user, customer, and employee data when it is no longer needed.

A series of data masking techniques are advised to protect personally identifiable information.

Companies need to implement technical measures to prevent data leakage.

After April 30, 2024, any company that wants to become ISO 27001/27002 compliant will need to meet the updated guidelines. And companies that were already compliant with the previous version will need to update to the new standards by October 31, 2025.

Security and Exchange Commision (SEC) Regulation

In July of 2023, the SEC started requiring that registrants annually report on their cybersecurity risk management processes.

This includes things like:

Processes for assessing and managing cybersecurity vulnerabilities.

Describing current or likely impacts from vulnerabilities.

Describing the oversight the company’s board of directors have over vulnerabilities.

Describing the role management plays in assessing and managing vulnerabilities.

These disclosures are now required in reports at the end of every fiscal year.

NIST

Remember NIST? In February of 2024, they updated their Cybersecurity Framework to version 2.0. The most major change was to add a new function:

Govern: Communicate your vulnerability management strategy with your team.

This function is all to do with organizations making sure that their cybersecurity risk management strategy, and its expectations and goals, are being established, communicated, and monitored effectively.

Later in the document, NIST more explicitly states that this function’s success falls to executives. They even specifically place this function in the center of their new graphics, because “it informs how an organization will implement the other five Functions.”

While NIST isn’t a mandated compliance guideline for any company, it is referenced in many other compliance guidelines. The NIST functions are a gold standard for vulnerability management. And a keen reader will notice that “strategic communication” is becoming a bit of a must-have in meeting standards.

The trouble with NIST, and similar guidelines, is that they establish what needs to be done, without much guidance on how to do it.

Beyond check-box compliance?

Compliance standards are certainly helpful in getting companies to prioritize vulnerability management. But in a 2020 interview, Charles Henderson, head of IBM’s cybersecurity services team, summarized the problem with compliance being the primary driver of change: “Organizations are focused on meeting compliance requirements with vulnerability management rather than actually eliminating the vulnerabilities.”

Companies could afford to just check the boxes when there were fewer consequences for getting breached. But new laws, like CPRA, come with financial penalties for negligence. Doing due diligence to reduce breaches requires more thorough methods to manage vulnerabilities.

Elements of Vulnerability Management

The process of finding and remediating vulnerabilities is typically called “the vulnerability management lifecycle.” It’s worth researching the cycle that will best fit your company, but a typical version, as described by IBM and Crowdstrike, would be something like:

1. Assess your assets and their vulnerabilities.

2. Prioritize vulnerabilities.

3. Resolve vulnerabilities.

4. Rescan and verify that they’re resolved.

5. Improve your systems and their defenses.

Anyone in IT or security can tell you that each stage alone is just the tip of a pretty humongous iceberg–and executives might not get why you’re tightening bolts on an “unsinkable” ship.

Still waiting on that patch rollout. [Source]

So the real first step in vulnerability management is getting buy-in from leadership, which you can hopefully do by sending them a steady stream of data breach horror stories.

Assess your assets and their vulnerabilities

Once you have the buy-in you need, the first official step of vulnerability management is to assess your assets and their vulnerabilities.

Software vulnerability scanning software is seeing a lot of growth in response to all of the recent changes. These programs scan your company’s assets and compare them against databases–like the aforementioned CVE–of known software vulnerabilities.

Overall, this software is solid. There may be issues with scanners’ databases being out of date or the like, but most of them do the job they set out to do–so long as your team knows what they need to scan. But what about the devices and applications you don’t know about?

Challenge:

Asset management is one of the most crucial steps in understanding your cybersecurity risks. That means getting an inventory of your assets. All of them.

Companies struggle with this. Our own recent study found that 47% of companies still let employees access company resources from unmanaged devices. An earlier report we conducted found that only 46% of companies stop employees from downloading sensitive data onto personal devices–and it’s rare that they have any visibility or control over that data once it’s been downloaded.

If there’s a known exploit on an application that accesses sensitive data, you desperately need to make sure it’s getting patched. But you can’t do that if you don’t know it’s there.

And when you consider that employees might be using multiple personal devices to access your systems, and that those devices might have multiple vulnerable applications lurking on them, then you start to see the “trouble with tribbles” issue of unmanaged assets.

To quote Nils Baris, “Captain Kirk, I consider your security measures a disgrace.” [Source]

All of those tribbles–I mean, devices–aren’t subject to vulnerability scans, or to any data oversight. Your team can’t protect what they can’t see.

Prioritize vulnerabilities

Getting a complete inventory of your company’s assets is hard enough, but prioritizing which vulnerabilities need to be fixed is an even tougher challenge.

For starters, the number of new listed CVEs grows every year, even while teams are still struggling to patch their backlog from previous years. Teams are often swamped with a very long list of software vulnerabilities to patch and update.

But frankly…a lot of those software vulnerabilities aren’t a huge deal. In fact, the vast majority of them don’t pose any immediate threat. In 2023, over 25,228 (give or take) CVEs were listed, but DarkReading found that “7,786 vulnerabilities had potential exploits, but just 159 had weaponized exploit code, and only 93 were exploited by malware.”

It’s like how your front door is vulnerable to being knocked open by a rhinoceros. It’s technically true, but you’d still focus on a security system that could stop the much more likely human attacker, rather than getting rhino-proof armor. Most teams prioritize patch updates according to the ones that are most likely to be exploited.

Challenge:

But this is where it’s important to again differentiate vulnerability management from the much narrower concept of patch management. Even if, somehow, your team were able to get every piece of software on every device patched, only 5% of attacks in 2023 actually worked by exploiting software vulnerabilities.

If teams were to prioritize all vulnerabilities based on how likely they are to be exploited, they’d have to take a much broader view on their organization. The overwhelming majority of breaches stem from things like phishing, stolen credentials, or other human elements.

That’s not to say that timely updates aren’t important, but that they wind up prioritized as a sort of easily quantifiable smokescreen for vulnerability management.

Resolve vulnerabilities

Next, teams are meant to resolve their list of vulnerabilities. That might mean fixing them, updating software, or just letting them be.

Challenge:

The trouble we face is that problems with the human element are a lot trickier to resolve at an organizational level.

Patch management, as overwhelming as it can become, is at least straightforward. Meanwhile, more abstract vulnerabilities like shoddy user verification or lackluster security training abound.

Similarly, even as security companies warn about bad actors social engineering their way to super-administrator credentials, leading to devastating ransomware attacks, Capterra reported in 2023 that 43% of companies let employees access far more data than they need for their job.

But finding and resolving these more abstract vulnerabilities requires more than a patch rollout.

Verify that vulnerabilities are resolved

The next stage of the lifecycle is to verify that the fix has repaired the vulnerability. For patching purposes, that just means running another scan.

Challenge:

More abstract systematic changes, however, rarely lead to a satisfying checkbox.

Measuring how successful cybersecurity awareness programs are, for instance, is a constant moving target and requires frequent adjustments. Any other procedural change is likely to involve similar long-term effort to verify that methods are working.

Improve systems

The final stage of the lifecycle is meant to be focused around improving company systems and their resilience to vulnerabilities.

Challenge:

According to a 2023 report, only 34% of IT and security professionals said they felt confident that their VM program had eliminated the gaps that can be exploited by attackers.

As one of the anonymous respondents put it, “Some vulnerabilities require a lot more than just patching and updating. These ones are harder to get support from management.”

Patchable vulnerabilities receive an outsized focus. And by now, it’s pretty clear why. They’re just more straightforward.

But when IT teams are stuck with all of their focus placed on playing the single-vulnerability patch management game, they get in a never-ending cycle of playing catch up. And much more vital security issues continue to not receive the attention or resources that they need.

Improving Vulnerability Management With Zero Trust

Now that we’ve established that (if you’re doing it right) vulnerability management is really hard, let’s look at some practical ways that companies can manage its challenges.

Fair warning that we’ll be referencing our own product (Kolide Device Trust) fairly heavily in this section. But we could never pretend that one tool (even our super awesome one) is capable of fixing all the problems plaguing vulnerability management.

Still, Zero Trust (and Kolide) can genuinely help companies refocus their efforts and reduce their attack surface. In fact, around 2019, Forrester estimated that Zero Trust Architecture could reduce an organization’s risk exposure by 37% or more. And the logic behind that statistic is sound.

Use device trust to manage assets

Teams need to know what devices are accessing company data and whether those devices are secure. That’s the basic principle behind device trust.

Kolide Device Trust ensures that only known and secure devices can access company systems. That means no unmanaged mobile devices or random BYOD will be able to bring unseen vulnerabilities into your systems.

Strengthen authentication to resist phishing

Despite years of investments in SSO and MFA, some of the most nightmare scenario attacks still happen as a result of weak authentication security–in particular, compromised and phished employee credentials.

MFA is useful, but it’s not foolproof. Keeping an eye out for compromised passwords is also a vitally important step to keep IDs secure, but bad actors can work fast, and there’s a possibility they’ll break into systems before the password breach gets reported.

The solution to this problem is to move beyond authentication factors that can be phished. Passkeys, which are gradually permeating the app ecosystem, are a promising substitute for passwords.

Likewise, Kolide Device Trust authenticates via a certificate on the device itself. That means that even if a user’s ID gets compromised, a bad actor still can’t log in from a device that isn’t verified. Unless someone has your password and computer, they can’t get in.

Use device trust for patch management

A company we work with ran a vulnerability scan for compliance purposes, and found many unpatched software vulnerabilities on their systems. But when they looked at the advised remediations to fix those vulnerabilities, they realized that 60% of them could be fixed by simply requiring users to update their Mac OS and internet browsers.

Kolide requires users to apply these updates themselves, and will not let them authenticate until their device is compliant. This eliminates one of the main bottlenecks to effective patch management: the strain on IT of remotely forcing patches and dealing with all the support tickets that come along with it.

Educate users

It’s a common saying in security that “humans are your biggest vulnerability.” 1Password (our parent company) ran a very recent survey of security pros. A third of respondents listed human elements like phishing and human error in the top three threats to their organizations.

Regular and consistent training has been shown to markedly improve workers’ resistance to things like phishing emails, but a third of companies don’t offer cybersecurity training to their remote workers.

Keeping users educated, and enforcing good security habits, lets them be an ally rather than a hurdle to your vulnerability management program.

Vulnerability Management Is a Journey, Not a Destination

For too long, vulnerability management has been stuck in a reactive mode. CVEs come in, then patches go out. Data gets breached, then systems get strengthened. Guidelines get updated, then boxes get checked.

When your captain is telling you to bail water out of a rowboat that keeps springing new leaks, it’s hard to think about what a better boat might look like. But it starts by moving to a proactive, rather than a reactive mindset.

True vulnerability management needs a lot of communication, broad-reaching strategy, and support. It’s going to fall to your people–at every level–to make that happen.

Want more info on how Kolide Device Trust works? Watch our on-demand demo.