May 3rd, 2021 – Open Mic – Legal, Cyber & IR

Welcome everybody. It's week 49. Wes, we're closing in on, uh, and I say Wes 'cause Wes was one of the originals, uh, closing in on one full year of the cyber call. And, uh, welcome everybody. Pretty wild, huh? We, Yeah. We should throw like a big party. Uh, yeah. Get together in person. Yeah. Who here in chat wants to do a cyber nation? Uh, con We're not gonna call it a conference. This gonna be a con baby. Who wants to, who wants to join in on that Cyber call? Con, not A Yes.

Cyber Nation Plus, plus one. There you go, Ryan. There's, there's always this delay or people have a post perennial look. Love the shirt. Ah, there you go. Yeah, you know, it's an honor of upcoming. May the fourth be with you, my friends. Let no one, especially Ray Ray's probably not on, I know Ray's a big Star Wars fan, so he'll relate to this shirt. Uh, I definitely wanted to buy it to uh, get the street cred from you. Awesome. Star Wars fan.

So you'll think I'm cool too 'cause it's definitely shows how much I know about Star Wars. Alright, well let's, let's get right on into it. I am going to put up a quick poll. Always love if you guys could take a look at that and give us your thoughts. Um, Eric, uh, I'm gonna introduce everybody, but can you, you know, as I put up that poll, you know, you've been speaking to a lot of the MSPs.

They've been reaching out to you since first getting introduced on the cyber call, and I put your link below if you have questions on MSA style. Give us your thoughts on this. Why, what the why? Yeah, so, so the why is that, you know, MSAs are, are complex documents and just because you have a lawyer draft an MSA or review an MSA or what have you, it doesn't mean that that MSA applies to your business and, and covers everything that you do for your customers.

And that's one of the most basic things that I see, particularly with my newer clients, is that they'll have an MSA and it's either a good MSA or it's not a good MSA and we can sort through that, but a lot of times it just doesn't cover what they do. You know, may maybe 20% of their business is the resale of hardware.

Um, there needs to be separate terms in your MSA for the resale of hardware that are different than the terms for when you deliver managed services or professional services to your customers. Or maybe there's great terms in there for managed services but not professional services. Uh, and they're very, very different legal risks and legal parameters that you have to pay attention to in your MSA, um, that, that most business owners, because look, they're complex stocks, right?

They're not fun to read. No one wants to, you know, read about indemnification and then warranties and liability and things like that. But you do have to make sure that it applies to your business. Got it, got it. I appreciate you bringing that up and, and getting, we'll get some feedback here.

Again, if you guys could, you know, the polls are anonymous, so just to be really interesting, if you guys could just take a moment, answer it and, um, and we'll address some of that a little later as well. So here's today, today's open mic and a lot of you sent in questions. I'm gonna do my best to get them to everybody in the, um, the our hosts here, uh, and, and, and get off on, uh, a a good note.

Um, because normally we're doing some kind of piece of content, lots of questions get ans asked and we don't always get to all of 'em. So that's the intent with that. Uh, just a quick intro, Eric, from you, just in case people don't know you, and then from Chris, same thing. I I think most people do, but let's just appreciate you guys coming on. Yeah, thanks Andrew. And I'm, I'm, I'm thrilled to be back.

Um, so just real quick, um, I've spent 22 of my 23 year legal career, uh, working in-house for IT services companies and MSPs. Um, and recently I've branched out on my own, uh, and I am providing those types of services, those general counsel services, uh, that I provided to multinational, um, IT providers, um, to, to MSPs and other IT services providers who might not need a full-time in-house resource, uh, but certainly benefit from, from a fractional share of one. Yeah, yeah, absolutely.

And Eric, you know, I think pe people that have been on no, you know, 17 years, you and I go back, I remember back when you guys were a really small MSP. So for those out there that think, wow, you know, yes, Eric was the chief legal officer for Logic, a publicly traded, you know, 3,500, you know, employee MSP, uh, he also has roots in building and scaling, uh, to about 250 employees.

And then having, yeah, Starting, uh, starting with, with three partners in a, in a small systems integrator that we, we grew to 250 people before selling it to Logis, which is how I ended up there. Yeah. Excellent. Excellent. So Chris, most people know you. Um, we'll find out if Jason Slagel's on any moment because, uh, if he is, I'm sure we're gonna hear about it, but go ahead.

Yeah, Chris, with solid security based in Austin, Texas, uh, half our business is focused on incident response and half our business is focused on cybersecurity. I guess what most people would say as proactive. Um, my background is, you know, security and it come from a banking background for the majority of my career. I've been in solace for about eight years, but I was solace is first customer initially back 18 years ago. So that's how the story all started. So happy to be here once again.

Yeah. Well, thanks again. Really appreciate you guys all, Ryan and Wes, always great to have you on with us. Okay, so let me start off with us. We are gonna go with, um, a, uh, I'll just keep everything anonymous right now, but we, so here's the question. As I work with my clients and walk through cybersecurity threats solutions, I think of some of their questions like what's the return and bus justification, uh, bringing, you know, company's leadership team for the cost of cybersecurity tools.

Like, you know, these days, sim right can range from 25 to $50 a user, um, I think purchased 2199. Uh, I'm kidding. But, uh, um, but, you know, advanced, you know, cyber tools like EDR like give, give us, you know, you talked to a lot of MSPs, Wes, what are your, what are your thoughts? And you've sat on, you know, someone that procured these type of tools and that would justify 'em to the board.

So I thought it'd be a good one for you For, yeah, th this is a good question and I get asked this occasionally, especially from my partners, that'll be like, Hey, I'm talking to a client and I think we're at the finish line. They understand what we're doing in the package, but they know that we're going from whatever it was before to whatever it is now.

And it's a lot more, and I'm gonna even case in point of this, one of my favorite partners, I won't say their name, uh, if they're on the chat, they can even join us on the call if they want to talk about it. 'cause they'll know who, who this is. But, um, they have a fairly large healthcare provider that, um, was not exactly doing everything that needed to be done with HIPAA and high tech requirements. And, uh, they were storing logs, but they weren't doing anything with them.

And so we're going through the, the finish line with them and, and the doctor who ultimately was responsible for reporting to his board that's gonna make the budgetary decisions, like, look, I get it, we need it. No arguments, but here's my challenge. They're gonna ask what the ROI is they're gonna a they do in all things. If we move to this EMR system, how long is it gonna take? What's it gonna cost and what's it gonna save us in the long run? What's this gonna save me in cybersecurity?

