Speaker 1: Welcome to the Cyber Risk Management Podcast. Our mission is to help you thrive as a cyber risk manager. On today's episode, your virtual chief information security officer is Kip Boyle and your virtual cybersecurity counsel is Jake Bernstein. Visit them at cyberriskopportunities.com and focallaw.com.

Kip: Hey Jake, what are we going to talk about today?

Jake: Hey Kip. Today, we're going to discuss an April, 2021, New York Department of Financial Services consent order with a company called National Securities Corporation, resulting from an investigation under the cybersecurity regulation.

Kip: The National Securities Corporation, I mean, that's pretty generic, man. It sounds like a drug front to me, but probably it's real. No, I know it's real. I've seen the order. But okay, listen, before we start the show, we need to make a brief announcement for the attorneys in our audience.

Jake: That's right. It's our CLE ad. And if you've been listening to our podcast, you are probably aware of what we're about to say, but we're going to do it anyway.

Kip: People need to be reminded.

Jake: They do. If you're a lawyer, imagine your client asks you, "Hey, our competitors just got hit with ransomware. It's been a few weeks and they still don't know when they're going to be back up online. How do we avoid that kind of thing?" What would you tell them as their lawyer?

Kip: And maybe that's already happened to you and maybe you felt like you weren't really sure what to say, or maybe you figured that out for yourself, and if you have, that's great. But what would happen if a client called you on a Saturday night late and said, "Yeah, we've lost control of all of our computers and every screen in our building or multiple buildings has a ransom demand on it. And $500,000 seems like a lot of money and it's going to double to a million dollars if we don't pay it in seven days. And there's all kinds of other threats, what do we do?"

Jake: Well, that's a good question. What do you do? And if you want to figure that out, you should join us online for a one hour cutting edge CLE on June 23, 2021, at noon, Pacific time, 9:00 AM Eastern, 10:00 AM Central, where Kip and I will teach you how to begin to answer these increasingly common questions.

Kip: Right. Okay. So listen, in this session, it's just going to be ordinary language, not ones and zeros. And what we're going to do is walk you through two actual ransomware incidents that Jake and I have handled, and guess what? They sound strikingly familiar to the questions that we pitched to you just a moment ago. We're going to tell you how the attack started, how the victims recovered, and we're going to explain the role of the attorney throughout an incident like this.

Jake: In addition to one CLE credit, you'll receive actionable advice that you can use right away.

Kip: Yeah, exactly, in your practice, and what we're hoping is that it's going to allow you to serve your clients better. So you need to sign up for this, and the way you do it is super simple. You just go to b.link/cle. So that's the letter B and then dot L-I-N-K forward slash C-L-E. And listen, if you're not an attorney or if you aspire to be an attorney, everybody's welcome. So if you want to come and hear about this and you're not an attorney, that's perfectly fine. So sign up and we're looking forward to having a wonderful session. Okay. Let's get back to our episode.

Jake: You bet. So let me just state clearly, again, that this is another one of those legal episodes, but just like our recent episode on class certification, this one is also really important and I think very instructive. Though the NYDFS cybersecurity regulation order we'll be discussing today isn't particularly unique, and it certainly isn't the first one, is nonetheless very relevant to our listeners. And just to make it clear now, if we say New York DFS, or NYDFS, that refers to the New York Department of Financial Services, and that is the New York State regulatory body that covers Wall Street and banks and insurance companies and things like that.

Kip: And it's kind of like California's law in the sense that you might think that on the surface, it only affects people who are, is it domiciled? Is that the correct term in New York? But actually, it doesn't. It actually has nationwide implications, right?

Jake: It does. Well, you need to be a covered entity under the regulation. And so there's different ways of that, but we're really, in this particular episode, we're going to focus more on a specific order. And Kip, why don't you tell us who is National Securities Corporation?

Kip: Oh, yeah, absolutely. Well, they're not a drug front. That was just me being lippy in the beginning, as I sometimes do. I just find their name to be really funny because they don't have much to do with national security or stocks or bonds or cyber security. Yeah. This non-descript name is actually on the company that does insurance. So you can buy life insurance, you can buy accident insurance, health insurance, variable life, variable annuities, blah, blah, blah, all this insurance, in New York State, and they're licensed by the Department of Financial Services to sell those products. So they are in fact a covered entity, right?

