Building an Incident Response Plan for Success

So, Okay. Okay. Alright, we're back. Thank you all for hanging in there. I hope you really enjoyed session one. We're with Wes. Wait, so Wes, it's the Wes' Beard Emporium. Correct. Wes, we've had some sales call role plays with Gary on that. Yeah, it's, it's Fabio actually. Um, yeah, Wes is my, my brother. Yeah. But, uh, I'm fabi I'm stood in for him. Something about him. Yeah. And I was able, I signed Fabio up. He's now a customer of mine, so. Ah, Right. Very, very True.

I think he would say we're doing a great job. I'm paying a lot. All right. So we are gonna kick off the next session, which is building your incident response plan. Hopefully I can get Chris Lair in here shortly. Um, it looks like he may have had, he may have had to reboot. Um, Wes will be with us for about 25 minutes or so. Um, I'll go check if Ryan can still come on. Andrew, why is it that the two, the techie guys, Wes and Chris, are always having to reboot and having issues?

You and I seem to be fine Because they use Max and I switched to a PC and the world went, I, I I, I don't know it, it seems week after week. Um, hey, but While we're waiting, something you guys could all do for us as a thank you is see that URL at the top, Crowdcast slash e Delio, just highlight that, go right to LinkedIn and be like, Hey, first session was awesome. If you want to attend and just paste it in and Crowdcast will do the rest for reals.

Like, if you guys would do that for us, it'd mean a lot. We're already at 5 37, let's blow it up to a thousand. Right? Yeah, That would be great. That Would be great. Thank, thank you everybody. Yeah, thank you. Okay. So hopefully Chris, we'll get in here shortly. In the meantime, um, I am thrilled to have my good friend Mike Beard, CSO of Marco back, Mike, um, before I welcome you per se and let you say a few things about your background and what you do.

Um, we had you on Gary, how long Ago doing this, Uh, the incident building your incident response plan? I think that was, uh, Q4. Yeah, last year. It was a Q4 last year, Mike. Yeah. Yeah. December mean, But blew it up. I mean, we had Wes, you and Chris did the tabletop, which you're gonna be doing again tomorrow.

So we're gonna be testing the incident response plan, but then Mike, you were kind enough to come on, not only go through walkthrough building and incident response plan, you then sanitized, you know, your incident response plan and allowed everybody to have access to it. Um, I, I don't know if you're gonna do that again. Uh, it's in the cyber nation. For those of you that haven't been in Cyber Nation, you can get it there. But Mike, welcome and thanks for joining us.

Just a brief, uh, overview about yourself, for those of you out here who may not know Mike regard. Yeah, no, thanks Andrew. So Yeah, Mike Briar, CISO, Marco Technologies. So we're, uh, I think most people have heard of Marco. We're up in the upper Midwest. We kind of stretch over to the East coast nowadays in the, I'd say the northeast coast part of the country. But, uh, yeah, I've been at CISO here for a couple years.

Uh, started my career at Marco as an architect working in our larger accounts. Um, prior to that, I spent a little over 10 years as a recovering banker. As, as Wes would put it, I spent some time in the financial industry, uh, both in terms of an IT director and CISO role, and spent a few years in manufacturing K 12 as well prior to, so about 22 years in the industry. I'd say about 15 of that been in the security space. Excellent. Well, well, welcome and thank you for joining us.

I'm not sure where Chris is. I keep re-prompt him here. So, um, Mike, um, you know, in, in interest of time, first off, for everybody out there that may be new, just a quick few housekeeping things I'll keep an eye on, ask a question. Um, we'll keep an eye on chat. Common question, is it recorded? Yes. Uh, up in the upper left schedule, you'll see session two of six right now, when this session ends, um, in 15 or 20 minutes, it'll be up there for recording.

If you're a true methods member, Gary, you're gonna have this in the true methods portal available into the security section. Yep. We'll get it rendered and it'll be part of our security track and that, that we are building on. Okay, fantastic. Mike, can you kick things off until we figure out how to get Chris up here? Yeah, yeah. Happy to do so. And I, I think, uh, Wes, I might ask for a little bit of your help on this one too.

I, I think first and foremost, we wanted to start with what really is the theme of a good incident response plan. And I think that starts with really the founding principle of do no harm, right? And I know that's what Chris, Chris wants to talk about, so I'm not gonna steal some of his thunder. But, um, Juno harm really is a, it's a critical element and unfortunately in the space that we're in, we see that still continue to be one of the, I'd say the negative prevailing trends.

Um, MSPs tend to jump in and we like to go fix it, and we destroy a bunch of evidence and forensics value in the process, right? So we wanna, we wanna make sure that we address that. And I think I'm gonna see if I can share this here. Yeah, Mike, right above you, you should be able to, um, you guys just bear with us. Crowdcast isn't the most user friendly when it comes to sharing PowerPoint. So then Mike, if you just kind of zoom in, there you go. Zoom in on that piece. Perfect. Yeah.

So, um, first and foremost, I think we talked about this a little bit previously and, and it's so important that I want to hit it again. Microsoft really has delivered a phenomenal resource to us when we start with an incident response plan, right? They've, they've got a really good guide that walks through really the key elements of what makes a good incident response plan, that there's technical components, a lot of communications.

Um, I can't stress the importance of communication prior to the event. Educating people as to what to expect, how the plan works, what their roles are within the plan, et cetera, to during the event, how do we communicate out what's going on both internal to the organization in the MSP space to our client, um, to our clients. And then there's also an external com communication component to it as well. Um, we wanna hit operations, right?

Operations obviously is, is very impacted in a cyber event depending on the type of event. Um, so understanding how, how we're gonna thread operations into the whole incident response, um, efforts is important as well. And then, of course, the legal aspects of it. And, um, legal is where I'll defer, uh, you know, to your always to your third party legal firms themselves, breach counsel, et cetera.

And then I think Chris, and I'll give you some guidance as we go through it later as well, but we wanna incorporate all four of these elements in our plan as we go through it. The time to figure out legal is not during an incident, right? You wanna know who your legal resources are prior to an incident. And a lot of times insurance is gonna be one of kind of the governing things for this. Let's start there, right? Let, let's understand what we've got for insurance.

