Episode 16: Cybersecurity Areas to Avoid w/ Reg Harnish

Catch you guys off guard just a bit. That's why every time—

always be prepared.

Great.

All right guys, welcome to the, uh, officially first, maybe 16th, we can't really figure it out, episode of, uh, Elephant in the Room. What's up, Alex?

Not much, man, not much. Enjoying the upgrades.

Enjoying the upgrades. And hopefully you guys are enjoying too. Uh, the move to Crowdcast was really strategic, um, mainly in that we have a lot of conversation. We've really started to create this environment where we wanted to always continue the conversation Even when it wasn't live, right? We have these crazy days and sometimes we want to ask a question about what we're talking about and you're like, damn, I had shit to do. I couldn't hop on at 1 o'clock with these guys or 4 o'clock with these guys. So Crowdcast is the new platform. If you don't like it, also give us feedback because it's real pivotal for us to understand what's going on. With that being said, Alex, we got a couple new guests here. Yeah, yeah, I mean, one's a recurring guest, but, uh, so, uh, without further ado, uh, Wes, what's up?

Yo, yo, what's going on, my friends? I've had a great day. Uh, I've had 4 demos for Empath today, so I'm running out of words. We're gonna see how it makes it. Fortunately, we have someone that's smarter than some of all of us together with Reg Harnish on, so, uh, Maybe I won't have to talk too much.

You know, I think with that being said, Reg, kind of to us you're a legend, uh, but I think to everyone else maybe, uh, they may not know who you are. Want to give us a quick little, uh, download?

Uh, sure. First, I feel like I'm Winger opening for Metallica here with you guys, but, um, I, I spent, uh, well, I love Winger. I would prefer winger, actually. I spent about a decade in MSPs back when like managed services was being invented back like 1999, 2000, 2001. Was a co-founder at Autotask and the CTO there for the better part of a decade. And, you know, we got to see some pretty amazing things, learned a lot there, obviously with Bob and Dick Frederick and stuff. It was pretty awesome. Left there, but got the idea for Grey Castle Security while I was at Autotask. And around 2002, we were selling or attempting to sell custom software to, to big, huge IT distributor. Anyway, it doesn't matter. And so we ended up having to go through an ISO 27001 audit. I had no idea what that was, got my butt kicked, but just fell in love with cybersecurity around 2002, 2003. Got the idea for Greycastle Security, launched that company around 2010. We were very lucky. There was really not a lot of people doing enterprise professional services in cybersecurity. So we became one of the fastest growing, Inc. 5000, 3 or 4 years. One of the largest providers in that space. We were pretty much an all-in-one provider for enterprise cybersecurity. And then I stepped down from there, end of 2018, started Orbital Fire mid-2020, beginning of the pandemic, because why not? And we've been focusing on cybersecurity for small businesses, partnering with MSPs. So solving problems for SMBs and MSPs at the same time. So it's been an interesting ride for sure.

Right on. Well, thank you for that. And Alex, what are we trying to cover today?

Before you go there, I just have to say, you know, you have an absolute baller day ahead of you when somebody just kind of lobs in, oh, you know, I was the co-founder of Autotask and then moves right along. Right along. Just moving on.

Yeah. Little thing.

Little thing. Is that still around?

Yeah.

So welcome, Reg. Welcome. Welcome, Wes Spencer. Great to have— grateful to have you both.

And I think that leads to Kyle's next question, which is what we cover today.

Yeah.

So, you know, we're going to spend a good chunk of time today talking about some things that— and this is uncomfortable for MSPs, but maybe some things you shouldn't touch as we're going through cybersecurity, as we're working our way up the growth ladder in our small businesses. And I think it's a conversation we've had on here a few other times, right? As you grow, there will be different things that fit into your wheelhouse and different things that you can work well with. And if you're too early in your journey, there are probably some things you should stay away from. Things that, like, you know, building a SOC that you probably shouldn't be doing if you're a half-million-dollar company.

So you're saying that million dollars I invested into my MSSP when we were only $4 million was a bad idea?

You know, I'm not here to judge.

Well, I thought you had $3 more million to work with, right?

And you know, I think this will be a fun episode. And Wes, you and I talked quite a bit about this, where it goes a little bit against the zeitgeist. And I'm sure you experienced this back in your Perch days, where MSPs just felt like they needed to have a SIEM, but really didn't know why they didn't know what they didn't know.

Yeah, you know, I would actually run into that not just among MSPs, but we had some direct customers as well. And, you know, you start talking to them and they're like, well, I don't, you know, I don't think I need this whole— like, I don't understand why you're mandating that your people come with it. We're trying to, you know, have— look for something we can manage ourselves and we can do this ourselves. And some of it comes from this arrogance state of, you know, we don't trust other people to be as good as we are at something. Some of it comes from ignorance that they don't understand why they need somebody to be managing something on top of them. Some of them, it comes down to micromanagement and the inability to trust others and sort of say, I have to do this by myself because I can't give up control. But you see this across the board and that, that immaturity never leads to good outcomes. It just doesn't. It either leads to negligence or it leads to potentially something really going south and then you eating the cost and the problems from it, or it just goes to poorly controlled, poor, poor outcomes for the client. But I do see this happen a lot in the industry, and it's not just among MSPs. And we have to understand things that we can and can't do on our own.

Kyle.

No, completely. And there's a dark side of cybersecurity as a service, right? And I think we need to frame what we're really talking about today, which is us delivering service, not being cybersecurity practitioners, because when we're delivering a service, we've got to have an economic engine in order to provide it, or our employees are at risk, our business is at risk., and we may not even know that that's happening because of what a lot of the messaging from big vendor or acme MSP vendor, whatever we want to call them, is trying to push on us. And Alex, what's your whole take on this?

