Security + Devops + Ambidexteriety = Fun (Europe 2021)

Visma embedded security into their DevOps transition from early on. This has led to advances in both fields that makes words like DevSecOps, SecDevOps redundant. DevOps seasoned with security is natural, fun and really empowering for the DevOps teams. Espen shares the Visma story in a fun and engaging way for those that want to avoid security becoming a delay in DevOps and rather control it from the Developers perspective and accelerate development.


Espen Agnalt Johansen

Security Director, Visma



Hi everybody. I'm S I'm the father of three daughters. I'm married to three-month. I have a dog and a cat, but most of all, I love security. Um, I love security and I spend most of my professional life doing security in some sense, from both work in the armed forces. When I was younger, man working for United nations to working as a manager and operator in many companies, I've also worked as an undercover cyber operator for clients for many years. The main job was to infiltrate criminal environments and learn how they worked. I figured out how my client's IP was abused by them, but I also am in my midlife crisis and that I take great pride in, um, and this one is about sailing and I'm completely immersed in that point. The pictures on my wall depicting sailboats, uh, I dream about long cruises to faraway shores.


Uh, but mostly I actually spend time on, on YouTube learning about sailing and also buying the cool stuff that goes with this particular midlife crisis. Um, and I recommend all of you to have a couple of them. They are really fun, um, declared them out loudly. And since this creates the opportunity to do something really fun and people accept this recklessness. So back to security again. So I've learned over the years to respect many different trades, and I've also learned to be curious about people and how each and every one can contribute to delivering top notch security in their services. So in this talk, I will try to make our research more available and I will try to make it easy going, uh, for those who really want depth, uh, you should read the research is well published. I of course would love if any of you take the time to read and comment on some of the publications that we have made, uh, in this talk, my focus will be on security DevOps, and ambidexterity combined.


Uh, I will also share how we have experimented with using ambidexterity as a method to merge these into a more potent tool for, for the self-managed teams, some developers and operations, people view security, people like this. And we also see that the people like this classical security cards sometimes want to subsume, uh, others in their own paradigm. Uh, these people are often seen yelling things like ISO 27,001 or similar words while some security and operations people view developers like this, like kids, but a keyboard and little impulse control. And they also want to subsume others in their own paradigm. They're often seen yelling words like dev ops, agile and JIRA, and even confluence sometimes. And some security and developments. People can view operations. People like this kind of suppressed, rather skilled and have a need to subsume others in their own paradigm. These are often seen yelling birds like ITIL network backup and service desk, but I've learned over the years that everybody just want to be a ninja.


So this is what all three characters in this narrative agree home. Um, and, um, but can we really become Linda's? Um, I've also done lots of martial arts in my life and all that to become really good at that stuff. You have to do that and not anything else for a very long time to become really, really good, but all of us have to agree that you are involved in the same circle of life as depicted here. And therefore might argue that they're all the same. So why did this need this? But emphasis on the differences pressured, look at the similarities and find ways of breaking down the walls and acting together our practices and experiments suggest that if we speak the same language, if we work together, we can accomplish a hell of a lot more than if we fight and focus on the differences between us.


So in the, um, in the DevOps, um, uh, infinity model, uh, all three competencies are, I came to moment. Um, and also we have to, to, to agree that we're all just humans, even though if you, um, take on the form of a developer or a security person or an operations person, we're all just people. We have slightly different views separately from isn't working, but all of us have different competencies. And these are complimentary that's at least what our research suggest. Um, so one thing that's in common, that's real are humans and humans as a species are territorial. So, and since we're also an apex predator, uh, we only have to fear ourself. So with that in mind, so we are territorial. We do have, um, different opinions. Uh, we are quite good at what we do all of us. So why couldn't we be more like caucus?


So quokkas other, world's happiest animals. They live in Australia where basically everything wants to kill you. Um, but, uh, yeah, a Qualcomm would probably hurt you, but he can't because it's quite small, then it's nice. Isn't it? It's lovely looking greeter. They don't territorial and they're happy to share space, even food and shelter. So despite being hunted by predators, like we are hunted by hackers. Aren't, we, they have a chill view of life and are happy to share both information and then everything else. So let's be more like, walk us. So with that in mind, I'll bring you through the, the outcome of the, of the research that we have done. So for, for people in this mode, this is a mantra for management to reflect. If you have empowered your people, um, are they enabled and have you embedded and ensured that you above, um, the small cutout, then the bottom of the screen is a part of our security strategy for the company where we try to exemplify this, but I'm an external, it can be a bit confusing in the beginning.