Let's reach out and understand what our cyber plans are, who the approved vendors are on that, and let's take that into consideration when we go through and build a plan like this. But, all right, without, uh, without further ado, I'm gonna jump in. Microsoft hits it better than anybody do no harm, right? Take that medicine principle and let's apply it to cybersecurity incidents.

All too often we see, even, even in something small like a, a business email compromise, we see some of the events that we do through troubleshooting and, and some of the things there really have negative consequences as we respond to different, um, to the different aspects of that incident, right? It could be not retaining log value, right? Sometimes we don't know that a, a fish or a BEC event led to something larger for a period of time.

You know, that dwell time, unfortunately, is quite large these days. I, I think, uh, you know, we, we, anywhere from a couple of minutes to hundreds of days is what we're seeing takes SolarWinds for prime example of that, right? Dwell time on that incident was, was quite lengthy. Um, so we wanna make sure that we maintain that forensics value, right? Do do some of those things that are important. And, and that, again, is do no harm. I, I think that applies first and foremost.

So, Wes, any comments on that? Um, you've got some thought. No, I mean, I, you nailed it. It, it's like what we're not talking about here is not intentional harm. There's nobody on this call that's like, how can I intentionally cause harm? At least I don't think it's, it's, Mike, what you said. This idea of the way that we, we avoid unintentional harm is the same way that we un we avoid unintentional harm in other things. Like, I don't wanna harm somebody intentionally while I'm driving.

Well, how do I avoid that? Well, I do things like following the laws, understanding where a stop sign is, and you know, when to turn with right of way and things like that. It's the same concepts here. Like we, we, we avoid harm when we understand how an incident should be handled and know what we can do when we can do it, who should do it, and a trail of evidence along the way.

And if you're not comfortable than any of those things, you're better off sitting tight, not doing anything, than trying to jump in It's knowledge of that. And, you know, the one thing that I've learned from you, Mike and from Chris, is that it's as important to know what not to do as it is to know what to do. And it's almost like another example is think about like when Covid first hit, you know, it was one of the things that was a huge issue is they didn't know how to treat it.

And some of the things that they did to treat it actually made it worse, right? And they had to learn and figure it out. They didn't know, they didn't have that knowledge. And the same thing, the difference is the knowledge for this is available to you. We're doing it, right? And so once you have that, then you have that, you know, you should have responsibility at that point. That, yeah, that, that's right. And that's, um, I I think preparation, right?

When we talk instant response plans, building an incident response plan, you know, Gary and Wes just said it, it really does come down to preparation. And all four of those, the, the different components, right? The technical, the operational, the communications, the legal perspectives, I, it really is a lack of preparation. That's why I think as we sit through these tabletop discussions that we've got tomorrow or, or later, right?

Have your incident response plan out while you go through those tabletops, that is the time to be testing it, right? Walk through it. When, when Chris and Wes run through it, do you have something in place, right? Do you actually check the boxes when they go through it? That's how you're gonna identify it. You gotta start there. Take it another step, actually tabletop it then in your own organization. And, and I think that's a, that's a critical part to building an incident response plan.

These things, I did share mine last time. It's up to I think 20, 20 plus pages now. It didn't start that way. I think it started as probably four or five pages. We went and copied a template. We started responding to incidents and doing different things, and we grew it over time. And that lessons learned component, I can't stress that enough, um, as we go through it. So, yeah, Because I, I, I want to zoom into that for a minute, Mike, because, so two things real quickly.

You know, a tabletop test is never a pass or fail. Like never approach it. Did I pass it? Did I fail it? No, no, no. You'll never pass or fail it. It's about going through that journey and seeing what did we do well, what the gaps do we have?

And, and the second thing I wanted to mention is, one thing I learned that my examiners loved at the bank more than anything else, anytime we had an incident of any kind, whether it was like a physical incident, a cyber incident, a whatever, fraud incident, every time you know what they cared about, they didn't go like point fingers at me and say, how dare you, blah, blah, blah. They said, show me your after action report. Show me your lessons learned. That's what they wanna know every time.

Because again, this goes back to resilience. This goes back to what did you learn from it? And how do we know that you documented it so you can mature past it? That's what this is all about. And by the way, those are the kind of conversations you should be having with your clients. It's really important to talk to your clients in languages like that, to say, we're not perfect. You're gonna have an incident. Every MSP and every client of every MSSP is gonna have an incident.

The key for us is to build resiliency. When those things happen that we document, we respond quickly and we have some after action to handle it. Like, that's reasonable. And I, I think it's important for us to think that way. Yeah. Really very important. I can't stress that enough. Um, anybody that's undergoing the, the SOC two journey, for example, in your organizations, it's actually a required element. And that's one that I would encourage you not to skimp on it, right?

The best example, again, I'm gonna pick on SolarWinds. If you use SolarWinds internally in your environment, that's something that your auditors to be frank, probably are looking for, is did you complete lessons learned? Did you follow your instant response plan for the SolarWinds type of event, right? And that's the, even if you, you know, you had no indicators of compromise. If you perch didn't detect anything and you didn't get the phone calls, that's all great news. Did you document that?

And did you still take lessons learned, right? Because you're still gonna find things that, hey, we maybe, maybe we weren't able to pick up and load the IOCs in a timely manner, or we didn't know where to go, or we didn't have a process for this. Part of your lessons learned then is establishing that we do have a process.

So, um, yeah, just following some of the comments, I, you know, I think, I think we all know it in the industry, that right, when a cyber event happens to a customer, how we handle it, this incident response plan truly is becoming one of the most important elements of the MSP business because if we don't handle it correctly, they are going somewhere else. Um, if we do handle it correctly, that's how you retain customers.

And I think that's, um, that can really show the strength of an organization, um, as to how we handle all these things. 'cause it is not an, if it's, it is truly a win. So, um, I'm gonna apologize for a little bit of the disjointed us. I had actually planned on Chris and I planned on Chris kind of kicking it off and me rolling through. So we're rolling with the punches here. But I'm gonna, I think I'm gonna take the next step.

