59. Compliance Does Not Equal Security – Tech Field Day Podcast

When it comes to security, the most important thing that you can do is write down everything that you need to accomplish and put little squares next to it so you can check off all of those boxes, because once you've checked them all off, you're obviously secure. Right? In this episode of The Tech Field Day podcast, compliance does Not Equal Security.

Welcome to the Tech Field Day podcast, where we bring together a group of influential IT experts from across the enterprise IT space to talk about key concepts in the industry. This podcast features a variety of perspectives from members of the Tech Field Day delegate community, and is often recorded in association with one of our events. Tech Field Day is a part of the future and group, and this podcast is published on our sister company site, Textron tv.

On this episode, as we head into Security Field day, we're gonna be talking about compliance and security. But before we do that, I would like to introduce our guest starting with Melu. Hi everyone.

I'm Melu Meyer. I am a cybersecurity and privacy lawyer. I will be a delegate at the upcoming security field Day and Field.

I host my MPA socializing security, and I manage work through Compliance Counsel, which is a fractional CISO in compliance service. So I'm probably the biggest compliance nerd that Tech Field Day has invited to this podcast. Just boldly say that.

Hi everyone. I'm Jack Poller. I am, I'm an, uh, principal analyst at Paradigm Technica.

I am an engineer turned marketer, turned industry analyst focusing on cybersecurity. And I'm on the exact opposite side of the fence as Melu. Well, thank you very much for joining us.

My name is Tom Hollingsworth and I am an event lead here at Tech Field Day focusing on security. Let's jump into the premise for this episode. We've often heard that the department of security is in fact the department of, no, you can't do that.

We can't expose that. But when it comes to compliance, it's often the department of, yes, we'll just put these check boxes on this list and when we address each of them and we check them off, then everything's done. We're secure, we're not gonna be hacked.

I mean, how hard can it be? However, we all know in reality that compliance does not equal security. Alright, I'm gonna jump in with this because I think people need to understand that just because you comply with a regulation or a set of standards or something like that, that does not equal security and I'm, I'm gonna get obviously input from everyone here.

Uh, just to give you an example, uh, yeah, I totally encrypted all of that information with a des Cipher, so I'm secure. Right? Well, exactly.

I think, uh, that's the key is the requirements were put are put in place. The compliance requirements are put in place to focus on helping you secure your organization, but they are not sufficient to secure your organization. Uh, just because you encrypt something doesn't mean it's secure.

If you don't use the right encryption algorithm or store your encryption keys safely, you know, if you, you put your encryption keys on the whiteboard behind you as you're doing webinars, then that's not really secure, even though you've complied with the requirements to encrypt all your data. Yeah, for me it's always, I hear one, I'm pleasantly surprised that you said compliance is the department of Yes. 'cause I've never heard that as a compliance officer.

I've always been told like, you guys are the police, you're the department of, no, I always thought that that was something that like IT security and compliance that we all had the same vibes on. But I, I will say I'm a compliance officer that comes from a position of yes and problem solving. I agree with today's premise in the sense that you cannot have compliance without security.

I don't think you can have security without compliance in the sense that for me, compliance is the overall framework and the structure of the program security is actually how we actually do what we say we're gonna do. So when we're talking about doing the right thing and checking the box, I really, really hope it goes beyond just like passing an audit. Because I will agree, just doing a SOC two, an ISO 27,001 to me is not enough.

If it's actually just like a reason of an audit and it happens once a year, then maybe you're secure for that one audit assessment that everybody scrambled for ahead of time. But ideally, we want our system secure 24 7 365. We never wanna feel like we're only securing systems because an auditor asked us to show them something.

Well, I think the auditor is a, an important part of the equation, which is, is your auditor. And you know, we had a discussion earlier, is your auditor a CPA firm or is your auditor somebody who actually understands security and the implications of what the requirements are that you're trying to meet? Right?

So if you don't understand why a requirement is put in place, what it means, and when somebody says it's not applicable in this particular case and your auditor says, I don't care. The requirement is this, you must do this, then you have a problem. Right?

