Session 1

All right, we are live. It's here already. Welcome everybody to the incident response planning session with my great friends, Wes Spencer, Gary Pika, Mike ard, and Chris Laer. Gary. Um, man, this is coming off yesterday's cyber call, which was, you know, I think one of our best around agreed, uh, you know, cyber insurance. We talked about, you know, what happens after. Um, so let's see what we can do today to prevent those types of things from happening.

And with that, Gary, are you prepared a few slides to kind of set the stage here and, uh, lemme let you Yeah, I just wanna make sure everybody, we assume everybody knows, uh, everybody here, but, uh, Wes Spencer is a CISO of PERT security, uh, best in the business. Uh, Chris, man, I've learned so much from you, uh, your perspective because you're dealing with things, you know, once a breach has happened, had just been invaluable, right, to everything we've done.

Uh, and Mike, we've got a chance to know each other on the, on the cyber call coming from a practitioner standpoint. So just a really, uh, all these different angles, Andrew, is really, I think, what builds value, especially on a topic like today, which is a very broad nd uh, topic. So, oh, a couple things. Uh, we have something here for you, a cybersecurity ebook. Andrew, uh, will post the link true methods.com/security, Right, right below Gary, right? So there's a, a green There.

It's, Uh, call to action right there. You can always just click, it's a click away. Yeah. Also, if you are not already signed up for the cyber call, uh, and also the cyber nation, um, go ahead. Here is a great place to start. True methods.com/cyber call. So here's an overview. Um, what we did in the last session was a tabletop exercise. So the team went through we really good overview of the threat landscape, right? And what's, what, what's happening out there.

And then did a review of an actual breach scenario that was so interesting. The engagement level on this was so high. We had over 700 people registered, kind of the do's and don'ts. And the feedback that I got overwhelmingly Andrew, was, it was an eye-opening, and we did a poll and 75% of the people said they would watch that again, 90 minutes worth, and they would share it with their team members. So we had to do a follow up and go one level deeper and actually talk about, you know, the plan.

So today what we're gonna do is, um, talk about how to approach an incident response plan development of that. We're gonna review a couple different plans. One that's really awesome, that's, that comes from Microsoft. And then Mike is nice enough to share a version of what he actually created, uh, in his business. We'll talk about some of the top mistakes to avoid, and most importantly, how to make this thing a living document. Because if it's not, it's already outdated, right?

This can't be like your business plan MSPs that you do once, and then you take it out, you know, a year later out of the drawer. Uh, you can, you know, it's not the best way to run a business, but you can get away with it. You'll just won't get as much done and maybe not make as much money, but this has really serious consequences. So, uh, that's it, Andrew. That's all I have. So, with that, uh, we're gonna start with Wes kind of leading the beginning of this conversation.

So, uh, I'll hand it over to my good friend Wes. Yeah, right on. So, uh, Gary, I need to know how to get one of those microphones you had in your biopic. Uh, that was pretty awesome. Oh, that's a road podcaster. So I, I, I'm in my, I'm not in my home office today. Or you would, you would see it When I get to the big leagues like you. And if you'll hit the stop sharing button, that'll let me, uh, take over. Uh, but when you get to the bigly, I get to the big leagues.

I can't wait to have one of those. Alright guys, so, um, Hey, how I, I send you a microphone and you send me one of your awesome cameras. Would that be fair? That would probably not be fair. Not Be fair? Yeah. Alright, guys. Hey, we're Go ahead, Andrew Off just real quick. Do you want me to pepper in the questions? How do you want me to, to do that? We had some, you, you know, I'm ha I'm happy to go, uh, however you want me to do that. Yeah, I do. That'd be perfect. Both polls and questions.

And, uh, yes, as we go through them, or if you even have one organically as we start going through, pop it in there. When I see you type poll into the chat, uh, we will make sure to, to call attention to it. All right? So guys, we're gonna be really interactive today and what that means, those of you that are, uh, cyber callers that are on here, you guys already know this. Uh, we are using the chat like crazy. We'll use the ask a question. We're gonna use the polls because this is two-way.

The best thing about Crowdcast is we get to get really interactive with you guys, and that is the, the, the very idea. So, uh, that's what we're gonna do. Alright? So let me just start with that. Anyone in the chat, has anyone ever seen Microsoft? I'm gonna go pull the title up before I shared out their reference guide. Has anyone seen that used that at all in the past? I want to see in the chat if anyone's been active with that guy.

And while we're getting some chat, Wes, I just want you to know, I threw a poll out there to find out, have you written ha you know, an incident response plan. And again, you know, be honest, this is about not about us. This is about us doing what we can to help everybody. Hey, look at, look at the nos coming across. That's, uh, that's pretty awesome. So here's what I'm gonna do.

I'm gonna hit the chat and I realize we probably have like screen share inception going on here because of me sharing this tab. Yeah, it'll, now it should be cleared up. All right, so here's what we're gonna do, guys. We're gonna talk through, uh, Microsoft's instant response reference guide. And I'm gonna kind of play this role of a moderator as we go through. And unfortunately, maybe I can change my screen share a little bit.

I actually, now I can't see the chats coming through, so I may try to fix that in a minute. Um, but as we go through all of this, I want to kind of talk through this and I want to get the lessons learned from Mike regard who's with me. I also wanna get the lessons learned that come from, uh, Chris Laer, because this is some really, really good stuff. So I sent the link there in the chat. You can pull this up and look through it and kind of go through it with us. But I wanna start here.

This first, do no harm. This is really, really cool. I love that they start with this. So if you're thinking about building an incident response plan or fine tuning it, or maybe you've got one that's really old and honestly really bad, and you're joining this to fix any of those case and points, this is a great kind of conceptual starting point to, to begin with, is this idea, just like doctors look, the reason we're doing this is for two reasons.

One, we wanna avoid harm in our organization, whether it's a cyber threat, it's a physical threat. The idea behind all of this is augmenting our business practices. So we're much more resilient and much more safe against the things that may be happening against our own org, right? So that's really important. But the second thing I think that happens with all of this too, is, and Chris, I want you to elaborate on this while I fix my, my screen share a little bit.

You know, we also wanna avoid harm in the actions that we're taking in the middle of a cyber incident. So, so Chris, I guess a question for you is for, you know, you've handled probably thousands of cyber incidents in your role. Uh, have you seen some examples and stories where organizations actually cause more harm to their org in trying to respond haphazardly versus through an incident response plan? And if so, give us some examples. Sure, Wes.

So there's, there's a couple of couple of sides of this that we can talk to. First of all, from the legal side. So one of the things that we see can do a lot of harm, and there's been some articles recently, is when they just don't, um, they don't have the right attorneys involved at the right time.

And so they're taking steps, they're, they're putting things in writing, they're communicating things internally or to their customers or whatever the case without having any type of legal oversight or pr uh, crisis communication oversight. And so that's, that, that, that's a big issue right there. So, you know, from a technical perspective, especially with the managed service providers, the, you know, the, the first wires that connect or to jump in and start doing things technically.

But in the case of incident response, especially today, especially with the advent of the privacy and security laws and the, and the more your customers become, uh, more diverse across the country and even global, it's really key that you have those legal steps addressed and, and as early as possible, because you do not want to mess up there. And Chris, that's not a decision, right? You can make after you've been breached. That's right. You, you really need to make that up front.

I mean, it's, yeah, I mean, typically you're going to have, if you're gonna have insurance involved, they're gonna cover you on that legal side. So I really don't understand why people wanna delay that decision or put off or, or are scared of that decision. And I will still say today, we usually have, I'd say, you know, you know, uh, an occasional case come in where they just are, are scared to do that.

And it can cause a lot of issues and it may not cause issues on day one, but day 30, day 60 and on down, if something bites you, you know, one of the, one of the things that I've talked about in the past is like with hipaa, and a lot of times when you're dealing with very small, uh, HIPAA related entities, uh, they wanna just avoid that altogether.

The problem is though, is if they come back again in the future and the OCR finds out that they suppressed something in the past, it's just gonna be 10 times worse, uh, of what happens to 'em. So you wanna make sure you're in front of that at all times. So the other side of it is from a technical side. So what the, the big thing is, is in today's world, the forensic side is so important.

And so when we destroy evidence, whether we're rebooting things or wiping things or whatever the case may be, you're doing a lot of harm. So you might bring yourself or your customer up very quickly, but because you, you've destroyed what is necessary for forensics, the story cannot be told. And most of the time when that happens, the worst situation has to be assumed. And so that just makes things a hundred times worse than they probably actually were. Yeah, that, that's a really good point.

And I guess a question for the chat. We don't have to do this in a poll, but I do have a chat question. Gimme a yes or no back. Does your incident response plan, or if you don't have one, just your playbooks, your cyber response stuff that you do, does it actually detail and document for your entire staff things they can and can't touch from a forensic perspective? Just gimme a yes or a no. It's just keep it generic here. I'm really curious about this.

And while we're waiting for those to come in, ard, can you share a little bit more about why that's important? You know, uh, obviously Chris shared a lot about the, the, yeah, we're getting a bunch of nos coming in. Um, and that's important to talk about ard, can you share a little bit more about that? Obviously the forensics are important to it, but maybe how do you even get your MSP to across the entire organization? I'm gonna have to ask you to repeat Wes, I caught Mike, you're on mute.

Oh, did I, did I lose audio? Yeah. So quickly, my, my question was simply this, um, you know, how, how elaborate more on why this is so important, Mike, uh, of the protecting the forensics behind everything. Yeah, I, I think Chris, Chris actually hit it, right. The, the most important thing is most of the time an incident typically is not quite as severe as you think it is. And we do not wanna have to jump to that worst case scenario.

And that's, that goes through, you know, we, we've seen things where it's simply virus sandboxing that catches something and it looks like an incident and it triggers a full instant response plan type event. Um, and without that forensics information, we're not gonna know that, hey, this was actually a system designing as it should have in this case. Um, so it, it really is that breadcrumb crumb trail.

And that's it again, it goes back to every state's got privacy disclosure laws now on the record that could cause us to trigger and, and we have to be certain within that space. Yeah. So we're getting a lot, mostly nos I'd say 90% nos are what came across here, right? So that's a huge takeaway, right? We need to make sure that we include, um, training and education and awareness around the policy development to make sure that we protect forensically what's happening, right?

Because, let's be honest is, is most of us are like MSPs. We're, we're very hands-on people. When there's a problem, we go fix it. That's traditionally what we do in the world of it, right? In fact, we're so good at proactively fixing things before they happen. Um, Chris Laer, our inclination is to go fix a cybersecurity problem without really fully conceptualizing the forensic risks that we may cause by, by interrupting or ruining some, some data, right? So, what's the litmus test?

How do we know when an incident occurs, Chris? What can be fixed and, and like right away? And what things need to be forensically, um, uh, protected? What advice would you give? So, I mean, the, the easiest answer is just to understand your customer.

