Security compliance around the Hash Table.

Rick Howard: At the beginning of this year, 2021, I finished reading Yuval Harari's most excellent book, "Sapiens: A Brief History of Humankind." And if you haven't read it yet, I highly recommend it. It's one of those mind-blowing books that will keep you thinking about it for months afterward. One of the ideas he puts forth as a contributing factor to why our species, Homo sapiens, have outpaced all the other species on the planet is our ability to create myths that everybody can attach themselves to. One of his examples is the creation of the limited liability corporation and something that lawyers call a legalized fiction. I know that sounds crazy, but hear me out. Here's Harari speaking at a TED conference in 2015.

Yuval Harari: The most important actors today in the global economy are companies and corporations. Many of you perhaps work for a corporation like Google or Toyota or McDonald's. What exactly are these things? They are what lawyers call legal fictions. They are stories invented and maintained by the powerful wizards we call lawyers. 

Rick Howard: I bring this up because in my last CSO gig, the company founder was from Israel. And although there were no official laws on the books, the U.S. federal government refused to buy our products at scale because the founder wasn't an American. Our solution - we created something called a legal entity, a piece of legal fiction written by a lawyer that created a federal version subset of the actual company with a U.S. citizen as the president and a U.S. citizen as the CSO. 

Rick Howard: The Israeli founder wasn't part of this new legal entity, and that broke the dam. We can now sell to the U.S. government at scale all because of a piece of paper, a legal fiction, crafted by our corporate legal wizards, who I'm sure all belong to the house of Slytherin - no offense to my lawyer friends. In last week's show, we talked about the bewildering array of international, U.S. federal and U.S. state cybersecurity compliance laws. And one way we can reduce the complexity and scope of that environment is a judicial use of these legal entity fictions. Let's find out how. 

Rick Howard: My name is Rick Howard. You are listening to CSO Perspectives, my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. Tom Quinn is the T. Rowe Price CISO, a regular at the CyberWire Hash Table and a security veteran that has spent over two decades working at financial institutions like State Street, BYN Mellon, JPMorgan Chase and now going on six years with T. Rowe Price. I started out by asking him how senior leaders at financial institutions think about compliance not just at T. Rowe Price but the entire finance sector. How do they approach compliance laws? Is it a burden? Do they embrace it, or do they push it down into the hierarchy? 

Tom Quinn: Every senior leader that I've talked to on the business side in financial services - most people would say that regulation is a good thing. It makes it clear what's expected and that you have ground rules in place. I think that's important. Depending on maybe the size of your company and the complexity of your company, you may have different ways that compliance is actually implemented. Depending on the size, scope, scale and what the regulation says, you may have technically oriented compliance people, or you may have compliance-oriented technology people. 

Rick Howard: (Laughter). 

Tom Quinn: And I think you actually need just a bit of both. I'll include businesspeople, right? You know, you can have business-oriented compliance people or compliance-oriented businesspeople. And I think it works best when you have a culture of compliance. Then everyone's grounded enough in it as well. And I think it's also important too - right? - is that in many cases - right? - these compliance requirements - how they get implemented matters. And I think if you have compliance-oriented businesspeople, they'll see maybe the best way to be compliant. And if you don't have enough knowledge about the give and take of what the compliance regime is really looking for, you may pick a way to implement compliance that's very costly to you and may even miss the mark - right? - for what you think. 

Tom Quinn: So I think it's important that there's a clear dialogue in place as well for both sides, and it should not be seen as adversarial. I think in some cases, people may think that there's some adversarial relationship - that these happen. I don't - I've never viewed it that way. I think the regulators really do care about their remit. I think compliance teams care about their remit. I think business teams care about it, too, and tech teams as well. And I think when you're communicating effectively, talking about what is working, what's not working, giving appropriate feedback - and regulators will listen. I'm here to tell you - right? - that regulators want the feedback. When you have that regular dialogue, it's super beneficial. And I've always taken the viewpoint of transparency is valuable. Visibility is valuable, too. And communication is key and making sure that the regulators understand that you care and that you intended to be compliant. 