So just can your auditing team and the compliance, the requirements themselves be flexible enough and bend enough to actually provide you that security that you need? So let me ask you this question because I've had my fair share of audits that have gone sideways. Um, and a lot of times what it comes down to is the auditors in question not being knowledgeable enough about the subject matter that they're auditing.

And, and the anecdotal story is that I was ins, we had installed wireless access points for school and we had put them in the ceiling. We were running them over power, over ethernet switches. And when the auditor was doing the audit, he wondered where the power adapters were for the access points.

And that was a 25 minute conversation about how power over ethernet works because the auditor did not understand that you did not need power adapters. But on the list that he had, power adapters were listed with the access point. And if he didn't check both boxes, he couldn't pass this for the audit.

So do we run into this situation because the people who are performing the audits don't have the breadth of knowledge to understand where the importance should lie in the audit itself? Or are they just reading off of a list that somebody handed them because you're the the person on deck this week? It really depends on the audit firm.

And so for me, I always am trying to find audit firms that have really good people who know what the f**k they're doing. I have had an experience one where I used to work in cloud hosting and I used to fly around the world and audit data centers around the world. It was like the coolest job I've ever had.

I will say once, you know, we would do those internal reviews where I would basically go on behalf of the companies to basically try to break into cages and walk out with things. And so that was, you know, an internal assessment, which is a friendly auditor. Then we would bring our external auditors, which was not a friendly auditor.

I had one once come out, he had graduated from college two weeks before. He had never been to a data center before and he was there to do a FedRAMP physical security assessment of one of the best in class data centers within the US and we had to walk him out because he could not, like he was, I mean if you've ever been to a data center before, it is a really cool experience. For the first time I was not willing to pay for somebody's first time into a data center if that was also how I needed to do my job.

So we basically ended up being like, Hey, like we're gonna ask your team to send out another assessment and we're gonna do it again. And fortunately, that firm did make it right. They did send somebody else out, but it also cost us a ton of money.

'cause I was traveling out there so suddenly, like, it's wild. So for me, it's always trying to find the right audit firm to making sure that they're actually technologists and not just right, like somebody with a financial background who's done finance audits and now suddenly is doing technology audits. That's a really steep learning curve suddenly if you're doing financial and accounting audits and then suddenly to be dropped into a data center for the first time and learn where the internet lives.

So I think for me, it's really important to always be partnering with audit firms who have technologists that are also auditors who are really in the business of actually validating the controls and not just checking the box. Well, I don't, I don't wanna beat up on auditors. I mean, I brought that up in part because we've all had those types of experiences, but I think there's also, um, uh, to some extent I have issues with some of the requirements not translating into stuff that doesn't necessarily make you secure.

For instance, there's a lot of requirements for DLP data loss, data leak protection, right? And the DLP solutions, uh, up until very, very recently, the last maybe year or so, DLP was in a state where it was insufficient to be able to capture everything that people were doing with confidential data and to understand what that data is, classify it and secure it in one form or another. However, a lot of organizations said we've, we've checked the box from a requirement we've put in place a DLP program, we get alerts, we process alerts, we do stuff.

Obviously our data is secure. And that's a little bit like the, the, the somewhat facetious discussion we had at the beginning about encryption, right? Is DLP sufficient to, for data security at this point in time?

It is definitely not right? But it is a lot of what people look at when they say, I've complied with my data security requirements. I have encryption in motion, I have encryption at rest, and I've got DLP, what else do I need to do?

And it's that part of the compliance requirements that bothers me from a security perspective that it's not really providing true security functionality or utility or, you know, securing your organization. And I think that's part of why we keep coming back to this so many times is because the intent behind what we've done with security is valuable, right? We're trying to keep data safe, we're trying to keep users safe.

We're trying to make it so that everybody on the whole is better off with this than they would be without it. It's when the regulations don't really match up anymore to what we see in the real world. And I think my favorite example of this is your average spear phishing education campaign, right?

