When Compliance Replaces Security

Have you ever had the feeling that you needed to do something because of corporate security? You didn't really know why? I certainly have. Welcome to Threat Talks.

My name is Lieuwe Jan Koning, and here from the Security Operations Center at ON2IT. We bring you the next episode. Let's get on to it. Welcome to Threat Talks.

Let's delve deep into the dynamic world of cybersecurity. Let me introduce my guest of today. His name is Sina Yazdanmehr. He is the CEO of Aplite, and he'll introduce himself and his company in a minute.

But we're going to talk to him about, because he is, he talks to many, many different organizations, small and big. And so he knows a thing or two of the real practice of cybersecurity. And we started talking a while ago about how culture in organizations affects cybersecurity. For example, what if compliance is too distant from reality?

Or what if your users do not understand or trust the things that you require, or the tools that you give them? Well, we’re here to talk about that. Sina, thanks very much for joining. Hey, thank you so much.

What does Aplite do and what does your job look like? Sure. First of all, thanks for having me back for the second time. It's good to be here again.

About us. So we're actually a boutique IT security consultancy based in Berlin in Germany. And we usually help companies of different size from SIP to B corporates to get their security under control and on track, both from the compliance perspective and also actual security to be sure they cannot be breached or compromised by threat actors. Yeah, I remember in our previous time you were here, we talked about a huge leak of all kinds of medical data that was, that you apprehended and it was astonishing, really.

What you uncovered. But today we're going to talk about a little bit different things. Two things mainly actually, we're going to talk about how compliance sometimes has the wrong effect. And the other one is that, sometimes it's hard to deploy a security solution with good intentions.

And how do you make sure that that doesn't happen? So let's start with the first one. You had an example of where in an organization, a certain risk that was really there was mitigated in an unusual way, maybe. Can you elaborate a bit on that?

Exactly. So it usually happens when in companies they sort of mix compliance with actual security. And they try to address the security risk or gaps with just compliance. So the example that happened, it was actually in a big corporate that when we started the project with them and we wanted to help them enhancing your security as a company.

The first thing we noticed was a big [ ] of risk acceptance that it was already approved from different departments from for different severities and different applications. Okay, so I understand there might be a reason, but some of them are, for example, valid for two years. What's happening here? You mean [ ] there’s an acceptance of a risk that has been there for two years already and never, never been talked about anymore?

What kind of things are we talking about then? What kind of things? Different ones. For example, not having the firewalls in front of a new system that was deployed two years ago and they said, yeah, for now, we are not sure we are going to deploy something..

later. Never. Technical vulnerabilities, architectural gap, whatever you can think of. It was there and from different departments and other ones.

Once we had some interviews with different people and try to understand what happened, turned out that it became as a part of their company culture that when they have a new initiative, new system or whatever, there are some sort of security checks. Of course. There's a list, there are some requirements they need to go with, but instead usually the project owner, the product owner bypass all of that and just calls it security risk exemptions, all those items. And they know that they usually get support from the top management because that way they could save a lot of time, a lot of effort, go faster, launch faster.

And the management wanted that. So they supported it. And that became a sort of legitimate way for bypassing security and say we're having security because this is part of our process, right? Our CISO department says if you have short resources, if you don't have time, you can fill out this form, explain what's happening and then go live.

Then afterwards you're going to fix it, right. But the point is that they never fix it. They just ask for a renew, renew, renew, and the lists just grow bigger and bigger. And when the CISO, so the CISO had this problem, I say, okay, I'm trying to fix it.

But also the answer I get from the top management is that you create this process, right. You brought this process to the organization. You said this could work this way. A lot of effort, a lot of time is spent on it and now you want to change it.

Look at the list of risk exemptions. If you really want to fix all of them, it's going to be years of work. We cannot afford it. So they got themselves into a situation that they sort of mix or confuse compliance and security.

They started to solve- The gap between the two becomes too wide then. Exactly. So I'm curious, how does that work then? Because there must be.