And if your customer is a regulated entity or you know, for a fact they have some type of data, whether it's P-H-I-P-I-I, it doesn't really matter, uh, if they have that involved, and it's kind of a no-brainer to me that you need to, to stop and pause and, and, and capture the forensics. I think one of the biggest pieces though is, is that, uh, a lot of times when we have to do forensics, there is nothing being logged or being captured in the environment at that time.

So now we're having to quickly try to figure out what to forensically capture and whatever. If you plan ahead for these types of things, and especially in your environment, you really don't have any excuse in your own environment, but for your customer's environment.

So it takes some convincing, but if you have things set up where you are correctly logging things, you do have the mechanism place to capture images and those types of things, it becomes more of an operational task rather than something that you have to make a decision on.

But I would say in today's world, uh, again, with just so much, so much, um, focus being placed on these types of events, it's, it's almost tough to say not, you know, you almost have the litmus test is for those very few times that you may not need to do anything, but the majority of the time you at least need to ask someone the question, uh, do, do we need to capture something or everything.

The other thing I wanna note, and I haven't really talked about this that much on, on on prior type of discussions around this, is when you're dealing with cases that may involve internal, some kind of internal risk, or maybe it's a former employee or an existing employee or whatever the case may be, that's a much different, um, situation than you have with a ransomware or something that, where you have some kind of criminal element somewhere internationally when you're dealing with something like that, um, chain of custody is ridiculously important.

So I would say if there's any cant or indication of some kind of insider being a part of this thing, that's where you really have to be super careful, get attorneys involved and make sure things are done by the letter of the law. Because if they're not, and if you want to go after that person or persons in that thing, most likely they're gonna end up being able to defend themselves just because the evidence wasn't taken care of appropriately. So there's some that, that, that's really good.

And there's some fantastic questions and, and back and forth going on the chat. And I wanna call this out, right? So one question that was asked, and Todd had a really good answer to this, um, let me see if I can scroll over and find this. Actually, first a comment from Mark. Mark, I appreciate your transparency.

He said we had an engineer, uh, from uh, we had to stop an engineer from going into that restoration process and go back to the beginning of what our incident response plan calls for, which is calling your insurance carrier and starting out process, right? I mean, that, that you're not alone in that mark. I I think a lot of us have those struggles, and that's where, uh, tabletop testing is really important.

That's where walkthroughs and refreshers, because often your, your tier one, your amp, your, uh, your analyst guys that are actually handling, you know, most IT issues and tickets that come into the workflow, these are things they need to have some education and awareness around because they just wanna go fix the problem. So, mark, you're not alone. I appreciate that. Um, Chris, could you answer this question from Neil?

He said, I don't expect a general business lawyer to be acceptable during incident responses or a specialty we should be looking for. And of course, Todd's pointing out, um, your insurance carrier should have that, but anything else you'd add to that, Chris? Yeah, so there are, there are lawyers who are considered breach coaches or breach counsel, and that's who you wanna leverage. And one thing is, is that with those types of attorneys, they do not have to be licensed per state.

So typically you're gonna have these larger law firms that have these specialists involved. Yes. Uh, they're the same types of lawyers that are, uh, provided to you as part of your insurance policy. But those are the ones that you need to be aware of from a breach perspective, uh, to help you out. Yes, a general purpose attorney or someone that you just leverage on an everyday basis, uh, is not going to be versed, is not going to be experienced, uh, for this type of stuff.

And, and we have gotten into those situations and it's a, let's just say it's, um, it's a little bit of a challenge when dealing with somebody that's just doesn't do this as a daily part of their job. Chris, I've heard you say on previous calls that you recommend in most cases that people use, uh, the legal representation of the insurance company, they work with them, they're pre-approved, that sometimes you bring in your own third party, it actually creates friction, right?

It can create friction. There's gonna be some delays because the carrier has to negotiate with that law firm on rates and, you know, kind of terms of engagement and all that type of stuff. And so, yes, it is best to leverage one of those terms. The insurance carriers take them very seriously on the work that they do, and so they're well vetted. And so there's really no reason for you to kind of question the carrier's judgment on that and just to go with it.

'cause you're not gonna have any coverage issues or anything of that nature if you go with what the insurance carrier recommends. And you have The same goals at that point. Like you're all, everyone's aligned. Everyone's aligned. And, and, and the other thing that people need to know is, well, hey, the insurance carrier, that means the attorney must be working for them. No, the attorney is just pre uh, pre-approved. Uh, they are engaged directly with you.

So all the legal agreements and everything you do are between you and that law firm. And so that's who they represent, they represent you. Wes, can I jump in a second? Yeah, please. I had a question, and then I think Ruben Tele had telepathy. He was asked, he, he asked the question and his question is, um, best practices around capturing the logging that's needed for forensics.

And, and Chris, the follow up if I could to that question, and certainly above my, you know, all, all of your comments, but the follow up to that question is, Chris, you deal with so many of the RMM breaches. What if the MSP isn't, you know, isn't capturing logs, doesn't have, you know, some third party SOC monitoring? Are there implications? Does the, the, does the defense attorney sit there and go, wait, let me understand this.

You, you're in this business, you know, what, what does that look like? If you could, so part one of the question is, you know, best practices for logging and then part two, what is the ramifications for not having it? Go ahead. Okay, so for the logging perspective, uh, the idea behind logging, and we can probably spend a whole session on this, is to log those critical and security events and that those, that activity that would need to be captured. So we'll just use an RMM as an example.

If you're able to capture the RMM activity that deals with creation of accounts, modification of accounts, uh, creation of scripts of jobs, all those types of things that can be, be captured and logged and retained properly, then you're gonna be in good shape. Um, many times when we get involved in RMM cases, and knock on wood, uh, the, the attackers aren't necessarily going in and deleting the logs there. So a lot of times when we get in there, we are able to capture those RMM logs.

But if you were able to, if you were forwarding those logs to somewhere else where they're being safely stored and secured, then if the attackers do go in and delete your logs, or for some, you know, the RMM gets destroyed or whatever the case may be, those logs are there.

And in, and in the case where you're an MSP and you're the actual victim, and your clients are basically a sub victim, if you wanna call it that, of that, um, the, your logs are the, the most important thing because those logs will tell the story of what the attackers did and what they didn't do. And this comes up every time in an MSP case because not every one of their clients wants to know that, know this.

But the most important clients have this single question, how do we know that the attackers did not get in and access or steal my data? And the only way that the MSP has to, has to prove that, uh, is through that RMM activity, if the RMM was, was the weaponized attack vector used by the attacker. So again, those logs are super important.

Uh, if you wanna look at it from a server perspective, obviously the logging that's in, uh, active directory, those critical things, uh, all, uh, firewall logs, I can't tell you how many times we get on a call and somebody says, no, we didn't really have our firewall forwarding logs, or we didn't have that enabled, or they rolled or whatever. They only, they're only set for to be around for eight hours, and so they rolled. I mean, it's just goofy stuff like that.

So, I mean, it's, there's a lot of good articles on there on what to log, what not to log. It's one of the things that we're starting to dig into now as part of, uh, incident response testing is to look at those types of things. But again, uh, we could spend, you know, we, we, we could have a, you know, and, and Wes could agree, I mean, they're in the logging business. So, um, there's just, there's just a number of things that you have to kind of Office 365 or Microsoft 365, that's another one.

If you're capturing those logs now, you're gonna be in a much better situation if a business email compromise occurs, uh, then rather us come in after the fact and try to dig through that stuff. Yep. Yeah. You wanna have any comments on that? Well, yeah, I, Chris, Chris, is this well said, right?

So Chris and Perch pretty tightly together, uh, when SOLAS brings in an incident, uh, and, and, and Perch is getting involved in it, it's very much SOP for both for and my soc work together, and we usually discover we're working with the leader we have, which is usually little to none. Um, and as Cody points out, you know, questioning logs on a compromised machine is a big deal, right?

And then on top of that is Chris Min, what we have or lack of having, um, you, you kind of walking into this in the dark versus just an organization that does have an incident. You, they have carried out for a long time, we can go immediately back into that and review. And so, um, Chris is Rob, to answer your question there, how long the store, you know, I'll tell you practically, 60 days is really important.

Um, that gives us, you know, if you look at the Verizon data breach, it's typically, you know, the time to discover on average is 30 to 60 days. Um, so having that 30 to 60 is important, but if you're regulated, it's going to be pushed on to you and you're not gonna have a choice on top of it. So, for example, um, with hip, that 67 retention period is, is critical. Um, and then others, of course, financial, we typically see about a year.

Um, and we're seeing where we're still gonna see what comes out with CM C and some others. So if you're regulated, it's gonna be dictated to you. But I'd recommend 60 days of log retention is, is standard and, and a good idea at a minimum.

Um, okay, so in time, in, in, in, uh, uh, interest of time here, these are some things, we're not gonna go into all of these, but, uh, when you're talking about incident response, keep in mind from the preparation and the during the incident side, I love how Microsoft kind of splits both of these out together. So, you know, it's not just a technology dependent solutions. You see technology, operations, legal communications that is bred into all of a mature incident response program.

And we're gonna talk in a little bit, just let me table this for now, but I wanna get you thinking about it. Yes, legal and communications are two very difficult pieces for most MSPs. You don't have onsite legal, I understand that. I mean, I'm sure Mike Ard does at, at, uh, Marco, but we don't all have, uh, Mike's resources, right? So how do we deal with that?

And then also communication planning, uh, among most of us that are, you know, bootstrapped, salt of the earth kind of folks, you know, how do I actually truly communicate in an incident? And Chris, I want you to elaborate on that a little bit more, right? So what we're gonna do, we're gonna kind of scroll past some of this stuff, and I wanna get into a few things that I think are pretty important. So this is what was produced in concert with ERNs and Young.

So keep in mind that the kinds of clients ey targeted in the survey data that you see here skewed towards large enterprise. Um, so keep that in mind as you're going through this, but just some data that I think is important. Uh, when they did this survey a few years ago, they found that most organizations were not very comfortable with what was happening inside of their incident response processes and their capability to respond to an incident.

So if you feel uncomfortable, just know that you're not alone, that that's an issue that I think we all have. Um, and this is becoming something that all of us have in place, and I like what they say here.

And Chris, I want you to elaborate on a little bit of this, um, as well, is one of the things they say right here in this paragraph, and this is something, if you guys know me, you know, I talk about this a lot, this idea of, as security practitioners, we need to push pain back onto our bad guys, onto our adversaries. And here's what I mean by that. Um, a lot of times bad guys love to operate in their zone of control and their level of comfort and confidence.

And so they are very comfortable with like the normal tactics and operations that they're good at, and they don't understand much outside of that. So, as an example, maybe some threat actors really, really good at phishing campaigns, you know, launching emote or whatever the, the, the command and control and exploit kit are to get access into the RMM to then deploy ransomware everywhere.

