Anoop, welcome to the Evolved Radio podcast.

Thank you, Todd.

Glad to be here.

Alright.

So, we're gonna be talking about, everyone's favorite topic in the MSP industry, security.

We're gonna take a a sort of interesting route on this as well.

But, you and I chatted about this, an idea that you would frame that I really liked, and we're gonna talk a bit more about sort of left of the boom, versus sort of a lot of conversations in our industry tend to focus on right of the boom.

And I'm a big fan of, the governance end of of security, which is, I think, something that doesn't get as much play as it probably should in our industry, and I know this is something I think you're passionate about as well.

And you had this idea around security as a utility, which I really love as a framing on this.

So you wanna expand on that idea for us?

Wow.

Security as utility.

That's a high level concept, so we'll we'll start out on the hard stuff.

So I think the idea is today, a lot of people think of security as an additional tool that you Right?

Like, hey.

It's discretionary.

Let me look at all these different tools and choose what I like, which is fine.

But I think the idea behind utility is you don't choose your, whether you want water this week, this month.

You don't choose whether you want electricity this week, this month.

It's just presumed you have it.

And, obviously, for MSPs, they are providing utilities.

They are providing core network infrastructure.

And so the idea behind security as utility is it's just part of what you have to deliver as part of your service.

And the only thing that's really, worth debating about there is what goes into that?

What what is foundational?

And I think that'll go towards the governance question.

Yeah.

And I think that that is a, I think, a very common question.

Right?

Because I often pose this to people of, yes.

Security is required.

We're much past the days of, you know, you've got firewall and AV.

It gets a lot more complicated than that.

But it does sort of get, a bit of an odd question of, like, what is the minimum that that people should instill and expect that their clients to consume?

Right?

So, yes, you need some type of XDR.

You probably need some type of asset monitoring and event management.

Does it actually go to having, like, a SIM tool, or do you need a SOC?

Should you enforce MSA?

Like, those are a lot of the most more common sort of catchy questions that people have of, like, well, is there a uniform answer to this?

Like, should you, as an MSP, take on a client that does not want to enable MFA?

Or maybe that's sort of a good place start as far as some of the fundamentals of that.

Right?

Yeah.

Great question.

And and this, in fact, this question is why I believe, NIST, US National Institutes for Standards and Technology, put out their first version of the cybersecurity framework because of the market confusion around what should go into a security program, what should go into a security stack.

And, the second, version was released last year, and it calls out five pillars or we call them five pillars of cybersecurity framework.

And, I'm not gonna go through them because they're better better left to Google.

But it does answer the question, what are my foundational pillars of cybersecurity?

The thing about the framework is it doesn't prescribe what you have to do.

It just says, here's the five pillars.

If you're not if you don't have a solution, in each of these five pillars, well, then you've got a gap.

Right?

I mean, that that's that's basically what it's saying.

And each pillar itself has a number of sub categories and and you can delve into get as complex as you needed.

Right?

If you're dealing with an enterprise or financial services institution, you'll really want all the subcategories filled out, or you can get as basic as needed for depending on your client needs.

So for, like, a typical SMB, like, and, again, like, this is a consulting answer as well.

It depends.

Right?

But, like, what are some of the basics that I think people should be expecting around sort of, like, beyond, some of the things that we tend to see as as just sort of a norm.

Right?

So you probably have some asset management.

I've seen some people confused around, like, what this actually means.

But if you have an RMM deployed and it's collecting, you know, at least asset information and maybe some SNMP information around sort of non agent deployed assets, then, you know, you basically got inventory collection.

Whether or not it's formalized in any way, like, yeah, you can probably check that box.

And I I see some people get a little confused around that.

But, like, I I I think there's some confusion about how to actually go about and what qualifies as checking the box on these things without some independent verification from a third party provider with some expertise around this, I suppose.

Right?

Yeah.

I mean, what on the asset side, the the core idea there is if you don't have inventory of what's on the network, then how can you how can you protect them?

Right.

Right?

So that is, really the first pillar of the NIST cybersecurity framework.

