Resolve vulnerabilities
When Common Vulnerabilities and Exposures (CVEs) are detected in your software, it is recommended that you perform an impact analysis for the reported CVEs, and then work on how to resolve the CVE.
Follow these guidelines to explore commonly used remediation options to resolve a vulnerability. This article was created to assist you in the event that the CVE description or deployment risk does not provide sufficient information regarding how to resolve a vulnerability in your software.
ヒント
Prioritize resolving vulnerabilities that have the highest potential impact to your most important components and dependencies.
The following remediation options are commonly used to resolve a vulnerability.
Benefits of resolving vulnerabilities
Resolving vulnerabilities helps to:
Minimize exploitation risk
Reduce the chances of attackers successfully exploiting known vulnerabilities.
Maintain security posture
Maintain a more secure environment, especially in the face of emerging threats.
Comply with security standards
Many security standards and regulations require organizations to promptly apply security patches to mitigate risks.
Protect data and systems
Ensure that sensitive data and critical systems are not left exposed to potential attacks.
Prevent spread of malware
Vulnerabilities in software can be exploited by malware to spread and infect other systems. Applying patches helps prevent such outbreaks.
Address known vulnerabilities
Patches directly target known vulnerabilities, effectively "fixing" the weaknesses in the software's code.
Vulnerabilities in your software
Ideally you would scan your software before releasing your software so that you can resolve critical vulnerabilities before making it available for consumption. Below are some factors you may want to consider when deciding how to resolve a vulnerability:
Software update
Release a full update of your software, including the patch and any other improvements or enhancements. This approach ensures that users have the latest version with all the necessary fixes.
Patch
Provide a patch to fix identified vulnerabilities in an existing software version. Patches are thoroughly tested before deployment to ensure they don't introduce new problems.
Virtual patch
Implement a virtual patch as a security measure implemented at the network level or via security software to protect against known vulnerabilities in your software without modifying the software's code itself. Virtual patches detect and block attempts to exploit vulnerabilities before an official patch or update is available. They act as temporary fixes to provide immediate protection until the actual patch can be applied to the software.
Hotfixes
Provide a hotfix which is a type of patch that is released urgently to address a critical issue in the software. Hotfixes are used when a severe security vulnerability or a major bug with significant impact is discovered and needs immediate attention. Unlike regular patches, hotfixes are deployed quickly without waiting for the next scheduled update cycle to minimize the potential impact of the problem.
Security advisories and notifications
Issue security advisories or notifications to inform users about the vulnerabilities, their potential impact, and the necessary actions users should take to protect themselves.
Enhanced security configurations
Provide users with guidance on how to configure the software securely. By adjusting settings and options, users can reduce the risk of exploitation while a patch is being developed.
Collaborate with security researchers
Engage with security researchers who discovered the vulnerabilities to identify issues faster and collaborate on effective fixes.
Redesign and refactor
If the vulnerability is deeply rooted in your software's architecture or codebase, consider redesigning or refactoring the affected components to eliminate the vulnerabilities and improve the overall security.
Deprecation with transition period
If the vulnerabilities are difficult to fix or the software is becoming obsolete, you could announce the deprecation of the software with a defined transition period for users to migrate to a supported alternative.
Segmentation and access controls
Apply network segmentation and access controls to limit the impact of potential attacks by isolating vulnerable components from critical systems.
Education and user awareness
Provide users with educational materials and best practices for using your software securely to reduce the risk of exploitation.
Integration with security solutions
Encourage users to integrate the software with security solutions like antivirus software and firewalls to add an extra layer of protection.
Vulnerabilities in third-party software
Ideally you would scan third-party code before integrating it into your software so that you can make informed decisions about whether you want to consider an alternative or resolve critical vulnerabilities before making it available for consumption. Below are some factors you may want to consider when deciding how to resolve a vulnerability in third-party code:
When you detect a vulnerability in third-party that is integrated with your software, consider the following options:
Upgrade, replace, remove, or uninstall
The choice of remediation action depends on various factors, such as the severity of the vulnerability, the availability of patches or updates, the criticality of the software to your organization's operations, and the feasibility of implementing the chosen solution. The goal is to implement the most effective and efficient remediation strategy to reduce the risk exposure associated with the identified vulnerabilities.
ヒント
To identify known patches for a vulnerability, navigate to your Threat detection report:
Click on the link in the CVE ID field.
Scroll down to References to Advisories, Solutions, and Tools.
Review patches provided in the NVD by different sources.
Possible actions to address the identified vulnerability:
Upgrade
Install a newer version of the software that contains fixes for the identified vulnerability. Software vendors often release updates and new versions that address security flaws found in previous versions. By upgrading to the latest version, you have the assurance that the vulnerabilities have been patched and that you are using the most secure version available.
Replace
When it is not possible or practical to upgrade to a newer version of the software. You may choose to replace the vulnerable software with an alternative product that is not affected by the same vulnerabilities. This action may require you to find a comparable software solution from a different vendor or switching to a different software category altogether.
Remove
Eliminate or disable the specific functionality or feature that contains the vulnerability. This action allows you to continue using the software without exposing your software to the risk associated with the vulnerable part.
Uninstall
Completely remove the software from the system. This action is taken when the software is no longer needed or when the identified vulnerabilities pose significant risks that cannot be mitigated through other means. Uninstalling ensures that the vulnerable software is no longer present on the system and cannot be exploited.
Reconfigure vulnerable software
Make changes to your configuration settings, software setup, or system setup to mitigate or reduce the risks posed by identified vulnerabilities. This is a proactive approach to risk management that aims to reduce the attack surface and strengthen the security posture of the software or systems. It is often used as a temporary or immediate measure while more comprehensive remediation efforts, such as developing and deploying patches or updates, are being implemented.
Reconfiguring your affected software may include:
Security settings
Adjust security settings in vulnerable software to limit access, restrict privileges, or disable specific features that could be exploited.
Access controls
Strengthen access controls to ensure that only authorized users or processes can interact with the vulnerable software.
Firewalls and network configurations
Configure firewalls and network settings to block or filter traffic that could exploit the vulnerability.
Updates and patches
Apply updates, hotfixes, or patches that address the vulnerability and fix the software.
Software versions
Reconfigure your systems to use a different version of the software that is not affected by the vulnerability.
Isolation and segmentation
Isolate the vulnerable software from critical systems or sensitive data to limit the potential impact of an exploit.
Policy changes
Update security policies or best practices to prevent similar vulnerabilities from arising in the future.
Security controls
Use alternative measures or safeguards to mitigate the risks associated with a specific vulnerability when it is not possible or feasible to immediately patch or fix the vulnerability. Security controls are used as compensating controls that are designed to address the specific security concerns posed by the vulnerability. This can vary depending on the nature of the vulnerability and the system it affects. These controls are used as a temporary solution to reduce the risk exposure until a permanent fix can be implemented.
Compensating controls may include:
Tighten access controls
Restrict access to the vulnerable component to only authorized users or IP addresses.
Network segmentation
Isolate the vulnerable component from critical systems and data to minimize the potential impact of an exploit.
注記
Scope measures whether a vulnerability in one system or component impacts other resources beyond its security scope.
Intrusion detection or prevention systems
Deploy systems that can detect and block suspicious activity targeting the vulnerability.
Accept the risk
Risk acceptance refers to a deliberate decision made by an organization to acknowledge and tolerate the potential risks associated with a specific software vulnerability without implementing any specific remediation actions. Instead of attempting to mitigate or eliminate the vulnerability, the organization accepts that it exists and chooses to continue using the software or system despite the identified security weakness.
ヒント
Accepting a risk should be a conscious decision made after careful consideration of the potential consequences.
Risk acceptance should never be used as a default response to all vulnerabilities.
Risk acceptance should be a part of a broader risk management strategy where organizations prioritize and allocate resources based on the severity, likelihood, and potential impact of vulnerabilities to maintain an appropriate level of security posture.
Regularly reassess accepted risks to ensure that changing circumstances do not change your initial assessment that the vulnerability is in an acceptable range.
Common reasons for accepting the risk
Organizations commonly accept the risk associated with a vulnerability due to one or more of the following reasons:
Low impact
The vulnerability has a low potential impact on the organization's operations, data, or reputation. Therefore, the cost and effort of remediation outweigh the potential harm caused by the vulnerability.
注記
Impact measures consequences of a vulnerability being exploited by combining the score of these three factors: confidentiality, integrity, and availability.
Low probability of exploitation
The vulnerability has a very low probability of exploitation or the chances of it being discovered and utilized by treat actors are minimal. Therefore, the probability of a successful exploit of the vulnerability is considered too low to warrant immediate action.
注記
Attack complexity measures the level of difficulty required for an attacker to exploit a vulnerability.
High cost of remediation
The cost of remediating the vulnerability outweighs the potential impact of an exploit. Therefore, the remediation process is too complex, time-consuming, or resource-intensive, and it is economically impractical to address the vulnerability.
注記
Cost-benefit analysis is commonly used to measure if the financial costs of remediation outweigh the impact of accepting the risk.
Impact limited to non-critical systems
The vulnerability is present in non-critical systems or components that do not handle sensitive data or core functionalities. Therefore, the potential consequences of exploitation might not pose a significant threat to the overall security posture.
Interference with business operations
The remediation efforts have the potential to disrupt critical business operations or impact essential services. Therefore, the risk is temporarily accepted while implementing compensating controls or prioritize remediation at a more suitable time to avoid disruption.
Legacy systems or end-of-life software
The vulnerable software is considered legacy or nearing its end-of-life. The risk is accepted because a feasible upgrade or replacement is not readily available.
Risk mitigation measures in place
Compensating security measures are in place that effectively mitigate the potential impact of the vulnerability. These measures could include strong access controls, network segmentation, intrusion detection systems, or monitoring.
Informed risk tolerance
The organization has a specific risk tolerance level that guides decision-making and the identified vulnerability falls within an acceptable risk threshold.
Short-term acceptance
The risk is temporarily accepted while a proper remediation plan is being developed or while you wait for an official patch from the software vendor.