And that's a challenging question, right? Like you can approach this in a couple different directions, Andrew. One is you can approach it from the data breach cost perspective of just, you know, the average cost of a breach. And you know, Chris or, or Ryan can probably fill in more, but you know, studies show anywhere from 120 to $150 a record, right? So if you wanna put some cost on it, you can throw that out there.

And we talked about that a little bit, but he is like, yeah, but he's like, that doesn't help me because I don't know if I'm gonna get hacked or not. I don't know if I'm like, I make this investment, I could still have these problems. I'm like, yep, you're right. You could. And so I said, let me make an analogy for you.

I'm like, so if a patient walks into your clinic today and they want an MRI or you want them to have an MR mri and they say, great, I'm gonna do this MRI if I come in every month, every week, every week, every year, and I do an MR MRI and these other things, you're gonna guarantee I'm not gonna get cancer. And he was like, okay, I see your point. I'm like, look, everybody in cybersecurity that when we talk about it, they want to know if I invest, will this make me not have something bad happen?

We don't get the choice to make that call in reality, right? Like, and this is very similar in other things. And the second I hit that home with him on like healthcare and, and he is like, yeah, you're right. We'll never tell a customer they're never gonna get cancer if they do all these other things, but we will tell him it's the right thing to do and we're gonna catch it early and we're gonna handle it right? And he is like, yes.

All of a sudden, like the clouds part and he's like, okay, I get it now. He's like, it makes sense that that's the angle. And so I just think sometimes decision makers naturally have that bent of like, tell me this is gonna make sure x, y, Z things don't happen. But it's not that, think about it in insurance insurance is similar, right? I pay for a bunch of stuff with insurance, but it's not gonna guarantee a, a hurricane is not gonna hit me here in Tampa.

So that's, I think it's important to kind of steer and redirect the way that people think through all of this. It is important to run the numbers, but I think beyond that, it's important for us just to understand what we're doing with this. We're not guaranteeing no breaches. Um, we're not even necessarily saying that, um, you know, there's an ROI we can calculate out of this. It just doesn't work that way. Um, Ryan, you've been in this field for a long time. What would you add to that?

I think that's pretty complete actually. I don't know that I would add much to it. Yeah, well that's really well said though. Putting it in there. Something they can understand. I mean, isn't that, you know, communication one on one, right? And we often miss that 'cause we're so interested in kind of pushing our agenda, like, hey, this is the right thing for you and you know, you're gonna help you and all these other things that are in our head, if you will.

'cause we're thinking about what's important and what we know ultimately could happen. But if they don't understand how to, you know, translate that in their words. So, um, send in your questions by the way. Um, and I see some in there already, so we'll get to those as well. So, Ryan, coming to you as a cybersecurity leader, which I would classify you as if I could.

Um, what's your two minute elevator pitch to a client who believes that this is not really a huge issue for their org, meaning cyber, you know, I don't need to, you know, put in additional controls, et cetera, because I really don't have anything hackers would want or value in my works. Yeah. Two minute elevator pitch is tough. Um, 'cause there's, How about three? The question is flawed. It has, um, it has in inaccurate assumptions built into it, right?

And that takes a, that takes some reeducation. But what I would generally say is, um, attackers don't care about the value of your data. They carry how much you value your data. And so you can't, you know, we can't think about it in such bright line terms. It's not about the value of it to them, it's the value of it to you. And I, I would actually usually, I usually use that question to turn it into a, well, let's have a conversation about the value of your data, right?

Because the value of your data really just de dictates what type of cyber attack you're going to experience, right? So if your data has intrinsic value to an attacker, then you're probably more likely to experience some sort of exfiltration and extortion event. Um, which may or may not include ransomware. Increasingly, I think Chris can back this up, not huge trend yet, but we are seeing, um, data exfil, uh, extortion incidents without encryption.

Um, and so that's, that's one avenue of, if the data is just intrinsically valuable and it could potentially land you in what kind of regulatory waters, if the data is not intrinsically valuable to them, then it's more likely to result in a ransomware incident because that's, 'cause now I'm counting on your data mattering to you, and so you're gonna want to pay to get it back so you can keep doing what you need to do with the data. 'cause it, it doesn't do me any good to steal that ex billet.

And you know, maybe, you know, if, if, if I disclose that information and it doesn't cause you material harm and I can't really pressure you or influence you with the data, um, being in my custody and it doesn't result in some sort of notification requirements, your customers or some sort of other material harm, then you know, that leans a little more towards ransomware.

So you really have to turn into a conversation about the data and the value of the data to you and the value of the data to, uh, malicious third parties. And then that really becomes an opportunity for you to have, have an educational conversation about, well, these are the different types of adverse cyber events that you could experience and that you need to build resilience for. Yeah, really well said. It's almost like you gotta bring the future to the present.

Like, you know, if this scenario does that, does that matter to you? Would this scenario matter To you that people don't think about their data the way they should until something bad happens? And they're like, oh man, you know, I mean, the recent story was the one with, uh, the $50 million demand on that, um, on that police department or whatever. And, and basically the, the attackers are saying, Hey, will, we'll release the names of all your informants, you know, for $50 million.

So that's kind of the worst case, but that's what these guys, these guys are finding creative ways, uh, I guess you could put it that way to make your data more valuable than you even thought it was, was going to be. Um, it's, it's interesting because when we see these situations, we come across them a lot, right? We come across where, hey, they have great backups and whatever the case may be, but the data is the issue. And, um, it's just, it's just kind of, it's kind of weird.

You, you have to start asking those questions at the, at the time of the incident and it's too bad you couldn't ask 'em six months or a year ahead of time. But, you know, you find a lot of, uh, personal data out there. I mean, we've had ones where, uh, we had a financial institution and their attorney who was outside, was storing his documents on the financial institution servers because he thought that that would be the most safe, secure place.

What more would be more safe and secure than the bank systems. But then the bank systems were compromised, so therefore his data was compromised too. So you had actually kind of a two for one there at that particular time. I mean, um, you have other cases where, uh, you know, you have principles or owners that have their own private information on their financial statements, whatever the case may be.

