Session 1

Welcome, everybody. We are back at it. I feel like it's, I'm ready to say the cyber call, but it's not the cyber call, it's the incident handling workshop with some really very special folks here. Chris Lair, Chris Sears, and Noam Morganton, who's new to a lot of you, probably, but not new to Chris and Chris. We'll explain that later. Um, just kind of, uh, my goodness. There's buzzing and beeping going on here. I thought I, my Mac I bear with me, everybody.

I'm just turning all this stuff off because it won't, it won't stop. Yeah, I, I had faith in you, Andrew, but it's gone now, man. I went to preferences. Turned off notifications. Nope. Dinging doning. Anyway, welcome everybody. Alright, so kind of a little bit of an abstract. Um, we'll do some introductions. I'll set the stage and then we will get right on into it.

I'm excited about this one because from an abstract perspective, Chris, we're gonna, um, by the way, I'm gonna call them by their last names not being, uh, derogatory, but we have Chris and Chris. So I, we will go by Lair and Sears, but, and I were talking this morning, we did a quick video that really, you know, what a dynamic change over the past few years for MSPs. You know, gone are the days where, you know, you cared about your, like your number one metric was customer sat.

Now, I'm not saying customer sat is an important, but your frontline help desk people have a very different job today than they did 3, 4, 5 years ago. Um, so everybody in this MSP world today is in an incident handling role. Whether you think you are or not, you are incident handlers and how you handle incidences as, uh, lair is gonna talk about, um, who's very in depth and, and in terms of, um, litigation insurance companies, what happens when things don't go right.

We'll be talking quite a bit about. So from an agenda perspective, we're going to discuss the evolution of MSP incident handling. Chris Sears, I'm gonna really, uh, grateful for him coming on because, you know, he's got a decent sized MSPI think 70, 80 or so people, they've evolved quite a bit. They are doing incident handling to a certain extent. And so we wanna understand from an MSP's perspective how that evolution has taken place.

From Chris LA's perspective, we're gonna work through what are the best practices. Um, and you know, we're gonna go through literally when there's multiple parties involved, what are those best practices and processes that ideally should be in place and what happens when they're not. Um, and then the reason we have Noam on with us is, uh, he's a founder and CEO of a company called Exigence, which, um, Chris Lahrs organization uses to handle all his incidences.

Chris Sears is in deep into a POC of it, and we wanted to get your opinion at the end, open q and a. Um, your thoughts on this platform, is it applicable to MSPs as a whole? Um, so that's what we're going to do. And then by the way, Chris Layer is going to show how he uses it. So we're gonna look under the kimona, if you will, of what it's like to pull in multiple parties into an incident, um, and the effectiveness of that. So let's get right on into it. I'm gonna start with Chris Sears.

Um, Chris, you know, can you talk a little bit about how your MSP has evolved in terms of, you know, getting comfortable with incident handling? How did that occur? Um, you know, if you could maybe just walk us through that evolution, that'd be awesome. Yeah, thanks for having me on here. Of course. Uh, so when I started, we were really small. I've been with Applied Tech for a long time, like over 19 years now. So we were about five employees when I came on.

Um, like most small companies and MSPs in general, we had a lot of process, but it was always in somebody's head, right? It's whoever kind of owned that process, it was in their head, not a lot on paper. We got better as we grew, but still incident response, you know, wasn't top of mind for us. And, and we didn't really have a great documented process to follow. As the company got larger, we started pulling more people into that, right? Anybody from our knock may be involved with an incident.

It was very important that we had a repeatable process that they could trigger as soon as there was a security concern and, and have that be consistent and repeatable across our customer base. And no matter who, you know, was involved with handling the incident initially, um, a few other drivers of it, as we've grown our company's worth more, there's more financial risk for us and our board and the owners, right? If, if we get things wrong as part of incident handling.

Um, also our customers are larger and, uh, more complex, which can lead to, you know, uh, incidences that, that are tougher to handle and, and have more moving pieces and parts. So again, having that process to rely on and not try to do all of this on the fly, uh, is really important. And then just the nature of threats have changed. Um, the, it's become more complex. Back in the early days it was just, uh, you know, a virus infection, malware, it was basic.

And then we started get getting Crypto Locker, uh, a lot of business email compromises as people move to, you know, primarily Office 365 and, um, and now exfiltration data exfiltration and having to worry about that ransom on the backend even if you have good backups. So, you know, all of those being said, we, we had to do more around this and that's what drove us to, you know, spend more time thinking about this and putting more structure in place. Yeah.

And Chris, you offline, when we were kind of getting ready for this webinar, you even talked about EPHI and the fact that you have regulated customers. Can you, can you talk a little bit about that just from a concern of, of, you know, you could do everything right, but, you know, with exfiltration, et cetera. Yeah, so our primary regulated vertical is in the HIPAA space.

And, uh, it's definitely important to understand the difference between an incident and, and a breach and how you determine that. And, uh, focusing on things like evidence preservation so that you can do a proper investigation and, and figure that out. 'cause the reporting requirements are different if, if you can prove an incident versus a breach.

So having somebody on the team that understands all that nuance and, and thinking about that from the very beginning of an incident and having that drive your response is very important.

Um, we do, we we're starting to get more into NS 801 71 and, and now CMMC and they're certainly reporting requirements and, and instead of EPHI, um, but you've, you've gotta understand what regulations apply to the customers you're working with, uh, and make sure that that is driving your decision making as, as part of the process as well.

Chris, I'm, I'm curious, do you talk to your customers, you know, we, we use the term write of boom a lot, but about incident handling, do you talk to them about ir, policy planning, tabletops? Like are they, how, how does that go? And, and, you know, 'cause I I think a lot of MSPs want to know, there are some Ms MSPs, like Mike Beard talks a lot about, like, they sell a lot of right. Of BOOM services. Yeah. And so I'm just curious from your perspective. Sure, yeah.

Especially with our regulated customers, we definitely have those conversations. Talk about things like sim tools and EDRs things that are gonna gather that data, right? So that if you do have an incident, we have actionable data to, to do a forensic investigation on. Now, I would always say we don't perform an actual forensic investigation.

