Patch Management Best Practices
Table of Contents
You’ve read news articles about the latest “zero-day” exploits spreading across the web. These exploits are great news fodder, but zero-day attacks aren’t the most dangerous enemy to your organization. Patches are.
What does your patch management process look like? Do you have one?
A patch is a small fix to an existing piece of software, usually used to fix bugs or security vulnerabilities. But having a fix available and never applying it won’t help you. You need to implement patch management best practices and apply them to the right applications at the right time.
You’ll need to patch operating systems for your servers and endpoint devices. Don’t forget that patches need to be applied to vendor products integrated into your environment, not to mention patching your own software is another key piece of the puzzle.
Before we discuss how to create your own patch management process, let’s look at why it’s so important.
Why is patch management important?
When patches are released to the public, the vulnerability often is disclosed with it. If you were an attacker, would you spend weeks or months trying to find a vulnerability, or read up on the latest patch for a third party component and bet on the fact that most users are not fast enough to apply them?
If you take into consideration the fact that only 10% of the code base in an average application is written in house and that 21,000 known vulnerabilities (CVEs) were reported in the last 18 months, you’ll understand that known vulnerabilities have become the weakest link in your software security.
Patches require time and effort to apply. Annually, organizations spend 18,000 hours and over a million dollars on patching activities. Despite this effort, many have seen a reduction in the time it takes for an exploit to appear in the wild for a given patched vulnerability. Without implementing strong patch management best practices, you’ll waste time and risk leaving the door open to attack.
In a study by the Ponemon Institute, 57% of cyberattack victims stated that applying a patch would have prevented the attack. 34% say they knew about the vulnerability before the attack.
A solid patch management process is an essential piece of a mature security framework. The faster you can apply the right patch to the right application, the more secure your environment will be.
Eight best practices for a smooth patch management process
While patch management is a challenge, it’s not impossible. Apply these eight patch management best practices to build your process and protect your systems.
#1: Inventory your systems
A comprehensive inventory of all software and hardware within your environment is a critical piece of any patch management process. Once you have a clear picture of what you have, you’ll be able to compare the known vulnerabilities to your inventory to quickly discover which patches matter to you.
#2: Assign risk levels to your systems
Risk levels give you the ability to choose the right priorities. Don’t waste the 18,000 hours spent on patching by applying patches to the wrong systems.
While all systems should be patched, it makes sense to assign risk levels to each item in your inventory. For example, a server in your network that is not accessible from the Internet should not be as high a priority to patch as a laptop used by your sales team. The more exposed to attack an item is, the faster it should be patched.
#3: Consolidate software versions (and software itself)
The more versions of a piece of software you use, the higher the risk of exposure. It also creates large amounts of administrative overhead. Choose one version of Windows, Linux, or MacOs and keep that version up to date with patches.
Large organizations sometimes buy different software products that perform similar functions. Periodically review all software in use and its purpose. When you find multiple pieces of software performing the same function, choose one and get rid of the rest. Fewer software products mean fewer patches you have to apply.
#4: Keep up with vendor patch announcements
Using third-party vendors is a common practice. It’s good business sense to use a product to perform a common task and to spend your energy building software that differentiates your business.
Keeping up with vendor patch announcements is key in this heterogeneous environment. Once you have a clear inventory of products, subscribe to all of their security updates through whatever channel patch announcements are made. Monitor each of these by sending them to a specific inbox or Slack channel. Create a process to ensure none fall through cracks so each patch can be added to the patch schedule.
#5: Mitigate patch exceptions
Sometimes a patch cannot be applied right away. For example, a Java patch may break an existing business application. Changes need to be made to make the patch work. However, this will take time.
In these situations, mitigate the risk to the extent possible. Lockdown user permissions on the server (which you should do anyway). Don’t leave an unpatched server exposed to the Internet. Figure out how to reduce the impact and likelihood of an exploit until the patch can be applied safely.
#6: Test patches before applying everywhere
Every environment is unique. A patch could cause problems or even bring down machines with certain configurations. Take a small subset of your systems and apply the patch to them to make sure there are no major problems.
Once a handful of systems check out, begin rolling out the patch to larger and larger groups until the entire company is patched. Patching quickly doesn’t mean applying the patch everywhere at once. Make sure patches don’t fall through the cracks and that a plan is in place to get everything patched in a timely manner.
#7: Apply application patches as quickly as possible
Applications you build have much more flexibility than operating systems and servers. When security vulnerabilities are found in your custom code, these should be added to the dev team’s backlog and treated with the same importance as vendor patches.
Don’t leave the door open for an attack in your own applications. Quickly fix vulnerabilities and update your software in production.
#8: Automate open source patching
Open source components help dev teams to build software more efficiently. But open source libraries are susceptible to the same vulnerabilities as other software. As more open source libraries have appeared in recent years, the number of vulnerabilities in those libraries has increased.
The number of open source vulnerabilities is rising quickly as more open source tools are created and used.
If you use open source, you need to patch the open source libraries you use when vulnerabilities are discovered. The challenge is keeping track of all of the open source libraries and tools in use by your developers.
Automation is the key to keeping a solid inventory of open source tools in use and what versions are vulnerable. Automated tools, like Mend Remediate, not only know what libraries you use but will automatically open a pull request with updated versions when it detects an unsafe version in use. Developers only need to accept the pull request to patch their open source libraries seamlessly.
Open source vulnerabilities become vulnerabilities within the applications that use them. Automated open source patching eliminates this risk without adding a burden on development teams.
Forget about zero-day exploits – Patch your systems
Instead of focusing on the latest zero-day exploits, work on implementing patch management best practices. Poor patch management will lead to an attack on your systems.
Keep an inventory of your systems. Keep up with vendor announcements. Test your patches, mitigate where you can’t patch and act quickly to patch your own applications. Use automation to keep open source vulnerabilities from becoming vulnerabilities in your applications.
Patch management is a challenge that can be met. Follow the eight patching best practices presented here to protect your environment and become the envy of your patching peers.