I'm gonna go ahead and share out, um, share out an actual sanitized incident response plan. So this is, um, essentially a, it's an earlier version of ours, but it is a draft incident response plan. I find it, Bear with me while I share here. Yeah, Mike, and it's not for lack of trying. We are, Chris is on three computers so far. Who knows? He's in the LinkedIn line of fire. I think he's, Uh, I think maybe he's Too secure. That San Antonio internet he's got going on over there. He can't get out.

Oh, oh, oh man. I thought that was him connecting. That's what I thought for a moment there as well. But Wes, it's not for a lack of trying here, trying to get Chris on. And Gary, sorry for the noise. I keep going back and forth here between, All right. Um, hopefully this is not flashing like it is on my screen for everybody. It is indeed, unfortunately, It is indeed flashing, maybe Unshare reshare it. Chris says it's an Adobe bug.

There was a recent, uh, uh, exploit through Google last, I'm not sure if you saw that, where, um, there was this popup on, on, uh, on the browser about you need the latest Adobe plugin, which was kind of a, a joke because Adobe's no longer supported. And, uh, it took people to this site and this malicious site just recently. This, the read this just the other day. So hopefully that's not what you got, Mike. Uh, hopefully not. I've got a, I am, uh, locked up. So we are, we are definitely.

So you guys, thanks for the technology Jinx earlier, by The way. Um, tell you what, maybe What we can do is we'll improvise here. Uh, Andrew, do you have a copy or, or maybe Mike email a copy to Andrew, Mike, is that, and Andrew can share a screen. Yeah. Mike, is that the copy that we put in Cyber Nation? If you could tell me real quick, if so, I'll just get it up right now. Waiting for Mike to reconnect.

Well, this is, this is turning out, you know, So, um, I, I can, uh, I I can add a few things into this while we're waiting. Please do. I've, I've been known to ad lib a time or two. So, uh, one of the reasons that people struggle with, um, oh, I can't even, can't even see me anymore. There we go. I do not like how it changes my video. There we go.

One of the reasons we struggle sometimes with like, incident response, incident response planning, and what goes into it is there are a number of pieces that get into it. Well, hey there, look who just joined us? How's it going, man? No audio yet. I'll just keep going until you, until you come off mute and you talk to me. I, It shows your mute on the app. You might, you might be able to unmute on the app Or go to, you gotta go to your settings, Garrett.

Um, go Your, yeah, go to your go to, go to your settings and re-pick the microphone. It'll probably say default and pick the actual microphone and we'll have you back. So while you're clicking around layer, no worries. Um, so what I was gonna say is one of the challenges I think we sometimes have in all of this is, how many of you guys feel like you are good with, um, like, like a business impact analysis of BIA? Anyone here ever done a BIA? I'm just using this as an example.

I wanna get some yes or no to Chat and why we wait for some sample data come through. I think, Chris, you're live Mike's. I'm on. Yeah, you're on. And then everybody's here. Wes, by the way, um, you did a really cool business impact analysis, very simplified one, but a good one that's in the cyber nation as well. Um, so, uh, Yeah, so I guess just to make a smooth transition, what I was gonna say, and, and I guess me just jumping in, made the magic happen. So that's a good thing.

Um, is, uh, so when you start thinking about incident response, you need to know what your high value targets are, what your high value assets are, like what are you trying to protect here? Like if it's nothing but a printer, who cares? Go get to go to the store and get a new printer. And so bis are a useful process in this is to say, what do I have in place and what's critical? What needs to be restored? When, how long can I go without it? What kind of gaps of data can I survive?

These are like process stuff like VCIO stuff that doesn't generate revenue itself, but is a godsend when an incident happens. And I was gonna jump into that, but you know what I'm gonna do? Um, I'm just gonna pause and let, uh, la take it back over with, uh, with regard. Hey, I appreciate that. I'm hoping everybody can hear me. That was three different computers, six different reboots, two different mobile devices, and it still didn't work. So I have no idea what happened.

But anyway, uh, so instant response. So yeah, I mean, we've seen a, a lot of changes over the, over the last few months, right? So a lot of you probably seen us in in other forms or other discussions. And there's a couple kind of themes that I've kind of seen. Number one is I have seen that, uh, for the most part, managed service providers seem to have their stuff together a little bit more around instant response, which is fantastic.

They have their, they have their plans in place, they seem to know what's going on, that type of thing. Uh, so that's the most common theme. But the second theme is, is there is a theme of overconfidence now. And so we now have this theme that managed service providers are actually going in and starting to kind of make some decisions on their own, which doesn't really align pretty much with their incident response plans.

So we've seen some, some cases where, uh, the managed service providers, um, are basically restoring environments without any thought of preservation. Then we ask 'em what happened? And their response simply is, well, our client told us they just want to get back up. So we did that. And, um, the long-term revocations are that are horrible, right?

Because I, I would tell you, I've had half a dozen calls in the last, uh, few months where a managed service fire says, yeah, our, our client, they had a ransomware event. We, we were able to recover them. We listened to what you said about backups, and we made sure those backups worked. However, now a few weeks later, our clients are calling us asking us why they, why, why is our information on the dark web? And so what happened is the MSP just said, Hey, we got backups we can restore.

You didn't even investigate what variant it was. And obviously if you don't touch bases with these guys, they're gonna publish it. And so then they're like, well, what do we do now? I'm like, well, did you preserve any data from those systems? And of course their answer is no. We just recovered on top of everything and done so their clients are left in a really poor situation there, because now they have to basically notify en mass.

So there, 'cause there's no way to ascertain what the bad guys did, what they stole, what they didn't steal, how much they stole, or whatever the case may be. So I mean, the good news is that's a tough message, dude, To customers. It is a tough message and it's really difficult to explain to attorneys. And then on top of that, it gets, uh, really squarely on the insurance side, right?

Because, you know, if, if the client does have a cyber policy and now that policy has to pay out for a much larger reporting and notification type claim than they did before, and they look to you to say, well, you took the steps to kind of, um, jeopardize the, the forensics process and put us in that position, you could be set in a position.

So, um, you know, my, my greatest thing and what I hear want to hear from Mike and what we'll go through today from an interactive perspective is, you know, I think there are different scenarios, and we talked about this, you know, last year and so on, but you know, some of these scenarios that I've seen that have come up is, Hey, what happens if a client gets hit that is co-managed?

