Announcer: Welcome to the Cyber Risk Management Podcast. Our mission is to help executives thrive as cyber risk managers. Your hosts are Kip Boyle, Virtual Chief Information Security Officer at Cyber Risk Opportunities, and Jake Bernstein, partner at the law firm of K&L Gates. Visit them at cr-map.com and klgates.com.

Jake Bernstein: So Kip, what are we going to talk about today on episode 198 of the Cyber Risk Management Podcast?

Kip Boyle: This is one of those podcasts that I really enjoy. Thank you for putting this together. This is where we're going to take a really interesting lawsuit and we're going to look at what happens when a HIPAA business associate agreement gets tested in court after a ransomware attack. And for those of you who are watching, you could see that the episode title is Breaches within Breaches, and I love that. And so we're going to take a look at this lawsuit.
I love lawsuits because they let us see things that we normally don't get to see when there's a cyber breach of some kind. I love doing cautionary tales. That's what this is. We're going to talk about contractual obligations, incident response, and the importance of actually performing the security controls that you promise to customers and others. So Jake, this is great. Why don't we start with the basics, take it away.

Jake Bernstein: Sure. So this case is between a company called Molecular Testing Labs. We'll probably end up calling it MTL. It's a medical diagnostic laboratory. We all know these types of companies, right? But importantly, it's a HIPAA covered entity. And it's a HIPAA covered entity because it engages in HIPAA covered transactions, billing, insurance for medical, well, in this case, medical testing obviously.

Kip Boyle: But they're not a HIPAA covered entity in the old sense, which is to say-

Jake Bernstein: No, they are.

Kip Boyle: They're like an outsourcer to the medical community, right?

Jake Bernstein: So it's interesting. Medical labs fit into an interesting space. They technically have always been covered entities because they are effectively a form of healthcare provider. They're conducting-

Kip Boyle: That was the word I was searching for.

Jake Bernstein: Yeah, healthcare provider. So no, they are. It's a medical diagnostic laboratory, but it's a healthcare provider. They're independent. They don't owe allegiance to a hospital or A group of physicians. They're not a subsidiary. They are an independent entity, and they are an independent HIPAA covered entity. So that's kind of-

Kip Boyle: Okay, sorry about the diversion.

Jake Bernstein: No, no, it's worth it. HIPAA is very confusing. We've talked about it before. I'm sure we'll talk about it again. Okay, so the other company who goes by the name of Ntirety, which is just capital N-T-I-R-E-T-Y, Ntirety-

Kip Boyle: Took me a moment on that one.

Jake Bernstein: Yes, is their managed services provider and business associate under HIPAA. So let's just break that down real fast. Everybody listening to the podcast knows what an MSP is, managed service provider. Now, a business associate is actually a defined legal concept under HIPAA, and it is a service provider to a covered entity. And you have a BA, which is what we call a business associate, has independent obligations under HIPAA. And the covered entity and the BA must enter into a BAA, which is a business associate agreement. These are not new. These have been floating around, I mean, at this point, I think literally decades.

Kip Boyle: But what's interesting is in the cybersecurity sphere, we don't always get involved in that because these are really contracts and it's more in the legal world and the contracts management world.

Jake Bernstein: And I don't know why, because a BAA is fundamentally about compliance with the HIPAA security and privacy rules. And frankly more so, I mean both, right? I mean, we talk as if they are separate.

Kip Boyle: I've just noticed that in my work.

Jake Bernstein: No, no, I'm not disagreeing with you. You are correct.

Kip Boyle: They are handled differently.

Jake Bernstein: I guess what I'm saying is that we should draw a line in the sand as of today or whenever this airs, that you really shouldn't do that. I mean, a BAA though it's old, really needs to be looked at by the security team. And I'll add this, we did do an episode, and Kip, I'm sure you'll dutifully link it in the show notes at some point, about the potential updates, the proposed updates to the HIPAA Security Rule. If those go forward, if those are finalized, then a BAA is going to get even more detailed and it's going to become even more of a cybersecurity operational issue. It already is, don't get me wrong, but it's going to become even more so in the, potentially, not too distant future.
Okay, here we are, these two parties, MTL and Ntirety, entered into this BAA back in September of 2018. Now, the BAA, like all BAAs, was supposed to ensure that Ntirety would establish and implement appropriate safeguards for the protected health information it handled on behalf of MTL. And if that sounds a little bit like a canned phrase, it kind of is. There's many different ways of saying it. But that is the purpose of a BAA is to ensure that Ntirety complies with the HIPAA Security Rule, which requires them to establish and implement these safeguards.