Jake: That is correct. And what's really interesting is that the department begins its order with a series of recitations describing the background. And they remind everyone that their cybersecurity regulation is first in the nation. And it dates back to August, 2017, which maybe feels like a long time ago, maybe it doesn't. But this is true. I remember when this regulation came forward and was passed and it was definitely first in the nation. It predates obviously the CCPA, it predates the New York Shield Act, which came later. And we actually did-

Kip: It's funny that you'd say that Jake, because it actually did read a little bit like a press release. I was kind of surprised.

Jake: Well, you know, they're setting things up, I suppose. I believe that we have a back episode about the New York DFS cybersecurity regulation. And if people, we're not going to rehash that, but you can go find it in the archives. The interesting thing about the regulation is that it borrows heavily from the NYSCSF. it was very much involved in that.

The other thing is that unlike many of the other regulations and statutes that involve cybersecurity, the cybersecurity regulation in New York is, I'd say a lot more specific. And you're going to hear that. This case is primarily about the failure of National Securities Corporation to implement multifactor authentication for its email servers and kind of access overall, including third party applications. In addition to those two failures, they also failed to notify the department of a couple of cyber events in, one in 2018 and one in 2019. And, and this is really interesting, falsely certified compliance with the cybersecurity regulation for the calendar year 2018.

Kip: Ouch. That's something unforgivable. I mean, they could probably go with a little hand slapping on the actual issues here, but to falsely certify, I think kind of makes regulators extra angry, right?

Jake: It does. It's a really easy way to get yourself in, I think, pretty substantial trouble, is to say you're doing something when you're not.

Kip: Oh yeah. And it's so tempting to do that. I mean, I won't lie. I've had to sign things. Even in the last episode, when we talked about the insurance application, we really pointed out the fact that whoever's responsible for the network security of the organization that's trying to get the policy, had a separate little section where they had to attest that everything they put on that application was absolutely true. And it's so easy to just check the yes box when you think that's what the regulators or the insurance underwriters actually want to see. And it's just so easy to do that, but it gets you into a world of hurt if something bad actually happens.

So, yeah. Ladies and gentlemen do not, don't give into the temptation. You're going to see a little bit about why that's not a good idea in this one, so you want to dig in?

Jake: I do. And there's some really, I mean, we'll talk about this, but I think, there's a reason for are certification requirements and putting things in writing. And even though it might seem to be a bureaucratic requirement, it actually is important and I think we'll see why.

So, to kind of dig into it, as you may remember, Kip and the audience, the NYDFS cybersecurity regulation places an obligation on all covered entities to "Establish and maintain a cybersecurity program designed to protect the confidentiality and integrity of its information systems, as well as any consumer, non-public information contained therein." And this is a fairly standard definition, but I think what's interesting about the regulation is some of the other definitions. Why don't you tell us about cyber security events, because this one's kind of curious.

Kip: Yeah, yeah, absolutely. Okay. Now let's see here. 72 hours, that's how long you have to report the incident to the super superintendent of the department. But, gosh, we've seen these kinds of things before and it's a little confusing. I mean, when does the 72 hours start? And then the other thing is, you have to report something to some remote supervisory body, so you also have to tell the superintendent of the DFS, right?

Jake: Yeah. That is a little confusing how the rule reads. My read on it is that, if you have an obligation to report to some supervisory body, whether it's a government or self regulatory, you also have to tell the DFS. One thing I want to point out though, is that the way that they define cybersecurity event, it's a act or attempt, whether or not successful, to gain unauthorized access to information stored on an information system or disrupt or misuse such information system.

Kip: Yeah, that's an overreach, man.

Jake: Well, I was just going to say, I mean, I don't want to spend a great deal of time on that, on this definition, but let's talk about for just a minute. If you were to take this literally, first of all, I don't think the DFS actually wants anyone to this literally, because-

Kip: I hope they don't.

Jake: if they did, Kip, how many notifications do you think the DFS would be receiving on a second by second basis?

Kip: That's just the thing, if I took that literally and I was working for a covered entity, I'd have to just send logs to them. I mean, that's the only way I could do it.

Jake: Constantly.

Kip: Right. I'd have to say, "Where do you want me to send my log feed?" Because I couldn't possibly keep up because guess what? Every Tom, Dick and Harry is assaulting my firewall all the time, all day, every day of the year.