And that by its none of the business related stuff is really valuable to, in their point of view from an embarrassment perspective, but their own personal stuff and their personal wealth and that type of stuff. And then we get into it where people don't realize, hey, there's a little, there's a lot of competitive risk if that stuff gets put out there. So, you know, they're like, oh man, am my competitors see this?

Or not even their competitors, but they may, they may have multiple clients and they don't want one client seeing the pricing and the rates that they give the other client, uh, that could open up the kimono. And then, and then the other one is, is the, there, there is this, and it's kind of funny, uh, worked with one bank that, um, cared about salary information so much, this will date you, but date us.

But that at one time they had their, our HR person was not allowed to keep salary information on the network. She had to put it on a zip drive, actual zip drive and walk it down to the CFO when they wanna discuss it. And that's the only thing they would allow. So you get, it's still kind of half and half, right, where people are like, oh man, if all my employees find out what, what we're paying our employees, that's really bad news. So it's amazing.

You would think that a lot of these things people would think about, but they really don't until the incident actually happens. Yeah. Very good. Wes, I think what Keith was saying there, and just could you give, you know, I, I'll stay on track here because we are all our questions, but you know, Keith Nelson, who's been take Keith, wonderful to see you really supply chain there, right?

Wes, in essence, what Keith's saying, like, you know, uh, I don't have anything, but what about maybe you, you're a distribution company or you have supply information all price, you know, like there could be things that maybe you don't think, but what about your customers or their customers customers actually do care? Uh, yeah. A a classic example of that is CMMC, right?

Like, Hey, all I do is I create this one widget that goes on this one thing that happens to go on this one helicopter that China doesn't have right now. Uh, you think that's not valuable, just wait, just go ask China, uh, how valuable that is. And so yeah, you're exactly right. It could be things like that, or it could be like, I don't think that we know how bad guys think the way that we, like, we don't think the way they think often.

And so to Chris's point, I think oftentimes we don't, um, always recognize from a fourth party what that may be worth. Um, or you even look at like Eric can contribute to this. Like things that can lead to lawsuits, lead to a lot of data going into that lawsuit, leading to a lot of public information that can just be read up and, and looked at. Um, I, I was, hmm, how do I say this?

I was looking some stuff up just the other day about a public lawsuit and fair amount of information, just public record just clicked right into the, the county go right into the dockets and there's all the data. And I was like, whoa, there's a lot of information here. So it's, yeah, those are things you gotta think about.

And one thing I did wanna say quickly that, um, Brian, that he said that really resonated with me, I'm sorry, Keith, is, you know, this whole idea of like, you know, we try to be the hero and come in and be like the awesome save the day thing. And in reality, um, that doesn't really resonate with our clients. Um, and that doesn't re resonate in security if we try to, you know, run in like bull in the China shop, you know, hacker, hacker, we're gonna fix all this and we're so awesome.

And that doesn't re like I love what he said, like what we really should be focusing on is, you know, I'm gonna read this, you know, focusing on the customer's business and creating value in security by augmenting and showing what they're doing and how we're protecting that. And a lot of that goes back to, I don't know if you guys have seen StoryBrand, um, you can just Google StoryBrand. It's a marketing concept, but the whole idea behind that is like, look, we're not the hero, our hero.

It's, it's this idea of like, we're the guide that comes along, right? We're like the Gandalf to Frodo. Um, Frodo couldn't do what he did without Gandalf coming along, but Frodo is the hero of Lord of the Rings, right? And it's the same thing with us. We're not the hero. We're coming along, we're augmenting them, we're adding business value to what they do, and we establish relationships like that. You establish those for eternity, right? You're now a business partner.

You're the VCIO, you're not just the guy running in, you know, trying to save the day. And that resonates. Yeah. Very good. Well, Eric, lemme start off this one with you. And then love, uh, Ryan. Chris, any comments on this? So how does one disclose a breach publicly and to its effective p persons when an bill is confirmed? Um, uh, or even, you know, you or how, I'm sorry, let's just, let's just keep it there. Like how do you handle that, Eric? Yeah, that's a good question.

And, uh, you know, let's not talk too much about disclosing it publicly because that kind of depends on the industry, the degree of regulation, whether it's a public company, whether it's a private company, whether it's material, whether it's not. Um, but the important thing there is, is the affected people and every state is different. Um, every state has differing definitions of what is PII or personally identifiable information.

Um, you know, so if there's a breach of, of a list of names, odds are, it's not personally identifiable necessarily unless there's another factor as well. Maybe it's a name and an address name and a phone number, a name, and a credit card number, um, or something like that. Um, and then you have to get into the issue of what constitutes a breach, you know, and, and is it an actual breach, a suspected breach? Maybe it was a breach, who knows?

Um, but again, every state has different laws, different regulations that, uh, that relate to that. And then where it gets really touchy are the notice requirements. Um, how, who do you have to notify? How do you notify and what do you do? And that's dependent on a bunch of different factors. Um, the, the breadth and and scope of the breach, the type of information that's disclosed, um, how many people's information is disclosed, do you have to offer credit reporting and, and things like that.

Um, and then finally, there's, there's exemption to all of this that, that might nullify all of the, the reporting requirements, the biggest exce exemption being encryption. Um, and I think we talked about this a couple weeks ago, but a breach of encrypted, encrypted information generally is not considered a breach at all. Um, so that's why it's really, really important as MSPs and as it services providers to make sure that your clients are encrypting their sensitive information. Excellent.

Ryan, you wanna add anything to that? Yeah, I want to key in, I agree with, like, it depends on your industry and a bunch of factors that are difficult to quantify, but I want to key in on the, when you don't know, right? Because I think there are gonna be a lot of SMBs and MSPs, they're gonna be in a situation where they didn't have the right controls in place to begin with, to really understand scope.

Maybe they didn't have sufficient logging, they didn't have, you know, sufficient network security controls in place, whatever. But you might find yourself in a situation where like, okay, I know something happened, I know something was accessed, I don't know the extent to which it was accessed. Then you're going get into a gray area, right?

And I think that's really a point where you need to a ask answer for yourself, are you gonna be the type of Ms P or the type of company that discloses regardless, or are you gonna be the type that says, well, we don't have a, a firm requirement to disclose if we don't know exactly who, so we're gonna, um, we're gonna only notify the individuals that we can confirm and, and, and be done with it. And I think there's like the what's required and what's the right thing.

