Hero Culture and a $1 Million Mistake

You're under pressure to deliver the next feature , and this peer review you don't really have time for today, so we'll ship it into production. Next thing you know, your company loses 1 million euros. That happened. Welcome to ThreatTalks.

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 ThreatTalks. Let's delve deep into the dynamic world of cybersecurity.

Let me introduce my guest of the day. His name is Sina Yazdanmehr, and he's been on our show before, and I'm really happy he is back. Today we're going to talk about how culture of an organization can affect cybersecurity, and today we're going to talk about what happens with security if an organization is under pressure to deliver something, or if the security department says no all the time. What do you do?

How do you move around that? Well, Sina, welcome in the show again. Hey, thanks for having me. And you are CEO of Aplite.

Could you briefly explain what Aplite does? Sure. We are a small IT security consultancy based in Berlin, Germany. And we mainly help different organizations from SME sites to big corporates to get actually their security under control and on track and make sure they're compliant with their requirements.

Great. Yeah. So you know a lot about the real world and how to solve problems that you encounter in many different organizations. Yeah.

We were talking the other day, and you had an example. In the introduction, I said something about pressure. And actually, I got this 1 million euro loss from you. Could you explain what was the situation here?

You didn't lose it, but one of your customers. Yeah, I didn't lose it myself. Good. So far.

But exactly. So let me get us started with this story and what happened, and then we can analyze it, why such those cases happen. So one of our customers that handles online transactions is a SaaS, and they usually have a big pick in their transactions around the end of the year when there's a Black Friday, Cyber Monday, Christmas time. And that actually brings a big chunk of their revenue that time of the year.

Two days almost before Black Friday, they decide to launch a new feature. Everybody is rushing. We need to go live. We need to go live.

And they bypass a few tests, checks, including security compliance tests, and they just go directly to the production. As a result, the transactions goes to random different bank accounts instead of the right accounts. And because usually a transaction takes a few days to settle down, and then the finance team checks the accounts, it went like that for a week until the finance team noticed that numbers don't add up anymore. They started analyzing, and they started analyzing, and they noticed that there was a bug in the code that they pushed to the production before Black Friday, and it just randomly changed the bank account numbers.

So they lost money. It doesn't sound like a feature. Why was that in there? Is it like an oversight, or did someone test random numbers?

Why? What I understood is that they usually have some account numbers that they use for testing, and they forgot to change it completely before pushing to production. So one part of the account number was fixated. The good thing is they traced it.

Exactly. And so they lost that money. The money went to different bank accounts, and they need to trace all of that to see if they can return it. Yeah, it wasn't a very good Christmas time for them, unfortunately.

No. No. No. They handled it, but it happened.

And usually, such a situation happens that, let's say, so-called hero culture, that the person who saves the day, delivers the future on time, find the shortcuts to get to the production by the deadline, gets the rewards. So, so-called hero culture, the person who saves the time, gets the rewards, and gets the rewards. So, so-called hero culture, and that the person who saves the time, gets the rewards, gets the rewards, and gets the rewards. Usually, it's the person who saves the time, gets the rewards, and gets the rewards, and gets the rewards.

So, so-called hero culture, and gets the rewards. So, so-called hero culture, and then comes back to the people who saves the time, and gets the rewards, and gets the rewards. So, so-called hero culture, and gets the rewards, and gets the rewards, and gets the rewards, and gets the rewards. So, so-called hero culture, and that's how-called hero culture, and that's how-called hero culture.

So, so-called hero culture, and the hero culture, and the hero culture, and the hero culture, and gets the rewards. Yeah, and this one first surfaced, and there's probably lots of other things that also are in there, as a vulnerability, that nobody ever sees. Because maybe the pentest didn't even order, or indeed the peer review didn't really happen in the end, anyway. Exactly, exactly.

So, there might be a single-some vulnerability, as you said, that no hackers found and exploited yet. But that doesn't mean it will never come. Here, actually, for our company, compliance really works here. Because there is, in stressful situations, it is allowed to push code faster.

But there is always a very immediate review done. I mean, SOC 2, for example, is really picky about how you put that whole process in. So, it does, it can actually help you, if you don 't waive it. We talked about it last time.

This is probably a similar thing. Yeah, but you make an important point. The hero is the guy who delivers the revenue, and also prevents the potential loss of revenue. It's hard.

It's a bit of a prevention paradox. Exactly. How do you fight that? How do you fight that?

