What is Patch Management?

Patch management is an essential practice in IT and systems maintenance. It’s most simply explained as the way that you correct errors and vulnerabilities, by using “patches”.

These are updates to operating systems, network equipment, software products, and applications, created to solve issues that are found after release. A good patch management process can keep your environment secure from cyber-attacks, help an IT environment run smoothly without downtime, ensure that you’re fully compliant with many regulatory requirements, and also help software to run at peak performance.

Your patch management approach needs to include keeping on top of all available patches, knowing what patches are right for what systems, creating and documenting your patch schedule, and thoroughly testing systems after patching is complete. Automating patch management can help to streamline and improve the accuracy of these tasks.

Why bother with patches?

Software patches include adjustments to programming code. They cost money to produce and software houses don’t create them frivolously. Here are the main reasons that software producers create and distribute patches:

Security: Hackers explore operating systems and system services constantly looking for ways to manipulate them in order to break in, monitor processes, install spyware, or steal data. A piece of software that seems to be secure today might become a security weakness when new knowledge arises. These newly discovered loopholes are called “exploits” and patches remove them.

System availability: By removing discovered errors, patches can prevent the system from crashing or hanging. You might not have run across the error that is being fixed but, if it’s there, it could damage your system uptime, so it is better to apply the patch.

Standards compliance: If you need to comply with an industry security standard, such as PCI DSS or HIPAA, you need to implement a patch management strategy because that is a requirement of those standards.

System guarantees: Software providers will refuse to stand by any system guarantees for buyers who fail to keep up with the latest version of the software by applying all patches. In some instances, providers refuse access to support unless the software is fully patched. Having out-of-date software can also be an excuse used by your professional insurance provider not to pay out in the case of a disaster.

System enhancements: Some feature improvements are not issued as a full update but as a patch instead. This is particularly the case that improvements are meant to enhance the efficiency of a backend process. So, if you don’t apply patches, you are missing out on free upgrades.

In short, it is not a good idea to ignore patches.

How do I discover that patches are available?

Although patch installation is a relatively straightforward process, there are so many complications that can arise when looking after all of the infrastructure of an organization. This is why it is better to use the assistance of an automated patch management tool. Patch management systems can check for updates …

How do I check whether an overnight update really worked?

Creating all of these data gathering and analysis procedures would be time-consuming, so it is just easier and more cost-effective to use a centralized patch management tool that includes execution status reporting.

Patch management best practices

Create patch management system policies by first thinking up a set of rules. These rules inform the patch management system of important operating parameters, such as when the system is available for a patch run.

Your patch management policies need to be coordinated with business practices and system priorities. They will be implemented in the patch management system as a series of profiles. Here are a few tips:

 

1. Create separate profiles per device type and operating system

The patches that you receive won’t apply to all of your devices because your software is closely tied to the operating system that runs. Therefore, you don’t need to patch all systems simultaneously. Creating separate profiles gives you flexibility.

2. Separate out systems that are critical

An example of this is an operating system or a service that needs an entry in the registry. Patches applied to these programs will require a system reboot. Other software packages won’t require that and should be put in a separate patch rollout group.

3. Create a system preparation policy

Set up a profile for creating a system restore point so that everything can be rolled back to its status before a patch rollout began if something goes wrong during the patch application process. Attach other admin policy actions to this profile. Schedule this profile to run first before any patch rollouts.

4. Create a regular window for patches

Identify a day of the week and an hour of the day each week when there is almost no user activity.

Don’t make it the evening of the last day of the working week unless you intend to start work early the following day despite it being an official day off. You don’t have to attend the rollout but you do need to be able to check system availability after it has completed and before the user community clocks in for work.

5. Leave gaps in the rollout schedule

If you are likely to apply patches in several policy groups during the same time frame, leave a gap of between one hour to one and a half hours between the launch times of each. This gives time for each policy group to have completed its updates before the next begins. Run the lower-priority patch group that doesn’t require a reboot first, unless system dependencies written in the patch release notes require otherwise.

6. Ensure that all devices are on

You can check in the patch management system to see whether there are any patches that need to be applied in the run-up to your weekly patch rollout timeslot. Ensure that all of the devices that will be touched by that policy group activation are on and connected to the network before you leave the office for the evening.

7. Be the first in the office after the rollout

Don’t set a patch rollout window for a day when you can’t be sure that you will be the first to access the system the next day. If an appointment means you probably won’t be able to check the system before the users log on after an update, suspend the rollout.

For more detailed information about patch management best practices, please visit our support page on the subject.

Frequently Asked Questions

What is automated patch management?

What is Patch Management Life Cycle?

See Atera in Action

RMM Software, PSA and Remote Access that will change the way you run your MSP Business

Try Atera For Atera