ERP124 - Security as a Utility

Welcome back to the Evolved Radio Podcast! In today's episode, I'm joined by Anup Ghosh with Threatmate. Anup and I deep dive into one of the MSP industry's hottest—and sometimes most confusing—topics: cybersecurity. But instead of focusing on the aftermath of a security incident (what they call "right of the boom"), we shift the conversation to proactive measures—what it really means to operate "left of the boom."

We unpack the concept of security as a utility, discuss how to utilize NIST and CIS frameworks, and explore fear-based selling.

This episode is packed with insights that will help you strengthen your security posture before disaster strikes. So listen in to stay ahead of the next big threat.

This episode is brought to you by Opsleader Pro. A place for MSP owners and managers to get the systems and tools they need to build a stable and growing MSP. Part group coaching, part peer group, everything you need to run a successful MSP.

What is Evolved Radio?

Evolved Radio Podcast: Interviews with technology experts, industry thought leaders, business leaders and other interesting minds. Exploring the evolution of business and technology.

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.