Jake: And I understand what they're trying to get at is, with this language of whether or not successful, but the problem is, and I've seen this before, this is kind of a clash between someone who wanted to write a legal rule that they thought would be helpful, but I don't think they understood the kind of operational reality. And this is a theme of our podcast and how we work together is, you really need to be aware of both the law and the legal requirements and operationalizing-

Kip: That's right.

Jake: those requirements.

Kip: Yeah, absolutely.

Jake: Here's just a classic example of a well-meaning, but I think, basically-

Kip: It's kind of naive.

Jake: It's a naive definition. Because surely you don't want me to tell you every single time someone attempts to gain access unsuccessfully.

Kip: No, they don't. And I get that and I would not ring them up and say, "Hey, where do you want me to send my log feed?" What I would do instead is I would try to make a reasonable interpretation. Okay. What do they really want? And I think what they really want is something more material. What they really want me to do is to report to them the material attempts, the stuff that would alarm me, as opposed to just this random door knob rattling exercise that goes on every second of the day.

Jake: Exactly. I think that's a fair interpretation. And the good news is that as a regulation it can be changed. It's not quite like a law where it has to go through the whole legislative process. Rule making is faster in theory. So that could be fixed. But I think it's worth pointing out, nonetheless.

Kip: Yeah, yeah, yeah. No, I do too. Because it's a theme, right? What we're doing is we're highlighting this theme, that is a constant... There's a constant gap, a chasm between what the regulators are trying to do and how it actually ends up looking to an operator like me. And so just thematically, we're just going to keep seeing this over and over and over again. So I think it's worth taking a moment to point out that as an operator you have to try to interpret these in the most respectful way.

Jake: You do. And the same issue is present, as you mentioned, with the 72 hour notice provision. I mean, what does that mean? 72 hours from when? These things, they're never binary, where you suddenly just know. I mean, it's a series of steps of learning about an incident, particularly given this definition.

Kip: And that's a good foreshadowing, actually, of the continuing legal education that we're going to be doing, that we talked about a moment ago. And we are encouraging people to sign up because guess what? We actually had to wrestle with that. We actually had to figure that out.

Jake: Oh, yes. Absolutely. Actually every time there's a breach, you have to think about it. It's a common thing. Let's go ahead and move on.
One of the other requirements here that I wanted to bring up is, I think one that is probably underappreciated and I'm sure it's extra irritating, but I think it has the potential to be really, really effective, and that's the certification of compliance with the cybersecurity regulation on an annual basis. And this idea, it is beginning to spread.

Kip: Well, HIPAA has something like that.

Jake: They do. And even though they didn't pass, I believe both... I know the Washington Privacy Act had something along these lines and I believe the Florida statute might have as well. Although I could be wrong on that. It changed so much. It's hard to keep track of all the different versions particularly when they don't pass.

The bottom line though, is that this idea of certification... And oh, by the way, it absolutely has, it reminds us of the FTC consent orders that we've talked about more recently. The FTC has been adding in this requirement that, hey, you need to certify compliance with your information security program. It's pretty interesting. And I think that it's a good thing, a good reminder.
Now, let's dig into the more specific area here, unlike, for example, the CCPA, which just says, reasonable cybersecurity measures, the cybersecurity regulation here in New York goes into quite a bit more detail. So much so that section 500.12 specifically requires that covered entities implement multifactor authentication when there is external access to a covered entity's internal network. So Kip, what do we think about that?

Kip: Well, I think it's actually pretty commendable that the regulators in New York State realize that that's actually a really valuable control. It's really... It's so material. If you go back and listen to any of a number of episodes that we've done, including, I'm thinking specifically of we did one on the essential eight that was published by the Australian Signals Directorate. Multifactor authentication is, I mean, it's a huge way, if you turn it on, it's going to help you become a difficult target. There's no doubt about it.

It's not to say that multifactor authentication is bulletproof. It's not. And I'm sure that as more people turn it on, the criminals will find ways to attack it and subvert it. I mean, we already know that multifactor authentication by a code that gets sent to you by text message, we already know that you can tamper with that. And I'm sure they'll find other ways to tamper with other ways to do it. But I think it's great that it's in here because it works. It's practical and you should turn it on, even if they don't tell you to.

Jake: I agree. And what I like about it too, is also that it's not a specific technology, which I think it's never wise to legislate use of a specific technology. Instead, it's a well recognized security concept, right?

Kip: It's a principle

