New Google vulnerability: Learn about zero-day CVE-2022-3075 in Chorme web browser  | Fix now >> 

The CyberRisk Summit on-demand: Watch the latest #CRS anytime, anywhere | Watch now  >>

New report: Mapping MITRE ATT&CK framework to CVEs |  Read more  >>

How-to guides

The most common CVEs (and how to fix them)

Learn the most common types of CVEs, how they occur, what they mean for your business, and how to fix them.

Mike Parkin | April 25, 2022

Every year, MITRE adds thousands of new entries to their Common Vulnerabilities and Exposures (CVE) list. With only a few exceptions, the number of vulnerabilities posted to the list has gone up almost every year, with over four thousand posted already in 2022.  That’s not to say that all CVEs are going to lead to a compromise.  In fact, most of the vulnerabilities that get a CVE entry are never exploited in the wild. The problem is the ones that are exploited. While the raw number is a lot lower than the total number of vulnerabilities, the impact can be dramatically higher. 

Fortunately, not every exploitable vulnerability turns into the kind of event we saw Log4J or the recent Exchange Server issues. 

One of the challenges Security Operations teams face is prioritizing the constant stream of CVEs and coordinating with their counterparts in IT. Those IT folks are usually the ones tasked with deploying the patches when the vendor makes them available. Or at least altering the configuration, turning off unused features, or applying whatever other mitigations are available that don’t fall to the SecOps team. 

Addressing that prioritization issue is where risk management tools like Vulcan Cyber® come into the picture. They help an organization bridge the gaps between SecOps and IT, and other stakeholders, so the right people are getting the right information to get the right fixes in place. And by “right fix” we mean the ones that deliver the most benefit for the organization. 

This risk management capability helps a lot with new vulnerabilities as they make the CVE list, but it still depends on the vendors making the patches available or publishing some kind of workaround the organization can deploy to help mitigate the problem. This is not always possible, at least initially, as it can still take some time for the fix to become public.  That’s even counting cases where there was responsible disclosure, and it wasn’t the sudden exploitation of a zero-day coming out of nowhere. 

What would be ideal is a solution that lets an organization deal with new CVEs regardless of the specific details. Unfortunately, there’s really no silver bullet for these things. Each vulnerability is either a new issue, or a new take on an old one, which doesn’t lend itself to a single all-in-one solution that can cover each new problem. 

There are still some things we can do that can help with broad categories of CVEs. Honestly, these are things we should be doing as best practices in the first place. But they warrant repeating, at length, because there are far too many breaches that happen because an organization wasn’t following industry best practices, or the best-configuration recommendations from the vendor. 

CVEs

Configuration issues

A fair number of CVE entries cover vulnerabilities that are only relevant for applications or systems that use a specific, often unusual, configuration. In some cases, that unusual configuration may be required to meet a specific business need. If that’s the case, then make sure these are reviewed regularly. Which, again, is something we should be doing already. 

The bottom line is that if a vendor has a recommended, or hardened, or otherwise secure configuration, it’s best to follow it unless there are specific business reasons to do otherwise. 

Access control

Another common thread that shows up in a lot of CVE entries are either privilege escalation or local exploits that require some kind of existing access. In either case, restricting access to potentially vulnerable systems is a step towards preventing any attack that relies on access to execute. How that access is limited depends on the system, obviously. With servers, the first step is limiting access to only include people who have a genuine need to be there. It may be tempting to include everyone who asks. But the reality is the fewer people who can get onto the system, the fewer opportunities there are for someone to execute an exploit. 

Linux includes a range of tools that can help lock down a system, and there is no reason not to use them – other than a bit of added complexity. The benefits usually outweigh the costs. 

Servers aren’t the only targets of access exploitation, since workstations can be used to launch attacks against servers and can be inviting targets in their own right. Which leads to implementing multi-factor authentication wherever it’s practical. 

While users sometimes find MFA annoying, the benefits of that second step far outweigh the minor inconvenience. Numerous breaches over the years originated with compromised credentials, and multi-factor authentication can reduce the risk of an intrusion even if credentials are somehow revealed. Keeping attackers out not only protects an organization’s IP, it gives threat actors fewer opportunities to deploy exploits. And that’s what we’re trying to address here in general. 

Perimeter controls

There is a common theme in cybersecurity that the perimeter is effectively dead, and with the shift to remote work over Covid it’s easy to see why. Most of the workforce is outside the perimeter working from home. While that’s starting to change back to in-office in early 2022, chances are people will remain outside the office as long as they can. Though to be fair, Covid didn’t change things for the applications that still live in premises in the datacenter. Though the wholesale shift to cloud computing has had an effect. 

But the perimeter isn’t dead, and the servers and systems that remain in the Enterprise environment are still the subject of a large number of CVEs. And even with many applications in the cloud, some of them are the subject of CVEs as well. Which means the perimeter is still a useful layer of protection for both systems and applications. 

Firewalls, web firewalls, web gateways, and the like, are still important. While it’s impossible to predict what specific vulnerabilities will come up next and become CVE entries, configuring the perimeter to allow only the minimum necessary access can help keep attackers from reaching vulnerable systems. Likewise, sanitizing entries in web applications and providing the workforce with secure gateways can prevent application compromise in either direction. 

No silver bullet for common CVEs

There is no “one size fits all” solution to address every possible new CVE. There is no silver bullet.  But there are the basic best practices we should all be utilizing to keep our environments safe. So when the latest CVE drops, we may have some breathing room while we analyze the risk and decide how to prioritize the patches. 

Cyber risk is something all organizations need to face. And siloed teams, muddy data, and slow, inefficient processes represent a golden opportunity for threat actors. Communication and collaboration between teams are vital, as is full visibility of vulnerability data, all in one place. Vulcan Cyber elevates your cyber risk management into intuitive, efficient processes that can be realized easily across all teams to efficiently reduce risk and own cyber hygiene. Get a demo today.