You said the CISO actually understood what was going on then. Was it, did he make like a policy? I mean, but it's very common to be able to make exemptions, for example, for the short term indeed. Or maybe I mean, in the end, the CEO needs to weigh everything right.

Indeed go to, I mean, if your alternative is to go bankrupt, it's understandable that you would then post at least postpone a piece of cybersecurity. I can understand that that happens. Right. So it's not, and it's very common that you have an exception list.

So why did it grow into a culture then here? I think there were multiple factors. First of all, the pressure from top management because they had very big ambitions that we need to do this, that, get more share of the market and always precedence for business objectives. Another very detailed problem was that the risk exemption by default could go for one year.

And when you’re running a system with some sort of risk for a year, then it becomes harder to allocate resources and justify you need to fix it. So it makes it more easy for different parties to justify, see, for a year, it works, no problem. And then extend and extend. And I think that situation was running already for 5 or 6 years, if I'm not mistaken, and CISO started thinking about the situation already a bit late, that the list was already long and it was a sort of settled culture in that company, so changing it was much harder.

I guess if they started a little bit earlier, could have been easier, and they could have their risk exemption process a little bit more controlled and shorter so they could mitigate it earlier and better. But they started thinking about it a little bit late. Yeah. And were you able to turn it around or are they still doing it?

Yes. How? To some extent, to some extent. So what we did was first to redefine the whole process, shortening the period to make it a bit harder to get the risk exception.

And actually we made it more clear what risk exemption means. It's not just that you fill out a form on ServiceNow, you click submit and you're good to go and launch your program. We made awareness among all those management that this has a legal responsibility for you. If something happens this form shows that you took responsibility for this particular reason means this, this, this.

And then you start to sort it with their severity based on their inventory and whatever they had started addressing them from the top priority going down. It took us almost a year and a half to clear this to some good extent and sort of reestablish the culture, but I would say it fixed not 100%, but to a good extent. Okay. Yeah, no, I can imagine.

I mean, I'm sometimes in those discussions myself. Yeah. Exactly. I don't know, what is your experience actually?

Yeah. So what we've seen sometimes, is that there's auditors, auditors for SOC II, ISO 27001, all those kind of frameworks. And then and often there is like a yeah, a requirement or at least a interpretation of a requirement that this doesn't really fit your organization. And then actually the question about are we going to accept this risk comes up because we have the same thing, risk acceptance for the short term.

Or if it's really difficult to do, or really expensive, you can always take a limited risk as long as you're really aware of it. And I remember one time that we, there's a thing in RBAC. So, role based access of our users, so a user is part of a role. And the role then gives you permission, for example, SOC employee has a role, etc..

And, what auditors really wanted us to do is to validate that our intention of who was in what role and what role actually could do what, that we should, that we prove that the intention and the actual situation was the same. So they wanted to have, they wanted us to do a comparison and how we set this up is, we have a central repository like an LDAP repository where that all is that is both our intention, but on technical level it really is the real world also. So from my point of view then, from a technical point of view, the IST-SOLL is the same.

There's nothing to prove, just the statement that we use the same thing for it. And it took a while. We could also have said, yeah, we accept the risk that we don't do the IST-SOLL thing, but that really isn't the right solution, I think. So we actually went into a conversation with the auditor and explained how there was, now we have a document explaining how this works and what we focus on now.

And that’s what I was really happy about is that, whenever a role changes, for example, that we know that there's always really approval to in the right parts of the organization so that it cannot be by accident or because you know someone in IT, for example, that you get another role or get another permission in a role, etc. No, the change process on that is regulated. And that's a much, much more important thing, I think, than doing... Yeah.

Because we could also have made an Excel spreadsheet. Right. And like I said in my introduction. Have you ever felt that you need to do something?

Well initially, that was the plan, and I'm happy that we turned it around at that very moment in time, and that keeps the exceptions list down. I don't like the exceptions list. I mean,... That was a very good point.

