Kip Boyle: Hi, this is Kip, and I'm interrupting the start of the show with a brief announcement for the attorneys in our audience. Once every quarter throughout the year, Jake and I offer a free online continuing legal education session. Our next CLE will be at noon Pacific Time on Wednesday, March 30th. This time we're going to explore the impact of the Pandora Papers on the legal industry and the practical cybersecurity lessons for attorneys everywhere.

Join us online for a one hour cutting edge CLE on March 30th, 2022 at Noon Pacific time so Jake and I can share what we've learned by analyzing the Pandora Papers, a massive collection of over 11 million confidential leaked documents about offshore wealth that were stolen from law firms and then recently published. In addition to one CLE credit, you'll also receive actionable advice that you can use right away. Sign up now on eventbrite.com by using the link in this episode's show notes. We hope to see you there.

And now, let's listen to the next episode of the Cyber Risk Management Podcast.

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: Hey, Kip. Today we're going to review the significant that the Federal Trade Commission made to the Safeguards Rule, which is a rule issued under the Gramm-Leach-Bliley Act relating to financial institutions and consumer financial information.

Kip Boyle: Okay, good old GLBA, Gramm-Leach-Bliley. I have definitely heard of that. That's not new, but there's been change, huh?

Jake Bernstein: Correct. The original Safeguards Rule was promulgated, which is a lawyer term that just means a rule was set forth and actually taken effect. It's so hard for me not to say that. Anyway, it was promulgated a bit more than 20 years ago by the Federal Trade Commission, as required by the passage of the Gramm-Leach-Bliley Act itself in the late '90s.

Kip Boyle: Okay. All right. I can't help but to think of our recent episode of the False Claims Act. By the way that was, let's see, episode 96, which dropped not too long ago as we record this on January 4th, 2022. The False Claims Act, that was signed into law by Abraham Lincoln. At least the GLBA legislation is like contemporaneous to us, right? We were alive.

Jake Bernstein: We were alive. Yes. We're much more recent territory with the GLBA and its Safeguards Rule. As a matter of fact, this is actually the first time that the FTC has updated the Safeguards Rule since it was originally created.

Kip Boyle: Okay, all right, all right. Let's see here. You told me during show prep that this change is actually pretty fresh. We're recording this in January 2022. This rule change happened October 2021. Yeah this is really fresh in legal terms. The Safeguards Rule. Again, I have this feeling we've talked about something like this before in the podcast asked. Well, did we? Well, look, whether we did or didn't, let's just rewind a little bit. Give us a little background on the Safeguards Rule. What is it? What is it really?

Jake Bernstein: Sure, absolutely. The GLBA, which is also called the Financial Services Modernization Act of 1999, and well, perhaps in retrospect, it wasn't the best idea we've ever had. Substantively speaking, the GLBA repealed a portion of the Glass-Steagall Act of 1933, which effectively deregulated banking and some have said led inexorably, or at least heavily contributed to, the 2008 subprime lending crisis.

However, we're not going to be looking at that aspect of GLBA and the Safeguards Rule has little to do with that kind of deregulatory aspect. Just keep in mind as we talk that the GLBA was passed 1999 signed by Bill Clinton and the dot com bust was still a couple of years in the future.

Kip Boyle: The dot com buts, I'm actually old enough to remember that. Not just by reading about it in the newspaper, but actually watching people get laid off. I'll never forget, one of the most vivid memories I have of that is the company I was working for at the time did a layoff. I wasn't laid off on this first round, but I remember standing in this hallway and I remember this guy who just got hired.

He had like a box of business cards that he'd just been given, the ink isn't dry yet, and he got laid off like within days or weeks of joining the firm. I remember he hurled his box of business cards down the hallway, and they just like exploded in this massive confetti thing. All the cards just sort of like fluttered to the ground. They were on the floor for days. Nobody was ready to clean it up. Anyway, sorry, that's just a little blast to the past. But there was real pain and suffering in the tot com bust for sure.

What's interesting about what you said is that here, we've got this massive piece of legislation potentially linked one way or the other to the 2008 subprime lending crisis and deregulation of banking. This is like another thing all together inside there that's still rolling forward out of that train wreck. This is really interesting. Listen, let me just stop editorializing. Keep going.

