Vulnerability Remediation: Tutorial & Best Practices

Vulnerabilities refer to security gaps or weaknesses within a system that you can leverage to undermine application availability, function integrity, or data confidentiality. An application’s attack surface encompasses all potential entry points or attack vectors that threat actors use to exploit the vulnerability. Your application’s attack surface grows in tandem with application functionality and interaction points. Attack surface growth is often multi-faceted across your organization due to the release of multiple applications by different development teams, possibly utilizing distinct programming languages and frameworks.

Poor inventory management, competing priorities, and resourcing challenges make vulnerability remediation challenging across a diverse and ever-expanding attack surface. The challenge is compounded when considering the financial implications of data breaches.

Market analysis shows that security breaches are on the rise. Attackers take advantage of high-impact vulnerabilities, frequently crafting or utilizing exploits on the same day a CVE is published. However, attackers are aware of the challenges in remediating vulnerabilities at scale and do not hesitate to leverage previously reliable exploits, especially with high-impact vulnerabilities. Therefore, you must be equipped to remediate the growing number of vulnerabilities identified by your security teams. This article explores some of the challenges, how vulnerability remediation has evolved, and the solutions and best practices you could deploy to improve your organization’s security posture. Please read our guide chapters on vulnerability management and prioritization for more context.

Summary of key vulnerability remediation concepts

Vulnerability remediation challenges

Vulnerability challenges revolve around the issue of multiple data sources, separate lifecycles, and silos created by teams managing vulnerabilities independently without a holistic view. Security teams deal with resource constraints both in identifying vulnerability priorities and communicating risks to business and remediation owners.

Scaling vulnerabilities

Within your environment, you’re likely facing vulnerabilities that are identified through multiple sources, such as source code, cloud components, network devices, and other assets. As vulnerability classes and numbers grow, so does the infrastructure used to identify them. Different vulnerability classes are often discovered through dedicated tooling that specializes in those classes. Acquiring a reliable understanding of your security posture becomes difficult due to the combination of multiple tools with varying vulnerability reporting formats being stitched together.

Prioritization challenges

Additional vulnerabilities are identified as your application(s) evolves and grows code base, dependencies, and resource connections, but older vulnerabilities reside in non-remediated states. It can be cumbersome to acquire a clear understanding of where you should focus your efforts. Organizations often prioritize vulnerability remediation based on technical severity. However, risk-adjusted values, relationships between vulnerabilities, and aggregate risk should also be considered. The security industry is maturing and has developed the Stakeholder-Specific Vulnerability Categorization (SSVC) to improve prioritization efforts.

Tracking risk posture

In an ideal case, remediation would be the chosen approach; however, this is not always possible in alignment with organizational risk appetite. For example, a penetration tester reports a vulnerability and determines that the severity has been underreported. Due to the resources required to deploy the fix, the security team determines that a WAF mitigation ruleset is an adequate compensating control to mitigate the risk. However, the state of this vulnerability must be tracked to ensure that it’s monitored and that risk exposure does not exceed the organization’s risk appetite.

{{banner1="/banners"}}

Approaching vulnerability remediation

Once a vulnerability has been identified, remediation is the primary goal as long as it is practical. In the past, vulnerabilities were generally focused on a single application and were the responsibility of the application security engineers. In today’s applications based on microservices and a web of interconnected APIs, it’s common to see vulnerability remediation initiatives crossing organizational boundaries leveraging a blend of software, database, site reliability engineers (SRE), and the security team.

Automated approaches

Up until recently, patching and vulnerability remediation were primarily seen as manual processes. Solutions today use automation to improve scalability so that engineers can orchestrate patching across the estate without manual intervention on an assets-per-asset basis. Analytics have enabled static source code analysis (SAST) and software composition analysis (SCA) tools to provide automatic auto-fix capabilities. Automated solutions are best suited to vulnerability classes where the remediation process is:

• ​​Well-defined and does not require extensive codebase changes
• Consistent between instances
• Independent specific vulnerability circumstances
• Evaluated to determine functionality disruption or resource availability

Examples include third-party dependencies, configuration flaws, and common coding vulnerabilities. They reduce user error across patches and ensure remediation consistency.

Manual approaches

Vulnerabilities that require an understanding of business logic, Service Level Agreements (SLA), or architecture details are generally remediated through manual intervention. In such scenarios, automated mechanisms are not mature enough to take the broader context into account and may cause issues downstream. Instead, security engineers work with relevant stakeholders to determine a fix that remediates the vulnerability but also aligns with other functional and non-functional requirements

An example could be an organization facing issues with unauthorized access due to poor verification of JSON web signatures (JWS) claims on their platform. Multiple services process the same token in this case, and verification must be consistent across the vulnerable platform. To do this, engineers collaborate and implement a single solution that can be leveraged across multiple services. They manually deploy new services or implement libraries with application programming interfaces (API) that other teams can easily integrate with.