So I'd like to hear from Mike from that side of things versus, you know, a client that's not co-managed, that's completely dependent upon you. And then the third scenario, which Mike, you know, obviously they're huge and they have probably every possible combination scenario one could dream of is what happens when you have a client that may have a different firm involved full-time as well. So you're doing it, there's a different firm doing security and uh, so on and so forth.

So, you know, Mike, maybe if you want to kind of speak to a few of those things and then I can kind of interject some questions here and there. Yeah, no, um, good question. So the, uh, I I would say co-managed, I think is the most difficult out of what you just said. To be frank, that, and I, that shouldn't surprise anybody, that it's very important to be very clear where the lines are of delineation before an incident.

I think that's probably the number one takeaway, that it's easy to say that. And, and to be frank, we say it a lot internally, but we still struggle with it because we'll say where a line is and then our marketing material says something else, or maybe a sales rep promise something else. Um, that, that's where that consistency really is important. Just having the delineation that we're responsible for this.

And then I think the next step is when we are responsible for this, it's having a team that's actually capable of delivering in a co-managed way, right? And that's the, unfortunately not every engineer is capable of doing that, is what we've found with security solutions. I wanna be clear on that, right? That may not be the case for other things, but security does add some complexity to it. In a co-managed environment, the client typically is co-managed because they expect a level of expertise.

Um, you have to be able to deliver that expertise when an incident happens. It's typically gonna be at least a tri-party, um, incident, you know, forensics review, I guess, or statement of work, if not even more than that, you may have four or five parties on it. Um, where we've really struggled, I think in co-managed is MSP systems by default, the multi-tenancy and, and things within our platforms don't do a good job of, of really segmenting that data out.

So attorney-client privilege becomes an issue. Um, understanding how you're gonna interface with that client from an attorney work product or attorney-client privilege perspective is, is super critical. And that's an area that I think is continues to be a challenge. We still struggle with that today just from a platform technical limitation standpoint. Um, understanding your role in a co-managed customer is very important from a how far do you go?

And again, I think it's just being very clear upfront in your agreements, your contracts, your catalog, whatever that case may be. And it's probably a combination of, of those documents, um, is very important when an incident happens, be very clear right at the get go of the incident on that very first call, here's what we're responsible for, here's what we're not.

If you want us to do these things, if you have the capability, do it right, be, but be clear that maybe it's time and material or it's something outside of the covered agreement. Be clear on it. And also to Chris's point, we're far too overconfident. All too often, don't be afraid to do that. Hey, that's not us, that's a third party firm. You need to go to your cyber insurance, get a forensics firm and actually let them do that. We'll continue to work with them.

So that's what we've seen in the co-managed space. Um, I wanna start on that one, Chris. I don't know if you wanna unpack that one a little bit. I think it's a good one because I think it's coming up more and more.

And so I can tell you, you know, the situation we have where you deal with a lot of mixed personalities in, in CO and co-managed environments, especially if there's, you know, a CIO involved or, um, you know, another type of maybe a, um, contractor type virtual CIO meaning not an M-S-P-V-C-I-O, but a real person that's standing in as a CIO in that particular situation because I find those to be probably the most complex.

Um, you know, we get in a lot of situations where you have CIOs that, you know, have 20, 30 years of experience behind them and, and, um, the better way of putting it's, they think they know everything, right? And so they've never been in a, in this type of situation, I'm sure they've been in some kind of antivirus attack or something like that back, you know, back in the day, but nothing like that.

But they are not going to be the type that's going to just step back and, um, act like they don't know anything. They're going to try to take charge because they're trying to save face, obviously save their job and, and do a number of other things to kind of pasteurize in front of whomever. And so that's where you have to have these relationships and you have to where incident response planning and, and, and testing and being ahead, being ahead of the curve or ahead of one of these events.

It's, it's very key. I mean, you know, I have a situation Yep, go ahead Gary. If it's co-managed or Mike, when you're, you're doing some tabletops, does that have to include either the client or another vendor ahead of time so that it's really clear where those lines are? I think in these cases where it's co-managed, and especially if it's a key relationship, you need to do that, you need to force that test to happen, uh, because especially these co-managed these personalities involved.

If, if you're not, if you're not doing that, there is a, there's a huge bucket full of surprises awaiting you, uh, once this incident gets kicked off. And I think, Mike, you're gonna agree with that? Yeah, a hundred percent. I, I, I would say two things. I would say assessments always a great place to, to evaluate up front as well, because that's just another tool in our toolbox to identify areas that we're responsible and not.

Plus it kind of puts the customer on notice on, we found these gaps, we formed an opinion, here's where your cyber posture is, that's now documented. So when something happens and it comes back that you know, hey, you didn't have multifactor that caused a BEC event kind of thing, and it's co-managed, you're responsible for it too. Yeah, well, we're actually really not, because remember when it causes you to do that.

So I would say that, uh, tabletops are, are critical and and I think that's, uh, coupled with an assessment. I think those two things go together hand in hand. And I, I, I wanna hit a couple of the questions. We've had some good questions come through that ties back into this, you know, put a cover, put a, put a CYA clause in your contractor, limitations liability and those things, they're really good tools. And to be frank, I would encourage everybody to do that.

I'm not an attorney, talk to your attorneys, but my opinion on that matter is limitations of liabilities go a very long ways, but they don't cover everything because there's certain conditions that have to be in place for that to apply. You have to have reasonable technical, physical, administrative controls, right? Like those controls must be present for that to happen. If you're negligent in your duties, doesn't matter, that goes out the door.

And to Chris's point, when we maybe get a little, go a little cowboy and start doing things that we probably as an industry shouldn't be doing, um, or maybe don't have the right expertise that can void that pretty quickly. Um, so, so just be aware of that, that limitations of liability are important, but they must be backed with sound procedures, sound practices in order to really be, um, to your benefit. And You really need to have that audit trail conversation.

So whether you're doing tabletop exercises, you're communicating stuff in a QBR or whatever the case may be, you need to have that fall back to fall back on, because like I've said, many a times, those clauses are great, but it doesn't prevent somebody from suing you. And then if you have arbitration clauses in there, it doesn't, you know, it doesn't prevent them from going to arbitration.