It's called identify, and it's identifying what are the assets on the network.

And what's important about that, at least to me, is it's not just the laptops and servers.

Right?

It's every, device with an IP address on the network.

You want to know what's there.

Right?

And so discovery of what's on the network is a key part of identify.

Right?

And that's that's that starts with the basics.

What do you have on the network?

Yep.

Once you know what's there, then you can begin to look at the second pillar, which is protect.

Right?

Protect is all the stuff you do left to boom to prevent an intrusion on that network.

Yep.

So NIST gets a lot of airtime.

Lot most people, I think, are probably familiar with that.

Whether or not they've sort of looked deeply at it and then have have established some policy and procedure around that framework or other, I tend to be a fan of, more of the CIS framework.

I I feel it's more consumable.

And maybe this is different.

I haven't looked at the sort of the updated, NIST framework, but, I found, like, a CIS feels a little more, modular.

Right?

Where you you you you can kinda look at it, and you're like, okay.

You know, how how intense do we wanna get around security?

We won't don't wanna do sort of, this giant spreadsheet of NIST.

We're gonna start with just sort of phase one and maybe phase two, and then we'll look at some situations where maybe phase three makes some sense.

And then there's other systems like ISO, seeing a lot of other organizations now looking towards getting SOC two certified.

How would you sort of if someone asks you, like like, what should I use?

Like, NIST is is pretty industry standard.

But is there sort of a place for CIS or ISO, outside of a client just requesting those in your mind?

Yeah.

Absolutely.

I mean, each of them have their place.

So this cybersecurity framework, we think, is a good place to start to take stock of your security program.

Right?

Again, like, what do you have in place as far as your security program?

What are you missing?

And, you know, you've got a lot of solutions.

So the first part about that is just understanding where do your solutions fit in.

If you have, like, Huntress or ThreatLocker or BlackPoint, etcetera, do you understand where that fits in the NIST cybersecurity framework?

Right?

And and that's typically detect, respond, recover.

To your point around, CIS, so CIS is prescriptive.

Right?

So NIST, CSF is a way of understanding what you have and, therefore, what's missing.

CIS is prescriptive, which is good.

Right?

And if you just want to, say, look.

We want our our clients' networks hardened to the best practices available.

I think CIS checks that box.

Right?

Because it says, hey.

If you've got Windows 11, desktops, laptops, we've got a standard that you can follow to secure those devices and also for Linux and also for macOS.

Great.

So now I can go to a client and say, hey.

I'm going to we're going to do an analysis, understand what you have on on those endpoints, where there are potential risks, involved, and then do some remediations to harden them.

And if you do that much and this is why not not just you, Todd.

I I think there's people in in our space that are now talking about getting to CIS compliance because it is prescriptive.

It tells you what to do.

It gives you something you can point at and say, we are meeting, you know, best practices in at least hardening our our endpoints against attack.

Right.

And and I think one of the things that I I feel often gets overlooked in some weird way is more sort of, you know, the shoemaker's kids go without without shoes.

And and not that people are being, sort of absent about protecting their own house, but I feel like it doesn't get the same level of approach and rigor, certainly around sort of policy management.

And I I feel like it's a really good place to start because, like, if you're gonna protect your clients, if there's anything you should be doing is is really hardening your own environment because Yeah.

You know, MSPs are a very valuable target because you hold the keys to hundreds of other companies.

So why hack one company when you can hack another and get access to a hundred other companies as a result of that?

And And we've seen that.

Right?

Yeah.

Some very scary events around this.

But I still feel like so many MSPs that I see are really very distinctly focused on client management and client security.

And if you ask them about their internal policy, like, they'll often tell you, you know, here are the things that we have deployed.

Here are a couple of things that that we do.

But they're pretty loose on the formalization and the policy around the management of this.

And I I think that's why this this whole idea of sort of this left of the boom appeals to me is what better place to start than Mhmm.

Formalizing and understanding your own security so that you can then take that and consult to your customers around, here's what we do.

Here are the basics that are required.

