A vulnerability is a flaw or weakness in a system that, if exploited, would allow a user to gain unauthorized access to conduct an attack. One of the most common types of vulnerabilities is bugs, or vulnerabilities that exist within software such as operating systems or applications. When one of these bugs is discovered after software has already been launched, a patch is released to remediate the bug and prevent it from being exploited.
It is generally best practice to install patches that are released for the software you’re using because it will reduce the likelihood of a successful breach, ensure that your systems are up to date, and help you comply with regulatory requirements. However, that doesn’t mean that you should necessarily install a patch the moment it is released. Patches should be implemented strategically, taking into account the impact deploying a patch will have on your business operations and security posture.
Here are the steps you should take to put in place a successful patch management program to assist in efficient vulnerability remediation:
- Develop an Up-to-Date Asset Inventory: In order for you to know what patches you need to deploy, you first need to know what software you’re using. That may sound simple enough, but in reality, it can be extremely challenging. Modern application development relies on the use of open-source code to keep up with expectations of constant development and release. While this is beneficial to the DevOps process, it can be a nightmare for security professionals who are unaware of “shadow code.” An up-to-date inventory of the open-source code being used will help you track the libraries you’re using and any vulnerabilities associated with them. If you’re using many of these libraries, it may be worth investing in an automated tool for this because it can quickly become challenging to keep up with new code that is added and changed. As part of your asset inventory, note which systems have known vulnerabilities associated with them, as well as what security controls you have in place that might minimize the impact of a vulnerability. Patch management is a part of your overall vulnerability management strategy, which means that there may be times when patches are not necessary because another facet of your VM strategy is in play.
- Establish Patching Policies: Once you have an asset inventory, you should group these assets based on risk. Evaluation of risk should consider factors such as business criticality, usage, and other mitigations that may be in place to counteract a vulnerability. Once you have your groups, you should create policies for patching vulnerabilities in these groups. The policies should layout the patching priority, frequency, and timeframe for applying patches for various levels of vulnerability criticality.
- Monitor for New Patches: Just like you can’t patch what you don’t know you’re using, you also can’t patch something if you don’t know a patch has been released. For closed-source software, like Microsoft, finding out when new patches are available is relatively easy. There are scanning tools that can identify if you’re using outdated software, and you can stay up to date with their regular cadence of Patch Tuesdays, which happen on the second Tuesday of every month. With open-source code, it may not be as easy to find out when a new patch is available. Open-source software is most often updated by the maintainers of the library, but they may take some time to fix a vulnerability. Subscribe to places where patch announcements are made and send these notifications to a specific location for monitoring. You may also be able to utilize your vulnerability management tools to detect new patches. Some of these tools will detect outdated open-source libraries and submit a pull request with updated versions. You should also, of course, be testing your own proprietary code for vulnerabilities that need to be updated and submitting identified problems to developers.
- Test New Patches: One reason why you may not necessarily want to automatically apply every patch that comes across your desk is that it may have a negative impact on something else. Set up a test environment that hosts your critical applications and apply the patch in this non-production environment to preview its impact on operations. If this is not practical, you can create a small operational testing group to apply the patch to instead before applying widely. It may also be helpful to do a backup before applying the patch to your entire network just in case something does go wrong.
- Deploy the Patch: Deploying the patch should be done as quickly as is safely possible while taking into account any downtime that it may cause. If this patch is going to have an impact on end-users, you may want to alert them so no work is lost during rollout. Businesses will sometimes put off patching indefinitely because they’re afraid of causing downtime during a busy season. If you’re going to wait a significant period of time before deploying a patch, such as waiting until the holidays are over for retailers, make sure there are other controls in place to minimize the impact of an exploit on that vulnerability. A successful breach is likely to cause a lot more damage than an unsuccessfully deployed patch. Known vulnerabilities are known to attackers too, and there is a lot of potential for gain if they’re able to successfully exploit one of these vulnerabilities in the multitude of environments that use a particular library of open-source code. This is where integrating your patch management process into your overall vulnerability management process becomes especially critical.
- Review and Document: After a patch has been deployed, make sure to monitor the environment for any unforeseen negative impact and document that the patch has been deployed successfully. Your patch management process should integrate into your larger vulnerability management strategy. The vulnerability scans you perform can help alert you to vulnerabilities that need to be remediated. You should then be able to use the information in your asset inventory to determine whether this vulnerability is best remediated by patching or if another method of remediation, such as applying additional security controls, is the better option in this scenario.
Having trouble keeping up with patch releases? RH-ISAC members receive a daily intel report featuring relevant information such as newly released patches, vulnerabilities discovered, malware reported, and industry news aggregated from across the internet and RH-ISAC’s sharing platforms. Learn more about how RH-ISAC membership can benefit you.
