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.