If we get to a point where we feel like sensitive data may have been accessed, we always start that conversation with the customer of, do you have cybersecurity insurance? Now might be a time to reach out and, and start that process, right? Because then we can get a breach coach involved. We can get a, an actual forensic investigation company involved, probably a legal team involved for legal guidance. 'cause we never want to give, you know, legal, uh, guidance to our customers.

That's not our place. Um, but that's kind of the trigger for us is once we see that maybe any sensitive data has been touched, you know, engage and get more people helping us with this process. Yeah. Well you, I, my my head's going towards a, a bunch of things right now. I'm not gonna start touching on data flow diagrams and things like that, but man, really applicable in terms of sensitive data and where is the data, et cetera. Um, one follow up question, and then we'll go to Chris Lair.

Um, so, um, I, I work for you Chris. I'm on frontline help desk. Can you talk about policy in terms of how do I feel comfortable, you know, working something and going, Hey, I think this, I think this might be more than just a help desk issue. And can you walk us through how you guys have changed the culture Sure. And allowed people to kind of have safe harbor, if you will, no matter what is going on.

Yeah, so when, when we onboard new techs, um, there's two different training sessions they'll sit through with me. Um, one's gonna be HIPAA specific so that they understand the risks to our organization and proper handling of, of client systems and, and, you know, that may contain EPHI.

Um, and then just another one that reviews our entire security stack, what we sell to our customers, what we have implemented internally and, and key, you know, a key repeating topic and all of that is if you see a, a security concern when you're working a ticket, you need to start our incident response process. Um, which the, the main focus for that is getting the right people in the room to talk about it.

Because these can go on so many different tangents technically that it's impossible to try to document, you know, a technical response to everything. So you've gotta have people that are aware of the risks to the organization, aware of the risks to the customers, and, and have those people involved right away. Um, and, and we, you know, never push back.

If somebody opens it up, even if it's like a, probably a spoofed email, we still wanna look into it, we'll hit Officer 65 and we'll look at the logs that exist, look at sign-ons, just see if anything's suspicious is there. Because we don't wanna brush something off and say, nah, that's just a spoof. We, we don't need to worry about it. And then it comes back to bite us, right? Because then we're negligent. We, we knew there was an issue, we didn't dig deep enough.

So for us, we always err on the side of caution and, and investigating and making sure we're all comfortable with the determination that nothing bad happened here. Um, and, and we reinforce that.

And then as a, if a new tech is picking up, like, let's say a business email Compromise ticket and they haven't worked through our incident response process before, we will team 'em with somebody on the frontline that has, um, because we'll usually have them, you know, they're like tip of the spear reaching out to the, the end user, resetting their passwords, forcing sign out in Office 365, getting 'em reset up and, and, you know, reconfigured again, uh, doing the data, the, the log gathering for our, you know, more technical people to do the ana, uh, analysis of the logs.

So we, we do shadowing so that they, they don't feel like, oh my gosh, I'm, I'm out here by myself trying to execute this plan, right? We're all in a dedicated teams chat, giving them support, and they're, they're partnered with, um, somebody who's been through it before. Yeah, really cool. Really, really. Yeah. I have a question for, for Chris.

Is, uh, since you, you know, worked, you know, so many healthcare clients, typically, who do you find on your client's side that you're working with on these particular cases? Is it the quote compliance officer they have, or is it the CEO or whatever? I mean, who, who have you seen, I mean, who do you work with the most on the client side, and are there some examples of where things are more effective with some clients versus others? I, I think it's really all over the board.

A lot of our, uh, regulated customers are on the small side. So I would say they, they don't have, you know, like the security officer and the privacy officer are the same person in most cases. They don't have these roles split out. They're not large healthcare organizations. Um, so it's really a mix. It, it tends to be our, whoever our primary point of contact is anyway.

And then if they do have a, a dedicated security officer or privacy officer that is someone else, they'll definitely be looped in. Um, and then usually when it comes to a regulated customer, we're a little bit quicker on the draw of saying, let's get cybersecurity insurance involved. You know, talk to your agent and, and start getting their guidance as well. So then they're in the loop. But we do it for all customers.

We have that primary, if there's a security incident, you know, what's the primary point of contact if we have reporting requirements within our contracts with the customer, what are those? Do we have, you know, a day, three days, seven days to evaluate an incident before we escalate to them? That's all spelled out in our agreements and, and documented, uh, in our PSA.

So, Chris, uh, Larry, you work obviously with a lot of MSPs, you, and, and obviously a lot of incidences, um, by the way, I, I didn't, I just realized maybe I could just take a quick pause and apologize to everybody intros, so I jumped right in. So not everybody knows you two. So let me, let me just pause, Chris, and I'm gonna a and Chris Laer, and I'm gonna ask you for an intro, then I'll come back to Chris Sears and Nome.

But, um, Chris, the question I'm gonna ask you, but let you do your intro is, you know, setting up an incident response plan, because we heard Chris Sears say specifically process has to be repeatable. So I'm gonna, you know, kind of list off some things that I want you to talk through that, you know, MSPs probably haven't considered a lot, um, up until, you know, the last year or so, and hopefully they are considering these and building and putting it into their IRP.

So Chris Lahr, who are you, and tell us a little bit about you. Sure. Uh, thanks Andrew. Chris Lahr. I am EVP and CTO of a company known as solid security based out of Austin, Texas. We are an incident response and managed security company. Uh, we're just almost 20 years old. Uh, a few years ago we were acquired by a London-based, uh, business liability insurance carrier called CFC. And CFC is, is really known for, um, cybersecurity policies.

And so, uh, as actually two years ago, we started with them three years ago and acquired just a little over two years and two months ago. And so I spend, uh, I do a lot of different things in my daily life, but the majority of the time I do spend, uh, working incidents and our, our, the population of people that we work with fit in the SMB space. So we don't work really rare. It's where we work any kind of mid-market cases and on up to product. So we, we align well.

And when Andrew talked about, you know, we did, you know, work with MSPs, I mean, you know, 99% of the cases we work with an SP is involved some way, shape or form.

And so, uh, whether the, there's an MSP associated with the, the case that we're working on, or if it's a case that's somewhere in the country where we don't have bodies, uh, we, we call upon, uh, MSPs to help us what we call boots on the ground, help us do some things that we need to done, we'll be done, whether it's recovering, deploying software or, um, you know, pulling forensics for us. So, uh, yeah, see, I've seen thousands and thousands of, of cases over the last three years.

