The Myth of “You Can’t Patch Your Way Through Mythos” | Sumedh Thakar

Well, thank you very much Ashish and welcome to all of you to another edition of the Cyber Race series here. This thing's been going on for a couple years now and never a dull day in cybersecurity. I think as we've been evolving, the frontier models have made life very interesting. I think as much as interesting it is to look at the technical aspects of it, the social interaction around methods and frontier models has been more entertaining than ever. A lot of pundits and self-proclaimed experts on LinkedIn predicting the demise of all kinds of different techniques, technologies, etc. And that's what I wanted to talk about: different types of narratives out there about, 'Oh, we cannot patch our way through methods.' Is that a myth or is that a reality? That's the question. And I think we can safely say, especially those of you who are in the trenches on a daily basis in cybersecurity, know very well that you cannot patch your way through methods, but you cannot zero trust your way out of methods. You cannot DDR your way out of methods. You cannot firewall your way out of methods. The reality is that your defense in depth and the layers of defense and having them working really well have never been more important than now, when we are struggling to respond to the speed at which attackers are coming up to us. And a very big part of that defense in depth, of that strategy, is going to be making sure that your defense in depth is really working. So I think it's not about picking one technology versus another and saying that, 'Okay, you just deploy this one security control and you're going to be fine.' And I think a lot of you who are working on this on a daily basis know that very well. I think of this as: if you are buying a car and your car has airbags in it in case you hit something, as a safety net so that the airbags will deploy and protect you, it doesn't mean that you're going to now buy a car that does not have any brakes to preventively stop yourself from getting into a crash. So the same way, if you have a car with really good brakes, ceramic brakes and whatnot, it doesn't mean that you're going to now say, 'Hey, let me not spend on an airbag since I'm so confident that my brakes will work every time.' I think that ability to make sure that we have the preventative, the proactive, and the reactive working well has really never been more important. What does change, however, is our efficacy and the speed at which some of these controls are being deployed. You know, when you cannot have firewall rules being updated once a week. You cannot have your EDR signatures or EDR technologies being updated once a week. And it's the same way that you cannot have your patch management process be the same way as it used to be, with vulnerabilities coming at a much bigger volume, with vulnerability exploitation times reducing, and more importantly with frontier models. The ability to chain these attacks to create breaches is really something that needs to be responded to with some level of making sure that you are very good at the remediation piece of this as well. And at a very high level, as management boards are asking how the security team is planning to respond to autonomous AI-based attacks, your response cannot be, 'We need to hire 50 more people to do more manual remediation.' Some form of autonomous remediation as a roadmap is absolutely essential today to make sure that we are giving the confidence to the business that there is a plan in place that will allow us to respond to autonomous AI-based attacks with autonomous capabilities in the different security controls that we have, and one of those controls that is going to be very important is autonomous remediation. And I think that's where we have seen significant interest in the last few weeks from a lot of our customers, a lot of the companies out there, looking to understand how they can bring in this layer of autonomous remediation as part of their overall security stack. And of course, the biggest pushback, and that's kind of where this whole conversation about 'is it a myth or not' is the pushback that comes from people being worried about, 'Oh, but what if it breaks something?' This is always the battle and the push and pull of risk management between operational risk of applying an autonomous remediation with the security risk of not applying a remediation in time and the attackers come and get you. Now I'm a lot more optimistic about the evolution of AI in the space of cybersecurity. I think models, frontier models that are coming out, as well as a lot of open source models, are actually going to be better for security. In theory, and I'm just saying this, in theory, if every software development shop had access to a model like this, whether it's open source or one of the commercial models, they will be able to find all of their vulnerabilities and exploits before the attackers do. Which means in theory you may not have any more zero-day vulnerabilities because the attackers don't know your vulnerabilities before you do. But it does mean that the threat vector can change more towards not being compromised from unknown vulnerabilities being exploited, but being compromised from attackers leveraging AI to reverse engineer patches to be able to find the exploits quickly and attack you on the vulnerabilities that are exploitable in your environment that you have not remediated in a quick period of time. And that's where a lot of that threat vector is moving. And that is why there is so much interest right now in the topic of: is autonomous remediation possible? Can we do it? And what does it take to get into more of an autonomous remediation capability? And that is what today a lot of the conversations that we are going to have are going to be so interesting and exciting because they really talk about the ups and the downs of taking this approach and fundamentally what do we need to be successful with an approach that talks about autonomous remediation.

