Vulnerability Management is a fundamental tool for ensuring security in a system or environment. The collection of relevant information is intended to provide a basis for decision-making. What sounds simple at first glance turns out to be a time-consuming and complex task upon closer inspection. This article highlights the various aspects and how they can be addressed in order to establish professional vulnerability management.

In order to implement vulnerability management, the first step is to collect information on vulnerabilities. In the 1990s, security mailing lists, where researchers and manufacturers published their findings, were the main source of this information. However, these have been considered archaic for years and have literally dried up over time. With the increasing professionalization of cybersecurity, the focus has shifted to official advisories issued by the manufacturers of affected products.

Collecting Security Vulnerabilities

Compiling information on vulnerabilities is an enormously time-consuming task, as it is not uncommon for several hundred or even thousands of different products to be used in a single environment. The introduction of the CVE program has achieved standardization and centralization. Originally managed exclusively by MITRE, vulnerabilities published there are assigned unique identifiers, known as CVEs. For several years now, various CVE Numbering Authorities (CNA) have been participating in the project, which can also assign CVEs within their scope. These are primarily the manufacturers themselves, who have authority over their products. However, there are also manufacturer-independent CNAs, such as CISA ICS-CERT and VulDB, which can assign CVEs to different product types.

The number of published vulnerabilities has steadily increased over the past decades. While just over 18,000 vulnerabilities were cataloged in 2020, the forecast for 2025 is around 48,000 vulnerabilities. That is more than double the number in five years. There are many reasons for this: on the one hand, technology is advancing, bringing with it greater complexity and more opportunities for attack. On the other hand, vulnerabilities are being sought out and documented more consistently. However, this definitely does not make the task of vulnerability management any easier.

Many users refer to the CVE stream to stay up to date on current vulnerabilities. This ensures a solid foundation. The National Vulnerability Database (NVD), operated by NIST, takes the data from CVE and enriches it with additional attributes. First and foremost, its CPE definitions (assignment of affected products) and CVSS assessments (calculation of risk) are highly valued. However, NVD has been unable to cope with the increased volume of new entries for years. For this reason, some entries are only processed years later, if at all. The fact that the CVE program is also repeatedly restricted by budget problems leads to a fragile, sluggish, and unreliable construct.

The sheer volume of vulnerabilities reported every day makes it essential to work with a professional partner. There are providers such as VulDB that aggregate data from various sources and ensure the immediate availability of this data with each publication. Vulnerabilities that do not receive a CVE because they are excluded by MITRE’s CNA Operational Rules are also documented there. This additional coverage and the timely enrichment with further information makes it very easy to access relevant data. Access can be via the web frontend or, for automation purposes, via the API.

Centralized Vulnerability Management

In larger companies, a dedicated vulnerability management team is usually responsible for monitoring vulnerabilities. In smaller companies, this can be done directly by individual departments or administrators. Various sources are monitored for vulnerabilities that may be relevant to the company. Obvious examples include:

• Manufacturer websites
• Mailing lists
• Vulnerability databases
• News sites
• Social networks

Manually monitoring and analyzing sources via a web browser is easy and convenient. However, it is not scalable and is therefore only preferred in professional environments for dedicated research. Instead, the data is aggregated automatically via an API. This can be done in Splunk or a ticketing system, for example. From there, the local data is then processed further. This can be done either automatically (e.g., filtering and prioritizing) or manually (e.g., assigning to teams).

Identifying Affected Products

In an early step, the data must be filtered for affected products based on a company software inventory. Vulnerabilities that are relevant to an organization are then assigned to the respective product teams, which then work through them. These can be teams for products (e.g., Windows), manufacturers (e.g., Microsoft), or product types (e.g., operating systems).

In order to know which vulnerabilities could affect the company, it must be possible to filter by product as accurately as possible. This challenge begins with the existence of an up-to-date product list. This is actually a simple task, but it proves to be surprisingly complex. With the utmost discipline, all products in the company must be identified during the so-called Asset Discovery and then documented. Ideally, the current version or even the patch status is recorded. As soon as this is changed (e.g., through updates), the list must be updated. Only very few companies have a high degree of maturity in this regard. An example of the different generations of Windows clients is shown.