Jake: It's a principal. That's exactly the word I was meaning to use. Thank you for providing it.

Kip: And I want to take a moment and talk about that because, I look at CISSP, I look at CISM, I look at, there's all these certifications that teach people how to be cybersecurity professionals. What they tend to be deficient in is teaching principles. And if I can learn principles, then I can walk up to just about any technology, any situation, and I can use my principles to figure out, what do I need to do here? And then I can grab the technology that's most appropriate for the situation. So I love it when we talk about principles, because they're timeless and enduring and the seminal paper on principles that I still follow was published in 1974.

Jake: Yeah. It's a really good point. And I think multifactor authentication is not, people may think that it refers to a technology, but in fact, it really, as you said, refers to a principle that it's a form of authentication with an extra component. That's all it is.

Kip: That's right. Yeah. It's just, it's two or more things that you have to present, something you know, something you are or something you have. I mean, and that's what it comes down to. Back in 1974, when those principles were published, we didn't have biometrics, but we do now. So we've got facial recognition on the iPhone and on and on and on. So the technologies and the products can change, but the principles are enduring.

Jake: Exactly. So it's a good reminder about that.

The MFA here, in this particular case, they just didn't do it, at all. And because they didn't do it, they had a number of cybersecurity events. And what's interesting is you go through the findings of fact in this order, and there's two cybersecurity events that are discussed where clearly National Securities Corporation reported. These are the two that they reported. So one of these was a fairly simple kind of phishing email attempt where someone gained unauthorized access to an employee's Office 365 email account. Now, immediately the New York DFS is saying here that the non-public information of customers was potentially impacted, they don't know for sure. The National Securities Corporation did contact all potentially impacted individuals, but they didn't have MFA implemented for Office 365. You can't do that. I mean, this is such a basic component. That's why I'm so happy to see that it's required.

Kip: Yeah, but multifactor authentication, not everybody likes it. Despite all the virtuous aspects of it that make me love it, if you're not used to it, well, quite frankly, it's a pain in the ass when you first do it, especially if you've got to receive a code, you've got to read that code and then you've got to type it into a box. And people who, I mean, it's annoying to anybody, particularly people who are vision challenged in any way or who don't type straight most of the time, so it's going to slow you down. And I can only imagine that the reason they didn't have it turned on was because of managerial concerns of productivity and just people's just being irritated by the idea that they have to add this into their workflow. Those are very common objections.

Jake: They are, they are. So that first event was in kind of September, 2019. It wasn't discovered until... Actually it was discovered in mid-September, they didn't report it until almost a month later. The second cybersecurity event, again, that was reported was in middle of actually May 2020, about a year ago, and this one was worse. The previous one, it was kind of a... They gained access to an email account, could have been bad, might not have, but this one is something that I'm very familiar with. I've actually had a few clients call me about this, that there was an affiliated independent contractor, a broker actually, who noticed a potential unauthorized transfer of funds from a client account for $200,000. And after this broker noticed this and they began looking into it, they found two other unauthorized transfers in the same amount.

What happened, and this is very, very common. Again, probably as a result of a phishing scheme, someone had gotten into this broker's email account, Office 365, again, which didn't have MFA enabled, and set up forwarding rules and Kip, why would threat actors set up forwarding rules in an email account?

Kip: Oh yeah. Just like you said. I mean, this is just common technique. And the idea here is I want to send messages as Jake Bernstein and scam people into moving money, but I don't want the real Jake Bernstein to know that I'm doing this. I could buy a lookalike domain and try to do it completely separate from your system, but if I can actually hijack your account silently and then put in some rules, which are not all that sophisticated, but if I can put in some rules so that you never see. Jake never sees Kip, the intruder, sending or receiving messages, where I'm having all these conversations in your name, then you have no idea this is going on, that somebody's impersonating you with your actual account.
And this is really good because if I'm receiving messages from Jake and I'm like, "Ah, these, these look kind of shady. I don't know." And I inspect the email headers and all that stuff, it's going to have an air of absolute legitimacy, because why? They're actually using your account. It's not a lookalike or anything like that. So this is really common, and that's what MFA does, is it severely drives down the risk that that's going to happen to you.

Jake: Exactly. And so in this particular situation, the company ended up losing $400,000 because, even though they caught the one, the other two went through.

Kip: Once the money's gone, you don't have much time to stop it.

Jake: It's gone. Yep.

