AI Shrinks the SAP Patch Window to Hours

Hey guys, thanks for the throw. We're talking with Ivan Mans, who's a co-founder and a board member for SecurityBridge, and we're having a little chat about, well, what's going on with vulnerability disclosure in SAP environments because like everywhere else, the number of vulnerabilities being discovered is way up, and it's not quite clear how we're going to handle all the remediation efforts that go with it. Ivan, welcome to the show.

No, thank you for having me, Mike. It's a pleasure to be here. I think no one's actually come out and said that we are using AI to discover more of these vulnerabilities, but we have noticed that the size of the patches being rolled out are much bigger, so we can make some assumptions about how that's occurring.

My question to you is, are organizations prepared to kind of absorb that level of remediation? And ultimately, do you think this is just the new way things will always be? Or at some point will we get through some sort of, I don't know, catharsis where all the vulnerabilities that can be discovered are discovered?

No, I think at first, and I can confirm because we do run a research team, we actually use AI to discover new vulnerabilities. So researchers are actively using it. So that's probably one of the reasons why we see there's a bit of an increase in the number of vulnerabilities out there for SAP.

Now, the second part of your question then, are companies able to deal with it? Unfortunately, it's a clear fact that we see every single day with our customers, unfortunately not. We still see a lot of customers having patching debt.

Sometimes we even get to see customers that have not applied solutions to vulnerabilities which are known for years. Now, with the number rising, that problem only becomes more problematic. So every single day, we are having conversations with organizations to see how can we make your patching cycle more effective, how can we shorten the time from disclosure to actually remediating it?

And that's always a challenge, especially with complex applications like SAP. Right. So SAP apps are some of the most critical apps in any business, and a lot of things revolve around those, I guess we'll call them systems of record.

There are probably other apps in there that are collaboration apps, but SAP is well known for their system of record. But are these going to be targeted more in the age of AI because, well, they are such a rich, juicy kind of target, and if there's that many vulnerabilities, and correct me if I'm wrong, but the bad guys are using AI too, right? Yeah.

True, and they're using it without guardrails. So, I think the risk will continue to evolve. Now, SAP systems, until quite a few years ago, were really back-end systems with hardly any internet or network connectivity.

Nothing was actually publicly exposed. Meanwhile, also, SAP systems have evolved quite a bit, and the vast majority of SAP systems do have a working network connection. So, and as soon as you have that working network connection, you become vulnerable.

Now, again, until a few years ago, you had to be a real engineer to really understand SAP. So even if there would be a vulnerability, the way to exploit it would have been very difficult. Now, the drawback of AI is it made it very easy, even for script kiddies.

It became actually doable to breach SAP systems. So as you look at all of this going forward, what's to be done? Do I just need to have some sort of continuous patching system in place, or is there some other way to think about applying the controls around the SAP environment that maybe I can protect it still without necessarily applying the patches?

What's my exit plan here for getting out from underneath all this? Yeah. I don't think there is a true exit plan.

I think the only solution would be you need to reduce your patching window from, sometimes we still see organizations applying a patch window over months, not just a days. We're literally talking about hours. As an example, our research team, they have weaponized seven vulnerabilities in the last three months using AI into a working exploit.

And so it's relatively simple nowadays to reverse engineer vulnerabilities. Now, an organization needs to reduce the patching time, but you can never run quicker than a bullet. So there will always be a point in time where you just can't keep up anymore, and in that case, we need to look at some compensated controls.

We need to put in more hardening standards. We need to look at isolation. So there are many other mechanisms, but SAP customers would have to evolve to almost immediate patching.

Mm-hmm. Without a question. A lot of organizations don't patch immediately because, well, they're afraid of the patch, and they're concerned that the patch will do more harm than good in the sense that some application that the business is counting on will be taken down.

So how do I wrap my head around what to patch, when to patch, and do I need to move towards real-time patching? And if that's the case and something goes wrong, how do I roll it back? Yeah.

I think the fact that a lot of SAP customers, they're a bit afraid to apply immediate patching because of the side effects. That probably has a bit of a historical reason. In the SAP space, there are two types of patches.

You've got patches for functional issues within the software, and you've got patches for security issues. Now, whenever we are resolving functionality issues within software, you need to run through rigorous testing. You need to have a testing cycle, and that will take time.

Now, when we apply fixes to vulnerabilities, typically, these are very small patches. They're quite easy to test as well. They do not necessarily need to run through the entire process of testing.

Let's also not forget, SAP applications are huge, and most customers only use a small subset of the functionality that the entire platform actually has. Now, if there is a vulnerability that is residing in something that you're not using, it doesn't make any sense to test. You can almost apply a hotfix and just run that through your landscape in order to secure it.

So I think historically, most organizations have a three-month patch cycle. Nowadays, we see organizations having a certain security maturity. Whenever we talk about a CVSS rating of five to nine, so really hot news notes, they do manage to apply a fix within three days.

But even that is still on the short side. It's still too late. Mm-hmm.

So, I like your suggestion. Move to that nearly almost real-time patching like your phone. So to your point about that, a lot of organizations that are running SAP that I know are several versions behind, and they've customized it heavily, and there's a lot of custom code floating around.

And does that just make them more vulnerable, and should they just be running the latest, greatest version of SAP in the hopes that SAP is staying on top of a lot of these issues? No, I don't think so. Whether you run the latest and the greatest, because even the latest and the greatest will have new vulnerabilities that have not yet been discovered and disclosed.

So to me, the way we see it, it's a bit independent on which version of SAP you are, and because there's always a difference between the version of the functionality and the patch level of the system. So whenever SAP releases a patch, it will be valid for multiple versions. So that really is not really the, how do you say it in English, the denominator.

