Storebrand Success Story (Part 2)

In this episode of the mnemonic security podcast, Robby speaks with Knut Elde Johansen and Øyvind Bergerud from Storebrand about their transformation from early cloud challenges to established cloud maturity.

They discuss how Storebrand shifted from outsourced IT to building a modern, in-house cloud infrastructure, and how security evolved alongside it. From implementing policy as code to enabling developers through threat modelling, purple teaming, and CNAPP, Knut and Øyvind share hard-earned lessons from building a secure, cloud-native environment. They also explore the changing threat landscape and how Storebrand prepares for attackers who are becoming just as cloud-savvy as defenders.

Transcript

Speaker 0:03

From our headquarters in Oslo, Norway, and on behalf of our host, Robby Peralta, welcome to the mnemonic security podcast.

Robby Peralta 0:15

Now that I have all this grey hair, I'm glad that my employer has thought about pension for me. They've placed their trust in a dependable and forward-looking company called Studebram. Their origins date back to 1767, when clouds were less digital and Norway was a part of Denmark. And in the modern era, they're well known as a leading player in the Nordic market for long-term savings and insurance. And given that they bear the responsibility of my financial future, I'm happy to know a few people that work there. A few mnemonic alumni, and a bunch of others that both I and the industry have great respect for. So after our chat in their fancy podcast studio, I couldn't help but connecting some of their success to topics discussed in the Policy as Code episode. Now I'm not saying that their success is due to Policy as Code or has anything to do with the guests of that episode, but I am saying that the current state of security in Sodebrun is a success story. And one that seems to have an awful lot in common with the material covered in that episode. So I'll let you decide and hopefully enjoy. Knut Elde Johansen, and Øyvind Bergerud. Welcome to the podcast.

Øyvind Bergerud 1:37

Thank you.

Knut Elde Johansen 1:38

Thank you. It's an honor to be invited. We've been listening to you for a couple of years now, so this is real fun.

Øyvind Bergerud 1:43

Yeah, we are really excited.

Robby Peralta 1:44

Warms an old man's heart. Me too. I think it's been 130 episodes and five years, and I've never been in such a professional studio.

Øyvind Bergerud 1:53

Yeah.

Robby Peralta 1:54

Outside of home. Yeah, yeah.

Knut Elde Johansen 1:55

Well, uh happy to please. Yeah.

Robby Peralta 1:58

So where are we right now?

Knut Elde Johansen 1:59

Now we're in uh big studio in Storebrand headquarters at Lysaker. So uh yeah, this is where we record a lot of uh stuff for our customers, and we have some internal podcasts and customer podcasts, and yeah, it's what did you say? 400 sessions here, yeah.

Øyvind Bergerud 2:15

And now also the Kron podcast, so which is getting really popular. Cool.

Robby Peralta 2:19

Well, it's nice to be here. I'm not gonna lie, I was nervous. I walked in this room, there's a bunch of people behind computers, and I was like, wait, they're not gonna actually like help us do this, are they?

Knut Elde Johansen 2:28

And and usually it's not the other way around, right? You have complete control and people are coming a bit on the edge.

Øyvind Bergerud 2:32

Yeah, but it's great to have you here and not seeing you only on the screen. Yeah, yeah, yeah.

Robby Peralta 2:36

Likewise, likewise,

Knut Elde Johansen 2:38

indeed, indeed.

Robby Peralta 2:38

So I'm I've known both of you for many years. Uh rumor has that. Um Stig, you guys obviously both know. Yeah. Uh rumor has it that he took everybody up to a cabin and locked everybody away for a couple weeks, and you guys came out with like a cloud strategy, cloud security strategy. Is that true? Did that actually happen, or is it

Knut Elde Johansen 2:55

yeah There was a gathering, absolutely. Yeah, and like uh the saying goes, never let the truth destroy a good story. Might be some modifications to it, but uh roughly I can I guess you could say that. Yeah, yeah. Absolutely.

Robby Peralta 3:10

Or was it you that locked everybody again?

Speaker 4 3:13

Yeah.

Øyvind Bergerud 3:14

What happened there stays stays there.

Robby Peralta 3:18