Well, I think it goes back to some of the other things we've been talking about. Like every vendor is in business to sell you something. Um, and that's just something that we have to— it's a lens we have to look at every problem through. And when you're saying, you know, hey, we might get some misleading messaging from Acme MSP vendor or whatever, at the end of the day, their job is to sell more of the license that they have in front of them, right? The product that they have in front of them. And as an MSP, it's too easy for us to go, if I can buy this and add a few dollars in margin to it and pass it along to all my existing client base, I can start to rack up numbers in my head. And all of a sudden, before I know it, I've convinced myself I can make $500,000 on this license over here. And in reality, I forget to think about the people cost that goes into it. The fact that only 3 of my 45 customers are going to buy it right away and I'm going to be stuck paying for all the licenses for it. And oh crap, it's going to require 24/7 monitoring and my people like to sleep at night. You know, there are all these things that play into it that we just haven't thought about because we've been programmed to almost be the VAR, right? Go buy a license, resell a license, moving on. I can make money at it and I just pile some labor on top of it.

No, completely.

And I don't know, Reg, if this is one of those cruxes that started to build out the vision for your new venture, but I know what I'm at at IT Nation. We even made a couple of jokes of, oh great, you get 20% margin, 30% margin on that EDR, hell, even 100% margin. But at the end of the day, that's a dollar, it's $3, right? The endpoint, you're not making giant profitability per se. And there's an unforeseen cost to the other side, right? The right of boom of any type of incident your MSP has to respond to.

Yeah, I mean, well, certainly we started thinking about this 4 years ago, going through market analysis and the financial model, et cetera. And how could we check a bunch of these boxes in a way that added value, not just to SMBs, but to MSPs and solved a lot of those those problems. And then when I saw your, what was it, the, the minor leagues of cybersecurity, and you guys had put together sort of a framework for when it makes sense. I think, first of all, I love that. And I think thinking about it in terms of your revenue growth is a simple way to do it. But I think the real answer is a little more complicated. I think there's a few more axes, because you could be a $5 million MSP and be throwing off negative EBITDA every month, so you're still not ready. So while it may— the revenue itself is really just sort of an indicator of current status, but it's not a leading indicator of where you're going. So if you're going to invest in cybersecurity, you need money and you need to be a profitable organization, I think, to take that kind of effort on. And I think there's a few other things too. I think You know, in terms of the vision of your organization, you know, I'm not even, I don't like the term MSP or MSSP. I feel like those things are bloated and vapid these days. But I think if the vision of your organization is to solve certain problems, your venturing into cybersecurity should align with that too. So it's very much culture, core values, vision, EBITDA, and then revenue for me, of course, is is a big one as well.

But no, yeah, it's, it's, it's an interesting juggling act. And when it comes to the offerings, whether you call it MSP or MSSP, right, there is some investment you need to make to build out that foundation of delivering the services you're profiting on. And I think this kind of leads into really what we were looking to discuss today, because we do have some frameworks around this on What are some of the risks that we have when we are starting to offer cybersecurity, yet maybe we're not prepared to deliver on some of these cyber tasks? So, Alex, I don't know if we— where you want to start here, if we want to go, um, just sick or just down the list here.

Um, but, you know, service level arguments are always a great place to start.

Let's go there. So let's, let's talk a little bit about this because Wes, help me out here. I'm not the cyber guy. Everyone knows that by now. What is it with SLAs and cybersecurity that MSPs may be getting a little over on their skis on?

Well, Alex, I've literally never heard anyone call it service level arguments.

I love that. It came from one of our partners at Lifecycle, and his point was, if you're talking about SLAs, you've already lost. Yeah, because it doesn't matter if your SLA was 4 hours and you responded in 30 minutes if they needed it fixed in 12 minutes.

Yeah.

And if you have a 4-hour SLA and that's long enough for a cybersecurity breach to spread across the entire organization, great. You responded in your SLA, you still lost.

Yep. And then on top of that, service level discussion, you're beat. Yes. And then on top of that, I remember I hate to excuse my French, but it sort of ends up becoming a pissing match to a large degree. And here's why I mean that, because I remember in my Perch days, oftentimes we'd come up to a competitor and they'd be like, well, you know, the, the purchase SLA is like 2 hours and I found one with 20 minutes. I'm like, woohoo! You realize that there's literally no standardization between the words, uh, uh, service level agreement. There's literally— there— so, and here, here's what I meant. I was like, give me the SLA. So the, the prospect gave it to me. I took a look. I'm like, okay, I'm reading. There it is. All it says is within 20 minutes they're going to start processing the alert. And I'm like, do you know what processing the alert means? And they're like, no. I'm like, so all they're telling you is some system is going to pick it up. Well, if we want to go by those words, then the like purchase SLA is instantaneous. It's milliseconds because we start processing the alert the instant the engine sees it. The question is not when we start picking that SLA up and when we start working on it. The question is when we actually deliver and finish. And a lot of times that's the real thing that we're going for is when is the alert going to be fully reviewed? When is it going to be assessed? When is it going to be escalated and sent to the user for action? That's the question. And unfortunately, I hate SLAs, but you're getting me on a soapbox because they never determine and dictate any of that. You'll never find a company that says, oh, within 2 hours we're going to have in your hands a fully fledged everything you need to know SLA, like fully answered escalation in your hands. No, they're never going to do that. And so we sometimes mislead ourselves in that. And then we go to clients and we say the same thing, and then something happens and it burns down and you're too late. The client says, you You told me you had a 20-minute SLA and we didn't find out about this sucker for 4 hours. Then we didn't take action for another day, but let's ignore that, right? So I'm— yeah, SLAs are just such a garbage metric, largely speaking, and literally don't help us. They, they just turn us— it's a marketing tactic. Am I wrong, Reg?

