![The Edge Logo The Edge Logo](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt530eb1f4e672eb44/653a71690e92cc040a3e9d6d/Dark_Reading_Logo_TheEdge_0.png?width=700&auto=webp&quality=80&disable=upscale)
Cybersecurity In-Depth: Feature articles on security strategy, latest trends, and people to know.
5 Ways to Improve the Patching Process
So many software vulnerabilities, so little time. But failure to patch them can have serious consequences. Here's help for overwhelmed security teams.
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt10eaf77f5eaab219/64f0d531a84e75727d943124/602x250_update_.jpg?width=700&auto=webp&quality=80&disable=upscale)
In theory, anyone who depends on software should patch a vulnerability as quickly as possible. That goes for consumers as well as enterprises. In hindsight, Equifax would likely agree. The major breach of 2017 was, in part, the result of a failure to patch in a timely manner, writes security thought leader Kevin E. Green. But there are many reasons why patching doesn't happen quickly. Or at all.
According to the "2019 Vulnerability and Threat Trends Research Report," published by Skybox Security, part of the problem is security teams are overwhelmed by the number of new vulnerabilities — 16,000 were reported last year — making patching rather unmanageable. Some organizations can't patch quickly because the risk of downtime far surpasses that of the vulnerability. Still others don't have a patching policy in place that identifies who is responsible for patching what and when.
"When you consider that [quality assurance] testing should take place before a patch is rolled out, and that many organizations have to work around defined 'downtime windows,' it becomes clear that every organization, every day of the year, is vulnerable to known attack vectors," says Bob Noel, VP of strategic relationships for Plixer.
So how can security teams make patching a smoother process? Here are five ways.
Image Source: MyCreative via Adobe Stock
It's impossible to protect what you don't know you have or where it's running.
"Maintain an up-to-date inventory of all systems being used, whether physical or cloud-based, including operating system, versions, software deployed, network addresses, and location of the device/instance," says Mounir Hahad, head of Juniper Threat Labs at Juniper Networks.
When that updated inventory is combined with a current list of all security products and solutions in place, as well as how they are configured, it is then sometimes possible to standardize operating system versions and patch levels across all products. "This makes the job of rolling out a patch update much simpler, as it can be packaged for a standard deployment," Hahad says.
Because software is so interwoven, patching every vulnerability can actually cause more harm than good.
"The most common issue I see," says Pierluigi Stella, CTO of Network Box USA, "is systems that just cannot be patched because they use functionalities of the OS that will somehow change when patching, and that will ultimately break the application."
Wendy Nather, head of advisory CISOs at Duo Security, agrees. "The more dependencies a software has, the harder it is to update it because you have to do that in concert with all the dependencies that software has," she says.
GitHub's security vulnerability alerts tool, for example, sends developers alerts to notify them when any of their projects has a dependency with a known vulnerability.
"Whether you are developing your code on GitHub or somewhere else, there's really no excuse for not monitoring your dependencies for security vulnerabilities and getting them patched," says Justin Hutchings, senior product manager, security at GitHub.
As systems have grown more distributed and complex, the responsibility for supporting different parts of the same system has also spread out, Duo Security's Nather says. As a result, an organization can have a Microsoft Exchange administrator who may not know much about the underlying operating system, which means that person won't be able to troubleshoot the network.
More than likely, organizations have not thought of building patch management as an engineering process, but "it has to be a full engineering process that takes place on a regular basis," Nather says. "Locate the people who understand everything that's running on that system and figure out who needs to be involved in the changes."
Better cross-team cooperation and integration of tools can make it easier to prioritize which vulnerabilities to patch, too. For example, organizations may integrate their vulnerability assessment tools with network traffic analytics, Plixer's Noel says.
"When servers with known vulnerabilities are connected to the network, the traffic to and from those servers should be monitored to know if those vulnerabilities are compromised," he says. "This allows organizations to minimize risk and react quickly to inevitable breaches of these known vulnerabilities."
Organizations that have done configuration and asset management are probably going to have an easier time with patch management. That's because when security and IT get together and talk about risk and its scope, they are better informed and able to make more educated decisions.
As patches are released (or exploits are announced), organizations should run a risk analysis to understand what the likelihood is for their systems to be breached, Juniper's Hahad says. "This will help to prioritize the rollout of an update," he says. "For example, a vulnerability in network code via a certain port could be deemed a 'critical' update by the software, but if the firewall restricts this traffic, then business risk is lowered."
Doing patching right means trying to find a balance between protecting your environment and not overspending on that task. Organizations need to first assess the risk of exposure in not patching, says RiskLens CEO Nick Sanna.
Security teams have to look at the threats they are facing as a company, he explains. Then, if they add "X" number of people, they need to evaluate how much that will change the risk. Then it's time to ask at what point they get to a level of exposure they can live with. "The risk from exposure from a given threat changes depending on how fast an organizations is patching," Sanna says.
Security practitioners need to be mindful of any unintended bugs that might arise from an update applied too quickly to the organization.
"Say, for example, there are issues with logging into your organizational domain. Maybe the update messes up the corporate VPN connection that remote employees rely on, or the mapped server drives that users need to get their work done were suddenly unavailable," says Adam Kujawa, director of Malwarebytes Labs.
This is where QA testing comes into play, Plixer's Noel points out. When IT teams take proactive measures by first deploying an update within a limited scope, it helps them to determine ahead of time whether patching could cause any issues for users if it is deployed across the organization. Yet, according Kujawa, many organizations can be slow in doing this, especially if under-resourced.
"Some teams are using a qualifying process, such as 'emergency patching,' 'urgent patching,' and 'normal patching,'" adds Rick McElroy, principal security strategist at Carbon Black. "Then they will have varying layers of testing rigor that goes along with that."
Security practitioners need to be mindful of any unintended bugs that might arise from an update applied too quickly to the organization.
"Say, for example, there are issues with logging into your organizational domain. Maybe the update messes up the corporate VPN connection that remote employees rely on, or the mapped server drives that users need to get their work done were suddenly unavailable," says Adam Kujawa, director of Malwarebytes Labs.
This is where QA testing comes into play, Plixer's Noel points out. When IT teams take proactive measures by first deploying an update within a limited scope, it helps them to determine ahead of time whether patching could cause any issues for users if it is deployed across the organization. Yet, according Kujawa, many organizations can be slow in doing this, especially if under-resourced.
"Some teams are using a qualifying process, such as 'emergency patching,' 'urgent patching,' and 'normal patching,'" adds Rick McElroy, principal security strategist at Carbon Black. "Then they will have varying layers of testing rigor that goes along with that."
In theory, anyone who depends on software should patch a vulnerability as quickly as possible. That goes for consumers as well as enterprises. In hindsight, Equifax would likely agree. The major breach of 2017 was, in part, the result of a failure to patch in a timely manner, writes security thought leader Kevin E. Green. But there are many reasons why patching doesn't happen quickly. Or at all.
According to the "2019 Vulnerability and Threat Trends Research Report," published by Skybox Security, part of the problem is security teams are overwhelmed by the number of new vulnerabilities — 16,000 were reported last year — making patching rather unmanageable. Some organizations can't patch quickly because the risk of downtime far surpasses that of the vulnerability. Still others don't have a patching policy in place that identifies who is responsible for patching what and when.
"When you consider that [quality assurance] testing should take place before a patch is rolled out, and that many organizations have to work around defined 'downtime windows,' it becomes clear that every organization, every day of the year, is vulnerable to known attack vectors," says Bob Noel, VP of strategic relationships for Plixer.
So how can security teams make patching a smoother process? Here are five ways.
Image Source: MyCreative via Adobe Stock
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024