Centralized Risk Management with Shailesh Athalye | Qualys QSC 2023

This is Textron tv. Hello. And we're back at the Qualys Security Conference in the Americas.

And we're here with Shilesh Atalier, who is Senior Vice President for product management at Qualys. And we're gonna be talking about how all this new platform that they just unveiled for centralizing the management of risk actually works. Hey, welcome to show.

Hey, Thank you so much for having me. Alright. We have been collecting risk scoring for a long time from all kinds of different tools.

Yeah. And they often conflict. Now you guys are making an effort to centralize the management of that process.

How does that work and what are the implications for people? Yeah, great question. So what we could say is, uh, we'll, we'll divide that into two parts.

You know, um, historically all the security practitioners been dependent on the NVD provided the CBSS rating, right? Like our CIS provided. How important is this configuration of the system for me?

Now, when you wanna elevate that to provide that in terms of what is my risk from all of these vulnerabilities or my misconfigurations or all these, uh, issues, what I have in my environment, you want to talk the language of what you are giving the report to. If you are giving the report to your executives, they don't typically like the language of, Hey, this is the laundry list of all the issues, what I have. And then the question becomes, okay, what does it mean for me?

Uh, what's the risk for our business from all of that? The second part which became interesting is the security practitioners over a period of time been using the CVSS based prioritization. That sort of now became, as the data shows that almost 65% of the vulnerabilities are now prioritized as critical or high by CVSs.

That means the security practitioners, when they prioritize that and they give it to their IT team, their tough work call is now accommodating all of these issues and patching them. When all of these not necessarily are business important, then that means you're putting in your time, you're putting in your cost and and asking the IT team to patch something, which probably not, not any more relevant or risky. Now, the second part of the answer is that what is risk?

Right? Risk is something what is critical for your business, which is used by my business critical app. For, for example, if I'm Expedia, my checkout app or my airline app is most important for me, or booking app is most important for me.

So it is important now for security practitioners to tell the risk in terms of if I have any issues for this checkout app, if this for booking app, then the CISO would be like, Hmm, now let me look into it. The second part of the risk becomes when you get all of these indicators of vulnerabilities, misconfigurations, you need to map it to, if there is any threat known to anywhere in the world which can exploit these vulnerabilities, if any attacker is already exploiting it. In my industry, if I'm, again, if I'm in healthcare, if there any ransomware attacks have happened in healthcare using this vulnerability or misconfiguration or not, has any ransomware attacks happened using this vulnerability or ransomware or not?

So that becomes the second factor to enrich your vulnerability. And all of these are not considered by either CVSS or some of the other tools. And that's the problem we are solving with our quality tourist platform.

It brings in the context of what is business critical and if the vulnerability or misconfigurations is detected mapping based through threats and giving that context so that the security risk team talk the language. What business wants to, uh, look at is what is my cyber risk in terms of my business? And I measure, communicate and eliminate that accordingly.

So let's start with the business side. 'cause a lot of security people are challenged talking to those folks and they would clearly just want to crib the way that you are gonna describe this. So I'm gonna ask you very specifically, you show up, you present them with this number, and then they're gonna say, how is that number arrived at?

And I tell them what, Yeah, uh, you should tell them, uh, again, two things, right? One is, what is my risk right now in terms of quantifiable number? That's number one.

They don't wanna look at the laundry list. Now the second part of that is now un wheel that number, how we come to that number. And that's where Qualys approach has always been very transparent.

We came out long time back, 20 years back, just the SSL or certificate security assessment just free for customers where customers could come in and look at like, Hey, if my certificate is at risk and we provided them full algorithm, how we come up with this risk. And we have always taken that approach. Even our true risk calculation.

We keep our algorithms and our our calculations absolutely open for customers to look at and provide that to their management, their IT team to see that, okay, if there is a threat attached to a vulnerability, we crank up that risk by point 20. If that particular vulnerability or risk is related to your critical business app, then we crank it up by 50 points. And all of this is at the end of the day, like any risk scenario is customizable.

So if you don't like it as a customer, you can come in and tweak all of these parameters which go in this transparent algorithm as customizable parameter. And that way you can come up with the quantifiable risk score, which we can communicate across your company. How do you envision that change in the conversation between the security people and the IT people?

Because, and there's two communities in there. One is the infrastructure people and the other is the application people. Yeah, the infrastructure people generally, it's not in my database.