Rick Howard: I've been evaluated by other organizations in my past career and - was mostly an exercise in interpreting what the rules said you were supposed to do, having a plan to accomplish that and then demonstrating to the evaluator that you're making that best effort to get there. Is that what it is with these things, too? 

Tom Quinn: In general, I would say yes. There are certain compliance regimes where there really is very little room for misinterpretation and very little room for, you know, doing best effort. I'll give you one example - right? - where you really don't have a lot of wiggle room. And that's for communication retention and surveillance. Like, you are required to keep, you know, communication of that business as such in the financial services industry - client communication. It's not OK to create a retention program and not hit the mark. It really could be problematic. 

Rick Howard: It's like, all right, so we're going to do this. You have to demonstrate to the auditor or the regulator that you did it. 

Tom Quinn: That's right. 

Rick Howard: And it will be different across every institution, right? So it's really an - how you decide to present that information is important, right? 

Tom Quinn: Presentation isn't - is critical - right? - to be able to demonstrate and present that you're being compliant. You may be compliant in a multitude of different ways, right? For the email example like, hey, you have to retain, and you must demonstrate that you can retain. There must be a hundred different products and a hundred different ways to demonstrate that you're compliant. I think that's where - there's often a dialogue about being the spirit and the letter of the law. And I think that there is some flexibility about how you're being compliant, but you still have to demonstrate. 

Rick Howard: Do most financial institutions try to take this on themselves, and they, like you said, buy some tech, some GRC tool to help them do that, or do most of them outsource it to a big consulting firm, like Accenture or something like that? Or is it a mix of those things? 

Tom Quinn: Again, you know, it really depends a lot on how the company operates currently. Like, if they have a large investment in compliance people and technology people have a view on compliance, they may do it themselves and maybe even run that tool. And in some cases, you may have a service that you use that could be outsourced. The service could be outsourced. But compliance, regardless of maybe the how of implementation and how much help you're getting, the company is required to be compliant. You can't ever use the justification that a large consulting firm is doing this, and they're the reason why we're not compliant. There's no way you can say that because otherwise you would demonstrate - right? - that you're not serious about it. 

Rick Howard: Right. For last week's show, one compliance consultant estimated that many of his big clients are spending 5% of revenue just to collect data for compliance and demonstrate compliance. Is that a ballpark figure that you agree with, or is that way off base? 

Tom Quinn: I think your mileage may vary. 

Rick Howard: Yeah. 

Tom Quinn: And I think, Rick, a lot of what you'll find is the how could be costly - like, very costly. So if somebody was spending 5% of revenue, the one thing I would question is, how early are you on your compliance journey? Have you built in compliance after the fact - right? - after system design or business workflow design? And then, are you recreating data sets? Are you leveraging data that may already be available, that may be easier? And then, how are you using the tool? There are so many things that come to mind when I hear something like 5% of revenue because that is a very, very big number. 

Rick Howard: It's a huge number. And I want to be clear, he wasn't saying that he recommended that you spend 5%. He said that his clients were spending 5% on compliance - is like, wow, that's a lot. That's a big number (laughter). That's a huge number. 

Tom Quinn: Yeah. But it just makes me ask a lot of questions. Like one, are you still compliant after spending 5%? 

Rick Howard: (Laughter) Yeah, good point. 

Tom Quinn: But I think the - like, earlier about, like, the how - and the how matters - right? - is being efficient in spending for compliance, I think, is key. Like, it's critically key. And I think it goes to the heart of who's creating the requirements at your company. Depending on what your answer is and then who builds it for you, you could get into some very complicated things. And maybe there's an easier solution to demonstrate compliance. We think that kind of through. Like, how much money is it costing? Could we be more efficient and be compliant? You can't be either or, right? It really is, how can we do this better? How can we be more efficient? How can we get better, demonstrate it - more easily demonstrate to the regulators that we're doing things? In some cases - right? - maybe we're over-demonstrating. And I think in some cases, it's important to understand, if you've gone further than required, to meet a regulatory need. 

