How MSPs Can Approach Vulnerability Management & Succeed

And we're on for episode 88 on the cyber call. Welcome everybody. We have a fantastic guest today. He was on actually cyber call number one, um, where I tried to do this frenetic pace. Oh, there's Wes, um, of trying to get, I don't know, like seven companies on at once or seven topics on at once. Gary, with the intent that we were gonna do it in a half hour, that, that's worked out pretty well, huh? Yeah, exactly. Hey, Wes. Wes, What's going on, friends? All right, there you are.

Just so you know, Wes, you're late, you're on probation. I deserve it. I deserve it this time. Yeah. Oh, too funny. Hey, Mindy, welcome. Okay, so, um, few quick announcements. One next week. We are on the channel program. The link is below. You'll see it, it says CISO Summit. Um, so take a look at that. We're gonna have the four CISOs. Ryan will actually be in the hot seat versus the other seat. Um, and, um, I got some links. I'll, I'll pop into chat shortly.

Um, just kind of setting the stage here, I just thought it was of critical importance right now, um, to have Steve Carter our guest on who I'll have him introduce himself momentarily. Um, more than ever, when I talked to Chris Laer, and I think I probably mentioned this last time on the cyber call, um, he is seeing common unpatched vulnerabilities as his number one, um, as the number one reason he's, he's getting called in.

This isn't, you know, Wes, you and I have talked about this and, and I'm gonna put in our cyber cast where you and Ryan and Phyllis did a phenomenal job on control seven, which is continuous vulnerability management. It, it is hygiene. And Wes, you talk about it in that, of, at that particular episode of, hey, dental hygiene. Um, so this is getting a little like, to me, um, something that Gary, I'll point to you that we're gonna have to figure out how to build into our offerings.

This is hatch management, quote unquote. This is gonna have to be a table stake 'cause it's getting messed. Yeah. And what I'm gonna say to people, if you can't do that, like save your money on all the rest of this stuff, like you're spending another 10 or $12 a seat for advanced security, like put that money into doing your basics and then start adding your stack on top of it. It's like you're building a, a moat, but there's a bridge across it and you're not addressing it, right? Yeah.

And you know what we're gonna start to see on the insurance front, I know this 'cause I'm having the conversations as we speak, is you're gonna have to provide evidence of, of patching. You're gonna have to, they don't care who and how you're using it. They just want to know that you're going to have to provide evidence. Uh, so the game is starting to change for sure. The other thing to that last, last point is they're, you know, the defense attorneys aren't dumb.

They're gonna say, do you patch windows? Yes. Do you patch common applications? Yes. Why didn't you patch their firewall? Oh, well, they weren't paying for it. Not a good answer. They're not qualified. Right. Gary? Your customer isn't Qualified. Yeah. And guess what else? I, I talked to an MSP about a month ago. One of their customers had an issue and it was through a patch vulnerability. I'm like, aren't, why weren't you patching?

He's like, well, we were, but we didn't realize that our agent wasn't on that workstation. I'm like, okay, that's probably not good. So step one, listen to Ryan and make sure you know all your assets. Step two, patch them all. Yeah. Ryan, um, kick us off real quick here as we go into Steve's intro. You were messaging me earlier. Speaking of patches, can you talk to us a little about Cyclops Blink and what that kind of, how all that vulnerability's been around? You're, um, you're muted.

Uh, hold on. All right. Before even we can't get him off mute, you go off, you fix that, Ryan, and in the meantime, I'll have Steve introduce himself That, Oh, you're back. Okay. Steve, don't introduce yourself. Ryan, go ahead. Talk to us about Cyclops Blink. Um, yeah, so we, we talked about Cyclops Blink in the, uh, in the, uh, cyber call two weeks ago on Ukraine conflict. Um, in relation to, uh, their, a lot of us are probably familiar with, uh, DDoS botnet known as BPN filter.

Cyclops Blink is believed to be the next variation or variant of VPN filter, um, hot off the presses. This this group is, uh, affiliated with the threat group known as Sand Worm, who was known to attack the pyeongchang Olympics, the French election, and be the group behind not so very, very capable threat group affiliated with the GRU out of Russia.

And recently they leveraged a vulnerability in WatchGuard fire box appliances, I believe they're called, um, that had been patched back in May of 2021. And in November of 21, they started working with the FFBI because 1% of those appliances had started to be seen participating in the Cyclops Blue botnet, which subsequently has been used in, you know, in the Ukraine conflict for DDoS attacks.

And so, uh, that this one's really interesting because one, the exploit isn't possible unless you change the default behavior of the appliance to allow all internet traffic to your management interface. I believe might have to correct me on that one if I'm wrong, but the other thing was this completely avoidable because you could just have patched the firmware within that six months and been totally fine.

Uh, and so, but this, you know, going back to what Chris Lair said with SonicWall and Forti Gates, um, these internet facing appliances, these network appliances are becoming really high value targets, both for initial access brokers, ransomware as a service affiliates and D os botnet operators. Um, so in my opinion, you need to be starting to think about patching those on an at least quarterly basis. Um, I would say monthly, but monthly can be difficult to test and release at scale.

And by the time you finish, you're doing it again. And so you definitely need to tighten up your, your, your test and release process as quickly as you can. But yeah, a lot of these attacks really, really easy to, uh, to prevent just by keeping your software on your remote access gateways and your firewalls up to date. Wes, I'm putting in, uh, also the cyber cast with, uh, on this, and you mentioned Colonial Pipeline in there. Speaking of, you know, internet facing, right? Yeah.

I mean, going back to hygiene, um, and we've seen this time and time again, like Colonial Pipeline is no exception to this, but, um, it certainly continues to point out this, it doesn't take a lot of skill to do these crazy things. I saw a meme shared with me this morning, and I wish I remembered who sent it to me, but it was so sort of like, you remember the good old days when bad guys were like reversing and doing some wild, crazy, uh, insane things.

And today, you know, this day and age, um, boy, they can shut down an entire gas pipeline simply by, um, reuse credentials on a firewall that was supposed to be de I mean A VPN that was supposed to be decommissioned, I mean hygiene that should have been in, in, in place there. And they even admitted, yep, we, we did decommission that VPN server, but we failed to actually take it offline. Uh, what does that tell you? It tells you their offboarding procedures have some major gaps inside of this.

And, uh, you know, just yet another example of, um, boy, it doesn't take a lot of skill. It takes a lot of luck and fortuitous timing, um, and some amount of targeting to do some of these things without anything, um, really scary on top that, that, that should be concerning to us. Cool. Thanks for that, Wes.