And like I tend to lean more towards what's the right thing than what's required, even though the right thing, you know, um, kind of, you know, cracks the egg in your face a little bit more than, than maybe the other option. But I think right now we're living in a role where that level of transparency is really required, um, even if it's not legally required, like it's expected. Mm-Hmm. So, um, so, you know, we, we always err on the side of over communication.

And then Ryan, the other, the other important factor there that, that I didn't mention before is the timing of the notification. Um, because again, every state is different and if you're going to notify, if you have to notify, you have to do it within a certain amount of time. Again. And it differs by state. Some are very prescriptive, you know, 72 hours, 48 hours, three weeks, whatever others say, as soon as practicable immediately, or all those other legal buzzwords.

Yeah, I mean, all two people hide in like behind language, like out of an abundance of caution, we've reset passwords for everyone, which, you know, the fine print says we have no idea who was affected and who wasn't. So we just swung a big hammer and made sure that it's safe for everyone.

Um, so I mean, you, you, you, you gotta look out for the ways that people try to gloss over that, but, or try to minimize PR damage, but like, just tell 'em, you know, we didn't, you know, our logging wasn't a hundred percent and so we're taking this action to, to make sure our customers are safe. And that's, that's the honest truth. And I think people would, you know, would, would tend to believe that you look at the statement out of an abundance of caution with a little bit of skepticism.

Well, Ryan, what I like, what I like about what you just said is if, you know, if we can get them to do a tabletop exercise and get to the point where, and by the way, we don't have logging in place, you, you know, we've recommended that you've declined that piece. Going back to what Wes' original question was, these advanced solutions, um, okay, so now your data has been exfiltrated, how would you like us to handle it?

Our professional recommendation is telling you and telling all, you know, but you know, Eric, I see you shaking there your head, but Yeah, no, you, you hit on the head. Absolutely. Okay. The other thing you can't lose focus of is you may have some contractual requirements to disclose quickly as well. So a lot of people miss on that. So that's a lot, A lot of times you ask that question in the case of an incident and they're like, well, we have no idea.

And the other fortunate unfortunate side of things is guess where their contracts are? They're encrypted. So they don't know. So they don't really have a way to even figure that out very quickly. And so that's, that's not a good deal, especially with some of these people that have key relationships and those contracts with that language are very, very instrumental to their bottom line. Yeah. Speaking of that language, right?

When you sign a contract with someone and says, I will notify you within 72 hours of a confirmed breach Mm-Hmm. What is a confirmed breach mean? Right? I, I could be sitting on does it mean you've confirmed that my data was accessed? What happens if there was a larger security incident? But you are unable to confirm whether or not my data was accessed, right?

So like, you need to be careful about those things too in your other agreements because a lot of people try to hide around, you know, behind confirmed security incidents as a way to limit their notification requirement. Yeah. And we spend a lot of time negotiating that in, uh, in MSAs and in s about, uh, what exactly those notification requirements are. Very cool. Um, Eric, um, I've got a few to come to you. I just want to go over a scenario for the panel and then I'll come back to Rapid Fire.

Some of these questions for you, Eric, on MSAs. 'cause we got some of those in here as well. Eric, I'm gonna read the scenario one, all you guys to chime in here. Several weeks ago we had a client who had a bad actor gain access to their environment via legitimate logging credentials and successfully encrypt the FI a file server and two PCs who fur though further damage was thwarted by various security, uh, mechanisms in place.

Once analysis and containment were complete, we called the client early Sunday afternoon to ask, ask if they had cyber liability insurance. Uh, and if so, the carrier may want to call their own IR firm. The clients said they didn't have cyber liability insurance. We explained that we were not an incident response firm. And if they wanted us to refer one and if, if, and if they wanted us to ask if they wanted to refer one, they said, no, go ahead and recover, uh, to get working.

Then Monday we, which we've proceeded to do. So, uh, they did, and then they found out after the fact they actually did have cyber insurance. So who wants to start off with that little doozy there? I can, I can start with that. And, and, and I think that that, and, and, and Chris might disagree with me, but I think the fact that there is or is not insurance, um, for purposes of of the answer to this question isn't that important.

Um, I think what the MSP is concerned about is, is what is their liability here? What's their potential liability here? And you have to look at what they are obligated to do for this customer. Are they obligated contractually to respond to this incident or are they not contractually obligated to respond to this incident? And if they aren't contractually obligated to respond, they can, uh, they can do one of two things. They can say, all right, Mr.

Customer, you gotta go find an IR firm, or, or here's an IR firm and they'll take care of you. Or they have to become contractually obligated to respond. And that's in the form of some, some sort of a sow that, that says what they will do. And it's gotta be a really carefully crafted SOW that, uh, that will tell them what it is they're going to do and what it is they're not gonna do, and what they'll be responsible for and what they aren't.

So the fact that they're, that they're, that they didn't think that there was cyber liability insurance and they ended up being, that comes into play in the back end in terms of if they're gonna get paid, how they're gonna get paid, who's gonna pay them, et cetera.

Um, but you gotta be really, really careful to, you know, under the guise of customer service, you're taking care of your customers to not get involved in a, in a situation where you're doing a lot of stuff that you shouldn't be doing or you're not contractually obligated to do. Um, and, and, you know, we all know what the, the road is paved with. Yeah. I'm gonna, Chris, what? Oh, go ahead. Go ahead. I'm wanna be a little contrarian here.

I see a lot of comments about like, only do what's in your IR plan. Only do what's in your MSA. Um, I tend to look at the world in terms of what's the right thing to do, right? And so, uh, in this specific situation, right, what it sounds like is we detected, we called the customer and said, we detected, what do you want us to do? Do? And we went straight to recovery. We skipped the response part, right? Right. Of broom detect, respond, recover.

Part of your response capabilities, even if you're not doing the forensics, should be to maintain the evidence. So even if you're gonna recover when you recover, don't do it in a way that you destroy the evidence. Because when you do that, you completely annihilate the ability to ever go back and determine what happened.

So even if you found out on Monday, oh, there is cyber liability insurance and they do want to call in an IR company, great, here's the evidence that we preserve for you, the environment's back up and running. So, and, and you know, I don't, I don't really know how that intersects with MSAs and whatnot, but like, just evidence preservation should be a fundamental part of response before you get to recovery.

