How Soon Should Vulnerabilities Be Patched?

If you've worked in security for more than a minute, you know vulnerability and patch management are important.

Having vulnerabilities is like leaving the front door open when you leave for work. Just because the door is open doesn't mean you're in trouble, but it does make it easier for someone to wander in and grab your grandma's secret cookie recipe. 🍪 So, we know closing the doors is important.

But what does that mean exactly? How soon do you have to patch vulnerabilities in order to be compliant and secure? Let's find out.

What vulnerabilities are we talking about here?

For the purposes of this blog, I want to define a vulnerability as a weak point in a technical system.

This high-level description aligns with NIST's definition (which was adopted by the FFIEC). It says a vulnerability is a:

"Weakness in system security procedures, design, implementation, internal controls, etc., that could be accidentally triggered or intentionally exploited and result in a violation of the system's security policy."

The reason this clarification is important is because there are a lot of types of vulnerabilities out there (e.g., humans are vulnerable, paper documents are vulnerable, etc.) and as much as you might want to, you can't patch a person. Because of this, we're going to focus on technical vulnerabilities which can be patched. All clear?

How can I know if my systems are vulnerable?

You can't patch invisible holes. Because of this, step one is to figure out if your systems are vulnerable in the first place. There are a few popular ways to spot vulnerabilities:

• Security Assessments: Use a tool to perform automated vulnerability scans and/or hire a vendor to perform a scan or a penetration test. If you want to get really wild, you could even venture out into the world of "threat hunting." If you are unsure what type of test you need, I recommend this article by CoNetrix on How to Choose a Pen Test.
  
  
• Vulnerability Databases: Check your systems for known vulnerabilities using lists published by reputable agencies.
  
  
  • NIST National Vulnerability Database (NVD)
  • CISA Known Exploited Vulnerabilities (KEV) Catalog
  • MITRE Common Vulnerabilities and Exposures (CVE) List
    
    
• Threat Intelligence Feeds: Monitor security information sources (e.g., information sharing and analysis centers (ISACs), third-party alerts, news sites, etc.) or subscribe to a threat intelligence platform to get real-time vulnerability data or alerts.

The possibilities are endless. The key is finding out which options work best for you.

Are there patch timeframe guidelines?

There are some recommended (and sometimes required) patch timeframes, often based on the vulnerability's Common Vulnerability Scoring System (CVSS) severity level and the nature of the entity. For example:

• The CISA Security Requirements for Restricted Transactions require all organizations performing restricted covered data transactions to patch known exploited vulnerabilities (KEVs) in internet-facing systems within 45 calendar days.
  
  
• CISA Binding Operational Directive 19-02 requires federal agencies to remediate "Critical" vulnerabilities in 15 days and "High" vulnerabilities in 30 days of initial detection.
  
  
• FedRAMP requires cloud security providers who want to work with federal agencies to remediate "High Risk" vulnerabilities in 30 days, "Moderate" vulnerabilities in 60 days, and "Low" vulnerabilities in 180 days of discovery.
  
  
• PCI DSS requires entities involved with payment processing to patch "Critical" vulnerabilities within one month of the patch release date (Requirement 6.3.3).
  
  
• The CIS Controls recommend remediating vulnerabilities on a "monthly, or more frequent, basis" (Safeguard 7.7 Remediate Detected Vulnerabilities).
  
  
• The State of New Hampshire requires entities operating state network resources to patch "Critical" vulnerabilities "immediately upon availability of patch," "High" vulnerabilities in 15 days, "Medium" vulnerabilities in 30 days, and "Low" vulnerabilities in 90 days.

Why are patch timeframes problematic?

While patch timeframes are well-intended and can help enforce timely remediation, they introduce their own set of challenges.

