Security Patch Management — 7 Do’s and Don’ts

July 31, 2018 Ayala Goldstein

Like other security tasks in development organizations, security patch management is not for the faint of heart. Data breaches like the Equifax fiasco and widespread ransomware attacks like WannaCry make the general public shudder and remind us that known security vulnerabilities don’t go away no matter how vehemently  we ignore them. However, the reality is that when you’re trying to push out releases under aggressive timeframes, implementing a patch management strategy becomes another item in a long list of tasks.

A security patch is like a band-aid for a software version that your organization is already using. As bug bounty and security research outfits work hard to analyze code and locate security issues, applications, firmware and middleware developers continuously work to fix those issues and push out patches to address those security vulnerabilities. Now all we have to do to ensure that our products are secure is to update the vulnerable version that our team or organization is using. Sound simple? It’s not.

That’s where security patch management comes in, making sure that security patches are rolled out efficiently, that security vulnerabilities are detected, that the most critical fixes are prioritized, that patches are tested so that they don’t interfere with other components and processes, and that all teams are working together so that the software development life cycle is still running smoothly.

We’ve put together a list of four recommended best practices and three common mistakes organisations need to avoid when putting together a security patch management strategy.

#1 Do: Come Prepared: Put a Security Patch Management Policy in Place

With new security vulnerabilities discovered and published at an alarming pace, organizations have to make sure that they have laid out the groundwork for addressing and fixing them. Having a detailed security patch management policy in place helps organizations map out all the logistics of the patch management strategy in advance, so that when necessary, teams handle security patch rollouts like a well oiled machine.  

A typical patch management policy will cover and document timeframes and scheduling, testing, responsible parties and points of contact, prioritization, patch deployment and monitoring.

#2 Do: DevOps it Up: Automate Your Patch Management Strategy

One of the key factors in the DevOps approach is automation, and patch management tools are coming into the mix, replacing tedious and time consuming manual processes.

Automated patch management tools for organizations can cover a number of patch related tasks like monitoring, alerting, prioritizing, deploying, testing, reporting and more. Many organizations use multiple automated patch management tools for various tasks and processes, depending on their needs, so that they have all or most of the required patching processes covered across a diverse development environment.  

#3 Do: SCA to the Rescue: Patch Management for Open Source Components

While there are many automated tools out there for patching proprietary software, they don’t cover open source security vulnerabilities.

Open source security vulnerabilities and their patches aren’t published in one centralized location, they are published across a variety of security advisories, bug trackers, project documentation and databases. Since the information is de-centralized, it’s nearly impossible to track manually. This is where automated software composition analysis (SCA) tools come in.

Automated SCA tools can continuously track an organization’s projects throughout the development lifecycle to locate, alert and report on any vulnerable open source components, which libraries they affect, and the security patches available. By using an SCA tool, an organization can manage the open source components that they are using, and immediately address any vulnerabilities as soon as they are discovered.

#4: Do: Test and Monitor Your Security Patches

In our fast-paced development ecosystem, urgent security patching might feel like putting out a fire. Having a security patching policy in place and using the right automated tools helps address patching in a more systematic manner. Another essential component in security patch management strategy is testing.

Ideally, DevOps, security, or IT teams will sandbox the patch before deploying it in their environment. However, this might be a costly process for smaller organizations. If an organization doesn’t have the resources to test a security patch in a virtual or controlled environment, it’s recommended to roll the patch out gradually, and closely monitor performance, so that if the patch is incompatible with other libraries or components in their system they can quickly revert without causing too much damage.

Now that we’ve covered some of the industry’s  best practices, let’s take a moment to learn from common mistakes and look at some of the industry’s worst practices, and how to avoid them.

#1 Don’t Take Your Time

Security patch management is a time sensitive business. Recent history has showed us repeatedly that once a security vulnerability is published, hackers are working fast and hard to find it in organizational systems. That’s why creating a patch management strategy, documenting a detailed policy and integrating automated tools into your patching processes is so important.

#2 Don’t Get Too Attached to Your Patch Management Policy

Have a patch management policy in place? Good job. Now track and assess your patch management processes and see how you can improve it. The security landscape is continuously evolving, and organizations need to keep up. That means measuring the success of your current patch management strategy, and periodically going back to the drawing board and finding ways to improve it.

#3 Don’t Patch and Run

The unfortunate truth is that no patch is perfect, or one size fits all. No matter who published the patch, it might simply be incompatible with your system. That is why testing is so important, and it’s also the reason you need to closely monitor the components that you patch. Otherwise, you might find yourself with a painfully incomplete solution.

Security Patch Management: It’s a Marathon, not a Sprint

Many IT and development outfits cringe at the thought of a patch roll out, traumatized by past experiences with crashed systems, delayed releases and unhappy customers. Security patch management policies and tools can help create a well managed strategy and processes that will enable them to beat the hackers to security vulnerabilities in their systems, without breaking a sweat.

 
Previous Article
8 Startup Due Diligence Questions You want to Be Asking
8 Startup Due Diligence Questions You want to Be Asking

Next Article
The 5 Common Mistakes Your Devops Team is Making
The 5 Common Mistakes Your Devops Team is Making