So, um, Steve, I was gonna say like, why this is so hard, Andrew, let's take it back again to looking at, I'm, I'm a, uh, IT director and in a company and I have a team and we have 500 end users, right? And four locations. Now I'm an MSP managing 500 seats. I got 20 customers and 20 firewalls and 20 environments and 20 different sets of applications and process.

And many times my MSP, the number of people I have might be smaller than what that 500 company has as their IT department, and they have two people focused on security. So this is a challenge, like this is why we're saying our business model has to change. So that we, our whole thing was from beginning, Hey, guess what?

We deliver the kind of tools and process and experience that no one of our customers could get, you know, that only you could get it if you were a, you know, a mid-market enterprise company. Well, we have to actually do it. Yeah, yeah, no doubt we could, Steve, we could go on and on and we'll be at the end of this before we even introduce you. That's Alright. It's a great conversation. Sorry Steve, we're all fired up now, Which Is perfect timing to bring you in. Steve. Steve, welcome.

Uh, you, you're not only a great friend, but, uh, uh, you run an incredible business and, and I'm really happy how much you guy, how how successful you guys have been. So welcome. And, and with that, Steve, talk to us a little about your background, uh, and your current company. Yeah, sure. Well, first, thanks for having me here again, Andrew, uh, I guess almost two years later, something like that. Yeah, Yeah, yeah. Um, so yeah, just, just a bit about me.

I, I spent the majority of, of my career, um, helping government agencies build and scalable vulnerability management programs. And probably sounds a lot sexier than it actually was. Uh, but after about 15 years, I started a, um, I guess kind of a hybrid MSSP slash defense contracting business. Uh, that was in 2015. It was called Rampant Technologies. And that was really where I first began to work with the private sector for the first time.

Up until that point, it was all just kind of the feds and, uh, and so I started working mostly with, you know, mid-market and, and small to mid-size enterprises. And, and I found that super interesting because I started to notice that a lot of these smaller organizations have a lot of the same vulnerability management challenges that large agencies have, and maybe a little less magnified, but, but the same kind of challenges nonetheless.

Um, so then in late 2018, I started a new company called Nucleus Security to build, um, a vulnerability management platform that I felt like was really just missing from the market. And so today I spend most of my time, uh, running nucleus and, um, and really just helping to automate what I like to call intelligence led vulnerability management.

And so our customers are really a blend of both like large and small, uh, enterprises in addition to MSPs and some MSPs who are offering, uh, vulnerability management services to, uh, you know, other small businesses. So, uh, like I said, really excited to be here and, and excited about this conversation. 'cause I see personally I see vulnerability management through this lens of, you know, middle market and large enterprise.

And I believe you guys kind of see it more through that lens of the s and b space. And, but I, I, you know, I think a lot of the innovation that's happening to Gary's point, but the innovation that's happening, uh, in this space, upmarket could be super valuable and applicable down market to Ms. MSPs and MSPs and, and yeah, that's, that's super exciting stuff. Yeah.

I, as we get into this, um, I hope you kind of maybe just share your perspective on, on, you know, what it is that you guys do and why it's not just, you know, a scanner. Like you're dealing with multiple environments. So maybe pepper that in there when we start to talk about prioritization and things of that nature.

Ryan, as, as I turn it over to you to kick things off here with Steve, Gary's last comment kind of dovetails, I think into this first thing, which Gary, you're, you know, you, you talk often about, you know, and this is Sunil, you people in process, right? Mm-Hmm. And Ryan kind of talked, this is about roles. This is about, you know, having some kind of process and it starts off with policy. So Ryan, over to you on this. Yeah.

So CIS controls, which everybody knows we're a fan of here on the cyber call, uh, begins with establish and maintain a vulnerability management process highlighting the word process for MSPs and their clients, right? So let's start with do you, do your clients have a vulnerability management policy? And what are some of the items that go into that policy that drives your process? Yeah, yeah.

I would say most organizations that, that we work with today do have at least some form of a, of a documented vulnerability management plan and policy. Um, in, in some cases it's, it is, um, very much a living and breathing kind of kind of plan, but in more cases than not, it's, it's really just kind of a dead plan that's, uh, that's in the process of being resuscitated. And, and that's why, you know, we're, we're involved as, uh, as nucleus to, to kind of help out there.

Um, but I think there's a lot of reasons. And, and one of them is that there just really aren't a lot of good examples, uh, of good vulnerability management plans because the plan, uh, you know, a good plan is gonna look different for, much different for a small organization than a larger, you know, thousand person organization and, and much, much different for a 10,000 plus person, person organization. So, so there just isn't, you know, there's not a good template you can grab out there.

There's not a lot of content out there and guidance, uh, on what a good plan looks like. Um, but really to, I think to your second point, like what are the key pieces? Uh, I, you know, the first thing that always comes to mind is just defining how you, how you do, uh, vulnerability discovery, right? And this is really, you know, vulnerability scanning to start with.

Uh, but it could also be things like, um, bug, bug bounty programs and vulnera, vulnerability disclosure pro programs, DDPs, um, it could involve third party pin testing, things like that. And so defining the, the scanning tools that you're using, uh, the scope of the assessments that you're doing, the schedule, uh, like you guys talked about for, you know, scanning and passion and things like that, uh, that's, that's obviously like a, you know, one of the core pieces of a plan.

Um, but what, what I found is really, um, one of the most powerful things to, to define the plan is, is the risk levels for your organization, the vulnerability risk levels for the organization. Because, and this one's interesting because most, I think, and you guys correct me if I'm wrong, but I think most small businesses will prioritize vulnerabilities mainly from the severity of the vulnerability that the, the scanning tool returns, right?

So if, if Nessus or if cyber CNS says a vulnerability is critical severity, then that's gonna be at the top of your list, right? Well, That's, that's what compliance trains us to do, right? PCI, you have to mitigate everything above a certain level. So it's Yeah, your, your prioritization becomes your CVSS severity. Exactly. Right?

And so, and the idea in, in, in my mind, that's, uh, when I see organizations doing this well and having a really solid vulnerability management plan and policy, they've, they've basically said, look, the, the, the severity of the v that the vendor gave us isn't enough to determine the risk to our organization.

What we need is really an understanding of both the threat intelligence that's relevant to the specific vulnerabilities, and then the context around the, the assets that are impacted by that vulnerability, and then even the data that the, that those assets are hosting, right? So then you can say, you know, in our organization, we consider vulnerabilities that meet this specific criteria to be an urgent or a critical risk level, right?