This is the things that that we're gonna implement for you.

Any thoughts on that?

I think you're absolutely right.

I mean, you should get your own house in order, and you should be able to present that to your clients and prospects that, hey.

This stuff, we're we're recommending that, you use.

We use it ourselves.

To give you a tangible example from this morning, I was talking to a partner of ours who said, hey.

Before I run this pen test on, you know, this client, I'd like to be able to show them, you know, what we did on our own network.

And so we went in and and take a look, at at the results from the pentest we ran on on their network, and it had some criticals.

And I said, I I'm not quite sure you wanna you wanna share this.

And he was like, no.

No.

I really do because we believe in that transparency with our clients.

And more importantly, it shows that even we will have issues.

And better yet, when I show them in, you know, the next report a month, we'll show them how we how we resolve this issue.

So that's that's almost radical transparency if you think about it.

But the fact that he was willing to show his own report from his own network to a to a client, I mean Yeah.

Maybe that kinda gets to some of the the sales tactics that I I'd like to talk about here as well.

Mhmm.

And, you know, interestingly, I've had some some sales, or some, security and sales experts on the past.

And I said, you know, okay.

A lot of lot of FUD is used in in the sale of cybersecurity.

Like, is is that is there a better way to do this?

And surprisingly, I've had a few people say no.

Like, FUD's great because it works.

Right?

What's your sense of, like, the the story that you shared there almost goes in a different direction in my mind is is just sort of stating the obviousness of, like, everything is imperfect.

We have to understand sort of how security gets applied and, you know, what good enough looks like.

Obviously, we need to cover some of the criticals, but, you know, again, more more sort of like a policy angle of, like, you just need to do these things.

Right?

Like, there's a certain way you build a house.

You have standards.

There's a certain way you implement security.

There's standards.

Right?

Like, more of a just sort of a a a transparent and and very kind of vanilla conversation about that.

But maybe that doesn't sell as well to someone who is not concerned or paranoid about security.

What's your feeling on sort of utilizing FUD as a sales vehicle for security?

I I don't like it.

And I don't think security vendors or our partners need to use it either.

If you look on the news, there's enough, you know, screaming headlines on security incidents that you don't need to add more gasoline on that fire.

What the way I like to approach it from a sales point of view is solving business problems.

And let's face it.

The the clients we're talking about, their primary concern is not cybersecurity.

It it really isn't.

Right?

It is if you're a dentist, it's making sure that the, dentist, application network is running.

Right?

If it's manufacturing floor, making sure that all connect through the network, there's no problem there.

So what they're trying to do is they're trying to do their business, and they're counting on you, the MSP partner, to do your job and make sure the network stays up.

Right?

So from a cyber cybersecurity point of view, it goes back to that utility, which is in order for us to make sure that you can continue to run smoothly, we need to secure this network.

We need to follow the CIS standard.

We need to do vulnerability discovery, and and patch management on those.

Right?

Those are all left of booms boom stuff.

I I something that really cuts through the noise on this one, though, is insurance.

Right?

So and that tends to be the driver, to the business discussion, which is when your clients are selling to their clients, and their and their clients are asking them for the the cyber insurance policy, that drives the business discussion.

Right?

And the and the cyber insurance questionnaires are quite rigorous these days, and they do require most of the stuff that you'll find in this CSF.

Right?

And so they come to you as as a managed service, provider and say, hey.

Can you help me fill this out?

Like, yeah.

Well, if you're on our tech stack, you're you're good, hopefully.

And then you just you basically identify all the stuff you're doing, and now you're solving a business problem.

Right?

And if you have a gap, like, you don't have cybersecurity awareness training, which is required in this CSF, it's also required for for cyber insurance, then you fill it.

Right?

It's just a business discussion.

It's not a, hey.

Did you know business email compromise you can lose your payroll?

Which is real, but that's that's the FUD part.

Right?

Right.

Versus you have to do this in order to get cyber insurance.

You need cyber insurance in order for you to continue to win business.

Yeah.