Jake Bernstein: Sure, yeah. I think it's probably a good call to limit our focus to the Safeguards Rule aspect. From the FTC's perspective, which is what we really care about here, GLBA added requirements for financial institutions to explain their information sharing practices to their customers and to safeguard sensitive data. Keep in mind that when we have discussed GLBA and the Safeguards Rule before, because I think we have, we stressed how far the definition of financial institution can be extended.

Kip Boyle: Yeah, yeah, that's right. That's right. Let me look here. We have not numbered our episodes explicitly in people's podcast listening apps, although we've started doing that, ever since we hit episode 100 and we've started to realize that there's actually some prior episodes we want to reference to. We're numbering them now, everybody. Let's see.

Jake Bernstein: This is episode 101.

Kip Boyle: Yes, this is episode 101 and that should be clear by reading the description. We're talking about episode 57. That was published on July 7th, 2020. What's the definition of financial institution? Well, yeah, I mean, we talked about this, car dealerships are financial institutions from the perspective of this FTC rule and why? It's because in their back office, what are they doing?

They're granting credit to people who want to buy automobiles. They're doing credit checks and that sort of thing, right? Therefore, they are a financial institution, which is like crazy. But yeah, it makes sense.

Jake Bernstein: And in fact, the FTC case was actually against a service provider to car dealerships. I think it was Lightyear Technologies, something like that.

Kip Boyle: Light beer. Light snack. Something like that.

Jake Bernstein: But in any event, they were kind of the back office technology company that was deemed to be a financial institution because their software and their backend was handling these credit checks. Yeah, that's really the idea. I really want to bring this point home because I suspect that many of our listeners may work at "financial institutions" without even realizing it, because this law and the Safeguards Rule, which is a regulation, applies to any business, regardless of size, that is "significantly engaged in providing financial products or services."

Now, this includes check cashing businesses, payday lenders, mortgage brokers, non-bank lenders, personal property or real estate appraisers, professional tax preparers, and even courier services.

Kip Boyle: I wonder if it includes pawn brokers? How interesting. That's pretty broad. Now, if GLBA and its Safeguards Rule applies to you, if you're listening to this episode, and you don't know that, you should probably talk with your attorney. But if it does apply to you, Jake, then what does it mean? What does it mean to that org?

Jake Bernstein: It's a really well named rule because what you have to do is safeguard consumer data.

Kip Boyle: Boom! Okay. This is starting to sound like a privacy law, right?

Jake Bernstein: It is absolutely a privacy law rule regulation. They're combined here, but it is also a cybersecurity law and rule. At the highest level, the Safeguards Rule requires businesses to develop a written information security plan that describes their program to protect customer information. And, this should sound very familiar, the plan must be appropriate to the company's size and complexity, the nature and scope of its activities, and the sensitivity of the customer information it handles.

Kip Boyle: Yeah, okay. The FTCs is coming through loud and clear, that's their reasonable cybersecurity standard, isn't it?

Jake Bernstein: Yes, it is. Obviously it's not a coincidence. Let's try to quickly, as much as we ever can on the Cyber Risk Management Podcast, run through what the original Safeguards Rule required and that will enable us to talk about what has changed.

Kip Boyle: Yeah, that seems reasonable. All right. Let's see if we can do this here. Now, I've got my show notes. Let's see if we can do this expeditiously, but without fumbling and stumbling our way through this because I want people to understand. The Safeguards Rule requires that every written information security plan, which we call that a WISP, which is kind of an interesting little turn phrase, but they all have to identify and assess risks to customer information, and they have to evaluate the effectiveness of the current safeguards for controlling those risks. Make sense.

Jake Bernstein: To me, that sounds an all awful lot like the identify function of the NIST Cybersecurity Framework, or alternately, the identify slash or dash P function of the NIST Privacy Framework. I think that's pretty clear.

Kip Boyle: Yeah, that's very vanilla. Yep.

Jake Bernstein: It is. Here's another vanilla one, design and implement a safeguards program and regularly monitor and test it.

Kip Boyle: Mm-hmm (affirmative). Yep. That's kind of like the protect function in the cybersecurity framework.

Jake Bernstein: Yep. We are definitely in there.