I think we cannot continue to not fix things autonomously with the fear that, 'Oh, what if the system goes down?' I think a lot of this fear really comes from our current application and infrastructure architecture that may not be resilient to your systems having issues or outages or things like that, and that is why the fear of an outage comes into play. I think as these AI-based exploits and attacks continue to come, and we are absolutely going to have to do more and more autonomous remediation or quick remediation, the architecture of our applications needs to evolve where they become resilient, so that an autonomous patch causing an outage on one node does not actually bring your application down. And that's the future we are going to have to architect our applications of the future to be resilient to any kind of patching, any kind of compromises, etc., so that you can very quickly pull out a node, fix it, put the node back, but your overall application continues to work. The good news is that with our movement into the cloud and container security in the last few years, we have definitely moved into architectures that are far more resilient than what we had in the on-prem side. With cloud, you get a lot of capabilities in being resilient, backups, different regions, etc. And that's really in my mind is the future where all IT dev teams really need to start building applications that do not have the fear of a potential issue coming up in one of the nodes when you patch it. Now, till that happens, the reality of where we are today is you have to deal with what I call as first-party patching: how do you find the issues in your own code base that through these models you need to fix, that nobody else outside the organization knows? And then a large part of your risk comes from all the software that you are running in your environment, which is your supply chain: this is your operating systems, your open source libraries, your third-party products that you're leveraging, your browsers, and the vulnerabilities and zero days that might be coming through those. How do they essentially bring risk to you, and what is the right equation in terms of thinking about remediating them autonomously or not? The fear of an outage is what pushes us back. But then now the fear of a compromise is competing with each other, because if you don't fix it on time you could get compromised. Is the cost of that versus you try to do a fix? What is the cost of that? And that's really where I think in today where we are, the ability to have high level of confidence in our remediation is the key for success in an autonomous remediation environment. If you have high confidence that if I deploy this patch or this mitigation, it is not going to create an outage, you are much more likely to do that. And the question now becomes, well, how do I get high level of confidence with autonomous remediation? And that's where at Qualys, when we innovated and disrupted this space a few years ago with the ability to bring out patching capabilities, native patching capabilities through our agents four or five years ago, we really learned through that process quite a bit. Just in the last year, we deployed 150 million patches at six sigma accuracy for our customers, and over half a billion patches deployed in the last couple of years. We have learned a lot with that. And I think the number one requirement for any autonomous remediation to not have issues is going to be hyper prioritization, which means just from a physics and a math perspective, the minimum number of things that you fix, the minimum number of potential issues that you have. So any remediation program that does not leverage the ability to hyper prioritize what actually matters to your environment is a non-starter. If you look at the good news, if you look at our recent report on the broken physics of remediation that you can download, we talk about how less than 1% of the billions of vulnerabilities that we looked at were actually exploitable based on threat intel that was available. Most of the vulnerabilities did not have a way to exploit. So the good news is that what we are talking about is less than 1% of the vulnerabilities need to be fixed quickly because they have exploits available or can be weaponized or are part of malware chains. We went one step further, and this is going to be the second requirement for any autonomous remediation: how do you prioritize that 1% down even further by actually running some of these exploits on your own code safely or your own system safely? So you know, before the attackers do, if this exploit will work in your environment or not. A lot of times you might have an exploit that works in a sandbox, but in your real world you typically have other controls that you have paid money for. You paid for EDR, you paid for firewalls. Are these controls blocking these exploits? So you don't have to fix them in an autonomous or emergency way. And what we found out with our TruRisk Confirmed capability and AgentVal, where we use agentic AI to run exploits on theoretically exploitable vulnerabilities, what we found out was that less than 20% of that 1% actually were exploitable in the customer environment. So talking about hyper prioritization, it cannot just be theoretical scores that are being given by these CEM solutions. These CEM solutions are just another dashboard that give you a random score that is not actually validated in your environment. So exposure management without the validation piece is useless, just as useless as it is if you're doing exposure management without fixing anything. So hyper prioritization by actually customizing the process to make sure that you truly identify the things that actually are exploitable in your environment is absolutely the step number one that is essential. The second thing to ask yourself is: now that I've identified these, are there opportunities for me to fix the issue or to prevent the exploit without deploying a full patch? Obviously deploying a full patch means more risk because you have an API that could have changed, some unexpected files might have changed. What we discovered, leveraging a lot of these frontier models as we are part of Project Glasswing as well as Daybreak and looking at Cyber 5.5 etc., reverse engineering a lot of these exploits, what we've been able to really figure out is that almost each one of these exploits has some form of mitigation that can be done on the machine that does not require you to actually deploy a patch immediately, especially for an exploitable vulnerability. So which means that with this approach, the next question after you hyper prioritize is: can I have an option that actually maybe I just disable SMB v1 on this machine? Maybe I just delete an old DLL that is going to be exploited? Maybe I just change the permissions of a file? We saw this with Red Sun recently for the Red Sun issue when it was a zero day. There was a very simple mitigation that was available. So now you can deploy an option that brings down the potential of an outage because you make a very targeted and small change. It could be change the port, change a firewall rule. So there are many things that you could do after that. The next will be: now that you know you have a certain set of assets where you want to apply a mitigation and a patch, is there a way that I can predict that this particular patch is not going to cause an issue, or if this particular patch or mitigation is going to be problematic? And that's where if there is a way to create an AI-based patch reliability score for new patches where you can predict the operational behavior of a patch, that can be significantly helpful in making sure that you are able to do this autonomous remediation. And that's where with over half a billion patches that we have deployed over the last couple of years, we were really able to go back and, and I want to be careful about using AI versus ML, we really leverage a model that we build using ML where we are actually able to look at a new patch that came out, look at which components it is updating, does it need a reboot or not, what is the historic trend of a patch on that operating system that updates that particular component, does it cause an outage typically, does it not cause an outage? And with that we can give you a significantly better visibility into the prediction of the reliability of a particular patch. And that becomes the core and the central component of making sure that you can actually anchor your remediation strategy in a high quality process that makes sure that you are hyper prioritizing, you are testing yourself with safe exploits. And by the way, a safe exploit means you could just set a payload that asks it to resolve a unique DNS name. If the DNS name is resolved, you can basically tell that machine was compromised, right? Can you then take it to the next level by applying mitigations and then making sure you have a patch reliability score? If we can do all of that. Now on top of that, if we can also hook into our application performance monitoring solutions or APM solutions like Dynatrace as an example, right? Where you can deploy a patch on a set of systems autonomously with say 10 systems, you can monitor your APM to see if the application continues to perform as expected for the next two hours, four hours. If it does, then you can deploy it on the next thousand and watch it for two hours. So there are many strategies like that that can really reduce the risk of an outage. And then ultimately, one of the things that we have done with our 150 million patches we recently deployed, we also have the ability to make sure that we can roll back the patch if there is an issue after you monitor it with an APM system. So I think accepting the reality that some form of autonomous remediation roadmap is essential. Can you take a risk-based approach to autonomous remediation is very important. You know, many CISOs just say, 'Look, update all my laptops and my desktops with Chrome or Java or Adobe updates, don't even wait for scanning for the work, right? Just go ahead and make sure that you can just deploy a patch as soon as a new patch comes out from the vendor.' So that gives us a way to take out, and like we talked about, attackers have to actually be successful in a chain of events. The more of these things we can fix autonomously, the chance that they will actually find all five of the vulnerabilities exploitable becomes a lot lower. They can exploit four, but the one that you fixed autonomously and proactively might be the reason why a breach is stopped in your environment. And that really is the approach that we need to be taking right now. It is not the end of the world. It is an opportunity for us to continue to improve the control that we have put in place, which is going to make things a lot better. And so this ability, of course, speed is very important, and the speed of remediation is very important, and that's what the autonomous remediation is going to be about. And by the way, you could do 80% of your stuff autonomously or 50%, and the rest can be done with the testing, etc. Either way, any improvement from where we are is a win to push the attackers back. I think it also highlights the importance of having a tier one scanner which is actually able to find the vulnerabilities in your environment within hours of the patches coming out or the disclosures coming out. I think the days of, 'Okay, maybe I have a tier 2 scanner that maybe gives me a signature after two or three days and I have to beg them to give the signature,' I think that introduces a certain amount of risk. Because if we are talking about moving from zero-day vulnerability to zero-day remediation to make sure that you can remediate in the first 24 hours or remediate autonomously in the first few hours, the number one requirement is you have to find it. And for that, please make sure as part of your autonomous remediation that you are leveraging a scanning profile, a scanning capability, a scanning tool that is giving you near real-time signatures, that is giving you quick signatures in a matter of hours. And anything where the process of remediation is not native introduces a certain amount of risk. So there are tools out there that will say, 'Oh, it will call your old tool that you already use for patching via API and then it'll do the job,' and it introduces a lot of risk when you are taking that kind of an approach if you're not looking at the reliability, you're not looking at those mitigation options. And I think with that, what we have been able to see is that what was really exciting is that 150 million patches we deployed in the last 12 months, 40 million of those patches are already deployed autonomously with zero human intervention in our customer base. What does that tell you? Which means autonomous remediation is not the future. Autonomous remediation is already here, and the forward-looking organizations today are already deploying millions and millions of patches autonomously with almost no outages. So we have to take a practical approach in terms of how we are going to address this issue, and there is no magic solution, but surrounding our processes to improve the speed with high quality information, leveraging AI, agentic AI, as well as good old hygiene to make sure that we are successful in breaking the chain that the attackers are trying to leverage, is going to be the key as we move forward. And so I look forward to getting all of your feedback as you go through the sessions today. It's a very exciting set of conversations, but please walk away from this with the confidence that you can go back to your management and say there is a way that we can start to introduce a roadmap for autonomous remediation as we look into the future. So thank you very much for your time, and hope you all enjoy the rest of the sessions, and look forward to seeing you in the next series. Thank you.