Kip: And by the way, let me say something about that. So the FBI is actually very good. If you detect this within 24 hours of it happening and you called the FBI, you call the Cyber Crimes Task Force, there's a good chance that if you do it within 24 hours, they'll be able to stop the wire or get it back. So that's something you should know.

Jake: It is, yes. Call quickly, for sure.

Now, this one was interesting insofar as when National Securities Corporation did the investigation of their affiliate, different company, technically, they determined that that broker's Office 365 account was compromised from March 23rd through April 30th, 2020. So you're talking a month and a week. Obviously, the non-public information of customers was impacted. They had to personally contact all potentially impacted individuals again. And this one must have been frustrating to National Securities Corporation, because they had internally migrated all of their employees over to Google Workspace and implemented MFA. But the affiliated independent contractors had not yet been migrated over to, I guess, what was then called G Suite. Now look, just to be clear, there's no reason why you can't have MFA in Office 365. I mean, that's been around for a long time.

Kip: Correct.

Jake: They just didn't do it.

Kip: Yeah, that's right.

Jake: So this is not a technology problem.

Kip: Right. Now, that hearkens back to a recent episode we did when we busted cloud security myths. So I want to be really, really clear here. It is not Microsoft's fault that you didn't turn on MFA. That's part of your responsibility. That's the shared responsibility security model. They make MFA available, but it's your job to turn it on and configure it.

Jake: Yep, exactly. So, the order then goes through the relatively straightforward application of 5oo.12B, which is the requirement for MFA, for any individuals accessing a covered entity's internal network from an external network, which applies to third party applications, including email platforms like office 365, like Google Workspace, et cetera.

Kip: And others, all kinds of cloud services would be affected.

Jake: Exactly. What National Securities Corporation got dinged for here was that even though their in-house folks had been moved over to G Suite, the independent contractors wasn't completed until, I mean, almost a year later in... So National Securities completed the migration to G Suite for all of its corporate employees around November, late November, 2019, but it took almost another year, August, 2020, for them to get all the independent contractors over.

Kip: And I don't find that surprising at all. That is pretty dang common in IT land, not surprised by that a bit. But the fact that they turned on multifactor authentication in G Suite and still didn't turn it on in O 365 is not good. But again, I understand why. I understand why they would do it. They would slip it in. They would say to their workforce, "Okay. So we've got you on G Suite now. And hey, as long as we're making a change to a new email system, we've also turned on MFA."

Well, so what they've done there right, is they've kind of hijacked the email migration as an opportunity to turn something on that if they had tried to do it outside of the migration, people would not have been as willing to accept it. But you kind of like slip it into another big change and it's more likely that people are going to roll with it. And so that's probably what they were waiting to do with the O 365 migration for their external partners.

Jake: What's really interesting here is that the... we don't have a ton of details, but what this says is that, National Securities did have some controls designed to protect the Office 365 environment. We don't know what they were. What we do know is that these controls, and this is just a quote, fell short of the section 500.12B standard of "reasonably equivalent or more secure access controls."

And then the other thing that happened here is that the DFS here calls out the National Securities Corporation, CISO. They say that National Securities did not present sufficient evidence that these controls were approved in writing by the entities CISO, as required by section 500.12B. So, this is one of those things where writing stuff down really does matter.

Kip: It really does. Especially when you get caught up in something like this, if you don't have evidence that you did stuff, then you didn't do it. I mean, from a regulator's point of view, if it wasn't written down, it did not happen. I mean, my gosh, that's been a principle in government and in government oversight organizations since long before Kip and Jake ever showed up.

Jake: Exactly. They also talk about how the National Securities Corporation used more than 60 third party applications that contain NPI or have access to National Securities internal network.

Kip: And I'll bet you, they didn't even understand. I'll bet you National Securities, if you had asked them before this, how many, how many of these third party apps do you think you have? I don't think they would've known it as many as 60-

Jake: Probably not.

Kip: And it's probably well more than 60 because of shadow IT and how easy software as a service makes it for somebody to plunk down a credit card and turn on services. In fact, we just had a conversation about this with one of our joint clients, did we not?

Jake: We did. Here's what I love about this order. And again, more detail would always be nice, but it says, specifically talking about MFA, they're saying that National Securities hadn't completed the MFA rollout for some of these applications. And in fact, one application remained without MFA as of the data of this consent order.