Kip Boyle: And then you monitor it and test it. Well, that's also, guess what? Third function, monitoring, in the framework. That's kind of all rolled up there. Let's see. Now , again, we're just recapping what does the current rule look like.

Jake Bernstein: The original.

Kip Boyle: Yeah, yeah, the original. Not the current, but the original one. And then the original one also said you have to select service provider that can maintain appropriate safeguards, make sure your contract requires them to maintain safeguards, and oversee their handling of customer information. Well, NIST Cybersecurity Framework has a supply chain management activity in there. This sounds an awful lot like that.

Jake Bernstein: Yep, yep. Vendor risk management. The last one is evaluate and monitor that program... Evaluate and update the program in light of relevant circumstances, including changes in your business operations or the results of security testing and monitoring. This is lessons learned, right? This is respond and recover. As you said, this sounds familiar. In fact, it sounds a lot like cyber risk management.

Kip Boyle: Yeah, just in general, right? We don't have time to do it today, but it'd be interesting to do some like archeology or some forensics analysis and find out, did GLBA create the NIST Cybersecurity Framework? Were they two similar things on completely different paths? Whatever. Sounds like it's converged finally. And then one thing that's interesting that I don't see in here, which we talk about a lot with customers, is you have to evaluate your program also in light of what's going on outside in the real world.

That is to say, what are the cyber criminals and cyber soldiers doing new that they weren't doing before? What's going on outside your four walls really? I don't see that in here, but I think that's absolutely necessary. Okay, everybody, you should be really happy because we didn't read the original Safeguards Rule verbatim. Thanks to our fantastic counselor here, Jake, we actually just did a high level skimming, but I think it was really good.

Jake Bernstein: Yeah, it's helpful. Now we can take a look at what the FTC changed. To begin with, I want to talk about what the... The chair of the FTC, currently Lina Khan, and that's the person who put out this statement, and Commissioner Rebecca Slaughter, they put out a statement on October 27th, 2021 that kind of explained the changes and the history behind them and also was kind of a response to the dissenting commissioners. The rule change was passed three to two by the FTC.

The first thing I want to note as they say is that the updates to the Safeguards Rule were first published for public comment back in April of 2019. To the FTC statement I think very, very truthfully says, "Hey, in the 20 years since the rule was created..." I'm really fighting the urge to say promulgated. You got to know that. Created is not the right word and I know that and it bothers me, but it's not just going with it.

Kip Boyle: Come on, there's an audience here that needs to talk in plain language. I appreciate the contortions you're going through right now.

Jake Bernstein: It's painful, but I'm doing it. In any event, in the 20 years since the rule first came out... How you like that? There've been a few changes with respect to how often we all use network electronic devices.

Kip Boyle: Oh my gosh, what an understatement. Some changes. There's been, yes, legion, a legion of changes. That's not unique here, right? I mean, regulators and laws are always sort of chasing after changes in technology.

Jake Bernstein: They are. Clearly like lots of data breaches, lots of data theft, the ensuing identity theft, all of these are bad things. Something to understand, a feature of administrative law is that agencies must have evidence to support rule changes. If they don't, then those rule changes could be potentially challenged before an actual court.

Kip Boyle: Oh, interesting. They can't just rely on professional judgment.

Jake Bernstein: No. The phrase is arbitrary and capricious. If something is done that doesn't have evidence, then it's in danger of being called arbitrary and capricious. We're not going to spend a huge amount of time on the Administrative Procedure Act, even though I would love to do that at some point. It's sufficed to know that the FTC spent quite a bit of time gathering the evidence.

Kip Boyle: Good.

Jake Bernstein: The rule updates are a result of pouring over lots of data, lots of statements from people in our industry, among others, and many, many consumer and business comments.

Kip Boyle: That's great. Yeah, a lot of security practitioners spoke up. I love that. I think partially proves the fact that as an industry, cybersecurity practitioners can make change happen, at least when there's a forum that's been created that we could step into and express our opinion That's really good. This is where I say, okay, so it's evidence-based and the FTC talked to constituents, but were these changes like... Are they actually useful? Will they actually make a difference? I guess we should probably start talking about what's new, right?