You're gonna have to go through that process anyway and you're gonna have to hire attorneys and you're gonna have to deal with all that. So yes, definitely. That's a, that's a great question. There was another question I saw in here that someone had asked that says, Hey, please, uh, give us a little bit of clarity or some differentiation around insurance forensics, et cetera. And so it's a good point. I think that was right up here for that was Drayton that asked that question.

So the, the way our world works today, let's just say you're, you have somebody that has cyber insurance policy, uh, there's one of two ways that that carrier is going to do things. Number one, they're gonna have a set number of law firms that they, one of those law firms, they're gonna assign to the claim and that law firm is then going to bring in whatever forensics company they have a relationship with to work that case with them.

The other option is that the, the cyber carrier is going to assign a law firm and a not and a forensics firm independently of one another. But those two work together and then they are gonna work that particular case. Now, the, the case in point is, and a lot of people, and this is something that if it comes up with their customers, it's something to get across is those both that that firm, um, from the legal side and the uh, IR side are engaged directly with your client.

They are not working on behalf of the carrier. They're only assigned by the carrier because they've already worked out kind of the T's and C's and the rate structure and all that kind of good stuff. But that attorney is the same relationship as if your client went out and went down the street and found a, found an attorney. The key thing about these law firms that these carriers have is that they are specialists in breach in what they call breach counsel or breach coaching.

And so, so it's very important to, uh, obey those lines. And I will tell you that a year ago, it wasn't as much of the case as it is now, is that the carriers were much more lenient about the way things went and law firms and when they, and when the carrier was being called and so on and so forth. But I can tell you with the rise in claims and the rise in the amounts that are being, having to be paid out in claims, the insurance carriers are no longer being as lenient.

So when it really comes down to these things, and I've seen it happen, is when people refuse to call their carrier up front and start that process early on. And so that's very punitive. So it is, it is very, you gotta be careful of that and be cognizant of that and respect that. And then if that IR firm comes in, most of the time that IR firm is going to lean on you as the IT provider because you, you have the most knowledge about that environment. They can't just go in there blind.

And so they're gonna do that. So just if you can play ball and cooperate, you'll be in in very good shape. And again, try not to take on too much of that IR burden because it's just not worth it to you. And it can kind of, kind of gray the waters a little bit between you, your client and the incident that's going on. Yeah. Chris, maybe, I think maybe just expand that just a little bit.

I, I think, I think it's important for folks to know that there is a difference between putting your insurance carrier on notice of something versus actively working a claim. Yeah, that's a, that's a great point. So it's not like, you know, on the, on the personal insurance side, you know, it's only, it was one of those things you call in your, your carrier State Farm or Allstate or whomever, and that qualifies as a claim whether or not you do anything or not.

In, in the business liability side, I can't speak to everything and I, I'm not a licensed broker agent, but what I can just tell you through experience is that you can still call and put them on notification. Does that does not initiate a claim. Um, you, you may get into it and decide that you don't even want to go down the claim path because your client might have a high deductible, 25 grand, a hundred grand, I've seen 250,000, right?

And so for them, the claim might be so small that it's not even worth them pulling that trigger on the claim 'cause they're gonna have to pay that much money out of pocket anyway. And they just don't wanna pull that lever for that claim. So that, that's a good point. So even if you've initiated that, let's just say hypothetically it was a call with us in a, in a law firm that we work with, that initial call doesn't, doesn't pull the trigger on a claim yet.

You're basically, hey, this is what's going on. The attorneys are going to provide an engagement letter and we would provide a statement of work just like, or, or multiple statements of work just like any other IR firm was. And then if you accept those and you accept that the fact that the insurance is going to cover those, then you have entered the claim. A good, good point, Mike. Yeah, I think that's important.

'cause that goes back to your, your point on uh, um, you know, small things can, can snowball real quick and that's where if we have something that maybe doesn't look like much, but all of a sudden we find out that data was exfiltrated, now we have to do full forensics on an environment, but we didn't put the insurance carrier on notice when that first phish link was clicked or whatever.

And too much time elapses you may not be covered, at least in my experience, that is a, or you may be a bit, there could be some punitive effects to it. Yeah. And then, and then there's gonna be things that may, they might partially cover and you're gonna still be out.

A lot of, you know, your client might be out a lot of money and it's, it's always good to get all those things clarified up front and the adjusters with all these carriers are very good at, at being upfront and, and making sure that stuff's clear and 'cause they don't want any snafus on their side 'cause it makes them look bad as well. Yeah. And Chris, I mean again, if you set it up this way, the MSP right is, you know, it's gonna be running a clock.

They're gonna be, you know, billable, uh, for this. And whether they get paid or not probably has to do with how the insurance claim works out in many cases. Wouldn't you agree? Yeah, I definitely agree. And, and there's even more rules today, right?

So with the, you know, with all the news around ransom payments and, and you know, the, all that type of stuff and, and you know, checking Bitcoin wallets and making sure you're doing OFAC sanctions checks and all that type of stuff, it's very important that those things get done as well. I mean there's still the back, you know, I don't want to, you know, harp on this cowboy con this cowboy concept, but we we're having MSPs going out buying their own Bitcoin still and, and, and making payments.

And you can't do that. I mean, you have to go through these sanctions checks. I mean, if, if you, if you pay a wallet that has a connection back to somebody, whether it's in North Korea or some other organization that's listed on any of those sanctions list, I mean, you're gonna be in a lot of trouble and your client's gonna be in a lot of trouble.

And so the insurance carriers have got a very good solid process to make sure that those lines are very clear and that those processes take place and there's the documentation to support them. Yeah, it's making the payment of ransoms a little bit more expensive because on the backside, the fees and everything that all this com extra compliance work that has to be done, it has to be absorbed in that fee structure. But again, it's, it's, it's super key.

You know, we used to say before, uh, you didn't have to call law enforcement right away, but today we're saying, Hey, you know, file a file, file a, um, something with the FBI now get law enforcement notified early because you don't wanna look like you were trying to hide or do anything behind the scenes. You wanna be as upfront, especially when it comes down to these ransom extortion payments as you can be.