And just like Andrew started out today, uh, it's, the change has been rapid and, uh, a lot different than it was a few years ago. I mean, I remember three years ago, we were able to, uh, get a case, negotiate the ransom, pay the ransom decrypt, collect forensics, and the people were back the next day up and running. That didn't work anymore. So there's no cases that fast. So, uh, a lot has changed, but that's, that's my background. Yeah. Awesome.

Okay, so question to you, and then, like I said, we'll intro each person as we go around, Chris, um, some things that, you know, I think about, and, and I'd love for you to expand upon this. So when do I call, you know, if, if there's a suspected incident, when do I call, you know, the cyber insurance carrier? When do I call breach counsel? External communications and pr incident response forensics? Uh, when do I notify my customers? What do I tell my customers?

Um, you know, and you know, one thing I I'm wondering about, you know, just in general, and I think a lot of MSPs and talking to, like, when do you call, Hey, enough's enough? You know, I'd love Chris Sears comment on this too, but, you know, I remember Ryan Weeks on the cyber call saying, Hey, if it's, you know, 24 hours as an example, this is, he was, you know, just spouting up. But if it's 24 hours and you have nothing new, you probably waited too long.

Um, you know, so can you kind of expand upon what should be in an IRP? How should it be used? The processes MSPs need to start following why all those, these questions are critical now. Yeah. So when, when Sears was talking about the, the tactic they take with getting cyber insurance involved as soon as possible is, is really the, the right way.

And I'll, and I'll talk about that, I would say a few years ago, even though the policy requires you to do that, the carriers were much more lenient about that, right? So people would say, Hey, yeah, well, we did this and did that. Then we figured out we had an insurance policy. So we called you guys a few days later, a week later, hell, sometimes it was a month later, right? And people were fairly, I guess, agreeable to that and, excuse me, didn't put up a fight.

But in today's world where there's a lot more claims and the claims are much higher in terms of what has to be paid out, uh, the insurance carriers are starting to, you know, follow policies more black and white. And most policies do say that you need to notify them immediately. And then the other key piece is, is that you need to get their approval before doing anything else going forward, or you're not going to, those things aren't going to cover you.

Uh, so that's really important to have them, you know, upfront. Now, there are, there are some exceptions. Uh, you know, we have people that are like, look, I don't necessarily want to call my carrier every time. Uh, there may be a situation that we want to maybe assess and we're fine with that. We'll pick up the tab because we don't want to necessarily pull the trigger on a claim every time.

And, uh, so they might do something like an instant response retainer or something like that to cover them from that side. But that's, those are more the, the exceptions than not the rule. So I would say, uh, even if it's, um, even if it's something that doesn't affect you directly, for example, in the news has been that this big Kronos ransomware attack and Kronos is a time, you know, a time clock record, time man, uh, whatever you wanna call it, workforce management platform.

And so even though that's not a compromise of you directly, people are still calling in the insurance claim because they're being affected, whether it's a business interruption loss, whether it may be employee data, whatever it is, they're making that call, even though there's technically nothing we can do, the legal sides of things can happen.

And so that's the next part of things is to say, you typically don't need to call attorneys and PR firms and all that, those things, because those are all handled with the cyber carrier. So they have done, they have a process behind the scenes where they vet and establish rates and everything with law firms, and the law firms know how things operate within that carrier. So that's very helpful.

One question that always comes up is, well, is that law firm working for the carrier or working for the, the victim, the insured, and they're always working for the insured. They're directly engaged and work on behalf of that. Uh, and then you have, uh, and then if, if a PR firm needs to get involved, the law firm's typically going to, you know, find that firm or have that firm get the approval behind the scenes from the adjuster, and then bring them in if necessary.

And the same thing goes with notifications, right? Your, your attorney in this case, what we call breach coach, breach counsel, whatever we, we say, let's just say, we'll use Breach Coach today.

The breach coach is gonna be the one that helps with the notifications, is gonna be the ones that put together the note, uh, put together the notices, and most of the time, they're the ones that are going to reach out and determine which of the different companies out there that handle notifications is going to handle it. And then again, get approval from the adjusters.

If you have a, if you have a client that says, Hey, I want to go choose my own and do all those types of things, I could just tell you it's gonna be a, a a bit of a nightmare. They're gonna have to go back and forth with the adjuster a bunch of times. Uh, for example, they might say, well, I have this, my own attorney that I want to use in these matters. The attorney's gonna say, well, my rate is $700 an hour, and the insurance carrier might only pay $500 an hour.

And so those things you're gonna have to deal with about that. The other thing you have to be thinking about, and, uh, it's one of these things that a lot of people don't, you know, they ask the question, do you have cyber coverage? The other thing is, is how much coverage do you have? And this is really important for you to know it's an MSP for your clients. There's two things. Number one is, you know, what's the amount of coverage? And number two, what is the deductible?

And number three is, are there any exceptions in that policy that would have some effect on that coverage? And so, again, if you'd asked me this a few years ago, I would've not had to tell you all this stuff. But, but in today's world, the carriers are starting to have certain requirements for you to have in place in order to be covered. And so if you have a claim, and let's just throw MFA out there, and you said, yeah, we're gonna have MFA enabled. Okay, great.

And then you, you, you, you go through, you have a claim, and guess what? You didn't have MFA enabled, or it was only half enabled, or whatever the case may be. There may be language in that policy that says, well, you might have had $2 million in coverage, it's gonna be cut in half to a million.

So those are things that are, are very good to know, because like most MSPs will tell you a lot of times when it comes up for contract renewal from their insurance policies or policy renewal, it's a great upsell opportunity for them because there's usually requirements in there that, you know, have to, that bring the MSP some work to do. The other, the other piece of it is the deductible. And this is super, this is, a lot of people miss out on this.

Most people have, sorry, oops, sorry, I'm having trouble hearing you. Sorry. The, um, the deductible can impact your client's mindset. So if it's, most people have small deductibles, 2,500, $5,000, we'll even call $10,000 a smaller deductible. But if they have a higher deductible, like $25,000 and up, your client starts thinking more less about what needs to be done and more about how much money they're gonna have to spend, and they get into pinchy penny pinching mode quickly.