And, and it might be that the, the, the scanner said it's a, a critical severity, but also, you know, it's impacting publicly exposed assets, right? Like a WatchGuard firewall, uh, or, you know, web servers in the DMZ. Um, but it's also vulnerabilities that, um, let's say have known exploits available that are being remotely, uh, exploited, actively exploited in the wild, um, perhaps even in an automated way, right? Exploited at scale, mass, mass exploitation.

And, and if all these criteria are met, then you know, we're gonna call that a critical risk. And then, you know, you go down the chain, you can define as many levels as you want, and that's really, you know, where I see organizations doing it, right?

Because then you can tie things like SLAs into those specific risk levels, uh, and really prioritize things correctly and ensure that this, the time you spend patching and reconfiguring and remediating stuff is spent on the, the most critical stuff. Perfect. Um, we're a little concerned about the chat going on right now, and it was very technology and tool heavy. And, um, so I'm a little sidetracked by that.

I think, you know, first and foremost, we need to reframe this as a process problem, not a technology problem, right? Um, technology exists to support your people and your process, and it's an important part of vulnerability management. But if you think about it as a technology problem, you've already lost. Um, but anyway, so Ryan, just to ask you on that, like, so, uh, from what Steve just said, you can have all the best technology, but, uh, Wes, you always talk about, uh, you know, bis.

So if you haven't done an impact assessment right, on your assets, like the technology really doesn't matter, right? I, in fact, I've never done A BIA where I didn't learn something significant that came out of it because we IT people, uh, we actually don't know the business processes that our own clients are operating with, right?

We just don't, we know to keep things like online and keep the green lights going and the amber lights off, but like, we don't actually understand their processes, and we don't understand the inter the interplay between these things. And even the supply chain, if I can use that word, of how the business operates from inputs outputs, and how to support that, which whi which services and platforms and things like that need to be in place in order to make things happen.

I, it's always a mindblower to me, like, wow, I had no idea you guys did that. So yeah, there, they're a key component there. Gary, you know, offline, this is a few weeks back, Steve and I were in a conversation and, and I thought he said it so well. He, he called it the trifecta, I think you said, Steve, which was, you know, it's really, you know, there, there's, and Ryan, you said this, by the way, in the, in the podcast, you, you're never gonna be able to patch all the vulnerabilities.

It's impossible. But back to you, Steve, you're like, you could have A-A-C-V-S-S nine or even a 10, but if it doesn't impact the mission critical system, is it the most critical, maybe not, maybe a seven on a most critical system that you have that's, that's currently being exploited is far more.

So I love the way you nuanced the importance back to Wes here about what are the most, what's the business, Dr what drives the business, not just, But people are still, I'm, I'm reading what Chris is saying, and Chris, obviously, we're not saying you can do this without tools. I mean, listen, I love software. I investor in several startups, okay, I want you to buy software, but I, but I disagree that you buy that and then build the process around it. I think you, you have to do your assessment.

You have to decide that process by the right tool for that. Then you build the process around the tool. Yeah, I mean, that kind of gets into my next question for Steve. So Steve, what I was hearing you say is kind of what you're, there's starting to be an increased drumbeat in security, which is risk-based vulnerability process and prioritization, right?

And so let's say I have a, I have a policy that says we shall patch vulnerabilities based off of the risk that they pose to our business and to our customers. And that's our policy. How do you go about building an SLA and putting that in place with end customers? You know, you say, okay, I'm gonna build a risk-based vulnerability management process, but, but then what? Then what do I do? Yeah, I, I'm not sure I fully, fully understand the question.

I mean, I think, I think it goes back to, you know, to the first question, having that plan. And when I think of SLAs, right? I mean, I'm, I'm thinking of kind of the, you know, the when the what, the how of, of vulnerability response in particular, right?

And so, um, you know, in the case of MSPs who, who are actually responsible for remediating and patching and reconfiguring and things like that, I mean, the first thing that comes to mind is, is obviously like timelines and, and just, you know, defining, defining. Once, once you have those, like those risk levels we talked about, right? Then it, it comes back to, you know, defining, um, you know, the timelines for responding to things.

And so for that, you know, sky is falling, urgent log for J vulnerability, whatever it is, uh, whatever it happens to be at the time, maybe that's 24 hours. And then, you know, you go down the line and, and, uh, everyone's got, you know, different ideas on what response time should be.

Um, but, but yeah, I mean, I think really the, the, the key is having that, that plan and that policy kind of defined in writing at the, at the right level, and answering all the right questions and just communicating that with, you know, downstream to your customers and having that, that buy-in across the board. Okay. So let's say your customers are running multiple vulnerability scanners. Can you share why that is?

And then our audience, how should they approach remediation of vulnerabilities that are being produced by multiple tools? What's the process that they should put around that in order to effectively manage their vulnerabilities? Yeah, sure. And, um, yeah, I'll say like most of the, most of the companies that we work with, uh, absolutely run multiple different scanning tools. I'll say probably our smaller customers run anywhere from like three to four.

But a lot of our larger customers, especially those that have, uh, custom, they're doing custom software development in-House, sometimes have, you know, upwards of 20 different scanning tools. And to your question, right, I think the, the main reason for that is just all of the different, uh, you know, kind of layers of your technology stack that really need to be assessed. Um, and, and there isn't one scanner that does a great job at, at any particular layer, right?

So you could have a, a tenable or ness or qu and that's gonna be great for, um, you know, computers for servers, maybe for mobile devices.

But then you, you know, when you start talking about, uh, shops that are, that are doing software development that need to have code scanning, that need to have, um, let's say third party library scanners and things like that, uh, maybe container image scanners, each of those is gonna require, well, it doesn't require, but you'll want, you know, kind of the best of breed tool for each of those technologies.

And, and sometimes the bigger scanning vendors will say, Hey, look, we can, uh, we can also scan, uh, third for third party libraries. We can also scan containers. But, but when you really, uh, look across the, the market, uh, generally each vendor has like one thing they're really good at, and then they try to do a bunch of other things that they're not very good at. And so you really want kind of best of breed tools in these different, uh, kind of layers.

So you might want a, a separate scanner for, uh, you know, you know, specialized for databases or specialized for ot. Uh, we see a lot of, you know, new OT scanners coming up, specialized for scanning, you know, APIs and, and web service endpoints. So that's the main reason why I think you could have a lot of different, uh, different scanning tools. And so Where it becomes a challenge, I think, is the more tools you have, right?