Let's just take you back to the roots of what ambidexterity is because dev ops is of course, a word here that everybody understand that ambidexterity might be new for some. So I'm gonna extend it. He in itself is the ability to use both the right and left hand equally well or left right equally well, so let's do a small exercise together. So now have both your eyes open, extend your right arm and pointed to the word equally, okay. Now, close your left eye, open it again, close your right eye and open it again. So most of you will experience that one eye is better at aiming than the other is Fastly. Majority of people have either the right or the left eye as their dominant eye. So in the shooting circles where people had actually done this for fun, this is known as the dominant eye.


So even inside your brain, you have dominates dominance issues. Let's do the second exercise. This is quite funny. Now put both hands in front of your face, let your index fingers point at each other. Now rotate the right hand forward while the left remains still stop the right hand, rotate your left hand backwards by the right hand, remain steady, okay? All got this right? And now stop the left hand. Now you take the right hand forward and the left hand backwards at the same time, come on, you start. And we stop now the left hand forward and the right hand backward at the same time stop. Most of you will realize that this was difficult. Some of you are really natural at this, but move are find this to quite be quite difficult. Uh, and even your body does not interior intuitively uh, work with you.


So even inside your own body, you have dominance. This is still true, but there is hope you can train yourself to become better. And if you want to, um, our way is to use a diverse group of people and make sure they are empowered and accepting that one company is you cannot always rule the others. There is, there is room for all. If you make some adjustments, I, myself, I chose to share leadership, or I choose to share leadership with people that are my complete opposites and the respect, their opinions. And I learned from them and I've accepted that they should not subsume others in my own paradigm.


So when it comes to security, uh, organizations, uh, usually are focusing on applying to top down approach. Um, I'm also inclined to do that, as I mentioned earlier, I'm ex-military, uh, and I'm an extra governance model can be adapted from the healthcare industry, uh, which combines a top down approach by establishing protocols and penalties like status setting, monitoring, and accountability, and the two bottom opera approach by helping the teams to become better in doing security activities, which basically is training and stimulating interventions and stuff like this. This approach basically assumes that the teams are self-managed agile teams that need leadership on security, but must retain the continuity and self-management of their software development, um, and try and get a patient implant, dental software security practices, enabling and empowering software development teams to adapt and add to overload mandates and embedding cultures of improvements. So when I back in a bit that let's go into insuring, which is the first of them, this is about at a patient of evidence-based best practices.


So for us, uh, if we're gonna look at the theory behind there's a top down role in the program, it's just focusing on creating an overall strategy and embracing the performance and process standards and the finding the roles and the responsibilities. So this is where we make sure that security requirements are based on a combination of personal needs, best practices in compliance with privacy laws and regulations, for instance, uh, it's also mandates for me, uh, as a leader to create a financial platform, put later activities and thrive. So given the main three characters of this narrative around what the police guy, the kind of kid with the keyboard and the flaky operations guy, uh, this is also an activity where you form me from a top-down perspective, decided to break up silos and put these two competencies together in the same reporting shape. Well, count breakfast doesn't have to work for everybody or experience at least show clear indications that this works best when they share goals.


And they haven't. And it's an easy approach to, to move them into the same team, this force a common goal, but it might not suit all of you. Um, so the quadrant to identify as basically a preparation oriented capacity building role for an organization is to enable and pleased to engage in bottom up improvement activities, including adapting activities. So the focus is on education and training enables action on the best of performance information, although potentially come through to do it for a bottom approach to need to spread improvement capacity across the system means that there's centralized provision of change resources and training as well. I've met press to spread learning. It's appropriate importantly like the production of information, uh, from, from other researchers to just the education and training compliment or the regulatory instruments. So in very short, give something, give someone the means to do something.


So when I translate this into a very simplified context, it's using a bottom up approach that focuses on persuasion, education, and training. Okay, this is the key of this one. So when I take this into the technical context, so we started quite early, the static analysis is that an analysis is a very exercise. So for me as a traditional military officer, I thought, okay, let's implement sauced and let's turn on all the compliance elements in it. And let's break build if there exists any kind of, um, um, poor version of encryption present in the code. Well, that doesn't work. It really doesn't work. So I had to re, or we had to reimagine this and we thought more of, of soft as a training tool. And when we start to see as training, then it became really good. So we learned from experience to show that dev ops teams, they stop making security bucks because it's the dev ops teams that make the bucks, and it's not some kind of magic that injects the bucks.