I would agree with you. This is— it should be focused on outcomes, you know, because there's a lot of— everyone's busy. You can show business all day long, but if it hasn't solved the problem But I think this is a communication issue. It's an education issue because I don't think the goals are really well defined in cybersecurity, particularly in an incident scenario where, you know, things are sideways. Most things are sideways and everyone's, you know, running around with their hair on fire. So you have to, I think you've got to be very clear about setting your expectations, what you can do, what you can't do. I think we're going to talk about incident response here. You know, I've been fortunate or unfortunate enough to have, you know, run incident command for probably close to 100 incidents, some of them the biggest, you know, headlines that people have seen here nationally. And yeah, I mean, I think a lot of it comes down to execution and outcomes and what's on the, you know, what's in your contract may be meaningless by the time you get halfway way through.

Well, and I think if we go to, uh, Alex's kind of definition of service level argument, your customers will have an expectation, right? They're gonna have an expectation on whether it's timed or it's just we have shit to do or we need to protect our businesses. We, we have an expectation on how long it should take you to get to something. And I think this is where it's a fun conversation, because if you are a $1 million, $2 million MSP where you've got one or two guys on the help desk I don't know if you ever have the wherewithal to guarantee any type of response.

So do you think— do you guys— I'll just throw this out to you all. Do you think that service level agreements, because they typically came out of the world of IT and there's a lot more tangibility and measurability behind this, like voice over IP uptime, right? And I can deliver an SLA on that. It's very calculated.

4 nines.

Yeah. Do you think because SLAs came out of that world, it's far more measurable? It's just a— it— what am I trying to say? Is that— is that the source of where SLAs became so messed up in cyber because of how much more intricate cyber can be because of the— how alerts happen, how they're investigated, true and false positives, investigation time, severity, all that kind of stuff? What do you think?

I don't know. I've never even dealt with SLAs. I mean, the only thing we actually— or I have committed to or my companies have committed to is We had basically a cyber 911, 800 number where you were guaranteed to talk to a human being within 5 minutes and you were guaranteed some direction on resolution within 59 minutes. I think it was the lowest that we committed to, but that was really, you know, we were working with enterprises, so it was different. So they weren't really small things that we're talking about, you know, tens of millions of health records or, you know, 60,000 endpoints encrypted in the last 2 hours. So they were big, big problems. So, but honestly, I've never had an SLA.

It's an interesting thought, Wes, of, and I think you see this quite often, and honestly, we could, we could go zoom out the lens of because we're IT providers, we should be cybersecurity providers, right? We, we think that there's a, transition or a, uh, some homogenization between both parties because they both involve technology to where it almost creates an expectation for some of, I have to provide cybersecurity. And I like to go against the stream a little bit to where I don't think all MSPs have to. I think if you set up the right procedures, right partners, the right letters of indemnification, the right expectations with the customer, You could tell them, I'm just the IT janitor. If someone decides to steal from you or if someone decides to let somebody in the front door, right? And I think we use the analogy of the general contractor in the front door of your business, right? We don't hold the general contractor responsible for someone breaking into your office, but for some reason that's happened.

Yeah.

Yeah. Maybe we should rethink this.

Well, I think there's a lot of momentum and certainly every vendor in the industry backed by PE, VC, whatever, you know, has got to turn some multiples. And I think the growth for them is certainly in selling more shiny gadgets and cybersecurity sort of a greenfield opportunity for them. But yeah, absolutely. I think MSPs do have a cybersecurity responsibility if they're even touching or coming close to things like MFA, 365 licensing, firewalls, encryption, things like that. But there's a— I got to say, we work with dozens and dozens and dozens of MSPs all over the country. And usually when we get into a new prospect, even the basic stuff isn't handled. Like, you know, password hygiene or encrypting endpoints, you know, just, just some basic stuff. And so I feel like the, while the industry is pushing every one of these MSPs towards these massive investments and changes in their business model, which could be honestly deadly for some of them, they've ignored the fact that we really haven't handled the fundamentals for a lot of these SMBs. And there is absolutely a lot of growth there. So I, I'm kind of in the middle on this argument. I feel like there's tons of growth opportunity for MSPs. In cybersecurity, but it ain't risk or compliance or incident response or workforce security. I mean, those are major danger areas. I know that's what we're talking about here, but there's so much opportunity for MSPs if they just focus on the cybersecurity around technology. Because, you know, if you look at all the basic frameworks, anywhere from 25 to 50% of any regulatory mandate framework best practice is has some technology, you know, related to it. It's, I think that's the place to start. And I do think there's a growth opportunity there.

So I want to drag an analogy a little further and see how it goes. I'm going to liken this to medical, right? And your family doctor, right? He's not the one who's going to go give you heart surgery. He's not the one who's going to go do something, you know, give you chemotherapy if you have cancer or something like that. But he does have an obligation to know that other experts exist, understand when to send you to the right person, and understand what escalation looks like beyond his general care that he can provide for you at his family medical office. So I think as MSPs, we're, we're more of that generalist than that specialist. There are going to be places where we just logically have to escalate to a higher power, even if that higher power is in our building. And when you're small, it's probably not. Does that analogy hold up? Is that, is that right?