I mean, definitely, it's not the ideal situation. And unfortunately, most of the companies these days try to deliver as much as possible with the minimum resources. Because of different factors, because of different reasons. And usually, the business management sees the business objectives.

Security is a topic, not the most important topic . So, marketing has promised something. I don't know. The business development department promised something to the partners.

And the deadline is coming. The developer team has a big backlog. And usually, security topics is the first thing to postpone it for later. Because first, we need to earn the money.

First, we need to earn the money. And then, we will secure it. This is a very common pattern that I usually see in different companies, different industries. And it's very common that they say, "Let's do it for now.

If it works, it works. Let's launch it. And then, we will secure it later." Most of the time, they get lucky.

This test was a very significant unlucky situation that this happens. But usually, they get lucky if they launch it with a vulnerability or, I don't know, network misconfiguration. It takes a longer time until a hacker finds it and exploits it. But there are also cases like this one that no hacker needs to exploit you.

It's just you that you're trying to secure more revenue. But because you're rushing into it and bypassing those security checks, you're actually making big damage. Yeah. Understood.

Yeah. It's hard to change this, I think. And in the end, it is a risk. Maybe the key here is to really explain the risk better upstream.

Exactly. And honestly, also make sure that the leaders are actually responsible for security and not the CISO that can be fired when something goes wrong. But there is two legislations, for example, make sure that this happens, that the CEO is personally liable if they do a very poor effort. Yeah.

Exactly. So, I mean, based on… Yeah. Please, go ahead. So, we also have to be careful that we don't become as security people.

Well, the department of no. Because what you say is the heroes are there to celebrate the increased revenue, etc. And like you said, it's the nagging security guys that always say no. And I believe you also have an example in that realm.

Exactly. I mean, probably I've also experienced it. I would be happy to also hear your experience and thoughts on this topic. Because usually when it comes to a new solution system that a department wants, and it's super risky, you know, it exposes significant threats.

What the CISO department is that says, no, because this is the easiest way and they can just be sure that these increases didn't happen. No, I 'm good. I don't need to deal with that. Honestly, it's increased with the rise of AI.

Because everybody feels there's so much value to gain. I mean, the hero thing that you said, I mean, you have this tool or this marketing tool or something where you code 10 times faster, etc. It's a real benefit that you see. And at the same time, the risk is yet unknown, not seen a lot.

Well, we see a lot of risk actually in prompt injections and leaking data. We talked about it before also. And that is more and more a challenge, honestly. So I do believe that sometimes you need to actually bend the rules a little bit.

For example , if we want to test with tools, we have a process that allows for a new tool to have a super simple , a super lightweight vetting. We had to see if there's indeed zero retention. Where is the company based? How is it backed?

Is it a Chinese government company, for example, secretly? And we put, most importantly, what kind of data would we want it for? I mean, if someone is using a special tool to make an infographic with material, I mean, the whole point of that information is that it gets out. So I don't care who handles that data, right?

And then it's easier to allow an experiment with AI and then with experience, vet it. Because the other side is if you go through a complete vet ting process with every test or app that you want to do, that's taking so much time and so much resources. Most of the time, after two, three weeks, you're already, you know, this tool is not for us. So you need to, so it's a constant balance, I think.

And what you need to be careful is that you're not the department of no, honestly . Absolutely correct. And the thing is that if you say no as security team, and I would say it's just an illusion that you think you just stopped that initiative or work and you're good now. People will find a way to bypass it because especially in big corporates, then you have different departments, different functions, and security just says no.

They don't put their whole activities on hold because Cinder said no. You remember last time we also talked about it, that some cases, if you know a guy in IT, you can push it forward. And if security doesn't help to make that initiative secure and be involved, they just put the security aside. They find their friends in the other departments or internally and get things going.

Have you seen that? Have you seen awful examples of this? Yeah, yeah. A very interesting example, which was also related to AI, because you know that many companies, they have their own internal AI and machine learning team.

And usually those teams need to have access to data for training their algorithm for testing. Usually, mass data or partial data is not so useful because they cannot see corner cases. Bu ying data is not an option because it's not really aligned with what they have. And tokenized data is still expensive.

So the way to go right now in many companies is the data scientists or machine learning teams. And they also want to request access to production data to train their Android. And of course, we know that it's not the best case. Many departments have known for that question, typically.

Definitely. Exactly. But usually what CISOs or security teams do is like, they say, "No, no, no, no, no, no. We can't.