If you know someone in IT, you can bypass any of those process and just get access that you're not supposed to have it. Yeah, exactly. Your friend make it happen for you and nobody knows. And at some point, turns out that someone did something.

Yeah, yeah. And at some point... You can still make it happen, but then at least it will be, it will soon be visible and acted upon. Exactly.

That's what you need to account for. So I think the discussion on, to me, the pole star here is that if there is a piece of legislation that has as an intent or so and it and it feels too harsh in your example that you say it's like, yeah, a lack of speed, for example, you need to do something. I mean, you need to certainly do the basics, but maybe there's a way that you can make it easier and make it as effective, but not like as it's written down, because often, I see that often that there's corporate guidelines.

I don't know about you, corporate guidelines that state stuff, that indeed stem from some kind of, common knowledge, a good thing. But in reality, yeah, it's not practical anymore. It misses its target a little bit. And then I think you should be flexible.

Exactly. And as I said, also giving context is very important that signing a risk acceptance as a manager, doesn't mean that you just submitted a form on an online website. It means something, you're taking responsibility. And if something happens, you're legally responsible for the outcome of that exploitation or whatever.

Yeah, yeah. Shall we? There's also another thing possible. It's the other way around.

Yeah. You also had an example of that where trust plays a role, more or less. Exactly. Where I connect these two topics is when companies give your employees, for example, company issued laptops phone or they tell them, oh, let's say we use this messenger as a corporate messenger.

Please do not share messages or files on other applications. Or for example, don't use your personal account on this application. But people don't know why. They say, for example, if you talk to me as a person, I say, hey, but I use like WhatsApp or Signal on daily basis.

I exchange anything, say it's.. I don’t think that’s been wrong, why I shouldn't send something to my colleague where that's.. The example I had, was for example, now that a lot of AI systems are out there, like ChatGPT, Gemini, etc, and many companies started getting their own accounts, enterprise accounts to make sure their data is not being used for training the algorithm. One of the companies we work with, they also got that enterprise deal with one of the providers because they knew [ ].

You’re talking about a zero retention policy. Yeah? That you don't get to use ChatGPT for free or Claude or whatever for free, then - Exactly. - your data is being trained on.

Why is that a problem? Exactly. Well, I mean, for example, a company that's particular company that we work with, it was a SaaS provider and their employees started, for example, checking their source code with ChatGPT or for example, their legal department checking the contract before sending it out or something for finding risk. I mean, if the model starts using your data for training, that means at some point there could be some exposure somewhere, like if someone exploited the prompt injection or something like that, the data could be exposed, part of your source code.

If, for example by accident you have also a sensitive information like API key, private key hardcoded into your source code, might be exposed somewhere else. That we had some cases on the news that you saw, everybody saw I guess. The same as legal information, because again, by law, you're not allowed to share it with different parties. And if there's a breach or it could be also publicly exposed.

Yeah. Yeah, I remember the, so what you could do, we’ve seen that you would say my username is and then your username and password is. And then the password is actually trained by the model. So it knows it predicts what your password is because it saw it before.

And the same with a legal document. If you say, so I say my most important customer, company A, and I say, put in Chat or in auto-add to my sentence, what’s it called, so and then you say a typical discount percentage of company A is and then it will actually put my number in. Right. Exactly.

That's the kind of thing we want to avoid. So that's why we have enterprise contracts. Yeah. Sounds amazing.

So then you have an enterprise ChatGPT on your laptop. Everybody. Exactly. For the employee.

Everybody can get their own subscription and use it for work. Like, then it's okay if you share a contract, piece of source code, or anything. I mean, still, you shouldn’t share everything with said model, but it's safer. And that company had the enterprise contract.

When I was talking to their CIO, like, okay, how you're handling the current situation, which ChatGPT, and he said oh, we’re good, we have this enterprise contract and I know everybody is using it. We have now about thirty subscription available, I’m like, your company is about 100 people. 800 people, sorry. 30 sounds too little as a subscription for your [ ] Either they're not using it enough or they're doing something else.