But, and here I lost my language a bit. No worries. How quickly are the adversaries starting to come up with exploits in the age of AI?

Because I think we usually count on the fact that it would take them months to create an exploit after a vulnerability has been disclosed, but it looks like that that's now being reduced to days and hours? Yeah, that's correct. As at the beginning, also, our own research team, we've done the experiments, and we did weaponize seven vulnerabilities in three months.

So we had three SAP patch cycles, and seven of those vulnerabilities, we just reverse engineered them using AI and turned that into a working internal exploit, just to proof case. But it really went from months to hours. Correct.

And we also used to count on severity rankings for determining what to prioritize when it came to vulnerabilities. But as I look at what's happening now, it seems like the adversaries are also getting better at chaining together a bunch of lower-level vulnerabilities to come up with something that's a little more lethal. So is this whole notion of scoring of vulnerabilities kind of becoming obsolete?

I'm not necessarily saying it's obsolete, but we should not entirely rely on it. I know there is a big debate upon, how relevant is the CVSS rating, really? The way we see it, even if you have a vulnerability that has a medium severity rating, and as you say, you would chain them up, you would end up in an attack chain that has a very likelihood to manifest.

At the end, it all depends upon what do we see in the wild. Have we already seen exploits? 5 is less critical, or at least our advice towards customers would be less critical compared to an eight, for which we have seen an X number of exploits already.

So it's a combination of multiple things that we see. " I still see people spending an enormous amount of efforts and money in trying to harden roles and authorizations in the system. And they forget about applying patches because they just say, "Patching is not our responsibility.

" And that just drives me mad. So patching should be the very basic thing to do, and thereafter, you can look at your hardening, you can look at your compliance, you can look at your custom code vulnerabilities, et cetera. To your point about that, do we need to maybe reorganize the way we are structured within these IT departments?

Because there are people who are in charge of managing the applications, and then there's security people, and everybody else thinks that somebody else is doing something, and then odds are good that nothing happens. So is part of the problem just the way we are structured and maybe, we have met the enemy in the mirror every morning? Yeah, true.

But I think also historically, since SAP systems are applications, they were not at the forefront of IT security. And so we ended up with silos. Securing SAP was an SAP task.

It's not an IT security task, and that is now changing. And we now see CISOs of the C-suite, they also have an eye on these high-severity vulnerabilities that are being published. So we do see that IT security teams now take ownership and responsibility for patching, whereby in the past, that was not the case.

There was a pure SAP responsibility, which is very often a bit of an isolated team in an organization. So what is your best advice to organizations about how to deal with all these issues as we go forward? Because I think a lot of them have a certain sense of being the proverbial deer in the headlights, and they just don't quite know what to do next.

Well, I think first and foremost, patch. Keep an eye on your patching debt. Keep an eye on SAP patch day every second Tuesday of the month.

Make sure that your team applies as soon as possible all the unpatched vulnerabilities. This is where it all starts. In parallel, you need to make sure that your system has a good hardening standard.

You need to apply all best practices. SAP has written an amazing document that describes how to run secure SAP operations. And then as a third component, monitor.

Make sure that you monitor, because you will never, ever be able to reach 100% security. There will always be zero days that no one ever knew of, and you may be hit with one one day. But you will see certain signals within your environment.

And if you apply real-time monitoring, you can also apply real-time response. So there are ways to isolate the incident, to disable users, to whatever mitigation you apply. But there is also a way to also respond at machine speed.

So if you apply patching, hardening, and monitoring, I think you'll be quite well off. Do you think at some point the system will get smart enough to understand what patches need to be applied and how automated can all this get? " It's not just an idea of the future.

That's what we do every single day. It's exactly our software that will tell the customer, "There is new vulnerability. It's applicable to these and these systems.

Your risk rating is already very high. " Now, you can decide whether you want to apply that manually, semi-automatically, or even fully automatically. But it's a long journey.

Customers are still in that phase to understand that the fixing is less impacting than not fixing. Mm-hmm. Which historically has been different.

Do you think maybe governments around the world are getting tired of this? Because historically, it was always, let's not blame the victim here, but at the end of the day, maybe governments are going to start saying, organizations, mandates that begin with the two words of "thou shalt" or else. Yeah.

But I think this is also where legislation helps. Accountability becomes important. If you do not do your basic housekeeping, and for me, patching is basic housekeeping, you also are to be held responsible.

And so we do see a big drive from legislation that will really make businesses more secure. So as you look at all of this, what's that thing that... A lot of it is just fundamentals, but is there something or one thing besides applying the patches instantly whenever they're available, that you kind of just wish organizations would do as it relates to SAP to improve their overall security hygiene?

Well, I think baselining. You need to do the minimum. Often we see, yes, there is a vulnerability that can be exploited, but if you would have done your system hardening, it may be that exploit would never, ever have worked.

And so you need to do your basic security. Read and apply all best practices. It will automatically reduce that attack surface.

Now, besides patching, sometimes there is even a workaround, and often applying the workaround is a lot easier than actually fixing the issue. If we go back to the example, if there is a vulnerable service that would allow a code inject, but you're not using that service, why not just quickly disabling it? Make sure that your organization is prepared to apply a quick change to the system, even during running operations.

Often a lot handier and a lot quicker. All right, folks. Well, you heard it here.

On a certain level, it's not rocket science. It's a commitment to security that's required here. And ultimately, with SAP, that's a good place to start, because I promise you that one of the first places that attackers are going to look for is, well, where's the most valuable assets?

And chances are, they're in your ERP system. Hey, Ivan, thanks for being on the show. You're welcome.

Thank you. All right. And back to you guys in the studio.