Michael Dahl

Hello, and welcome to this session, focused on the process of introducing and scaling the software security initiative within the world's largest furniture company, IKEA.

My name is Michael Dahl. I'm with Synopsys, and with me today I have Gustav Lundsgård, who is the IKEA Technology Capability Product Owner. Gustav is going to be sharing with us some very important insights from the journey that IKEA has ventured on, transforming from a traditional retail outlet to a digitally driven interior experience provider.

With that introduction, Gustav, please let us know a bit more about yourself and, more importantly, about the journey that you've been going through these past couple of years.

Gustav Lundsgård

Thank you very much, Michael. Very excited to be here to talk about software security and Cyber Jedis. Cyber Jedis is our security community of practice. I'm going to talk about the security context of IKEA and what IKEA and Ingka is, and how we have successfully created a security community of practice to defeat security challenges in our business.

I'm Gustav Lundsgård, a Technical Capability Product Owner in cybersecurity. I represent the software security team, which is one out of five pillars in cybersecurity at IKEA. I represent Ingka Group. Ingka is a part of the bigger IKEA brand. We are actually a franchisee that sells IKEA furniture, and we are the biggest franchisee of IKEA furniture, operating in over 30 countries. We are roughly 170,000 people, and we are mainly focused on retailing. We do not produce furniture; we sell it. Of course, the logistics behind it all are about shipping here and there, and shipping to our customers.

A few years ago, we transformed many things that we do. This is because of the biggest revolution since IKEA was founded, and IKEA is over 70 years old. I'm not talking about the pandemic we're in right now; I'm talking about the mobile phone and the behavioral change in retail shopping this has inferred. We need to change and reach and interact with our customers everywhere and in every channel, and this is usually what retailers try to do everywhere.

IKEA has traditionally been a big blue box on the outskirts of bigger cities where you go to buy furniture. But the regular customer today expects to buy stuff on their phone and get it delivered as cheap as possible to the door. We have, of course, seen these behaviors in our customers as well. We see that this is very different from market to market as well. In China, everything is through the phone, whereas in Germany, people still go to the store more than buying on the phone.

This is something that needed to change. Almost three years ago, we went out and said that we are creating a new IKEA in three years, bringing digital to the core of everything we do. This is the IKEA retail direction: changing not only how we sell furniture, but how we operate as an IT company. We went from being a traditional retailing company with, of course, an IT department, into becoming a digital company.

In the digital transformation that we did, we not only changed how we were set up, we also changed how we're producing our software. We went from being dependent on big software firms delivering big, complex, monolithic platforms to our infrastructure, to developing it ourselves. Of course, we're currently in a mix of both, right? But we are now hiring a lot of software developers and DevOps people, because the operational model that we have made for our software engineering teams is DevOps. DevOps means not a process of CI/CD, right? It means a culture that you as a team, you build it, you run it, you operate it, you deploy it. This requires a completely different company than something that only runs monolithic platforms in the data centers.

Michael Dahl

With that, obviously an enormous change. But changes start from the top, or do they? They also need to be filled out from the bottom.

Gustav Lundsgård

Exactly. Where is security going to go in this? Security traditionally is different from how we need to work with security in a DevOps team. We looked at some books and some metrics, like State of DevOps from Google and DORA, which talk about what is a successful DevOps transformation and how can we fit security into this.

I stole this quote: "Information security should be integrated into the entire software delivery life cycle." What we see is a shift to giving the developers the means to build security in. I think that we've all heard "shift security left" or "shift security everywhere," which has been maybe more recent years. What is that actually about? How do we empower the product teams to do this from day one, to really build security in? For us, that means something we call team-centric cybersecurity.

Team-centric cybersecurity means that if the product team develops it, deploys it, monitors it, and supports it, they are the best-equipped team to address the security of this product. They are the ones who know it inside and out. How come, then, that it doesn't work with the security engineer coming in for an assessment?

That is what I'm trying to visualize with this slide here: the product team is supported by a cyber engineer. We'll deep-dive into cyber engineers in just a minute. But both the cyber engineers and product teams enable the teams to work with security.

Traditionally we've seen, and we've done so ourselves as well at IKEA, that we come to do an assessment, like a pen test, and we give our team a report with: you need to fix X, Y, Z. We go back and whatever cadence you have for your test, you do an assessment again, and it's the same things that pop up. We've all seen that over and over again. We are not having the teams learning from the assessments that we're doing, and this needs to change. What we're trying to do now is have the security engineers empower the teams to work with security and make sure that when we find something, we address the root cause to it.

Michael Dahl

Sounds exciting.

Gustav Lundsgård