Tom Quinn: And that's why I think it's critically important to have a dialogue with the regulators to make sure that you got it right. Like, does this look right? Do you think you need more? Is this too much for you? And I think that constant refreshing of what you're doing and why is important. Just like you need to have architecture and engineering for performance for systems, for maybe security of systems, for maintenance of systems, you need to take the same kind of architecture and engineering approach to the regulatory. compliance nature of systems as well. 

Tom Quinn: And I think the sweet spot - and it's the way that we think about it - is, we should be building our operational reporting and our engineering designs and our architectural frameworks with regulatory response in mind. Because if you bake that in, you could get efficiencies. 

Rick Howard: Well, it's a complicated environment. You know, I really just started looking at this last week with any detail. And I found 50+ laws on the books - international, U.S. federal, state laws. I fully admit that I didn't get to all of them. Trying to keep track of that - it's - for your - any organization has got to be an immense operation. Are there a handful of these things that you pay attention? Either, well, we've got to do these three, and we'll worry about all these others later? Is it, we're just going to do them all and - I don't know. What's the approach there? 

Tom Quinn: No, it's a great question. So there are primary regulators to most businesses. And I think that you would certainly be spending time to make sure that you're meeting your primary regulators' needs or you're regularly talking to them. They may come audit you. But we pay attention to the regulations and apply to our business. 

Tom Quinn: One of the things I find that's somewhat a challenge, I think, for the way the companies and their systems are designed is, often legal entity - and the regulations apply to legal entities. They don't really apply to the concept of a company writ large. They apply to legal entities. And sometimes in legal entities you could have humans and systems in there. And sometimes, legal entities are only for tax reasons. So depending on the legal entity and the regulation that you've got in front of you, what compliance means may look different. And then how much you need to be involved maybe would differ, too. And I think it's important to make sure that you're kind of well-read on what regulations apply, what legal entity scoping you have. 

Tom Quinn: And often, the first question that I ask when we're having a legal entity or a regulatory discussion, which is, what data is in scope? What systems are in scope? What employees are in scope? Because sometimes what will happen is, they'll say, I don't know. So let's apply this regulation to the entirety of the companies. Well, if your company's small - maybe a couple hundred people - and you only do one thing, and you probably have one regulator, it probably works out just fine. 

Rick Howard: So help me understand that - what - the legal entity is a subset of a T. Rowe price. 

Tom Quinn: That's right. 

Rick Howard: It's a smaller business unit that does maybe financial, you know, credit cards or something, as opposed to something else. Is that right? 

Tom Quinn: Yes. So it's a great question, and it's taken me years... 

Rick Howard: (Laughter). 

Tom Quinn: ...Of focus to think through things like this. So - but a financial services firm is a company. But really, when you look at it from a organizational document perspective, you're really a Delaware-based incorporated company. Well, you may not have any employees in Delaware. 

Rick Howard: Yeah. 

Tom Quinn: That struck me as odd the first time I kind of went through this. Like, well, what's a legal entity? So an example could be - right? - you're in a large financial services firm. You have an asset management business, a trading business, a private wealth management business. What you really are is you're a holding company, which is a legal entity. And then often, what happens is that trading business, which is often a broker-dealer - that broker dealer needs a license and is a legal entity. The insurance company needs a license and is a legal entity. The asset manager needs a license and is a legal entity. Insurance is regulated by state governments. So you need to have a legal entity and a license to sell insurance. 

Rick Howard: It's a legal piece of paper - right? - that delineates that stuff, right? 

Tom Quinn: For most people, it may just be a piece of paper. I have to let you know it's not how regulators see. 

Rick Howard: I see. Yeah. 

Tom Quinn: That is a... 

Rick Howard: Yeah. 

Tom Quinn: ...Covenant with a regulator and a business. And now the piece of paper absolutely allows you to operate the way that you need to. But what I've observed over the years - I've been through this in financial services - is, the regulators are really holding people accountable to those pieces of paper. And... 