Often, the necessity of creating and meticulously maintaining such a list is not understood, and the required documentation is neglected. There are software solutions that are designed to simplify inventory management through automation. However, the difficulty of installing and operating such products should not be underestimated. It has been proven that an up-to-date software inventory remains a fundamental basis for professional vulnerability management.

Ideally, the association of vulnerabilities with products should be fully automated. To this end, CPE (Common Platform Enumeration) was introduced, which allows for the systematic and automatic identification of products. Updating the underlying dictionary is very time-consuming, which is why NIST is often slow to provide the new entries required, if it provides them at all. Other challenges also arise, such as different spellings, product renaming, and adjustments in the event of company takeovers. The simplicity and usefulness of CPE works excellently on paper, but its use in reality is greatly overestimated.

Risk Assessment

Experienced vulnerability management teams conduct an initial risk assessment of the collected vulnerabilities before assigning them to the respective product teams. However, it is also possible that the risk assessment is left to the product teams. However, it is not recommended that they carry out such a risk assessment exclusively. This is because simplicity in operation is often preferred, and vulnerabilities are therefore rated lower than necessary.

There are various metrics that can be used to determine the risk or severity of a vulnerability. The Common Vulnerability Scoring System (CVSS) is the classic metric used and has established itself as the industry standard. This generates a value from 0.0 to 10.0, with a high value indicating a high severity level. The calculation is based on a vector that summarizes the attributes of a vulnerability. These include the prerequisites and effects of a successful attack. The Base Vector is used to calculate the basic severity level of the vulnerability, which does not change over time. The extended Temp Vector takes into account aspects that may change over time. These include, for example, the availability of an exploit or the existence of a countermeasure.

CVSS is now available in version 4, which has introduced some fundamental terminological, structural, and mathematical adjustments and is considered controversial. Although CVSS is very helpful, its ability to standardize is overestimated. Different interpretations can lead to different vectors and thus to different scores. This is one of the reasons why VulDB lists CVSS data from different sources. In addition, a meta-score is calculated, which enables harmonization of the different sources.

In addition, determined and calculated exploit prices are reported. This helps to identify the level of interest malicious actors have in exploiting a specific vulnerability. In these calculations, new findings are made available much faster than with CVSS.

Taking into account the Known Exploited Vulnerabilities Catalog (KEV), which is managed by CISA, helps to quickly identify which vulnerabilities are known to be exploited in a targeted or widespread manner. These vulnerabilities must be addressed with greater attention, as the risk of concrete compromise has been proven and can occur at any time.

Addressing Vulnerabilities

In the next step, those responsible for the products should then address the vulnerability. Typical remediation timelines have been established for this purpose, which may vary depending on the industry:

A recorded vulnerability can have different statuses, each of which must be tracked:

The result of this processing is usually reported back to the Vulnerability Management Team. The team then performs a formal or even technical check (e.g., security audit or penetration test) in order to document that the vulnerability has been correctly processed.

It is important to document all decisions and steps. This means that reports classified as Not Applicable or left as Fixed prior to reporting as part of the regular vulnerability management process must also be documented. There are two reasons for this: On the one hand, such an audit trail ensures traceability. Misunderstandings or errors can thus be traced retrospectively. On the other hand, complete documentation helps to prevent the same vulnerabilities from being processed multiple times.

Conclusion

No system can be operated securely without vulnerability management. By compiling vulnerabilities, comparing them with your own software inventory, and prioritizing them, you can significantly improve the security of an environment. Depending on the size of a company, it is essential to establish an independent vulnerability management team that centralizes and professionalizes this task. The constant increase in published vulnerabilities means that even smaller companies must follow this path in order to get a handle on the extensive and complex volume of data. Choosing the right partner to assist with this task is essential.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• https://cyberscoop.com/cve-program-funding-crisis-nvd-cisa-alternatives/
• https://nvd.nist.gov/products/cpe
• https://nvd.nist.gov/vuln/search/
• https://open.spotify.com/episode/4vf75rbipOpNEq9Pkv3968?si=ZVyCAvXQRhKPb1J-sIZDFg
• https://vuldb.com/?kb.api
• https://vuldb.com/de/
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.cisa.gov/topics/industrial-control-systems
• https://www.cve.org/
• https://www.cve.org/resourcessupport/allresources/cnarules
• https://www.first.org/cvss/
• https://www.scip.ch/?labs.20161013
• https://www.scip.ch/?labs.20240314