If you're thinking about evidence preservation during the recovery phase, you're already too late. It should be part of your response plan, really. Well. So can we pull that out a little bit more? So, Chris, a question for you. You know, we, when we talk about that, we often say, you know, we talk about things like we'll pull the network cable or if it's a vm, you know, snapshot that sucker, but there's more to it than that on the recovery and evidence preservation side.

Can you talk a little bit more about that? Yeah, definitely. So, you know, the one thing is a lot of these guys today are operating in memory. And so one of the things that is ridiculously important today is the ability to, to scrape memory for what was going on. Because, you know, the bad guys are doing a good job of covering their tracks and operating in memory, which makes it harder for them to be detected.

And then once you, if you do collect the evidence from a traditional way, a lot of times you're not gonna have that. And so, you know, the first thing we see people do wrong is they just shut things down versus just disconnecting things. So really, unless your IR plan is very specific about things, which we would hope it would be, but even at a high level, you know, making sure that the, the, the right things are done, but especially the wrong things aren't being done.

And that mean, hey, don't just be pulling the plug off the power or shutting things down or rebooting things, or whatever the case may be. We, especially with VMs, it's, it's even easier to be able to, you know, suspend those things so we can get the memory and scrape the memory out. So that's, that's the first thing. We wanna be able to scrape memory. A lot of people also, um, just, hey, they, um, they don't treat workstations with the respect that they deserve in these particular situations.

So they're like, oh, yeah, yeah, well, we, we preserved the servers, but the workstation were already blocked, blew them away. I'm like, well, uh, do we happen to know how this thing got in? Well, we, we, we saw this user account, our, you know, our secretary or whatever. Well, what happened to her workstation? Oh yeah, we blew it away. She needed to get to work. Well, guess what? Her machine was, what people would designate as patient zero. And that's gone.

And so there's just a lot of information and where does that come in? So a lot of times, especially today in the exfil world, what we're able to tell very quickly is ridiculously important, right?

Because especially if you have a threat actor demanding to release some information or publish some information, and you wanna make a decision on whether or not it's a valid reason or not, we don't need to debate that today, but a valid reason or not to pay a ransom or to entertain paying a ransom to not have that data published, then knowing exactly what was published is key and only forensically are you gonna be able to do that. You're not gonna trust what the threat actor said.

And so without that evidence readily available, then you're doomed. And I would tell you more today than ever before, we are getting calls where that exactly is what happened. Somebody went in and recovered the environment, blew away all the data that was there, and it's gone. And whether that was yesterday and they could have just picked up the phone and called us, or it was a month ago, and now they're figuring out that the stuff's out there and they should have done something different.

That's what's happening. And so that has to be done. So how does that all kind of come into an MSA? I mean, I, I think that's almost a, a topic that's too long for today's call, right? But I think from an incident kind of handling situation, there does need to be some legal guardrails around that, right? And whether or not that's in the MSA or that's a, an addendum to the MSA or something that makes it easier.

You know, for me, my, uh, my philosophy around an MSA is it needs to, you know, it's good to have a good solid foundation from MSA and then have addendums or whatever that can be changed or altered over time because you don't have to keep going back and redoing an MSA every year, every time you want to change. And so that's what you gotta think about.

I mean, for us, there are things that we are, we are doing now, just to put it out there, that, that when somebody calls us, it's basically, think of it as a 72 hour contract. So it's these 72 hours where you, you don't know the status of your insurance, you don't know your coverages, all that type of stuff is unknown because it's a night, a weekend holiday, whatever the hell it is.

So here's a 72 hour thing you're going to, you're, you're gonna agree to do whatever we say and pay whatever we work on for this 72 hours until that stuff is confirmed, and then we can talk about another contract thereafter.

So those are some, just some things that I would say that you need to think about in these situations, um, especially when it comes down to these incidents because, uh, I know as probably another question, but you're gonna, if there is insurance and you've done a bunch of stuff, it's gonna be scrutinized. Um, and then you could be looking at an issue on your own.

If you do something wrong, you, you make a misstep, you forget something, you put something in writing, you shouldn't have put in writing, all those types of things. And believe me, if somebody's gonna, uh, in today's world, somebody's gonna look for a reason to sue you, they're gonna do it. Yeah. Good. Um, I'm gonna ask, we'll speed up some time. I'm gonna, I'm gonna combine a question that came in from Calvin. Thanks for sending that in.

So I got a similar one on GDPR and then I'll read Kelvin. So, uh, how, how to handle contract negotiations when the client is requesting GDR compliance, Eric, this, and then Kelvin says, question for the entire panel.

Have you ever struggled or dealt with reporting for something like GDPR and you're, how would you advise an MSP to proceed, uh, with reporting to authorities outside of consulting legal insurance, which of course, the first step, uh, we have an internal process for this, but always love hearing, uh, an external standpoint as well. So, Eric, you've dealt with, you were multinational, so obviously You don't Yeah, definitely. And, uh, and in fact, our company was owned by a company in the, the eu.

So, so we were dealing with GDPR before most people could spell GDPR. Um, so what is GDPR? General Data Protection Regulation? Um, and what it does is, is it, it, the European Union decided that they wanted to give certain rights to their citizens, and one of the rights that they wanted to give them was the protection of their personal data.

Um, and so what happens when a client is, is, is when either a, a client or a vendor is dealing with the European Union or the European Union citizens, um, and now you are providing those services. So there's gonna be a couple of extra steps involved, um, in your dealings with those clients, um, especially around data protection agreements, DPAs, um, and my advice is talk to a lawyer who's done it before, um, particularly in the IT space, particularly in the data protection space.

Um, because what a lot, what I used to see a lot is, you know, we'd have to sign A-A-D-P-A with one of our clients, but the client would then throw a whole bunch of stuff in the DPA that just didn't belong, um, under the guise of, oh, it's a legally required document, you have to sign it. Well, but then they wanted us to, to, to give away everything, um, that we would otherwise negotiate in an MSA and, and that's obviously not a, a great business practice.

So, so talk to a lawyer to who, who knows what belongs in a dpa, who knows what doesn't belong in a DPA a and who's done this a bunch of times. Got it. Ryan, real quick, anything with you being, uh, international also, I wanna, you know, a team over in the uk and, and you don't have to, if not, don't worry. Honestly, we tabletop just to make sure we understand our requirements and, and like, that's ridiculous. But like, when I am, I sit down and I say, I'm gonna run an incident response.