Jake Bernstein: Yeah. In fact, this is starting to feel like one of those YouTube videos where they are always just about to tell you the secret to life, the universe, and everything, but they never quite get there. Just to get you to engage... Yeah, it's 42.

Kip Boyle: 42.

Jake Bernstein: They get you to engage with the video longer. Anyway, it does come down to specifics. We're going to go through a bit, what's new. Now, just a disclaimer here, because we're not going to verbatim read the new rules...

Kip Boyle: And we all like that.

Jake Bernstein: This is a summary. If we leave something out, or if we don't get into enough detail, please forgive us now. This is meant as a higher level overview and a lot changed. Let's just start with all the new things that the WISP, the written information security plan, must now also include. The first one... And by the way, the primary feature that you'll notice is that things have gotten a lot more specific. For some people, that's the criticism of these new rules.

For others, that's what makes these new rules valuable. First one is access controls to authenticate and permit access only to authorized users and to limit authorized users access based on the need to know principle. That's good stuff.

Kip Boyle: Yeah, it is good stuff, right? We should probably do a separate episode. Look at all these episode ideas about security design principles for security mechanisms, right? Need to know, that is, in fact, a principle of good design. It actually goes back to a seminal paper that was published in the 1970s, which a lot of people don't know that, which has actually held up really, really well, even though everything's changed. It's great to see these design principles being codified. Can I say codified? Is that too lawyerly?

Jake Bernstein: No. Oh, I mean, yes, but you are more than... You're at this point honorary attorney yourself, so I think you might as well go ahead and say codified, Kip.

Kip Boyle: Okay, codified. But just disclaimer, right? I'm not an attorney. This is not legal advice, but it's great to see it in there. What else has changed? Well, this has changed. Now you've got to also to include in your program the identification and management of data, personnel, devices, systems, and facilities that enable the financial institution to achieve business purposes in accordance with their relative importance to business objectives and risk strategies. Holy moly!

Jake Bernstein: Pause. Pause. It's possible that I pulled that, but that...

Kip Boyle: He gave that to me to read. He told me I had to.

Jake Bernstein: I did. I did. But what is that? That really is just the best way of kind of saying that you have to understand the business requirements. You have to be able to incorporate the risk appetites and strategies and objectives in order to... Really it's still kind of identify. It's just at a more specific level.

Kip Boyle: I love this phrase, in accordance with their relative importance. Well, what that means to me is strict prioritization, right? Which we talk with our customers about this all the time. You have unlimited risks coming at you. You have a limited budget. The only way that really makes sense that is reasonable is that you've got to prioritize your risks, and then you've got to address them in a very rigid, prioritized way. Now that's in here, so I'm happy to see that, it looks like the revisions to the Safeguard Rule requires us to encrypt everything, right?

Jake Bernstein: Yeah. You did not read the script, Kip. It says encrypt all the things, which is kind of a modernish internet meme-ish type of joke. In any event.

Kip Boyle: Encrypt all the things. I guess I'm not cool.

Jake Bernstein: No, I guess you're just not. That's now been absolutely... I'd say there's evidence of this now, regardless.

Kip Boyle: It's evidentiary.

Jake Bernstein: Obviously it doesn't say encrypt all the things, but encryption specifically... This is another one of those like potential criticisms or features, depending on your point of view. But the new Safeguards Rule really does go into much more detail about how and when and what you have to encrypt.

Kip Boyle: Okay, that's good. It also says that we have to use secure development practices, which I think means software development, systems development, all that stuff. Is that right?

Jake Bernstein: All of the above, yes. I think again...

Kip Boyle: Securely develop all the things.

Jake Bernstein: Securely develop everything. I don't think we can argue with that. I mean, that's an important component.

Kip Boyle: So far, these changes just seem like they're playing catch up with what we know is the way to do things.

Jake Bernstein: Yeah, they are. This next little list here I think is going to even more clearly show that. Deploy MFA, that is actually part of the rule. You have to use multifactor authentication. You and I are not going to... We're huge proponents. We think MFA is almost a minimum viable component of cybersecurity these days.

Kip Boyle: That's catching on too.