And, uh, you, you gotta just be aware of that. So if you kind of ahead of those types of things, and you can say, Hey, client, I realize you have a 25,000 deductible one one of these. If the poop hits the fan, you need to be focused on doing the right thing from an instant response perspective and not, you know, pinch and pennies. Uh, that's an important caveat as well. But again, your, your policy is going to give you those experts.

They're gonna lay those things out for you if you try, if somebody tries to go their own route or their own path to bring their own people in, uh, it just gets kind of really, it can get ugly from a coverage perspective. Chris, uh, you know, you, I'd like to just come back real quick to MFA. I'd like to ask you the question, jump to Chris Sears, have him introduce himself and ask Hi him. Answer the question.

You know, we've had Eric till on quite a bit, you know, the, the former chief legal officer for Logic Callus, who, who now helps a ton of MSPs as a chief, you know, fractionally. Yeah, he's awesome. You know, he, he mentions a lot, you know, if you're in a court of law, you know, like you're saying about MFA, but it even goes beyond that. Like I think a lot of MSAs are need to be revisited in just because of all the changes.

Because from what I understood, and this is what I wanna ask you to confirm or deny, you know, in a, in the, in the sense of a, of a, you know, a, an attorney growing an MSS p, they're gonna say, okay, who's responsible for the MFA? And if it's not spelled out these days, well the client's clearly responsible for MFA, we've agreed on that. It's in their SOW or et cetera, et cetera. Can you talk a little about that in terms of, you know, security controls these days and how they impact cyber?

Uh, yeah. So, so, so one thing to note is that there's gonna be inconsistencies from one carrier to another. So you may have a client that has a policy with carrier A, you can't assume that the policy with carrier B is gonna be the same, and they're just, it's, it not to sound like a pessimist, it's just not gonna get there, right? I mean, they're not all gonna get together behind the scenes and say, Hey, let's make all our policy language requirements the same. It's just not gonna happen.

It's a big giant industry. It's been around for, it's one of the oldest industries around, and it moves very, very slowly. And so it is, like, I, I was on something the other day and I mentioned that like cyber policies is one of the newest policy types out there. It's 20 years old, but it's like, it's really kind of considered, you know, a newborn in the insurance world. And so, so you have to be thinking about in terms like that.

But, but when it comes down to these, these requirements, it's, it's, it's, it, it's good to stay on top of them. And it's good to understand, yes, who ultimately is responsible for it. And, and then that's very clear. So if it's in the contract, uh, that gets you a long ways there. But you also need to make sure, and this is where it gets a little tricky, right?

Because you sign a, they sign that MSA one time and maybe you've updated when upon renewal, let's just say it's a three year deal, and they've signed their MSA and they're two years in. There's a lot of stuff that can happen in those two years and so on.

On the other side of things, you need to make sure that you're doing the CYA things and to make sure that if a, if a client says, look, we're not gonna do MFA, or we're only gonna do MFA for this, these amount of people and not for our entire organization or whatever, that you've clearly articulated that. And then that you have that document, and I know some people have done it in tickets, some people have done it in emails and put it in tickets.

Whatever it is, you need a safe place to put that, and you need to know where to have that. Uh, and, and, and, and there's some people that do a great job of that. And then there's some people that are, are, are kind of, uh, kind of, they, they don't think about it as serious as they should. The the, the other thing that I've seen, which kind of happened by accident is I've seen MSPs and, and I've been on a few of them with them that do podcasts or, or whatever, right?

That maybe video podcasts, whatever it's, or they do webinars on a monthly basis or whatever. Those webinars can be a way for you to prove that you're communicating to your client base about security controls. So one of the things that a lot of people now remember, sometimes when these things happen, uh, your, your, your client that you've, that's been loyal to you for years, could turn on you on a, on a dime, right?

They could instantly go, well, those guys never told me about that, or We never discussed that in any meetings or whatever the case may be. It's, it's amazing how quickly somebody will, will blame someone else in these situations. And so the idea behind that is, is you gotta be prepared for that. And so having, so like when people are, they wanna do a webinar and then this month's webinars on MFA and backups, whatever, just throwing a couple of things out there.

You've invited, you've targeted all your clients, they've either accepted or didn't and they've either attended or didn't, but in your description, and when you send the in invite out, you talk about those things. So somebody says, Hey, I never knew about that, or You never told me about that, or whatever. You can say, well, here's our, this is the opportunity. We had to discuss this with you. So we tried to discuss it in A QBR, you don't remember that.

But we also had these free educational services. And, and, and same thing with, you know, in the bank from a regulatory perspective, you're required to put a bunch of that puffy educational stuff out there, security awareness stuff out there, because the bank regulators do that. Well, in the MSP world, we don't have regulators telling us what to do. But you can lev leverage some of these marketing things that you do.

I don't wanna call 'em gimmicks 'cause they're not, but marketing tactics that you use, you can use them to demonstrate education and awareness to your clients. And, and then, and then if they still decide to forego on the security controls that they should, you now have multiple layers of evidence supporting your side of things, saying, I, I did inform you and educate you, or at least I attempted to, and you just decline to, to watch, listen or whatever. Perfect.

So Chris Sears could halfway through here, could you introduce yourself? What what a hor horrible job I did here and I apologize. Just change it up, man. It's all good. Change. Yeah. I'm the, uh, chief Security Officer for applied tech or an MSP, uh, headquartered out of Madison, Wisconsin. Um, our goals in the future here are to grow very quickly through acquisition.

So that's, you know, part of, we'll talk about, you know, why I want exigent exigence in place moving forward as, as we grow and get even larger. Um, uh, yeah, I've been with the company for, you know, like I said, 19 years and, uh, seen a lot of growth and, and change over that time. That's awesome.

Um, so Sears, can we talk a little bit about left of boom, how you think about roles, responsibility and, and for those, um, that have, you know, not heard of, right or left of boom, it, it comes all just real quick. All the way back. It started with nuclear war. So anything prior to dropping a nuclear bomb was preparing for that incident. If the obviously incident happened, it was everything that postmortem and that would, you know, you'd be responding and recovering from that.

And then the military took it up and then eventually cyber took it up. So if you think about CSF and the CSF, identify, right, protect, detect, think about midway through detection. Anything left of that is really your preventative, your identification preventative type things through detection. Once you detect something and there is an event there, something has occurred that's considered boom and left of that, your more people process function is gonna be right.

