Vulnerability Management¶
This is an update to the document published on 2024-02-16
Vulnerability management is a continuous, proactive, and often automated process that keeps your computer systems, networks, and enterprise applications safe from cyber-attacks and data breaches by ensuring any weaknesses in the underlying software are updated.
While vulnerability management and patch management are two different disciplines, their end goals are aligned - to ensure your systems' weaknesses are identified and remediated. In a typical workflow, vulnerability management would identify the gaps, whereas patch management would close the gap.
Terminology¶
- A Weakness or a Vulnerability is the susceptibility or flaw in a system, network, application, or process that, if exploited, could compromise the confidentiality, integrity, or availability of information and resources, potentially leading to unauthorized access, data breaches, or service disruptions.
- A Threat is a potential or actual circumstance, event, or action that poses a risk of harm to the security, integrity, or functionality of a system, network, or organization, and may exploit vulnerabilities to cause damage, unauthorized access, or disruption.
- A CVE (Common Vulnerabilities and Exposures) is a standardized identifier assigned to a specific vulnerability or weakness in software, hardware, or systems, providing a common reference point for the cybersecurity community to share information about and address potential security risks. Remember Log4j a few years ago? It was reported under CVE-2021-44228.
- An exploitable vulnerability is a specific weakness or flaw in a system, application, or network that can be leveraged by attackers to gain unauthorized access, manipulate data, or disrupt normal operations, potentially leading to security breaches or compromise of the targeted environment.
- A zero-day vulnerability is a type of security flaw in software, hardware, or systems that is actively exploited by cyber attackers before the vendor or developer becomes aware of it or releases a patch. The term "zero-day" indicates that there are zero days of protection available, as there is no official fix or defense against the newly discovered vulnerability.
- A risk is a potential or anticipated adverse event or circumstance that may hurt the objectives, assets, or operations of an organization, involving the possibility of harm, loss, damage, or disruption and is typically characterized by its likelihood and potential consequences.
- Vulnerability Management is the systematic process of identifying, assessing, prioritizing, and mitigating vulnerabilities in a computing environment, aiming to enhance the overall cybersecurity posture by reducing the risk of exploitation and potential impact on systems, networks, and data.
- Patch Management is the systematic and strategic approach to acquiring, testing, and deploying software updates, patches, and security fixes across an organization's systems and applications to address known vulnerabilities, enhance system reliability, and safeguard against potential cyber threats and exploits.
How Does Vulnerability Management Work?¶
Agent-based scan¶
Typically an agent is installed on the operating system. It is a piece of software that would scan the system and inventory all software installed on it. Some scanners may also review the Windows Registry, or configuration files to determine if configuration issues can also result in a system compromise.
Agent-based scanners also tend to be very thorough, finding issues on all installed software, even if the software is not accessible to the internet. In a situation where you may have a vulnerability, however, if the internet port is completely blocked, the scanner will still report the vulnerability, even though it is not exploitable.
Agentless scan¶
In an agentless scenario (typically cloud-based), some Cloud Security Posture Management tools (CSPM) can take a snapshot of the virtual machine and scan the snapshot for vulnerabilities. This has a lot of advantages, like the ability to get your entire cloud environment scanned for vulnerabilities without having to deploy agents, or open network ports to allow the agent to report back to the central server.
Network scan¶
In a network scan, an appliance is installed on the network. This appliance will then perform a network scan and focus on the exposed network port. By enumerating the open ports, and running attacks against the open ports, the scanner can identify any exposed vulnerabilities. Like an agentless scan, no agent needs to be installed on the individual servers.
While a network appliance has a lot of benefits, it may not see all vulnerabilities that might exist on the individual system.
Dealing with vulnerabilities¶
In a typical vulnerability management system, there is an ocean of issues reported. How do you even begin to address it all? To begin our journey, we need to break it down into easier to understand concept. Consider that your systems (or hosts) and vulnerabilities are two distinct data sets that each have their own set of attributes that you can dig into.
graph LR
hosts:::blue --> cve[vulnerabilities]:::blue
iif([Is Internet Facing?]):::yellow --> hosts
prod([Is Production?]):::yellow --> hosts
appcrit([Application Criticality]):::yellow --> hosts
host_first([When first seen?]):::yellow --> hosts
host_last([When last seen?]):::yellow --> hosts
cve --> exploit([Has Exploit?]):::red
cve --> patch([Has Patch?]):::red
cve --> criticality([Criticality]):::red
cve --> discovered([When discovered?]):::red
cve --> published([When published?]):::red
classDef green stroke:#0f0
classDef blue stroke:#00f
classDef red stroke:#f00
classDef yellow stroke:#ff0
Hosts¶
- Is the asset internet facing or not? Machines with direct internet access may be more prone to an attack.
- Is the asset in production or not? You may want to put a higher priority on systems that can actually have an impact on your operation, rather than the ones that are in a test environment.
- What is the Application Criticality? Not all servers are equal, some are more important than others, so understanding how critical that server is will also drive better decision making.
- When was the host first seen? - This is helpful to decide if you want to exclude freshly built servers from your metric while patches are being applied.
- When was the host last seen? - Has the machine been decomissioned? If so, you may not want to incorrectly keep reporting it in the data set.
Vulnerabilities¶
- Is there an exploit? Some vulnerabilities cannot be exploited remotely. Splitting them out is very useful.
- Is there a patch? Not all vulnerabilities can be patched. When driving remediation activities, knowing which vulnerabilities can be patched and which cannot is useful for prioritising activities.
- How critical is the vulnerability? The criticality can also be a good indicator in how quickly an issue needs to be remediated.
- When was the vulnerability discovered on the host? The age of the vulnerability on the host is a good indicator if the patching process is working as expected.
- When was the vulnerability published? Knowing when the vulnerability has been made public can be used to distinguish existing vulnerabilities from newly discovered vulnerabilities.
CVE Database¶
The CVE database is the full list of all known vulnerabilities. You can view these databases online.
Metrics¶
Now that we've talked about what vulnerability management is, let's talk about how we measure it. Having a number of metrics to track will give you a sense of you're succeeding with your process.
In the context of a metric, the word system
can be interchanged with a server
, workstation
, website
, application
, domain
, solution
, network
, or any other descriptor that you'd like to measure.
There are 3 over arching themes when it comes to vulnerability management metrics.
- Coverage - the % of systems within scope that is reporting information. It can also speak to the confidence of the data.
- Posture - a score that represents the risk, or exposure that the organisation may have.
- Performance - a way to determine if the systems are being patched within agreed upon timeframes.
Under these main themes, we have a number of metrics, and sub metrics that can be used.
Category | Metric | Sub Metric |
---|---|---|
Coverage | Systems with VM agent deployed | last seen in 14 days |
last seen more than 14 days ago | ||
first seen 3 days ago | ||
Posture | Systems without vulnerabilities | exploitable and patchable critical and high |
exploitable and patchable | ||
exploitable | ||
patchable | ||
critical and high | ||
Performance | Vulnerabilities not remediated within SLO | exploitable and patchable critical and high |
exploitable and patchable | ||
patchable | ||
critical and high |
Each of the metrics can have the ability to slice & dice the data further.
- Filter data by Internet Facing hosts, Production or non-production systems.
- Filter by criticality.
- Show trends over time to demonstrate the age of vulnerabilities.
Vulnerability Remediation Decision Tree¶
While I am advocating for frequent patching, it does not come without risks. A new update to a piece of software may result in an unexpected behaviour, a change in how the application operates, that can wreak havoc on your operation. It is important to test before you roll it out to production.
Note
Vulnerability and Patch Management DOES NOT supersede your Change and Test Management process. Whatever decision you make will need to align with your internal change managment and testing processes.
Patch immediately¶
Ideally you would patch the system at your next patch cycle. Straight forward, quick and easy.
Patch it later¶
Sometimes you may be in a situation where a system could not be patched in a timely manner. While you may have a monthly patch cycle, you might only be able to patch this system once per year. If a suitable outage time is a concern, you may need to consider mitigation or risk acceptance.
Unable to patch - Mitigation¶
If you are in that sticky situation where your vulnerability tool is flagging an issue, yet some problem is preventing you to patch it, here are a couple of things you can consider.
Think defence in depth...
When we consider mitigation, we look at what the vulnerability is, and if there is any practical way an attacker could leverage that vulnerability against us. For example, if you have a Linux server that is internet facing with a particular kernel bug on its network interface that can result in the RCE (Remote Code Exection) issue to occur, that is quite a serious issue and needs to be addressed. If however that Linux machine is inside a protected DMZ, where only a WAF or a load balancer has access to the web server running on that particular server, then the chances of someone actually exploiting that vulnerability is quite low. What we're getting at, is that there are other controls in place, be it a WAF, or a firewall, or a network security group that is blocking traffic from hitting the server on the particular port that may have the issue. With such a mititation in place, you could argue that while the vulnerabiltiy is important to remediate, there are mitigating controls in place that would prevent the vulnerability from being exploited.
Unable to patch - Risk Acceptance¶
Once scenario that may prevent you to patch is that patching breaks the application. So what do you do?
While it is a little outside the scope of this post, you will need to go through a Risk Assessment process. You will need to document what could go wrong by not patching the system, the potential outages, data loss, or business disruption that could occur.
What other controls do you have in place? The mitigating controls are also useful in determining the likelihood of the risk eventuating.
With everything documented, you must go through risk acceptance. This is the process of presenting the risk to relevant stakeholders for signoff.
Remove the application¶
Through the risk assessment process, it may be deemed the risk is too high, and a decision could be made to replace or retire the application completely. Removing the application will resolve the requirement to patch, however it is likely a more difficult task to achieve.
If removing the application is not possible, revert back to either accepting the risk, or implementing some mitigating controls.
Tools¶
Conclusion¶
Vulnerability management is not just a cybersecurity practice; it's a critical component of safeguarding your organization from ever-evolving threats. By systematically identifying, prioritizing, and addressing vulnerabilities, you can significantly reduce the risk of exploitation and protect your systems, data, and reputation.
As we've explored, the process involves more than just detecting flaws—it requires strategic decision-making based on comprehensive metrics, contextual understanding, and the right tools to ensure an effective and proactive approach. Remember, vulnerability management is a continuous journey that evolves with the threat landscape, and its success relies on consistent monitoring, collaboration, and improvement.
Are your systems prepared to withstand the next wave of cyber threats? Take action today! Assess your current vulnerability management processes, ensure your tools are up-to-date, and start leveraging the insights discussed here to build a resilient cybersecurity posture. For more resources, visit CVE.org or explore tools like Tenable and AWS Inspector.
Secure your organization now—before vulnerabilities become incidents.