My incident response is not necessarily going to map perfectly with different milestones of different regulations geographically. I'll be able to tell you what I know and what I don't know at certain points. But it's really helpful if we understand where we need to communicate and who we need to communicate to, what we know and what we don't know as part of the overall IR strategy, which is really the comms piece, right? The kind of external communication media, public relations piece.

Um, and, and that, you know, regulator piece. Um, so like, I'm gonna be doing this technical stuff, but when we get into it, whatever it is, it's really helpful. If, you know, within the first 48 hours, we can say, well, this is definitely this type of incident, which is gonna trigger this set of communication requirements.

And you can, even if you do that in advance, you can even start to like kind of create outlines of those communications so that you're just filling in the detail rather than creating it from scratch. And I know that sounds like a lot of work, but at my scale, like you have to do that preparatory work.

It just, it, it is, it's, it's gonna be too much, it's too much stress in the, in the middle of trying to figure out what happened to also be figuring out how to communicate, who to communicate and what regulatory requirements are. You know, do we, do we need to rise to in this, in this moment? So, you know, I encourage people figure that out beforehand. Yeah. So, um, Chris coming at you and maybe throw a little spice, uh, a little, a little less spice in there with this too.

So the, you know, we heard 72 hours and you know, from you, Chris Ryan just said, Hey, within that first 36 hours, we're starting to hear timeframes. Felicia, you know, I'd like to know a realistic timeframe of events, uh, for IR for SMB.

So you, when an MSP responds, investigates escalates to a client, um, and, you know, she goes on to talk about, determines a reportable incident, reporting to insurance, uh, everything from, you know, carrier, you know, the carrier deploys an IR firm and when they arrive. So there's a lot to unpack here. I want to keep it kind of pithy. So if we can get a lot more questions and, but Chris, did I give you enough there?

Maybe start off by like the whole timeframe thing, and she's asking what's realistic and, and I think what we're hearing is maybe set the stage of really probably depends on maturity of the MSP and, and have they done a lot of the things we've talked about so far? Is that a fair way to even start off the conversation? Yeah, I think it's an in are are, are we talking about maturity of the, the MSP with respect to ir?

Are we, are we, are we talking about maturity level with the MSP, with the client and maybe a cooperative? Yeah. Yeah. I think the, the latter, Chris, not, I, I, I'm gonna take the assumption here that let's just take the assumption for this, that MSPs are not IR firms just for a minute. Like, what's realistic? What should, you know, setting expectations with clients and on and on and on.

Yeah, so, so first of all, I would say if you have an existing relationship with a client and they've had an incident, you need to be thinking about that from an MSP perspective to say, what's the risk to you, right? So, um, you know, if you're involved in an incident and you do certain actions, is it looking like you're trying to cover your own tracks as an MSP? Always like to put out backups as a good example.

Um, you know, if you, if their backups didn't work quite right and you had to do some other things or get involved in paying the ransom, the rest store and backups were on the contract and that's what you were in charge of. And then, and then you did all these steps and think you come out golden in the end, but in, but really you didn't because you were responsible for those in the first place in the backups and they shouldn't have paid the ransom in the first place.

So those are those things that, that you need to, to address and to think about. The other thing is you need to be thinking about, again, I, I'll come back to this, and attorneys are very, uh, paranoid about this as the Capital One ruling from last year where they made a decision about, um, about FireEye saying that because they had an existing relationship with the client, that the work that was done, uh, fell outside of attorney-client privilege.

And so, so here you have an existing relationship and everybody got the attorney involved and everybody thought, Hey, attorney client privilege is fantastic. But then the, the court ruled and, and that wasn't the case. And so then they had to turn everything over. So there's a lot of things that you need to, to, to be concerned about when you're dealing with these things and, and incidents.

And it's always good, in my opinion, just like in a legal matter to get an attorney involved to give them that advice. It's, uh, I think it's always that way from an IR perspective to have that relationship. You might be able to still do the work in the IR firm like ourselves relies a lot on you guys to do the work, but at least you're not making all the calls independently and kind of making some decisions that you probably shouldn't be making.

And at least you should know, Hey, look, this isn't a decision independently you need to make as EMSP, the client needs to make a decision based on this. You can't just roll with it. And a lot of times clients are willing just to let you do whatever you want to do to get 'em back up and running. But, but that could actually be punitive to both parties if you do that, especially in today's world.

I mean, before the insurance carriers, uh, from a claims perspective weren't as, um, they didn't, they didn't scrutinize as much as they do now. Now they're really scrutinizing because the, the amount, the quantity of claims is going up and the amounts of claims are going up. So you bet your butt there looking at what you as the MSP were supposed to be doing prior to that person being attacked, or at least what you advertise as doing. 'cause that's another thing too.

I see a lot of people with packages with the name security in the name or secure this or secure that. And just by that perception alone, uh, they may think that, uh, you're doing something more than you're actually doing and, and that's gonna drag you into, into more of a problem than you wanted in the first place. Yeah. Okay. Um, move on from there and go to, here's, here's an interesting one.

Um, what liability, legal or otherwise does an MSP have if they help their clients put together an incident response plan? Uh, Eric, you wanna start off with that one? Yeah, so it's a good question and, and it's something that, that, you know, I used to ask my, the business people involved all the time, right? And, and the question is, what happens if our service fails? Um, and it doesn't matter what the service is.

Uh, you know, whether you're installing a wireless access point or providing managed services or, or creating, creating incident response plan. What happens if you don't do a good job of it? Um, and there's your liability, there's your potential liability in is in the answer to that question. Um, so should you stay away from it simply because, you know, a bad IR plan or an IR plan that leaves things out, um, could lead to, to excess liability, if you will. Well, not necessarily.

It depends what your MSA says. It depends how your MSA protects you from the potential of liability. Got it. Wes, you, uh, in terms of, of stuff like this, you fired an MSP back in your days. Did, did, did, was, was any of that part of, you know, I'm, this taping taking a huge leap here that they didn't have the chops to do these types of things. Any any comments for you on this Comment?

So, uh, Trent is on, uh, we gotta bring Trent on to talk about this, but Trent and I, Trent, you, you know, you're on, uh, and he and I have talked about this in the past.

I would love to do a talk called Why I fired my MSB and why I'd hire them again, because, um, if I'm sure Trent is, is probably getting ready to chat back in, but I saw him earlier, so I know he's on, um, you know, we ran through this whole situation at the bank where, um, we ended up asking, because our third party due diligence began to go up into the stratosphere, post target breach.