I don't know where this platform is, it doesn't exist and we don't have it, but it does exist. And the software people are like, Hey, we're not using that piece of code. But turns out you are.

Yeah. And here's how we show that. So how does this conversation evolve?

Yeah, it's, it's the, it's always the question of context, right? Like, and that's what typically has created the divide between the security and risk teams and the IT cloud or the app team, right? Security and risk teams job traditionally has been like, Hey, this is your dashboard and these are the issues and the job of IT and app teams being like, okay, what can I go ahead and patch it?

But now the problem is because the attackers are getting faster in exploiting all of these issues, it's absolutely important that both of these teams talk with each other with the context. And that's why the truist platform, if you look into it, the truist gets sent automatically to their IT or applications security team's tools, if they're using ServiceNow, if they are using Jira, if they're using Jenkins, we provide the true risk with the context of which asset, if it is running or not for the service, if it is business critical or not. And we also provide them what is in it for them.

So we tell them, if we take care of this risk, this is going to reduce our true risk posture by 20 points. So that becomes sort of a motivation for them. Like, oh, just these five things and we can actually reduce my truist by 20 points instead of looking into all these laundry list of vulnerabilities and all of these laundry list of issues.

So that creates basically the engagement between both of these teams for knowing exact targeted, truist prioritized things they need to fix with right context of how to fix and directly providing into their system to the owner of that asset or application. So they don't deny that, Hey, this is not running if this is not my issue, et cetera. Mm-Hmm.

So the context is what Truist provides to both of these teams. How do I know that the patch won't break something? 'cause most of the time when you deal with developers in it, that's their number one issue.

It's like, I, I'd rather take the risk than go be down. So how do I get confidence in the fix? Yeah, great question.

Again, like I, I have, I have sort of a philosophical answer as well there. And, and it, it's a, it's a, again, a two part answer of course. The business criticality, making sure that you balance your business impact, that your business continuity, uh, remains true, is absolutely important.

If that machine is a crown jewel, if that machine is absolutely important to run your business smoothly. But if you look into now the risk related data, our research data shows most of the risk. One third of the vulnerabilities are low hanging fruits are present on the machines like yours and my laptops.

Which if they go down, yes, there's sort of a risk, but if that ransomware vulnerability gets exploited on our laptop and goes laterally moved, goes inside to crown jewel, that risk is much higher. And that's what the security teams need to provide to the IT team. Like, hey, your true risk is much higher, but look at this, your low hanging fruits are these 33% of vulnerabilities which are not going to break systems.

And we do that with our now true risk AI insights where we talk about like, Hey, 90% of the customers have applied this patch and it has not broken their system. And by the way, 90% of these customers who have applied this particular patch is typically have applied to the desktops. So please don't apply this on server.

But on the other side, it gives them confidence that this has not broken even desktops. So that's the context we provide and the insights we provide for them to now safely go ahead and balance this business impact with risk reduction. And not every remediation requires a patch.

There's other things Mm-Hmm. That can be done. Yeah.

Can you surface that and 'cause there's lots of options. Oh, a hundred percent. And and to be honest, like our, our CEO talked about that in his keynote, we all talk about time to detect an issue.

We all talk about time to eliminate or remediate a vulnerability or an issue, but there's something which is extremely big, which a lot of our customers talk about is time to communicate and that time to communicate it gets amplified because like you said, the vulnerability closing is not just one patch. Sometimes it requires you to apply one patch change misconfigurations, or change your registry key. And that becomes sort of a disconnect where IT team says like, Hey, apply the patch you gave me.

And the security risk team says like, oh, I still see the vulnerability still there. And that's exactly what truist platform provides them in terms of knowing what exactly you can close the risk of the vulnerability. So our true risk eliminate is not a traditional patch or, or, or, or a uh, patch update tool, which takes the system from version one to version two.

But it is a very targeted risk-based, prioritization based risk elimination tool. I said risk too many times, but it's actually a risk elimination tool which tells them that you need to apply these three steps. It gives them those in their own tools so that they can quickly just go ahead, apply changes in either cloud for their applications or their infrastructure vulnerabilities in just one workflow and close the risk of that.

And by the way, if they don't like it, we provide also customization that they can actually customize the scripts in our platform. And those would be used to eliminate the risk if they want to use their own scripts. Alright folks, that's how it works.

But arguably the most important thing that he just said is we might have a chance to all get along with each other. That would be an interesting benefit right there. Hey, thanks for coming By.

Thank you so much for having me. Thanks.