In This Article
What is Vulnerability Management?
Vulnerability Management can feel a bit like trying to put out multiple fires all at the same time, but high-level, it is a way to regularly identify, assess, and address vulnerabilities within an Information Technology environment. This should cover workstations, servers, network devices, Operational Technology devices, and even mobile phones. Essentially, if it's on or connected to your organization's network in some way, it should be reviewed for vulnerabilities.
Why is This Important?
It's very difficult to fix what you don't know is broken or missing. For a rough analogy, if you built a house and didn't inspect it, you wouldn't know that someone forgot to put the front door in and now your house is wide open to the outside world. The same concept applies to the world of IT in that you don't know what was missed, misconfigured, or has vulnerabilities unless you check for them.
Vulnerabilities, Exploits, Threats, and Risk - What Are These?
Understanding what vulnerabilities, exploits, threats, and risks are as well as their differences can help you not only communicate with the individuals that can help you address these, but also help you when talking about risks with the Management team.
Vulnerability - a weakness or some type of flaw which can be found in a system, network, application, or other resource or asset. These typically arise from bugs in software or code, misconfigurations, outdated software, or even by failing to change certain default settings like default credentials.
Exploit - a tool, code, technique, or other method that takes advantage of a vulnerability for malicious purposes.
Threat - the possibility of an attack that could exploit a vulnerability. Essentially, what is the likelihood that a specific vulnerability will be exploited.
Risk - the potential for loss, damage, or other negative effects when a vulnerability is exploited.
Vulnerability x Threat x Impact = Risk
There's a common formula frequently referred to in the cybersecurity world which is 'vulnerability x threat = risk'. This formula looks at the vulnerability and the potential for it to be exploited in your specific environment which produces a rough risk quantification for you.
I don't think this common formula quite gives you the full picture which is why I always include 'impact' into this formula. Looking at vulnerability, the potential for it to be exploited, and the impact it could inflict if exploited provides a much more accurate risk calculation. For example, there's a critical vulnerability within a software and it is easily exploited by anyone which would make this a high priority; however, if we also look at the impact, we would see that the maximum damage that can be done is all of the ceiling fans could be stopped. Well, now it doesn't seem so extreme. The point here is take everything into context - the vulnerability, the potential for exploitation, and the potential impact, otherwise you may be inadequately calculating risk which can lead to improper prioritization when it comes to vulnerability management efforts.
How are Vulnerabilities Scored?
Standards are great because they ensure we're all speaking the same language and can easily arrive at the same conclusion. Scoring vulnerabilities is no different and the one organization that sets the scoring is called the Forum of Incident Response and Security Teams (aka FIRST). FIRST created what is known as the Common Vulnerability Scoring System, or CVSS, which is a detailed method of scoring each vulnerability regardless of what the vulnerability is, how it came about, or who it affects. They assign a severity score on a scale of 0 to 10, with 10 being the absolute most critical. Here is severity scoring for the latest version (v4) along with the common color codes for each.
Score | Severity |
0 | None |
0.1 to 3.9 | Low |
4.0 to 6.9 | Medium |
7.0 to 8.9 | High |
9.0 to 10.0 | Critical |
This scoring and more details about how scores are calculated can be found at FIRST's website: https://www.first.org/cvss/v4.0/specification-document
Each vulnerability that gets acknowledged and published needs to be uniquely identified, especially since one software application could have multiple vulnerabilities that all can lead to the same negative consequences via the same exploitation methods. This is why the Common Vulnerabilities and Exposures (CVEs) identifiers came about. CVEs are the industry standard for uniquely identifying each vulnerability which makes it easier to track and manage from the perspective of both the vulnerability 'owner' and the people that need to address it within their own organizations.
There are a few vulnerability databases out there, like the National Vulnerability Database (NVD), so it's important to note that CVEs unique identify the vulnerability regardless of which database or website publishes them. For example, CVE-2024-5274 is about a type confusion in Google Chrome prior to v125.0.64.22.112 that allowed for the execution of arbitrary code. Regardless of which vulnerability database or website you would find CVE-2024-5274, it would always be the type confusion vulnerability in Google Chrome.
The Vulnerability Management Program - How to make it happen
The Plan
As with all things, thorough planning is the first step towards creating an effective vulnerability management program. The best way to start here is by gathering a complete list of all systems, software, and other information technology assets that should be covered by this program. We should then work to identify legacy systems or software and critical assets such as domain controllers which will all be referred to as sensitive assets.
It is important to note that you may come across devices that simply cannot withstand vulnerability assessments. As an example, I was performing a vulnerability scan on an entire subnet when a few very old printers began printing out solid black pages until they ran out of paper. It turns out, the vulnerability scan interacted with these printers in a way that caused them to unexpectedly print. Organizations often need to maintain legacy systems and software beyond their life expectancy for one reason or another, so identify these in the planning stage and approach them with caution.
Once you have a complete list of all items to cover with this program, and all sensitive assets identified, group them in a way that allows you to target similar assets at the same time but approaches those sensitive assets in a separate and specific way. For example with a large organization, group all workstations by site, all servers by function, and all operation technology (OT) by site. If you have a smaller organization, you may want to group all workstations into one and all servers into one.
A cautionary note here: I highly recommend that if you are just starting out, have a testing group which consists of a few devices of each type. That way, if there are negative consequences, they are minimal and don't cause user-facing problems.
Once you have these groups identified, try to assign an IP range to each scan if your network design supports this method. Doing this by IP address ranges ensures that you cover any new devices that may or may not have been added to your list. For example, if you're scanning a 10.0.0.0/8 because all of your workstations have addresses within this range, you ensure that any new workstations that get put on your network are covered by the scans.
Vulnerability Scans
Identifying vulnerabilities within systems and software can be done manually, but it is not recommended because it is extremely time-consuming and has a high likelihood vulnerabilities will be missed. Using a tool specifically for vulnerability detection, such as Horizon3 or Tenable, is definitely the way to approach this. Tools designed specifically for this are effective, efficient, and accurate with some even taking your specific environment and security controls into account when calculating a severity score.
If you absolutely need to do this manually, the best approach would be to gather a list of all software and drivers, including their versions, and search a vulnerability database one by one. Next, perform a full review of the host firewalls and ensure only ports that are absolutely necessary remain open. It can also be highly beneficial to perform a review against industry standards and benchmarks, like CIS Benchmarks, as they can help you ensure your assets meet a minimum baseline of security.
Back to the vulnerability scanners, once you have the list of all devices, applications, and other technology that you want to review for vulnerabilities, the next step is performing the actual vulnerability scan. Since there are numerous tools out there, the recommendation here is to follow their instructions for setting up and running a scan. If this is the first time you're performing a vulnerability scan within your environment, or you're using a new vulnerability scanner for the first few times, please take a few devices from each group and test them with the new scanner after hours or during the least impactful time of day. Vulnerability scanners can be resource-intensive for some assets and cause negative impacts in a few cases, so ensure you test these properly before targeting large groups.
Assessing and Prioritizing Vulnerabilities
After all scans are completed and you now have the results in hand, a full assessment of all vulnerabilities is likely needed. This consists of reviewing each vulnerability with the previously mentioned formula 'vulnerability x threat x impact = risk' which will give you a risk calculation specific to your environment - this is also known as recasting your risk. With the "norm" being IT teams that have a heavy workload already, it is essential to recast your risk so the most critical vulnerabilities within your specific environment can get the attention they need while buying a little time for lesser critical vulnerabilities.
Addressing the Vulnerabilities
When it comes to addressing vulnerabilities, there are actually four main methods of doing this rather than just patching or upgrading to fix the vulnerability. Here are the main options you have for addressing vulnerabilities:
Acceptance - this means that you are going to just accept that this vulnerability exists and do nothing about it. This may seem crazy, but if a vulnerability within your environment is scored as a 0.1 (CVSS) and when you recast your risk, it shows that the risk is extremely small, you may determine the amount of work and effort to fix this vulnerability is more than it is worth.
Avoidance - you completely get rid of whatever the vulnerability is. For example, if there is a vulnerability found within a word processing software on a server, you may determine that server doesn't need a word processing software at all, so you completely remove that software.
Mitigation - place additional security controls and obstacles in place to lessen the likelihood or impact of exploitation to bring the overall risk within your tolerance. For example, if a server has a vulnerability that can be exploited only by authenticated users on that server, ensure only users that absolutely need access to this server have access which then lessen the chances of it being exploited.
Remediation - actually patching, upgrading, or otherwise properly fixing the vulnerability. For example, you upgrade to a newer, unaffected version of a word processing software to fix a vulnerability within the word processing software.
Oftentimes, addressing vulnerabilities can be shrugged off as they are not the main focus of System Administrators and similar positions. I always recommend working with the other IT Teams to address vulnerabilities rather than using the 'security takes precedence and you need to comply' stance because we're all on the same team and we're all people, so just be kind and work with your other teams. With that being said, it is still immensely helpful to have a policy in place that guides the addressing of vulnerabilities to ensure they are not swept under the rug and that they follow a standardized procedure for notification, addressing, and reporting. In this policy, it should note the timelines around when each severity should be addressed to minimize the time vulnerabilities are present which helps reduce the organization's risk. A common set of deadlines are:
Severity | Timeline to complete once detected |
Low | 1 year |
Medium | 6 months |
High | 3 months |
Critical | 1 month |
Continuous Management
Kicking off a vulnerability scan that targets all assets is great, but threat actors and researchers are always trying to discover new vulnerabilities, new software and systems are always being introduced into your environment, and accidental misconfigurations may occur which means a vulnerability management program never ends. Performing scans, assessments, prioritization, and addressing vulnerabilities is a continuous cycle that should be conducted on a regular basis that fits your organization. If you have the resources and personnel bandwidth, you may perform this on a weekly basis, but more realistically, scans may be conducted every 2, 3 or even 4 weeks with addressing vulnerabilities being an overlapping and ongoing endeavor. The key here is this program is a continuous cycle that needs to be maintained.
3rd Party Penetration Tests
Penetration tests can be a fun or frustrating topic, but this section will only briefly dive into this with a future article taking a much deeper look at demystifying penetration tests. A penetration test is an authorized test against your environment in which a threat actor is simulated and cyberattacks are carried out against your organization to identify exploitable vulnerabilities and attach paths actual threat actors could take advantage of. Employing a 3rd party to perform this is crucial as 3rd parties are, or should be, unbiased and the organization you engage for this should be an expert in this field which nets you an effective real-life simulation of a sophisticated threat actor. These tests can be costly but have the potential to identify major gaps or shortcomings in your security, so these are typically conducted on an annual basis.
Comments