Keep in mind, this is back then in those days, um, we were asking so many questions of everybody and we began to do assessment of like, you know, hey, who has access to our infrastructure and what level of access do they have? You know, the big framework is like store process, transmit what applications, third parties, software, whatever, can store process and or transmit our data. And we began to think our MSP marks all three. Uh, that's pretty serious.

And so we started asking tons of questions and, you know, it was a struggle for them. It's not necessarily that they weren't doing it, but to have it captured and answered and documented was a big problem. And so we started going through this, and that's what led it was one of the things that led us to pull a, a bunch more things in house. And I remember sitting down with the CEO and, um, he came in and, and he actually banked with us.

And we sat down, we started chatting and he kind of interrupted me. He is like, Hey, you're firing me, aren't you? And we're like, I was like, yeah, cut to cut to the chase. Yeah. And he goes, good. He goes, 'cause if you weren't gonna fire me, I was gonna fire you. Uh, he is like, no offense, but you guys are asking us to do so much that we're just not prepared for. And, um, it's just, it's eating into everything we do. And, uh, so we, we amicably went, um, different ways.

Well, you look at the same MSP today, and they have a lot of banks in credit unions and shoot, they even have a cryptocurrency, um, uh, type of company that they work with that's heavily regulated. Uh, and how, what made that change for them to become such leaders? They said, you know, this was an opportunity for us to go back to the drawing board and say, wait a second, if we're not good at this, probably no one else is good at this either. This is like ERA 2014.

And so they decided they're gonna make some changes and, and learn to speak the language of regulation in banks, and they're better off for it. We've talked about that a lot on this, on this call. Um, but I think the, there, there's the lesson for us, Andrew, is like, um, and that's kind of the story I always use of why I fired my MSP and why I hired them again. Because sometimes we have to learn to go through these things and we become better off for it. It's not easy.

Um, but, but it is important for all of us to do. Yeah. Excellent. You, you hear a lot of MSPs, yes, we can do that. Yes, we can do that. Yes, we can do that, and then do it, and then figure it out after the fact legally. And that's kind of scary in today's world. Good stuff. Um, okay, this one, um, I hear from Beard a lot, so I'm gonna bring it up and I got asked today as well.

Um, how do you manage clients who do risk in who business in high risk countries, um, which, you know, they're insisting and they insist obviously upon it and allow, you know, we're gonna allow traffic hypothetically from China or Russia or whatever, right? Back and forth. Um, Ryan, you wanna give some thoughts, thoughts to that? Or, um, high risk countries, uh, do, do you guys get asked that on the RMM side at all? And if not, that's cool, we can move on to Eric or somebody.

I think you're on mute. Oh, you're, Oh, okay. Is Ryan on mute? Yeah, I think he is on mute. Okay. So ask the question again. I just wanna make Yeah, it's how do you manage clients, uh, who do business in high risk countries? And the th the same question for third party apps, you know, where they're insisting, right? Hey, well we, you know, we gotta have communication back and forth, uh, you know, with this, so It, it's a really interesting question.

Um, at, at Datto, we sell technology to MSPs who sell it, who either use it or sell it to their end customers, right? And we don't control where those MSPs sell that technology, Right? So we have that technology all over the world, um, literally in every country. And so one of the things we did when, when we were building the security program is say, where do, what countries do we actually have our technology in?

Not what countries do we do business in, but where's our technology actually deployed, right?

And then when you find that there's technology in a, you know, in a, in a country that, um, maybe is, you know, uh, is known to be risky or, um, that you feel might actually affect your, your risk profile or the threat actors in your risk profile, then I think that's worth the conversation to say, Hey, um, you're, you're in a country that has one of the, you know, let's take, um, Iran or Israel or China or Russia, right?

If you find your gear in that, in that location, or you have a customer in that location or a subsidiary of a customer in that location, then you gotta start asking yourself, what does that mean for me? What does that mean for my customer? Because them being in that country of origin is not just their risk, it's also yours now.

Um, and so you, you really need to understand or, or seek to try to understand what that may mean for you and what their business is, whether or not that's, you know, China, whether or not intellectual property, things that they might seek to steal, um, uh, you know, the type of infrastructure they're using within Russia. Um, you know, and, and the thing you wanna do is find yourself in some sort of situation where your collateral damage.

So I'm not sure if I answered that a hundred percent, but I think it's more about, you really have to understand where you are, what the, how that affects your risk profile and let that guide the conversation. I don't think it can just be, you know, we do business in a country that has sanctions, therefore, it, it's not a binary conversation, right? It needs to be informed, risk informed.

So I, I would say real quick on this, we come across it quite a bit and, and what we find a lot of times is when they have the connectivity between countries, let's just say US and China, 'cause that's an easy one. You start digging into the business purposes for that. And really it doesn't make any sense, right? They have this, like, they're all sharing the same active directory and doing all this kind of stuff, and they just need to share files once or twice a day.

And you're like, that could be done with secure FTP and not have all this integration within the networks. So I'm on, every single time I've done this, there is a, a simpler, and I will, I will bold, simpler, emphasize, simpler, uh, way of doing it that ends up being way more secure, uh, than this. And the tools really come and come, come, come to play, right? Uh, most people don't realize, you know, we talked about GDPR earlier.

When you're leveraging a, a, a tool with its console, most of these tool providers have a separate hosted portal for a US North American based tool than they do for the eu. And so those are things that you need to know about. And, and sometimes the vendors will step in and just tell you that, like, I just know, like carbon black for example. They, they just do that automatically for you.

Uh, but there are other vendors that may not, and knowing that is, is, uh, I mean we have, we have a client that has a German, uh, German presence, and they have, they're very, very specific to, uh, how things need to be done in German. So we actually have a person over in Europe responding to them. And only when it gets escalated to a certain level do our US employees then get involved.

So that's just like, uh, Ryan said it's not a binary issue, but it's one you have to really think out when you're an MSP and get to know the business reasons for doing those things. Okay. So let's go rapid fire here. I'm gonna run down 'cause ask some questions or in the questions. So, Eric, let's go with states.

With states us passing privacy laws is, uh, it's a, is it the, it it the safe bet to build policies, procedures off the most restrictive for notification of part of an incident based on the user of the company, notification on the state the client is located? Um, you, you could do that. I mean, I, I think you, there there'd be some states that are in competition for most restrictive or, or, or the, the toughest, um, laws. But, um, but you could do that.