Like we tell people over and over again, don't click on links. Uh, if the URLs there type it in. Don't just assume that whatever you're clicking on is gonna let you do that.

And, and I feel like people are getting to the point where they're fairly at least aware that that's a possibility. But I also see when it's getting taken too far, I think my favorite example of that was when uh, someone was sent an obvious email that included a link at the top that said, is this a spearfishing email? Click here to report it.

And the button was the link that spearfished you and they sent out a report. And now what you've done is you've discouraged everybody from following the guideline because well now it's, everything's a trick, right? You're just trying to make me look bad in front of my boss, so I'm just not gonna do anything secure at all because if I'm not gonna, if if it's not gonna work, then why should I even bother?

It's just making my life miserable. These are the people who have a notebook full of passwords and they just change a letter and a number every time and rotate through 26 passwords because well, the system says I can't do anything else, so I'm just gonna do it like this 'cause I can't remember anything. Whereas if they were able to do something, you know, like, I don't know, enable pass keys or biometric uh, authentication, they'd be 10 times more secure.

But the regulation says we can't use pass keys or the reg worse. The regulation doesn't say we can use pass keys. So in order to be specific about the regulation, we must rotate passwords every 30 days.

Well, now, now see that's where it gets really interesting is this crossover between compliance, user education, security, and what we're actually trying to do. And you know, you bring up passwords and I'll go to another one of my favorite examples, which is, uh, on identities as identity governance, right? And we have a requirement that we have to look at every identity in an organization and validate that that person's identity has the correct access for what they're doing now, right?

Their entitlement. So we do a review. So the way this works in real life is a line of business leader, the division manager, the department manager has a hundred employees reporting to that person.

And the IGA program sends out a list of here's your a hundred employees and here's every entitlement they have. Is this correct? Right.

So that's the meeting the compliance requirements is we've asked our, our line of business people to validate that their employees have the correct access permissions and great, that's very good. Except what does that line of business person do? I've got a hundred employees, each of which have a thousand entitlements, and every single one of these is some incomprehensible long string that I have no idea what it means.

So I'm going to say, yes, I've reviewed that, and I'm gonna hand it back and say, everything looks great, right? So we've done everything we're supposed to do as far as governing our identities. We've gone and we've validated everything, but nobody's actually done the real work to say, does Tom actually need access to the accounts payable system?

Right? And that's, this is, this is the challenge I have with a lot of these compliance requirements because it becomes so onerous the way we've implemented the checks, it's become so onerous and burdensome on the people whose job it's not to be security that we don't get security anymore. Okay, well, everybody's job is security.

Just just so we're clear, it's not just one team, it's not just compliance, security, id, it's literally everybody's job. We all have to be secure. But I hear what you mean.

And for me, I think when we're talking about is it compliance versus security, to me it's always just better if those teams are on the same page. A hundred percent. I think from a compliance mindset, I always see as framework, the regulation, the requirement that we're going after, which is turning into security controls, right?

For me, it's the minimum. It's really like if we do these things, we do the bare minimum and we're checking the box. When I've seen organizations be the most successful with securing their systems is when compliance and security have gotten in a room together workshop being like, these are the goals of this program.

These are the requirements. We all agree that this is the minimum that we're doing. We have to meet these things to be able to get this attestation, this goal, this thing that we're all working towards together at that time is a really, really great time for the security team to be raising any additional risks or like weak points within the system to try to figure out can security and compliance finesse those things together to try to improve the program while they're getting the budget approval spend for this new attestation?

It's a lot easier for an executive team to approve a new security tool or like a new program if the compliance team, they just have easier justification being like, we cannot get this standard because we're missing these things. And so I've seen the best security systems get implemented when compliance and security are on the same team. Compliance is coming saying, these are the rules we're trying to follow.

This is we're gonna try our best, but if security is saying, these are the best practice things we want to do on top of these things, and then we all get approval at the same time, because that's how the whole company wins, right? If we're securing the system, the entire company wins at the same time. But it's easier occasionally for compliance to get the budget approval if there's a new attestation versus security just saying, we want this new tool.