Rick Howard: But that helps reduce the scope, right? That's what you were getting to before. It says, here's the scope of what we're looking at, right? 

Tom Quinn: Correct. 

Rick Howard: Right. 

Tom Quinn: And that's exactly what's in those legal entity... 

Rick Howard: Yeah. 

Tom Quinn: ...Documents. I think the challenge is, very rarely are those documents used to build systems. Very rarely are those documents used necessarily - right? - to hire people or to get a building... 

Rick Howard: Right. 

Tom Quinn: ...Or sometimes, to buy a service. But the thing for it is, it's important to have a legal entity lens, right? It's not just your company. It's not just an email system, right? Legal entity matters. So when the state of Arkansas has a different set of requirements than the state of Maine on how you're supposed to do data protection or privacy alerting, like, that gets complicated. Like, the first thing you ask is, well, yeah, that's right. How many people from Maine do we have that are clients? How many people from Maine do we have that are employees? 

Rick Howard: Well, it's even more comprehensive when you just talking about privacy law, right? Because I'm guessing you guys fall under three different laws - the European Union's GDPR - the General Data Protection Regulation. California has got two laws that you have to follow, and those are just three that I discovered during a Google search. I'm sure there's many more. How do you guys keep track of all that complexity? 

Tom Quinn: For small firms that have limited scope, you could probably keep in your head, right? You probably know who your clients are, where they're at. Or maybe you only operate in one state or something. But the complexity happens when you're operating in multiple states in the U.S., multiple countries in the world, but you're using a shared system of record. If you've not designed legal entity in the way that you hold data, provide access, it could be very costly, and in some cases, you may get into that 5% of revenue discussion, depending on what exactly you're trying to be compliant with. 

Rick Howard: In the financial sector, are compliance programs part of the information security program that you run? Or are you a supporting player to a larger compliance effort that the bank has to deal with? 

Tom Quinn: I'm going to say it just depends. I'll lay them out, right? So compliance in financial services is a corporate function. And you'll have compliance officers assigned. Depending on the nature of the culture you have and the history that you have, compliance officers may be the ones who demonstrate compliance. And in some cases, it won't be compliance officers. It will be the operations teams, whether they're technology or the business. Often you may hear the phrase line one - line one employees - right? - that are demonstrating compliance. 

Tom Quinn: What I also find, too, is that most compliance teams are business-oriented. They understand the compliance of the business and the rules that may be in place. It's less likely that you'll find compliance people that are technology-oriented. And what I mean by that is, technology is opaque in general to most people that don't do technology. And cybersecurity sometimes looks like magic to most people who don't practice cybersecurity. Well, there are not very many - I've not come across them - compliance people that are very technical. Often they have business backgrounds. 

Tom Quinn: There have been cases where I've played a dual role of being responsible for compliance and responsible for the compliance-oriented aspects of things - the technology and cyber-oriented compliance itself - because I knew what the regulations said. I really knew what they meant. And that blending of knowledge of being a compliance-oriented technology cyber professional, I was able to say, I know what this means. I know what we need to do, or we're already doing it. 

Rick Howard: As you know, I'm spending a lot of time discussing cybersecurity-first principles on this show. It's my effort to identify the essential strategies that we're all using to protect our organizations. For the last 18 months, I've identified four big ones that we should be paying attention to - zero trust, intrusion, kill chain prevention, resilience and risk forecasting. What I'm asking you is, do you think compliance is a strategy that needs to be on the same level as those? Or is it buried somewhere deep underneath one of them - resilience, probably? Is it that important? Or is it just another function somewhere down the path? 

Tom Quinn: I think it's incorporated into the things that you were talking about. And I don't think it's buried at all. Speaking about first principles, I think you've just described - right? - what's most regulators are really asking for. Now, how they ask it, the language they use, the specificity they may provide on how you do it - but it's basically those things. 

Rick Howard: Well, I guess the question I'm asking is the penalties that you could get from noncompliance, are they material enough to the company? That's the reason they should be at the same level as those other ones. I agree with you that we'll gather data from all those strategies to help show that we're compliant. But is compliance a material worry? 