Obviously the more, um, you know, different types of reports, different formats of data that you're working with, um, so you know, what one vendor calls a critical severity is different than another vendor. And so you have, you do have these challenges of kind of normalizing that data and then responding to it in a consistent way, doing vulnerability response in a consistent way.

Um, but I'll say, I will say, uh, when I see folks doing, you know, organizations having a lot of different scanners, generally, if they're doing it well, there's not a lot of overlap in the sense that, um, you know, there's not a lot of duplicates, right? So the scanners are for those different layers, and you don't have like, multiple network scanners that are reporting on the same vulnerability. So generally that is less of a problem. Okay?

So obviously I've established, I'm big on people process and technology and thinking about it in that order. Um, when you think about vulnerability management process, there's a, there's a similarity to IR where when you've had an incident, you look back at your, your response and you say, what did I do? Well, what could I do better? How should I fix this process? How do, how do you suggest MSPs think about that continuous improvement life cycle of vulnerability management?

Yeah, no, it's a hundred percent agree, right? Especially when you get these, um, you know, these celebrity vulnerabilities. Log four J is a good example where, uh, the remediation or the response to a log four J is very much like incident response. And, uh, even though a breach hasn't happened necessarily, uh, I, you know, we, a lot of organizations set up war rooms for log four J and vulnerabilities like that.

And, and, and so, um, so yeah, it all, it all really does tie back to having this well thought out, uh, vulnerability management plan, uh, and, and policy. But, but the plan that's there, that, that says, here's what we do when there is a urgent or critical vulnerability like log for J that, um, uh, that is, that is announced, that's here, here are the steps we take.

And then it's the same process, just like with instant response, where you have, uh, kind of a retrospective to figure out, Hey, what did we do? Well, how long did it take us to respond to this? What can we fix for next time? Uh, and, and then incorporate those things right back into your plan, just like an instant response plan. Okay, Wes, over to you. Right on. Um, so this has been good conversation so far, and I like that term you use celebrity vulnerability, right? Does it have a name?

Is it a cool sounding name? Does it have its own website? Like I remember this back in the Harley days, and all that stuff would spin. Yeah. Just So you know, Steve, that means you just lost that and all access to it West Coast still admitted his own. Yeah, I can't wait till, uh, I have my own celebrity vulnerability named after me, or one that I create myself, right? Because that's how, you know, you've made it in the, in the, in the, the big stage of things.

The truth is though, it's, it's one way that the press and media like to pick up, uh, on, you know, news cycles on these things. It's really funny, the correlation that's there. Um, but speaking of that, speaking of Log four J, even though, you know, log four, shell, it had its own name, uh, and, you know, it was a pretty significant deal.

I remember talking to some of my enterprise CISOs when all of that went down, and man, they really struggled because a lot of them have, um, more mature security process because they only have their own, um, territory to defend, unlike MSPs that have 20 to 80 or more. Uh, and one thing that they realized they had these huge gaps on is not just the whole SBO m you know, the software bill of materials that we've talked about ad nauseum, but I think even more than that.

Like, they struggled with, even if we had an sbo MI don't think it's mature enough to actually understand where in the supply chain Log four J exists, whether inside our own network with our own vendors or third party where our data is stored and processed. And man, we're years away from solving this problem.

Like, I, I think we're years and years from solving this, Steve, so like across the board, when these kinds of things happen, like the next log four J thing that's super significant and every running everywhere, because it, how it works is a library. What, what should we do in hindsight? Like, what should we do now to prepare for those things? And what do you think it's gonna look like the next time something like this hits? Yeah, and that's, that's a great question.

Um, so when I, I mean, when, as you, as you talk about it, what, what comes to my mind really, uh, are those organizations that are building software in-House themselves that, um, that have embedded Log four J libraries in their applications, right? Because that's the one thing that they can, uh, you know, if you are one of those organizations or you're supporting one, uh, that's, that's one thing that, uh, that's one problem that you can solve, uh, if you haven't solved already, right?

And that's, that goes back to, you know, the list of different scanning tools and why you need different scanning tools. But the truth is, if you have a development team, uh, that's, that's building code for your organization, um, they've got some kind of CICD pipeline where they check code into a repository, and it's really easy to instrument that process with, uh, third party library scanning tools that check for vulnerabilities.

You know, they will detect every library, every dependency you have in your custom software and report on vulnerabilities associated with those libraries. And you could put gates in so that you don't actually deploy, uh, into production applications that have vulnerable libraries. So, um, I, I mean, I think that's the one thing that you can absolutely do and you should be doing if you're not already, um, for vulnerabilities like Log four J that are, that, that are libraries.

Um, beyond that, I forget the, I forget the second part of your question, but I don't know that just What the, what the future might look like. Have we actually had lessons learned that have resulted in changes in this area of understanding like library existence and where they are, and whether it's SBO M or not? Like, is the next time a Log four J style kind of thing hits, is it gonna be different, do you think? Or is it gonna be oops, same old, same old?

Yeah, I mean, honestly, I don't think we've learned, and I, I, I think it would be the same exact thing. I, I don't see, you know, much changing at all. I mean, I know that, that on in the federal space, right, there's a lot of legislation coming out that's going to require vendors to publish SBOs, you know, vendors that are selling software to the government to publish SBOs. And so there might be things that, uh, you know, things like that may help at least in the federal space.

Um, but, but honestly, I think we're, you know, we're probably years away from, from seeing like significant, you know, substantial, uh, improvements. I, yeah, I mean, I think if another log for J hits, uh, you know, later this year, it's the same, it's the same fire drill. Yeah. I, I tend to agree. I'm gonna share a link in chat. Um, this is more of just an awareness thing.

I don't think it's anything outside of the big four, like, you know, the DA data Kaseya, um, uh, ConnectWise, et cetera can actually do at this point. Like, MSPs can't do this, but I'd love to see, you know, something like this started, for example, let me just throw something out there and Ryan maybe get your thoughts on it since you represent probably the, the, um, most capable here.

Um, would it be possible in the next, let's say two years from now, the next big log four J style thing hits, would it be possible for Datto to have something in place? Like what, I just shared this article, and I recognize you haven't read it yet, but like, to where you could very quickly and in very timely share, almost in real, not quite real time, but just a day afterwards, this is exactly where it exists inside of Datto, this is what we're doing about it.

We can show you specifically and then, you know, lead for countermeasures down the line. Could this happen soon? Could the big vendors lead in this? I'm, I'm laughing because, um, I was literally having a conversation with a peer this morning about SBO M and how there's government legislation coming down the pipe, again, specifically for defense industrial base, you know, um, federal government, et cetera.