Jake Bernstein: It is. You know what? For us, it can sometimes seem like, why does that even have to be a rule? I mean, it's almost so obvious, but you and I also know that even today, a lot of people complain about the deployment of MFA systems because of that slight additional aggravating component needed to authenticate. But look, everyone, and hopefully our audience doesn't need to hear, but I'm going to say it anyway, you got to authenticate. It's a minor price to pay for what you're preventing with MFA.

Kip Boyle: What's interesting is there's a lot of pressure coming from the insurance companies actually to require insureds to enable MFA. Even people who in the past had the authority to resist it, a senior decision maker, they're not going to be able to resist it much longer because then they won't be able to get insurance. Well, at least, if nothing else, they understand insurance.

Jake Bernstein: Yep. What else? Again, this just all still goes back to what the WISP has to contemplate, secure disposal mechanisms of hardware, data, software, et cetera. One of my favorites, change management procedures. Those are a level of formality that usually only the biggest companies have, but I think it is important even for smaller companies to contemplate the change management.

Kip Boyle: Can I tell you how we do it? Cyber Risk Opportunities is a small company. We've got about half a dozen people right now, and we just have a Slack channel and it's called Office 365 Change Log. Anytime somebody is going to go in and make an adjustment to our Office 365 settings, that's where we talk about it and that's where we have our not only what we're going to do, but what we did and it's all date stamped and timestamped. It's no burden. All I have to do is just remember to not put that in a DM and just put it in there and voila, I comply.

Jake Bernstein: That's true and it's a good illustration of like change management procedures doesn't need to require forms being filled out in triplicate with the gatherings of the change management board.

Kip Boyle: But I do miss the carbonless canary copy that I used to get.

Jake Bernstein: Yes, yes, there you go. And then another one is various levels of logging requirements have been specifically added to the Safeguards Rule, which, again, I'm not going to argue with. I think it's important. Again, the criticism of the changes to the rule really do focus on the specificity. On the other hand, I think when you're vague and you have an industry that isn't steeped automatically always in cyber security practices, I think we need this.

Kip Boyle: Well, we certainly have seen plenty of examples of this already. I think the definitive example is the payment card industry's data security standard, which has been extremely prescriptive from the start. I personally do not prefer that because some of the things that they have you do by the time they actually get promulgated into the rule set, I did it again, promulgated, the stuff may be behind the times already, right? You get things like wireless encryption, right? WEP versus WPA versus WPA2 and so forth.

You could see PCI DSS saying something like you have to use WPA2. But then since that was published, WPA2 has been cracked or exploited. Now you got to go to WPA3, but the standard doesn't reflect that. People who don't know think they're safe and they're. Anyway, there's pros and cons to being prescriptive versus not. I prefer not, but I understand that people know what's going on and it helps them.

Jake Bernstein: There's prescriptiveness and specificity, and then there's dictating the algorithms. You know what I mean?

Kip Boyle: Mm-hmm (affirmative).

Jake Bernstein: I think there is a lot more detail in the new Safeguards Rule than there was in the old version. But I think lessons have been learned from things like PCI DSS, where maybe we don't prescribe things down to the algorithmic level.

Kip Boyle: I'd like to see them or to some sort of register published by the federal government that's like updated every day, right? Where it would say you have to use an algorithm that is attack resistant, see the register, then you'd go hit that webpage, and then it would tell you at any particular time what's considered to be attack resistant algorithms that you could choose from. I think that would be a really cool innovation.

Jake Bernstein: That would be a good idea.

Kip Boyle: Who knows? Who knows?

Jake Bernstein: Okay, so let's get through this. Yeah, go ahead.

Kip Boyle: Yeah, let's keep going. Now the other things that are required, continuous monitoring or annual pen testing with biannual vulnerability scans. I'm resisting the urge to unpack that. Let's just keep going. Let's get through the list. We have to end this episode sometime. It also requires security awareness training for everyone. Again, I am restraining myself. Please continue.

Jake Bernstein: The last one here is contractual requirements to ensure service providers are capable of maintaining the appropriate safeguard for customer information and the regular assessment of risk posed by service providers, meaning, and this is what makes it a little bit new from the previous rule, is you have to really assess the risk of using service providers period. Wow, okay. That was a lot.

Kip Boyle: That's it, everybody. That actually wraps up this episode. You're not going to let me do it, are you?

Jake Bernstein: No, no.