And I I mean, I've certainly seen a number of organizations getting denied cyber insurance.

And, you know, if you're not stringent about these things, like, there are situations where companies are being denied, policy claims because, either, like, they they weren't diligent about, you know, being accurate around the those those, questionnaires they have to fill out.

Right?

So Well you know, you need to be on top of these things.

That brings up another good point, which is, hey.

You you did the right thing in filling out the survey, but maybe you weren't precise enough or truthful enough.

And you have to be careful about that, for the point that you're making.

So give you a tangible example you brought up earlier, MFA.

Right?

Oh, do you have MFA, you know, deployed?

And you check the boxes.

Yep.

We've got MFA.

Right?

And and by the way, these questions are written like yes, no, binary.

They're not.

Right?

You could use the blank sheet of pay all the details.

Right?

So if you have accounts in your Microsoft three sixty five that are not protected by MFA, particularly a global admin, and you have account takeover on one of those accounts without MFA, even if you all the rest did and you file that claim, they they will likely deny it because that account was not protected by MFA.

And in your application, you said it was.

Right?

So that's super important to to get right.

Yeah.

That's exactly the situation that I heard about is, like, there was some account that they that was just overlooked that wasn't covered.

And I don't think it was even the one that got compromised.

It was just evidence that they're like, they they, the the they weren't accurate about the the management of the policy.

Right?

Which I think, again, gets to the sort of this whole point of kinda left to the boom.

Like, the reason that I think there's a few reasons why I think this is so important to focus on is is, again, like, right of the boom and management of those things is incredibly important.

And I think, like, doing tabletops, doing scenario planning, and being really diligent about what is the response to the the Holy Hell scenario.

But, you know, hopefully, in some cases, you don't actually have to get there.

And quite frankly, there's a great consulting opportunity in the governance and customer.

So I see this as it's not sexy work, but, you know, there's a lot of money to be made and a whole lot of heartache to be avoided in just spending a lot of time on it.

Right?

Yeah.

And and to build on that, so right at boom and maybe we should define these terms because we've been using them.

So boom is when the compromise happens.

The compromise can either be an adversary on network or it can be a malware detonation on network.

Right?

Left of boom is a timeline thing.

So left of boom is on the timeline.

Everything you could have done to prevent that boom, and right of boom is all the activities or technology are there to detect, respond, recover, etcetera.

Right?

So let's talk about managed service providers.

I would argue the remit for a managed service provider has left a boom, meaning your clients, whether they tell you or not, are expecting you're doing everything with the configuration management of that network to secure the network as best as possible, which goes back to the standards question.

Like, what is best as possible?

Will the standards define that for you?

Right?

Right of boom is all the stuff that requires a lot of security expertise.

Right?

Is there an adversary in the network?

Guess what?

That that takes some security expertise.

And a lot of managed service providers aren't trained in that or don't have a cybersecurity expert, so they will tend to outsource the right of boom stuff to the huntresses and black points of the world.

Right?

And then if you have a recovery scenario, that's, you know, again, that's a whole another, you know, talent in in doing the forensics and doing the insurance filing and doing the recovery of those devices.

So back to your point, Todd, is left of boom is where, as a managed service provider, you can go in and say, hey.

I will follow I will make sure you're up to standards.

NIST CSF, I think, is very good from a board governance point of view where you can say, here's where we stand across the board.

Here's how well deployed we are with these various technologies.

We got a gap here around MFA.

We're gonna correct that gap.

Right?

We have cybersecurity awareness training.

We're only 80% of the way there.

You know, we need your help client to get to a % with all with all the folks.

Right?

CIS, we've got a few endpoints that need some work.

We'll take care of that.

To your point, I think that's really expected from a managed service provider.

And as long as you're you're following best practices, you're you're in good shape and your client's in good shape.

Yeah.

I like this idea of more engagement with the customer and drawing them into some of the decision making because, you know, it's never perfect.

Right?

Like, hopefully, you're getting kinda 90% coverage, but it's certainly never gonna be a %.

And I sort of describe this as a security version of, uptime.

