When your organization is facing an active security risk, there’s a good chance plenty of others are, too – especially if it’s a vulnerability in a widely used software app or platform. So why not join forces with them as a first step toward mitigating those threats?
That’s the general idea behind CVE, or Common Vulnerabilities and Exposures. In the words of its parent organization, “CVE is a list of entries – each containing an identification number, a description, and at least one public reference – for publicly known cybersecurity vulnerabilities.”
It’s worth noting that “CVE” is both the official name of the overall list and the term that IT pros commonly use to refer to a single specific issue on that list.
How do vulnerabilities impact my organization?
The potential fallout from any security threat is usually more severe when individuals or organizations are unaware that the risk even exists. It’s hard to solve invisible problems, and known vulnerabilities that aren’t widely disclosed can remain just that: invisible. CVE is effectively an information-sharing system for publicizing known security vulnerabilities to help address that fundamental issue.
“There’s a reason the CVE system exists: Transparent, centralized disclosure makes everyone safer,” says Jerry Gamblin, principal security engineer at Kenna Security.
This is a good thing, but like with most security tactics, it’s not foolproof. To make the most of CVE in your company, you’ll need to understand its purpose and limits – and help others do the same.
Given that, we’ll cover some tips from security experts on the best ways to make use of CVE. But first, let’s get another plain-terms definition to help you help others in the organization understand CVE, including the taxonomy it uses for labeling known issues. We’ll also cover a comparison that might help when explaining CVE to people in non-technical roles.
What is CVE?
“CVEs are a way of classifying and categorizing issues with digital software and hardware that allows people from around the world to refer to such problems in one cohesive and all-around globally accepted language,” explains Benjamin Preminger, senior cyber threat intelligence specialist at Sixgill. “It takes the form of CVE-Year-ID, [such as] CVE-2019-0708 – the infamous BlueKeep CVE.” The ID number
Gamblin from Kenna uses an analogy to explain CVEs that librarians will appreciate, as will anyone who remembers getting schooled in the finer points of the Dewey Decimal System in their younger years.
“If you were born in the 1980s like me, the simplest way to understand a CVE is to think back to your visits to the elementary school library. CVEs are almost exactly like the card catalog entries and provide an easy way to reference known vulnerabilities,” Gamblin says. “Just like a card catalog, CVEs provide basic information about the vulnerability and tell you where you can find more information.”
For your technical team members, Gamblin also points to the CVE Automation Working Group’s GitHub repository, which includes all of the data points provided for CVEs in the most commonly used JSON schema.
StackRox director of product Hillary Benson notes that CVEs cover both open source and proprietary software. She also adds a different definition to the mix: “[A CVE is] the beginning of a migraine.”
3 ways CVEs can be helpful
That’s not to naysay CVEs, but to note that once one is published, the real work of addressing the underlying issue begins. With that in mind, let’s consider some tips that help not only explain CVEs in your company but make them more valuable to your overall security practices.
1. You understand CVEs limitations
Don’t expect CVEs to be (or do) anything more than they are, which is a list of known issues and information about them. This can be a very useful component of a security strategy, a clearinghouse of sorts that helps warn you of potential issues in the systems your company relies on – and that helps you catalyze industry responses to those issues. Just keep in mind that CVE is neither a catch-all nor a cure-all.
“CVEs only provide basic information about a vulnerability,” Gamblin says. “The CVE process is not equipped to handle every vulnerability in every product, as it would quickly overwhelm security teams within an organization.”
CVE isn’t intended as a comprehensive list of every security threat in the landscape, and the CVE system itself will not magically mitigate every risk. This doesn’t diminish its value; it just requires a reality check. Consider it a tool for keeping tabs on the visible part of the threat landscape rather than every risk your organization might need to consider.
“Many people don’t realize – or choose not to focus on the fact – that CVEs do not fully represent all the ways in which your software may be vulnerable. They only represent issues which are both known and disclosed.,” Benson says. ”Plenty of security programs begin and end with vulnerability scanning. However, unknown and known-but-unreported vulnerabilities represent serious security risks that have to be addressed as part of a broader, in-depth approach to security. CVEs are really just the beginning.”
2. You use CVEs to bridge teams
Security vulnerabilities, in general, can be a source of stress, Benson notes, whether because of a five-alarm-fire approach that requires all hands on deck to remediate high-severity risks, or a boil-the-ocean strategy that tries to remediate every issue rather than focusing on high-risk, high-impact vulnerabilities.
One of the values of the CVE system is that it not only shares important security information but it does so in a universal language. That can be a significant bridge-builder that enables teams to better coordinate and work together. Make the most of that, especially in organizations where teams are still operating with goals that aren’t aligned, or in full-blown silos.
“For better or worse, CVEs are a well-understood artifact of information security across development, operations, and security teams,” Benson says. “Any time teams with competing business priorities can speak the same language about something that usually separates them, it’s an opportunity to solve real problems. CVEs do form the basis for a common security language. They are easy to understand, to grasp onto. The challenge comes in capitalizing on that, which is where prioritization becomes important.”
3. You have a means for prioritizing CVEs
Just keeping up with CVE – which has limits by design – could be a Herculean chore. That shouldn’t be the goal.
“Every year, thousands of CVEs are published, and it is virtually impossible to effectively know each and every one,” Sixgill’s Preminger says. “As such, some level of filtering and focus is needed.”
Benson notes that it’s not uncommon for companies – especially larger organizations – to face hundreds, if not thousands, of vulnerabilities at any given time. Just as a development team needs to prioritize what code needs to deploy when (or risk never shipping a thing), security teams need to determine the CVEs that present the most significant risks – and then educate other teams and departments accordingly.
“As a security practitioner, one of your biggest challenges is to determine which of those issues introduce real risk to the business and then make a compelling argument to development and operations teams as to why they should be fixed,” Benson says. “Most organizations struggle to do this well because it’s actually a pretty difficult problem.”
Benson notes that while CVEs are assigned a severity according to the Common Vulnerability Scoring System (CVSS), the real impact of a CVE for a given organization depends not only on the characteristics of the CVE itself, but also the characteristics of the environment in which it is present.
Context is important: “Context” is also another way of saying “prioritization.”
“To understand the risk a vulnerability actually provides, you need to add more context around the CVE, such as which vulnerabilities would be most damaging if exploited, based on the systems and products your organization is using,” Gamblin says.
In the simplest scenario, you’re not going to fret over a CVE issued for, say, a software application that your organization doesn’t use. But on the flip side of that coin, a CVE related to a mission-critical system should probably rise quickly up to the top of your list. There are plenty of other environmental variables and criteria to consider in terms of prioritization, too.
“A vulnerability doesn’t mean much to anyone if a potential attacker lacks reasonable means to actually exploit it,” Benson explains. “This could mean, for instance, that you would consider a CVE present on an internet-facing application that can be exploited without authentication to be much worse than a CVE that’s locked up in an internal testing environment that’s only accessible behind a VPN. A vulnerability also doesn’t mean much to anyone if it’s present in a part of an environment that isn’t particularly important from a business standpoint.”
Automation can help with CVE prioritization
Third-party security partners and tools can help on this front; in fact, some can help automate that prioritization.
“Organizations can leverage automatic solutions offered on some threat intelligence platforms to automatically monitor CVEs related to their specific organization,” Preminger says. “This enables organizations to receive actionable intelligence that will inform their understanding of the threat landscape, the emerging and imminent threats out there, and specifically deal with CVEs [being] discussed by underground threat actors and [that] are therefore more likely to be exploited.”
Taking any thoughtful steps toward prioritization is a sign that you’re using CVEs the way they were intended and not as some magical solution. Moreover, the general trend to modern infrastructure and cloud-native development should also help in this regard.
“Applying some prioritization to CVEs based on the operational and organizational context surrounding them goes a long way toward improving overall security posture,” Benson says. “The growing popularity of declarative infrastructure has a significant impact in this regard, as it provides better visibility into that surrounding context and is much easier to continuously analyze than environments built on traditional infrastructure.”
[ How do containers help manage risk? Get the related Red Hat whitepaper: Ten Layers of Container Security. ]