So I will, I will jump in here because there's, there's a trap that you've set for yourself by doing that. Um, and I, I have to reference one of my college professors, Dr. Tracy Cart, um, when she said that there's really only two ways to motivate people, fear and greed.

Well, obviously security works really well on the fear side, right? We don't want our data to get exposed, we don't wanna end up on the news. We don't want the stock price to fall.

The problem is, is that when you encourage the adoption of things through the other thing, greed, right? Like I wanna make sure that we pass our audits. I wanna make sure that we do these things.

I wanna make sure that we do, we are compliant here. And maybe you do something innocuous, right? Like, um, if you pass this, uh, audit, then your, your budget goes up to support these new initiatives next quarter.

Or you know, with executives it's like, hey, if you pass the security audit two years in a row, then your compensation package is modified and you create the trap for yourself by saying, well, is the important thing that the security is in place or that I pass the audit? Because what that creates is a race to the bottom condition where I'm not looking for a rigorous auditor to come in and tell me everything that's wrong so that I can fix it. I'm looking for somebody who's gonna come in and do a bad job of checking all the boxes to say that I've hit the number.

And then that won't appear for years until we make the news because someone forgot about a, uh, a hardcoded login in a development system. And that's how a state sponsored actor backdoored my system and stole all my secrets. But the executive who got rewarded for passing those compliance audits for the last five years, they're long gone at this point because, well, they didn't care.

All the boxes got checked. It's tricky because this is really how the industry is set up in the sense that most organizations are not doing security or compliance because they really wanna be super secure. They should be.

We can all agree on that in this room that every company should want to be secure. Most of them are starting the approach to compliance and security because their contracts require them to, because suddenly they got a deal that requires a SOC two and ISO 27,001 or FedRAMP in the us we don't really have technology regulation forcing down security requirements in the same way that we are seeing attestations and certifications to be doing the same yet. 'cause like GDPR, for example, in the EU only says that an organization has to follow, you know, like security.

They basically get to decide what is secure for them. Obviously, we as best practice individuals, we have certain baseline standards, right? If data's not encrypted, they're probably not gonna hit that threshold, but it's still up to the individual organization to dictate what it means for them to be secure even to comply with something like the GDPR.

So because we don't really have true regulation from a like government perspective of what it means to be secure also 'cause it's really hard for them to keep up because it's changing so quickly, it's coming through the customer demand. And so that's why a lot of this is tied to greed in what you said Tom, is really because it's been coming from the customers, the one demanding security. Ideally, it's amazing when cus when companies are focusing on security first, that's incredible.

It's just for the most of them it was an afterthought. Yeah. I I I think that's right.

And I, you know, a lot of what you're talking about is the, the people versus process and the goal setting, right? And if you are an organization that is simply going to do checks the box compliance and security, you don't believe in security, then it doesn't matter what security doesn't matter. And you know, this conversation has made, you've, you've got your, your compliance and you're done.

If you're in an organization that actually does believe security's important, then you need to think about how do I go, how do I become secure and compliant simultaneously realizing the two are not synonyms, right? And I, for me, that's really the key is that, that, you know, that that goal and understanding it and it's how do you go beyond putting in place a program to do X, y, or Z to really understanding if it's making you more secure. You know, Tom brought up the great thing of security awareness training and um, you know, my wife worked for a biotech company and she saw a spam phishing email and being a, you know, somebody who works with a cybersecurity person said, is this spam?

And I, you know, is this phishing? And I said, yes, it's clearly a phishing email forwarded to your email administrator. And the email administrator's response was, yes, that's security awareness training.

Click on the link so you can see what happens next. So the program is actually training people to click on phishing links to tell them no, don't click on phishing links, right? When the right response should have been, thank you for letting us know you passed the test and I'll go tell somebody to mark you manually, mark you was passed the test, right?