Like, I I'm an old, Citrix administrator.

So, you know, uptime and and, the presentation layer being blamed was always a big problem for me.

That's right.

But I always describe to executives like, look.

We can do five nines, but, you know, here's the price tag for it.

You go to Austin sort of whistle and be like, oh, like, maybe three nines is good enough for us.

Right?

So that that type of discussion has to happen at a security level is, like, here are all the necessary controls that are con kinda nonnegotiable, and here are some of the controls that, you know, some of our clients have and some of our clients don't.

And, like, I I will if you have some questions about this and understand how it fits your organization, let's talk about that.

But maybe it doesn't apply to you, and maybe we could save a few bucks here.

But recognizing here are the risks that that presents.

And I think, like, we tend to get this wrong in a lot of ways in the industry of, like, this is the prescriptive approach.

It has to be blanketed.

Every customer needs these things.

And there are certain providers where that makes a lot of sense, and there are cert certainly certain customers where that makes a lot of sense.

But that's not necessarily a broad brush that everyone can get painted with, so it requires some level of discussion.

And I think this is helpful to have those those, those consultative discussions with clients so that they kind of understand the risks and the the the costs associated with how much is enough and how do we make that decision.

Right?

And I and I think you you you want to have that discussion, and then you want to have those decisions documented.

Right?

So if you present I know you mentioned SIM and XDR as an example, and I would consider those higher end offerings.

And it it you know, what's oftentimes not spoken about that is the human labor that goes into monitoring those logs and alerting us.

That's where your real cost is.

Right?

Mhmm.

And I agree not everyone needs 24 by seven monitoring just depending on what kind of network it is and what's at risk.

Right?

But being able to say, hey.

We did an assessment.

You know, we we think, XDR is an option, but you may not need it for for for what you're trying to protect.

But maybe, Microsoft three sixty five MDR is is a good idea because most of your attack surface is on Microsoft.

Right?

Yep.

And so if if we're looking at the Azure logs and we're looking for, say, impossible travel scenario where you've gotta log in from Eastern Europe and you have a log in in New York at the same time, that might be something where we we do actually wanna say, hey.

Let let's let's stop this login.

Yep.

Because we know that can't be the case.

Example where you're you're making a risk based decision based on what's at risk and what the threat environment is like.

Yeah.

And I think that goes to the point of, like, what the manageable situation is in a lot of these scenarios is isolation is in in a lot of cases good enough.

Right?

Because then we can deal with this later.

Like, do do we need to wake some someone up at three in the morning in order to verify some security event, or do we isolate the event or the user and then someone at six in the morning can be like, oh, that's a false alarm.

Okay.

Click.

Right?

Right.

So, you know, the the timeliness of these of these events and what their response to them is is is sometimes pretty variable from client to client.

Yeah.

Yeah.

One of the other things, I I wanna get sort of your perspective on a few things.

You mentioned, pen testing, and, got a couple couple of things here.

I guess, like, the the fact that your your like, your company, has a fairly heavy, focus on this, and, like, this is a fairly crowded space.

And I'm curious sort of the thought process of of, how you guys approach the market and what the offering was and and what your thoughts are around sort of, the competitive landscape in in that area of the security security awareness and security event management.

Yeah.

And I I it it's an interesting time to be in the cybersecurity space, just because there are so many vendors and so many tool options, which frankly increases market confusion around what do I need to buy, which is kinda what we're talking about.

We we took the approach of how can we simplify all of that for for our clientele, which are managed service providers.

And so we have what we call a unified attack surface management platform.

What makes it unified is we we say, look.

You have a a set of attack surfaces.

Right?

And if you go back to the CSF asset identification, that's the first we do.

We look at every attack surface, external, cloud, and behind the firewall.

And the first thing is identify what all those devices are, and then we'll scan them to identify what the attack surface looks like from an adversarial point of view.

Right?

So that's vulnerability discover it's asset identification, vulnerability discovery.

Right?

And we don't just stick to software vulnerabilities.

So we look at all exposures.