Kip Boyle: And it puts them on the hook, right?

Jake Bernstein: Oh, yes, for sure. We'll get to that.

Kip Boyle: Okay.

Jake Bernstein: Okay, so fast forward to 2025. MTL receives information about a material data breach involving data that Ntirety was supposed to be securing under the BAA. Now, this is already bad news, but then MTL launches a forensic investigation and determines that, shockingly or not shockingly, Ntirety had suffered a ransomware attack. The article and the complaint both say potentially from Russian threat actors. The reason it says that is the presence of Cyrillic characters, which is certainly suspicious. I wouldn't say it's determinative, but it is-

Kip Boyle: It could be a false flag, but yeah.

Jake Bernstein: I mean, who knows? It almost doesn't matter, right?

Kip Boyle: Right.

Jake Bernstein: Now, this is the frustrating part about trying to do news reports on complaints is that the allegation is that Ntirety had "significant deficiencies, shortcomings, and omissions" in its procedures and practices that enabled the attackers to access Ntirety systems and therefore MTL's confidential information. Unfortunately, we don't have a ton of detail because the complaint doesn't have a ton of detail, and the case is not moving, well, I mean, it hasn't gotten very far yet.

Kip Boyle: But still, I mean, we're getting an initial peek at this.

Jake Bernstein: Oh, we're certainly getting an initial peek. And frankly, we can probably guess not that we're going to on this episode because it doesn't really add anything to the analysis, but the fact is that they fell victim to what was probably a pretty standard malware gang attack style.

Kip Boyle: Yeah. Yeah. Okay, so this is sounding pretty bad so far, but in our style, it actually gets worse, doesn't it?

Jake Bernstein: It does. It does.

Kip Boyle: Okay, so what happened after the breach was discovered?

Jake Bernstein: Okay, that's where things get really, I mean, I guess interesting, sad maybe.

Kip Boyle: Sad? Geez.

Jake Bernstein: Sad. I mean you're just like, "Oh." You see enough of this, you're like, "Come on guys, come on." Okay, according to MTL's complaint, Ntirety "failed to provide material support to MTL for weeks" after the breach was discovered. The support they did offer was allegedly provided, and I quote from the complaint, "slowly and incompetently."

Kip Boyle: Oh my goodness. Now I understand sad. Okay.

Jake Bernstein: Now do you understand sad?

Kip Boyle: Yeah.

Jake Bernstein: And here's why I'm just almost face-palm level, Ntirety informed MTL that it would be charging MTL for its incident response efforts. There you go. You actually face-palmed. See that?

Kip Boyle: I did.

Jake Bernstein: He did.

Kip Boyle: I did. For people who are listening to this and don't see the video, I face-palmed. I didn't even think about it.

Jake Bernstein: Yeah, he didn't. That's the best part is he couldn't help it because even though I literally just said that, you did it anyway, which is actually extra funny.
So where are we going with this? MTL argues that under the business associate agreement Ntirety was required to support MTL in its efforts to respond to and mitigate and remediate the security incident's harmful effects. It's pretty standard. So not only did Ntirety allegedly fail to maintain adequate security, but then they also allegedly failed to properly assist in the response and then tried to charge for that incompetence. Not a great look.

Kip Boyle: Well, and one of the reasons why I face-palmed is because based on the feedback that I hear when I'm talking to different customers that I have, nobody really likes their MSP. As a group, they don't seem to have very strong reputations.

Jake Bernstein: It's a tough business, Kip.

Kip Boyle: It is.

Jake Bernstein: It's a tough business. I think it's one that arose for a pretty clear market purpose. It's a tough business. I really know.

Kip Boyle: It is a tough business.