Yeah, but uh, let's say then uh when did this like cloud security journey start?

Knut Elde Johansen 3:24

I think that uh we had kind of an organic growth in the beginning, so 15, 16-ish, then people starting to get curious about cloud, but there was no strategy back then. So people were just testing out things, building something here and something there, and and for quite a while we didn't have a cloud strategy. So that was uh around the time when Stig uh entered the building that that it was clear that we needed to have something defined and work more consciously with cloud and not just have it as a pet project on the side, I would say. Uh so and then because of that, you you're uh you actually have technical depth even in cloud because you had something in AWS and you have something in Azure and you have something in GCP and they're maybe not cobbled together, and yeah. We want to make the job easy now, would we? No, no, no, that's no fun. Uh and and still things are popping out of the woodwork. So yeah.

Robby Peralta 4:16

Did Storebrand have uh a cloud strategy at that time? Like uh in general cloud strategy? Like I know the security usually will come up afterwards.

Knut Elde Johansen 4:25

Yeah, no, I think that that came with uh around the time the Stig came. Uh in in the organization as like a business object and so on, there wasn't really anything clear, a big strategy that were defined in the organization, but there was a lot of testing on different things, and maybe especially for the part of the organization that is running our web pages, stuybland. Uh there was a lot of focus on clouds and containers, and I would say probably from 16, 17, something around there. Um but it was more of a pet project and devs and engineering that said we're just going to do this, and then they did, and then it became a success. Yeah.

Robby Peralta 5:04

So there was no real like business chart behind it, it was just this is modern and cool and maybe more efficient, so we go that way.

Knut Elde Johansen 5:09

Yeah, yeah. And more the tech and the dev guys running it because it's cool and modern and quick, and let's see if we can get the benefits out of this. More than the business seeing the need for tech to do something to deliver to them.

Robby Peralta 5:23

And since we're a security audience, how was that uh I've heard, yeah, we we go to the cloud and then we realize how expensive it was, realize all the problems, we kind of come back. Has has Storebrand ever had that journey, or has it always just been it worked and we just continue with it? Or we maybe pulled some back?

Øyvind Bergerud 5:39

When I joined in 22, we were uh already good way on the journey. So uh what I was focusing on was more the transformation of the security team because uh the IT infrastructure was very ahead of the journey with infrastructure as code, and uh they were also driving some part of the security because the security team were occupied by fixing uh all problems. And so then we had to do a transformation of the culture. Security was often saying no, using in the old style policy documents that didn't really fit into cloud policies, so we had to transform it into being infrastructure as code, also the policy, and then we had to to change into becoming an enabler instead of a blocker. Now I think we are in a very good position because now developers are coming to us asking for detection instead of us pushing detection on them.

Knut Elde Johansen 6:45

We were very lucky to kind of uh get you at that time because focusing on that transformation at that time when our department security operations isn't uh it wasn't really set in stone. What is the mandate? How should we work? How will we make this cloud security operation thing operate? And having that focus, uh Evan is talking about, made it so that we actually were a part of the whole team, not somebody going against the grain, so to say, but but we were uh working on their terms, we were learning uh how to be developers with uh ESA and so on. We soon understood why they hated us as security because we saw the guardrails that we put on on them that were stopping us as well. But we were uh cooperating in a whole different way and becoming a part of the bigger team pulling the same direction. So that was very uh instrumental. The the approach that uh Evyn presented when he uh took over and and uh made it so that uh we have a team that is, I think, now working very good in the organization.

Øyvind Bergerud 7:46

And I think uh what we did uh really good was trying to learn the same language as the rest of the organization because in the past we had like the policy document, ISMS, the uh ISCD, and those typical uh security documents, but the developers they were talking code. So then we also needed to learn at least the basic coding to uh we needed to deploy our own stuff to get on the same level as uh as the rest of the teams. So so we had the common language so we we could discuss security issues, yeah.

Robby Peralta 8:20

So I want to come back to policy as code because that's actually something that I didn't really hear about until like last week, like policy as code. Because when I think of policy, I think of like, yeah, don't uh don't look at porn hub at work. That's a policy, like uh, but then there's like policy as code, and I'm like, okay. And uh actually, well, let's just start there. Policy as code. How's that journey been for you?