So things like, do you have an SSL certificate expiring?

Because that matters.

Have you not set up your DMARC and SPF, correctly for that client?

Because if it's incorrectly set up, they can they can be subject to spoofing attacks.

Right?

And and and then other business challenges with email as well.

Do you have insecure services like you have FTP running on this website?

That's not a CVE, but it's an it it's an insecure configurate.

Yep.

Right?

So those users that we look at, MFA is another one.

We'll look at m three sixty five and Google Workspace because that's a significant attack surface.

And if your if your user accounts aren't properly secured, an adversary will take that before they use an exploit of a CVE.

So the reason for unifying it is we look at all of these security exposures.

We correlate it with threat intelligence, current threat intelligence, and we just focus you on the exposures that bring actual risk to that network.

So for example, if I scan a network, I will find typically thousands of CVEs.

But if I look at just the ones that have an associated exploit, it windows it down by about 90%.

And that's really significant because now to address risk, you only you focus on the ones that have an associated exploit, address those, and that will in turn raise we we publish the security score, and it it's highly efficient.

So instead of just doing patch management, you're actually addressing risk posed by an adversary.

And that applies across all these different attack surfaces.

Right?

So unifying it allows me to reason about where do I need to focus my efforts today?

And that's why we do cover a number of different attack surfaces.

Okay.

Cool.

And I think that that covers sort of the other question I was gonna ask.

And I feel like I kinda know where you'll head with this based on some previous answers, but I I'm kinda curious to get get your take on this is, a lot of MSPs, they're sometimes concerned about, especially vulnerability assessments and any type of, sort of threat assessment, of an environment, whether or not that should come from a third party with some independence.

And they they have some concern of, like, well, you know, if I'm the one sort of checking all the locks that I installed, you know, does the customer trust that?

I get it from, like, a unified view.

Right?

But what what's your feeling on sort of the independence of who secures the environment versus who verifies the security?

I I think that's more of a compliance issue.

So Mhmm.

Let's look at it this way.

As a managed service provider, you're responsible for the daily.

Right?

The day to day like, you're that daily driver.

You're there to make sure that if a new port opens, you know, someone opens up an FTP because they want to download a file or they're talking to someone.

You you need immediate visibility that this FTP port opened.

Now we we need to do something about it.

Right?

From a compliance standpoint, it is true that certain industries will require a third party, sometimes certified provider to validate slash audit that you're you're doing the right stuff.

And you'll know because, basically, that client will tell you that they need a third party.

But I would say, should you be doing investments every day?

Absolutely.

You should do that every day.

And that's that's what our platform does.

And it will tell you which ones of these you need to actually act on.

From a pen test point of view, I think there's still some debate on how often you need to do that.

And by the way, I I know sometimes people get confused.

What's the difference between a pen test and a vulnerability scan?

There's there's ample reason to do both.

The vulnerability scan will show you all the exposures you have on your network.

The pen test will then validate which of those, they can actually exploit.

Right?

So a pen test typically, when it succeeds, you have grabbed data that you shouldn't have access to.

You've created an account that you shouldn't have on a on a given asset, as an example.

You've logged in with an admin credential.

So running a pen test, we would say, you know, quarterly at a minimum.

Many compliance regimes require annual.

So so I think it's, you know, we we basically support any interval, but I I would think at least quarterly, you wanna do a pen test on your on your clients.

And by the way, very useful from a revenue and sales point of view is to run that run that discovery, so you understand what's on the network, run the discovery, vulnerabilities, and also run a pen test, and you'll have a really nice cybersecurity risk assessment for that prospect.

Yeah.

Kinda goes again back to this, the policy and governance of more data, faster data, more frequent, that keeps you on the left of the boom.

Right?

Right.

The better job you do left of boom, the fewer incidents you have to deal with right of boom, which, by the way, only, like, forensics in IR teams actually like that.

Right?

No one else wants to be in an incident response scenario.

Yeah.

Even the guys doing the work, I'm sure it's, you know, it's still stressful regardless of Yeah.