It's the developers who make them, um, let me stop making them some very fast, just two weeks or two months of exposure to soft inline. Um, other kind of methods of implementing salts gave more time, uh, for people to learn, but essentially just to see sauce and other testing rigs as training, um, instead of seeing them as compliance tools, this really helps when you get, uh, get the adoption, um, eliminate. Uh, so from the intelligence perspective, we can see that ransomware is quite popular amongst criminals these days. So maybe a small tabletop exercise for management, easy to use stuff, so they can familiarize themselves with what to do. Uh, if things should happen, basically prepared them and avoid what they call the flapping of arms, uh, when something hits them, it makes people prepared. So train hard, fight, easy part of it. Uh, the third quadrant notes, the important persuasive organizational role in empowering, and please utilize their bottom up improvements and capacity in their own organizations.


So empowering is basically creating a supportive climate for service improvement. This is the core of the empowering exercise. So for me, um, when we did this, uh, it is trying to understand, like, in the example, before, when we had these three characters, uh, it is that they need to be empowered as team. They need to be able to make the decisions themselves. And this came from a profound learning when we really dug into lots of the various, um, incidents that had happened over the years. And we figured out that the only one who could actually fix a problem in any of the products, well, it's basically a dev ops team, isn't it? So if there's a breach who has to fix it, it's the combination of development, operations, and security. It's not the security guy. It's not the operations guy, probably it is the developer, but it might be a combined effort, joint effort.


So they need to be empowered. And this is also very important for the innovation, uh, part in our company. So when they, not them, they are more compliance oriented. So for this activity, it's important to give people a voice and utilize their bottom up improvement capacity, enroll during sessions, and let them know that in their context, they have the power to decide. Uh, one of the things that we have done, uh, to experiment with this is to establish what we have called the trust center, uh, which basically is a public facing page, uh, where we have listed information about the various services that we deliver to customers. And we also made it abundantly clear that the ones who will participate in meetings with customers, it's not sales, uh, it is the actual developers. They will have to meet the customers from time to time. And this is a really, truly empowering act because the customers is the ones who have the power in any, um, company that does, uh, in, in private industry. So empowering is for me key, and it all sort of comes at a cost. So parts of the empowering, um, is to accept that me as a director of security might not always be the one who should meet, should make the decisions on security. And I've learned that that is a very good thing. When you reach that realization, you build these just self-insight decisions has to be made by the ones who can do, um, can do the tasks to fix them.


The last quadrant, um, talks about embedding and the, um, uh, the best word is to incorporate as an essential part of characteristic. Well, this is for us, the, one of the absolutely most important components. So if you look at it from, um, reflect on this, so the traditional way of doing security from my own perspective is to write some kind of policy and then published a policy and maybe even have some kind of system in place to, um, determine if people have actually read that the policy. So by reading things, you assume that people will do as you tell them, well, that's not how the world works to be quite honest. So in the embedding part, it is the importance of organizations engaging in top-down efforts to embed the culture of improvement, innovation, and learning. This comes to the board policies and priorities, clinical governance, local improvement support, and celebrating success.


So this can w uh, rise. Yeah, volunteerism doesn't always happen like that. And also in response to kind of accountability mechanisms like performance and process standards, things like this. So from my perspective, it is about making the act natural for me, it just made it possible, made it important to incorporate a security work in day-to-day activities, rewarding, good behavior, and at the same time not reporting negative behavior. So in this context, we can, I can give you an example, this is, um, our Greg and I don't just call it the dragon. If you can see on the, that this one is basically a quality management system or an information security management system, but it's made into context it's made in the same way that it can be recognized by both developers from operations people, and also from security people. It kind of resonates well because in details the entire life cycle, um, in this, you can, can view one of them.


For instance, on top, you have a small CRO, this is an important part of, of, of the embedding and also the empowering the Crow, uh, signifies our intelligence program. So if I expect the teams to make good decisions or make good security decisions every day, I have to give them at least the same information that I have available. So I'm lucky enough to be in a company that is quite well-funded and works well. So we have devised a quite extensive intelligence program. That means that the developers and the operations people and the security people have the same information available for them. So when they make decisions, they make them together and they make quite good decisions every day. The other one is the security self-assessment, which basically is a template with lots of good questions, but we have plenty to learn from the rest of the world.


Um, both from open Sam and many of the others, uh, or the other very good schemas or frameworks out there, and try to translate this into our context. So all of these services that basically it's depicted in this, uh, in this image and the dragon, uh, represent individual steps that people take. So we have chosen to organize this in a small, but very skilled team of experts in the middle of this and the security people. They deliver services, security services. So the way we started, uh, we just started off the hat and moved from there. Um, we had already a manual vulnerability assessments. I do, it did have a colleague that did, we're very good at penetration testing. Uh, we also did have security self assessment. We had some building blocks when we started this process, but we chose very early on to invest in some static analysis. So there's most research and our analysis because there wasn't this map at the time indicator, we could get lots of good effects of this witness investment, and I can testify. You can also read it in the research, uh, that has worked quite well. So sassed, if you don't do sauce, please do sauce. Very simple.


