Patching and preventing issues: What are the lessons you can learn?
In this Help Net Security interview, Kunal Modasiya, Senior VP & GM at Qualys, talks about why patching is still hard to get right. He explains how business pressure, revenue-critical systems, and patches that break things keep fixes from going out. Modasiya argues that speed alone has limits and that teams should look at the whole remediation workflow.
He discusses how proactive teams judge risk, why the gap between exposure time and weaponization time matters more than MTTR, and when automated patching makes sense on production networks.
Patching is one of the oldest disciplines in security, and teams have poured years of budget and tooling into it. Why is it still one of the hardest things to get right?
The first issue with patching is that it involves much more than one patch to one issue. An update may require several patches to fully remediate the issue, or it may rely on configuration changes to fully deal with the vulnerability. So “simply patching” can be harder than it sounds, especially at scale.
The second issue is why patches sometimes can’t be deployed at all. Most security teams have experienced this: they know the issue exists and they have the update ready to go, but the business won’t allow them to implement it. Why? Often, these applications are mission-critical and directly tied to revenue generation. Stopping that application means stopping revenue, and that is a hard decision to get support for.
IT teams are also familiar with situations where deploying patches caused unintended consequences or additional impact that was not visible before, leaving the system down for longer than expected. Critical updates need the support of executive leadership and the board, and getting that buy-in may require a stronger case than just a security issue on its own. You must look at the financial impact and make the argument in terms the business understands and can get behind.
“Patch faster” has been the industry’s advice for a decade. Has speed alone reached the limit of what it can buy a team?
Measuring speed around patching used to be about how fast your team could build scripts or other automation for tasks, but they would still be responsible for how fast those patches could be deployed. There was a limit to how fast people could roll out at scale, even with automation, because the whole workflow still relied on human actions. AI can help here, making it easier to test patches or check for issues before rolling out, but it has more impact when you look at the workflow overall.
For example, you may want to implement some patches automatically. You may want to test some in a small subset of your environments first, while others you may want to implement everywhere at once. That’s a decision to make based on how much the patch reduces risk versus the potential impact if something goes wrong. Running through that process with the help of AI can make it go faster, getting patches out more efficiently. Speed around deployment is part of the equation, and looking at that whole process is where efficiency can be improved.
For IT Security teams, providing this kind of information makes them more valuable to the rest of the business. Rather than just flagging where issues exist and how serious they are, IT Security can make direct recommendations on how to make those changes and what steps to take. This team can also be responsible for remediating and eliminating risks, rather than having to hand off to another team.
Some organizations move on a vulnerability before it lands on any official “must-patch” list, while most wait for confirmation. What does that proactive minority understand that the rest do not?
Proactive teams look at risk to their business rather than the standard definition that CVSS provides. These teams look at the combination of threat intelligence, asset inventory and potential business impact, and when there is an issue in their environment that could have a big impact on business operations, they are willing and able to move quickly. This proactive approach to risk operations keeps them ahead of any threat actor campaigns that might start up.
Getting to this stage involves looking at what risk really means to the business and where it exists. It’s not enough to have a critical issue – where is that critical issue? Is it internet-facing? Is there an exploit available, and are threat actors able to use it in their campaigns easily? Can we mitigate the potential risk fast through configuration changes, and then patch to remove the issue?
The forward-thinking security teams have gone through this process and operationalized it, so they can run the same approach on any issue at any time. They can also use this process to deal with any changes in the landscape, such as when a vulnerability that is mostly harmless can suddenly be part of a wider attack chain and moves up the priority list for remediation. That ability to stay nimble and respond is essential.
If you could get every security leader to start tracking one thing about remediation that they currently ignore, what would it be?
The typical metric that teams track is Mean Time To Remediation (MTTR) – how long it takes for your team to deploy a patch after the initial issue is released. While MTTR might still be useful, it is not the metric that I would encourage people to use now. Instead, we suggest looking at remediation efficiency.
Looking at the initial release of a patch is useful, but not the most important point. Instead, teams should consider their Average Window of Exposure (AWE). This covers how long an organization remains exposed to a potential exploit after it was released. In the case of zero-day vulnerabilities or when an attacker leverages an exploit long before a patch is released, an organization can be vulnerable days before discovery and disclosure. Alongside this, teams should track the Window of Weaponization, or WOW – this describes how fast an attacker moved to convert a potential vulnerability into a fully working exploit. The gap between AWE and WOW is the most important element for defenders, as it shows how long their organization was potentially exposed to a threat. This Remediation Efficiency Gap is critical because it describes that precise window where attackers have the upper hand.
There is growing talk of taking the human out of the loop and letting systems remediate on their own. What has to be true before an operations leader can trust that on a production network?
Automated remediation is possible, but many teams don’t want to hand over full control to AI. Like everything in security, this is not an all or nothing move. Instead, teams should rank their issues around how serious they are, how much impact they would have on the business if an exploit was released, and how much impact a deployment would have if something did go wrong.
The calculus here is that critical issues in revenue-generating applications should get the most attention from the security team in person. For low risk applications where the patches are both very likely to be reliable and the risk to users from any problem is low, those can be deployed automatically. A good example here is a patch for Google Chrome. For cases that are not so clear cut, teams can tier releases based on their company’s approach to risk and how quickly they can deploy patches.
Getting those processes implemented involves work across different teams. IT Security can provide insight and recommendations to IT Operations, and then that data can evolve over time to keep up with issues as they arise or evolve.
Looking at the future, we want agentic AI to take on more of these real-world SecOps and remediation use cases, as this enables faster, smarter risk reduction. Consider Patch Tuesday, when Microsoft releases its security updates each time every month. Knowing the patches to prioritise, most teams will look at the official information that is included in the release, and then concentrate on those ranking ‘critical’ or ‘high’. However, those official rankings may not be appropriate for your specific environment – you may already have that scenario covered through other mitigations or updates, compared to another issue that is much more pressing for your specific environment.
Agentic AI will be able to make that recommendation for your team to focus on, and then you can concentrate on where the real-world risk exists. Once you have prioritized your vulnerabilities, you can share that information and work on which ones can be patched automatically, or that might be owned by Line of Business teams like HR, Finance or Marketing. That ownership side is more important when it comes to getting things done, and agentic can make that process so much easier and more efficient.
