First, what is the purpose of a patch
A patch is a minor fix to an existing piece of software, usually used to fix bugs or security vulnerabilities. Patch management may not sound critical, but it can be one of the most critical aspects of the entire system’s productivity and security. Every new cyberattack is a reminder of why patching is essential, as well as the risk of not applying security patches.
Why is it so vital to keep security patches up to date?
Security patches is exactly what the name suggests, patches that involves securing your system and devices. These are the patches you need to view first and determine how critical they are and how fast you can implement them. Cyber criminals have become more and more focused on exploiting flaws, bugs and severe coding errors in systems and services. Simply because there are so many solutions out there and too many potential bugs that could easily be exploited. And when a bug is found they are quick to weapnoize it and make use of it in targeted attacks.
why we need to up our patching game
But what you really should be concerned about is that when you first hear about a patch coming out, there is a big chance that cyber criminals have already been aware and exploiting the vulnerabilities for quite some time. For example, the exchange server vulnerability which Microsoft patched in March had been used by hackers in the wild since early January or even earlier. This means they have had unhindered access to do as they pleased while none where aware of any vulnerabilities existed. And the scary part is that this is nothing new. Cybercriminals are actively hunting for vulnerabilities in known software as Microsoft Exchange, RDP services, known firewall brands, web hosting services etc. And if that wasnt enough, cybercriminals can also reverse engineer released patches in order to develop exploits against unpatched targets. This is a much easier task and seeing how many users and companies that delay patching, they make for easy targets.
How to get a handle on patching
You need to implement patch management best practices and apply them to suitable applications at the right time. Patching one piece of software from one vendor is usually a simple process, but if you have many devices with numerous programs or want to make sure all your devices are patched simultaneously, you will need to have a patch management plan and use patch management software.
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 will be able to compare the known vulnerabilities to your inventory to quickly discover which patches matter to you.
Assign Risk Levels to Your Systems
- Risk levels give you the ability to choose the right priorities. Don’t waste all your time 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.
Consolidate Software Versions
- The more versions of a piece of software you use, the higher the risk of exposure. 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 must apply.
Keep Up with Vendor Patch Announcements
- Keeping up with vendor patch announcements is vital in a heterogeneous environment. Once you have a clear inventory of products, subscribe to all 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.
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 patchwork. However, this will take time. In these situations, mitigate the risk to the extent possible—Lockdown user permissions on the server. Do not 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.
Scheduling restarts after an update is critical
- Generally, systems must reboot because they cannot modify system files while they are being used. Those files are locked and can only be modified when they are not being used. This is critical because the changes update does to the system will not be effective until the system reboot.
Test Patches Before Applying Everywhere
- Every environment is unique. A patch could cause problems or even bring down machines with specific configurations. Take a small subset of your systems and apply the patch to them to make sure there are no significant problems.
Automate Open Source Patching
- 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 discovered. The challenge is keeping track of all the open-source libraries and tools in use by your developers.
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 cannot patch, and act quickly to patch your applications. Use automation to keep open source vulnerabilities from becoming vulnerabilities in your applications.