Jake Bernstein: There's really no way to say it.

Kip Boyle: But things like this don't make their reputation any better. And then we get to the part about the fact that the business associate agreement, the BAA, there was very specific language in there that they signed off on. And then they tried to behave in a way that was completely contrary to it. How do you get out of that? I mean, that's like people are not paying attention to what they're signing, are they?

Jake Bernstein: Okay, now we're entering into speculation land here for a moment. So this is going to be outside the-

Kip Boyle: But that's what makes the episode fun.

Jake Bernstein: Of course, and besides, people expect that of us. But you know what? It's speculation with respect to this particular case. But you and I both know for a fact that BAAs are one of those things that gets tossed around, in my opinion, way too often. They oftentimes will get signed, even though HIPPA doesn't even apply. I actually haven't done the full legal analysis on whether or not that matters. I actually don't think you can force compliance with HIPPA if it doesn't apply. Anyway, it almost doesn't matter. People sign these things because they think they have to without really reading it.

Kip Boyle: What do they call it? Performative or something like that. I don't know, there's a word. Anyway.

Jake Bernstein: So I think one of the issues here is costs. And fundamentally, this is a breach of contract. That's the point of a business associate agreement. It is a contract. And what matters is that specific language that any BAA, so if you have BAAs, you should look at this, what damages is MTL claiming?

Kip Boyle: Okay, so I've looked at this and I can walk us through it.

Jake Bernstein: Yeah.

Kip Boyle: So what I saw was significant costs and multiple areas. So let's go through it. So MTL has already incurred expenses for the forensics investigation, the digital-

Jake Bernstein: We expect that.

Kip Boyle: Yep, that's pretty straightforward and expected. They're anticipating costs associated with fulfilling the HIPAA breach notification requirements and providing credit monitoring services to affected individuals. Of course, MTL is also expecting harm to their business reputation, and they themselves are expecting lawsuits, regulatory action against them. So there's a lot that is either happening to them already or they really expect is going to happen. And I think that naturally they turn to their BAA because guess what? There's an indemnification provision that requires Ntirety to indemnify, defend and hold harmless MTL against losses and expenses due to a breach caused by Ntirety's negligence.
Now, by the way, I'm not an expert in indemnify, what does it really mean to defend and hold harmless? But I can tell you, as a small business owner, I stop when I see things like that in contracts people ask me to sign because dollar signs start dancing in my head. If something awful happens, this could really destroy my business potentially.

Jake Bernstein: And I think one of the reasons I wanted to do this episode is so that I could go into Professor Jake mode and talk a little bit about indemnification, this little phrase, indemnify, defend and hold harmless. And we've definitely talked about security theater on this podcast. I've lost track of how many times. If we had a full transcript, it would be entertaining to see how many times certain catchphrases come up.

Kip Boyle: Actually, that's not hard to do because every episode we've ever done is transcribed on our website.

Jake Bernstein: Oh, well, that would be excellent. Maybe we'll have to do that at some point.

Kip Boyle: We could point Claude's Sonnet 4.5 at it, and I'm sure it would do a great job.

Jake Bernstein: We could, I'm sure we could. So I'm going to introduce perhaps not for the first time, I honestly don't remember, the concept of indemnity theater or indemnification theater. And this is a really important concept because something you said a minute ago, Kip, I want to dig into that just for a moment here, which is, yes, they have this indemnification provision, but you also said that MTL in this case is expecting themselves to be sued or face regulatory action.
And there's going to be people listening to this podcast who are at least tempted to think to themselves, "Well, that's not fair. This was obviously Ntirety's fault." And to you, I say, you are correct. However, from the regulator and responsibility for the data perspective, the buck stops with the business, the data controller. And I know we've said this before, but it's worth repeating and frankly repeating over and over again, most breaches these days are probably caused by a third-party vendor of some kind.

Kip Boyle: Oh yeah, and we've got plenty of data that proves that.