Chris, just wanna point out just the process that you and Mike are going through right now just kind of points out the need for tabletop. I mean if that doesn't spell the need to kind of walk through this process and have somebody like you, Chris kind of observing now you're gonna do this tomorrow, right?

It's why it's one of the most heavily viewed things that we've done collectively over the years, but having your eyes, a third party's eyes walking through that and going, whoa, probably not the step you wanted to make. Here's what could have been the ramifications. Yeah. Yeah. Even just a single point of expectations with customer expectations with other vendors. Just on that alone, Andrew, is, is, is critical. Yeah.

Chris, I want, I know you wanna say something, but I was gonna, Mike Was gonna say something first. Oh, go Mike. No. Yeah. So, uh, well first off Andrew, I did send you the, our plan. So it should be coming here in a minute. The redacted one, you can probably just share it out here. That's gonna be easier than me sharing at this point. Okay. We'll just let everybody take a look. Um, reasonableness.

So there's been a number of comments on like reasonable controls and, and kind of the flashy thing there, right? And that's so reasonable controls, that is, that is gonna be a legal thing, right? That's gonna put you back in the attorney camp. What is a reasonable control? Well, reasonable is, it's, it's what's common or maybe a best practice against your peers. That's really what it is. You know, Chris said it earlier, if you go to court, you're, or arbitration, you're sitting there.

If nine out of 10 folks have multi-factor and you don't, well you probably are missing a reasonable control. And, and I think that's a, there is no one answer for that unfortunately. 'cause what's reasonable for a thousand employee organization is not the same as what's reasonable for a 10 user organization. In most cases industry may change that. But, but that, that's important to note. And I think that ties back into seeing MSPs or other businesses lose cybersecurity coverage recently.

That typically is indicative of a gap in reasonable controls, right? What is reasonable? Well now it's being determined by your insurance providers as what's reasonable MFA To be frank, I don't, I haven't seen MFA on our, um, our insurance renewal questionnaire for probably two years. It was there every year up until a couple years ago. That's assumed that it's there, there now it's not even on the questionnaire. 'cause they assume that it's there.

They're diving into, I got, I had probably 10 questions on incident response plans. How often we test them, does it include certain elements? Do we have EDR capabilities? Are we right of boom, tying it back into the last section. That's really what they're after. That's reasonable now is do you have detection response capabilities? Do you have these plans? Do you test them? How often do you test them? Right? That's, that's my 2 cents on reasonable.

Chris, I'm sure you've got some thoughts on reasonable and, and Gary as well. You're exactly right. I mean, the thing that we're seeing now is, and I know there was, there's another, you know, segment that's kind of talking about, um, you know, legislation and stuff around MSPs and re regulations around MSPs. But you know, from a good sided perspective, you're not regulated, so you don't have to worry about that.

On the, on the, on the flip side of things though, it's very difficult to have a standard, a reasonable standard, right? So it's not like you're in the banking world where every, everybody knows how banks are supposed to operate and there's a, there's a, there's a standard what, how banks operate in the MSP world. Um, it's difficult because there's not this kind of general, you know, acceptable baseline for, for MSPs.

So that's why you have to go above and beyond what you do as an MSP, especially in these situations to demonstrate that. Because if you're in front of a, a very good litigation attorney, he or she's gonna tear you apart, um, or attempt to tear you apart because you know, there's nothing that you can kind of base your, your actions or behaviors on. So that's why it's gonna be key.

I mean, and the other thing is, is that's why I say it's important to know your lane, like we've talked about, know your lane with your clients and who's gonna be doing what, know your lane when it comes to this legal side and this and this, um, IR side because we've seen some great MSPs get ahead of the curve and start communicating and getting, getting third party, whether it's an antivirus or some endpoint vendor involved. And there's all this communication before the attorneys get in.

And it used to be thought that, hey, once you get the attorney, all that communication is retroactive under attorney-client privilege. But that's not, no, no longer the case. I mean, there has been very recent exceptions to that and it's scaring the crap outta the attorneys. So that's why you gotta be very careful on what you communicate.

I mean, I was, I've been involved in one where they had a compliance person on the, on the case of the victim, and this compliant person was adamant that every call, I want you to document everything we said on this call. I said, I'm not gonna do that because that's not in your best interest legally. We'll verbally communicate, but not until that written, that official written report gets done, will we put anything in writing? So you as an MSSP need to realize that as well.

What you keep notes internally is fine, but once you communicate anything in the email or whatever the case over to your client, you can't assume that's gonna be underprivileged. So you have to be very careful what you say because if you say something prematurely or something that you do not have the technical competency, uh, whether that's in actuality or on paper to do so, then you're, you're you're gonna, you're gonna look bad and your client's gonna be pretty p****d off at you.

Yeah, and it go it, Hey Chris, it goes back to communications, right? And I think, Chris, I know you're a, you're a fan of, uh, of theirs and I I'm starting to be as well, like xts, and that's where we're starting to see some new players come into the market that are really designed to handle communications differently because to be frank, because of that problem, right?

What ends up in a ConnectWise ticket, for example, um, or or a your other PSA solution that can be a problem down the road, right? Yeah. There is some sensitivity there. Yeah. And I think, you know, Jose asked a question, well, we, if we have a client that gets infected ransomware, what should we do? Well, our message to you today is, that's a good question, but you need to know ahead of time really what's at play.

You need to know if your clients have cyber policies, you need to know the proce the process of doing that, just like you set up escalation trees with your clients on onboarding, you better find out what that cyber insurance policy is, who it is, and the number that's called. And the, the, the first thing you're gonna do is you're gonna ask your client in that event to contact their cybersecurity insurance or at least give them that option and to pull that trigger.

And then, so, but, but for you, does that mean you need to stay and do nothing? So if you have the, if you have the ability to, to stop an infection, you can take those courses of action. And what we always tell you is disconnect the nick. Don't shut things down, don't power things off, don't reboot things, just pull the plug because once you reboot or anything, these guys are operating so much in memory now once you reboot or shut down, all that stuff's gone.