• Inconsistent requirements. Since there is no objective standard for patch timeframes, the requirements can often conflict with each other, leading to confusion, compliance challenges, and security gaps.
  
  
• Operational disruptions. Rushing to patch within a rigid timeframe can lead to instability or even downtime, especially for high-risk systems which need extensive testing before patch deployment.
  
  
• Misallocated resources. Just because a vulnerability is "Critical" according to its CVSS score doesn't mean it is critical for you. What if the vulnerability is on a low-risk system as opposed to a high-risk system? Expecting the same resources to be applied to mitigate the vulnerability could result in misused resources, which are likely already limited in the first place.
  
  
• Compliance culture. Ticking a patch timeline checkbox means focusing on compliance over security. What if a patch isn't available by the deadline? What if patching isn't the best option? What if other compensating controls may be better? What if the vulnerability is in an end-of-life system and there won't be a patch? In a compliance mindset, applying the patch is the most important thing. In a security mindset, protecting the system is the most important thing.

In cases where patch management hasn't been a priority, timeframes can give people a north star. However, for organizations where security is part of the culture, patch timeframes may result in more harm than good.

This is why we are beginning to see agencies shift towards the idea of risk-based vulnerability remediation.

What is risk-based vulnerability remediation?

Risk-based vulnerability remediation is a holistic approach to security. It recognizes that patching may not be the only solution for a vulnerability. Even if it is the best response, patches need to be applied in a systematic manner via the organization's change management process.

This approach is encouraged by several agencies.

• The CISA Cross-Sector Cybersecurity Performance Goals (CPGs) recommend critical infrastructure sectors remediate known exploited vulnerabilities "within a risk-informed span of time" (1.E Mitigating Known Vulnerabilities).
  
  
• While the CISA Security Requirements for Restricted Transactions have a brightline of 45 days, they also encourage patching within a "risk-informed span of time, prioritizing the most critical assets first" and encouraging organizations to "implement alternative compensating requirements, should patching not be feasible" (I.A.3).
• The FFIEC Architecture, Infrastructure, and Operations Booklet encourages "timely remediation, according to the risk associated with the vulnerability" (VI.B.3(a) Vulnerability Management). This idea is echoed in the FFIEC Information Security Booklet (II.C.10(d) Patch Management) and the recent FFIEC Development, Acquisition, and Maintenance Booklet (VII.B Change Management).
  
  
• Perhaps most notably, the NIST SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning is designed around the idea of risk-based vulnerability remediation. This publication focuses on the idea that patch management is only one form of risk response, and it explains that organizations may choose to respond to vulnerability risks in a variety of other ways (e.g., accept, transfer, mitigate, avoid, etc.).

Risk-based vulnerability remediation involves taking a look at the bigger picture and making a plan for security that goes beyond patch timeframes. It involves looking at not just a vulnerability's severity, but at the environment in which the vulnerability exists.

To quote NIST's Guide to Enterprise Patch Management Planning:

"Installing a patch or update or upgrading software to a newer version without the vulnerabilities are the only forms of risk response that can completely eliminate the vulnerabilities without removing functionality. However, immediately patching, updating, or upgrading vulnerable software is sometimes not viable."

In short, patching is a good idea. In fact, it's necessary for security. However, there may be better options for security and resilience than adopting a "patch as soon as possible" approach.

How can I take a risk-based approach to vulnerability management?

If you're looking to get away from patch timeframes and manage vulnerabilities holistically:

• Start by looking at your policies (e.g., vulnerability and patch management policy, change management policy, security testing policy, etc.). Make sure your policies provide room for adopting a risk-based approach to vulnerability management. If you're not sure what your policies should say, check out Tandem Policies. Our ready-to-tailor template policies are aligned with industry best practices and guidance and give you a great place to get started.
  
  
• Make risk-based decisions a habit. Not every vulnerability is an emergency. Get used to asking questions like, "How bad is this? Can it actually be exploited? What is the real risk we're facing?" When you do, security becomes smarter, not just faster.
  
  
• Begin thinking outside the box. Instead of scrambling to patch on a schedule, be open to other options. Look at what controls you have in place right now. Determine if there are compensating controls you can implement. Consider enabling automatic patching on low-risk systems. Fix the right things without disrupting everything.
  
  
• Ask for help from your service providers. Your managed service provider (MSP), security service providers, and consultants are ready to help. If you're looking for someone to help you with risk-based vulnerability management, check out our list of Tandem Partners.

Vulnerability management works best when it is performed in the context of your business. See how Tandem can help you better manage your organization's cybersecurity compliance activities at Tandem.App.