The question and the answer to what we were trying to do here, the Cyber Jedi or Security Champions program, there are many names for this, is that we created a set of objectives. This was over one and a half years ago when we created this guide and set out what we wanted to do. We wanted to make security scalable, because we can never scale the security engineers or pen tests or whatever assessment we're talking about as we can scale software development. We needed to increase the transparency of our offering, and this is something that we were wrong about. We learn as we're going, and that's what we're going to talk about here. We wanted to raise awareness, and we wanted to empower developers to address security.

Michael Dahl

How do you get these people onboarded and motivated to go with this? What kind of framework, what kind of structure do you build?

Gustav Lundsgård

As I was in a position to decide what it was going to look like together with my team, it was, of course, Star Wars. I am a Star Wars fan, and Star Wars is a theme I like. So: "Help me, Cyber Jedi. You're my only hope." This is a quote from the fourth episode of Star Wars, and if you haven't seen it, shame on you, but nice, now you get to see it for the first time again.

This tells us a message: if we're doing DevOps, if we're doing team-centric security, it is the Cyber Jedis within the teams that we need to train because they are our only hope.

Where did we start then? A little over a year ago, in March 2020, we created a pilot program. We had only seven engineers from, I think, six different teams that joined us because they wanted to learn more about security, and we wanted to try things out. We built out a few modules, like the SSDLC, Secure Software Development Lifecycle, secure coding, and web security.

After the pilot program, we changed a lot based on the feedback that we got. We made the modules too big and too complicated to understand. During the summer, after we had run the pilot program during the spring, we launched a new initiative. In fall 2020, September, we launched the new Cyber Jedi Academy with over 30 Jedis in one go.

There we went with self-led training, and we teamed up with the learning and development department at Ingka. They host our e-learning platform, and they work with upskilling of the whole company. They work with tools like Coursera and courses in anything, really, that helps us become better at what we do.

Self-led training, like the left-hand side of the picture here, shows a curriculum for the first level in the Cyber Jedi Academy. This enables the Cyber Jedis to do it at their own pace. The online learning system has things such as videos, links to documents and reading materials, surveys, forums, and assignments. This is something I want to stress: we made assignments to do in the context of their own team.

We did this together with four different levels. This is to increase a sense that you progress in your career as a Cyber Jedi. At the first level, The Saga Begins, you learn some basics: what is OWASP, what are different types of data, why do we classify data as privacy data and PII? At the Padawan level, you start applying what you've learned in your teams. This can be anything. One example of an assignment is that we ask them to look at the OWASP Cheat Sheets. People who have worked with application security know I love the OWASP Cheat Sheets. There are loads of information there and loads of things that they can read up on and apply in their teams. There are also some other activities that are more traditional security as well, such as SAST and SCA, and they start doing this in their teams.

At the Knight level, you lead your team through security activities that are more centered around the whole team, such as how do we work with threat modeling. This is really, really great when we have Cyber Jedis doing this. I love the fact that we actually have Cyber Jedis doing threat modeling on their own, because it all boils down to the teams themselves, without a security professional involved. We do support them in the background, but they have a team asking themselves what can possibly go wrong. That is, for me, what threat modeling is about. At the Master level, we only have one or two at the Master level, we hope that they will lead and inspire other teams to work with this.

Michael Dahl

The videos there that you showed look very professional. Is that something to do with Mr. Lucas himself, or is this made in-house?

Gustav Lundsgård

I wish, but some of the people that we have in the security team, and generally, maybe they should be hired by Mr. Lucas or Spielberg. It's not hard. It's just about being creative. Anyone with a reasonable mic and a webcam can start recording videos like we have used. We have videos from our privacy team, from our cloud security team, from the software security team, discussing principles and teaching our Jedis about things. It doesn't have to be a two-hour complex script with flashy effects. Two minutes talking about something that's important, trying to highlight important things. That's an excellent question, Michael.

Of course, we had the self-led training and these different levels, but it's hard to keep the engagement up. Together with this, we also had open sessions. Every week we have an hour where Cyber Jedis can come in and hang out, ask questions, and get help. Sometimes this just serves as a blocker for them to work on Cyber Jedi stuff. More and more lately, we've also had topics. We've had topics with Cyber Jedis presenting things they have done and challenges they have seen in security that others can work with and help with.

One example is a team that developed a nice way to decorate their pull request in GitHub with SAST results and whether or not they should go live with or merge this pull request. They came and presented that: "We used our SAST tool like this." Other teams get inspired and they see, okay, they did it like that; we also want to do it like that. The open sessions are great in that regard.

Michael Dahl

Just to understand, the open sessions also, in which channels were they conveyed? I guess people are not seeing each other face-to-face these days, so how did you do that?

Gustav Lundsgård