But the idea for us is defenders is this, what if we can push pain back to a bad guy by decreasing the ability of exploitation, increasing our time to detect and having much faster and more effective response, what does that do to a bad guy? It pushes pain back to them. It makes it more difficult for them. It makes it their job much, much harder. And this is something I think MSPs really need to mature in. Um, Mike Ard, let me start with you first. Does that concept make sense to you as well?

And why do you think that's important for us to be able to push pain back onto bad guys and increase their costs as the attackers? Yeah, it absolutely makes sense. I, I think, um, you know, just the more layers you've got, the harder it is to cut through that onion kind of a thing. And that's, that's the same principle that we're gonna apply here. We wanna, we wanna make it difficult, right?

If, if I've got two organizations that I can target, one of 'em has multifactor turned on, one doesn't, which 1:00 AM I gonna go for? I'm gonna go for the one that doesn't take a whole lot of work to, to go after. Um, so I think it's statistically, it, it's been proven, it makes sense just conceptually. It, it's, you know, who's, who's gonna get picked on, on the playground kind of a thing. Unfortunately, it's always the one that's the least prepared and the most, most vulnerable.

Um, and that's what happens in the real world. Unfortunately, we've seen that, seen that throughout. Uh, Chris, you wanna elaborate on that a little bit more? You're dealing with bad guys every single day. Uh, how important is it for us to be able to push pain back to the, to the bad guys? I mean, it's, it's really important. I mean, I can't tell you how good it feels when we don't have to pay.

Um, you know, when, when someone doesn't have to pay an attacker or that we've, we've made something very difficult with them. I mean, we've been in a lot of cases where, um, we, we, we see all these attempts and you can just kind of calculate in your head how many man hours that these attackers are, are, are spending on trying to get in or trying to encrypt. And, uh, it just doesn't happen.

And so, you know, that kind of makes you feel better when, when, pretty much the rest of the time you're just seeing bloodshed and, and these bad guys making, making money that they don't deserve and making way more money today than they've ever deserved. And so, yeah, the more stuff that you can do to deter them, or the more stuff that you can do to, uh, make their life miserable, uh, is a, is a good thing.

Now, it used to be that so many people had RDP open that that was the attackers, that was the easy way in, and that was, you know, the majority of the things that we saw. Uh, but today, now these attackers are, they're attacking the, the firewall vulnerabilities. And a lot of these vulnerabilities have been around one to two years. Uh, they're attacking exchange vulnerabilities.

So people that still have on-prem exchange, uh, and whenever I get a case that has on-prem exchange, I just start shaking my head because it's gonna be painful no matter what. And so, um, those types of things the attackers are starting to, to go after, and then they automate that. And so you just have to know that these guys aren't just simply typing in commands like you'd see in the movies that they do.

They're leveraging tools and, and, and auto automated functions that some developer out there has created for them to do these types of things. And so, you know, by making sure that you're patching, you're keeping things up to date, you're aware of the vulnerabilities and the configuration issues, and you're addressing them very quickly, you're gonna do everything you can to, to waste man hours on their side and save yourself and your client a lot of grief. Yeah. Yeah.

Chris, you hit on something there too. I think that's important to call out. So in the security world, right, we've seen a lot of things change just in the last 12 months where it's moved into automated response, automated capabilities on the, on our side, going back at the adversaries. And that's, that's important to call out. I think deep integration or the deeper we can integrate products and build that ecosystem out, that's an enabling feature.

It's not always more, sometimes it's just better integration and better capabilities within the existing tools. Things like we've seen with Perch, the deeper integrations into the Microsoft stack and some of the things we've done, um, to really grow and strengthen that tool set, for example, is really changing how we can respond and just how quickly we can respond. Alright, that's good stuff.

So I wanna move on a little bit more, uh, and let's get into a few more things that I think are really good for us to, to really, uh, dive in and talk about. So first of all, uh, you know, the, the NIST Cybersecurity framework is built all through this guide, and you should certainly use that, that ident that identify, protect, detect, respond, and recover. And it really comes down to respond and recover, right? These are the big elements of the cybersecurity framework.

I would say just in general, most MSPs and, and those of you that may be joining the call, they're not an MSP, but maybe a smaller business, you know, that detect, respond, and recover. Those are the, the domains of the cybersecurity framework that we're typically weaker in. It's typically much more difficult for us to do. It's more resource intensive.

Those of you that know Kyle, uh, Hansel from, uh, Huntress, he and I did a talk at V Cyber Con a few months ago talking about demystifying cybersecurity. And one of the things we talked about is you, uh, use, uh, framework, uh, of, of the, what he calls the cyber defense matrix. There's this idea is as we shift into detection, response, recover, these are very people dependent phases of the cybersecurity framework.

And so naturally there are things that we struggle with because as small businesses as MSPs, we don't have those resources. By the way, Andrew, you wanna plug Sunil, isn't Sunil gonna be joining us on the cyber call coming up really soon? Yeah, you had me smiling, Wes, because it was the call I had just before this call.

And let me tell you, if you have not heard Sunil, you speak and him present the Cyber Defense Matrix, you're in for a treat on October 12th, and that's following, we're gonna have Mike Beard and Justin Rainout who was on yesterday about cyber insurance on the fifth.

And Gary, we're really gonna plug into having the conversation, not the conversation you have with your kids, but having the conversation of aligning, you know, ccio CEO e sales conversation around framework, um, and alignment and why it's so critical to, uh, to understand those things. So, sorry for going off on a quick tangent, Wes, but I'm really excited about those two weeks, uh, back to back. Yeah, yeah. As, as am I.

And so I wanted to make sure we plug that, make sure you, uh, stay tuned for that. And maybe, Andrew, if you could, uh, paste into the chat some information about the cyber defense matrix. That'd be good. Just so people Got it. We're Talking about. Alright, so let's shift into preparation. Now. Let's kind of go into, and hopefully my audio's better. I'm just using my mic, uh, on the, the MacBook, so hopefully we're a little better now.

If not, let me know, but into preparation and talk more about how this is a really important piece. And I think we all know that, right? Being prepared. You guys guys know one of my favorite quotes, those of you follow me. As George Washington always said, the best way to be, uh, prepared for to stop a war is to be prepared for it. Uh, wow, what a great quote, right? And so this really carries over into what we're talking about here today.

And so when it comes into all of these things, Chris Laer, some things I want you to talk about for a minute. So when it comes to the technology piece of all this, and this is what we're good at, this is home base for us as MSPs, and so I don't want to spend too much time in this, but a couple things in the general preparation, identifying these high value assets, right? The things that, not just inside of our MSP, but also for our clients, this is really important stuff.

Why do you think we struggle as MSPs with truly identifying those HVAs? Or, or actually maybe I should ask it this way, to you, Chris, in the incidents you work with on MSPs that get hit with something, do you feel like they've actually, um, identified those HVAs for their clients? Or do you think that's a gap? Uh, first of all, I'd say it's definitely a gap.

I think when with MSPs, when we're doing our, whether it's pre-sales assessments or whatever the case, we're so focused on counting, uh, endpoints, servers, hard drive space, number of users and all that type of stuff, we're not asking those, those business questions. And one of those business questions would be, what is the most important thing to you?

Uh, for those of you who have heard me talk about this, a lot of times we get in any situations and the client is down, so many people are so focused on getting their entire environment up. But we can simply ask, Hey, does your client use QuickBooks? Yes. If we got QuickBooks up, what would your client feel? And they'd say, oh my God, hold on. Lemme find out.

And they, they talk to the client and the client's like, Hey, if you can get QuickBooks up, we're gonna be good for another two to three days. And so a lot of times that's the most important piece. And, and, and I would say 99% of the time, the EMSP doesn't know that. Another one is, is we see a lot is where the, uh, the, the actual client has their high, high value assets are not even being managed by the MSP. And so it's a fortunate side.

So like in the medical side with EMR, we see a lot of 'em have hosted EMR. And so that really kind of bails them out per se, because their clients can continue to operate 'cause all they need access to that. And so it kind of changes the things. But a lot of times MSPs don't understand that.

And I think if they really asked the question more often and they had to ask it in a, in a business way, the one of the things that they would identify right off the bat would be, we need to make some changes.

And what I mean specifically is with file servers, uh, you know, I think it's, it's mainly driven by cost, but I think it's something that could be mitigated on the side of the, the, uh, on the MSP is why do we have all of our high value files, low value files, meaningless files, and all that type of stuff in one location?

Because once that one server gets hit, and if it has 5,000 files or 5 million files and 5% of them have some type of confidential data, well now that whole server has to be, uh, treated as such.

And so I think if, if we asked those questions and we did the right things, we would find out that if we could kind of strip those high value assets out and secure them in a, in a stronger way, back them up maybe in a more frequent and stronger way, we'd be in a much better, we'd be much better shape when it came down to, uh, triggering an incident response effort. Chris, This is a great example of how an incident response plan can change behavior, right?

So you're doing your plan, but part of doing that plan for yourself and your customers, it's gonna change the way you actually do technology design where data lives, like you're gonna, you're gonna do things differently that maybe can mitigate a, the, the critical risks, right? Just, just through, uh, you know, technology changes. So as an awesome example of what comes out of more than just being prepared, it, it, it's changing the way you look at things. Exactly.

And it really, I think it, when you have those, 'cause we get, we have to get in those conversations with victims when we're dealing with this, right? And we just know through that conversation because the, the, the insured or whatever we're talking about, they just, they're like, wow, no one's ever talked to me about that. No one's ever asked me those questions in that kind of way. And so, you know, that the MSP never had those kind of conversations.

It was always about technical servers buying new stuff, moving to the cloud, but not in business terms. So if you can have those business conversations, then when you are talking about improving their backups, and when you are talking about re-architecting things, that's going to drive revenue, let's not, let's not dance around that. It's going to drive revenue. It will make more sense to your client when you're putting in terms of the business case.

And then you can tie that in the incident response. It's, it's, it's a great conversation. Chris, can I, can I just say something? 'cause it's, I think it's really relevant. Yesterday on the cyber call, we did a poll. We had, again, you know, a cyber insurance expert. And one of the poll questions was, number one, do you ask your clients if they have cyber insurance? Getting back to the operational type questions, do you have cyber insurance?

The second question was number two, do you know if all of your clients, you know, have you asked all your clients, do you know it was in the 90 percentile and we had a pretty, we had over 200 MSPs on this call and MSPs 90 percentile, the answer was no to both. So, you know, that conversation, Gary, that people aren't, you know, getting alignment in some of the most critical pieces. Like, you know, it's always like, what happens after, what happens next if we were breached? God forbid, right?