Now, and here's where it gets back to writing things down and performing your risk assessments, and then recording decisions that you make about risk. And the reason that's important here is that the National Securities CISO still hasn't approved, or hadn't approved, any reasonably equivalent or more secure access controls for any of these third party applications, even though they did have some access controls to reduce the risks.

Kip: Some people just don't like to write stuff down, I guess.

Jake: Well, I mean, there's a lot of administration that goes into this.

Kip: There is.

Jake: But I think this order is such a reminder of that. And the unreported cyber events, I mean, honestly, those are pretty inexcusable. They did happen earlier, in 2018 and then early, early 2019. They just didn't report it and you can't do that.

And then finally, the last thing we'll talk about here is the compliance certification. National Securities certified compliance with the regulation for the 2018 calendar year. And though it was timely done, the very fact that all of these things happened indicates to the department that they weren't actually compliant. Therefore, the attestation, the certification of it was false. Now that is painful, because what it means is, you might be following along and doing your certification as required, but man, you better be sure you actually didn't have any incidents or there's no evidence that there was a problem, because if there is, guess what? You're not compliant and you falsely certified.

Kip: This is just due diligence. I mean, this is just basic business due diligence. There's nothing mystical here, just basic due diligence. And for the CISO, it's just about prioritization. It really just comes down to that. Where in the priority scheme did this fit for the CISO? I don't even know who it is. I have no idea who this person is, so I'm not picking on anybody. But I'm just saying that this is common. When you're a CISO, you have to have strong priorities because you can't possibly do everything, and so you've got to make sure that where you spend your time is well decided.
In the order, by the way, I don't know why, but in the monetary penalty, paragraph 39, it says, "The company shall pay a total civil monetary penalty, $3 million." And then it says, "The payment shall be made in the form of a wire transfer in accordance with instructions provided by the department." And when I read that, I was just like, oh man, $3 million. What could I have done with a $3 million budget for their cyber security? Oh my gosh, I could have done so many great things for them that would've kept them, not just out of trouble with DFS, because that's not really the point, but it just would've kept them from having to suffer from this loss of $400,000 and everything else. So yeah, put the $400,000 in there, too. So $3,400,000 would be my budget and I could make them a difficult target for years with that money. That's just awful.

Jake: Yep. It is. And it's really, I think just very... the consent order goes on another half dozen pages or so talking about the remediation. They have to have a cyber security incident response plan put in place. They have to do assessments, all the other things that likely there wasn't evidence of. And so, overall, I love this order, to be honest, because it is so realistic. I mean, obviously it's realistic. It happened. but in many ways it's also just so generic because this could be anybody.

I mean, yeah, we're picking on poor National Securities Corporation, but this is not unusual. This is not weird. And if you're listening and you're thinking, "Gosh, we could be in the same situation." This is a really, I think, good reminder that if someone does decide to investigate you, they're going to very quickly uncover the reality of your cybersecurity program.

Kip: Oh yeah. Yeah, absolutely. Well, cool. Listen, everybody, we're going to wrap up this episode in a minute, but I wanted to let you know, if you're still listening, early in the episode, I talked about the usefulness of security principles and I mentioned the paper from 1974. So I just wanted to give you a little bit more information about that.

The paper is available online from the University of Virginia Department of Computer Science. And it's entitled the Protection of Information in Computer Systems. And it was published in 1974 and the authors are Saltzer, S-A-L-T-Z-E-R and Schroeder S-C-H-R-O-E-D-E-R. If you just do a quick Google Search, you'll find it. It is well worth your time to read this. It's invaluable. So there you go. There's the parting tip.

Jake: Well, that wraps up this episode of the Cyber Risk Management Podcast. I'm doing at this time, Kip.

Kip: Yeah, go ahead.

Jake: Today we discussed a recent consent order resulting from an investigation by the New York Department of Financial Services under its cybersecurity regulation and the failure of a covered entity to implement MFA on its email systems among other things. We'll see you next time.

Kip: Thanks everyone. See you next time.

Speaker 1: Thanks for joining us today on the Cyber Risk Management Podcast. Remember that cyber risk management is a team sport, so include your senior decision makers, legal department, HR, and IT for full effectiveness. So if you want to manage cyber as the dynamic business risk it has become, we can help. Find out more by visiting us at cyberriskopportunities.com and focallaw.com. Thanks for tuning in. See you next time.