We can't have that. We cannot give you access to the production data." Which is, yes, correct. Correct.

But what happened in one of the cases we had, the data scientist team, I remember correctly, went to the security team and said, " Hey, we know it's against the rule, but for designing our algorithm, we have no other choices ." And security team said, "No way. It's not possible." They said, "Let's discuss it.

Let's see how we can do it." And the security team, instead of getting into a conversation, understanding the requirement, and finding the right compromise and common ground to give them access, at the same time make it secure, they just said, "No, end of this. Sorry. It's not going to happen."

That team went to the operation team who runs the production environment. They had friends. I don't know what ever happened. They were good at buying beers.

Probably, exactly. And they got export of the database via SharePoint. And then, because there were multiple different developers, they even put the database on the database. They even had external contractors that they didn 't even have a company-issued laptop.

They had their own laptops. They also got a copy of that. And this was going for a year, if not longer, until we finally realized that. And this is what I was like, "But I told you, no, I told you, don 't do it."

I remember like, "Yeah, but did you expect that?" "Just to not work because you said it's not secure. It's not secure." So what happened there, the CISO or security team could get involved, find a much safer, secure way of sharing that data instead of ending up in a position that you didn't even know where your prediction data is.

On how many laptops, how many contractors, external people have it. I mean, it was completely out of control at some point. Yeah. So try to find a safe way to enable it.

And yes, it may not be to your core principles, and sometimes it's a bit painful to allow it, but it 's better than the alternative that people do it themselves. We had a similar thing, by the way, a while ago, with the chat app. So WhatsApp, all those. We wanted to not use those in the company.

So we have our own self-hosted chat platform. But not everybody has a company phone. But we decided, very limited, so not in the high- secure rooms, etc. We put a very specific control in there.

But personal phones are indeed allowed with all kinds of... So we have some extra requirements. But we did allow it. And it's actually painful to have your own application on a non-controlled Android phone, for example.

So you have to... So it brings some limitation on the kind of data that can be in those channels. But that is what we did, because the alternative was worse. And then you don't know what happens.

And it's certainly out of control. Not so much out of control of the company, but even out of control of your country and all your legal requirements that you have. So yeah, sometimes you have to meet halfway. You know, to me, what a crucial factor here is, is the technical expertise of the CISO team.

I'm interested in your view. But what I see happening is that if the team is real technical, they really understand what the organization wants to do, and therefore can figure out the safest way to... Like your example with ML, that really helps. And at the same time, it's also a bit like a business partner.

I mean, if you jointly try to solve a business problem, that usually leads to the most secure way of doing it. Have you seen examples of that? Or what's your opinion on that? Of course.

I mean, it depends on the company and CISO departments. Some of the CISO teams have very good technical experts for hands-on, for both offensive and defensive. But most of them, to my experience, they focus on compliance and make sure everything goes on the papers. Honestly, I can't blame them because many companies, depending on the industry, they are subject to many different audits during the year.

So every month, every quarter, they need to handle auditors, preparing reports. So they are very overwhelmed. And when a case like that comes to them, they maybe most probably understand that if they work together, and the partner, I need to find a secure way, is the best way to go. But because of their capacity limitation, and their business audit, and many other things, they say, okay, easiest is to say no.

Because first of all, we don't have time and capacity. And if we do that, it's going to be also a topic on the audit, and I need to justify it, etc., etc. Yeah, and the best, if you experience this kind of CISO team, understandably, that it works in certain companies like that, then probably the best thing to do is to come up with a counterprop osal, which you put effort in explaining why you take certain risks and what the alternative is.

To do it in a risk-based way, to report in a risk -based way, usually works best in my experience. Then you give the CISO something to, not a wave maybe, but to adjust the details of how a certain requirement works out. And that typically is the best. It's ideal if you have like a back and forth on the same level.

But if that's not possible, then at least make sure that you try to attach to, try to achieve the same goal as the CISO, which is not a bad goal. Exactly. Okay. Exactly.

Thank you very much. Culture in organizations. Lots of things to think about. And, well, I'm sure that if you're listening into this conversation, you're like, hmm, this might apply to my organization as well.

And now I hope we gave you some pointers and ideas to combat those. Sina, thank you so much for joining us today. I hope to see you another time again. I really enjoyed it.

And to our viewers, thank you very much for tuning in. If you like this, please reward us with a like because it allows us to spread the word further. And that's what we're here for. Thanks so 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.

Thank you.