And so, so there are actions you can take. Um, but you need to have all that, you need to be armed with all that information ahead of time. And then you need to have that conversation with your client too that says, Hey, if we're gonna do everything we can within what we do for you as an IT partner, but things, things happen, we don't have to go over everything. And if things do happen, here's the agreed upon process that you and I as your Ms P are gonna take.

And that's, and then, and then if it's a small client, that's probably as much as you can do. If it's a, a, a, a larger client, then you probably are gonna say, Hey, and let's go ahead and schedule an incident response tabletop as soon as we can so we can go through these motions and so we can all know and understand our roles and, and what what would happen in these types of situations. Mike, I have the plan. Do you want me to share it?

I, I think at this point, if you wanna just share the document, folks can go, go grab it. We've got, uh, okay, It, I, I put the URL in. I didn't know if there's anything in particular you wanted me to kind of just quickly share. And We were hoping that you would just read it word for word out, loud word with some, with some music in the background.

Chris, I wanna make one point, I mean, One scary thing about what you just said, um, on a cyber call in the last, I don't know, it's hard for me to keep track of time, uh, but months, we, we did a poll to ask how many people have had a conversation with every single one of their managed clients about their cyber insurance and Andrew, I don't remember the percentage, but overwhelmingly the answer was no. Yeah. So putting that in the context of what you just shared, Chris, that's a problem.

It is a problem. And it's just like, you know, hey guys, what, it doesn't matter what platform you're keeping track of your, your client certs, and when they renew and expire, you should be just as aware on their cyber policy as well, because when that renewal comes up, it's not your responsibility to renew it. But if they change the terms, they change the carrier, you need to be aware of it because you can't trust your client is gonna tell you, uh, un in an unsolicited fashion.

So, I mean, it's a very key piece because whether it's a ransomware event, which we kind of seem to focus on, but business email compromise is just as prevalent and there's so much of that stuff going on, and the money and dollars are involved and it's, it's in my opinion, almost even more embarrassing because what happens is these guys are getting in and flooding every contact within your client's email, uh, with emails. And so it's a, it's a much more difficult situation to explain.

And so that's why you need to be on top of these things. Yeah, That's, that's why Exactly. Chris, Chris, I did a really poor job trying to ask a question in the first session. I'm gonna try it again. But are there some certain prerequisites, for example, logging, you've talked a lot about, you'll walk into a situation and just be like, smack, you know, you'll, I'll be talking to you at 10 o'clock at night and you'll just be like, no, no information, I got nothing to go.

Can you, can you just kind share some key pieces? Because again, this comes into the people and process, right? That if they call in a company like yours, you need, you need some, some to, for lack of a better poor word, but data telemetry to figure this out. And most of the time we get called, there's none, right? And if there is some, it answers the questions more quickly.

So think about this, in today's world, it used to be when we had a ransomware attack, data got encrypted, we were pretty confident there was no exfiltration. It took us about, you know, three to four weeks to turn around the forensics report and people were happy we got them decrypted and all that kind of good stuff. Well, in today's world with exfiltration, there's a much, there's a much greater sensitivity. So for the most part, we know exfiltration occurs almost all the time.

So forensics has a lot more pressure now to get to the answers and to find out what was exfiltrated and what was not exfiltrated. And a lot of times we can say, yeah, it looks like the guy's got your D drive, they got, you know, 220 gigabytes of the D drive of server DC one or whatever, right? And then the client goes, well, I don't even know what's in there. That's everything, right?

And so the forensic guys have to get in there and they have to look specifically at what was packaged and what was let out and all that kind of stuff. So if you have logging that kind of points, the forensic, at least at a minimum points the forensics people to the right direction, that saves a lot of time.

And then if you have even more enhanced logging and even saves them more time so they can get those answers about exfiltration more quickly, especially when you're able to restore, because some clients may have data that if it's published, it can be very embarrassing or harmful. Now a lot of cases that doesn't happen. Sometimes you're just gonna have to live with it and notify. But in some cases, the data that the bad guys steal and published could really be embarrassing.

So the client or your client may be willing to pay based on what is what they, they have, well, if we can't tell what they have, the client's kind of in the dark and so they can't really make a very good informed decision. So, um, so it's super key. So yeah, you're right Andrew. I mean, we need to have server logs. I mean all those server logs need to be logged and they need to be, they need to be archived, you know, they don't need to be deleted.

Um, and I'm not talking about being able to access those logs live on the server 'cause these bad guys are going in and deleting the logs. We need those logs shipped to secure location and be able to access those firewall logs.

I mean, I wish I, I could probably do it, but it wouldn't be cool to throw out so many expletives about how many freaking cases we have where the clients have good firewalls, but the MSPs have not even turned on logging or they have it at such a short window where it rolls. It just makes no sense. I mean, that should be the number one thing because here's what happens with firewall logs. They're not the first thing we go to, but they are what we fall back on.

And so if the server data's not there, we can go back and look at the firewall logs and look at sessions and links and durations and all that kind of good stuff to help kind of minimize the possibility of what they took. But if there are no firewall logs or they've rolled it, it Yeah. And it's just, it's super, super frustrating. Right. And then the only thing we can fall back on then is ISP graphs and stuff. And that's a real long shot to be able to tell the story from them.

So, I mean, yeah, I mean, Andrew, I think, you know, we talked about instant response tabletop stuff, but you know, in the, in the, in the enterprise space, there are assessments done purely around what's being logged and what's not.

And so MSPs, you really need to think for this year, have that at the top of your list is a logging strategy, if you want to call it, for each of your clients based on their risk and be ready to implement that, even if it's some poor man's method of doing it and you can't do something sexy like we would want with a perch or something of that sim, uh, uh, something like that. Uh, you need to get something in place. Yeah.

And Gary, you know, just the right questions for differentiation, what we're hearing here, and you talk about this a lot on the cyber call, you know, questions around, Hey, just like Chris said, hey, if some of your, if your data got leaked, what, is there anything in there that literally could be, you know, reputation ending, business ending kind of a thing?

Do, do we need to be doing any type of data discovery as your MSP pulling a networks in here, do identification, classification, but thought, thoughts on that, Gary, that again, you know, listen, Andrew, everything that you're hearing, if you're hearing something that, um, Chris and Mike are talking about, and you either will make a change because of it or have to go check it 'cause you don't know the answer to it, they're, once you fix them, they're all paying questions in the sales process.