So, Chris, sorry for, so sorry I didn't interrupt and just give that, I just didn't wanna assume everybody knew that, but can you talk about how you guys look at roles, responsibilities, those things again? 'cause they're critical to this? Definitely. Um, so, you know, with our size, it gives us the flexibility to split roles out and, and have them covered by more specific people, which is great 'cause they can dig in a little bit deeper and maybe be more educated in that area.

You're, your smaller MSPs aren't gonna have that flexibility and people are gonna wear a lot more hats. And that's, that's normal. And we went through that. Um, at this point, you know, we've identified, uh, you know, for every incident we want a technical decision maker that's gonna be somebody that understands the tech, understands the security, but also understands, you know, the risk to the business. That's the key. They've gotta understand kind of all three things.

Generally that's going to be myself, uh, when we're in an incident. Um, then we're gonna have a, a business decision maker, and that's usually gonna be our CFO or our CEO. Um, and they're most of the time going to take my recommendation. But as we're going through an incident, I'm always looking for, you know, what's our exposure here, right? Not only on the customer side, but did we, did we mess up, right? Are, are we negligent in some way? Did we, should we have caught this sooner?

Were we aware of it and we brush it under the rug? Did we misconfigure something, right? Is there possible risk to our organization where we wanna contact our own cyber insurance carrier and, and start that process and start getting legal guidance and, and all of that? So if I see there's any concern there whatsoever, I will bubble that up to the, the CFO and the CEO.

Let them know, you know, here's what we know as of right now and let them make that decision ultimately if they wanna, you know, start that process. Um, then we have a security lead, so that's gonna be somebody from our security team. Um, or you know, we pull a few other people, um, that are just really well versed in like, um, pulling Office 365 logs and auditing 'em for suspicious activity.

Um, we have somebody in that role that'll help with, you know, again, I don't wanna say a forensic investigation, but evaluating all of the, the data that we do have, um, and again, trying to provide the best recommendation to the customer. If we're at a point where, you know, starting that cyber claim makes sense. Um, we always loop in the account manager, obviously we want to have them involved from the beginning so you know, they can manage the client relationship.

Um, and then on the variable side, it's gonna be whatever tech happens to have picked up that ticket. And then if we have that shadowing happening that I talked about, um, if it's a larger incident, then we wanna pull in a non-technical coordinator role. So somebody that's going to coordinate assets both internally and we have a lot of large co-managed customers where they have internal IT staff and they may assist.

And that can get a little sticky when you have lots of different people in a major incident all trying to, you know, work together but with different ideas. So you really need, um, somebody ideally with a project management background, that's who we use internally as our project manager would step in and, and be that coordinator. And then, uh, corporate communications.

So if we need to send out updates internally, if we need to send out updates to the customer, you know, who manages that platform because that can be a whole, you know, thing on its own right? Trying to get a communication out to the appropriate people and at the appropriate scale and with the correct verbiage in there.

So we, we've kind of identified all of those roles in our, um, documented process and then as necessary we pull them into that dedicated chat that we start, um, when uh, when we become aware of a security incidents. Yeah, and we'll be talking more about that with Noam shortly as Chris walks through that, why that's so critical.

Um, Sears, can I just maybe just riff on one thing just a little bit 'cause I'm gonna lead into back to Chris Lair 'cause Chris is gonna talk about, you know, when an incident does occur, there's kind of two routes an MSP can kind of take. How do you communicate when you think something really, you know, occurred? How do you communicate to the customer?

'cause I think, again, this, if I'm an m ms P and I haven't done this a lot of times what you say when you say it, how you say it all and how you deliver it, right? What median, right? Is it in your, are you documenting in your PSA maybe, hopefully not, right? Those types of things for attorney-client privilege. But can you talk the nuance of that and 'cause I think it's really critical. Sure. Yeah.

That was a, a hard learned lesson many years ago that you, you really need a central point of communication, right? You want all communication to the customer or any other external parties to run through a consistent person, right? So you, you're, you know, what's being communicated, it's gotta again, be a person that understands the nuances of, you know, the technical incident as well as the risks to your business plus the customer.

Um, you do not want that to be that lead tech who picked up the ticket, right? You don't want your desktop or even your server techs. Just don't put that on them because they, they're focused on providing good customer service, hopefully. And, um, you know, and, and the technical resolution, right? Which in their mind might be grab that server, wipe it, restore from backup in your backup and running.

They're not thinking about evidence preservation and they're not, when they're communicating to the customer, they're not thinking about, they might say something because they, they're just trying to put the customer at ease, but they could actually be opening you up to some sort of risk, at least in the customer's mind, which then could lead to, you know, going down a legal path that you don't want to go down if you don't need to, if you're careful with your communications.

So, you know, that's a big thing for us is it's, it is gotta be our account managers or you know, myself, the CFO, the CEO somebody, right? Somebody at a higher level that has a little bit more business acumen, I would say, needs to control that conversation. The tech, if they're communicating anything, it's just, here's your new password, I've reset your password, I've unlocked your account, right? Basic technical communication to the affected users. Nothing about the, the bigger incident.

Um, so that's, that's key for us and, and a really big part of our process that we, that we drill into our entire team. Yeah, I'm, I'm kind of chuckling internally 'cause I've had the pleasure to sit through so many of Chris LA's, uh, tabletops, which he'll be doing at, I put the URL right? A boom cyber summit, which he'll be doing best practices of a tabletop, uh, at that event.

But Chris la amazed me chuckle about how, you know, the, the emotion that you can see in the heat of a battle, especially in our m breach, um, it's, it's a pressure cooker. Um, yeah, Couple key things just to touch on is, you know, I heard a long time ago, if you don't wanna be sitting in, in reading your words in open court, don't put it, you know, down digitally, right? Don't put it in your teams chat, don't send it an email. Stick to the facts.

Do not, uh, you know, this is not a time to be throwing out, you know, assumptions and, and conjecture and all of that. You really wanna stick to the facts, especially when you're communicating to that customer. Um, you don't want to talk about what you think may have happened. You wanna say, here's what the log show, make your decisions based on the evidence we have available, but really be careful what you're putting down digitally, because that all gets backed up and saved somewhere, right?