Jake Bernstein: Oh, so much data. But you're on the hook. The party who hired the vendor is on the hook for that, and you're on the hook for that no matter what.
So let me explain then what indemnification actually does. This little phrase, indemnify, defend and hold harmless, now, look, we could write law review articles. Law review articles have been written about whether or not those are all the same. They aren't. Those actually are three potentially distinct legal concepts. However, they do often get run together. And for purposes of this podcast, which is not a scholarly legal publication, what I want to focus on is the idea of indemnification and defend.

Kip Boyle: Okay.

Jake Bernstein: So if you get sued, Kip, you need to hire a lawyer and you're going to start incurring costs right away. Now, if you are lucky enough to have somebody out there who owes you a defend, has promised to defend you, and it's somehow their fault, turns out that's great news. Because what that means is they will actually come in and hire and pay for the lawyer. That's a big deal because it means you aren't necessarily immediately incurring expenses directly to you.
Now, the reason why indemnity and the defend are different is that indemnification is really a cause of action that you can use. Once you've been injured, you make an indemnity demand or an indemnification demand to be made whole by whoever owes you that obligation. So these are different things.
The defend is like insurance companies. When you submit, I mean, typically that's who owes you the defend is the insurance company. That's the whole point, is that you don't want to have to pay for your defense. So the insurance company comes in and does it. And that's the whole insurance defense, legal industry and all that stuff. But the indemnity is different and the indemnity comes into play, you've suffered damages and you want someone else to pay for it.

Kip Boyle: Okay, so in this case, if I have reputation damages, right?

Jake Bernstein: Or your forensics damages. So the defend is actually very specific, defend a lawsuit. Maybe also potentially a legal investigation, but for sure, a lawsuit. Defend just generally, at least not to my knowledge, I've never seen this done, defend would not mean on its own cover the cost of a forensic investigation. So that might be an indemnification issue.

Kip Boyle: Got it. Okay.

Jake Bernstein: So that's what's going on here.

Kip Boyle: So there's a lot at risk here? Okay.

Jake Bernstein: There's a lot at risk here. So now you mentioned that, I mean, you said the BAA here included this indemnification provision.

Kip Boyle: Yep.

Jake Bernstein: So what MTL needs to do is send a formal demand for indemnification to Ntirety. That is the mechanism by which you say, "I've been hurt. It's your fault. And under this contract, you promised to indemnify me against harm caused to me that was your fault. Hence, I'm calling you out. Come do it."

Kip Boyle: Okay, but Ntirety didn't give any substantive response.

Jake Bernstein: No, they did not. According to the complaint, Ntirety provided no substantive response to the demand.

Kip Boyle: Okay.

Jake Bernstein: So here we are, we see the full cascade of costs that follows a breach, forensics, notifications, credit monitoring, potential litigation, regulatory action, business impact, everything. This is why covered entities need strong BAAs with actual teeth. So let's go through some of the key lessons for our listeners. What do you want to start with?

Kip Boyle: Okay. Well, there's so much here, and we haven't even really delved into this case, and already we can learn some things. So-

Jake Bernstein: Well, and spoiler alert, there's not a whole lot more detail for this case quite yet, but we are going to be getting into it.

Kip Boyle: I know, but you sent over the two complaints. I looked through them. There's a lot of, what do I want to say? Granularity. It's like-

Jake Bernstein: Well, to be clear, sorry, just to be clear, I sent you the complaint and the answer.

Kip Boyle: Oh, that was the answer? Okay.

Jake Bernstein: Yeah, the answer is the defense side's, and it usually just says, "Nuh-uh."

Kip Boyle: I know, but there's all this juicy little detail in there.

Jake Bernstein: There are. That's true.

Kip Boyle: And that's the stuff that kind of makes it real when somebody says they've provided no substantive response, we can go and read it and you can go, "Oh, yeah, that's silly." Okay, anyway, but let's look at some takeaways. So the first one is that if you have a business associate agreement, you have to clearly spell out the security obligations of the business associate, because it's really not enough to have generic language about appropriate safeguards. And I know safeguards is a word that irritated Jake. And you want specific requirements that align to the-

Jake Bernstein: I've accepted the phrase safeguards.

Kip Boyle: Oh, you've gotten over it?

Jake Bernstein: I'm done, I'm not going to fight it. Controls, safeguards, I don't care. Whatever.