It holds up, Alex. And I was thinking, I was looking at Jonathan's comments there. You know, I totally understand where he's coming from, right? Like disagree because there's, their MSP does have a responsibility. The question is, where does that responsibility lie and where's the expectation of it? And what do your contracts and agreements say? Because I'll tell you this, if you're using a managed EDR, they're going to disclaim away as much warranty as they can for anything, right? That's just in the nature of doing business. And same with your RMM. I've seen it before. I think we've all seen it. And so I think some of this comes down to shared responsibility matrices, making sure we built that, we've communicated this with the client, and also making sure that we have our own agreements that protect ourselves, just like our vendors protect themselves from us. Because it's not like Ford, right? Like if I get in a wreck and all of a sudden it turns out that, you know, there was a brake recall and like a— that it's a major flaw with the brakes, I don't necessarily go to my local Ford office and sue them like where I bought the car. And then, you know, the question is, well, do I sue Ford? Do I sue the brake manufacturer that is contracted through Ford to make— where does the responsibility lie? It gets murky for sure. So some of this you've got to make sure you protect yourself because the reality is the first finger the client is going to point to is you. They don't care who your EDR is and they don't care necessarily that you deployed it in detect mode without anything else. They're going to point their finger at you because you provide IT for them. So I think we have to be prepared for those eventualities and make sure that we really have communicated risk and what our responsibilities are, the client response our vendor responsibilities, and make sure that that is written in contractual language. That is, that is, that is, you know, because I think it's important that we hold ourselves up to that because these things get messy and they get nasty.

Well, and if we go down the path of, you know, and I love the analogy, Alex, of, you know, what Jonathan is saying about we do have a responsibility. I think we owe it to ourselves then to understand where that responsibility starts and where it ends. And I think we need to have a definition of where it ends. Ends and that definition to be communicated to that customer or client, because that's the only way that I am able to protect my business when it comes to having enough staff on staff or have enough people on staff in order to be able to provide that service to my client. Because the last thing I need to do is to put myself at risk and make those promises that, hey, even though I installed that firewall 4 years ago, I'm still liable for it, even though maybe you're a T&M client or maybe you're a managed services client that's really quiet and I don't really touch your office that often. Right, then I need that economy of scale to go, hey, you've hit that boundary, and I'm only a $2 million MSP, and if you decide to get CryptoLocker your entire network because the, you know, bring bring, this is the FBI, let me in your computer. Okay, I'll let you in that computer, and now the next thing I'm, I'm expected to dump 40, 50, 60 hours in getting that customer back up when they declined that extra service.

I think you're, you're touching on something that just irks the hell out of me, which is there are folks out there who believe that every MSP has to be an MSSP and that we shouldn't have any more T&M, that T&M should be dead. And I think that sounds great from the MSP side and it sounds great from the all my contracts are standardized and my life gets easy. It doesn't start, it doesn't sound so great when I'm starting up my mom and pop business and I don't have a ton of money and I'm not bankrolled by somebody and I'm trying to figure out how to get that small business off to get off the ground and my security expense and my IT expense is so significant that I just can't start a small business or no MSP will take me because I have 3 users instead of 10 or 30 or whatever their minimum is. So there's a place at which we have to find a way to provide service to a smaller company who maybe doesn't have the budget or even just the endpoint count to meet the minimums of what can get to be really expensive cybersecurity services from, from MSPs.

It's the all-or-nothing thinking that the MSP channel seems to do, right? Which is, if I do it, everyone needs to do it.

Yeah. And when you're $3, $4, $10 million, whatever, that's easy. But Reg, I'd love to hear your opinion on, you know, what's left for when we go to that extreme for the small business.

Well, I, first of all, if I could just comment on the industry. So I often get labeled as a vendor hater and I'm really not. In fact, I think those vendors are doing—

It's okay. This is a safe place.

Probably what I would be doing as well. Listen, we've all benefited from VC and PE-backed exits. Let's face it. But they're selling cheeseburgers. You can't blame McDonald's. For you being overweight or out of shape. They're selling their products. It doesn't mean you have to buy it. I think, you know, we're critically missing some just general critical thinking about the industry and what's actually working. And if you just look at a few basic metrics, so if you trust ConnectWise and Kaseya and others, that 94% of all SMBs are looking for a new MSP because they're not happy with theirs. 60% of all MSPs are basically at the break-even line or less. And they're, you know, the metrics go on and on. You know, this, the model that we are operating within right now, I was there when it was invented. It's an antique just like me. And it's showing its age. We have to evolve in cybersecurity has kind of been that straw that broke the camel's back because it we didn't realize how big this thing was for MSPs. And I still think as an industry that the MSP strata in cybersecurity still doesn't understand exactly what cybersecurity is because it's not about SIEM and MDR and it's just not, that's not what we do. That's not the goal of cybersecurity. And that seems to get completely lost in these conversations along with, is it good for the customer? So Alex, I think you were kind of going this way. Which is, hey, listen, we could be busy all day long and sell you tons of stuff. But if it's not producing value and positive outcomes for the customer, one, you're probably not going to sell a ton of it. Two, you're not going to keep those customers. And three, along the way, you're just going to end up losing money or worse in services that you probably never should have gotten into in the first place. But defining that jurisdiction is something that is very taboo right now. And, you know, we feel like we took it head on 3 years, 3 and a half years ago. And we've been screaming about this, but I just, you know, we've not been met with a lot of, they haven't rolled out the red carpet for us because a lot of the industry, the momentum is towards selling more stuff, more gadgets to address cybersecurity. But that's just never going, you can't build a house with hammers alone. That's just never going to solve the problem.

Well, and I think this goes to Wes Spencer's line of thinking, and I know you and I have talked about a lot of this, where we're trying to force some of our MSP, our IT knowledge and frameworks into MSSP. And Alex, you and I have also talked about this on the vCIO side, or like how I refer to it, fractional CIO, where we think it's always an all-you-can-eat model. It's this economy of scale to where I can a flat fee because I suck at selling and I suck at product development to where I can just go screw it. I'm going to make this easy for me as the MSP, not my customer, and not the scalability of my business, right? I just want to work on the nerdy crap. And the next thing you know, we go, oh crap, how come I can't do cybersecurity in an all-you-can-eat model? Well, because you can't account for some of the things that happen in cybersecurity as an all— they're not— they don't happen so routinely that I can drive those costs down. Right? Like, I can't offer an all-you-can-eat cyber other than a SOC because, well, pen test is routine, right? You have no idea when an incident's going to happen. You have no idea when you need to restore a client's entire network or spin it up in the cloud. Those things are just unpredictable. It's that— not if it's going to happen, it's when it's going to happen.