But so, so again, we're, it's that we're we're paying lip service to security by saying, yes, we've got a cybersecurity awareness training in place. Not thinking about what telling somebody click the link does. Right?

And I think that's, that's the, this is what gets my goat so to speak about this, is it's really irritating when people do the wrong thing for what they think are the right reasons. Well, the other thing that I think is important to understand is that the regulations also need to be malleable enough that we can change them when we realize we've run into a problem. A good example of that is if you implement a policy for passwords in your organization, your goal ultimately is to prevent people from using insecure passwords.

Right? But what if your policy prevents the use of a more secure password? For example, a password policy that says you can't have more than two sets of two repeating characters.

Okay, but what if my ultra secure 26 character password has four sets of repeating characters in it for whatever reason? Now technically my password is out of compliance with your policy, so I have to weaken it to meet your policy. As someone who's on the other side of that divide, it's frustrating for me to say, why am I forced to comply with a regulation I know isn't as secure as what I'm going above and beyond to do?

And creating that kind of, I don't know, friction. Because one of the things we've learned over the years when it comes to security is it works best when it's invisible, right? I remember when face ID came out for the Apple iPhone and everyone was complaining because, oh, well, it's not gonna be as secure as typing in a passcode.

What they didn't realize was the way that they used their iPhone changed when they just had to look at it to unlock it as opposed to typing in a code every time. Because when you do that, people can't shoulder surf your face. So we became more secure over time simply because the security control that we were trying to prevent phone logins disappeared underneath the phone itself as opposed to typing a passcode or putting my fingerprint on there or what have you.

So do we, are we setting ourselves up for failure because we're, we're aiming at the low end to ensure compliance, but we're overly restricting the people who are not only in compliance, but maybe even possibly even beyond that. Yeah, it's always built for the weakest link, right? Unfortunately, a lot of the, a lot of the controls are being built for the weakest link.

I will say, as we're rounding out, for me, it's when we're talking about are we checking the box, are we doing enough from a compliance perspective or should we be doing more from a security perspective? I would say my thought on this has always been making sure that our companies really thinking about, do they only wanna check the box? Because I agree with what we've talked about today.

If you are compliant, you might not be secure. And so for me, it's always thinking about like, there's a misconception with a lot of organizations that they're like, oh, well, because we're compliant or secure, I think the conversation needs to be different of compliance is helping us set a baseline standard, but security will continue to be a best practice. What will push us forward faster and be hopefully more innovative and honestly maybe even a differentiator in the market if we're thinking about security as the competitive edge that improves the organization's compliance posture.

As you can tell from this discussion, compliance isn't security, but they, they don't have to be polar opposites. One impacts the other and vice versa. It's very important to understand why you're trying to be compliant with certain rules and regulations, but also what it takes to make sure that you are not just checking a box.

If you ever get to the point where you're scanning down the list and checking things off, just to say that you check them off and not verifying that they're actually done or worse yet, finding yourself, opening your open up to other issues down the road, you're really defeating the purpose of both of those things. So take a step back, really understand what you're trying to accomplish and make sure that the reason why you're holding this audit or you're meeting all of these guidelines is something that you and the rest of your team understand. That'll just about do it for this episode of the Tech Field, a podcast.

But before we go, I'd like to give our guests a chance to let you know where to find more of the content that they create. Starting with me. Lou, Run.

Thanks again for having me today. You can find me, Mila Meyer on LinkedIn. com.

Thanks, uh, it was a pleasure, uh, talking with both of you. com. And we wanna thank each and every one of you for listening to this episode of the Tech Field Day podcast.

If you enjoyed this discussion, please make sure that you subscribe on YouTube or your favorite podcast application of choice so that you don't miss any of our episodes. And we would love a rating and a review if you have the time to leave one, because it lets people know what we talk about here and that we are in fact using the word premise correctly. This podcast is brought to you by Tech Field Day, which is the home for IT experts, for cross enterprise.

It, it is a part of the Futurum group. com, pod slash podcast, or check out all of our episodes on Techstrong tv. Thanks for listening in.

We'll see you next week.