But the conversation I was having was, why do we need to wait for it to be legislated to do this when we know it's the right thing? Um, and I already have my team looking at it like we have, we have a four phase project plan for SBO M and no one's telling us to do it. We're just looked at it and we're like, that's the right thing to do.

The thing is like, you know, SBO m is not SBOs gonna make it easier for people to understand their third party risk for a vulnerability, but it's not really gonna help until we're systemically pulling all those SBOs and assessing them on a continuous basis from a process perspective. So SBO m is actually just the first in what I think is many steps in terms of measuring vulnerability in your supply chain. Yep.

Um, but yeah, no, I do think, I do think MSPs should be demanding of their vendors, uh, that they start to provide bounds. Um, It's, it's, you know, in the years to come, I, I think 2021 being the year of the supply chain attack, that's, you know, that's almost a misnomer because I think that's just the beginning of what is to be multiple supply chain attacks. It's such an effective TTP, we're just gonna continue to see that happen.

And so either vendors need to get really good at being ready to respond to those requests, or they need to start being more transparent and putting that information out in real time before these actual, uh, events occur. And I think that's ultimately where we need to get to. And I think this is a great question for the CSO panel next week. Yeah. Uh, indeed it is.

And I think I'd love to hear from all four exactly what that looks like, because I think you've outlined it well, Ryan, I don't wanna stay on this topic too long. I wanna get back to another question for Steve, but I think the big four have to lead in this first.

Uh, and, and, and, and certainly surrounding like, you know, Cisco, Microsoft, others that we heavily use, but they've gotta lead in this first and, and at least provide us, um, that raw data and the interpretation of it before we can see MSPs go down any amount of this, this journey. Um, so that, that's good. And, and I'm really glad to see that happen. Um, Steve, I wanna come back to something. Um, you mentioned this a little bit earlier and I wanted to zoom in on it a little bit more.

You mentioned, um, there's definitely a difference between configuration compliance and like software vulnerability management, right? Like the two do go hand in hand and Aaron churn in it, write ABO who I think, you know, Aaron did such a good job. It's one of my favorite talks at Write a Boom around configuration compliance.

And he talked about, especially in the channel, there's a heavy focus on software and vulnerability management, but not nearly the nev the level of a focus on configuration compliance. Can you kind of give us some thoughts on why that is and how that could be addressed? Because I'll just throw one thing in it before you answer, is, I think, and we're seeing this from the chat, a lot of clients of MSPs are like, well, I don't care about configuration compliance. That's your job. So just do it.

Like, I don't want to touch it. I don't wanna see it. Andrew, you want to add something real quick? Did You, if you don't mind, Wes, I'm really, really glad you brought this up, Steve, over to you. But earlier on, Tim Fornet in chat brought up how VM vulnerability management moved down in CIS controls. Well, Wes, what moved up secure configuration. Why? Because it's the number one thing you can do to prevent an attack. So Well go back to the Verizon data breach report, right?

What did they say this past year? The majority of their sample set this year, they classified a small to medium sized business. There's more representation of small to medium sized business in the Verizon data breach report this year than in any previous year. And the number one thing they said was misconfiguration. Yep. So with that, Steve, have we given you enough to kind of, you know, chew on here? Yeah, I think there was, I guess there was a question there. I mean, you want me To recycle?

Let me recycle the question just so you'll be sorry. We, we all went crazy on that. I know's our fault, the cyber call. Here's my question. I, I would love some feedback on, there's a heavy focus in the channel around vulnerability management patch, the scary vulnerabilities, zero's not near enough of a focus on configuration compliance. That is a problem. How do we fix that problem? How do we get our clients to care about it? It's a, it's a, it's a systemic issue. Yeah.

Well, no, I think, I think part of it goes back to the, you know, what's, um, it's the celebrity vulnerabilities and what gets the most press and what's the scariest thing. And, and it's always, you know, I mean, you guys mentioned the, the WatchGuard one. Um, you know, it's always something related, it seems to, uh, to, to a patch, right? It's, it's generally not, Hey, you have to go out and reconfigure something.

Although in this case, there was some configuration aspect to it in that I think, um, you had to have mis intentionally misconfigured your WatchGuard to expose your management interface. That's a, that's a different conversation, I guess.

But, um, but yeah, I mean, I think that, I, I think when I think about, um, you know, when I think about configuration and, and security hardening is, you know, generally the, the term I'll use, I mean, it's, you know, it's, it's compensating controls, um, it's defense and depth. It's, it's kind of that hygiene that you like to, you know, build into your processes for deploying new software, new applications, new systems, uh, things like that.

And so, um, you know, I think of like in the, in the Linux world, which is, that's, that's where my background was primarily. Um, there's something called SE Linux, which is, uh, an an awesome, uh, thing you can configure. It comes pretty much default on every Linux system now. And you can configure it, uh, really, really simply in a mode where, um, you know, if, if your system is exploited, it really limits the damage, uh, that that can be done.

'cause it kind of isolates these processes and services, um, you know, host base, host base firewalls, things like that. Um, I, you know, there, there isn't enough emphasis put on it for sure. Um, but I think that it just doesn't get enough. You know, it doesn't get enough press. People aren't talking about it enough. 'cause there's always, it seems another sky is falling vulnerability to talk about, and everyone's hair is always on fire to go out and patch a thing.

Whereas the configuration management thing is kind of a, you know, it's a, um, you know, a harder kind of longer term thing that you have to do relating to change management and everything else. Um, so yeah, that's, that's kind of my stream of consciousness for that. I, I like it. And maybe food for thought for MSPs today. Um, if you're not doing really good confi, let me, are you doing good configuration compliance? Let me just ask you something.

If you had a, a configuration that was changed, would you even know about it? If you wouldn't know about it? How would you even know the purpose of it? Did a user change it in the course of business? Did an admin change it, did a threat actor change it? You look at like the kill chain and how things happen.

Maybe they got in through some scary vulnerability you're not aware of, but usually before the ransomware happens, there's gonna be some kind of configuration set of configuration changes you had no visibility into, and you could have seen that and taken action on it right away. So it's just food for thought of like, how do I build visibility and configuration management changes? Um, yeah. All right. So let's, let's change gears a little bit more. Yeah.