Øyvind Bergerud 8:42

We still have the ISO standards, and we still need to adhere to that. We still need to adhere to steering documents from top management. But what we're trying to do is translate those controls into actual uh security controls in the cloud environment. So we deploy malware unless if it doesn't exist and we don't open all ports on the firewall if it's not allowed, so we block it if someone tried to open it. And since we have democratized security and it's a lot of the infrastructure developers actually making the infrastructure, including security, and then we need to have some guardrails if they do something wrong. So the policy has called revert what is not allowed to do.

Knut Elde Johansen 9:33

And I think that in one way we were lucky because when we switched into the cloud focus, and and also then it meant that we started in sourcing. So instead of being a team that more or less were focusing on SLA, monitoring vendors, and so on and so forth, we we didn't touch any buttons at all. Moving from that to the complete other side, and we have to kind of write everything, but not in the portal, you have to do it in the code and uh and everything like that. So it was quite a shift, but then it moved us over to the the way the cloud is working and and how we can be a part of the native cloud uh way of thinking. And that was so much more interesting, uh, and actually be able to learn that because the technology that's easy, you always fix that. That's not an issue in migration. That's uh uh culture that's where you need to focus. Everybody thinking I'm gonna lose my job, some AI is going to do everything for me. Oh, I have to hold on to my stuff. I don't I must not share everything now, and so on. That's where uh the issues really lay, I think.

Øyvind Bergerud 10:30

And that was also maybe the biggest shift. It was the technical part where we moved to cloud, but we also in-sourced at the same time. So we took responsibility for our whole uh infrastructure, all our application, and previously we had that outsourced most of IT, and now suddenly we were a supplier and we needed to handle our own bot security findings, we needed to patch them ourselves, and there was no one to blame. So we needed to build a culture where we uh had the vulnerability management uh inbuilt in our processes, and uh we couldn't ask a vendor to do it for us anymore.

Knut Elde Johansen 11:11

Absolutely. And and I do think that that's uh that could be a place where you could get a little conflict, right? Because you have issues and it's so easy to to kind of blame the vendor and you shoot off some angry emails and everything is kind of outside the house, but suddenly that vendor is sitting on the other side of the desk. And and you have to cooperate in a completely different way. So we were kind of wondering okay, is there going to be a lot of tensions here? Is uh or but I feel that uh the uh culture in Storebrand in general are uh we're rooting for each other, and it's okay, you can do some mistakes, but it's important is to pick up the pieces and kind of do things together, and that is what saved us, I think, in in this cloud transformation journey. So I feel that uh the cooperation is even better than it was three, four, five years ago. And I see a lot of more people and working across uh how many developers do you have in Switch? A while ago, I remember they were talking about 300, but I'm not quite sure in the number now. But there is quite a lot of developers, yeah.

Robby Peralta 12:09

And just for context, what are they building? Why so many?

Knut Elde Johansen 12:11

Uh yeah, apps for financing, and uh they're building uh we have, of course, uh I would say we have two kinds of developers because we have uh more lightweight stuff that we did deploy on uh, for example, Storebrand. no, like small web apps and things like that. And then you have these big monolithic applications that is running the pension systems and everything, uh communicating to the data and everything.

Øyvind Bergerud 12:34

Yeah, we are developing uh a lot of software ourselves, but then of course we are dependent on off-the-shelf software for uh stock trading, and so we have a mixture of both a modern solution that we build ourselves, but then also an on-prem environment which is shifted left to to cloud as servers. So we have a mix of Kubernetes and servers. So for security, we have to take care of all of that, both modern stuff and then a bit legacy stuff. But we are on a journey of modernizing everything. I think that's our next cloud migration, or it will not be a huge migration as in the past, but uh gradually moving over to modern way of delivering software.

Robby Peralta 13:21

Let's go to developers. I just had a podcast with Finn. Mulighens Marked. Yeah, right. So I was wondering after that episode what what is actually teaching developers security look like? Do you have like a monthly sort of lunch and learn where you you know take some more stories, or like how'd that journey look?

Øyvind Bergerud 13:41

