Background
While the distinctions between vulnerabilities versus risks has been widely documented in various forums, we thought we’d approach this topic from a slightly different angle. At SimpleRisk, we’re often asked by prospects and customers alike if it makes sense to manage vulnerabilities as risks? Put another way, should vulnerabilities identified by scanning tools be imported into a risk management system and tracked through the risk mitigation life cycle from a central place? Or, are the unique characteristics of vulnerabilities so disparate from risks that they should be tracked and managed separately? We’ll address these questions in this blog, but first, we’ve included definitions of each below, followed by some key differences, and a brief recap as to how they can potentially be leveraged to complement one another.
Techopedia defines a vulnerability1 as “a cyber-security term that refers to a flaw in a system that can leave it open to attack. A vulnerability may also refer to any type of weakness in a computer system itself, in a set of procedures, or in anything that leaves information security exposed to a threat.”
Wikipedia defines security risk management2 as “any event that could result in the compromise of organizational assets i.e., the unauthorized use, loss, damage, disclosure or modification of organizational assets for the profit, personal interest or political interests of individuals, groups or other entities constitutes a compromise of the asset, and includes the risk of harm to people. Compromise of organizational assets may adversely affect the enterprise, its business units and their clients. As such, consideration of security risk is a vital component of risk management.”
How Do Risks and Vulnerabilities Differ?
One important distinction between vulnerabilities and risks is that when standalone vulnerabilities are discovered, context is not taken into account. While the existence of a known vulnerability tells you where and how an exploitation could occur, what it doesn’t tell you is the potential organizational impact if a given vulnerability is exploited.
Clearly, not all vulnerabilities are created equal. But, even if it’s relatively easy for a bad actor to exploit a “critical” vulnerability before you’re able to effectively prioritize mitigation, you need to be able to answer the question “what will the impact be if an exploit is successful?” A vulnerability may be classified as critical, but if its compromise will result in little or no impact to your organization, why prioritize the mitigation? This is especially true if there are other critical vulnerabilities present that could result in significant organizational impact if exploited.
In contrast, using the “Likelihood x Impact” formula to calculate risk has been widely adopted as a best practice by many security practitioners over the years. This formula is contextual and delivers two key metrics. By calculating the likelihood, or the level of ease or difficulty required to exploit a risk, coupled with the potential impact to your organization if a breach were to occur, you’re able to obtain two vital data points that provide a clear guide to help prioritize your risk mitigation efforts.
Another key difference between risks and vulnerabilities is that risks will often exist in organizations, even if no known vulnerabilities can be directly tied to those risks. In instances where you have physical security risks, geopolitical risks, or risks due to server misconfigurations, risks may never intersect with a known vulnerability.
Can vulnerabilities be complementary to risk management and vice-versa?
While it’s clear that vulnerabilities don’t equal risks, let’s review how they can potentially compliment one another. Given that the presence of known vulnerabilities increases the likelihood of an exploit, linking known vulnerabilities to the highest areas of risk allows you to more effectively prioritize mitigation efforts. Conversely, once you’ve identified your highest areas of risk exposure, correlating risks to known vulnerabilities can also be an effective way to prioritize mitigation; so it works both ways.
Should you try to manage vulnerabilities and risks under a single system?
Now that we’ve established a foundational understanding of the key differences between vulnerabilities and risks, as well as how they can complement one another, let’s turn to the key question posed in the opening paragraph: Should vulnerabilities and risks be managed in the same place? While it’s relatively straightforward to import vulnerability data into a risk management tool, and, in fact, several SimpleRisk customers currently do just that, in order to realize any measurable benefits some key factors should be considered.
On the surface, importing vulnerabilities into a risk management system may seem perfectly logical. After all, the data contains two elements that security practitioners need: assets and vulnerabilities. However, before going down this path, you should eliminate duplicates and false positives to avoid having to deal with an excessive amount of unwanted vulnerabilities that will now be intermingled with actual risks, without an easy way to collapse them down, organize, and manage them. If this scenario occurs, it will likely have a negative effect on your ability to manage and prioritize mitigation, making the process more confusing, time consuming, tedious, and less efficient. Let’s walk through a simple example.
Assume I have a cluster of 50 web servers that are all susceptible to an Apache Struts vulnerability. Upon importing that small dataset, I now have fifty assets, with fifty vulnerabilities, creating unwanted complications and redundancies. While it’s likely I could fix this one vulnerability in a single (or handful) of places and mitigate the issue in all fifty servers, I’ll need to wade through this data manually, which would probably take hours, producing little or no extra value.
In short, if the import process isn’t tightly managed upfront, it’s easy to see how a pool of hundreds or even thousands of vulnerabilities could quickly populate my risk management system. Plus, with no easy way to consolidate the vulnerabilities down and link them to the highest areas of risk exposure, it will rapidly become counter-productive to attempt to effectively prioritize mitigation efforts.
Conclusion
If you do elect to commingle vulnerabilities with risks and manage them from a central place, you’ll want to adhere to the best practices listed below. Understanding these guidelines upfront will help determine if it will be worth the investment in time and resources to undertake this effort. Keep in mind the over-arching goal here should be to create a process to manage vulnerabilities and risks more effectively, using the key metrics from each to help prioritize your mitigation efforts. For this approach to be successful, you’ll need to:
- Import “clean” vulnerability data by eliminating duplicates and false positives
- Accurately gauge the likelihood that a given vulnerability or risk could be exploited
- Quantify the resulting organizational impact if vulnerabilities or risks are exploited
- Correlate the key attributes of vulnerabilities with risks to hone mitigation efforts
- Adopt a ranking system that’s consistent for both vulnerabilities and risks
- Track and report on the mitigation life cycle of both vulnerabilities and risks in a way that’s simple to understand and communicate to all stakeholders
If your current risk management program is falling short and you’re convinced you will gain enough incremental value by managing and consolidating both under a single system, then go for it. But, be mindful that it’s 1) imperative to have adequate resources in place to implement, manage, and administer the associated processes, which will in large part be dependent upon the quantity of vulnerabilities being tracked and 2) essential that you avoid the potential pitfalls discussed here.
If you’re uncertain about moving forward with this approach, you’re likely better off using separate tracking and management systems – one for vulnerabilities and one for risks. Using separate systems to manage both has proven to be effective and you can still reap the benefits of leveraging how vulnerabilities and risks can complement one another. Also, by keeping them separate, you’ll avoid the potential headaches you may otherwise encounter by consolidating risks and vulnerabilities under a central system.