Um, then we just added more services. All of them are based on the same fundamental principles. And in this, you can see that we have added, for instance, CTI up in the right-hand corner, the cyber threat intelligence included some more training platforms, but all of them are again under the same ambidextrous model. Uh, we don't have to decide to B to here to help. Uh, today's status is roughly around, uh, we delivered the services and one main focus for leadership in this well for, for myself and others who are part of the leadership is to focus. It's the balance exploration versus exploitation of, of these services. The exploratory part it's important while the use of lean methodology and expectation means that we have to keep a focus on cost efficiency by living in the services and cultivate the mindset of closing down services that do not make sense anymore because they will evolve all the time.


Uh, for that purpose, maybe use something called retrofitting as a methodology to analyze and understand this for whoever be much more detailed described in a new publication that will be released shortly. That's going to be a cliffhanger for you. It's going to be coming up in the research and I hope you will be reading it. So, part of what we have learned is that this, uh, it's a really sustainable method of delivering security services on agree works. It actually works this one. So the next we plan is to embed more services in this small and maybe mode some more that are complimentary and all in the spirit of exploration and exploitation for if you are, if you're, for instance, coming from a small to medium enterprise, like may is quite big. So just remember that security in your development doesn't come for free, and it's not a freebie where you can just buy this product and then you're done.


Um, you can use the available tools from the cloud providers. So like Azure dev slop, well, they have lots of good things going there. Um, and if you have really good people in your dev teams, some dev teams are just one person effectively, um, can be unicorns out there. They can do all of this together, but the kind of fundamental learning from us, if that security is not free, it comes at a cost. And for us as a big company, it was quite a needed to focus our attention on AppSec as a separate domain at first, and now spreading the same thinking to other parts of, of, uh, of security. So this is how we managed the managing directors, uh, and also how to give advice to the, um, to the ops teams. This is, uh, what we call, um, uh, the security maturity index, um, and all of the services I visualized and indexes they're carefully crafted for different complex to make sure they are relevant and give proper guidance.


So when they perform well, there is no need for actions, like indicated here in this smiley, so that this is two services, basically the one on top as well. The one on the bottom has some issues. And it's important to try to contextualize this, uh, depending on the, uh, on the audience you do have available, it's when it performed, well, there are no need for actions. You don't have to do anything as the MD or the team you are doing well on the bottom. Uh, they are having some issues and the kind of tools that we have provided them with gives them some clue where to look. So some of this might be a management issue. Maybe they haven't spent enough money. Maybe they don't, maybe they need some, some skills, um, uh, maybe they need just some love and affection. So it's remarkable. Um, uh, in our research, how much just paying attention, uh, matters, just see people and, um, and be there for them.


So when you, in the audience who are mentors, um, some of you get lots of questions from your sales and marketing that you need to have certification a or B or C. Well, this entire model is data driven. And this, um, the process is basically produces the data in a systemic way, dynamically, basically everyday. So this data is then used as evidence for auditors, that the processes are actually functional and adhere to it. So remember this w if you, if you really are on to certifications and all that stuff, you have a choice. You don't have to have the stressful, uh, preparation sessions that most people are used to, uh, where you have to flap your arms again, and then ask everybody to conform to the processes. At least when your is here, um, you can just make the processes, produce data that validates that they work.


And this is how we have chosen to do it, especially in one of our models that I'm very proud of. It's the best in the cloud delivery model. And if you search for that bird on YouTube, you can find a brilliant video of one of my colleagues would explain that in more detail. So if you remember from the start, are your people empowered? Are your people enabled and have you embedded and ensured that two above, this is part of our learnings. And we really hope that you are still curious, there's much more data and research for you to enjoy if you would care to do that. Um, and we're also, um, publishing more research in this field, uh, as we will progress, if any of you would like to make contact with either me or some of my colleagues, we are always willing to share.


Uh, and, um, as a final thing, remember the Qualcomm, the Quakers are not territorial. They are happy to share space, food and shelter. We need to be more like walkers. So we're all in this together. Both developers, security personnel and operations personnel. Uh, but since we are all territorial, it doesn't make sense that only one of us decides to does it. So, um, we have to get over, uh, our very, uh, internal, uh, language, and we have to start communicating in the same language and work better together. Thank you for your time. And I hope you have enjoyed this, uh, this talk.