Kip Boyle: Well, that's like me going cyber security? No, I'm not going to say I'm a cyber security person, but I lost that battle a long time ago, too.

Jake Bernstein: A long time ago.

Kip Boyle: Yeah, a long, long time ago. Okay, but listen, you got to have specific requirements in your business associate agreement that align with the HIPAA Security Rule. You don't want vagary in the agreement because that just causes trouble downstream. All right, so that's the first thing. And that means don't get a BAA off the internet and sign it. Oh my goodness.
Okay, so the second thing is incident response obligations, again, needs to be crystal clear. Things like what support must the business associate provide? And I mean exactly. And then who pays for what and how quickly do they have to respond? And these details matter because when you're in crisis mode after a breach, you want people to leap into action. But if your business associate agreement doesn't really make that completely clear, then the person can just take their time or show up late with virtually nothing to help you.
And the third thing is that these indemnification provisions, as we've already kind of unpacked a little bit here, but they're crucial, again, the need for clear language. Who's going to bear the financial burden when things go wrong? And you have to remember that indemnification is only valuable if the party on the hook actually has the resources to pay. And that's why I, as a small business, am often obligated to show proof of insurance. Because if I sign a contract that says I'm going to provide up to $1 million of indemnification, but I have no way to pay that, well, that's a false sense of security on the other party.

Jake Bernstein: It is. And that in a nutshell is the indemnification theater that I warn about, which is you can get someone who's too quick to just agree to indemnify you-

Kip Boyle: Without the means.

Jake Bernstein: ... it could be a routine business matter for them and they do it all the time and they have tons of money and it's no big deal, or they don't know what it means, or they know what it means, but they need the business. You just don't know, right? That's got to be part of the diligence.

Kip Boyle: There's a lot of people who sign contracts with not really thinking so much about it because they're just so revenue focused.

Jake Bernstein: Yep, that's exactly right. Okay, so there's another lesson here about communication during a breach, the articles that I read about this and the complaint itself all noted that it's unclear how or from whom MTL received information about the breach. So it's quite possible that if it didn't come from Ntirety, I mean that's generally a requirement. Now, maybe Ntirety didn't know. That seems unlikely. Usually if you're a victim of a ransomware attack, you did know. Of course in the answer, they deny all of this, and they say that the servers in question weren't under Ntirety's control or custody and what have you. It's unlikely that we'll get a whole bunch of super great detail and things that we can learn from this case. But the fact that the lawsuit was filed and that a responding pleading was done is a good reminder that it happens.

Kip Boyle: And I wouldn't be surprised if MTL found out about the ransomware attack because they had a service outage.

Jake Bernstein: That could be it.

Kip Boyle: Because Ntirety is supposed to provide IT services. And if those services aren't functioning, then you naturally are going to wonder, "Why the heck do my computers not work the way they're supposed to?"

Jake Bernstein: And I agree. Well, frankly, it doesn't matter if you're the covered entity or the business associate, typically, you need to understand what your contractual requirements are after a breach. A lot of people don't know. I mean, if you've done tabletops, Kip, then you might know because someone will have taken you through this exercise and you would've at least thought through what you might do.
I hope nobody scoffs at tabletops these days. But if you are a scoffer at tabletops, then it's the equivalent of saying, "Well, there's no point in military or firemen or police doing any training at all. What's the point because there's just no value? It's not real." You're right, a tabletop isn't real. It's no more real than a war game or any of the other stuff. But in a crisis, you do what you've trained to do. And by definition, military, police and fire services, I mean, when they're called into action, it's typically a crisis by definition. And the fact is that incident response is also a crisis. And if you have not trained, then you might not know what to do.
And this is one of those simple things that you learn very quickly doing usually in your first, maybe second tabletop is what are our requirements? What's our notification timeline and can we make it? So BAAs typically do require notification on a specific timeframe, somewhere between 24 to 72 hours after discovery of a breach. And honestly, even if you don't have a contractual requirement, if you're a service provider, you probably should say something to your customers.

Kip Boyle: You'd think so, right?

Jake Bernstein: Yeah.