Everything's configured right the first day. Yeah. It's just, you push the button and off it goes, right? It's like, yeah, it Calls default, it's secure, right? Yeah. Yeah. Uh, hey, let's talk about threat intel for a little bit. I think Stevie, you guys are doing some work with Mandiant, who's freaking awesome. Uh, talk to us about how threat intel and maybe what you guys are doing, plus, you know, vulnerability management all goes hand in hand. Yeah, yeah, absolutely.

So that's, that's one, uh, one thing I'm super passionate about is, is threat intel in the context of, of vulner management. And so, so at Nucleus, we partnered with, with Mandiant last year, um, to basically take their data and kind of overlay it on top of all of our customer's vulnerability data and, and their data.

Uh, the, the data we've incorporated is essentially, um, it's information about vulnerability exploits that are in development, um, active exploitation of vulnerabilities occurring in the wild things. You know, this, this is information that goes far beyond, uh, what a, what a scanning tool's gonna give you, right? Um, it's really useful. I mean, primarily for, for vulnerability prioritization.

And going back to, you know, being able to assess a vulnerability and assign a risk level to it for your organization, however your organization defines, you know, risk. And so, um, you know, and, and I think until recently in what I'll call vulnerability intelligence, uh, which is like a slice of threat intelligence, it was, it was really only available, I think to, to mid and, and large size enterprises because of the, the, the cost, right?

I mean, there's like a six figure entry point just to get access to a lot of these vendors. Um, threat and vulnerability intelligence. Um, recently there's also a, a, a couple of sources of vulnerability intelligence that have, uh, that are, that are really good that any organization can use that are free. Um, one is, and and I think you guys might have mentioned this, I was listening to, um, a vulnerability management.

Uh, I don't know if it was the cyber call, it was another webinar you guys did, but, um, the, the, let's see, what's the, the first one was the cisa or CISA known Exploited Vulnerabilities list, right? That's one that they published about, I guess, four months ago or started publishing.

And they, they updated about once a week, but it's basically like, Hey, here's a list of vulnerabilities that are actively being exploited in the wild that they're observing, being exploited in the wild and, and recommended, you know, due dates for exploit or for, for remediation. Um, they don't give you a lot more context, but you can be pretty sure that they, uh, you know, they've got really strong reasons to put those vulnerabilities in that list.

I think there's 300 and something vulnerabilities in that list. And so that's one excellent source of, of vulnerability intelligence that you can then correlate to your, your environment and your scan results and the vulnerabilities that are impacting your organization. Um, the other good one that, that, uh, and it's actually been around for a while now, is, uh, it's a project called the Exploit Prediction Scoring System or EPSS.

And that's, um, that's something sponsored by First, and it basically just gives you a, a percentage for, for every CVE for every vulnerability. And there's, you know, 160 something thousand, I think now, um, this is the percentage of it being exploited, uh, exploited or probability, I should say, of it being exploited in the next 30 days.

Um, so they use some really fancy machine learning to come to that conclusion, and they look at all kinds of attributes, everything from like the vendor and the product to, you know, a ton of other attributes. Um, and so you can use, you know, you can use intelligence like this, um, really for the first time recently without having, you know, a, a, a giant budget and being, and being a large enterprise.

Um, so the, the challenge, I think, uh, especially, you know, shifting back to kind of MSP world is like, okay, it's great that these sources of data are out there, but now I've got to find a way to, to take that data and kind of correlate it again to, to the environments that I manage. Um, and there's not an easy way to do that, um, right now.

I mean, that's part of what we do at Nucleus, but, uh, you know, if you're an MSP, uh, trying to do that today, you know, it, it could be custom scripts, um, it could be Excel spreadsheets, you know, it's not gonna be fun, but it's possible. Awesome.

And, you know, I th there's, this is a topic for a longer conversation, but you know, this is also the goal of what ISACs and ISOs are supposed to be doing in, in other like peer groups where we're understanding what's happening in the world around us and compiling that. And I come from banking and I came from a small bank and, and my small bank certainly didn't have a full threat intel team.

And so we had to rely on what's happening in the world around us so that we could ingest intelligence and then apply that in the right things, whether it's new controls, uh, whether it's new defenses that we're going to put in place, whether it's discussion and risk items for the board, whether it's, um, even re-looking at certain compliance things that we may not have looked at before or reassess.

And those are the things that become a lifeblood of, of knowing what's going on in the world outside of you and a threat intel perspective, but having a lot of it custom tailored and delivered to you in an actionable ways. Because I think the big banks didn't understand. They're like, what are you talking about? Like, I have a whole team of threat intel analysts, and it's all they do. And I even have like, business driven threat intel analysts, and I have an army of people that do this.

It's like the rest of us don't have that capability. It's a luxury we don't have. So I need it to become much more actionable for me, uh, before I consume it. And that's a problem. That's a really good point, Wes. And yeah, until we have that functioning where there's a place where it really gets distilled down in a way. 'cause just almost every MSP is is not gonna build, you know, threat intelligence to where it needs to be. Yeah. Yeah. Exactly.

By the way, those are your listening and not watching Jack Andrew did post the link to the BIA that many of you asked for Andrew. I don't know, I searched forever and I couldn't find it. Uh, but, uh, I'm glad you found it. You'll have to teach me your skills there. Business impact. It was under business impact Analysis, not, I searched both. I don't know why I couldn't find it. I searched both. Um, but I'm glad you found it for me. Uh, okay, last question before I flip over to my friend, Gary.

So let's talk, and I'm gonna actually paste a link into this, but let's talk about external scans for just a minute, right? Like, um, those are important because it gives us visibility into how, uh, threat actors sees our landscape, right? But we also know that clean external vulnerability scans don't necessarily mean a whole lot because there's ways that you can bypass external vulnerability by just a phishing attack. Getting past all defenses is a simple example.

So what level of use are they? How should we best use them? And then for those that are not aware, I'm gonna post a link from cisa. CISA actually does free external vulnerability scanning as part of their hygiene services. And I wanted to share this. It's available for a number of your clients, and so might be something you guys wanna take a look at as a free resource. But, um, Steve, what are your thoughts on that? Like from a external scan perspective?

Yeah, I mean, you know, that's gonna be, um, your most obviously, uh, exposed. That's, that's your attack surface. That's what's gonna be hammered on the hardest. I I always recommend, uh, that people scan, uh, their, their assets that are externally exposed, uh, daily if possible.

Um, you know, it's, and going, so going to your point on, on Cysa cyber hygiene, I think that, um, that that's a phenomenal program, by the way, we're, we actually at Nucleus, we're, um, we're signed up for that, and I believe that's a weekly assessment. Um, you know, the, the thing about that is you have to, uh, as just something to be aware of, right?