And compliance requirements are all over, right, Wes? I mean, small MS— small company, big company, huge difference in exposure where where compliance is required.

Yep. So, so what we're saying as we move on is be careful about not setting your MSP up to be a house of cards, right? Revenue seems to be great and margins seem to be awesome when you're taking— we have intake left and right and all these clients coming in and people are buying all your cybers, you know, and the cyber sweatshop's kicking into full gear. Good for you. But you are correct, Kyle, when it hits the fan and we can introduce you to MSPs whose fan has been hit. All of a sudden, all of that evaporates almost overnight, or at least it could. This is why Cyber Insurance, as an example, can operate because they're doing what they're doing at scale. They have breach coaches that all day long are picking up the phone and dealing with incidents, right? They have incident response folks that all they're doing is handling incidents. They're built for this scale because it's what they do in and out. We do need to be careful about what the ramifications are of what we sell when we're not prepared to handle the right side of boom. When something occurs and we've never or rarely deal with it. This— I mean, we've seen this, this play out over and over and over in anything in life, all walks of life. If you're not prepared and you haven't gone through this one piece of the journey, but once in your career, don't be shocked when you mishandle and fumble that football badly because you just don't have the practice for it. We got to be prepared for those things. And who are the folks that we call up when that happens? That are in good practice for that. We need to be thinking about that. And maybe there just are things we should not be doing when it comes to that. Incident response is a great example of that in my mind. I think MSPs saying, "We'll handle incident response for you," terrible, terrible thing to do. Now, being part of incident response and having someone over your head that's directing and leading, totally fine, right? But, but yeah, I think we need to be careful of not biting off more than we can chew, to use an elephant analogy.

Dude, I guess I should have used my sound effect. Okay. And but, and, you know, even at an MSP level, right, I've seen this and I've told you guys the story. I think I've said it even on one of these episodes to where I had a client and I still work with them. They got talked in by big global MSP vendor. Hey, buy this EDR, we'll give you 40% margin on all the endpoints that you sell. And by the way, we have a managed SOC. So we'll go ahead and look at all of those. Well, what they didn't expect across their 6,000 endpoints was all of the extra incident tickets that would hit their PSA because they passed through the SOC and they said, hey, you need to take a look at this. And the next thing you know, they have an extra 20 hours a month in response that they have to provide. Now, yes, I do agree, Jonathan, we do need to provide it. But how do I build a product model to offer that security service to where I, as a business, can still have profit in my business, I can predict that profit, and I can pay my employees a fair wage in order to have this whole thing continue to go.

Yep, that's tough.

And when it's compliance, now I got a big old bullseye on my back if there's an incident, because the insurance company is going to come asking me, well, what did you do?

Yeah, I, I thought you had— you were supposed to have that covered. Charge, right? That's the— there's the compliance problem. And we used to hear this at Lifecycle all the time. How much should I charge to help a customer get CMMC compliant, or insert compliance framework here? Um, and that is such a scary question. And as an MSP, you know, people would want to roll it into their per-seat cost. You know, can I just include CMMC compliance if I add $50 a seat, $75 a seat? No, I don't know. How many seats do they have? Well, this customer's got 25. Okay, well, what about the customer that has What about the customer that has 200? What is their exposure? What do they have that needs to be brought into compliance and included in scope? And as MSPs, we've been trained that everything goes into per-seat cost. And then compliance comes in the room and just blows that whole thing up because I can't charge enough per seat to do CMMC compliance all you can eat, right? Two-seat client, no problem. $200,000 a seat, we got you covered, right?, but that, that number doesn't sell very well. Um, but it's the conversation that we haven't had ever since we were told it all must be, uh, all included and no line items on your invoice, and it's all got to be included in a flat rate.

Yep. And retainers are bad, and T&M is bad, and right, all these things that a true MSSP may actually look at these as professional services and T&M, right, with the right retainers, because that's the only way you can account for those things where I didn't know some guy was going to break down my door and hold us ransom. I didn't. Right now, this is also where I had my eyes open quite a bit working with our friend Tim Golden over at Compliance Risk, where there's an entire side of these compliance areas that are just pen and paper, right? A lot of these are contractual, right? This isn't technology. This isn't the firewall. This is, did you fill out the paperwork right? And I'll be quite honest, and I would love to see in chat How many of your engineers are good at paperwork? Oh, wait.

Yeah. So this is, this is an area where, you know, going back where I might actually disagree with Alex is we're not generalists versus specialists in the healthcare field. It's like going to your doctor for an accounting because there's only minor overlap. Risk could not be more different than IT for 100 reasons. And I rant about this all all the time. With IT, it's very binary, meaning if you need storage or a Microsoft license or a laptop, you buy one and you have one. It's completely symmetric. In cybersecurity, you can invest a lot of time, money, and energy in cybersecurity and not be any better off. And I've seen plenty of SMBs rolling the dice, doing nothing, getting lucky. Risk is like voodoo. There is nothing tangible about it and there is nothing binary or symmetric about it and it's never done right. So if you need to get, you know, to X storage, you buy it and you're done. Like there's a finish line. There's no such thing in cybersecurity. So for me, because most of what we do has a risk layer, even if it's a compliance-based, you know, project, you've got to bring it back to risk for the organization because that's how they evaluate whether or not it makes sense to invest. Does it support the business mission? Is it a competitive advantage? Does it decrease costs or exposure? And so, you know, if you've got a strong IT mind, you're probably not the kind of person that can, you know, navigate the waters of subjective risk evaluation. It is just completely different.