What's it gonna look like, you know, within the business? Yeah. And, and Andrew, listen, that's why we're here today to to, to go over the, the idea of this plan. But listen, I got asked on an interview recently, do you think that all MSPs are gonna have to have a ciso? And I'm like a ciso. How about just find out if their customers have insurance and what data's important to them? Can we start with that?

Right Before we, before we get to, you know, every SP having a ciso, so you're seeing here, there's a lot of low hanging fruit, Andrew. Well, and again, I I'm not saying that to beat people up here, everybody works really hard and it, it's, it is a tough business, I'm simply saying.

And as Justin said, look, if we can start to move, you know, part of our customer base into an alignment around a framework, you know, versus 90% not being aligned and what that looks like, you know, when the defense attorney starts asking you, Chris, I mean, it's a big difference, isn't it, that people, you know, he use the brain, you know, a a a surgeon analogy. Did you cut the same way and have the same protocol for every customer? Big difference in a defense situation. Is that fair, Chris?

Yeah, it's definitely fair to, to be able to demonstrate that you used, you know, some type of standard approach that you just weren't, you know, shooting from the hip. And the other thing is, is that you can provide the evidence to support that. So that evidence may be as simple as whatever you've documented in the tickets, but that evidence could also be in the forms of logs and reports that are produced as well. I mean, backups is a great example, right?

I mean, if you're sitting in front of a, a defense attorney and, and you're trying to defend yourself from some backups going awry, and then he or she asks you, well, how many clients do you have? Well, I have a hundred of them. Well, do you back them up all the same way? And then you have to kind of go in and explain yourself there. It gets a pretty nasty, and so you're right. You gotta, you gotta have a standard approach.

I mean, when I worked at, in a previous job, one of the things that we had to do is we had a very, very tight retention schedule on everything, especially on email because, uh, there, you know, people say dumb things in email. And that was kind of the lesson. We said, look, we're not going to use email as a retention mechanism, as a, as a record keeping mechanism. And so we had a 30 day email retention, and after 30 days those emails were gone. They were permanently deleted.

And I used to get called on this a lot. I used to get deposed or whatever, and the attorneys just didn't believe me that it was, no one ever does that, people that say they do that, they don't actually execute on it. And I was able to prove it. And not only was I able to prove it, but I was able to show them year after year after year, going back 10 years of our policy, of our retention policy, stating specifically that.

And then I was able to prove in the configuration and the looks on their faces when you're able to prove that to 'em is almost priceless. And so, yeah, you have to be prepared for that. I mean, especially in today's world. I know people have seen the word cringe come up a lot on the chat, but I'm, I'm saying it, it really sucks. It's, it's one of those things where, God, I gotta keep all this stuff and be ready to defend myself. You hope you never have to defend yourself.

But that one time that you do have to defend yourself, let me tell you, it's probably gonna be the most important, one of the most important events in your business life. Yep. So this is awesome. We're, we're about 40 minutes in, so I think, you know, Wes, if we wanna kind of get through the rest of this rest of this Microsoft piece, 'cause I wanna make sure we have time to spend with Mike 'cause that's gonna be awesome as well. Yep. You got it.

So let me tour through a couple things very quickly. I'm gonna kind of speed test, uh, through. One is, you know, first of all this confirming reliable software deployment. This is, like I said, that's your bread and butter, that's your RMMI found MSPs are far better at this than anything else, but this word confirm. Don't take that for granted. I can't tell you how important it is to actually test your deployments, your recovery, all of this kinda stuff.

If you're not doing that and you're like, oh, I did that a year ago, everything should be good. Uh, think about how many changes and new things happen in place that cause impending disaster. I'll give you a super quick example of that. When I took over at the bank that I came from, uh, you know, one of the things I dove right into at the very beginning was, Hey, let's talk about backup strategies, how this is all working. They're like, oh, we're good. We got a year back.

Um, and I asked him how was all working? He explained everything. I said, can I just see, can we, can I, can I see? I'm like, no, no, no, we're good. Let's don't bother yourself with that. You know, you're CIO don't worry. I'm like, no, no, no, I really would like to see it guys. So they show it to me. And long story short, to distill everything into just a few seconds of a, of a long story, uh, they had added our document imaging system into the backup recovery, which is a good idea.

But the retention policies were completely screwed up on the backup, uh, uh, the, the, uh, image retention server. And so, uh, that ate up all of the backup space we had. And so instead of having a year, we had two weeks. No one had checked it, no one had looked, no one had actually dove in to actually look and, and, and analyze what was happening. I mean, total scary moment. We dodged some serious bullets there. Um, these are the things that don't take these things for granted.

This confirm is really important. This is why we test backup and recovery strategies, all of these kinds of things. So I'm gonna scroll through all of this. Um, preparations things you should be doing. This is stuff right here that, for example, perch is really good at threat detection monitoring. We're gonna skip by some of these things. Um, you know, the forensic capabilities and we could spend so much time talking about all of these kinds of things.

What I wanna get back to though is some of the things in place that I think are really important for us in identification of high value assets and how we know what they are, how we track them, and how we prioritize all these things, especially in the recovery world. So I've got a question that I want you guys to answer in the chat. I'm gonna a two part question. Gimme a yes or a no. Does your organization utilize a business impact analysis? Yes or no?

Uh, if, if you don't even know what I said, then your answer's a no. Uh, do you have a business impact analysis? While we're waiting on that, Mike Ard, I want you to come. Can you talk, uh, a little bit more about why a business impact analysis is important? Yeah. Prioritization, if I have to sum it up in one word, it really is prioritization. It's understanding. Um, it, first off, it's a key part of preparation.

It's really understanding what the impacts of the organization are gonna be, um, from a, from a variety of different types of instance. So first off, I'm gonna do a, I'm gonna run a BIA against different scenarios. A pandemic versus civil unrest versus a cyber event. They're gonna potentially be different impacts to the organization, right? In some cases my people may be available and others they're not. Um, but really it's gonna drive business resumption.

Um, so business continuity planning, it's a critical element of that. Um, and it determines what elements I need to pull in, right? So what it, obviously, if it's a cyber event, I'm gonna run through, um, different things there such as detection, analysis, containment, eradication, et cetera, the things on the screen. Um, but it really ensures that I'm able to do so in a way that resumes business. Um, that really is gonna be the thing.

So it it, I like to talk about what are the top three to five threats to the business. That's really what A BIH should be identifying. Um, it should be driving us towards resolution. A business impact analysis should be identifying those weak links. Like I don't have redundancy or correct resiliency in a tool. Um, it, it's gonna pick those things out. And if we're doing a BIA correctly, it's gonna help with that.

The, the second piece that it does are really kind of the last piece it does is prioritization. It's gonna help me prioritize those assets, just like we've talked about when I get into recovery mode, um, which ones are the most important and it's gonna help me with resuming business from a prioritization standpoint. So next question out of this is, and I'm gonna show you an example of a business impact analysis. 'cause I didn't want to tie, I knew we get a lot of nos.

I'd say we're about 80%, 85% my eyeball test, uh, knows. So that's good that we're talking about this. Those of you that said yes, would you tell me whether it's helpful or not helpful for your organization? Just type in helpful or not helpful because I want everyone to see those that are doing it, uh, what the, the outcome of a business impact analysis is because it's easy for us to kind of interpret it as ah, just a bunch of busy work that I don't get much out of it.

Uh, so I wanna see the helpfuls and not helpfuls come across. And then what I'm gonna do, I'm gonna share with you guys a very simple, uh, business impact analysis right out of Excel. It's nothing fancy. Uh, we can send you a shell of this. This is not, you know, perches or cyber calls or Andrew Morgan's, you know, official blessed, uh, incident or uh, BIA. But I wanna, I wanna talk about it a little bit and why it's useful. So yeah, we're getting all helpfuls coming back, right?

I'm kind of qing you guys on. Um, but Chris Laer and Mike regard, I want you guys to talk about this a little bit. This is an example, a very high level, simplistic example that you could certainly make much better than this, but good for us to kind of see what a BIA might look like. So an internal org building A BIA might make theirs like, you know, multiple divisions inside of their organization.

Whereas you as an MSP, you could certainly kind of take this idea of building a BIA for all of your clients. And so like, let's say here's a small client of mine, Bob's taxes and more out of Tampa, you know, and I just wanna identify from him what are the big critical things if some big thing happens, right? A big hurricane, a cyber incident, something like that happens. What are the key things for him that they do on an operational day-to-day basis that are really important?

And how do I know to prioritize that? So I've just fired in one of these that's in here, but could you guys, Mike Ard, I'm gonna let you start again. Can you guys kind of talk about, uh, some of the elements that exist in here and why they're important and, and kind of, uh, bring to light some, some info from all of this. Yeah, I mean, really you're answering the five W's and H, right? We've got, first we start with the who, um, who is it, what, what? Then we move into the what, right?

So what, what do they provide? What services do they do? And what if you're, you know, if you're going down an SMB list, this is gonna be the types of services that they do. Manufacturing, tax prep, financial services, et cetera. If it's a larger organization, that's gonna be business units. Um, so it could be different functional areas within an organization. We're gonna jump over to the RT o RPOs, right? So this is where we start getting into the, um, the, when, when do things need to occur?

So if I build out a, if I'm an MS P and I build out my client list here, this is gonna help me prioritize. So going back to that priority of maybe who I need to prioritize higher in the list or lower in the list based on critical services and some of the time commitments that we've got, critical times of year. I think that's a really important element to include. Um, obviously for a finance organization, um, tax seasons typically pretty important.

So April, June, those timeframes are key times of year. Likewise, if it's a larger organization, finance in that organization is probably gonna be the thing there with a similar time on there as well. Staff. That's when we start getting into the who's component again. And, and the thing I like about the staff component, this really is a critical element. First off, identifying key people, um, or that critical staff is called here. Key resources really are important here.

You've gotta know if a process is gonna break down, if one or two people are gone, you have to call that out. 'cause that's a, that's a weak link in redundancy as well, when it's only Sally knows how to do a certain process. Um, the other thing is, this is accountability, right? So it assigns that accountability from a restoration perspective. So you know that when you go through, these are the folks that have to be engaged and who's accountable to ensure those services are, are back online.

Um, in this case, computer required or, or technical requirements maybe would be a better way to put it. Um, what is a technical requirement? Some cases that may be internet only, right? As long as we've got internet, we can get to QuickBooks from a mobile device such as an iPad or an iPhone. Um, in some cases that's, Hey, we need a corporate issued device, and what are the requirements that really are required there, um, to bring that end user back online. Uh, location dependencies.

Obviously, in a tax prep organization, we probably have paper files yet, um, still, you know, still in place. So identifying if there's a location dependency, that's gonna be pretty important too. Manufacturing, healthcare, there's typically location dependencies there as well, but again, it's identifying what are core key elements to business resumption, um, from that, um, cloud or on-prem is one that we've also seen pop up a lot now too.