Tom Quinn: It is. But there's a right way and a wrong way to do things. And resilience is more than just saying, I've got another server on a rack somewhere for a trading system that trades a million dollars a second or something. That's not OK, right? Hot standby multiple servers - like, there's a right way to be thinking about those things, based on what you're doing. 

Tom Quinn: And what I wanted to drive at is across the board at firms I've worked at, compliance was a very important outcome. It was architected and designed to be not only compliant to meet minimum requirements but to meet the business' requirements as well. So it wasn't really seen necessarily as a separate thing. It was in the same breadth, right? What are the business requirements? What are the regulatory compliance that we need to do? What are our client requirements? And let's build our practices, our systems and our protections to meet them. I've not been at firms where compliance has been used as a stick to have something done. Usually, we're already doing that kind of work. We had that kind of do-care mentality in place. So compliance was right along there with us as a design criteria for, again, systems and programs. 

Rick Howard: Well, I guess the question I'm having is, if it is true that some organizations spend 5% of revenue trying to be compliant, why are we doing that? All right, is... 

Tom Quinn: Yes, that is exactly the right question. I find that number broadly to be shocking. 

Rick Howard: Well, whatever, the number is - if you're - let's just say it's a hundred bucks a year, you know, way over on the other side. But the question is, why are we spending that money? Are we afraid that penalties will be material to the business? Or is there some other reason that we're doing this? 

Tom Quinn: If you have a license to operate - and that license has requirements - and we'll call those, you know, regulations - you're obligated to do that. It would be irresponsible to say, give me a license to operate a legal entity and then say, I don't care - 'cause the license is a quid pro quo. I'll give you a license and you promise to operate this way. It's part of doing that. I mean, you're obligated to operate in the way that's been outlined. 

Rick Howard: Yeah. 

Tom Quinn: What I find, though, is it's all in the how. 

Rick Howard: My point, Tom, is that every organization, especially in finance, you know, we're spending resources to be compliant. And is it because we're worried about the penalty? Just this summer, the European Union fined Amazon almost a billion dollars for fines because they did something wrong. But that's a drop in the bucket to them. 

Tom Quinn: It doesn't hit that 5% threshold... 

Rick Howard: Right. 

Tom Quinn: ...To your point, at all. These compliance regimes, in many cases, have been there for decades. And people just are - they're used to them. GDPR is new. It's 5 years old, or whatever it may be - 10 years old or something. But it's causing shifts that, they're going to cost you money. Like - so in some cases, that 5% could be new regulation, system or business process wasn't designed for it - needs to be retrofitted, right? So another option that someone could pick is this legal entity in this country with this regulation, we're not going to do business in that country anymore. 

Rick Howard: So I have this view, this diagram in my head, you know, where we have these four big strategies across the bottom. And then in order to make it efficient, we have to automate that. So DevOps cuts across all of them. But from - with this discussion, what I'm hearing is compliance cuts across all four of them also, right underneath the DevOps. 

Tom Quinn: So they do. And the thing, Rick, is that before, it was just a piece of paper. 

Rick Howard: (Laughter) Yeah. 

Tom Quinn: And what some people may not have realized is it was much more than a piece of paper - it was a covenant - and that regulators were maybe more inclined now to exercise the right to audit or exercise the right of compliance. 

Rick Howard: That was Tom Quinn, the T. Rowe Price CSO and a regular guest at the CyberWire Hash Table. 

Rick Howard: And that's a wrap. Next week, we are introducing a new CSO Perspective segment called the CyberWire Sand Table. You don't want to miss that. But as always, if you agree or disagree with anything I've said or anything our guest has said on this episode, hit me up on LinkedIn or Twitter, and we can continue the conversation there. Or if you prefer, you can send questions and comments to csop@thecyberwire.com That's C-S-O-P - @ - thecyberwire - all one word - .com. The CyberWire CSO Perspectives is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Note Sessions - remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design and original score. And I am Rick Howard. Thanks for listening.