What Is Vulnerability Management?

Security vulnerabilities. We'll always talk about them. They're part of our raison d'être at Fluid Attacks. On behalf of our customers, our initial goals with them are to identify, describe and report these security issues. But our mission doesn't end there. In our previous post, we mainly discussed vulnerability assessment, a procedure covering the goals above. On this occasion, we will focus on explaining a term we already related to the previous one: vulnerability management. This concept covers a broader range of activities concerning vulnerabilities, which we also provide to our clients. Before getting down to business, let's start by contextualizing for those who are unclear about what a vulnerability in cybersecurity is.

A security vulnerability refers to a weakness in an IT system that is usually the result of software bugs, design errors, or misconfigurations. Being exploited by attackers, a vulnerability can function as a way to allow them unauthorized access to and control over the system for the theft of information or other assets or the disruption of operations.

A vulnerability is, for instance, leaving an access point to confidential information on your system unlocked. This doesn't necessarily mean that damage will occur, but there is such a possibility. This in itself is the risk: a dangerous situation, a chance that something bad will happen. The valuation of the risk will depend on the probability of the negative effect occurring and the costs it would entail for its owners or other parties involved. In our example, the possibility is that someone unauthorized could illegally access the confidential information for wrongful uses.

Although, in the dictionary, the word "threat" also has among its definitions "the possibility of trouble, danger or disaster," and, in cybersecurity, it's sometimes used interchangeably with the word "risk," in our case, we prefer to attribute "threat" to the agent that can generate the negative effect or damage. However, the latter definition is also given to "risk" in the dictionary. (It's as if they were practically defining the same thing.) That's why it's sometimes better to speak explicitly of "threat actor." In short, if you have a vulnerability in your system, there is a risk that a threat actor will exploit it to harm you.

Security vulnerabilities are usually ranked by their severity (i.e., the level of risk they represent) according to the Common Vulnerability Scoring System (CVSS). This free and open-to-the-public international standard, managed by the non-profit organization FIRST, features a quantitative scale ranging from 0.0 to 10.0, which is usually divided into a qualitative severity rating scale, as shown in the following table:

The complete CVSS score is composed of three groups of metrics: Base, Temporal, and Environmental. The Base score represents the severity of a vulnerability according to its intrinsic characteristics constant over time and in different environments. This metric mainly addresses the ease with which the vulnerability can be exploited and the direct impacts of its exploitation. The Temporal score reflects the severity of a vulnerability based on its changing characteristics over time. Thus, this metric considers the existence and availability of exploit code and remediation patches. The Environmental score represents the severity of a vulnerability according to its characteristics relevant to a specific user environment. This metric takes into account factors such as the security controls present and the relative importance of the vulnerable system within an entire IT infrastructure.

Although it's common for organizations to use and report the Base metric, it's advisable for consumers to put into the equation the other two metrics to modify Base scores and reveal complete, more accurate vulnerability severities adjusted to their environments. To learn about some of the shortcomings of the CVSS metric, we invite you to read this post.

Publicly disclosed security vulnerabilities around the world are generally cataloged and described in freely available lists such as the CVE (Common Vulnerabilities and Exposures). On the other hand, the CWE (Common Weakness Enumeration) lists and categorizes types of weaknesses in software and hardware that can lead to exploitable vulnerabilities. CWE even offers a Top 25 Most Dangerous Software Weaknesses, similar to the OWASP Top 10. However, the latter specifically highlights the most critical security risks to web apps (risks associated with security vulnerabilities).

Vulnerability types are plentiful. Although different criteria can lead to the categorization of vulnerabilities, at Fluid Attacks, for example, we apply one similar to that used in CAPEC (Common Attack Pattern Enumeration and Classification) to organize attack patterns. What we do then is to separate the types of vulnerabilities by mechanisms of attack frequently used for their exploitation, which in this case are nine groups. As the intention here is not to list all types, what we offer below is a list of the groups with three types of vulnerabilities as examples for each one. Please visit the Criteria section of our documentation for the complete list.

Security vulnerabilities could be present in our IT systems without a problem if threat actors didn't exist. (In fact, if they didn't, surely the former wouldn't be called such.) But this is just a pipe dream. Cybercriminals are ceaselessly roaming the information networks in search of victims, primarily motivated by money. What they initially want is to discover our vulnerabilities. If they didn't exist, attackers would not be able to harm us. So, ultimately, what we seek to protect ourselves from is threat actors and their evil deeds, not vulnerabilities. However, what is within our reach, what we can control, is the prevention and treatment of vulnerabilities. And this is indeed something we can accomplish with vulnerability management. But what is vulnerability management in cyber security?

Vulnerability management is a process of identifying, evaluating, prioritizing, reporting and dealing with security vulnerabilities. Although it doesn't have to be seen as continuous, ideally, it should be. In fact, that is how it's usually offered. But why does it need to be an ongoing process or cycle? The cyber environment is constantly changing. New systems emerge, evolve, become more complex, and expand; with them, new vulnerabilities and, alas, new threats appear. The continuous vulnerability management procedure, with a stable repetition of different stages as a cycle, seeks to attend to this situation. Evaluating systems and their vulnerabilities at a single point in time, or only occasionally, is to lag behind the gargantuan leaps of information technology. And this could mean high exposure to the risk of suffering from cyberattacks.