It's, it lasts for a long time longer than you might think. And you, you never know when discovery might occur and you wanna know what's, you know, gonna be included in that. Um, and and Just like that bad tweet, like that bad tweet, right? Yeah. Like that bad tweet you said five years ago, come back to haunt you one day, Lair. So talk about when an event does become an incident, what you that talk about the kind of this path forks in the road that can Happen.

Yeah, so that's a, that's a good point you bring up. So really, uh, it comes down to what role as an MSP you want to play and the scenario that gets presented. The, the answer may not be the same for each scenario. There may be some times there's been cases where the, the MSP that is involved is like brand new. Like they said, we just took over this account last week or last month or whatever, right?

In that situation, they may want to distance themselves a bit because they really just don't have that trust in that relationship enough to say, Hey look, we wanna do what's right here, but we do not want to come across as, uh, potentially being an a scapegoat in this thing either, right? So those are some things you have to be thinking about. I mean, I have, I have a ton of cases where the MSP's, like leway, we just took these guys on, they got hit with ransomware.

Uh, we're gonna, we're gonna do what we can, but we're gonna follow your lead, uh, the IR company completely. So we're gonna listen to you and you exclusively during this process. We're going to, we're gonna tell the client that so there's just no gray areas or whatever the case may be. And that's that, that's fine. I think that's a very legitimate and logical way to be thinking about things.

Uh, the other side of things is, is what you have to be thinking about is what part you can play technically and where you don't want to be. So you've heard Sears talk a lot about the forensic side of things and how they stay out of that. And that's very important. I'll tell you why. Uh, I'm not a forensics person, nor will I ever be. Uh, forensics people are very analytical in nature and they do a very good job.

And what I tell people when it comes down to what you need to understand about a forensic analyst is that it's very similar to what you would have with some type of architectural or engineering drawing where somebody's putting their stamp on it and basically signing their name to it. And so forensic analyst as a whole, in ours especially, uh, are very, very, um, territorial when it comes to that in a good way.

So when they're doing things and they're going through their process and they're vetting what they've done and they're doing peer review and all those types of things, when that finally does get put to paper and the only time they put things on paper is when you have to put something on paper that it's, that it's there and it's accurate and it's correct.

And if you try to play that part, and if you try, I took a class or I went to whatever and blah, blah, blah, the risk is greater than the reward. And what I mean by that is if that thing goes to litigation and you are the person that gets called up to, to kind of discuss or who, whoever did the forensics and you are not a forensics person, the attorney's gonna roast you. I mean, it's just too easy.

You don't have the background, you don't have the experience, you can't kind of speak to it and all those types of things. And so you definitely want to have somebody that's been down that road that knows what they're doing and that, that has experience is super important. In the forensics world. You can go to a class and I mean jack squat, right? It's helpful, don't get me wrong.

But knowing the experience, how to deal with the attorneys, understand what the attorneys want in writing, understood what they don't want in writing, understanding what things you can say, what you can't say, uh, when you can say things, when you can't say things like, right. And so, you know, a lot of times I have to step in because I know my forensics people, maybe it's mid, it's mid analysis and my friends will be like, well, we're not done yet.

And I understand they have kind of this, Hey, we wanna do it. And when we're done and we put everything in black and white, it's ready to go. And they don't wanna say anything that, um, maybe wrong or, or or anything like that prematurely. And I understand that. So sometimes I have to step in and I just say, Hey, look, at this point in the forensics investigation, we have not seen anything that we are not expecting in this type of ransomware attack.

I, I'll say those types of things because I can, but, but the forensics person's never gonna stand up and do it because they're very, very facts based. It's if you, if you're really old school, just the facts, ma'am. I mean, that's, that's exactly what it's all about. So that's really important. So when you're an MSP, understand what you can do and what you're willing to do and just, just be willing to cooperate.

Uh, it's interesting because I would say, and I uh, I really haven't dug too much into this, but I would say over the last six to nine months we've had a lot more situations where the MSP was adversarial and is just slow walking things or behind the scenes is, is talking to the, the client and telling them something different or trying to dissuade them from doing something or whatever. And it just doesn't make a lot of sense. And in the end, guess what?

That client's gonna be talking to the attorney and the attorney's gonna be, be pulling up all sorts of red flags when those things occur. Yeah, go ahead Andrew. Yeah, Chris, I was, you, you, you, you jog my memory. 'cause we've had Spencer P*****k on who's, when the leading breach attorneys had him on the cyber call. And you just made me think about he, he said some very similar things about man, he's just like, man, the MSPs seem to be more, um, adversarial.

And he's like, when I work with an Ms P that's adversarial, boy, it does not go well for them at all. Um, it's more expensive, you know, in, in a whole host of things occur negatively. I I don't wanna go down that tandem, but I just, sorry, it just made me think about that. Um, but in interest of time, um, I know we have a few questions. No, could you introduce yourself, share out the screen that Chris Lair is gonna kind of lead and Sears is gonna kind of tag along with this.

Chris is gonna, LA's gonna allowed us go under the hood a little bit about how he handles an incident, why he handles it a certain way. He'll talk about the need for a system like this for attorney client privilege. So no, if you could share your screen, tell us a little bit about yourself, uh, it would be awesome. Sure. So thank you for having me over. Uh, I'm Norm Morganson, the CEO of Exigence. We're a software company operating out of, uh, Tel Aviv Israel.

Um, we have, um, customers mainly in the US enterprise customers, MSP customers using the tool for incident management instant response. And that's, that's the focus of our company. I mean, we provide a platform for managing incidents in a very controlled way, confidential. It is, uh, by the way, it supports multi-tenancy, which I know is a very important for MSPs. Um, and I'll take, I'll take a peek and show you a peek in the tool.

And Chris Laer, and you know Chris here as well, can, Chris Laer is a user, uh, is a customer of ours. And, um, but Chris here can also share, you know, what what he finds interesting. I'll be happy, you know, to hear from you here. So share my screen. Yeah, share your screen. And then I think we have a, what a ransomware case if you'll, and so let's let lair kind of drive, you know, why he does things in this. Um, yeah.

