Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / How Security Teams Use Automated Patch Management to Close Vulnerabilities
Transcript
- Lucas: If these conversations are useful for what you're building or running, we want to keep them coming — and we deliberately don't run ads on these shows. Luna: Yeah, that's something I hear from listeners a lot — the fact that there's no sponsor break, no product pitch, it's just straight into the topic. Lucas: Right, and if that model works for you, the simplest way to support it is buy me a coffee dot com slash fexingo. No pledge, no subscription — just a gesture that says this approach matters to you. Luna: Exactly. And today's topic is a perfect example of something that's hard to get a straight take on elsewhere — automated patch management. Lucas: Let's start with a number that stopped me: the median time to exploit a known vulnerability is now 15 days. That's down from over 40 days just three years ago. And in some cases — like the ProxyLogon Exchange vulnerabilities in 2021 — we saw active exploitation within hours of the patch release. Luna: So if you're a security team still running a monthly patch cycle, you're basically handing attackers a two-week head start. Lucas: Exactly. And that's why automated patch management has gone from nice to have to table stakes. The old model — IT staff manually testing and deploying updates — just doesn't keep up. I mean, look at what happened with the MOVEit vulnerability last year. The flaw was disclosed on May 31, and by June 5, ransomware groups were exploiting it. That's six days. Luna: And the damage was massive — hundreds of organizations compromised, millions of records stolen. All because patching couldn't keep pace. Lucas: So the question becomes: how do you automate something that's historically been so manual? The answer is a combination of tools, process, and prioritization. On the tool side, you've got platforms like Ivanti's patch management suite, Qualys Patch Management, and Microsoft's own Intune and WSUS. These tools can scan your environment, identify missing patches, and deploy them across thousands of endpoints automatically. Luna: But isn't the fear that automation breaks something? I mean, a bad patch can take down production systems. Lucas: Absolutely — and that's the tension at the heart of this. If you auto-deploy every patch instantly, you risk destabilizing your environment. If you wait too long to test, you're exposed. The solution is tiered automation. For critical vulnerabilities with active exploitation — think CVE-2023-34362, the MOVEit flaw — you deploy immediately to a subset of systems, validate, then roll out broadly. For lower-severity patches, you might schedule a weekly automated cycle. Luna: So it's about risk-based patching, not blanket automation. Lucas: Exactly. And that requires good vulnerability intelligence. You need to know which CVEs are being exploited in the wild, which have proof of concept code available, and which affect critical assets. That's where platforms like Qualys's TruRisk and Tenable's Predictive Prioritization come in — they score vulnerabilities based on exploitability and asset criticality. Luna: I've heard CISOs say they're patching less overall but more strategically. That fewer patches, better targeted, actually reduces risk more than trying to patch everything. Lucas: That's exactly right. A 2024 study by the SANS Institute found that organizations using risk-based prioritization patched 40 percent fewer vulnerabilities but reduced their exposure window by 60 percent. It's counterintuitive, but it works. Luna: Let's talk about a real example. I read about a large healthcare system — I think it was Mayo Clinic or one of the big ones — that implemented automated patching with Ivanti and cut their median patch deployment time from 45 days to 72 hours. Lucas: Yeah, that's a well-known case. They had thousands of endpoints, legacy systems running critical patient monitoring, and a manual process that involved multiple approvals. By automating the deployment pipeline and creating a 'fast track' for critical patches, they dramatically reduced risk. And they didn't eliminate testing — they automated the testing too, using pre-production environments that mirror production. Luna: What about the legacy systems? I imagine you can't just auto-patch a medical device running Windows 7. Lucas: That's the hard part. For systems that can't be patched — either because the vendor won't support it or because the application breaks — you need compensating controls. Network segmentation, application whitelisting, virtual patching via an intrusion prevention system. Automation still plays a role, but it's about monitoring and alerting rather than deploying updates. Luna: And there's a cost argument too, right? Automating patching frees up security staff for higher-value work. Lucas: Huge. A typical enterprise spends about 30 percent of its security operations time on patching. If you can automate even half of that, you're talking about dozens of hours per week that can go toward threat hunting, incident response, or architecture improvements. And with the cybersecurity talent shortage, that efficiency matters. Luna: So what's the state of adoption? Are most enterprises doing this yet? Lucas: It's growing fast. Gartner predicted that by 2025, 60 percent of organizations would have automated at least some patch management. But there's still a long tail — especially in mid-market companies and regulated industries where change control processes are slow. The biggest barrier is often organizational, not technical: getting the IT and security teams to agree on a process. Luna: And that's where automation can actually help, right? It forces a repeatable process. Lucas: Exactly. Once you define the rules — 'critical infrastructure patches within 24 hours, standard patches within 7 days' — the tool enforces it. You can still have human overrides, but the default is speed. Luna: What about the cloud? I know AWS and Azure have their own patch management capabilities. Lucas: Great point. In cloud environments, you have additional options like AWS Systems Manager Patch Manager and Azure Update Management. They integrate with your existing patch tooling and can handle both OS and application patching. The challenge there is multi-cloud consistency — if you're using AWS and Azure, you want a single pane of glass. Tools like Qualys and Ivanti support both. Luna: So the trend is clear: automation is becoming the standard. But I'm curious — are there any downsides or risks we haven't covered? Lucas: One big one: if your automation platform itself gets compromised, an attacker could push malicious patches. That's why you need to secure your patch management infrastructure — strong access controls, audit logging, and ideally air-gapped or isolated management networks. Luna: There was a case a few years ago — I think it was the SolarWinds attack — where the software update mechanism was used to distribute malware. That's the nightmare scenario. Lucas: Exactly. SolarWinds was a supply chain attack, but the same principle applies. You have to trust your patch tooling implicitly. That means code signing, integrity checks, and never deploying from a compromised pipeline. Luna: So the takeaway for our listeners: if you're not already automating patching, start with the critical vulnerabilities. Pick a tool, define your risk tiers, and test the process on a small set of systems. Lucas: And don't try to boil the ocean. Even automating 20 percent of your patch workload — the most urgent 20 percent — can cut your exposure dramatically. The tools are mature, the process is proven, and the cost of not doing it is only getting higher as attackers get faster. Luna: Alright, good conversation. Let's do it again soon.