Of of sort of the scenario for sure.

The other part, I guess, like, kinda relates to this as well is, the this can be a lot of work.

And I think that's partly what scares people away from the governance aspect of this is is it's not an expertise.

I think that that's easily remedied by some training and some experience in getting involved in these things and spending time on it.

But, you know, it's it it feels like a lot of work to do this on on any regular cadence, and that's where I think the tools can be helpful around this automation of collection.

Right?

And Correct.

Like, tools like yours where you just sort of says, here are the parameters.

This is this frequency.

These are the networks.

This is the assets I wanna check.

It just kinda does those things.

And instead of kinda having to have events where you're like, oh, okay.

You know, it's third of the month.

I guess we need to do all of these, execute on all these things.

Like, you have a tool that just spits back reports for you, and we'll know you'll know when there's an exception rather than kinda have to comb through and find things.

Does that makes is that am I kinda understanding that right from a private from an automation perspective?

That's exactly right.

It, the automation part is built into the platform where it'll automatically, not only do the scans, but also do the analysis.

That's a big deal because it used to take a vulnerability, you know, management expertise to figure out what this is and what to do about it.

And we do that all, we we do that analysis using machine learning.

And then we use generative AI to build out the solution and tell you.

And then, it's risk ordered.

Right?

So for today or this week, here are the key things you need to work on, and remedy, and here's the solution.

Because if you do this, that's where most of your risk is.

Right?

So I think that automation is super important.

The other thing it gives you is reporting back to your client, which we know is super important.

Right?

Because when you meet with your client monthly, or quarterly, you wanna be able to show progress.

Right.

And this is a great which you could say, here were the vulnerabilities we found.

These were the ones we remediated.

Here's what your score was before we did it, and here's where it went up to.

And I think that being able to show what you're doing for your client to secure them, they don't need to know all the details of all the CVEs and what are criticals and what are mediums and whatnot.

But they do wanna know that you have their back and that you are, in fact, managing the risk of their network.

And being able to show that in a report is a really good way to communicate that.

Yeah.

I like that idea of of the progression.

Right?

Like, I think there's reporting that isn't as valuable, but if you're able to demonstrate progression or at least the the the maintenance of that.

Right?

It's for some period, it may be, you know, we were at 70.

Now we're at 88.

Now we're at 95.

And then at that point, distributors are like, we're we're maintaining between 95 and a hundred.

We're doing our best, and that becomes a just a quick update rather than sort of that progression that you move through.

Right?

And by the way, that is one of the differences to write a boom.

Right?

So if I'm paying someone 24 by seven to monitor my network for threats and they never find anything.

That's actually good news if you think about it.

Yeah.

Right?

But then you ask the question, are they looking hard enough?

Right?

Are they seeing everything?

How do I know?

Right?

Yeah.

Left of boom is actually the blocking and tackling that MSPs do.

And to be able to quantify that with KPIs and say, here's all the stuff we did for you, and here's how we've improved the security.

It's like managing other parts of the business.

Right?

You just wanna be able to show, here's here are the issues we found.

It's like you said, code.

Code on the house.

Right?

We're building the code, and here's the proof points of all of that.

Yep.

Fantastic.

Well, I appreciate your time, Manu, and, thanks for for sharing a bit of insights and keeping us, safe on on the left side of the boom.

Any last, bits to share or anything we haven't covered?

Well, I think, you know, keep looking at the compliance side of this and the governance side of this, the cyber insurance side of it.

It is driving the right kinds of decisions, I believe, that, MSPs will make.

And and and that's because there's money at risk.

Right?

So anytime you have money at risk, smart people get together and they say, how do we reduce that risk?

So I think it's super valuable to to continue to look at the NIST CSF, look at, CS compliance.

It will guide you down the right path for what you need to do for your clients.

And, obviously, at ThreatMate, we're glad to help on the left of Boom side.

But thank you for your time.

This has been, very helpful, and I hopefully enlightening for for the audience.

Great.

Thanks for your time.

Take care, Anoop.

Thank you.