And, and that really can help identify, and Chris touched on this earlier, right? In the example of an EMR solution, if it's a hosted EMR solution or a cloud-based system, that can really change how I do, uh, how I restore organizations, right? So my R-T-O-R-P-O, in some cases, it's gonna be outsourced. So understanding how that SLA is committed in a contract is very important.

If, uh, the business puts down that they want to be back up in an hour, but their contract says they've got 24 hours for, for that service to be restored, it's probably not happening in an hour, right? So understanding that level of commitment is very important as well as, again, just understanding where that data is from a prioritization standpoint. Um, and then critical applications.

I think that one's pretty self-explanatory, but identifying those core apps to the business, this is where conversation really is critical. 'cause a lot of organizations will start to all of a sudden miss everything. You're like, no, no, no, no. If your business goes down today, what do you absolutely have to process to process payments to continue to operate, right? And use the MSP for example. Probably there are an end tool in your AP system, AR system, right?

Um, QuickBooks and a, an automate or whatever that case may be. Other services can trickle up after that. So that's having a real conversation around the organization in terms of precedence and priority. And then of course, impact level is, I think, pretty self-explanatory as well. And sometimes I've seen impact level. Um, there's typically some metrics that will help determine that.

Uh, there's, there's a lot of ways that can go, but that can be a calculation or in some cases it's a little bit of a really good guesstimation. Um, I hate to say that, but that, that is what it is too. When you, when a larger organization, what's the impact level to the business for, for a business unit such as finance, it depends on the company. Um, so we may have to, you know, business executives may have some input on that as well. So, um, this is really good.

And, and you guys may be looking at this and thinking, well, this is really simplistic and probably wouldn't be that useful to me, right? But Chris, I want you to elaborate on this a little bit more. Let's say on MSP, and I've got 60 clients, and I've got this listed out, maybe Bob's taxes and more has three different things on it. And my healthcare, uh, uh, clinic has, you know, five different things on this, right?

And, and I've got a, a list of maybe 30, 40, 50 of these, maybe more, that are all listed out here for my clients. And I have a systemic, you know, what perch calls a buffalo jump where, uh, you know, my, my entire arm m is hit and everything is down ransomware everywhere. How helpful is a BIA in recovery of a systemic cyber or physical incident? I mean, it's incredibly important.

I think one of the things too, to mention on there is whether it's three things, five things or 20 things on a list, you have to understand the dependencies of those things too. When I worked at the bank, uh, our a CH department, when we talked to our a CH, the head of a CH, we said, Hey, I, she goes, I need to be up in an hour. And we said, well, that's great. I said, we don't, you need the core banking system in, in order to operate. She's like, like, yes.

Well, that core banking system's not gonna be up in 12 hours. So if you're up in an hour, what can you do? Absolutely nothing. Exactly. So knowing the pieces that need to be put in place first, second, and third from a priority perspective, and knowing what pieces need to be placed from a dependency perspective is super key, because you can, you're you, or I mean, your, you on your side of systems and your client on, on, on the side of their systems could spend more money than necessary.

If a system comes up and great, but it's the, it's other dependencies don't come up, you know, uh, you know, the easiest one to say is the internet, right? I mean, if their systems require the internet and it's not up big, wooy doo da, that thing comes up. So I think that's super important, but having this BIA is that roadmap, uh, you know, that, that you're gonna work off of, and it's going, it should drive your instant response plan. And it should also be that kind of checklist.

So you're going through, you say, okay, what are we working on now? Okay, is that done? Has that been verified that that's working? Yes, check. Now we go to the next thing and the next thing and the next thing. And so this thing is super, super important. And it's super important to have that this thing, um, basically accepted by the business and, you know, updated by the business. You have to ask that question on occasion. Hey, is this still the most important thing?

Is are, is this list still current? And it's not that it, it doesn't take that long. It's not very complex to come up with these answers and be able to refresh and update a BIA once it's in place. You know, Chris, one, one thing that I find general, working with MSPs, many of them technical background in every aspect of business, they complicate things. So, you know, I like to say here in chat, they like to shoot an ant with an elephant gun.

And when it comes to the kind of items we're talking about here, simplicity is powerful. Having something that hits 80% of what you need has the right thought process and actually is usable because of it, right? Compared to something that's got 20 different tabs on it that, uh, is so complex that it's, it's built not to be, uh, followed. That's exactly right. One thing if you do have a larger client, right? And you do have to use tabs, roll it up into a major tab, right?

So if you, you, you have to have some inputs, fantastic. If it's easier to organiz and for, to assign people and that type of thing, fantastic. But roll that up to some summary tab that is simplified and basically people can kind of look at it. I mean, when we were at the bank, that's exactly what we did. And we had a number of people that, let's just call them observers.

They had fancy titles within the bank, but when it came down to disaster recovery or incident response, they really didn't have an active role, but they definitely wanted to follow along. So having that summary sheet allowed them to follow along, which gave us the ability to do our work and not have to be distracted by a bunch of questions that we didn't have time to answer. Alright, good. So in interest of Time, uh, really good stuff. This, I am happy to make that I'll hit the save button.

I literally just kind of popped that BIA, um, together for you, but happy to share that with you. And definitely look online. There's a lot of BS that are out there as templates. Some are extremely complex and overkill. Some are like that one pretty bare bones and stripped down. Uh, but, uh, happy to share that out for everybody that would like a copy of it.

Okay, so I'm gonna cover two last things and we're gonna turn it over to Mike, who's gonna walk us through, um, a a really good example of an incident response program itself. So you can kind of talk, we go from the planning to the actual, the, the, an actual example of it. Um, one thing I wanna talk about just very quickly is, you know, how do we build the teams for all of this?

You know, this is an issue that we really have to think through because we usually are resource strapped as MSPs and how does this work? And so when you look at our enterprise approach, this, you know, they're talking about, you know, using like the, the incident command system for crisis management. You can Google this if you wanna see more about what they're talking about. Really good information online.

But basically just the way of making sure you have a group of people that are specialized, trained in understanding of how to handle all of this. And it might come across in some areas you haven't fought through before. The logistics, financial, legal, these are things that are really important in handling all of this, because a cyber incident is not purely just a technical incident, right? It's not just purely only technical. There's a lot of other things that wrap into this.

And so I'm gonna kind of scroll down past some of this stuff, um, that, uh, talk about some of these things. And I wanna get into what I really want to hone in on here is the, the first thing is communications. And Chris, I can think of no better person than you to talk about the communications pieces of an incident, right? Right. So the last thing that we want is some, you know, IT guy to handle communicating in the middle of an incident, right?

Uh, Matt Lee, who's been really insightful in the chats here, talked about how they use cue cards and they have certain things they say and don't say. Can you talk more about best practices around communication to make sure that we don't say something we shouldn't, that we say, you know, that we protect the organization and the incident as it's occurring. Can you talk more about that? Sure, definitely. So the first rule, uh, rule of thumb is only those who need to know should know.

So it's a need to know basis, right? Uh, so many times we get involved where there's already been messaging sent out to the entire employee population, or, you know, in the case of an email compromise, they just start, you know, email marketing about things that they're really not fully aware of what happened. So you need to keep it very tight. Uh, if you do have to communicate, you know, outside, you're gonna use, you're gonna use certain statements such as an IT event or have an IT issue.

You're not gonna use terms such as incident breach, compromise hack, anything of that nature because, uh, you breach is really overused. And there are, there's specific legal definition around breach. And most of the time until you do the forensics, you don't really know that a breach did occur until what extent it occurred. So you wanna do that in the interim at the very beginning.

Uh, but once an event, and, and just like Wes is talking about, if it's a major event, a buffalo jump, you're gonna wanna have attorneys and crisis communication people involved as soon as possible because that messaging to your clients is gonna be key. 'cause you're gonna have people knocking on your door, calling your cell phone, calling your employee's cell phone and everything like that. So you want to get as much control around that as possible.

The other thing is you wanted to define the frequency. So one of the mistakes that we see a lot, especially in a case where, uh, let's just say a, a client is compromised and the MSP is there, is that the MSP does a great job of communicating with them for the first two days. And, you know, the client's getting all this updates and everything, maybe every hour, every couple of hours, and then very, very quickly that communication drops to almost nothing. And that's, uh, a really bad situation.

And so you wanna make sure that you, this communications, like we talked about, is super, super important. I like the idea of cue cards. Uh, you really need to have somebody that is assigned to this role, that has a very good head on his or her shoulders, and can, can, can, is patient, and can kind of contain and follow instructions and, and make sure that things are done right.

If you have somebody on there that's not so, uh, that's easily going to blurt things out or have diarrhea of the mouth as we like to call it, uh, that's usually not gonna end well for you, uh, in these types of situations. I, Right on. Good stuff. Really, really good stuff. So appreciate the insight there. Um, last thing before I turn, uh, the controls over.

I feel like we can kind of leave you guys at a stage where we really talked about the content and guts of an incident response plan and how to build one is legal, right? So we've talked about legal all throughout this. I don't know if you guys have followed the Uber breach that happened a while back and the indictment that had, that came through for the former Uber ciso, that was something I paid a lot of attention to.

And there's some interesting things inside of that where the Uber CISO and the CEO both said, Hey, we were following legal's advice. And yet, uh, an indictment still came through because of lack of notification around the breach. Really, really interesting stuff. And I think legal is gonna continue to evolve, uh, in, in how breach response, breach notification, all of that kind of comes in place. And I'm telling you as MSPs, it's important for us to consider this as well, right?

We're not going to also fly under the radar. The more MSP breaches that happen, the more, uh, we are seeing state and federal regulations come around, notification laws. This is stuff we've really gotta plan for. We need to have legal involved in all of this. And so my final question for, for you, Chris, is as I kind of hold, uh, the mouse over the, the, the, the legal pieces of this, what's an MSP to do?

I mean, they don't have in-house legal, so how do they get through all of this, both in the preparing and during the incident side? Is this all through cyber insurance? What are the things they need to know around legal Chris? Right. So from a legal perspective, we touched on it earlier that you wanna have somebody that's involved from a legal perspective, uh, if you're in the event now, before the event occurs, before the event occurs.

Uh, it is, what I always have said, especially with your agreements and stuff, is yes, you have an attorney that puts together your agreements, but you should also have another attorney. That's what I typically would call a litigation attorney. Uh, basically try to tear holes in those agreements. Uh, that will really help you out to say, okay, look, I got these great agreements, but how will they hold up in this particular case?

You have a litigation attorney, review it from that perspective, you're gonna be, you're gonna be in much better shape and you're gonna be much better prepared going forward. I know yesterday on the cyber call, there was a question around hold harmless agreements and how much teeth that they hold, how much weight do they have in these particular situations? And that really is a perfect question for no one that was on that call. That's a great question for an attorney in that particular case.

They can look at your agreement, they can look at the hold harmless and see if there's any kind of conflicts there, or does one support the other or whatever the case may be. And just like on this thing right here, I mean, the other thing I think that for the majority of us MSPs, uh, we don't really have a board of directors.