Is with the cyber hygiene program and, and a lot of third party, um, vulnerability assessment services that will just kinda look at your attack surface like that, you know, you, it's a, it's a static scope list that you give them list of IP addresses, uh, or ranges of ips, uh, list of domain names or websites that, um, that your organization owns. And, and there's not, there's not, um, at least with cyber hygiene and a lot of these services, there's not a lot of discovery taking place.

And so that's one thing to really, um, to, to be mindful of, is you want to, you want a, some kind of service or, or offering, basically that is able to discover a tax service on a continuous basis. Uh, and there's a lot of tools out there that can, uh, that can do that, can do that.

Um, and I think, and I'm not sure if, if there are any that have kind of made their way down to kind of MSP world or, or not, but, um, you know, things like the discovery and, um, I think Rumble and some other ones like that come to mind. But the idea is that, you know, these, these tools will discover what your external attack surface is, um, and they can't find everything. I mean, this is also kind of a, an asset inventory challenge and asset management challenge.

Um, but yeah, so the first step is just understanding what, what is that list of things that are exposed. But, but yeah, I mean, I would say this is something, uh, if, if I'm writing a vulnerability management plan, uh, I'm, I'm assessing, I'm scanning, uh, external facing assets every day.

Uh, 'cause those are the ones where, you know, if we, if there is a new vulnerability announced, a log for j something like that, instantly I wanna, I wanna read on, okay, is this something that we need to patch? Uh, you know, in the case of this WatchGuard one, right? You don't wanna wait until just routine patches, uh, come into play, right? You wanna detect that within 24 hours maybe, or a week or something like that.

So, so yeah, I would scan like, you know, I would recommend like a, like an assessment every day, uh, for things like that. Yeah. Fantastic. And, and I do think that's wise invaluable for sure, given that it's your externally facing footprint, right? Uh, Gary, I'm gonna flip it over to you. Awesome. Uh, first question I had as listening, I, I hear so much, we talk about vulnerability scanning, it's network scanning. What about application scanning?

Like, is there, is that much more difficult to do? And, and, you know, 'cause the feedback I've gotten from some people is that that still is as much a manual process as automated. Um, I think the short answer is, is yes in general, right? I mean, when you look at, um, traditional network-based scanning of computers and infrastructure, um, that's, that's pretty straightforward to do with, you know, with, with tools that have been around for 15 years and 20 years.

Uh, but in, in the world of, uh, of application security, uh, the landscape looks totally different and it's pretty complex, right? And it goes back to kind of what we were talking about a little bit earlier with all these different layers of the technology stack. When you, when you think in terms of, um, application security, you, you wanna scan your code, you want to scan the running web app that's in production, and then you wanna scan a bunch of things in between.

You wanna scan for those third party libraries based on your SOM, you want to scan the container images that your developers are building and then deploying in into production, uh, before they get there, ideally. And so, so yeah, application security becomes a lot, a lot more complex and challenging really quickly, and you need a lot more tools for it as well. Um, so, uh, yeah, I guess that's kind of a long, long-winded answer.

But, but it absolutely is something that, um, you know, we're seeing more and more of in smaller organizations. Uh, right, so we, so we work with a, with a lot of companies that are, you know, a hundred, 200 people and have, uh, pretty significant dev teams, pretty large dev teams that are turning out a lot of custom software and custom code and, and those in, in those organizations, how they do vulnerability management in the context of their development processes.

I mean, that's, that's really the most, uh, that's the most difficult part of vulnerability management organizations, right? They've got the network stuff mostly figured out and kind of automated and things like that. Um, but getting the vulnerability assessment and management right in the context of software development processes is, um, you know, it's still, it's still a big challenge for a lot of organizations because it's, it's still just the technology's evolving so much. Yeah.

Um, so Matt Lee and I hold beard banter on, uh, vulnerability management and software and the complexities of it. If you wanna go back and reference that, Matt, I don't know if you want to drop a link to that in the chat. So Steve, um, we talked about, uh, you talked about people process technology, as I always say, on at least once on every cyber call. Boy, that sounds expensive.

So how, like, you know, knowing and how an MSP is, are there some, any kinda a guidelines of estimating cost of like what it takes to do this? Ooh, yeah. Well, I, I hate to say it depends. Um, I always hate to say it depends, but it really does. You know, if I'm an MSP, I have to be thinking about first, what kind of service do I wanna offer, right?

I'm looking at the customers that I currently serve, maybe the types of customers that I'm, uh, I'm leaning into or targeting and trying to figure out, you know, what is it, what service is, do those customers need? Because I think the service offering is going to be different, you know, with smaller organizations it's gonna, there's a spectrum, right?

And, and smaller organizations are gonna require one thing and it's gonna change and become more expensive and complex the larger the organization is. And so there, I don't, I don't know of any good like, um, kind of metrics or, you know, rules of thumb for, for like costing that out or the economics of that.

Um, you know, I just think it's, it's really gonna be a matter of putting together, you know, a service offering and, and the process and that vulnerability management plan that outlines all of this stuff and then, and then, you know, figuring it out, right? It's, it's, uh, it's not gonna be a standard thing, I don't believe. Yeah. Hey, Andrew, while we're, while we're talking, is it possible to throw up a quick poll and forget about what you're offering to customers?

How many people on the call feel like they have a good vulnerability management plan and execution for themselves? Just for themselves, for their MSP? Good question. And then what were you gonna add, Andrew?

Yeah, Gary, just 'cause you know, in one of the prior cyber calls, you, you said, Hey, I'm kind of changing my mind a little bit about onboarding and, and the only reason I'm saying this is I, the question you just asked Steve, if, if you haven't defined the policy of what and, and business impact, in other words, what are the critical systems, it's, it's gonna be pretty tough to figure out, hey, we've agreed on this, these are the four systems that if these things align, exploited this, that I'm doing work.

So, you know, it it, I I could, I don't think we can hammer enough the process side of this conversation. Yeah.

You know, and, and then one thing, Steve, is, uh, 'cause I'm watching, you know, my customers go through this now, is as they're putting this together, you know, we like to think in terms of monthly recurring revenue, but it's pretty hard to put this into a seat costs, you know, a lot of, a lot of what you have to do, it's process and tools, it's almost the same cost for your 50 user client as your a hundred user, you know, client.

So, I don't know, do you see people starting in the beginning doing this more as like project type stuff until they start to get command over the costs? You see the problem I'm trying to lay out, Are you, are you talking specifically kind of in the context of like more of the application? No, I'm saying we wanna start to have, be able to do some level of vulnerability management for our, you know, scanning process for our customers. But how do we go to market with it?