You know, and Chris can lair can you also take it from the MSP's perspective? 'cause at one point before you got bought, you did have an Ms P We did. You sold exactly Right. Yeah, we did. We sold it off. Uh, and now there are MSP uh, full transparency, but, uh, I don't let 'em touch anything. Don't tell me. No, that's pretty funny. It don't touch my stuff. But anyway, uh, no.

So one of the things, and I've used this word mindset is, is when, when you're in an incident situation, and I'm not a fan of 10,000 tools, uh, but when it comes down to things, and when we had our Ms P side of the business, it made, you know, at the beginning it said, Hey, look, we have, and I ConnectWise manage. We have that. Why, why don't we use that? And, and the pieces, I guess were there.

The thing about it though is, is when you're dealing with just normal IT stuff, whether it's tickets, whether it's onboarding, whether it's um, uh, project work or whatever, I mean, those things, those things are what they are, right? And when you have an incident, and just like we talked about at the beginning of this thing, you want people's mindset to be different, right? They need to handle things different. The business rules are different. The everything's different.

And I said, look, in order for that to make sense, we really need somewhere different for that to take place. So that was one, one kind of trigger. The other thing was, was all about communication and collaboration. And, and let's be honest with you, the PSA is not the greatest collaboration tool, right? It's tickets and that type of stuff. People email back and forth, it's reflected in tickets.

But when you're dealing with, typically in the MSP world, it's you and the client and maybe a third party here and there, but it's mainly you and the client. When an incident, it's you, it's the client, it's the insurance carrier, it's the breach coach, it's an IR firm. It could be a PR firm, it could be, there's just a number of parties involved and, and sharing that information. Email is not my top choice, right?

People just say stuff in email that's wrong or that gets misinterpreted or, or whatever the case may be, uh, premature. And I was like, let's see if we can figure out a way to kind of solve this problem and move out of the email as being the primary method of communication. And so that's when I got introduced to Nom and Exigence. And they had had, they had a platform, uh, that they had built for incident response, but it was built for enterprise.

And so the enterprise, uh, it, it was kind of built for that. And, and we're like, well, we looked at, we looked at what's going on there, and we said, what can be done to make that more of a multi-tenant to use the best term, uh, a, a system? And, and so all the moving parts were there. The back, the backend architecture was there for them to create a, a, a system that could support our security requirements, could support our, our our confidentiality requirements and so on and so forth.

So really from a collaboration, uh, collection of information and being able to track and follow a case from beginning to end the pla this platform made sense. And he also had the, the capability to tweak things for us and to customize different areas of this, create different fields and those types of things for us to where, uh, to where it just made our lives a lot easier.

And the funny thing about this is, and this is a little bit of dirty laundry, is, it's kind of funny, is we really didn't have anything like this before. We were managing it with a combination of email. There was some Slack, some teams, there was a OneNote. And there, you know, there was all sorts of different things being used. And when you go to this, it's kind of funny. The things that people were complaining about were things they didn't even have before. They're like, it's missing this.

And I'm like, well, yeah, it's missing that, but you don't have that today. Why are you complaining that it's missing this? You don't even have that now. You know? I was like, and then, so it's kind of funny how these things go. But, but from the end point is we're on this journey with them.

Uh, and uh, really the ultimate goal is it for it to be that kind of single pane of glass for all the different entities to be involved here, and those people who need to see the things that they need to see can see those and so on and so forth. So you have roles based permissions, you have a number of different things in here that really fit well with an incident situation. So, um, let's go to Sears. Sears, um, no, maybe just stop scrolling. Sure.

Sears, from an MSP's perspective, why did you guys, you know, again, 'cause we know there's tool sprawl, right? And MSPs are like, gosh, another tool, right? Why can you tell, can you kinda walk us through the logic and why it was important to, to start to go down this path for you? Sure. So a big part of it is, you know, the growth that we've had already within the organization and the growth.

We project, like I said, more and more people involved in the process and it's, you know, a documented process, but it still relies heavily on somebody doing the right thing and following all of these steps manually. Um, so adding some technical structure around this documented process, I think is very important. Making it very easy to launch an incident, choose the type it automatically has, you know, everybody assigned to those roles I talked about, they get pulled into this chat.

Uh, it really streamlines that effort to kick off, um, you know, the incident process for us. So, you know, that's a big one. Um, I found, you know, we use teams heavily and so we use a dedicated teams chat for each incident. And when these things drag on for days and, and you've had a lot of discussion, doing the postmortem is nothing short of a nightmare using teams. If anybody's tried to scroll back through a long teams chat, it just doesn't work well.

So I'd love the idea of this timeline and as important things are being said or done and, and recorded in the teams chat, being able to pin those to a timeline with a certain type of classification, um, is, you know, absolutely critical. I think in, in being able to do that, that postmortem writeup, um, you know, both quickly and, and thoroughly. Um, it can also help if, you know, you're like, oh, who made that change to a firewall? What did we do there?

You know, boom, you can just set the timeline and you're not trying to, to go back through this giant chat, um, or, you know, use the search function. That also isn't all of that that great in teams. Um, and then having the place to archive it. So trying to export a teams chat is, is difficult, um, at best.

So having this platform where we can, you know, if we choose to store files there as well as, you know, the entire chat history, or we can decide we don't want chat history, we just want to keep the timeline and the files. A lot of flexibility there as to what we archive long-term rather than me trying to scrape everything and put it into a, a lockdown SharePoint site for, for long-term retention like we do today.

Um, and then, uh, in one of our calls with nom, I brought in our, our director of operations, um, just to get buy in there, um, because this is, you know, gonna be a new expense for our company. It's something we don't have in place today. Um, and he got really excited thinking about using it not just for security incidences, but technical incident response and, you know, documentation as well along with possibly even like hr.

If you have problem employees and you don't have a good platform for tracking your response to that and you wanna make sure you're checking all the boxes, giving them all the opportunities somewhere essentially to keep all of the documents and everything, um, you know, there, there was that potential benefit as well, which means you can spread that cost, uh, you know, across different kind of business units and, and have more justification for, for bringing a tool like this on and not just thinking of it, not, you know, security mindset.