Kip Boyle: You would think so. And if you're a publicly traded company, I mean, you're going to have to notify anyway.

Jake Bernstein: You will, you will.

Kip Boyle: Now, TTXs, I got to say they have a bad rap because quite frankly, they haven't historically been done very well. The people doing-

Jake Bernstein: I think that is an issue.

Kip Boyle: The people doing them are not doing them in a very compelling way. However, that doesn't mean you shouldn't do them. This is one of those things where I tell people who are decision makers, I'm like, "Look, a TTX is, you just have to eat these vegetables. I get it. You don't like eating vegetables. We want to go eat candy and chocolate. I understand. But sooner or later, you got to eat your vegetables. So you can eat these vegetables, which are not many, or you can wait and eat them when they come by the truckload and they're soggy and cold." Anyway, now the-

Jake Bernstein: And in Looney Tunes style, shoved down your throat with Daffy Duck jumping on top to shove them down. I mean, it'd be bad.

Kip Boyle: Yeah, but I think that's an apt image to put in people's heads.

Jake Bernstein: It is. No, I think it is absolutely a correct image.

Kip Boyle: And then communicating about incidents at a high level, make sure that you do that because hey, it could come around. The news could be leaked somehow. And then if there's any one thing people hate, it's being surprised by bad news, especially when it comes from a third party. Unfortunately, we have a lot of data that shows that most victims of breaches find out from third parties.

Jake Bernstein: Third parties, yep.

Kip Boyle: Which is awful, right?

Jake Bernstein: Yep.

Kip Boyle: Now, there is a balance that you have to strike, though, between being fully transparent versus not saying too much before you know the full story. And I know-

Jake Bernstein: That is true. I totally agree with that.

Kip Boyle: And I know. In TTX's, I've seen the public relations person saying things like, "No, we have to be more transparent. We have to share more information." And then I've seen legal counsel say, "No, don't do that because that could expose us to liability, and that could really hurt us in court if we ever end up in court."

Jake Bernstein: Plus, the other part of it is you don't know if that's the full story. That's the main issue here. The main issue is transparency is generally good, I like transparency, but transparency, you can't, what's the phrase? My wife's been saying the phrase. You can't put the toothpaste back in the tube.

Kip Boyle: Back in the tube.

Jake Bernstein: And that is such an apt phrase here. If you say something wrong, it's real hard to later go back and shove that back inside and be like, "Nevermind. Just kidding."

Kip Boyle: It is. So one thing I tell my customers is, "Okay, look, you should make a decision ahead of time before something awful happens. Are you going to lean towards transparency and create your plans around that? So you have holding statements and ways to be transparent without misstepping and saying things you can't take back? Or are you going to lean towards saying as little as you can get away with for as long as possible? And are your holding statements and your plan designed from that perspective? Because figuring it out in the moment is a bad idea."

Jake Bernstein: Bad idea, bad idea. So let's also come back, and I know we've been saying it a bunch, but just underscore why vendor risk management is so critical. And look, we've already mentioned this, when you're a covered entity, your business associate's security failings become your problem under HIPAA. You can have the best security program in the world, but if your MSP drops the ball, you're still on the hook, right? We've all said this.

Kip Boyle: And it's not just HIPAA, it's any regulatory regime.

Jake Bernstein: No, isn't just HIPAA. Now, this is something that we don't talk about as often as maybe we should, Kip, which is the concept of ongoing vendor monitoring. And I don't have a good answer here, and I don't know that you do either. But on the one hand, I know you can't just sign a BAA six plus years ago and assume everything will be fine, but what else can you do? And what does that look ... Kip face-palmed again.

Kip Boyle: It's a face-palm again.

Jake Bernstein: It's two in one episode.

Kip Boyle: Yeah, because as soon as you said that, it reminded me that in my book, and when I talk to people about this, I say, "I get it. It's fun to be on the happy path all the time. I'm going to make this investment. I'm going to do this partnership. I'm going to take this risk and everything's going to turn out. And we'll be profitable and we'll grow and everybody will love us, and I'll finally get that jet I've been thinking about. But if you don't take a moment to think about what could go wrong," that's really what we're saying here, right?
Negative visualization is one way to think about it. And this is something Aristotle was trying to teach us from millennia and millennia ago is you have to at least think about what could go wrong. And then can I test that somehow to see if it'll go wrong? Should I just have a plan in case it goes wrong? You really need to.