Like, you know, uh, because it's done differently than some of the other services that we roll into our monthly fee. Right? Right. So, so, so if you're an MSP that, um, let's say isn't, isn't, isn't offering a service like this today. I mean, I'm a big fan of occurring revenue myself, right? But, but you not, it's not offering this today. I don't think it's a bad idea to kind of start with, um, you know, the project based work like this to kind of figure it out, right?

Because there is some level of this that is figuring out what works and what doesn't work from a service offering perspective and what your customers want and don't want. And so, yeah, I mean, I would say getting started, you know, saying, okay, we can, we can offer, um, you know, this service kind of on an ad hoc basis or twice a year, something like that, where we perform this type of assessment.

Uh, and then kind of over time turning that into more of a, um, you know, a recurring, you know, a, a monthly cadence, a weekly cadence, whatever it might be, and, and figuring out the economics there. I mean, that, that sounds like a, and then Maybe put some of the scan like, and some of the scanning stuff, like you said, that's maybe a little more technology based that's easier. Like that is stuff we know how to bundle in, Right? Right. Exactly.

But, but so much of this is, is kind of process and, and, and figuring these things out that it yeah, it is hard to imagine just like, uh, okay, just instantly kind of going to market with a service like this. It does seem like it's a, it would be a process. Um, so, so yeah, that makes a lot of sense. Yeah. So I, I'm suggesting people first make sure you answered that question. Uh, start on yourself like we always tell you.

And then what I would do was pick a couple customers where you feel they have the highest risk and put a project plan together for 'em. Like work it out. This is not something I think you want to come up with some offering and then tell all your customers and start rolling it out. That 30 customers, I think you gotta, the people I've known who've gotten furthest down the line, the, you know, the most security first MSPs, they've done it in that process.

They start with them, one or two customers, then they expand it, and by the time they get to the rest of their customers, they feel like they have command over the cost drivers. Gary, I think, you know, we're, maybe we'll go a little over here if we can, but we do, I I'm thinking we do a cyber call.

Gary, if you were open to it on how you talk through, uh, how you bring a new product, pro product or service, she probably Won't be open to it To, to market because what you just kind of articulated, like Sonny Lowe talks, if Sonny's out there talks about it really well, like Sonny was talking about how he's bringing on access control right now, you know, and the first five customers, you lose money the next five, you start to get your legs under you.

But it would be really cool, Gary, how, if you could walk us through that on the side. Yeah. The logic have to, how you have to see your business and costing so that you can make those decisions and you gotta have a framework by which you look at it. 'cause not all this fits in neatly. It's not just like buying another toll and turning it on in your stack. Yeah. There's a, there's a lot more to it. And so, yeah. Yeah.

I, I also wanna mention that, um, something that, that we've been working on that's, that's just about ready to share. Uh, you guys might be, might be interested in some of the, some of the listeners is just a, it, it, it's more of a, um, you know, how we view vulnerability management in the form of a vulnerability management plan and policy.

It's like a template that you could use, uh, you could use as A MSP, you could use just as a, as an organization, uh, to define your internal policies for vulnerability management. Again, all the, all the tools in use, uh, all of the SLAs that you've, um, you know, agreed upon internally and things like that. And that might help some of these MSPs to uh, kind of kind of frame this and, and start thinking about it. Um, just throw it out there. Yeah. Really, really valuable today.

Steve, Andrew, I was saying, you know, I think we probably should circle back to BS again Yeah. In the future call. Yeah. So I just, Gary, I love what you said, Steve, maybe, you know, I just pulled, pushed the question in there. Hey guys, would you like to have Steve back walk through that template? And Gary, we do a combination of with, you know, your process of bringing something to market. Um, I think that would be really Yeah. Impactful.

But while we're waiting to do that, can the 68% of you that don't have a good VM payment process internally work on that in the meantime? Please. Yeah. I mean, make that, let's make that like in the past we've done this, let's make that call to action even more specific. Yeah. Well, we know everybody. Look at your internet facing assets and look at your vulnerability management processes that exist today and identify two improvements that you want to make in the next 30 days to that process.

Ryan, because I cut you off. Awesome, Ryan, Because I cut you off early. Could you repeat that? 'cause I want to take that snippet and get it out there for all MSPs. Yeah, I was gonna say like, do doubling down on what Gary just said. Let's, let's make this more specific.

Look at your internet facing assets and your existing vulnerability management process and understand what your current capabilities are and identify two improvements you wanna make in the next 30 days to the management of vulnerabilities in that sphere of vulnerabilities. That's where you start. Yeah, man. Awesome, Ryan. That's how, by the way, that's how you get anything done. You break it down into something that you can actually do and get started and it leads you the rest of the way. Yes.

Small, small, small chunks, right? Yeah, I, I mean it, Ross asked a great question. He said, how much human resources do I need to do this? And what I've been trying to say every time we have one of these conversations is dedicate one hour on a Friday with a couple of your texts and just examine this and, and figure out one thing you wanna do to make that thing better. And that's how you start the snowball role. Yeah.

It's almost like Gary, you used to talk, you probably still do within true methods, like when your service board just gets inundated with tickets, you have a pizza party, you know, on a Friday and it's a ticket closing party, you know, and, and you know, I think we have to start incorporating similar type, you know, and by the way, Your team loves that. They wanna learn new new stuff. They want to, and that's how you change your culture.

So again, Ryan's given a bunch of good nuggets, uh, here in the four minutes after our time. You're getting, this is for free bonus. Okay. Tell your friends about the cyber call. We'll just keep getting, All right. Wes, you still there? I don't know, I can only see your icon, but I hope you're still with us. Um, yeah. Alright, cool. Um, I know we went a little over. I appreciate we had a big turnout today. I appreciate everybody staying on late. That did stay on Steve.

Really, really thank you so much for coming on. And would you come back and do that with us on the, you know, the template ly, you know, Absolutely. It, it, it's an honor to be here guys. Thanks for having me on. Happy to come back anytime. Yeah, it was great to have you. And, and, and maybe we can talk a little bit more about specifically why MSPs might look to work with you on larger customers and larger opportunities.

So I knew some of the bigger MSPs are using you and working with you, so I appreciate your selflessness and, and being here to help everybody. Um, on behalf of the cyber call and week 88, uh, under wraps, um, wishing everybody a fantastic day and fantastic week. Take care. See you guys. Thanks. Thanks everybody.