Vulnerability Management Best Practices
The more vulnerabilities that exist in an organization’s systems, the more opportunities an attacker has to gain access and cause harm to the business, its employees, and its customers.
When designing and implementing a vulnerability management process, consider the following best practices.
#1. Perform Regular Vulnerability Scans
Vulnerability scanners are automated tools used to identify potential vulnerabilities and other security risks within an application. Since scans are automated and can be scheduled, they introduce minimal additional overhead for a security team.
Organizations should perform vulnerability scans:
- At regular intervals: Security teams should schedule vulnerability scans at a fixed cadence (daily, weekly, etc.). This helps to identify any new vulnerabilities that’ve been discovered or introduced into their environments.
- Of new software: Before and after deploying a new application, the software should be scanned for vulnerabilities. This helps to ensure that no new security risks are introduced into an organization’s environment.
- When new vulnerabilities are announced: Some vulnerabilities — like Log4j — require immediate action. When a new major vulnerability is announced, an organization should perform an ad hoc vulnerability scan to determine its risk exposure.
When designing a vulnerability assessment program, it’s also important to consider the visibility of various vulnerabilities. Ideally, vulnerability scans will be performed from both outside and inside the corporate network and with varying privilege levels (unauthenticated, authenticated user, administrator).
#2. Apply Patches Promptly
When a software manufacturer becomes aware of a new vulnerability in one of their products, they develop and issue a patch to fix it. Once a patch has been announced and released, cybercriminals could start scanning for and exploiting it within hours.
Organizations should plan to apply patches as soon as possible. Some key elements of a patching strategy include:
- Patch Prioritization: Some patches address critical vulnerabilities, and others may affect high-value IT assets. Patching should be prioritized to maximize the potential impact on an organization’s exposure to cyber risks.
- Patch Testing: Ideally, administrators will test a patch in a realistic environment before rolling it out to production systems. This helps validate the patch’s effectiveness and ensures that it doesn’t introduce new security issues.
- Automated Rollouts: Organizations commonly have many patches to apply, and some may affect numerous systems. Automated patching workflows are essential to rapidly and effectively applying patches at scale.
- Update Validation: After an update has been applied, the patched system should be evaluated again with a vulnerability scanner. This validates that the patch was successfully applied and that no new security risks were introduced.
#3. Perform Risk Prioritization
Nearly all applications contain at least one vulnerability, which means that organizations commonly have more vulnerable systems than they can effectively patch. When deciding where to put their resources and effort, security teams should perform patch prioritization.
As a security team considers when/if to apply a patch, some things to keep in mind include:
- Severity Ratings: Many vulnerabilities have associated common vulnerability scoring system (CVSS) scores that describe how severe the issue is. All else being equal, a critical vulnerability should be patched before a high, medium, or low one.
- System Criticality: Patches may address vulnerabilities in systems with differing levels of importance to the organization. For example, a vulnerability in the organization’s “crown jewel” database may be far more impactful if exploited than a higher-severity one in a less important system.
- Scope of Impact: Some vulnerabilities may exist in a single system, while others could impact the entire organization. Vulnerabilities with a larger number of affected systems may require patching before those that impact only a few devices.
- Resource Requirements: Some patches, such as updates to the Windows OS, are designed to be automated, while others require manual business operations. The impact of a patch should also be weighed against the effort required to apply it.
At the end of the day, an organization won’t (and likely shouldn’t) patch every vulnerability since each one consumes resources that might be used more profitably elsewhere. The decision of what and when to patch should be based on the threat posed by:
- A particular vulnerability
- An organization’s risk tolerance
#4. Manage System Configurations
Some vulnerabilities are created by errors in application code. For instance, SQL injection and buffer overflow vulnerabilities are caused by a failure to follow secure coding best practices. However, other vulnerabilities are introduced when an application is deployed and configured.
New security vulnerabilities can be introduced by:
- Weak passwords
- The use of default settings
Organizations can manage this by defining and enforcing the use of a secure baseline configuration for all corporate applications and systems. The use of this baseline should be enforced via regular audits and configuration management systems.
#5. Leverage Threat Intelligence
Threat intelligence provides insight into the threats and cyberattack campaigns that an organization is most likely to face. If other organizations in the same industry, jurisdiction, or size are being targeted by a particular threat, it’s likely that your business will as well.
Threat intelligence can be invaluable for prioritizing vulnerability remediation and mitigation efforts. Vulnerabilities that are experiencing active exploitation should be patched immediately if possible.
If no patch can be applied, the organization should implement monitoring and any preventative measures available to reduce the risk of exploitation.
#6. Integrate with Incident Response
Vulnerability management and incident response are related and complementary efforts.
Ideally, vulnerability management negates the need for incident response by eliminating security risks before they can be exploited. However, this is not always the case.
In the event that an organization suffers a cyberattack, access to vulnerability management data can expedite the incident response process. If the incident response team (IRT) is aware that a particular vulnerability exists in an organization’s systems, this might expedite root cause analysis and remediation efforts.
On the other side, intelligence from incident response can also inform vulnerability remediation efforts.
Incident responders might identify unknown vulnerabilities or find that an unmanaged one is experiencing active exploitation. This data can help the security team address high-risk vulnerabilities and update its risk prioritization to prevent similar incidents from occurring in the future.
#7. Embrace Continuous Improvement
Vulnerability management is an ongoing process for most organizations. New vulnerabilities are being discovered and disclosed every day, so most security teams have a constant backlog of vulnerabilities to assess and patches to apply.
Since eliminating vulnerabilities entirely likely isn’t an option, security teams should focus on trying to improve their vulnerability management programs over time.
Some metrics to consider include:
- Number of vulnerabilities that reach production systems.
- Average time to identify a new vulnerability.
- Average time to patch a vulnerability.
- Average time to patch a critical or high-severity vulnerability.
- Total number of vulnerabilities in production systems.
#8. Consider Compliance Requirements
Companies need to consider a range of regulations and standards when developing their security and vulnerability management programs. Exploited vulnerabilities are a common way that sensitive data is breached, and companies need to manage these risks.
When defining patch management plans and processes, security teams should consider the types of data processed by various systems and their regulatory implications.
For instance, some systems may need to be prioritized in the patching process due to compliance requirements.
Feedback