I prefer to be more state specific and do what's, what's legally required by the state. So there's no difference in interpretation, especially as you get into questions about what is a breach, who's the, who is covered by the notification, and that where the data was, where the residency of the person is. Um, I still prefer to go on a state by state basis. Okay, good. Uh, I'm gonna, I hope I'm understanding this.

Assuming that an MSP who has an MDR tool and an event that has stopped business for one customer, what happens next? I'm not sure. Do you? I'm not sure I understand that, Jonathan, maybe you can give us a little re-Ask that question. Todd. Uh, encrypting sensitive info. How can we do that in such a way that the EXFIL data isn't usable to the bad guys? Wes, you're shaking your head. You got a thought.

Well, This gets into those con those conversations as well about, and I've seen this trend emerge as well lately around, um, like, uh, data exfiltration around, um, oh, what's the term Ryan, I'm looking for? Um, that is just, it, it lost me of, um, uh, protecting, um, uh, uh, finding data, leaking out, data loss prevention. There we go. It took my my brain a second. Look, these things are really challenging and there's no, there's no solution that you put in place to totally solve this.

Um, especially compounded with clout, right? And so, um, what you have to do, as in all things, is you must put best practice in place. It must be risk-based. And you must truly look at, yes, Tim, thank you DLP, um, what does it take in? How, how I'm never gonna have true perfect DLP unless, like I have a friend that works at the Pentagon, he can't bring this into work, he just can't. So end of story, right?

It's much easier if you're gonna go that that direction, but like ask that single question to, to be like, yeah, we allow phones at work. Are you really gonna stop the ability for screenshots? How are you gonna stop that? Like, it's not possible to fully eliminate all of this. Same with encryption.

So there's things that we must do, you know, for sure, you know, obviously encryption in transit and all things and you know, making sure we're aware of things like, you know, authentication and data data, uh, like outbound in non-encrypted means making sure that we're encrypting data at rest. There's many ways to do that. Making sure that we're asking our third parties how their encryption works, um, and certification standards.

But look, um, or, or even DOP instead of like what Microsoft controls on top, like I know a banks are really famous for doing this. Like, you know, even like word documents themselves are um, have digital rights protections on them. Like there's lots of stuff we can do. We just have to think what's that fulcrum of usability and security from a risk based perspective. Um, and go from there, right? Lemme me ask you this 'cause you probably can chime in. Can I? Because I the timeline?

Yeah, because it's more another encryption. So hold that, hold your thought for encryption at the server level, having drives encrypted potentially doesn't restrict the unauthorized access. How does it get handled in response to r back in place, but the data wasn't encrypted due to feasibility of encryption of drives, virtual environments, et cetera. So what you were gonna say, maybe kind of It is, yeah. So I was gonna say encryption is not a panacea.

In fact, it just creates two more sets of problems. One, it creates an availability issue. What happens if I lose the keys, right? And now how do I recover in that instance? So now you have to have a good key escrow and good key management practices, but also if the attackers in your environment took your data, you now need to guarantee they didn't access the keys as well. Because if I take your data and I take your keys, right, the only thing that that creates is because the data's encrypted.

I'm transferring larger amounts of data because I can't do the deduplication of the data, uh, because it's been encrypted, right? Um, so like you, you need to answer now where the keys accessed. And so I think someone brought up like Azure, um, I think in the cloud environments they're making like the key management key escrow stuff a little bit more easier to do.

Um, well, but if you're doing it yourself, um, you really need to threat model that because it can really give you a false sense of safety. Excellent. So here for Chris and to Eric, 'cause this is a good what you, you guys team up well on this. Chris, what would you say to an MSP that wants to go down the road of having an an an in-house IR team? Good idea. Bad idea. Starting off with you, Chris. You go Eric. Well just know what you're doing. Know what you're getting into.

I mean, I see a lot of people that just pick a piece of IR that wanna do it and, and it's all sorts of, it's just not well thought out and well planned. And I mean, that's what it comes down to do. I think there's a lot of MSPs that have those capabilities to kind of do do it potentially, yes. But it's usually not something you're gonna blend with the rest of blend in your existing employee staff. You're gonna have to have dedicated people and they're gonna have to do dedicated things.

And, and then you're gonna have to think of it out. I mean, uh, I I, I've come across ones that say they do forensics and you see what they've written up and it's not a forensic report whatsoever. It's terrible. Yeah. Um, and that's kind of risky, Eric. Yeah. And make sure that your contract's cover it. Make sure it's covered in your MSA, make sure it's covered in your style once you determine if it's something you can do well or not. Ryan, you were gonna say something?

Yeah, I was gonna say, I'm gonna double down on what I said earlier. If you're getting into incident response and forensics, don't do anything until you work on evidence preservation, right? That is step one of response is evidence preservation. You do not belong doing anything else in IR in forensics if you are not doing evidence preservation. Excellent. Alright, uh, one more here, uh, from Steven.

Are the state requirements to follow based on physical office location, say a branch office gets, is only one that gets hit? Um, or is it HQ assuming a different state? Or do you have to follow state by state of the offices, say data exfiltration, Eric wanna start and we can go to Chris?

Yeah, and Chris probably knows this better than I, it's been a while since I've looked into it, but it's definitely state by state and oftentimes it's the residents of the, of the residency of the person whose data is breached. Correct. Chris, that's that. No, that's exactly right. And so in today's remote work, uh, world, there's a lot more states involved now. Yeah. Because people have moved and hired people remotely. So it's a whole new bubble. Great.

So just real quick, um, with, oh, we were at the top of the hour. Was this good? I know it takes about 20, 30 seconds. Could you just give us a yes or no? Did you like this kind of format? Uh, open mic answering questions, should we do more of it? Just a wire end for those of you. Uh, greatly appreciate it. Thank you Steven. Uh, great question and thanks to everybody. Uh, closing out week 49 here, Wes with three to go, Ryan. Uh, and then special thanks to Eric.

Uh, people can get a hold of you if they have questions regarding MSAs or any other type legal things. Uh, I put your link below. Um, and obviously you guys probably know how to get ahold of Chris. Uh, if you don't let me know and I'll make sure you guys can. Alright. With that, everybody, have a fantastic week. We'll look forward to seeing you all next week. Thanks again. See you guys. Thanks.