Security vulnerability management strategy can be part of an overall security program, which could also include strategies such as implementing defenses and traffic review, security training for different groups of employees, developing incident response plans, etc. Vulnerability management is a preventive approach. This procedure aims to help bring and keep an organization's risk exposure to a minimum. Vulnerability management tools streamline and facilitate the operations within the cycle and often allow everything to take place from a single dashboard.

When we talk about vulnerability management, vulnerability assessment must necessarily enter into the equation. Conversely, the latter could occur independently. Vulnerability assessment is part of the vulnerability management process because it's when security issues are identified, classified, and reported. This assessment can be carried out either by automated tools (i.e., vulnerability scanning) or humans (usually through penetration testing or ethical hacking); still, there should be a complement between the two. Thus, vulnerability assessment is integrated into a cycle where vulnerabilities are also prioritized and treated.

As in the case of vulnerability assessment, vulnerability management can be carried out by automated tools, at least in part. Similar to what happens for the identification of security issues in IT systems, the contribution of tools for such an essential procedure of vulnerability management as vulnerability remediation is limited. In fact, this limitation is much more marked than the first one.

What some automated tools seem to be able to do so far is to remediate vulnerabilities that are too basic and superficial, many of which are present in open-source third-party components that require only the identification and application of patches or updates to be fixed. Therefore, human intervention continues to be fundamental. It is true that, as has been happening for some time now in different phases of vulnerability management, tools increasingly allow time and effort savings so that security and development experts can focus directly on the most complex and risky vulnerabilities. However, proper vulnerability management today cannot be fully automated.

First, we have to refer to some tasks to accomplish before starting the vulnerability management lifecycle. The organization that intends to implement this solution should begin by defining the scope of the process. It should be clear which of its systems and components will be assessed for vulnerability detection. (This may require asset inventory services.) In relation to the assets involved in that scope, the organization in question should assign values to them in order to determine which are most critical to protect.

In addition, the organization should define roles and responsibilities for its vulnerability management team, such as who would be in charge of monitoring different stages and the whole cycle, who would identify, address or remediate vulnerabilities, and who would review and authorize the implementation of strategies and the delivery of reports. Ergo, it should also choose the tools and services for vulnerability assessment and, in general, all steps of vulnerability management. Finally, the organization should establish vulnerability assessment and treatment policies (e.g., review frequency, temporary and absolute acceptance parameters, and remediation deadlines).

Although this is not a strict model, these are usually the vulnerability management process steps:

This stage can start with vulnerability scanning. Automated tools scan the organization's chosen systems to detect whether any or all of the security issues they have in their databases of publicly known vulnerabilities are present in those systems. Accurate configuration of the scanners and their scans can help avoid disrupting or altering functions in the evaluated technology and very high false positive rates. Then, the human intervention comes in the form of manual pentesting, which is assisted by other tools. The so-called pentesters, with a methodology oriented towards the in-depth assessment of IT systems, endeavor to detect anything that escapes the radar of automated tools. Often, these are more severe, more complex and previously unknown (zero-day) vulnerabilities.

At one point in this stage, the pentesters or security professionals seek to minimize false positive and false negative rates. To achieve this, they validate scanners' reports and fix their errors. That is, they remove from the lists of identified vulnerabilities those reports that do not actually constitute vulnerabilities and include in them the vulnerabilities that the tools should have reported but did not. (These are separate lists from those delivered from penetration testing in the previous stage).

Both scanners and pentesters generally rate their findings based on well-known metrics such as CVSS. As we said before, this system scores the severity of vulnerabilities from 0.0 to 10.0. Then, vulnerabilities can be prioritized; they can be ranked in order of importance according to the risk they pose. The usefulness of this vulnerability prioritization is that, at the time of the report, the organization under evaluation can know which security issues to deal with first.

One of the influential factors in the evaluation and prioritization of vulnerabilities is their exploitability. At this stage, questions such as the following arise: Is this vulnerability exploitable? How easy is it to exploit? Is there already an exploit for this vulnerability floating around the web? (An exploit is a specialized code that allows taking advantage of a security issue.) What would be the impacts of its exploitation? Pentesters are crucial to answering questions such as the latter. From their offensive security approach, i.e., by simulating "real-world" attacks, these experts are responsible for testing the exploitability of specific vulnerabilities in order to provide evidence of the potential impacts.

After evaluation and validation, each finding by the tools and experts can be reported through a vulnerability management tool or platform. Ideally, each vulnerability should be able to reach this stage or, better, complete the cycle independently. We mean that solution providers shouldn't expect to have a massive accumulation of vulnerabilities before reporting their existence to those who, in the next stage, will be in charge of their treatment. As teams receive small numbers of prioritized vulnerabilities, they can easily decide what actions to take. Among the various details about each identified and assessed security issue that can be provided to the organization under assessment are the following: type, severity, location, identification date, current status, description, evidence of existence and exploitation, and treatment recommendations.