Exactly. Exactly. Like numbers don't add up. Let's like look into it a little bit deeper and turned out afterwards that many other users were still using their own private ChatGPT account for work, uploading code, contract, etc.

, etc. and the reason was first one group of them didn't understand there is like, ChatGPT is ChatGPT, enterprise, my private account. If you say it's good, it's good. If it's not good, then why you have the enterprise account?

So they didn't have this background of that. Hey, this is not being used for data training. And the second group were more like if I use the enterprise account provided by my company it’s for surveillance, my boss wants to know what I'm doing. If I write the code myself, or I just get it from ChatGPT.

I don't know what monitoring they have. They see whatever I do. And it was, again, I would say context and trust that some people didn't know that this is just because of security, and some people didn't trust their company. Like, yeah, they just want to see what I'm doing.

And I think because of that- And it is opposite, the intention wasn't like that. I mean... Exactly. [ ] we know, the intention is to actually do record everything that you do and your company does it.

That's the reason in the first place. So how do you overcome that? Because this is probably true for many companies. First, how do you...?

I understand that 30 out of 800 is low. So that's an indicator. But even if that's not the case, maybe how do you make sure that you know that everybody is using your enterprise license? So I was saying it goes back to the security culture.

And I will say security culture isn't a separated topic from the company culture itself, it is an outcome of that. It's about how a company handles pressure, conflict, frictions, etc., etc. and it depends how much employees trust their company and what they’re asked.

It's about the trust between them, between management and employee, and they.. it should be clear why we use this tool. What employee does, why they asked you not to do it, and make it clear that we are not using it for checking your performance, etc. etc..

Still, there might be some people who don't believe it or they have a different opinion that you should go, let's say case by case in some extent, but if you want to see it on a high level as a company of hundred people, I would say beyond security, you should have the good trust with you between management and employee. So they trust when you tell them, don't use this tool or use this tool and also give them context, because usually security teams make these mistakes that they assume all other departments have the same security and IT knowledge as they do, but let's say other departments like maybe finance, marketing, etc.

they don't have the same level of security knowledge and experience, and maybe it's not very clear to them what's the difference between an enterprise ChatGPT account and a private one. So once you make it clear and understandable, definitely you see the impact that they understand why they should use that. Yeah. So CISO, IT manager, CEO, whomever should as part of, like we say you should be on time, also say this is, because otherwise obvious reasons, but for cybersecurity those reasons aren’t probably always as obvious.

So what you would advocate is that there's like a cadence of communication there. And would it be in the New Year speech or is it a newsletter? What works best? I would say it’s not a once in a year occasion.

I mean- So New Year’s speech is not enough. speech is not enough. [ ] But definitely through the, let's say, all hands meeting that is very common in different companies that have been regularly, usually security team can have a slot to present or reminder in the newsletter. They can do that again.

And of course, Christmas speech is always a time to remind them about security topics. Yeah, that's your favorite topic at Christmas? Cybersecurity. I feel this.

Exactly. All right. Well, clear, that is a clear message. We need to do the communications as you explained and for the compliance be critical on what you waive and find the practical solution to all the requirements that are there for a reason, right?

Sina, thank you very much. We'll talk again next time about a slightly different topic. But it also has to do with culture, but in a slightly different angle. Thank you so much for today.

Sure. Talk to you next time. To our viewers, thank you very much for tuning in today. If you like this, press the like button.

And I did say that next time we're going to talk about another topic on cybersecurity culture. If you don't want to miss it, press the subscribe button because then next week it will automatically be in your inbox. Thank you very much. Bye bye.

Thank you for listening to Threat Talks, a podcast by ON2IT cybersecurity and AMS-IX. Did you like what you heard? Do you want to learn more? Follow Threat Talks to stay up to date on the topic of cybersecurity.