Kip Boyle: Damn it.

Jake Bernstein: You're kidding, right?

Kip Boyle: I can see the look on your face. You're like, "No. There's more to say." All right, fine. I don't want this to be a two part episode, even though you love two part episodes.

Jake Bernstein: Oh, I do love two parters. Don't tempt me.

Kip Boyle: You love me some two parters. All right, there's a little more to say, and then we can wrap up.

Jake Bernstein: Yeah. All of those things that we just mentioned and went through relatively quickly, at least for us, are requirements for things to be contemplated in the WISP. There are some other additional requirements though. Like before, you still have to document your risk assessments. They just need to be more detailed than under the previous version of the Safeguards Rule. We're not going to get into detail on that right now.

You also now must have a written incident response plan that has to address seven bullet points that I'm frankly too exhausted to even read aloud. It's typical stuff though, right? It's things that you should be doing anyway, except now it's a rule. If you couldn't tell, I pronounce that with a capital R.

Kip Boyle: Now, we're a YouTube video again, because we talked vaguely about seven bullet points that we will not tell anybody about and we're not going to tell anybody about. Sorry, we're not going to close that. You're not going to get closure on that from us this time. Just sufficed to say there's more specificity in there. And then I guess I really should also say that every entity that must comply with the Safeguards Rule must also designate a responsible "qualified individual." How interesting.

I think we could probably call this the security practitioner forever employment rule. Maybe that's too self-serving. Well, anyway, I think it's good. I like the way they phrased this, a responsible qualified individual. Not going to so far as to say that it has to be a person with the CISSP or whatever. Boy, I really like this. Not too specific, but specific enough. Good stuff. One of my big takeaways from this, Jake, is I have always considered the NIST Cybersecurity Framework as the embodiment of reasonable cybersecurity from the FTC. This, I think, throws a lot of weight onto that interpretation.

Jake Bernstein: It does. Something you said toward the beginning really got me thinking. If we think about timelines, we just learned that the original Safeguards Rule, which really did clearly have... It obviously had the right framework, the right skeleton. It's 20 years old. The NIST Cybersecurity Framework is really only... I mean, it's less than 10 years old.

Kip Boyle: Yeah. It published in 2014, I believe, and they took about a year and a half to make it. I think the executive order came out in 2012, took them six months to get organized. It's 2022, so it's coming up on a decade.

Jake Bernstein: It is. But I think you're right. I think that what we're seeing here is... The FTC didn't obviously write the NIST Framework. They may have had input, along with many, many others, but they do absolutely write the Gramm-Leach-Bliley Safeguards Rule. They also real estate at least somewhat connected to things like the HIPAA Privacy and Security rule. Now, they're obviously not quite as much. That's HHS OCR. I think that the FTC is really starting... Not starting. The FTC does know cybersecurity, right?

I mean, they've been the primary enforcer of things. We've talked before about the reasonable standard and then the somewhat newer phrasing that they're using in consent orders. We had a whole episode on the at minimum standard. And that's really what you're seeing in this rule, right? The FTC is trying to find a way to require business and business leaders to think about and act upon what are actually nothing more than reasonable cybersecurity practices, right?

It's risk management that we like to talk about. This is really the how you travel. This is obviously something that we have preached in the past, but cybersecurity isn't something you buy once, right? It's something you do.

Kip Boyle: Right. It's that thing you di.

Jake Bernstein: In fact, I feel like there might be a company that has a slogan that has something to do with that. Really that's my takeaway from this.

Kip Boyle: Yeah. Well, listen, if you want to know more about the Safeguards Rule and the other things that we've talked about, again, episode 57 published July 7th, 2020 is the place to go in our archive. I don't have anything else to say about this one right now. What about you, Jake?

Jake Bernstein: No, let's wrap it up.

Kip Boyle: Okay. Well, now we're really going to wrap up this episode of the Cyber Risk Management Podcast, and today we learned quite a bit actually about the Gramm-Leach-Bliley Act, GLBA, and the Safeguards Rule and how it was updated by the Federal Trade Commission. And then some of the specific updates of the rule. I think if you are working at a financial institution, as it is broadly defined, you need to get up to speed with this and do it quickly. Good luck to you. Let us know if you need any help 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.