So we have tried different forms of security champion community. We started out with uh meetings, I think, every month. Uh we didn't get like the interaction, and we have distributed teams. So uh instead we uh transform into a smaller group. So we have one security champion or we call it security manager per division, which has maybe 50-60 developers uh in their division. Uh we have meetings every 14 day, and then we are talking about policy and how should we improve our security baseline? What can we agree on on secure development lifecycle across our company? Uh and then against the developers, we have a two-day workshop where we are learning developers about burp and hacking themselves, and uh they do that for two full days. So we have managed to take all developers in Stoibrun out of their daily task and uh train them. So we're going on a physical roadshow. Basically, doing fun stuff helps. Doing fun stuff helps. Uh we are doing like hack along, so our trainer is not prepared for the task. So the developers need to help him when he's on stage, and we get quite good interaction, and we get very different solution than we are expecting. Because programmers think JavaScript, we think scripts, and suddenly there's a huge JavaScript that's all the same task as we had a curl command to do, but uh sometimes they're doing it better than us. They'll remember that one.

Knut Elde Johansen 15:28

But yeah, no, but again, it's interaction, right? The instead of just uh sitting people down, talking to them, do this, do that, and so on. But uh at the end of the day, it's probably for harder hard to understand for you that that wouldn't work. Uh, and historically we see that CTFs, I think, was what the first things we started creating things that they could hack on web pages and things like that, and that always engages. And then you have like conversations with people three months after. So yeah, absolutely, and that uh gaming platform we have for call uh for security uh training for developers is also a good thing, I think.

Øyvind Bergerud 16:03

Yeah. And what we are focusing on this year is uh threat modeling, and so we do that before we start the development process, and uh at the same time we are doing what we call a smoke test on application, and then we get very nice interaction with the developers because we are uh early in the process and they have all the codes in their head, and so it's very easy to mitigate what we are finding compared to when we are doing penetration testing at the end of the project that we used to do. Um then they were kind of finished and already moved on to the next thing. So shifting security left with the threat modeling and easy or lightweight penetration tests.

Robby Peralta 16:48

Can you can you say a little bit more about that? Uh, the threat modeling and the smokescreen you said?

Øyvind Bergerud 16:53

Yeah, so threat modeling, what we mean is basically sketching out data flow and thinking like an attacker. And so it's visualizing the threats what we are building, and then that makes also the developers more aware of what can go wrong with what they're making. So, especially with AI, we didn't know a lot from security. How should we test it? What is the risk? And sitting together and drawing on the board, and then later doing a test. Uh then we have learned a lot on what the new type of vulnerabilities might be.

Knut Elde Johansen 17:28

Yeah, I think so. And that's another example of the learning going both ways because they we instead of being very technical, we we go high level and we say, okay, but what's the risk here? They think really you tell me instead of I come and tell you. And okay, maybe if someone gets access there, and okay, let's play talk about that for a while, and then after all, it's them defining all the issues and and they're also uh coming up with solutions for it and and uh getting validated on that. Uh, and and that's a very good way to democratize security, I think, because then everybody, no matter your background, you know, okay, I have a database with sensitive data. I know that if somebody gets to that, that's an issue. Everybody can model like that, right? So you can bring in business people and and everyone. So it's uh it's proven successful in many layers, I think.

Øyvind Bergerud 18:17

Yeah, no, I think we will do more threat modeling also on our third-party vendors because it's hard to see uh what is the risk of integrating a third party into your environment, and especially in incident response. It's good to have a threat model where you can see this is the service we need to shut down now. This is the value we have and need to protect.

Robby Peralta 18:42

So you're like the episode I had yesterday, it was with solar winds. They're seeing talking about like if we landed on that box that the solar winds was hosted on, you know, what happens then, and then how do you but okay? So, one of the outputs from that threat modeling, I would assume, is to actually write like detections or policy as a code that would detect things. Or what was like some of the outputs of that?

Knut Elde Johansen 19:02

That varies a lot, I would say. You see, okay, here is access to the this database is the most critical issue that we can think of. Okay, how is the authentication here? Do we need another authentication layer, or or what did that look like, and so on? So it kind of depends on who you're talking with and how technically deep you're going in the solution. Uh, but I think the the common understanding of what the actual risk is and be and agreeing on that has a lot of value in that process.

