Free Book - External Exposure & Attack Surface Management for Dummies
Vulnerability remediation is the process of identifying and neutralizing security issues affecting cyber assets. Because these issues can cause millions of dollars in lost revenue, remediation costs, or fines if they result in a data breach or damage to cyber-infrastructure, vulnerability remediation is one of the most important parts of cybersecurity.
A cybersecurity vulnerability is a flaw that affects assets in technical environments – like web applications, servers, Internet of Things devices, or firewalls – that could be exploited by an attacker.
Vulnerabilities are officially documented by the National Institute of Standards and Technology (NIST) in their National Vulnerability Database (NVD). Each vulnerability is assigned a Common Vulnerability and Exposure (CVE) identifier, given a technical description, and assigned a severity score, also known as a Common Vulnerability Severity Score (CVSS) on a scale from one to 10. A score of 10 is the most serious and scores of 9-10 are reserved for critical severity vulnerabilities.
These issues can allow cybercriminals to access, alter, or exfiltrate valuable data or siphon resources like computing power or money from organizations. Because so many parts of cyber infrastructure are connected to each other, even seemingly innocuous vulnerabilities can allow attackers to get a foothold into a network. In 2019, the Ponemon Institute revealed that 60% of breaches occurred because of known but unpatched vulnerabilities.
Remediation is the process of remedying an issue or fixing a problem. In cybersecurity, remediation usually refers to the process of patching or otherwise resolving software vulnerabilities. These vulnerabilities can be remediated by completely removing the threat to an asset or system. In some cases, remediation may not be possible immediately or ever, and so threats can be mitigated, lessening the threat without removing it entirely.
While some vulnerabilities are fairly straightforward to remediate through applying available security patches, other issues may require delicate orchestration of multiple components while preserving necessary software functions. Security teams also have to consider when to patch affected assets or systems to ensure that customers aren’t surprised by outages or coworkers don’t experience unexpected delays due to critical applications being pulled offline.
Now it’s time to focus on vulnerability remediation – taking the issues that affect your most important assets and fixing them. But how does the process work in practice?
Vulnerability remediation begins before the actual process of fixing issues attached to assets. The first steps of vulnerability remediation actually involve identifying the assets in your scope of concern, testing them for issues, and prioritizing those issues.
The first step to identifying vulnerabilities is discovering and classifying all your assets. Skipping this step or failing to identify all assets could result in major blind spots across your attack surface. As part of this discovery process, collect context about the assets, including technical details about the assets, what software versions are running, who the organizational owner is, if an exposure puts important data at risk and how discoverable and attractive it is to attackers. This information will help when prioritizing vulnerabilities.
After finding and indexing all assets, the next step is actively testing for vulnerabilities that could provide attackers footholds into your external attack surface. Because testing can be both technically difficult and time-consuming, many organizations fail to actively test all their assets for a wide range of vulnerabilities, instead resorting to only passively scanning a subset of assets. However, this type of passive scanning can only find a limited range of vulnerabilities, potentially missing critical issues. Automatic active security testing capabilities, like ones offered by the CyCognito platform, automate this process and perform it at scale, allowing organizations to identify a wide range of issues across more of their attack surface than could ever be reasonably achieved manually.
Because the attack surface is constantly changing, it’s crucial to continuously check for new assets and vulnerabilities to ensure dangerous vulnerabilities are not lurking on unknown or under-managed assets.
Once you have fully indexed your assets and understand the issues affecting them, you are probably left with hundreds or thousands of issues to sort through. Simply starting at the top of the list is likely to miss critical issues, leaving major risks exposed to attackers.
Prioritizing which vulnerabilities to tackle first requires understanding more than just the CVSS score of each issue. Incorporating additional context, like how attractive the affected asset is to attackers, whether threat actors are actively exploiting the vulnerability, and what other assets could be accessed through exploitation, can highlight issues that may have otherwise been neglected by just prioritizing by CVSS score.
This type of context should be gathered in the “Identifying Vulnerabilities” step, but solutions like CyCognito that automatically collect and incorporate this data into the prioritization process can save time and effort.
Finally, having identified, tested, and prioritized the security vulnerabilities affecting your assets, your team is ready to start the process of remediating these vulnerabilities. As the section “What is Remediation in Cybersecurity?” above explained, vulnerability remediation is not as straightforward as it sounds. Now that you’ve identified the basic processes of vulnerability remediation, the next step is to create a vulnerability management program.
Vulnerability management programs go beyond the initial process and incorporate best practices like measuring and reporting vulnerability remediation metrics, automatic processes to accelerate remediation times, and validating fixes after they’ve been implemented.
The next sections of this article will outline key tips and metrics you can use as part of your continuous vulnerability management program. However, it’s important to remember that this is an ongoing process that requires continuous monitoring and assessment to ensure that your organization addresses emerging threats effectively.
The success or failure of a vulnerability remediation process can be measured in a number of different ways. The examples below are not exhaustive, but show the types of metrics that teams can consider as they build their vulnerability remediation process.
Many security teams are measured on their Mean Time to Remediation (MTTR) – the average time between when the security team discovers an incident and when that incident, and the associated vulnerability, is remediated. Keep in mind that vulnerability remediation timelines should also take into account the time it takes to test and validate any fixes, document actions, and communicate with stakeholders.
The time to remediate a vulnerability may be affected by compliance requirements around the asset or issue, the availability of patches to address the vulnerability, the criticality of the affected system, and availability of resources. Teams also frequently have different vulnerability remediation timeliness depending on the exposed risk of the vulnerability.
Another way that MTTR can vary is according to the Service-Level Objective (SLO) for different types of vulnerabilities. An asset with a zero-day exploit is by definition in danger of exploitation as soon as it is discovered, so it is often critical for teams to remediate these types of high risk vulnerabilities as quickly as possible. For less severe vulnerabilities, turnaround times can be longer, depending on the resources at the team’s disposal and competing priorities. Most teams will have different MTTR goals depending on SLO, which may incorporate CVE severity or number of critical assets affected.
Another useful metric is the number of times a vulnerability is patched and is still found on subsequent scans, also known as rate of recurrence. A high rate of recurrence can indicate issues with your vulnerability remediation process or problems with the way your vulnerability remediation tools are configured. We’ll talk more about the recurrence of vulnerabilities in the “Make Remediation Validation the Final Step” section below.
There are a number of challenges that can impact vulnerability remediation efforts. We already discussed the difficulties that can come with identifying potentially affected assets, testing for vulnerabilities, and prioritizing which vulnerabilities to focus on remediating, but other issues can also negatively impact vulnerability remediation.
Resource constraints: limited budget and personnel hours can delay the implementation of needed security measures, sometimes indefinitely.
Legacy systems: if critical systems have reached end of life (EOL) but are still in use, any additional security issues that affect those systems will have to remain unpatched.
Zero-day vulnerabilities: also known simply as zero-days, these urgent issues are already putting your resources at risk the moment they are discovered. If they’re found before a patch is available, security teams need to get creative with how they protect affected systems.
Attack complexity: some vulnerabilities are entwined with other software or systems, resulting in a comprehensive approach to remediation that may involve additional teams.
Communication: effective remediation often requires many individuals and teams working together to ensure vulnerabilities are addressed quickly and efficiently. Confusion about responsibilities, the scope of issues, or prioritization can result in delays.
The tips below can help you and your team address these challenges and build a more efficient process that follows vulnerability remediation best practices.
It may seem basic, but ensuring that your organization prioritizes vulnerability remediation helps ensure that your team is given the time and resources to fix your most critical high risk vulnerabilities. Some organizations may have specific regulatory requirements that mandate critical issues be fixed within a particular time frame, but unpatched vulnerabilities can expose risk to any business.
When incidents happen, it can create an environment of urgency (even panic!). While it may feel like a delay to create a clear vulnerability remediation policy, including best practices and procedures to follow in an emergency, by anticipating issues and doing some legwork up from, you can save time in the long run.
For example, when a new CISA advisory is released, you may get an email from the C-Suite asking “are we on top of this? Do we have any assets that are affected?” Checking your entire attack surface for affected assets ensures that you aren’t missing any IPs, certificates, web apps, or domains that could still be vulnerable, giving attackers a foothold into your organization. However, it’s important that your vulnerability remediation timelines give your team space to take a short time to understand the vulnerability, including whether any exploits are available or whether attackers in the wild have been using these exploits targeting organizations like yours. This information, gathered according to your organization’s vulnerability remediation timelines best practices, can also inform your plan of action. Finally, make sure you understand what steps need to be taken to patch the vulnerability across all affected assets.
Creating vulnerability remediation policy will also make it easier to implement the next tip: communicating with your partner teams.
Have you ever heard the saying “don’t bring me problems, bring me solutions”? It’s true in vulnerability remediation too. Once issues are discovered, communication between teams can be one of the biggest vulnerability remediation challenges. Poor communication or inconsistent priorities can slow work to a crawl.
Before contacting another team and tasking them with remediating a vulnerability, take the time to document vital information about the incident and which parties are responsible for various parts of the vulnerability remediation process. Having easily accessible documentation on issues, including the priority level, validation that the issue exists, and details on which team or business subsidiary is responsible for maintaining the affected asset, can reduce back-and-forth communication between different teams.
Another way to improve communication is to create automatic workflows that involve the security and task management programs and vulnerability remediation tools that your partner teams are already using. If your IT Operations team uses Jira exclusively and is always asking you to fill out a ticket, use the communication method they prefer. To make it easier on your end, use workflows and integrations, like the ones in CyCognito’s EASM platform, to automatically export critical information into whatever platforms you need.
Reporting on vulnerability remediation efforts can serve multiple functions. Having a centralized dashboard that automatically collects and displays vital vulnerability remediation key performance indicators (KPIs) can help security teams keep track of their impact. The dashboard below appears in the CyCognito platform and contains metrics related to the average MTTR and the average age of issues in the attack surface, tracked by month and by subsidiary within the organization. It also breaks issues out by issue severity to better track remediation times within SLOs (discussed above in the section Determine Service-Level Objectives).
Fig. 1: A sample CyCognito Remediation Tracking dashboard, showing metrics related to issue age and MTTR
Teams also use reporting to automatically generate reports for team leaders or the C-Suite. These reports can highlight progress towards specific KPIs or quickly sum up the severity of cybersecurity issues affecting the organization. Designed to be high-level and produced on a monthly or quarterly basis, automatically generating these reports demonstrates the work your team is doing to keep the organization’s resources safe.
Fig 2: A sample report generated by the CyCognito platform, demonstrating metrics related to shadow risk and cloud assets
Sometimes, the business needs of your organization make implementing a security fix difficult or impossible, at least in the short term. In these cases, security teams can use compensating controls – procedures that outline what to do if immediate remediation is not an option – to mitigate the impact of vulnerabilities without fully remediating them.
Some industries, like the financial sector, have specific regulations that govern vulnerability remediation. According to the Payment Card Industry (PCI) Security Standards Council (SSC), payment card institutions are allowed to implement compensating controls "due to legitimate and documented technical or business constraints” that prevent them from immediately patching vulnerabilities.
For another example, consider a hospital: if their security team finds a zero day exploit that affects their ventilators, it isn’t practical to immediately take those vital medical devices offline to patch them. In this case, it is important to develop compensating controls. The hospital may choose to disconnect the machines from the network to ensure they cannot be exploited by outside actors until they can be taken offline and updated.
If your organization has business critical resources that could be affected by severe exploits, consider documenting compensating controls that would allow the organization to continue to function while minimizing the exposed risk of the vulnerability.
One of the biggest vulnerability remediation challenges is ensuring that the job is actually done. Before jumping into action, it’s important to validate critical details about the incident by having documentation that the issue exists, that it's affecting assets in your external attack surface, and that the proposed fix will actually solve the problem.
After action, it’s tempting to move on to the next vulnerability (and there is always another vulnerability waiting) but before switching gears, take time to validate that the issue was actually resolved. One common step that is often overlooked is the need to restart the application for the patch to be successfully implemented. If this step is missed, the effort to coordinate and apply the fix has no effect.
Fig. 3 An example of the revalidation feature in the CyCognito dashboard.
To do this at scale, it’s helpful to have an automatic revalidation system, like CyCognito’s in-platform issue revalidation feature, but even checking by hand can save your team future headaches if it turns out that the fix needs a little bit more tweaking.
If your team has implemented these steps and wants to bring your vulnerability remediation to the next level, consider monitoring your external attack surface with CyCognito. Check out our website and explore our platform with a self-guided, interactive dashboard product tour. If you’d like to chat to an expert about external risks that might affect your organization, you can schedule a demo at https://www.cycognito.com/demo.