The idea was, of course, to have this physically from the beginning, but I think that we overcame it and it became easier to do this due to the pandemic, to be honest. We can have an hour slot in the week in Teams that anybody can jump into and listen and learn something about. We have this every week, where we sometimes invite people from various organizations, or we have a Cyber Jedi present something. Spreading and sharing the burden of this is important.

That's what we did, and that's what we have done in the past year.

How did it go, and did we really hit the target? What we learned is that at the start, specifically in the pilot program, we learned as much as the Jedis because we had a massive SSDLC with a lot of activities that we wanted them to partake in. But we didn't understand how difficult it was from team to team, with different contexts and different techniques, to implement the things that we had in the SSDLC. Our secure software development lifecycle, the SSDLC, isn't anything very fancy or particular compared with many other companies' SSDLC. We're talking about code scanning, dependency analysis, cloud config monitoring, logging monitoring. That's not what we're going to talk about here.

What we also learned is that time commitment was hard to get from product owners and engineering management because they didn't understand why they would give up a person in their team 20% of the time, because that's what we asked for: 20% of the time. They didn't understand why they would lose feature development or tech debt development to focus this much on security.

We also found that the feedback from the Jedis was really valuable, not only for the SSDLC, but for anything really that has to do with security. We take feedback from security into so many processes today: how we think and work about risk management, vulnerability management, privacy, cloud, configuration management, incident response, and responsible disclosure. Everybody wants to join the Jedi Academy and get their feedback.

The last point here, what we learned, is also connected to the time commitment. We need to spend the Cyber Jedis' time wisely, and the activities must make sense and make the product better. If it doesn't, and the engineering manager and product owners don't see the benefit of this, they only see a person educating himself. It doesn't give the team any value. That is something that we need to think about carefully.

Michael Dahl

Let's talk maybe, Gustav, just the reflection on the recruitment of the Cyber Jedis. Was there a CV list that you had to check off and say, "You can be a Cyber Jedi," or how did that process go?

Gustav Lundsgård

Currently, anybody that's an employee within Ingka can become a Cyber Jedi. That's really important, that we don't want to close the door on anyone wanting to pursue this. It's a really good thing when people come and say, "I want to become a Jedi." We need to entertain the people who express their own interest. If they want to take the step themselves, that is the perfect candidate. We, of course, have a mix of both self-nominated people and people that come from being endorsed by their manager or being, forced is the wrong word perhaps, but pushed from the managers.

So what went well? We learned a lot of things, but we had some highlights that I really want to talk about that make the Jedi Academy worth all the effort that we've put into it.

We created a helpful community. Communities, according to the State of DevOps and digital transformations, or in DevOps transformation, are the most important thing to succeed instead of a center of excellence. In a community, you will help, and you will see other people who have the same challenge as you and who have solved it, and that inspires.

In the community, learning goes both ways. The Jedis understand and feel like, "I can actually feed back what works and what doesn't work in this big enterprise." It helps shape the future of how we're going to do assurance, how we're going to do security. That makes them engaged, and that makes them feel special. We support the Jedis not only with, "Now we're going to do threat modeling, and now we're going to do SAST." We also support them with discussion in their teams and giving them the ammunition of why this is so important. That is my bold text here: believing in the mission, the why.

This is something we speak very much about in the academy. Why are we doing this? Why are we spending our effort on security? For me and for many others at IKEA, it's about what type of company are we, what type of software are we trying to produce? IKEA has a clear vision. We want to create a better everyday life for the many people. We want to be people and planet positive. We want to be sustainable. Maybe not most importantly, but I love this saying: we want to show that it is good business to do good business. If that is something that we want to strive for and that people believe in, we must have secure and high-quality software. If we have secure and high-quality software, the digital experience and all of these things are also benefited from this. The why and the engagement are really important to come across with.

What went well as well, and this is also a drawback that I'm going to talk about in a minute, is that we see that the teams with a Cyber Jedi are more successful in their security activities because they believe in it and they understand it.

Michael Dahl

I think this is a very valuable comment here, Gustav, because exactly as you say, if you look at your webpage, if you go even and read a bit more in depth on your annual reports that you publish, it's a really very clearly stated announcement saying that you want to make or make a contribution to a better world. I'm really happy to hear that this is also reflecting that and part of that. So it all comes to a bigger unity, right?

Gustav Lundsgård

It's a part of who we are and what we do as a company. Security in a DevOps world needs to be something that you do. It's not something that comes at the end of a life cycle that we traditionally see. In an SSDLC, you end in a testing phase, and then you test the hell out of your application, and then you maybe have something that you need to change. We want the teams to do security as well as they do Jira planning. It's a part of everything they do. We can talk for two hours on our threat modeling approach; that would be another talk, I hope, at a point in time. But yes, that is really important.