Jake Bernstein: Our mutual friend, Adam Shostak, has become the expert on threat modeling, which is just negative visualization.

Kip Boyle: That's right. That's right. I was giving a talk to about 200 credit union board members and senior decision makers just last week. And I said to them, "Look, you don't need to be an expert in cyber risk to ask great questions. You don't need to know how your data backups are happening or what vendor you're using or how you configure it. None of that's important. What's important is that you ask the question, what are we going to do if the backups don't work? And how do we know that they do work?" That's all right.

Jake Bernstein: It is true.

Kip Boyle: So ongoing monitoring can just be as simple as that.

Jake Bernstein: It can. And let me ask you this, Kip, too. CMMC or something related to it, it was FedRAMP, has the concept of continual monitoring or continuous monitoring. It's not really the same thing. I mean it's related. But my question for you is, and I know we've talked about this with some of our mutual clients, what can you actually do? You're not going to do pen tests on your third party vendors. You can ask for SOC 2 reports. I mean you should before you onboard them, do some kind of security assessment and maybe even require evidence of specific controls.
But Kip, there is a major, I would just say general market failure in this space because you and I both know having been on both sides of these issues, that some SOC 2 attestations are worth the paper they're printed on, some maybe aren't, the same with a security assessment, whatever that even means. Is it just a questionnaire? And then we do want to talk about the MSP perspective for a moment. And by the way, I do want to say I have no idea if Ntirety is liable for this or not. We don't know.

Kip Boyle: No, we just have two people in conflict right now.

Jake Bernstein: Yeah, we just have a complaint and the answer in a lawsuit. That's all we have. And we already agreed that being an MSP is tough. I do think though, that the MSP needs to understand that HIPAA obligations are real and enforceable and that the BAA will be used. But before we move on to that and start to wrap up the episode, I do want to press you, Kip. In your, we'll just say your venerable years of experience, have you even seen the beginnings of a workable vendor monitoring framework?

Kip Boyle: Yeah. Well, a framework? No, not a framework. What I've had to do though is I've had to think about testing claims. So I guess if you want to think of it that way, how do you test these claims that are contained in these contracts? And I'll give you a non-business associate agreement example, but I think is illustrative.
So you and I have a joint client and they have outsourced their security operations center. So network security monitoring, they've outsourced it. And I have said to our joint client many times, how do you know you're getting your money's worth? And the way we've chosen to do that is every year we conduct a pen test to just check defenses, I mean, what you normally would do a pen test for.
But as part of that process, we also are on the lookout for the security operations center to send alerts, hey, somebody's scanning your network, somebody's inside your network rattling all the doorknobs. You ought to go check this out. But every year, we do the pen test, no, we get no alerts from this network monitoring service that supposedly should be monitoring.

Jake Bernstein: It doesn't fill one with a warm and fuzzy feeling of confidence, does it?

Kip Boyle: No. And so guess what? In the last three years, they've changed outsourced security operations centers three times because going into the agreement, they tell them, this is what we expect. And then months later we do the pen test and they get no alerts.

Jake Bernstein: Yeah, Kip, honestly, I think you've identified an even tougher and worse business than being an MSP, which is being an outsourced security operation center. I get why the market wants to do outsourced SOCs, but I'm not convinced the concept is sound.

Kip Boyle: There is economic disincentives in play for that whole thing to work, but I think the big reason why it's happening is because it's checkbox security. It's security theater. I've done it. It doesn't do anything, but I can say I did it.

Jake Bernstein: No, and I think that is correct. And I think there's certain things I think you just have to do yourself.

Kip Boyle: If you can. If you can.

Jake Bernstein: If you can, yeah.

Kip Boyle: But anyway, so I think lacking a cohesive framework, testing the claims that these outsourcers are making is something that you should be thinking about. That's what we think about. Also, I think that going into the outsourcing arrangement, you need to reserve certain testing in the contract, right?

