Venky: One of the data we have is it takes about 250 to 300 days from knowing a vulnerability to fixing them in code through the assessment. And that’s probably because it’s not in their control. There are too many third-party components they integrate with that are just part of the app Stack.”
Do you think virtual patching has a role to play here through a web application firewall that has to be an integral part of the app Stack?
Sunil: Absolutely. And the numbers that you quoted, I kind of completely buy into that. And the complexity is both your first-party application and the third-party applications.
For the 1st party applications, having a software bill of material (SBOM) for all places using the vulnerable version of Log 4j. Are you using the vulnerable constructs of the log 4j?
That’s a very easy question to ask, very difficult to answer. Because, first of all, you don’t even have an SBOM. So how do you go about doing that? That’s one aspect.
And then the third-party products or the software you use within your stack, finding out that dependency tree, whether they are using one of the vulnerable constructs, is also a fairly uphill task.
Once you have that visibility, you discuss the second challenge set. Now, who is the owner of that application within your company. You can get it into part of their sprint cycle that needs to be fixed by this timeline. Because that’s an internal organizational challenge, there’s no clear application mapping for the team.
If it’s a monolith, it’s even harder if the microservices and you have good attribution. But yeah, but very few companies have reached that set of maturity.
Most of them don’t have it, and I can completely buy into it because you cannot wait for those 200-plus days for the vulnerability to be sitting out there.
So what do you do? You apply a virtual patch in your WAF so that at least you applied a patch. You stop being vulnerable, you stop the bleeding, and then you have time to fix the core issue.
I’m a big believer. Whenever we do evaluate a WAF or a WAAP, we upfront ask,
- Do you have virtual patching capability?
- And if you have it, are you responsible for creating those rules?
- Because my internal folks might not know how to create rules for your platform, will you keep me informed?
- Will you apply the virtual patch, or will it appear in my admin console as a one-click application?
So those are all the set of things that we do consider before we want to go ahead.
Venky :I will also add one more point to that. The virtual patch benefit is not just time to fix the benefit. I mean, the time to fix benefit is certainly a very compelling benefit you immediately get because to under 250 days, and you get it within a day here. Still, it’s also an intelligence-gathering benefit of our hacker intent.
Because what does the hacker do? They also try to find a vulnerability and then target and exploit it. And now the virtual patch is there. It’s doing two things. One is preventing that exploitation doesn’t happen. But when that virtual patch policy gets set, we know whom we are dealing with on that session, identity, and IP is the hacker on the other side.
So we can probably dynamically increase our defense posture without worrying about false positives for those whose attack intent is established.
Sunil: Absolutely. And for platforms like yours, I’m sure just the way we find an issue, and once we fix it, all our customers benefit. I can see the corollary for you guys that once you know that a hacker from this set of IP addresses is trying to poke Customer X, you can include that as part of your blacklist of IP addresses.