{{banner2="/banners"}}

Vulnerability remediation best practices

Some key best practices in modern vulnerability remediation efforts are given below.

Centralize management

Large-scale vulnerability management in an enterprise environment requires a centralized view for complete context and end-to-end visibility for security teams. A centralized view is created by integrating with popular tools that discover vulnerabilities in various application environment tiers like networks, databases, and application source code.

Centralized management allows security teams to manage vulnerabilities based on a combination of business risk and technical risk, providing a more accurate reference for remediation prioritization. Engineers can adhere to compliance standards and formulate remediation strategies more systematically.

The Silk platform allows users to maintain an end-to-end view of the vulnerability management lifecycle powered by effective and accurate vulnerability remediation prioritization.

Standardize processes

Standardizing vulnerability information across sources provides a scalable mechanism to improve security posture. A centralized location for reporting vulnerabilities allows you to follow consistent workflows for all vulnerabilities, regardless of source. Engineers can maintain consistency by standardizing how they track and report on vulnerability classes, team remediation activity, task status, and service level agreement (SLA) timelines. Some examples of rules could be as simple as ensuring that all reported vulnerabilities are tied to an asset and have a severity and an assignee assigned. More complex rules can ensure that if a vulnerability is “accepted,” it can be automatically placed in the backlog after a severity-dependent timeframe. For more concrete implementation examples, read about Silk's remediation campaigns that offer flexible automation, bulk ticketing, and custom logic.  

Enable collaboration

The vulnerability remediation process should enable collaboration between all stakeholders since system configuration changes could affect application functionality and performance. Tracking the vulnerability status is vital for scenarios where remediation requires multiple cross-system changes.

You must also assign the correct asset owners with the relevant knowledge for remediation. Silk stands out in aggregating vulnerabilities away from the identification process and associating them with issue tracking and asset owners.

{{banner3="/banners"}}

Measure progress

Metrics are vital for assessing, monitoring, and strategizing across various aspects of operations. They allow stakeholders to measure performance, make data-driven decisions, and manage risks and other resources. Some KPIs you can consider in your vulnerability remediation program include:

• Mean time to detect (MTTD): MTTD can be defined as the duration of time between the creation of a vulnerability and its discovery. MTTD can be calculated on a case-by-case basis but is also valuable at a macro level. The equation below calculates MTTD across multiple vulnerabilities:

MTTD = (Total Sum of Detection Time) / (Total Number of Vulnerabilities)

• Mean time to remediate (MTTR): This is often supported by a Service Level Agreement (SLA) provided to customers as part of your vulnerability management policy. Once a vulnerability’s severity has been assigned, it continues to dictate the timeframe that you use for implementing mitigation or remediation controls.
• Average vulnerability age: In combination with MTTR, average vulnerability age is often used for tracking risk exposure due to 3rd party risk. It refers to the duration of time since a vulnerability’s public disclosure. This ensures that remediation strategies are aligned with business SLAs.
• Rate of recurrence: The recurrence of a remediated vulnerability on an asset could potentially signal an issue with the baseline configuration. Continuously monitoring the recurrence rate allows your engineering teams to scrutinize process errors or system misconfigurations.

Prioritize high-impact remediations with asset linking

Remediation efforts often target specific vulnerabilities without addressing the underlying issues that give rise to these vulnerabilities in the first place. This isolated approach leads to an increase in vulnerabilities as application features expand, creating a bottleneck for remediation teams who must grow to keep pace with the rising number of issues and meet (MTTR) objectives.

To effectively counter this issue, it's essential for teams to uncover the fundamental causes and implement comprehensive measures to prevent them from recurring. The root cause analysis requires a knowledge of the interconnected components, including both internal assets and external elements like third-party libraries or vendors.

Silk Security offers an asset-linking feature that enables teams to gain a contextual perspective on a given vulnerability, including its cause-and-effect relevance to similar issues across the enterprise environment. Establishing and maintaining relationships between assets and vulnerabilities saves much time and effort compared to manual root cause analysis. This approach also helps the security team prioritize the remediations with the highest impact across the most critical applications.  You can learn more by reading this article about driving high-impact risk remediation with Silk Security’s application asset linking.

{{banner4="/banners"}}

Last thoughts on vulnerability remediation

The article has described the importance of a vulnerability remediation program, some of the challenges you might face, how to tackle them, and best practices you can implement going forward.

An efficient vulnerability remediation program ensures that you are taking appropriate steps to address vulnerabilities that are the most likely to affect your business negatively. It allows key stakeholders to define key performance indicators (KPI) and measure progress across the business. Additionally, it takes the dynamic nature of modern technology companies into account, by fostering collaboration between teams without creating bottlenecks.