Øyvind Bergerud 19:30

But we also detect when we're doing the actual test, that's more like a purple team type of test, and then we see if there are gaps in the detection. And sometimes we uh lack logs from application teams, and then the security team are cannot see it, and then we try to implement the measures against that.

Robby Peralta 19:53

So uh we'll go there now. Um, purple teaming. I heard that's something that you guys are are doing on your own.

Knut Elde Johansen 19:58

Uh yeah, yeah.

Robby Peralta 20:00

Tell us about that journey.

Knut Elde Johansen 20:01

I think it's uh it's been a very interesting way to go. Uh, we're organized uh in two security departments, so Sleag's team is more of the uh risk-oriented in the CRO uh part of the organization, while we're in the tech tech part. And as such, it could be a bit of divide, and and he also has the red team because they're an independent testing function, right? But then we got together again and they can do testing, and we see what we see, and they uh give us some input and and we learn a lot from each other that way, and and define how we should find things instead of uh asking and and just looking at uh each other from distance. And I think it's a very good team effort because you kind of sit together as a blue team and a red team, but then you get together as the purple team at the end, and usually it can be a bit of a uh competition between the red and blue, but kind of switching that to working together makes us so much more powerful. And they okay, I see the detection works now, but tune it a little bit like that and that, and you'll take 10% more right off the bat. And ah, okay, great. We would never thought about that ourselves. And the other way, they oh, you're actually seeing that, okay. Then I have to switch something here and let's see again. And then you really emphasize what the red team is really about because the only function the red team has is to improve the blue team. That is why they're there, and and but in real life it tends to get like uh you say, Even that is more a computation. Ah, did you catch us? No, you didn't agree at one point for us. Uh, but instead, we now okay, do this, and now next time you'll see it right away. Okay, good. Now actually blue team are improving. It wasn't one or the other winning

Øyvind Bergerud 21:36

because that doesn't b because in the past uh there was uh huge discussion around is this really a finding could this really happen? But when they're in a purple team mode, then you don't talk about that. The only intention of the test is to improve uh detection. So it gives better value for us.

Robby Peralta 21:55

How do you go about um I guess that kind of goes along to threat modeling? How do you figure out those like scenarios?

Knut Elde Johansen 22:01

We have a separate threat intel function within uh security operations to help us. What should we look at now? Who is the most relevant actor? Is there techniques that we should be aware of? What do we need to prepare for right now? So that's kind of main input I would say.

Øyvind Bergerud 22:14

Because that is the goal for the purple team to emulate the threat actor that is targeting the financial sector in the Nordics. So we pick uh one of those threat actors and then we simulate the techniques that they're using.

Robby Peralta 22:29

Yeah. And now that we're there, do you do you have any like trends that you want to highlight that you've seen that are interesting developments in that space for TI towards your sector?

Knut Elde Johansen 22:36

I think we see that the shift in attackers' way of thinking and working. Now they are increasingly becoming more cloud conscious instead of just landing on a box and jumping around like you do on a network. Is it cloud? Is it on-prem? I don't care. Now they are going for the management plane and getting access to the managed plane. They can pivot to the data plane and they're kind of they are becoming cloud native. And that's something that we really need to prepare for and work uh hard towards.

Øyvind Bergerud 23:03

Yeah, and I think that is the key word prepare for because that's what we are focusing on being more proactive. So both in the security controls we have, we have a zero trust architecture, so we have micro-segmented our workloads. But for the SecOps team, we are working more on finding the actors before things happen instead of waiting for an alert. Because that's what we see. When we took over the responsibility for monitoring, we had a lot of alerts all the time, so we needed a way to prioritize it. So that's why we're using threat intel, focusing on certain threat actors, and then now we're doing threat hunting for those actors every week. So we have a continuous process all the time to look for threat actively instead of alerts popping up and trying to uh close them down.

Knut Elde Johansen 23:55

Threat Intel is a vital part of that, of course.

Robby Peralta 23:58