Yeah. Chris, I think what you just said now also addresses one of the questions that we're, that were raised about incident standing, you know, beyond security and also, you know, for it especially as a, as an MSP. So I think it's a very valid comment. Yeah, absolutely. So we're here for open dialogue. Number one. I wanna say, um, if, if you're would like to Noam's allowing, is it 60 days known for you guys guys, 60 days? 60 days? No. Put your email in if you would in chat.

Um, we have a pre-configured kind of MSP version with templates already. We're looking for feedback, uh, from MSPs to, you know, like, uh, in terms of where no's open to pricing, whether it's per incident, um, bigger firms like, uh, Sears or you know, they're gonna buy outright, but there's other MSPs that are doing it per incident. Um, so this is an exploratory thing. We want feedback from you all.

Um, if you are just maybe a quick why or n are you doing some initial, you know, incident handling in your firm, um, was today's topic relevant for you? Just why, or n if you could give us that there's a little delay, if you could let us know in, in, in chat, that would be greatly appreciated. And then, um, I'm gonna go back to, there's two questions posed in in the ask a question section. Matt Lang asked the first, so, so the question is do you see a merging of it?

And maybe this is what you just said, no, it may be referring to that, but this, I think this is what Chris Sears just answered, so apologies if it is, do you see a merging of IT incidents and security IT incident response, Chris Sears, uh, the, the A in CIA triad doesn't necessarily mean a secured incident, but it is an IT incident. Would love your thoughts. Um, yeah, I think there's certainly a crossover there.

And ultimately you may not know right off the bat, are we dealing with a strictly a technical incident or was this malicious in some way? It could be an insider threat, it could be somebody got in from the outside. Um, so, you know, you kind of need to treat them similarly to start with until you've really determined what you're dealing with. Yeah, you might have to prove that it's not a security incident, right?

Um, so a lot of people don't realize that that, you know, even though you said it was an IT incident, somebody might disagree with you and so you have to prove it. Otherwise I, is that part of this re rationale for exigence for you Sears of like that, those, those being defensible as well and go, Hey look, we, you know, we thought it was, but it, it's not. Here's what we did. I think, I don't know, that's a, a primary driver for us certainly, but I think it's a nice to have.

And again, treating every, using the same platform for both types of incidences makes, you know, for a lot of continuity there, regardless of how you choose to, to handle it or, or what the ultimate, ultimate determination is at the end. So, uh, yeah, it's definitely a benefit of, of having a platform like this for sure. By the way, we see this almost with every customer. They use it for both IT and non security incidents. Yeah, yeah. Yeah. That's, that's really interesting.

Um, I think it's really interesting, Chris Sears that you talked about. I didn't think about that, but hr, what a great one. You know, unfortunately that is a highly litigious scenario and you know, as you grow as an MSP, obviously your odds grow, right? We, you know, we said, you know, now all of a sudden we have to start to document, hey, we asked you to do this, or this person did X and y. It's, that's really interesting.

Um, uh, and then Chris Lee are, you answered the question in there, uh, but I don't know if Chris Sears has any comment on this. He, it says, just to clarify, are you suggesting the Ms Ps file a claim with their cyber insurance carrier if they use a third party software that was attacked, even if it doesn't directly impact the m ms p? If so, can you give an example? So Chris Laer answered it, I was just curious if you had any comments on, on that, Chris Sea? Um, can you clarify the question?

I guess I'm, Well, I think that question is more like, Hey look, do you call the insurance company every time? Uh, and I think in the, in the question it was, do you file a claim a anytime e even if a th let's say you have a third party that had some situation, even if it doesn't impact you, do you call them? And I said, no, you don't necessarily file a claim, right?

But if there's a potential for there to be an impact, you should at least notify your carrier because they just wanna be notified. So there's a little bit difference between notifying your carrier and opening a claim, but it's always good if you think that there's some threat to at least give them the heads up the notification. So when something does happen, you did your part by letting them know upfront.

Yeah, I think if there's no evidence of, of loss or, you know, data access or anything like that, lost revenue, you know, we're not going to make a claim. But in this case, that's where I would, you know, um, rely on the business decision maker, right? I'm not gonna make that ultimate, ultimate determination. I'm gonna take that to, uh, you know, Ken and Daniel and our team and say, Hey, you know, what do you guys think here?

Do you wanna at least, like Chris said, do the, the notification and, and that way if this does lead to something else down the road, 'cause sometimes you don't realize right away the scope of an incident, um, at least you, you know, made that notification and um, you know, hopefully, you know, aligned with whatever requirements are in your policy or if you don't make that notification because you could have coverage reduced, you could just be found negligent, like, Hey, we're not gonna cover you at all 'cause you didn't let us know early enough and we could have mitigated this loss if we had acted right, you know, quicker.

So, um, definitely would, uh, you know, do that notification if it made sense. Yeah, and especially these kind of, these bigger ones, like we've, you know, in the past there's a big black BO one, the Kronos one, it's the latest one's been the news. The insurance carriers have a process that they set up to deal with these massive ones, right?

And so if you go off and do your own thing or wait or whatever, and you, they're not, they don't include you in that massive, in that kind of mass process that they deal with, they're not gonna be too happy about it. So you just wanna do things, what's right and let them guide you. Again, uh, carriers are not trying, they're not, they know they're, they're there to pay claims. They're not trying to figure out ways not to pay claims.

They just want to do things as cost efficiently as possible because they know that it's going to affect premiums and they know they need, if they didn't, if they didn't pay out claims, they wouldn't sell policy. So the, the, the two go hand in hand, uh, but they are just being, uh, much more particular about the way you do things and nothing's really changed. The policy language has always been there. They just not has been as rigorous, uh, around those requirements as they are now.

So we're at the top of the hour. I just want to thank no, Chris Laer. Chris Sears, Chris Laer, I'm putting your email in. Um, you for those out there, just in closing, if your MSP wants to walk through a tabletop, Chris does this on his own. Um, he, he'll bring in the Exigence platform. So maybe you have a big client, a regulated client where they need to do a tabletop. It's, I did it with him. We kind of sat a fly on the wall with an MSP at Big MSP and it was awesome, um, watching it.

They had, they actually did it as an event and they had like about 10 of their clients and prospects in. So reach out to Chris Laer if you need anything. Um, so again, thank you all for, for joining in today. Um, and, and again wishing everybody very happy, healthy holiday coming up. Until then, everybody take care. Thanks guys. Thank you.