And if you can try to put your mindset in a board of director, uh, setting, you would understand that a lot of these things that we're talking about would be typically, uh, presented to a a board and approved by a board. And a lot of times on board of directors, there is an attorney sitting in there, uh, for a number of different reasons, attorney client privilege and all sorts of other reasons. But for review of this type of stuff.

So if you keep those types of things in context, that these things are that important, that paramount, uh, same thing with your policies, uh, and all that kind of good stuff. You have some type of legal review, you're, you're gonna do it. I mean, uh, I think Mike can talk to, I mean, they're a very large MSP and a lot of things they do, they do with lawyers involved because it is a, it is a great and fantastic business practice.

And if you can find an attorney that's gonna be reasonable and and gonna be able to do this, and you can manage that correctly, you're gonna be in as good a shape being prepared for an incident as you are with an incident response plan. And the last thing I will tell you is we are starting to get a lot of attorneys reach out to us to say, Hey, look, we are gonna go do a table, an incident response tabletop exercise with a client of ours. We're gonna do the legal side of it.

Can you guys come in and help us with the technical side of it? And that's a two day exercise. That's a day spin on the legal side of it. And that's a day spin on the technical side of it. So you can kind of see where this is moving. And so you can just be, it's just, I know it, they're expensive, but it's just becoming more of a part of our everyday world. Okay. Right on.

So that kind of concludes, um, Wes taking you under his wing and walking you through what I think is a really good preparation guide. There's a lot more to the guide than just that. Uh, but that is some really good stuff that I wanted you to know as you're thinking about building, maturing, enhancing that plan. So, Gary Peak, as I turn it over to you to kind of talk and, and share and work with, uh, Mike regard on the actual plan. I hope that's been helpful for everybody.

I hope you've had some good takeaways that have been useful. Uh, so back to you guys. Yeah. And, and I think listen, um, for the majority of people that don't have a really well developed plan, like that's an awesome building block, Wes right to start with.

And then Mike, now we can go to you and talk about like, in real life then here's the preparation, what, you know, what happens between that and rubber meeting the road, which is, you know, having a, a document for a company like yours, right? That I'd say is mature and security as, as, as most or any other. So this just should be awesome. Yeah. Very good. Let me get, uh, screen share going here. All right, we'll share this out.

So, um, yeah, so I'm gonna walk through, so this, this is the, the 1.0 version of our re redesigned incident response plan. This is about a year old, so we are not on 1.1 anymore, but, uh, which is important, I think going through this, we're gonna definitely call some things out that we've identified that needed to be changed as we go through it. And I'm gonna ask Chris and Gary and West to jump in and, and help as well. Um, but first and foremost, I think it's good.

Let's go through the table of contents, right? 'cause this is really where the meat is. Um, and one of the things that I, I agreed to do is I will share out the first, I think I'm gonna share the first four pages of this. Um, Gary will share it through the portal on, on true methods. And we wanna make this available. 'cause the table of contents I think will get you going in the right direction. And then, uh, you'll see the pages three and four are just really kind of the purpose.

What's the intent? What are the core steps of an incident response plan as we run through. So if we jump through, um, first off, we've got introduction, scope, definitions. Those are gonna be core elements typically of any policy. Um, introduction on this. We actually started, um, as well with the do no harm statement. I think that really is a key component of incident response. Um, and really it's outlining what the function of the incident response plan is.

Who are the elements, who does it serve, et cetera. Which in our case, we use this plan internally. And we've also now adopted, um, most of the elements of this for our client facing, um, customers as well. So we do use this in both sides of the fence, or both sides of the house, as I typically call it. Um, plan summary. We've aligned to the NIST standards. So we're gonna go through, it's aligned to NIST 861 R two, um, pretty straightforward there.

So we've got the standard NIST elements, all five phases, um, that are called out there. We went through that in the Microsoft example, so I'm not gonna spend a lot of time on that. But then if we dive into framework, this is where we start getting pretty darn detailed as we jump through. So one area that I can tell you right now that we have added some sections is in the preparation phase. So in the 1.

0 version, last year we called out preparation and we had assignments for who's responsible for things. Um, we, we had the who's, we didn't have a what they're supposed to do, right? Not necessarily in enough detail. We had the high level organizational, here's what an incident response team's supposed to do for preparation, but we didn't have, this is what the incident response commander is supposed to do. This is what the technical lead, which in our cases our CTO is supposed to do.

This is what our CFO et cetera is, what their different responsibilities are. And, and this is one that has really evolved. Um, first off, if you align to any of the frameworks, if you serve CMMC customers or CJS, et cetera, you, you need those elements. So we wanted to make sure that we added those in, um, to meet those requirements as well as it provided some detail that when we table topped this, we didn't necessarily have that, right? It got to the, who's doing communication, for example.

And, and we had it in our plan. Um, you'll see that later on, that we actually had communications called out, but everybody in the room kind of looked at each other, went, well, I don't, I don't know who's doing that. And everybody looks at me, right? I'm, I'm not the one doing it. It's our communication director that's doing that. So, um, we, the who's and the, what their responsibilities are, I think is one area that if you're gonna take notes, I would make sure that you do call that out.

Um, detection analysis. We, we really dive in. This is, to some degree, this ties into what we just talked about. This is gonna be definitions to a degree. How do we define things? How do we triage things? Um, what are some of the things that we do, right? So when I'm looking at, um, indicators of a compromise, that's gonna be some definitions that's gonna be indicators of a compromise. Um, some technical components to it as well. Incident scope.

Um, we've aligned this to a number of industry standards. And, and again, it aligns to Nest eight a hundred sixty one, but we've included some things in there based on the client sectors that we serve, right? So if I'm a, if I focus on hipaa, I might have things more in there. What is HIPAA's definitions or, or certain things like that. 'cause the last thing you wanna do when you get it in into an incident is have to go look all this stuff up, right?

If you, if if we've looked it up once to answer a question, when we're going through an incident with a client, we typically pull that as part of lessons learned and then we'll incorporate it into the plan, um, going forward as a resource. It may not necessarily end up in the top, but it's for sure an appendix, as you'll see a little further down the page. We've got quite a bit of stuff for certain, um, organization types, right? If they're PCI aligned or, or HIPAA aligned.

Um, so One, one of the things that I was gonna say is if you look at this, you know, most people, like, they'll think just about there's an issue remediation, but most of this is not remediation. Like this is all the other stuff that's really, really critical in a response. Yeah, that's exactly right. Um, that, that's exactly right. And that's the, um, re remediation's probably the easiest part, right? We're, we're all technologists as providers, right? We're really good at those functions.

We're not really good at these other things. And if you don't have this, the remediation can actually be the result, right? It can break everything else. It can make things, as you Chris has always mentioned, it can make, if you don't have this piece of it, the remediation can make things worse, not better. That's exactly right. Um, all of this is in lead up, but I think Chris has done a good job of, of lining up to, um, a number of the reasons why we need to do this.

Uh, it's, it's paramount, um, you know, going through what's the impact of an incident. Like, all, all of this ties into we have to understand these things before we jump in to figuring out what happened. Whether it's going into con, you know, containment. We need to know what we're gonna try to contain. Um, you know, we need to know what we're gonna investigate. And I'll be upfront that we're ones that we will, um, I do have a security team.

I will investigate certain things, but there are certain things I'm not gonna investigate. And that's actually called out my plan. In some cases, we will outsource either partial outsource, we'll work on it along with a third party. Um, or in other cases, depending on the severity, we're gonna outsource it a hundred percent. I think plans need to be aware of that.

One other thing I wanna mention, you know, your organization, you mentioned you have somebody in communications, you have a lot of roles that the average MSP doesn't have. So they need to have all those same functions though, Mike, right? No matter what size they are. So they're gonna have to take people and decide within their organization how they're gonna overlay those functions and responsibilities.

'cause they're just as important to a, you know, a six man MSP as they are to, to someone who's scaled to where Marco is. That that's exactly right. In some places people might wear multiple hats, right? For a smaller organization that doesn't have a cso, the CIO or CTO is gonna be wearing the, the technical responsibility, they're probably wearing the security responsibility hat. Your HR director might be your communication director when we get into an incident as well. Yeah.

Yeah, that's exactly right. Um, yeah, just moving down the different elements. I don't, I don't think I need to read this for everybody, but, uh, you know, as we jump into containment, to Gary's point, that's a, there, there's two sub points in that, right? It's pretty straightforward. We know those parts pretty well.

We reference other areas, other procedures, other documents, um, and that's really where we're gonna put the meat of, of how we do things depending on the, the type of incident that we jump into. Then I would say the most important piece, and I just, coming from the financial world, this was probably stressed the most, and I think it is relevant here as well, that post instant review, right? Getting into lessons learned, that really is critical.

And I, I think that one, it should be spelled out in your plan, um, what you're gonna do, how soon you're gonna do that. Um, 'cause there is a time component to that. And, and I think, you know, we don't wanna wait too long. We also don't wanna jump to conclusions. 'cause if certain things pop up, we could have facts that come up a week later. We want to be able to incorporate that. Um, and then task, again, task assignment. Who's gonna be responsible for certain elements of lessons learned?

Um, you know, if it's incorporating things, changing, changing the plan, that's probably me. If it's, hey, our communication plan wasn't very great on this incident, we need to update that. And that may not necessarily be relevant to that. So task assignment absolutely critical, um, as we go through it. So I'm gonna pause there, I guess, uh, Chris or Gary, anything else to add? Yeah, I think what you just touched upon, like the post-mortem on instance is really important, right?

It's a great, it's a great time to, uh, reflect back on the plan and make any changes. The other thing I wanted to talk about is just kind of the life of the plan. I think we've mentioned that this is a living document and is dynamic. And one of the things I learned being when I worked for a publicly held company was the concept with Sarbanes Oxley was around controls.

And those controls had to be updated anytime there was a material event that happened in the company, whether or not that was a infrastructure change or an architectural change, or an acquisition, or whatever the case may be. And I think the same goes for the incident response plan. So it's one of those things like if you end up, uh, bringing on a new client that, um, that may change the way that you do incident response in some shape or form. And so you should at least review the plan.

And then in the version tracking section here, you don't necessarily need to show that it changed, but you need to show that it reviewed. And so at that point, yeah, go ahead, Gary. No, no, I was gonna say, and Chris, something that you, you know, also changing with you, you alluded to this recently. You know, the, the, it has to change the evolution.

Like, you know, people that you mentioned they were getting hit with, you know, RDP and then, you know, you have all these, uh, you know, uh, uh, different types of breaches, then data exfiltration. Now, just recently you were talking about, you know, new attacks around, uh, you know, operational, uh, you know, kind of operational attacks and admin rights.