So there's a lot to unpack right there. Uh I'll start with the the first thing you wrote down the the cloud native and preparing for the bad guys to be cloud native. What does that look like from a security monitoring perspective?

Knut Elde Johansen 24:10

For example, at the beginning of the year, there was a lot of talk about primary refresh tokens and tokens being stolen and bypassing a lot of protections like MFA and so on. And then now the trend has shifted a bit. But it's important to kind of understand what they are doing, what kind of techniques. And the cloud is the one way I would say it's rather new is the way that it focuses mainly on identity as the protection barrier or mechanisms to defend. And as you like to say, OVAS Top 10 in number one is still broken authentication, and it also kind of means that you're always one authentication bypass away from full compromise. When you have layers, there is something else. But I do see that now the cloud vendors as well are getting to that point. So two, three years ago, you would see them mainly say that expose what you can expose. If you have some practical benefit of that, then just put it out there, we protect you. But now they say expose what you need to expose, and to have like this edge access solutions and everything, because maybe exposing everything all the time isn't that good of an idea, anyway. So we see kind of the network controls are coming back with the decryption and all those things that five years ago people would look at you and say, No, no, this is over, you stop talking about that. But but I do strongly believe that the defensing layers is still really important, and we need to keep focus on that.

Øyvind Bergerud 25:36

Yeah, because we are kind of seeing what we saw in the past be in the lateral movement was you get access to the network, and then we have a very flat network, and we have been working for several years segmenting in DMC, and now we have a segmented micro-segmented, so one application cannot talk to other application unless we permit it. But at the same time, we see that you can laterally move with identity. So if you gain uh access to a global administrator in cloud environments, you can basically do anything you want. You can delete workloads, uh, possibly you can delete backups. So we need to think in a new way uh how we are protecting the environment. And maybe we'll talk about segmenting identity in the in the future.

Knut Elde Johansen 26:25

And yeah, yeah, because now suddenly you see cases of threat actors becoming global admins and then throwing everyone out, and you're outside your own castle, so to say. And that wasn't a possibility on on-prem. There was always some guy you could call and he could pull the plug or whatever. But now you see actually, and if that were to happen with us, then we were at a business, right? We don't have any infrastructure at all. If somebody has it, they can just name their price because uh the option isn't there. So, yeah, that's scenarios that's a bit scary. But that's also something we're working with the vendors and others to solve.

Øyvind Bergerud 27:00

And that's what we have been focusing on the last half year also. We have uh built a management plane which is totally outside our operating uh plane, and we are using privileged access workstation that can manage our cloud environment, so we are not that vulnerable to token theft because there is no attack path. And then we are talking about can we do the same as we did in the past? We could take out the network cable and take us offline, but with the privileged access workstation and the management plane, we can probably do that again. So the tier zero access to management doesn't exist where the attacker can have a foothold. So we are thinking in the same principle as we did in the past, but it has a new cloud flavor to it.

Robby Peralta 27:49

And all these things were like identified through like threat modeling and just like thinking together like what's the worst thing that could happen. And you just built these scenarios over time.

Knut Elde Johansen 27:57

Yeah, uh, and some penetration testing and so on. Uh, the that exact scenario was actually as an external pen tester who came in with a very deep cloud knowledge, and he just became cloud admin in a few days, a couple of times in a row. And and our board just couldn't have that risk. Somebody can just take over. That can't happen. You have to uh get some options here because we cannot live with that.

Robby Peralta 28:20

How often did these like at you mentioned something about tokens? Uh how often do those threats actually change? Is it like a six-month basis? Is it a 12-month basis? Is it like monthly?

Knut Elde Johansen 28:30

Maybe three, four times a year or something, two, three times to see a shift in trends. But again, it's uh no year is alike. So yeah, that's the

Robby Peralta 28:40

kind of reminds me of uh you don't have to be the fastest, you have to run faster than everybody else. Yeah.

Øyvind Bergerud 28:45

We are now quite secure with our cloud journey, but our partners who is their security posture, and that is something coming up with Dora. So now we need to also be in control of the security posture of our uh subcontractors. So we need to closely pay attention there.

Robby Peralta 29:04

