Patch Management: Is Your Incident Response Plan Ready for 2025?

There was a lot to keep security first responders on their toes this past year. For example, the global IT outage on July 19 took some organizations down for days — others for weeks. Another smaller — but still significant — Microsoft Azure outage occurred in July, and if this year is like any other, countless unnamed periods of attack, downtime, and recovery were happening for thousands of cyberattack victims in every industry.

Now that the new year is beginning, it is time for teams to take stock of their incident response (IR) plans and ask themselves, “What would we do if we found ourselves in the same position?” Not all incidents are results of a malicious cyberattack. Many occur because of outdated software components, neglect, or error. And yet, the downtime experienced from these is just as real — and just as painful.

Time for Review: Business Continuity and Incident Response Plans 

It is vital to have a business continuity plan that’s ready for anything; not just cybercrime. Decision-makers would do well to learn from the global outage of this past year — which was caused, after all, by a faulty automatic update to a widely used solution — and make the needed adjustments. 

For example, could recovery have been expedited with some utility that could be used by remote employees when a system is in a constant reboot loop? Are we staffing and prioritizing patch management and offensive security as much as incident response? In other words, are we putting a fence around the cliff instead of just an ambulance down in the valley?

Also, review org chart changes to ensure that the new IR plans take into account the current hierarchy and don’t get snagged on outdated personnel. Have any key stakeholders left the company? Were there departmental changes that necessitated role changes? The bottom line is that the plan needs to reflect the most correct and current organizational structure. 

What Is Patch Management?

Speaking of including patch management permanently in future incident response plans: How exactly would you define patch management?

Patch management in the modern enterprise today encompasses having a program in place that consistently monitors for, identifies, and remediates instances of outdated software, applications, or solutions. A good patch management program will vet for common vulnerabilities, and include:

• Security patches
• Service packs
• Hotfixes
• Bug fixes
• Feature updates

Human error commonly leads to misconfigurations, and the more humans are installing, provisioning, and deploying systems, the more a constantly running patch management program is needed. This leads into the patch management process, a systematic approach to:

1. Identify necessary patches based on existing bugs and vulnerabilities
2. Acquire patches
3. Test the patches in the existing environment
4. Deploy the patches to the outdated/ vulnerable systems
5. Monitor the performance of the patches over time

Reviewing Your Patch Management Program

Before declaring your patch management complete (and integrating it into your incident response strategy), it’s helpful to ask some thorough questions. Here are some you may find relevant:

1. Do we skip QA testing and go directly to production on updates? Do we want to go back to doing QA testing first?
2. Can we control patching process for our environment for our entire IT estate?
3. Do we change our patch window, or should we adjust how we prioritize our patching schedule?

And perhaps most importantly, you want a patch management program that adapts based on current events and prevents them from happening to you. It might be important to ask: What are our vendors doing differently after last summer’s global outage?

For example, are they now going to allow the user to control upcoming updates (roadmap items)? Or are they changing their operations to push out only a percentage of updates to any one customer? This will ensure that the entire environment doesn’t go out due to a bad update. For example, no more than 20% of a single customer deployment receives an update, and even these are done in batches over the course of a multi-day period.

Testing Your Latest Incident Response Plan

Just like deploying patches, incident response plans need to be monitored if they are to continue successful. Much is in flux within a modern environment, and if someone isn’t specifically designated to make sure IR plans keep up with the times, they will likely fall off the radar.

Make time to do this at the beginning of the new fiscal year. Engage a third party to do a tabletop exercise so there can be an unbiased test. Third parties can also be useful for penetration testing and adversary simulation, which will really put your IR plan through its paces and reveal any gaps. 

This year, incident response strategies will need to accommodate more ways of being compromised than cyberattacks alone. Adding patch management to the mix will future-proof your organization against a wider range of (very plausible) threats.