Search
Close this search box.

6 Patch Management Best Practices for Keeping Your Business Safe from Cyber Threats

Author

Sergio Monge

https://www.linkedin.com/in/sergio-monge-gamez-2651b680/
sergio.monge@auxis.com

Service Delivery Manager

Unpatched business systems roll out a welcome mat for hackers aiming to steal data or hold it hostage. But patching systems isn’t as simple as clicking an install button – and as the complexity and risk grow, implementing patch management best practices is vital to keeping your business safe from cyber threats.

Nearly 60% of cyber-attack victims said installing an available patch would have prevented their breach, a Ponemon Institute study reports. Even worse, 34% said they knew about the vulnerability before the attack but never fixed it.

Case in point: the 2017 Equifax data breach that exposed the data of 143 million Americans stemmed from an Apache Struts vulnerability that had remained unpatched for two months.

The record-setting number of zero-day attacks in 2021 drives the urgency of patch management best practices even more – with zero-day malware comprising more than two-thirds of cyber threats in the third quarter alone. Zero-day attacks stem from software vulnerabilities exploited so quickly by hackers that IT teams have zero days to fix the problem.

Such attacks carry hefty costs. The average price companies paid after a data breach set another grim record in 2021: a whopping $4.24 million.

Why is patching a problem?

Patch management is an organization’s process for applying software updates, often required to correct errors (aka bugs) or address security holes in the system. Patches are regularly released for operating systems, applications, and embedded systems like network equipment.

Since patches identify the vulnerability they’re meant to fix, installing them quickly is essential. Hackers can exploit a given weakness within hours of a patch’s release.

However, while software patches are mostly available within a reasonable timeframe, busy IT teams often suffer “patch fatigue” – lacking the time or expertise to keep up with complex patching schedules, post-patching QA procedures, and zero-day vulnerabilities that must be immediately addressed. They also struggle to work around business hours to minimize impact.

Organizations spend an average of 18,000 hours and $1 million+ on patching activities annually – and the time it takes for hackers to create new exploits for patched vulnerabilities is dwindling.

Some IT teams are also wary of patches, which can involve complex coding vendors are pressured to write and distribute quickly. With a wealth of equipment to manage and testing delays, it often takes organizations 100+ days to apply patches – leaving them vulnerable to cyber-attacks.

Implementing patch management best practices improves more than security. It can optimize business-critical functions as well, leading to performance improvements like fewer application crashes and downtime. It helps organizations keep pace with the latest software features and capabilities that improve end-user experience.

And as cyber threats explode, it helps enterprises avoid legal and financial ramifications for failing to stay compliant with stringent patch management standards required by regulatory bodies.

Patch management best practices every organization should know

1. Define and document a patch management policy.

Too many organizations choose patching tools and procedures without taking the time to understand their requirements or the functionalities and controls of their environment. Unfortunately, that often leaves them stuck with a solution that doesn’t fully fit their needs.

Developing a patch management policy with stakeholders across the organization helps you clearly identify your organization’s vulnerabilities, zeroing in on what needs to be patched, when, and in what conditions. It also establishes testing and recovering routines, procedures, and timeframes for effective patching that minimizes business disruption.

A strong patching policy should define:

  • Scope. What technologies and teams are involved
  • Cadence. How often does each technology require patching?
  • Maintenance. What maintenance windows can be predefined?
  • Priorities. For instance, security, updates, feature, and critical patches.
  • Pre-and post-patching activities. That may include pre-patching communication and approval procedures, as well as post-patching testing, communication and QA controls.
  • Zero-day timelines. What are high-priority vulnerabilities?

2. Know your infrastructure.

Once you have a clear view of your requirements, you can start translating them into procedures. Doing so requires an in-depth understanding of your infrastructure, considering:

  • What infrastructure components are most critical to the organization? Every environment is unique – and a bad patch can trigger problems or even “break” machines with certain configurations. To avoid disruptions, longer timelines with extensive testing can be wise for patching critical devices.
  • What components are most vulnerable? While all systems should be patched, assigning risk levels makes sense. For instance, an intranet server that isn’t accessible from the internet isn’t as high a priority as a highly critical perimetral network device. The more exposed to attack a device is, the faster it requires patching.
  • Are there devices that can no longer be supported or will be out of support soon? No antivirus or firewall can protect you from a core-level vulnerability in an operating system (OS) that can no longer be patched. If devices have unsupported OS or application servers that can be accessed from the internet, they should be replaced as soon as possible with newer technology. Prioritization is based on business impact and vulnerability to attack.
  • Will some devices be excluded from patching? For instance, devices running legacy or homegrown applications. Best practices should include isolating unsupported devices from internet access, when possible.

Answering these questions helps you define patching groups based on technologies, criticality, vulnerability, and business needs. For instance, if test environments aren’t available to test patches on critical servers, you can build resiliency by scheduling patches for less-critical servers first or patching servers with similar functionality on separate schedules.

3. Plan patch schedules and maintenance windows.

Patches require time, effort,