After obtaining details on each vulnerability, including treatment recommendations, the team responsible for this stage must take action. The ideal treatment option is vulnerability remediation, especially if the vulnerability involves high-risk exposure. Remediation is the patching or complete repair of the security issue to prevent exploitation. We should keep in mind that sometimes suggestions from automated tools or novice individuals may not be the best. Hence, the intervention of specialized cybersecurity staff is a sine qua non for appropriate vulnerability treatment.

Another treatment option, mainly when, for one reason or another, there's still no opportunity for remediation, is vulnerability mitigation. This is about reducing the likelihood of exploitation of the vulnerability (e.g., applying a technique that makes it more tricky for an attacker) and the potential impacts. It may be a quick temporary treatment while a patch or other form of vulnerability remediation is being developed.

Finally, there is the option of vulnerability acceptance, which may be temporary or permanent. Choosing this option may depend on the internal policies of the organization in question. One security issue may be accepted by this organization simply because the risk it represents is very low, and the remediation costs are higher than those associated with its exploitation. In any case, it is usually advisable that there is no permanent acceptance and, regardless of how low the risk is, to achieve remediation of the vulnerability in the near future. Another thing is when what needs to be remediated is an issue that, for instance, is found in an application that the organization plans to disable in the very short term. In this case, permanent acceptance is more justifiable.

Security vulnerability remediation should always be verified for the stakeholders' peace of mind. In this stage, rescans and reattacks are performed to validate that the solution given to each vulnerability was effective, thus indicating its closing. In addition, reassessment is recommended to discover whether new vulnerabilities have arisen due to the previous treatments. Once this is accomplished, the reporting information can be updated. For example, the security status of a vulnerability can shift from "open" to "closed."

Vulnerability reports that accumulate in vulnerability management platforms can be used by managers or administrators of the organization to evaluate efforts, achievements, and progress. A good platform allows the delivery, customization, and downloading of reports in different formats and adjusted for both executive and technical staff. When the platform contains a wide variety of charts and figures, the organization's teams can properly monitor trends in the emergence and remediation of vulnerabilities and mitigation of risk exposure. Moreover, if the platform allows, they can be aware of their compliance with multiple international security standards requirements.

Another way of expressing the above question could be, "Why do we need vulnerability management?" The importance of vulnerability management for an organization lies essentially in what we mentioned before: It is a procedure that allows us to keep control of a problem. Those vulnerabilities, resulting from our ignorance or carelessness, which threat actors seek to exploit, are the ones that we intend to detect and close as soon as possible or prevent them from coming to public light and even taking shape. Let's translate the importance of a comprehensive and continuous vulnerability management lifecycle into specific benefits:

Are you interested in implementing a vulnerability management process? At Fluid Attacks, we offer a Vulnerability Management solution within our Continuous Hacking service, which we can integrate into your software development lifecycle from the beginning. We connect all stages of the previously described vulnerability management process from a single place, i.e., Fluid Attacks' platform. We develop our own automated tools or security scanners, which apply methodologies such as SAST, DAST and SCA for continuous vulnerability assessment on your systems. We also have a large group of penetration testing experts who, with their skills as hackers (see here their multiple certifications), verify the findings of the scanners and identify those vulnerabilities that these machines could not detect. Their goal here is to minimize false positive and false negative rates. Of note, we use artificial intelligence to prioritize the assessment of those portions of systems that may be more likely to contain security issues.

For vulnerability scoring, we go beyond CVSS, adding a version modified by us: "CVSSF." With this metric, as you can learn in detail in another blog post, we overcome several drawbacks, such as that one that makes us mistakenly believe that a vulnerability of severity 10.0 means the same risk as ten vulnerabilities of severity 1.0. In our platform, we continuously report vulnerabilities to you as we discover and evaluate them in ongoing security testing. In addition to providing you with many details about each finding, we include tangible evidence of vulnerability exploitations carried out by our red team and recommendations for treatment. Also, from the platform, you can assign remediation activities to your team members. After they apply the necessary corrective measures (for which our experts can advise them), you can ask us as many times as you want to reassess or reattack vulnerabilities to verify that they were effectively closed.

Using our platform, you can choose specific vulnerability treatment policies, determine which security requirements to comply with (covering more than 60 security standards), and ensure compliance. Additionally, you can keep track of vulnerability remediation times and changes in risk exposure within your organization. Of course, you can customize reports and download them in different formats. You can enjoy this and more within a service that, from a preventive perspective, seeks to help you continuously improve your organization's security. Being one step ahead of cybercriminals, your organization can avoid falling victim to cyberattacks and seeing its assets, operations, and even reputation seriously damaged.

Are you interested in our service? Don't hesitate to contact us.