So, you know, not only do your, do things change internally, but as things are changing so quickly, you know, in the landscape, this also has to be addressed, right? Mm-Hmm. So you have to have a process for, for, for, for that review other than an incident. Yeah, exactly.

And one of the things you gotta think about too is we, we always talk about laws and regulations, but the other thing is, is there's a lot of people, and your clients are in there, I mentioned this earlier in the chat, that may have contractual requirements around notification of, of an event to one of their suppliers or partners or their customers, or whatever the case may be. And you may have that too. So you need to be cognizant of those things as well.

So those need to be, 'cause you may have some, you may have a timer that starts, uh, that's completely different. Any kind of regulatory or legal timer because of some kind of con contractual responsibility. So that's another thing that you have to take into an account, uh, when putting these things together and updating them and all that fun stuff. All right, Mike, keep going. This is awesome. That's right. So, um, yeah, so version tracking, we, we do cover that.

And I, again, this is the, the 1.0 version, but, uh, and it's been sanitized a little bit too. We're on, we're on one point 10. And again, this is roughly, we started on this journey about 15 months ago, right? So that shows that that lessons learned component, it does drive changes, um, as we jump through, um, different appendix. So this is things that we've learned through time based on customers that we serve, um, and the segments that we're in.

But, you know, hipaa, we, we do have some HIPAA information here and, and we can jump down to these different things. PCII talked about that. Two other elements that are really becoming, I think, pretty popular is, um, notification or interaction with law enforcement. You do need to think about that, right? If you're gonna interact with law enforcement, which some of these you may, um, how are you gonna do that? Who's gonna do that? Um, is somebody in the organization gonna do that?

Is it gonna fall under attorney-client privilege? An example I'd give there is, um, some breach counsel is, is typically pretty adverse to filing IC threes. Others are all for it. Um, that is an interaction with law enforcement in and of itself, right? So there, there's other things that come into play there. And, um, Chris, I might have you touch on this one 'cause I'm sure you deal with law enforcement quite frequently. Yeah. So law enforcement's an interesting thing.

I mean, at the, at the bank I worked with, we just had a general rule. No one tossed to law enforcement except for X, Y, and Z people. And that, and that, that moved over to the incident response plan either. So everybody was very clear on that, no matter what the issue was. If it was a, a robbery at a branch or it was an internal employee issue, or whatever the case may be, it was very clear that you didn't talk to law enforcement unless you were one of this small group of people.

So that kind of makes things easier. And I think in the MSP world, that should apply. Now what happens with law enforcement and when is it appropriate? So typically, uh, local law enforcement is not gonna do much good. Um, you may make the example of something like New York City, uh, where, uh, local law enforcement does have a, a, a material cyber type investigation unit.

But for the most part, you know, reaching out to law, local law enforcement, or if local law enforcement calls you, uh, there's probably nothing just to jump right on top of it and give them any information. But that's, again, something that you're gonna lean on your legal team to tell you when, and, and probably even just to facilitate that communication as well and be a liaison between that.

Uh, when it comes to more like the FBI or someone of that nature, we do a lot with, uh, Canadian Provincial type, um, law enforcement when dealing with cases up there, typically they're not involved at the beginning. Uh, they usually get brought in, you know, after the incident has occurred, usually a lot of times after the forensics has even been done.

And so there is, and, and most of the time the information that they're asking for is not really something that would be increasingly crucial to your client, meaning that it's gonna be IP address information, it's gonna be information around the indicators of compromise. It's not gonna be, they're not asking questions about why the backups failed or anything of that nature.

And so, again, uh, in, in most cases, uh, that information is, is shared, but the attorney basically gives the advice, gets the approval before any of that takes place. I mean, but I think from a philosophical perspective, uh, you should say that you're gonna cooperate law enforcement, but you're gonna have those guardrails around how you're gonna cooperate with them.

Now, in some cases, this is where the attorneys will come in, law enforcement's required to be brought in, but again, that's for the, uh, it's so varied across different jurisdictions and all that type of stuff. It's best to lean on them to make that, make that determination and not you. That's right. Uh, yeah. And that, uh, we're gonna take a similar approach with regulatory authorities. We treat them very similar to law enforcement. Um, but very important to call out.

Again, depending on the client basis that you serve. And, um, state, you know, state laws are absolutely something that could end up in this space as well, whether it's privacy laws or, um, actual cybersecurity laws, depending on your geography and where you reside. Um, client, this is where we call it client notification and communication. Again, we've talked about that a lot. And then just public media handling. Um, and public media is gonna be another thing, right?

That goes back to the, you know, what are you gonna, what are you gonna say? What are you gonna post? Our marketing groups all like to post on social media and that kind of thing. This is probably not something we want to go crazy on. And, and our breach council is ultimately gonna guide that decision. Um, they're gonna review everything, and that's something that's in our policy. We want legal to, you know, Chris touched on it earlier, we want legal to be involved in everything.

Um, jumping through these hoops, making a determination, if that is the right word to say. In some cases, even, it can come down to debating one word in different posts. But, uh, very critical element to having your policy as well. The, the time to address this is not when you're knee deep into it. I would also note that in a lot of cases, your cyber insurance may provide resources for that as well.

Um, public media handling, public relations is typically something that can be covered in those cases. So Yeah, and they usually, um, they usually kind of pre-team up with the law firm. So the law firm that the insurance company provides, as well as the crisis communication PR firms have, have a pass together and they work very well together.

And so, again, it's kind of one of those situations where you should trust that, those decisions because, uh, instead of bringing your own PR firm that may have never worked with this attorney or, or vice versa, uh, that can be a, that can become a challenge. So you might as well just let the experts that have worked together know each other very well, work as a team with you to, to, to handle those things. That's right.

So, um, we've got an incident response flow chart that we've in, that we have that helps us walk through it. And it's really a decision tree. I'm gonna, I think I'm gonna jump down to that in a second. It's, it's partially redacted, but you'll get the point. And that, that's I to be upfront. I think that's probably been the most helpful thing, um, that we've had running into this.

It really does walk our folks through, they pull that chart up and, and some of my guys just printed off and put it right on their desk kind of a thing, and they'll walk through it. It's a pretty simple, if this happens, you need to do this. If it's a no, do that instead. Um, and let's walk through it. So I, I think that's a, just a very good visual to include in a plan. And we've seen pretty good tangible results from that. So just sharing some feedback there.

Evidence chain of custody and tracking form. Um, this one came out in necessity that if, if you do get involved in on the more serious side of things, you're required to have this. You know, it comes down to if you're sending hard drives, right? If we're packaging up images on a hard drive and shipping it off, um, and whatnot, you need to have evidence tracking for that. So having a good form to do that is something, again, that you want ahead of time.

Um, these things don't need to be too complex. You can, you can do a search result for it, and you'll find some pretty good examples. But, um, evidence tracking really is a critical component just from that chain of custody as we ship, um, materials around. And that, that could be physical media, it could be, of course, be digital assets as well. Um, and that's, that's something that we've included in that. Chris, I don't know if you wanna add anything on that one. No, not really.

Don't have anything to add there. I think you said that, right? All right. Incident response scenarios. So, so this is an area that we've, um, we started with kind of the three most common scenarios that we as an MSS p face. I think, uh, um, I would assume this is preferably pretty common for most folks on the call business email compromise or corporate account takeover, um, typically is our number one thing, um, that we, we see, right?

It's, it's weak passwords, a lot of, you know, social engineering. There's a lot of ways phishing, there's a lot of ways that this can, can occur. Um, we've walked through those various, um, scenarios and, and we walk it through. We literally walk this through a, if, you know, if a scenario like this happens, let's go through the steps and take it through, and, and it's an example. I wanna be clear on that. So the purpose on this is, it's, it's training, it's a resource.

Um, it's just, it's a really good thing to have, depending again, on the client sectors that you serve, like C-G-I-C-G, you know, criminal justice does a, they call out that they, they want you to have kind of the top six things. These are three of those. Um, it's a really good thing to have and to talk about. And that's, again, like I said, that's an area that we have expanded, um, to include. I think we're up to six or seven different scenarios now.

Um, denial of service is one that has absolutely popped up, um, more recently and, and how we address that, right? So, again, it causes you to think about it, and whenever we pop a scenario up, we actually tabletop it. So we are gonna walk through, these are gonna be things that we go through, and they, they don't all have to be formal, right? I don't know, I, I've got a little bit of a law enforcement background as well. And, and it comes from what they call a tactical mindset, right?

Just think about if this happens, what am I gonna do? And it's something that, you know, drinking your coffee in the morning, um, I encourage my folks to think about these things. Like, Hey, does this tool really work in this scenario that we've never thought about before? Think about what happens that might cause you to think on something. And nobody does a better job of showing this than, than I think, uh, some of Wes' examples, right? George Washington, what's the best way to evert a war?

Be prepared for Here? So Mike, let me ask you this. Uh, you can see the level of detail here and, uh, just in terms of, just in your business, and then you think about the customers, like, this is time consuming, is I want everyone to get this idea that doing this right, protecting yourself and your business outside of tools and tool stack, it, it is a lot of labor, right? A lot of process. And, um, hopefully everyone's picking up on that, right?

That this is a commitment you have to have and you gotta, eventually, you gotta price it into your services. Absolutely. Um, it's, I think it's kinda like Stan standing at the bottom of Everest when you start on it. I, I think that's why it's so daunting for everybody, right? You look at this, and I should have not have scrolled down right away, but I think we're up to 26, 27 pages, something like that, which is, that's a lot of words. Yeah. That said, we had to write it one time, right?

All changes after that. It's lessons learned. It's pretty easy to adjust it, right? So yeah, the more that we can do this and there's tons of these plans out on the internet, I think that's the, that's the first and foremost thing is pick something that you like and start somewhere. You are gonna mature it and grow it. And the best way to do that is start somewhere, tabletop it, grow it from that, and then incorporate into when incidents happen. There's no rocket science to this.

It's, you just have to start. The best time to start is now. And I always say that the, the likelihood of you pulling this incident response plan out is far more likely than you pulling out a disaster recovery plan. I just think that this stuff is gonna happen more than a tornado or a hurricane or anything of that. And I, the other thing I like to echo on these types of situations, especially with your clients, is people are much more, uh, empathetic or sympathetic when it comes to a disaster.

Uh, people are far less empathetic, sym sympathetic when it comes to a cyber event. So, uh, I would say, you know, if you've been hit by a tornado or a hurricane, customers are gonna be understanding that you're gonna be down and they're gonna be down and that type of stuff. But when you get hit, when their IT provider gets hit by a hack, uh, there, there's not much understanding. So having your ducks in a row here and having this well rehearsed is, is paramount. Yeah.

I mean, listen, if, if you're looking, uh, you know, you know, I always bring back things to sales, right? So, uh, you're with a prospect and you're starting to have these kind of conversations. One great question to ask is, Hey, you know, can I see a copy of your incident? Has your, has your MSP worked with you on an incident response plan, a business impact analysis? Can I take a look at it? And 99 times out of a hundred, they're just staring at you and say, a what?