I um wanted to talk to you guys about the concept of CNAPP, cloud native application protection platform. Uh how's that differ from SIEM? Or CWPP uh or uh the other acronyms explain that explain the acronyms for me.

Knut Elde Johansen 29:22

Yeah, I think it's kind of hard myself because they are so blending into each other so much. At the core, it's a lot about vulnerability management, really. It's about touches not being applied, and it's about configurations not being secure. That's the the main things. If it's like in a container, if it's in the identity stack or in a classical Windows VM, is still what you're working on. It is those vulnerabilities you have to remediate and prioritize them and then uh monitor if somebody tries to exploit the kind of the different parts of the puzzle.

Robby Peralta 29:55

And uh yeah, how is that for you guys?

Øyvind Bergerud 29:57

I think the visibility that we gain from a CNAPP platform is quite unique because we are now cloud native and we focus on Azure and GCP, but we also have uh workload in Amazon and we have it in Lin Node, and but when you're a quite large organization, Shadow IT uh kind of makes that happen. And then it's good visibility and then get priority on attack paths and where we should focus our security posture. And it might be outside your main focus, uh and that's where you need visibility. At the same time, we talked about democratization of security. We as a security team we are unable to patch everything, we are unable to run around and tell people to patch everything. So, what you're building is a dashboard for each department, and uh so they are responsible for their own security posture. And we are also putting the responsibility on the management level three, so they need the tools to see what they're responsible for, and that's where I see CNAPP gives us a lot better visibility, both for us as a central security team, but also for managers that are responsible for risk. And in the past, they might not know that um something was unpatched and end of life, and the classic hygiene still applies, even though if you're in cloud.

Knut Elde Johansen 31:24

Oh, yeah, absolutely. And I think CNAPP plays a crucial role in what you say with the cross-cloud issues, right? Because you have an exposed VM in this cloud here, and then suddenly it has a secret, but it's a secret to a super sensitive service in that cloud. But the guy who's running things over here doesn't know about that cloud and what's the criticality there. So being able to see those correlations across clouds is really important. And also, issues and configurations are changing so quickly in cloud. So, one thing that was designed securely one week, then they released a new functionality or they changed something and it wasn't secure anymore. And it's almost impossible to be on top of that all the time, right? Both for us and for the developers, and things are changing. So we see very capable developers doing things that are just because they weren't aware, and then being getting it to flag, then you can see it right away. And you can use it many ways, right? Because you can, for example, if you have something you want to deploy, you can just deploy it in test, and then you see an app the next day. We see is there issues here, or can you just go to production with this? Yeah, this is okay, or maybe step up here and there. So that's really key, and also the way of prioritizing what you're going to do based on how business critical or how exposed, and so on. Because I mean, even in a relatively new cloud environment, we got uh tens of thousands, if not hundreds of thousands of vulnerabilities. It's not feasible to fix that, and no matter if we had that like a three-year project, we still wouldn't fix it. So we need to prioritize and figure out where we should put our energy and and what risks we can accept. And and that also creates a better environment because then you say to okay, the application team A, for example, you have these uh 5,000 vulnerabilities. But if you focus on fixing these 10 this week, let's talk again in three weeks and see how this will look now. Then you're actually giving them the feeling of doing something because now you took the 10 top 10 issues instead of 10 of a list of 10,000. It doesn't feel like I did anything. And the guys coming back next week and saying now you got a thousand more. So then it's kind of a not a good environment to work in.

Øyvind Bergerud 33:36

And and we really need to prioritize, and that's what the Synaptool is uh helping you doing. And uh we talked about micro-segmenting uh the infrastructure, but if there are secrets in your code or cloud keys, it doesn't really matter because then the attacker can circumvent it. So we needed to do a cleanup last year, so now we hope we are stable, but but you really need to focus on the small thing that really matters, and then you need a tool that can help you prioritize it. And then in addition to uh uh to those tools, I probably think you need uh to have uh scanners that are fit for your own environment, so we still need that also today. Yeah, and hopefully, we get better support in the tools that we can integrate with it and send our findings to central tools, which gives us visibility, and we can give that visibility to developer teams, we can give it to managers, and we can give you a dashboard for security. So I think the more look at vulnerabilities to put more light on it, then we can make it go away.