Because if you are not, and you're here with us, okay, um, there's a good chance that when you meet a prospect, Andrew, that when you ask those questions, you're gonna uncover pain and risk, man. Yeah, absolutely. Is that what you're heading towards? Yeah. Yeah, absolutely. I mean, you, you know, because, because again, you know, you and, and again, we're talking, you're bringing up a lot the MSP separating themselves these days.

Learning, you know, you know how you are arming your te team of MSPs to ask certain questions to differentiate themselves. Price being a differentiator process, being a differentiator. I mean, it, it's gonna be a, I just think it's gonna be a have and have nots as we go further and further into the era of assume preach. So that, that's why. Absolutely. And I saw in chat here, people are saying, Hey, to do this, right, where are you in pricing? 2 50, 300 a seat.

And so if you're, people are listening and you know, you're at 150, uh, or, or lower or when you go in to ask those questions, you know, right to what, you'll know what questions from this education where you can start to uncover, paint and build a wedge.

And, and you can also, this, this also gives you the ability to explain things and why, you know, you say, Hey, look, I'm, I'm presenting you this firewall, it's a little bit upsize for maybe what we would've done before because we need these added capabilities and this is why in these situations it's so key. So now you can start to tell that story around why you're doing those things. And also it should influence your architectural design as well.

So if somebody's saying, Hey, we're doing a server refresh or infrastructure refresh, or we're migrating to the cloud, whatever the case may be, you're gonna build that out into your plan, not as an option. You're gonna build that into that plan.

And so you're gonna have that additional capacity built in there, and you're gonna make sure that that additional capacity is maintained at the life of that thing that we see so many times where people have used up all their storage and then they get in these situations and they don't have anything anywhere to recover to.

And so you gotta plan ahead and make sure you stay on top of things and have that cushion, that buffer for logging, for restoration, for whatever the case may be, because it's real. No one can say, it's not gonna happen to me anymore, because there's a, a quadrillion examples that will prove that wrong. Chris. And, and, and as we wrap things up here, when you just talked about running outta, you Said quadrillion, Um, he was talking about our national deck here. All right.

So, um, Chris, but when you were talking about, you know, storage, you, you reminded me of a story you dealt with with a big manufacturer that had cranes and had, you know, a common storage mechanism that everybody in the industry uses. They weren't really keeping an understanding of the growth of the company.

And as Gary likes to say, they thought they had all the backups going correctly, but they were archived to the cloud, they really weren't getting done, and it was trying to suck peanut butter through a straw. Can you, can you kind of talk just briefly about the importance there of keeping in tune with the growth of your customer's data as Well? Exactly. Right.

So whether it's the, the backup appliance, the BDR appliance that you've had in there that they've outgrown or they're your inability to restore to it or run VMs on that, we find that a lot of times they have a, a great datto appliance as an example, but they've outgrown the ability to actually run VMs on a datto appliance, right? So it doesn't, you know, that doesn't make any sense. And the other part is, is, is being able to restore in a timely fashion, right?

It's great when you and I explain this all the time to, to fix, it's great when you do to cloud, but if it takes three weeks to three months to get your data back, that's a, that's a crazy deal. One of the first cases we worked, they actually had their data over in another data center like three or four states away. And, uh, one of their, their MSP at the time made his own independent decision to load those servers on a plane and fly them to the main site.

Fortunately, the owner caught wind of that and said, no, stop. And the MSP was like, why? It makes like the logical sense. He goes, no, that's my only copy of data to my company, and you're putting it on a plane. I, that's too much of a risk for me. You keep it there and we figure out another thing.

So it's a great example right there of making sure you're on top of things, you know, technically how things are working, and that from an IR perspective, that you're clearly being, you're informing the client of what to do and you're, and you're making those decisions too often. As technical people, we start swinging the sword and we can't swing sword in these types of situations. You gotta know what you do 'cause you swing the wrong way. There really is no way to revert.

You're, you're kinda screwed. And a lot of plane engines seems to be on fire lately. That's Right. That's right. Well, Chris, Mike, um, fantastic job as always. Um, and, and through our audience, love your engagement enthusiasm, Gary. Always think of the commentary. Um, just some housekeeping real quick again, um, I will end this session. Don't go anywhere. Um, let me talk about who's up next. 'cause this is, I'm, I'm very really excited about this, but stay where you're at.

I'll end this session. I'll pull everybody in. But next session. Um, the beards, the beards, we're doing a little different this time. Historically, when we do events, we have an, uh, a capture the flag event going on simultaneously, highly competitive, et cetera, et cetera. And we pulled a bunch of, of, of, of you all that have been with us for a while and said, what are your thoughts on if we had a teaching session?

How about if we bring in some of the brightest and best to teach you and bring in your technical team? And so we're gonna have Jason Slagel, who I think has won everything, um, who, who's, uh, just phenomenal. Um, on the red teaming side, um, probably blue teaming side as well. He knows, he knows both. And, and he, uh, is the VP at CMWR. Um, will, will have him introduce himself.

We'll also have Bryson Medlock who ran training for the Alert Logic soc for many years and is a great red teamer as well. They're gonna teach vulnerability management and vulnerability exploitation today. Um, again, think of literally even at a 1 0 1 level, don't think it's, oh gosh, I don't know about this. Please join us or bring in your technical team. Gary, any closing thoughts before I end this one? Pull everybody into the next one.

No, I want to just thank Mike and Chris and, um, you know, Mike, um, for you, you're in a role. You have a busy job. Uh, you, you have nothing to sell, uh, and you give us your time on the cyber call. You share the things you have to help the industry. I just, I just gotta say thank you on behalf of our industry. Yeah, Absolutely. No, thank you. Happy to be here. Yeah, Mike, Chris, thanks as always, my friends.

And, uh, we'll look forward to having Chris back tomorrow with Wes as we actually walk through a tabletop. All right, so sit tight right where you're at. We're gonna end it and pull everybody back in. Make it a great day, everybody. We'll be right back. Thanks everyone.