So immediately you can use the work you've done, you can monetize it, you know, with your customer base to drive value. You can monetize it in the sales cycle to use as a wedge, besides the fact that you're actually helping yourself and your customers too. Yeah. Awesome. Um, just for sake of time, I, I just wanna hit on a couple elements. So this one really probably is a, this one was one of the most important parts of the plan. You've gotta call out who the actionable, responsible parties are.

Um, I, I've seen some questions on the side, you know, about, hey, putting the call lists and that kind of thing. I'll be up front. We don't, this is a plan that we wanna pull up and execute, and we do don't wanna make it 50 pages. So we re we refer to other call lists, we refer to, um, our business continuity plan actually has that first to last call order in it.

And this, um, incident, our incident response plan is a component of our business continuity plan, as is our disaster recovery plan, right? So all of those do come together under one umbrella. Um, that's, that's something I would encourage, because obviously a trigger for a, for your BCP could be an incident. Um, so understanding and knowing how those stitch together, um, I think is important.

And then just for sake of time, uh, I wanna run down and hit the flow chart just so everybody can kind of see. And this is probably too redacted, but, um, key element here I think you can see is that we've got a lot of stuff underneath that that are kind of internal to our organization, but, um, we've got different assignments down on the bottom. We've got the, the color chart you'll see legal as a pretty big is, is purple. We've got a lot of purple boxes, um, that I left showing.

And, and that's a, that, that's, this is what we've done, right? We've built it out. So you can pull this out and you literally start, it comes in with a ticket. Um, that's how ours typically come in, as I'm sure do most of yours into the PSA. And what do we do from that point? Um, there's a pretty substantial flow to that. And I'll, I'll go through and do a better job of redacting this. I I will make a version of this available as well.

'cause I think this is a good thing to have, um, just to do that. Really good. This is really awesome. Look, I, I, I, I think, uh, both with what Wes covered with the preparation and what you've been just so gracious, like you don't have to share anything, right? Uh, to, to do Mike. Uh, I don't know how the rest of the team feels, but I feel like we really, I, hopefully everybody who's on today feels like we got him pretty far down the line. Like, enough where you can really get started, right?

Um, or you can go back and look at what you have and, and kind of do a little gap analysis. So Wes, what do you think? I'm right on the money when, uh, Mike Ard said he was gonna share this out, I was overjoyed because I think sometimes we talk too much about it and we don't actually show, uh, and share. And it's really good for us to do this 'cause we're all in this together. Yeah, absolutely. Andrew was this awesome, Awesome as always.

Um, you know, just you, you can see it from the, uh, response, uh, in the, in the, in the chat and, um, the interaction and the engagement level that we've had.

So, um, you know, Mike, uh, uh, Chris, Wes as always, you know, as you like to do, Wes, one of these and, and thanks for, um, your selflessness in terms of, you know, uh, helping, helping a lot of people, uh, not only helping, not only directly helping, you know, the m MSPs, uh, and MSPs that are involved, um, with Gary, the cyber nation perch, the cyber call. But, um, they're clients. I mean, this extends, extends down through, you know, Gary, we're probably what, touching thousands in Yeah.

Look, somehow we got this thing started, the people here, and, um, I think we all feel the same way. Like beyond our businesses, this has become a personal mission. Yep. Right? To, uh, help MSPs protect themselves and their customers. Um, this biggest thing that's happened, right? Um, just, just the last six months deescalations in the 25 years that I've been in the IT business.

And, uh, so we're not gonna, we're not going down without a fight, and we're gonna do whatever we can to educate everyone and knowledge, right? That is the only thing that's gonna get us from where we are to where we need to be, you know, moving forward because, uh, it's not going the other way. Uh, I feel like the threat actors have proven, you know, Wes, they're, you know, where MSPs were a few years ago of ramping up and maturing their business model.

They're at the early stages of maturing their business model and figure out how to be more effective, you know, in terms of their threats, man. Absolutely. I mean, what I love is that we're on this journey together. When I look at where MSPs were at three to four years ago when perch was first starting to come to market and understand MSPs, wow. Um, where we've been then, where we're at now is light years ahead.

I mean, truly light years ahead, and a lot of that's due to Andrew Morgan and the work that you've done among them and bringing us all into knowledge share. Uh, but there is hope we are doing better. Um, there are victories. You may not feel like it, but the fact that we have 537 people on this call that were interested and want to know more, uh, that just makes me so happy to know that, uh, we're really doing real good, uh, among our SMB clients and that, that's so important, Gary.

Yeah, and listen, I said it on the cyber call, you know, this week, whether MSP's leaders like it or not, you reached the point where you're gonna have to be business people first and tech second. It's not, you don't have the luxury anymore. Before it was just that if you weren't, you didn't make as much money and you didn't grow as fast and you didn't get your return on, you know, investment or assets. Now you and your clients are both, you know, at risk. You don't have that luxury.

So everyone's gotta think in those terms, gaining command. 'cause we can't do any of that if we don't change. If you don't change your business model, how you package, how you price, how you go to market, how you have that value proposition, you're not gonna have, like, think about how much work Mike and his team have put into this. You have to have that built in so that you can do it. And this point you have to do the work. You can no longer not do it. I think we're all in agreement on that.

Gary, it, it came out yesterday, I won't belabor the point, but it came out yesterday about, you know, with Justin asking, you know, you, you have to be able to, you know, practice what you preach. You have to, and, and, and you used to talk about command from a sales perspective. I, you know, I've, dear friend, I've known you for 15 plus years, and you'd always talk about, Hey, you can't go ahead and hire a sales person and expect them to just sell. You have to have command of this.

Cyber is identical in that analogy. I mean, you cannot expect to have, you know, your house in disarray, the old cobbler's kids, you know, back in the days where you could have your place just, you know, in shambles, but your customers really nice Goa those days because in the depositions those things come out. Questions about, you know, what kind of, you know, risk assessments are you doing internally? Tell, you know, what about your cyber hygiene? Wes, I see you're shaking your head.

Those things happen, don't they? Yeah, they do happen. And um, you know, David Powell says it best if, uh, you, you talk to a fitness trader who's 400 pounds and chugging Mountain Dew, uh, the chances of anybody using that, uh, fitness trainer for anything outside of like playing World of Warcraft or whatever it is, is, is basically n right?

And so having your own house in order, um, understanding how to do all of this and build this, starting with yourself, eating your own dog food, not only does wonders to protect your own organization, but also flowing down into giving you the confidence. And I like that word you used command to be able to share this with others. For example, Cody, I see the question he put in the ask a question of like, how do I get my customers and clients to understand this?

Um, a lot of this comes down to really, truly understanding it yourself and, and understanding the value behind it. I'll give you one quick example I'll lead you, we'll leave you with is, uh, and I can share this publicly. So I love what Carl, uh, from Snap Tech says about all this Carl Bickmore. So Carl talks about, you know, certain things that they do. They brought on a client who had already had a breach and they had to walk through that with their client.

It wasn't at the fault of, um, of, uh, of Snap Tech, but they got that, they inherited that breach. And, and listening to him talk about how he handles that from now, he set a minimum standard. And the way that he talks to his clients about, Hey, this is so important. You can't afford not to have this. And honestly, we can't afford not to have this either, that kind of buy-in and confidence that comes with it 'cause they've been through it.

The bullets have flown over their head and they survived means the world to them, right? Gary, Listen, I haven't seen anybody get there by someone giving them a sales script or done for you marketing. That's not how it happens, man. It happens by actually changing, doing the things we talked about today, changing your organization, building that culture. And when it does the other parts of it, answering that question, how do I explain the value? It's like falling off a bike.

'cause most it people, business owners as MSPs, when it comes to technology, they're competent, they're sincere. And once they do it and see what's involved, uh, you know, you're not gonna sit, uh, you're not gonna sit Mike down and tell him someone else can do something for less When he's logged all these hours with him and his team, that's not happening, okay? It's part of his DNA now. And that's what you have to do.

Do the work, make it part of your DNA, your customers will pay more, you'll win more deals. I watch it happen over and over and over again, man, this is not only the right thing to do. It's good economics for SM for MSPs when they do it. Gary, we, we've seen, and we've seen, you know, the people that have put in the hard work go from 150 a seat into the two hundreds, two 20 fives and, and more fair.

I just saw a small deal today that just this morning that came across, you know, one of our peer members, it was only a 12 or 13 seat deal. It was like a 360 bucks a seat. So, yeah. 'cause they set a minimum. So, yeah, I, I will tell you once, once this becomes your culture, price will no longer be an issue. It's, it just isn't. Yeah. In every market we're watching it happen. And Wes, you're seeing this, you're seeing the same thing out there every day.

Yeah, I all Day long, like Wade says, all day long, all day Long. Hey, um, I put Chris LA's Chris, I want to give you a big shout out. You have been, you know, in the, I think three plus years, or you and I have been doing stuff, well this group collectively, but, you know, I can't thank you enough for your selflessness and, you know, um, your knowledge, your, um, just sheer willingness to, you know, give lessons, learned what to do, what not to do.

Um, thank, he Doesn't have the same kinda lighting that, that Wes has, but he, other than that, he's, you know, he's awesome. He Is. Um, he Got up this game. I want mine to look a little bit more dramatic. Serious. Yeah, you're more mysterious. So, um, I Appreciate that. I appreciate the team that, you know, doing this solo would be next to impossible.

I mean, this cast of people, I mean, I don't, if I was on the recipient Iner observing this, I would just be like, I guess foaming at the mouth because, uh, you're, you, you get, you know, five excellent perspectives here, uh, from what we do. And then also on the, on the weekly calls. I mean, it's just, uh, it's what we do and we're proud to do it and I'm, I'm proud to do it personally. Yeah.

And, and so Chris, I put your URL on there for LinkedIn if people wanna hit Chris up, um, you know, Good person to be LinkedIn with. Yeah, It really is. Um, not that you're hoping to have Chris, uh, on speed dial, but I would tell you it's really important to have someone, if it's not Chris, on speed dial because, um, you know, again, it's, it's about preparation. Mike.

Um, also I've known you for a long time now and really, uh, can't thank you enough for your selflessness and sharing so much stuff, um, with the community. Um, really appreciate you showing up here as well. Awesome. Alright, Andrew, we'll wrap things up. Uh, thanks everybody for attending. We hit 5 37, so, um, again, we're gonna get this recording out to everybody. Sure. Also, I'm gonna get the assets and I'll be posting them at True Methods along with the video.

So again, thanks to everyone and we'll be working on something else that'll be big for Q4. Absolutely, really appreciate it. Wes, Mike, Gary, Chris. Thank you. Gary, you want to take us out with a ha See Everybody.