And not only that, I—

oh, sorry.

Yes, sorry, not only that, I mean, the frameworks themselves are usually up to two-thirds the pen and paper or process or people or culture or, you know, things that have nothing to do with technology. So listen, the MSPs who decided not to work with us, really good people and wanted to do great things for their customers. But let me tell you, they're probably heading down a path that they're going to regret at some point, whether it's us or someone else. Because they— I don't think they understood what they were getting into and the type of work that it actually is. It's completely different.

Well, and I can tell you, when I built out my MSSP, Rich, I thought, you know, just completely ignorantly, I could turn a helpdesk guy into a SOC analyst. Right. And I sat him down in front of the SIEM and we had this complicated setup with ServiceNow ingesting all this stuff from the SIEMs.. And I realized real quickly, if they hate paperwork on the help desk side, they're really going to hate paperwork on the SOC side because you are literally just whitelisting and blacklisting and you're getting down to the nitty-gritty and you're going in documenting everything. That it just wasn't who they were. That wasn't the thing that drives them. So I had to go through this entire, just complete revolution in my own mind of, this, this is a different service model. It's a different way of working with a customer. And I think this gets perfectly into the incident response subject because even with compliance, they're going to judge how you respond.

And there's no more documentation than an IR.

Absolutely. Yeah. Well, not only the documentation beforehand, but the post-incident scrutiny. I can remember one case we spent probably 6 months responding, major healthcare, you know, a health system with probably a 2 dozen, you know, maybe 125,000 employees. And the incident we brought to closure in probably, I think around 4 to 6 months, something like that. My memory's horrible. But I do remember working and just fighting with the Department of Health for a year because we were able to, through forensic analysis and investigation and working with the FBI, et cetera, doing attribution that actually while the healthcare asset was accessed in an unauthorized manner, there was no breach as breach was defined legally. Took us a year to do that, but that was never really, you know, that required a whole different set of thinking, legal, crisis communications, law enforcement. Insurance, regulatory oversight. And honestly, most of the incidents I've been involved in, I spend way more time dealing with, you know, attorneys and, you know, third-party risk than I do technology. Usually the technology is one of the easier parts. So to expect an IT-focused provider to come in and coordinate some response to effective closures, just not realistic. There's just so much else that goes on in response and you will be scrutinized. I promise you, in the right scenario. I mean, I'm sure there's thousands of incidents that go and people just, you know, reimage machines and go on. But you're going to run into one of those situations where someone's asking questions. Were you prepared? Did you follow your own incident response plan? What did you do about Evidence preservation. What did you— and you're going to end up in a hole that you just cannot back out of.

It reminds me actually of an incident that I even responded to with my MSSP where, right, if you're gonna— and by the way, I do want to put out that there is a right way to do this as an MSP, and there, there's 100% the ability to transact this and to build out a service line to make these things happen. You just have to be willing to put your money where your health is. I know when I hired my first CISSP to manage my SOC and manage my service team, that was the first employee I hired at $150,000 a year. And this is back in 2015, right? That was like that first moment of going, oh shit, I thought a Tier 3 engineer was expensive. Like, I remember losing sleep for weeks on end going, oh my God. And we luckily had some really good advice to have them be separate companies with different EINs. Just in the aspect that one got prosecuted versus the other, right? The whole company wouldn't fall apart. And I, man, the attorney that gave me that advice was still to this day, like, that was the best thing that could have ever happened. Because when we did have these items happening, they had to sit in front of basically a board saying, here's how we responded to everything, here's all the documentation, right? There was that first moment where I'm going, holy crap, this guy just paid for himself because he could have sunk both ships. Because I hate to say We had a— our MSP team left RDP wide open and had some accounts with no passwords, and it was our fault. So at the end of the day, right, having those types of documentation, I had to pay for it. So Wes, I'm curious on your thoughts. You've been quiet.

On what part?

For real.

We've been talking, I guess, on the incident response piece. Yeah, well, uh, I, I think I've mostly shared it. It's funny because we stumbled into it earlier. Um, I just, I do think that incident response is a dangerous piece for— like, I don't think any of us are saying don't be prepared for incident response.

Don't—

none of us— you, you have to be, right? You have to have an incident response program in place. Uh, your clients need to have one in place. You need to teach them what it is. Uh, if you're looking for a good one, check out Tim Golden's. We've mentioned him before. He's got a really good incident response program. You should be cybersecurity insurance aligned. You should make sure your MSA protects you against all of these things. But I think you just have to be prepared for what we said before, the eventualities of what you just won't be in practice for and you don't have the capabilities of delivering. And Reg did say it correctly before. One of the tricky parts of security is sometimes you just can't calculate the cost of an incident and you don't know how long it's going to lurk around. And something that seemed not so bad turned out to be horrible. And those are the things that will literally bury your company, let alone the fines, let alone the litigation, let alone all of the lost business. Those are things that will get you into a whole bunch of trouble. Now, I'm not trying to turn this into a cyber insurance discussion, but this is a great example of like we already turn to others as an MSP in certain areas we're not capable of. Insurance is one of those.. But even understanding, like looking at, you know, like an Orbital Fire, someone that can provide a lot of the services and capabilities that surround that, that are left of Boom to help us reduce this incident from even happening. That's also something that we need to have in place. Right. And so, yeah, I think it does require a good attention to detail and a lot of thought of what can we realistically do. And maybe a good framework to think about it is what are the things that we routinely do day in and day out, week in and week out that we're comfortable with. Anything else we should write down and say, we don't do that often. We don't do that hardly at all. Maybe these are things we need to figure out a partner for that can help us because we just don't do them and we'd rather not make the revenue off something that we think we can do because we're just building a house of cards and it's going to come tumbling down pretty quickly.