So, the drawbacks. There is bad news. If you haven't fallen asleep yet, here comes some interesting stuff. We have no good baseline to measure from. We have made a huge digital transformation as a company. As an effect of that, we don't really know where the teams started, and we don't really know their security status from the start. That means that it's hard for us to measure the positive impact of the Jedis. We do see some things, of course, that we do know that the Jedis really are contributing to security and increasing the quality of our software.

Another drawback is that there's a lot of expectation on the Jedi, specifically now, when we have proven that the academy is something that people want to be in and people want to learn more about. We see that other security engineers in cybersecurity and engineering managers put so much pressure on the Cyber Jedi that he needs to solve it. That's something that we always have to manage: manage the expectation that the Jedi is there to facilitate. If we think about the slide I showed a while back on team-centric security, where the Cyber Jedi is surrounding the team, it's the product team themselves that must do the security work.

It also comes with a high cost. It is time-consuming, both from internals and consultants that spent building modules and doing this every week. We're also having some software engineers, and maybe not only software engineers but other engineers in the company, where we're giving them assignments where it does not potentially reduce risk. That's really what we want to do when we talk about security. So there are some drawbacks.

Michael Dahl

Gustav, I need to ask you also, when you talk about the resource and time consumption allocated here, this obviously reflects the extent of the transformation. Some companies do possibly a smaller kind of transformation, and some other companies, like IKEA, have done a massive transformation. I guess always for a project like this, the magnitude of it is reflected in what you need to add to it.

Gustav Lundsgård

Exactly. I think everybody needs a Cyber Jedi Academy because you can put in what's important for you and make sure that the effort and the assignments that you give them are valuable. It doesn't need to be security, for that matter. You can do this around a lot of things. There was a discussion today on how we're going to do IT recoverability and backups, and the Cyber Jedi Academy is likely going to teach some things about this as well. I think that's a good question.

So, what should you do? What are my tips for you to create your own Cyber Jedi Academy? Start with an MVP program, and I think this relates to Michael's question as well, which is really good. Is it only for big software companies to do this? No. Do an MVP program and improve on feedback. What is it that you want to drive? What is the behavior and culture you want to foster in your company?

In this, make sure that you spend the developers' time wisely so that it reaches the objectives that you're trying to do. It may be compliance, it may be reducing risk or privacy or whatever you want to call it. All things they do must help their product. If it helps their product, the Cyber Jedi will get support, both from the engineering managers, the product owner, and from the teams themselves, because they see they become better as a team by the assignments and activities that we send out the Jedis to do.

This is also a great example that the Jedi comes out and implements something in the team or helps the teams implement something. That is learning by doing. In my book, that is by far the best way to learn. You need to do it to learn it. That's really what I want to stress with this.

So, the future. Are we done? Is the Cyber Jedi Academy done at IKEA? Absolutely not. We haven't even had a full rollout. It was less than a year ago that we created the bigger rollout. What we need to focus on right now is making paths for other roles than software engineers and DevOps engineers. We're a big company. We buy a lot of software. We integrate a lot of software. We have a whole data analytics department with hundreds of people. We need to make paths for them as well and make sure that the things that they do are relevant. One example of this that we've failed with, or not failed but there was a rollback, is that we had a few platform engineers as Cyber Jedis, and when they got an assignment to integrate SAST in the CI/CD, there was nothing for them to do. That is a waste of time, and they cannot do it.

We want to increase the frequency of onboarding, because at the pace we have now, we have approximately 70 Cyber Jedis right now. It's hard when we have more and more Jedis picking up pace, and we've really created this rolling snowball right now, where we want to have a frequency of onboarding where they can onboard at any given time and still feel committed and still feel the engagement from us that we're happy that they have joined.

We need to make the different terms clearer, and this is also related to increasing the communication toward managers on the commitment and personal development that it actually is to go from The Saga Begins to a Knight and a Master level. This is a transformation and a journey not only for the product team, but for the person. The end goal of all of this, and I'm sure we'll maybe never reach it to 100%, is that I want to have one Jedi in each team.

Michael Dahl

There we have it, Gustav. That sounds like the project achieved. Thank you so much for your very, very valuable input here. It's really great to listen to this journey that you've been going through, sharing the tips with us. Really appreciate it. Thank you so much, Gustav.

Gustav Lundsgård

Thank you very much, Michael, and thanks for everyone listening. I'd just like to put in a small story as well on that: this is far from my doing. I have a whole team of really awesome people behind me. Jennifer, Björn, Philip, Rajiv, and Emil, everybody at home, big thanks to you as well. Thanks for listening.

Michael Dahl

Great stuff. Thanks.