Guidance to Improve Patching and Vulnerability Management

August 31, 2023 | By IANS Faculty

The core idea of patching timelines is very old and is based on the idea that vulnerabilities should be addressed in a priority order. This pattern was then picked up by the PCI standards which became a common requirement.

However, the technical drivers behind the pattern have changed and it is time for practices to change as well. This piece details how to succeed against today’s adversaries by making serious and significant patching changes in your environments and practices using automation of deployment and testing.

Patching Automation Issues

Patching has gotten safer as vendors have split feature releases from security patches, making patching itself less risky, and reducing the justification of pushback from internal teams. At the same time, automation technology has made patching easier. On the detection side, environments have grown significantly more complex, potentially reducing the validity of a “critical” or “high” finding, while attacker capabilities have increased, allowing automated analysis of patches to find areas to target and the ability to rapidly chain lower-severity issues together into a more-significant concern.

All told, this means the factor of concern is no longer patch severity but is, instead, exploitability.

Patching Exploitability and Psychological Pinning

It’s common to see tables like these in vulnerability management programs, with the one on the right being far less common but important in organizations that are attempting to modernize but still constrained to contracts and standards with a patch timeline concept. (See Table 1)

The problem is that even if you are setting an expectation that 95% of critical findings are to be patched within 10 days, leaving a buffer for more complex issues, the way such a rule is interpreted by most people is that patches do not need to be deployed until Day 9. In more mature organizations, they may take the form of patches being delayed to the next weekly patch window, still within the SLA. This is the psychological concept of “pinning,” where if someone hears that “high vulnerabilities should be patched in 30 days,” they are much more likely to deploy the patch on Day 28 than they are on Day 2. After all, on Day 2, there’s a lot of time before they have to do it. This means whatever the timeline says, all you’re doing is giving more time for attackers to target the issue. The correct table should look like this:

This table is obviously not very useful in a business context, but illustrative of the core conflicts we face.

Patching Core Conflict

The fundamental conflict of patching is that we (1) accept the fact that humans aren’t error-proof and they’ll make mistakes, and (2) that we somehow believe they’ll fix their errors correctly in a patch.

The fundamental conflict of vulnerability scanning is that we (1) accept the fact that companies that focus on finding flaws in software are good at what they do, with collecting data from third parties to scan our environments, and (2) we somehow believe that scanners will find and report the issues to us so they can be fixed before the attackers can take advantage of them.

These conflicts are nonsensical, but they underpin the common business practice of patching within time windows, meaning the entire practice is built like a house of cards, ready to topple with the first faulty patch or zero-day exploit, which are on a significant rise, as seen in Figure 1.

Worse, we have a fundamental conflict with exploitation as well, where we simultaneously believe that attackers are (1) supremely skilled and can release working exploit code quickly after a patch is released, and (2) utterly incompetent and won’t be able to compromise our systems within the patch windows, ignoring all evidence of zero-day attacks and vulnerability chaining.

Using a Risk-Based Approach to Patching

We see a lot of claims around organizations taking a “risk-based approach” to vulnerability management, coupled with a timeline table. Clearly, the risk they’re addressing is “risk of not meeting the SLA” as opposed to “risk of compromise.” Taking a true risk-based approach to vulnerability management requires a focus on automation, contextualization and compartmentalization. Putting any timeframe at all on a manual patching process—whether it involves scheduling and vetting—just serves to delay the one critical action: making a potentially vulnerable system unable to be compromised from a known attack.

Pushing the timelines without investing in the ability to automate patching—including deployment along with automated testing, rollback and configuration of compensating controls—only serves to burn out the team, causing people to leave, which makes it even harder to meet the arbitrary timelines, while also making it harder to adopt the automation and infrastructure redesigns needed to support the contextualization and compartmentalization practices needed to support a nimble automation model.

Vulnerability and Patching Best Practices

For this to work, you need to fundamentally rethink how you handle vulnerability management and move beyond basic patching:

  • Truly segment your environment: Segmentation makes it harder to chain vulnerabilities, microsegmentation and zero trust make it much harder.
  • Invest in testing: You need the ability to quickly verify that an altered system can perform its functions. This means a significant investment in testing multiple scenarios. This cannot be done manually if you want to scale.
  • Consider blue/green environments: In a blue/green environment, you can flip between systems/configurations quickly to deploy patches in real time without downtime and with verification. This design is critical for rapid vulnerability management.
  • Pre-analyze contexts: When a high-profile patch comes out, it is too late to determine which systems are at risk. The systems should already be contextualized, so you can—within minutes—understand the impact on your environment and schedule the automated patch test process before the attackers do.
  • The attackers are significantly more invested in automation and target identification than most organizations. It doesn’t matter what numbers you put into a table. Until you invest similarly, you’ll start to lag behind and will continue to fall behind faster every day.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.

Access time-saving tools and helpful guides from our Faculty.

IANS + Artico Search

Our 2024-2025 CISO Compensation and Budget Benchmark Survey is Live!

Get New IANS Blog Content
Delivered to Your Inbox

Please provide a business email.