I'm going to sell this text for $10 a user per month, just hoping that everything happens and I can pocket the money.

Yeah.

On, you know, there's a lot of things, and this is why those checklists and those templates are so powerful. There's a lot of things we just don't think about, right? Having all the phone numbers handy. Stupid simple as it sounds, when you're in the middle of an incident, do you want to have a document you can open up that says, hey, here are the people I call in the order that I call them, and these are the instructions I'm looking for when I talk to this person? Or do I want to be rummaging around on Google for the right phone number or for access to a piece of information? You know, an insurance account or an attorney phone number or whatever it is that I need to do in the middle of crisis.

You certainly don't want to be caught going, hey, Mr. Customer, can you call so-and-so because I'm not an authorized user to discuss with them? Oh, by the way, you're on fire and your business is stalled and no one is working right now, but can you make that phone call for me right now because I, I don't have permission to talk to them? Yeah, you're gonna look real good to that customer. Well, especially when it comes to the workforce security side, right? There's going to be moments where you do have it 100% fortified. And right, this is the MGM example. MGM probably had really good lock and key on most of their shit. Would it take one phone call?

It was a failure of controls.

It was a failure of process.

And it was a failure of, uh, was it not a third-party help desk? I don't even think it was their help desk. Um, so I think that just brings it even more close to home. But I saw Reg snickering over that one. I would love to hear your thoughts.

I just think, you know, this is a psychology problem. It's a lizard brain limbic system problem. It's a cognitive bias problem. It is a behavioral change issue. This has nothing to do with technology. And by the way, MSPs are really good at MSPing. They're not necessarily the folks with the highest emotional quotient or sensibility around behavioral change and, you know, motivating human beings to do different things. I just— it's— they're very different skill sets. So I know, and listen, companies that I work very closely with and adore are selling awareness platforms to MSPs. I get that because customers are being, you know, they're dragging their MSP into these things or the MSP sees this as a growth area. I don't really have a problem with that. What I have a problem with is the solution stopping there, dripping out awareness training once a month and maybe doing a little social engineering testing, that, that's not an awareness program. That has nothing to do with behavioral change. Are those elements that can be very useful in pursuing that goal? Absolutely. But listen, at the end of the day, whether it's an awareness platform or a hamster wheel, no one really cares. The job there is to make people more aware of their security responsibilities and and more importantly, actually apply those skills. I'd argue that 99% of the end users at our customers, which, you know, we're getting close to 9,000 now, the vast majority of those, they have the skills to recognize a social engineering issue or a scam or a compromised website. Well, what they don't have or aren't willing to do is take the 2 seconds it requires requires to apply those skills. They're in a hurry. That's a very different part of the brain. You know, instinct and biases, you gotta kind of know how to deal with those. So if your training program is nothing more than a monthly drip of video, I say get out of the market because you're not helping the customer. Refer that business to someone who can actually help affect real behavioral change. And by the way, hopefully make a little bit of money on that. It's just a very different concept that requires very different expertise and skills and a very different approach.

Wes, is it me or does that sound like an advertisement for the talk that you and Connor gave at IT Nation? What was the title?

Yeah, Security Hasn't Solved a Darn Thing in 20 Years, or Cybersecurity Awareness Training Hasn't Solved a Darn Thing in 20 Years. Yeah. And here's why. And yeah, we just went into— I was worried at first that we were going to be a little too esoteric, but it ended up being a really good thought exercise, as conferences ought to be, on why we're not doing a good job with this and where we keep running up. It's what you just said, Reg, how we keep running up against the philosophy problems that exist behind the scenes. Right. And our human native inability, like requirement and ability. Society is built on trust or desire to want to trust one another.

Right.

And so, yeah, we dove into that. I'm sure Connor or I would be happy to get you a copy of the slides. Well, maybe let's— maybe we should have Connor on and we can actually redo the presentation at some point.

Right.

But yeah, I think it's healthy to talk about those things because, yeah, the human, the human psyche is flawed and bad guys have been preying on that since the beginning of time. And so this adoption of using cyber as a means to do something that's an age-old problem has existed forever. Right. And we talk— I even talked about this. I mean, it goes as old as creation literature. Culture, right? Like, uh, you know, look at like Adam and Eve and the apple, right? Being tricked into eating the apple. Like, this is embedded in the very beginnings of our, of our, you know, who we are and the mythological backgrounds of, you know, it's, it's just there. It's, we've always been subject to these things.

It's kind of interesting to think about, honestly, is you're, you're really becoming a human consultant, right? You're looking at the psyche and the culture of a company and, and how they enforce process when it's not the technology process, it's the operational process.

And I think there's two other important considerations. One is this— this term gives me the chills— it's the human firewall. These things could not be more opposite. I mean, the firewalls don't have bad days or hate their boss or want to quit. You know, they're not disgruntled. They do exactly what you tell them to do every single time. They're nothing like human beings. To call them human firewalls, just— and I get it's just a buzz term, but I just— it drives me crazy.

But—

and now my second thought is gone, but I'll come back.

Well, and firewall would not have lost the second thought. I'm just—

it's just gone.

Well, right. Or just people forget, right? If we get down to conditioning, right, we go back to Pavlov type stuff. I know I bring it up a lot because I talk about behavior all the time. You have to introduce those stimuluses quite a bit for it to continuously happen, right? And do I have the wherewithal to check in with people if it's in between those phishing tests, right? Is it— yeah, I do it quarterly, but between the quarters, I can tell you right now, Joe at the front desk is going to forget. He doesn't care. He's making $8 an hour. And this kind of goes into pen testing a little bit, and this is kind of the last area we wanted to get to, but I don't know if MSPs really understand how much goes into a pen test, like a true real pen test.