Jake Bernstein: You do, audit rights.

Kip Boyle: Yeah, audit rights.

Jake Bernstein: And audit, I mean, yes, the generalized phrase is audit, but you need to be absolutely clear. And ideally, you would even build in things like one, we don't have to tell you when we're testing. And two, you could also build in if you don't already have it in there, to avoid arguments, I would build in, if we test and you don't notice, we at least have the option of canceling without further obligations and possibly even request a refund depending upon how you've paid. I think these are all things to consider.
And I think also, Kip, you're a hundred percent right, the testing I think is really, really critical here because there's no other way to do it, right?

Kip Boyle: No, it's a black box.

Jake Bernstein: It's a black box. If all you do is give a security questionnaire and accept the signed BAA, you don't really know.

Kip Boyle: No, you don't, not until something awful happens. And then you're MTL. Then you're MTL filing a complaint. And then the other aspect of this too, I think this is where CISOs really struggle, is when you outsource something, you no longer have direct observation. You don't control how that work is done, which is really important because if I say, I'm going to encrypt this data, well, how you encrypt it matters. But I don't get to see that when I outsource something. So it starts to feel super abstract, super ethereal, and kind of like I'm grasping at air going, "How do I do this?" And you have to do it through a contract. And that contract has to be really well done in advance.
And so what I have to do as a CISO is I have to develop a very good working relationship with the contracts manager at the company that I'm working with so that I can make sure that the audit rights I need are in those documents. Because the contracts manager may not realize that they need to be in there.

Jake Bernstein: And I think as we now truly do begin to wrap up here, I think the bottom line from this case is simple, contracts matter. When the excrement hits the rotary air impeller, the BAA-

Kip Boyle: Another face plant, I can't believe you used that.

Jake Bernstein: ... the BAA is not just a compliance checkbox. It's this critical risk management tool that defines who does what, who pays for what and what happens when things go wrong. And look, there are many legal and regulatory consequences to a data breach. That's not news, right? Everybody knows that. But with adherence to contractual obligations and appropriate communications, a breach of contract claim doesn't have to be one of them. There doesn't have to be breaches within breaches.

Kip Boyle: Right, no, there doesn't have to be. So, all right, great. So very well said, Jake. And I guess that does wrap up this episode of the Cyber Risk Management Podcast. So today we discussed a very instructive lawsuit that's going on between a HIPAA covered entity and its business associate, and it followed a ransomware attack. And we never even talked about the ransomware attack and inaudible

Jake Bernstein: It doesn't matter. It almost doesn't matter.

Kip Boyle: I know. We covered the importance of clear business associate agreements, BAAs, incident response obligations, indemnification, vendor risk management, all that. And by the way, before we close this out, Jake, I want to say that one thing you taught me about third-party risk management is bucketizing or categorizing, right? Don't treat them all equally.

Jake Bernstein: Oh, goodness no.

Kip Boyle: Put them into categories, right?

Jake Bernstein: Yes.

Kip Boyle: Who's really most important, who can really mess up our day? And put extra scrutiny on them. And anyway, we'll talk about that some other time.

Jake Bernstein: We will. Now, Kip, even though you tried to wrap it up, at the risk of adding a few more minutes, I do want to say now that-

Kip Boyle: Okay, okay.

Jake Bernstein: Well, I'll wrap it up like this. The company that delivers your water to the water jugs does not need to be dealt with in the same way that the company that is doing your monitoring, your 24/7 SOC. Put another way, you may have a lot of vendors and you may be thinking, "Well, there's no way I can do comprehensive cyber risk and vendor risk management on all of them." You probably don't need to.

Kip Boyle: No, you don't need to.

Jake Bernstein: But you need to put them in buckets and categorize them. So, okay, now, Kip.

Kip Boyle: All right. Thank you everybody for being here, and we'll see you next time.

Jake Bernstein: See you next time.

Announcer: Thanks for joining us today on the Cyber Risk Management Podcast. If you need to overcome a cyber security hurdle that's keeping you from growing your business profitably, then please visit us at cr-map.com. Thanks for tuning in. See you next time.