Knut Elde Johansen 34:44

Yeah, I think that's that's key. Give people visibility so they actually can see and prioritize, and then also give them some context and understanding so you empower them to do stuff instead of shaking your head or more of the old approach, maybe. Then you you instantly feel that you get a so much better uh uh temperature and the the climate is nice, and everybody's kind of uh happy to see each other. You you feel you pull the same direction, and and that's key, I think. Um because otherwise we would just be running around with a stick and we would be in a bad mood most of the time, uh I guess. Yeah.

Robby Peralta 35:19

Strikes me that you have everything as you could possibly ask for. Whatever you ask for, you've gotten it. What is missing? Is there anything missing? Like what do you wish that was there that's not there?

Knut Elde Johansen 35:29

If there is one thing, I I I'm more thinking of iterations and expansion more than this one key technology or one feature that we should have. We could always have more of everything, I guess. In tweaking mode.

Øyvind Bergerud 35:43

Yeah, I think uh we have been talking about protect your crown jewels for quite some time in security, and uh I still think we uh miss a business context in our tool. We have been working with our CNAPP provider to import uh criticality of uh of our asset and uh rate vulnerabilities higher if they are affecting a critical system compared to a low critical system. But I but I think that is in general in the whole security industry that uh we as a customer of an MSSP or a cloud provider, we need to be better at telling them what is important for us. So we put the protection in the in the correct place.

Knut Elde Johansen 36:26

I think that's a very good point. Uh the the built-in uh like uh support for ground jewels definitions, if that was there from the start, that would uh make an improvement, absolutely. I think there is some vendor as some, some has nothing, some has a lot, but there isn't a kind of a core function, and I think it should be. Uh absolutely

Robby Peralta 36:47

interesting. So uh I always save the AI question for last. You guys did some red teaming around LLMs. How is AI how is the stated AI and uh or yeah, machine learning in Storebrand?

Øyvind Bergerud 36:59

I'm not sure if it's a fun story, but we as an insurance company have been working for LLM models for quite some time. So chat GPT is just an evolution of what we have been doing for uh probably decades. No way, because that's how you predict natural disaster, and we have a lot of scientists doing doing that for us. But we have embraced the AI, uh Chat GPT uh in our organization, and we think uh yes, there is a security risk of overexposing data to AI, but there is also a risk of not using AI. So we are experimenting on AI in many areas. For example, in my team, we are have a lot of questionnaires from Wenders asking about our security posture. So we are using LLM to answer uh questions on our security posture with chatbots. So I think that is one of the use cases where we succeed, and then we have had some trials with doing LLM models for security incident response, and we are not that happy. So I think it needs to mature, and as of now, it can give us help on some easy tasks, but the complex task, I still think we need human

Robby Peralta 38:12

language tasks, language tasks.

Knut Elde Johansen 38:14

Yeah, absolutely. And and I think Mikko Hyppönen touched on that on Sikkerhetsfestivalen as well last year. That yes, it has promised, but it's not quite there yet. And I think that's what we're seeing. Some very promising things that are very, very good, and a lot of things that aren't quite there yet. So it will be very cool to see in like three, four, five years, then it will really explode, I think, and that will be probably both fun and scary as tech here usually is.

Øyvind Bergerud 38:39

Yeah, but uh we have done some penetration testing on our own chatbots, and what we typically see is the traditional overexposing overlogging, so logging secrets, logging sensitive data, but the same focus we had with application security. We still need to apply for AI or LLM security.

Robby Peralta 39:04

Knut, Øyvind, I'm very, very, very glad that you guys are securing my pension.

Knut Elde Johansen 39:08

As glad as we hear, we will keep on making it safe, uh secure for you. Absolutely, really. Thanks for having us.

Robby Peralta 39:14

Thank you for having me in your lovely studio. I hope I'm invited back one day. Thank you.

Øyvind Bergerud 39:18

It's really nice to be with you.

Robby Peralta 39:20

Likewise. Well, that's all for today, folks. Thank you for tuning in to the mnemonic security podcast. If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcast at mnemonic.no. Thank you for listening, and we'll see you next time.