A good one, you mean?

Not a $99 one?

Well, I'm going to push that a little further.

I'm going to push that a little further.

Yeah.

I want to— before you go into lack of standardization, I want to tell my MSP pen test story. We get a phone call. From a town in Delaware, a municipality, and they said, we got state money and the state's going to pay a vendor to come in and give us a pen test. And I went, oh shit, I don't even know what that means to me, but I think I'm in trouble. And so I went and got the smartest guy I know, and I sat down with him and said, what's going to happen to me here? And he goes, well, you're going to get beat. The important thing is that you prep them for that and that you learn from it. So we prepped the client. We told them what was going to happen. We kind of explained it all to them. We expected to come in and get beat. And then the guy comes in and he runs a Nessus scan and he goes, looks good here. And he packs up and leaves. And that was it. And my mind was blown, but we looked like a rock star, of course, because we've got, you know, layers of security deployed and ACLs and firewalls and all that, you know, everything's actually set up with security in mind, but they didn't dig deep enough to find anything, even if it wasn't right. You know, they were just looking for 3389 hanging open. And so, Reg, as you start to dig into this, like, there's no standard. Somebody got paid to call that a pen test.

Yeah, which is okay. I mean, it's a very organic process. Again, very non-binary. I think the— there are other issues. One, obviously, segregation of duties. You shouldn't be testing your own stuff. But two, and probably the most important for me, is what are you going to do with the results? I kind of think like it's It's like the dog that actually catches the mailman. Now what? So the fact that you were able to pop a firewall, let me come back to outcomes. But now what? What do you do with that data? I think it's important to recognize that the reason we do penetration testing, in my opinion, is to identify exploitable vulnerabilities that might impact or cause disruption to the business. So jacking a firewall, who cares? Like, that is meaningless to a small business. Can you wire money out of an account? Can you download intellectual property? Can you get to regulated data? Can you, you know, compromise global admin credentials or other reputational assets? Those are the 5 things that matter to small businesses. Nothing else does. They don't understand if you're able to get to the directory and escalate privileges. Okay. Like, and honestly, for us, we don't care either if our customer goes out for a third party, because if we're in a customer, we always recommend that they use a separate penetration testing firm. But if a pen testing firm, you know, $250 comes in and they were able to get to a directory, like, okay, whatever. Like, what does that mean? It's, it's generally useless. So I think you shouldn't be testing your own stuff. There should be standards, which that's not an MSP's problem. And the reality is this all comes down to risk. And unless you can speak that language and bring those outcomes back to stuff that's meaningful to the customer, it probably wasn't an effective test anyway.

And it goes back with pen testing even on the MSP logic to where we think we have to have no tickets or a pen test needs to come back perfect, right? The goal is 100%. And that's just not the case, right? Because things change so often and users change their own environments so often that you're never going to get 100%, and that is okay, right? It's, it's the— and I love that you put that frame of mind on this, Wes, because I thought the same thing. And I'm like, oh my God, I can't tell my customer that they got a 73 on their pen test, right?

Just could—

I couldn't get myself to it. So we're doing all of this work, I'm losing money on the client trying to prepare for the pen test to make us look perfect and that's just the, the naiveness that we sometimes approach it as. So with that being said, we are approaching at the end of the, uh, time, and I do want to thank everybody. Wes, uh, wanna, wanna talk a little bit about RejectionCon real quick?

Heck yeah! I see a whole bunch of people on this webinar that haven't registered for RejectionCon. Come on now, my friends. So, uh, if you don't know about RejectionCon, uh, we have a speaker here with Reg, which Awesome. The way that RejectionCon came about was really simple. I had ran into a whole bunch of MSP friends. They're like, hey man, I had this talk, I was so excited, I didn't get in, and I'm sad about that, right? And we— everyone deserves a voice. Everyone has a story to tell, and RejectionCon is about that. Sometimes the big conferences, the BlackHats of the world, or even MSP conferences, sometimes let in the same people over and over and over, even this guy, right? And sometimes you want to hear from someone new as a fresh perspective. And that's what we're about. And so the cool thing about RejectionCon is all the, all the proceeds from conference passes go to charity. It goes to the Rural Tech Fund. It's a 501. They impact every single state in the country, helping reinvest and get STEM, you know, science, technology, engineering, math going. It's for underprivileged communities. How awesome is that? So knowing that your dollars go to an amazing cause that actually helps MSPs and the IT world as a whole is a great thing, knowing there's amazing talks that are going on. All I need you to do is go right there and register, rejectioncon.com. Get in on that. We have an MSP pass, so if you're an owner today, go buy a pass for your entire company. If you're just a regular attender, whatever, that's fine. It's a pay-what-you-can model, but I do want to see you pay because I want to see this go into charity. Uh, rejectioncon.com. Hope to see everyone there. It's going to be awesome.

And then Reg, kind of maybe fill us in a little bit on, uh, you know, how the community can interact with you guys.

Sure. You know, so, you know, our program is really purpose-built to complement and not compete with MSPs. If you want more information about what we do and how we do it and how we can help you, whether it's with minimizing your liability in an incident or helping you sustain or improve your customer retention rates, I mean, happy customers tend to stay longer. And by partnering with someone who's going to handle cybersecurity, we've, we've got the math, the data is there. It works. OrbitalFire.com or partners@orbitalfire.com if you want to email us. And if you want to argue about something, reg@orbitalfire.com.

I love that. If you want to argue with me.

You might regret giving that one out.

All right, guys. Well, it's been a pleasure. I'm going to go ahead and let everyone out on time. Time today. Thank you very much. Give us feedback on what you thought about the Crowdcast environment. Thank you very much, Reg, for hopping on. Everyone else, see you next week when we go back over employee onboarding processes. See you all then.

Woo-hoo!