CyberWire Daily - Moving Faster - Securely. Why Your Org Should Add Security to your DevOps Program [Security Sandbox]

Episode Date: October 10, 2022

In today’s episode, our sandbox heads to the deployment pipeline for a conversation on the who/what/when/and why of a DevSecOps program and how it adds value to your business. And your main questions- – how you can encourage buy-in and adoption. Joining me today are Marcin Swiety, Relativity’s Senior Director of Global Security and IT, and Raphael Theberge - Director of Security Integrations. So, grab your DORA metrics, your source controls, and staging environments, and let’s dive in.  Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. I'm Amanda Fennell, Chief Security Officer and Chief Information Officer at Relativity, where we help the legal and compliance world solve complex data problems securely. And that takes a lot of creativity. One of the best things about a sandbox is you can explore and try anything. When good tech meets well-trained, empowered employees, your business is more secure. This season, we're exploring ways to elevate the strongest link in your security chain, people, through a creative use of technology, process, and training. Grab your shovel, and let's dig in.

In today's episode, our Sandbox heads to the deployment pipeline for a conversation on the who, what, when, and why of a DevSecOps program and how it adds value to your business. And it's going to answer your main questions, how can you encourage buy-in and adoption? Joining me today are Marcin Świętu, Relativity Senior Director of Global Security and IT, and Raphael Taberge, Director of Security Integrations. So grab your DORA metrics, your source controls, and staging environments, and let's dive in. We're going to jump right into the topic at hand.

We're not going to do a shot every time somebody says DevOps or CICD. It's super close. I know, Raphael's nodding like, I thought that's what I was here for. Okay. It's super close. But no, we're going to go through this in the beginning, though. How would you describe DevSecOps to your grandparents, Raphael?

All right. Well, the first thing I would say is that I simply wouldn't. I wouldn't do them the disservice of bothering them with that. But for argument's sake, let's say that I would do it. The closest analogy that I would use is probably comparing it to having a cookbook, where, you know, you open up your cookbook, you have a picture of here's a meal that you want to prepare. Whatever it is doesn't matter.

You chose the worst thing to do on a show with me, by the way. You went for cooking? Let's do this. Let's do this. This is not an accident. All right. Smart man. Okay. And you really have two different components in your recipe book that matter. You have a list of ingredients and preparation that's needed, and you have steps to build it. And the way that I look at the DevSecOps portion is really as those two aspects.

You have the build steps, which is your recipe of what you do to achieve your final product, which is a meal in this case. And your sec ops that you add into it is really all that has to do about the preparation, all the surrounding, how you prepare your ingredients, what ingredients you ingredients, what ingredients

you use, what quality you want, what's the nutritional impact of it. Everything from A to Z stems from that. And I'm stretching the comparison a little bit, but bear in mind this is an Instagram per usage. Yeah. No, if you were pandering to the chef in me, like I'm interested in this, we're going to go into this. I have some input on this one.

Marcin, do you agree, disagree? Does this resonate with you? Because I'm about to double click on it. To some extent, yes. But no. I like to make a switch here. I don't see how that differs, though, from the usual approach, right? And there is something about DevSecOps that is actually different,

that actually allows you to run faster, make stronger outcomes, or more predictable even at some point. So what's the difference in the recipe and the ingredients between what we did old style and we do right now? This is actually what I was going to double click on, March, and I'm not surprised you honed in on it. But here's the thing. So with cooking, before you start, you put together your mise en place.

You put all the recipes in place. You get everything situated. And then once you've made sure everything is there, trust me, my kids are always trying to get me to make pancakes. And I always tell them, do the mise en place. Let's see how this goes. So they get everything together. They set up all their ingredients and everything. The difference from my very different perspective per chance is that instead of waiting for all of the ingredients to be put in place first, is that instead of waiting for all of the ingredients to be put in place first, you start running.

You would start the cooking and start the moving, and you would pivot as needed. And that's how I feel about the DevSecOps, is that it moves things to the left. You're not waiting for a step to be completed to go to the next one. And I think this is an interesting topic for the three of us because, Raphael, it's like a Batman reference. You were born in DevSecOps. Molded by it, right? We were not. We built, created, made this entire thing, and then said,

oh crap, we probably need to figure out how to implement security more to the left. That's the way I'm approaching it. Correct, Marcin and I? are we wrong? Is that an incorrect way of looking at it? I don't think that it's wrong at all. I think that with my analogy, what I was showcasing is how do you make one instance of a meal? Now, when you shift this into a business context and you want to make not one, but potentially, let's say a million a day, to make not one, but potentially, let's say a million a day, for argument's sake, then you need to have those steps very well defined. You need to be using the same structure everywhere.

You need to understand every single step and all the complexity it entails all throughout so that you can upscale it and truly change from grandma's kitchen to a manufacturer. Oh, so now your grandma's cooking. Okay, that was a good way to talk to her then. That's why you chose that too. You're like, you're cooking. So DevSecOps promotes faster development of secure code base. Aha, I see a flaw.

Everyone in technology has latched on to this term. So for instance, I have more than just security, I also have IT. IT has latched on, oh, we have to do DevOps. We have to do, first of all, okay, let's go back for a second. DevOps versus DevSecOps. You know I've gotten into a fight

about this one many a time. Did I back the wrong pony? What are we supposed to call it? The question of naming convention is a very difficult one. That term, and both those terms really, have been co-opted by so many other entities to turn it into marketing material, to make it more accessible. And there's a lot of good reasons why. of good reasons why, but the meaning has been diluted over time and really it can be twisted and turned to mean whatever you want today. That's the best answer, Fred. It could be whatever you want. So you're going to let people choose their own adventure. Marcin,

what do you refer to it as? I think my concept of what what devsecups would mean actually and in that term is coming of those three functions and and interests together and collaborating um and i think when we when we go back to your recipe um analogy rafael uh i think there is something that just you know popped into my mind when my grandparents were making dumplings. So I remember every now and then there was a, I would say, soccer game on and my grandparent would love to watch that. But he had a duty to assemble the dumplings. Oh, yes. If you would take that task specifically out of the kitchen to the living room where the game was on,

somehow the entire process, although it was streamlined, like this is a huge adventure for the entire family to prepare a lot of dumplings for coming weeks, it kind of broke because there was no closed feedback loops on how fast we are going how much we need more minced meat how we are going with boiling boiling the the dumplings and so on so forth and i think that what it actually means to me that kind of closed feedback loops uh very short side of what's working what's not working what we can align and adjust and we are still perfectly aware what the exact steps are, although we need to adjust the speed, the process, and we need to synchronize together.

So I think that's what DevSecOps means to me. So move faster, move better, move more securely. Why are people not taking the time to go and do this and implement this? Oh, this is a good one. I think the biggest, I found the biggest detractor to this or the biggest wall that we need to break through is we've always done this this way. I think that's the common theme that we have in the entire industry. And there is a good reason for that.

What worked so far, it's really hard to knock that down. And we have a saying in Poland that if it works, don't touch it, because it might break. And I think that's one of the... It's pessimistic as expected. I love it. Yeah, of course, of course. I'm born in Poland. But that's one part of this,

of why people are not doing this largely and everywhere. It's because there is another way, there is a contextual historical point of view on how things are being done at this moment, in this specific moment, for a specific company. And that type of switch is actually something kind of redefining the relationships,

the product, the outcomes, and more specifically, the responsibilities and ownership. And that's, I think, what is the basis for how we are not doing it everywhere, in every company, in every world. Raphael, you've come to a new place. Yeah. How's it been for you?

Is it the same impression? I think that there is a bit of a fundamental truth in that changing the status quo is difficult. It's an inherently difficult proposition. Even if you have the best intention in mind, you need to be able to see your vision through. You need to be able to showcase, yes, this will be a meaningful endeavor. And for you to cast that vision to everyone around and for them to understand that they need that baseline understanding of why does this matter. So there's a lot of education that needs to happen in terms of why should I invest in this? What are the expected return on those investments? And that's both in time and quality of life and predictability. And truly, fundamentally, it's really a matter of education. And for some people

and maybe a lot of people, I'm not sure, seeing it matters way more than hearing about it. And being able to experience, okay, here's what it is to operate in a company that does DevSecOps correctly, or correctly is quote-unquote, right? But you said DevSecOps, just saying, so that's how you said it. Yes, yes, yeah, fair enough. Caught you. All right, got saying. So that's how you said it. Yes, yes. Yeah, fair enough. Caught you. All right, got it. Yeah.

I love a couple of the things you've mentioned though, because I think it's a surprise to hear you speak so much of this about like the business side of it. I think a lot of people expect us to just speak about the security and like just get stuff secure and that's all we care about. But you're clearly coming at this from a business perspective of how to move faster, more efficiently to accomplish better business needs and so on. So talk about DORA metrics and I assume this is not DORA the Explorer.

So I'm ready. Teach me. What do we got? There are four metrics inside of the DORA set. This is a set that is actually one of the ways how you can measure success and measure how how you track towards uh this this uh this journey um there are four of those uh two of those are speaking solely about speed and maybe even frequency of how you deliver and the later two are talking about when what happens when something goes wrong and how often it happens so you have the deployment frequency you have lead time for changes and the other two is mean time to recovery and is mean time to recovery and change value rate.

So these are the four basis metrics that I think the entire industry is either familiar with or actually uses to track towards DevSecOps achievement or advancement or maturity, whatever we like to call it. So Rafael, if you've got these metrics, you were speaking all business-y earlier. So taking these DORA metrics, which I have to look at as well, what am I supposed to be taking away from it? I just want to see green is good, or is this providing some other value that I need?

Well, green is good is certainly one part of it, obviously. But going more in depth, I think it speaks to how do we monitor those metrics. We have a metric, the name is called lead time to change. All right. How is that being measured and what does it encompass? Is it actually measuring the entire time it takes to go from keyboard on hand to a change on the production environment? Or is it only a subset of that? environment or is it only a subset of that? And I think that when we speak of the distinctions between DevOps and DevSecOps, it's really about englobing the entirety of the pipeline,

including all of the security characteristics into those metrics. So instead, you will have the same metric, it will have the same name, But what it means, what it encompasses, and how it is being measured is different. If, for example, you take your lead time to change and you factor in all of the security analysis, security fixes, or whatever is needed, your average lead time to change may be a little bit higher because you're now encompassing a few more things, but it will be way less spiky because you won't have those big anomaly when there's a security event or something has been detected. You smooth out those metrics over time

so that you can better predict future performance. So it's not just for engineering. It's not just for engineering. It's for not just for security. It's for all teams that can do this and they can approach these metrics and try to measure moving the needle over time. Marchin, I'll start with you because I know Raphael is going to have something very exciting to talk about on this topic, but has this impacted the relationship between security and engineering? I say that laughing because I'm waiting to see. That was me taking the grenade pin out and throwing it over there.

Yeah, this required a huge redefinition of what the relationship is actually about. There's a lot of friction in most of those redefinitions because it touches the ownership and responsibility set. And as soon as both of those sides or three sides or four sides, depending on how we are built and how we are doing our business, those sides to this, as soon as they realize that they are co-owning the success and co-owning the future of their component, of their growth and ultimately their business, then that redefinition actually starts to get better. And that's properly set up as a North Star. So what I'm trying to say here is I've seen a lot, especially when I

looked at my consulting days on different companies from different industries, that type of relationship can be love-hate. In most cases, it's actually that, love-hate with a little bit of cue towards hate, because security has been known as gatekeepers, blockers, or even no-sayers in a lot of engagement that I've seen in the past in other companies, in I think every industry that I worked for. And this is interesting because what DevSecOps is supposed to build is a true partnership. And I think that's the key change that we need to look for. But I would hope to take your point of view,

Raphael, on this side. Okay, so let's have the guy who I stole from engineering into security, by all means. Has there been any friction over there, buddy? I think, you know, if I pull back to the original question, how will it affect just agnostically the relationship between security and engineering?

It depends on when and how it's done, primarily, depending on what stage you're at in your company. If you're doing it as day one, joining a startup, you're four people in a garage somewhere, there will be no consequence. There will be no impact. It will work, and that's it. If you are a multinational corporation and trying to go from zero to one, now there will be an impact. You're trying, like I said earlier, changing the status quo. You are enacting changes. There will be friction during that period of change. The intended outcome at the end is really to reduce the amount of friction between those two things through various automated pipelines and various automated processes. But it doesn't reduce the total amount of interactions.

It changes them. Those interactions will still happen probably to some automated systems. Those interactions will still happen, probably to some automated systems, but these will capture what I like to call the more toil-level tasks, where people are doing things that are tiny nitty-gritty things that need to be done over time. And by ideally tackling those in an automated fashion, you're upscaling the conversation between your security group and your engineering organization to be working on much harder and deeper problems like architectural and deep meaning conversation that will change how your company functions and essentially create more time and more space to have those deeper conversations. essentially create more time and more space to have those deeper conversations.

And yeah, those will be fraught with back and forth, and not everyone is going to like it, but it needs to happen. And those are the truly impactful decisions that will change the course of how things go. So all of these things that are impactful, I just want to pull back because there's a couple things that I'm going to say is like kind of the, what do they call it, like an elephant in the room here. You have to get buy-in for people to do it. We talked about it a few minutes ago that it's, where do you, you know, who's doing what, where are we going with this, what am I looking for from DoraMetrics, et cetera, but then also why aren't people doing this. Let's talk about minute for the buy-in. I think everyone thinks the buy-in has to happen at the executive level or the functional leader level, when actually that's where we struggle the

most is that it's not there. We need to get buy-in from the actual engineer's hands on keyboard because they have, as we mentioned, a list of priorities. And this is not number one priority. To stop the fire hose that's coming at them, they're going to have to take that for a while while they go and fix this, right? And then everything will smooth out. But they're not convinced that's going to happen. So there's a question about buy-in here for DevOps, DevSecOps. So there's this idea here of we've got to get buy-in,

we've got to get buy-in. It's not from us, I think it's from the engineers. What would you two say? I would tend to agree. But I think that we can argue over the definition of buy-in in this case. You can be autocratic and say, you must now use pipeline X to achieve Y. And it is what it is.

That will create some friction, but it is possible. Now, if you phrase it differently and you say, hey, I've created this pipeline X, you can choose to use it or a subset of it, and it may well improve on your delivery time and let people self-serve and self-onboard into it and get to see the progress by themselves. And not everyone will be impacted immediately positively by those changes. So the level of experience of the specific engineers will matter. Ideally, you want to have people with a little bit more seniority go into it and really iron out the key details.

And then your more junior-ish staff will get to benefit from it significantly more. and then your more junior-ish staff will get to benefit from it significantly more. I would say I agree with 100% to that which you just said, but I would actually add also that the buy-in does require a strong support from leadership and management, but this is not a buy-in type of relationship. This is a strategic decision at some point. You have to run faster, you have to make stronger, more robust software, and you have to eliminate the frictions. You cannot maintain the speed with, you know,

growing company, more complexity, more products, more components. So this is like a business decision on a higher level of managing the entire thing. But I would agree that in the lower levels, this is buy-in through enabling them to see the benefits. But also, sometimes every now and then you need to step in and say that you cannot take your, you know, dumpling assembly in front of the TV because it will not work. You have to be responsible for the entire process. You have to be owner

of the future, of your component, your code, regardless whether it is about the maintenance, whether it is about the security. You've built it, you are required to be projecting and protecting its future. I think that's a little bit different than this whole buy-in.

Sometimes you just need to create a space where that's a requirement because otherwise that ownership might blur itself very, very quickly. So buy-in aside, once you decide, what's my timeline look like for this? Can I get DevSecOps in six months? What's the situation here? Marcin, you want to go first? Yeah.

I don't like to talk about timelines. It's my favorite thing, by the way. In the kitchen, I constantly ask the sous chef, and I'm like, okay, so you want me to do this with the risotto? How long until I start? He's like, I don't like times. I don't know why you always ask me times. I'm like, because I'm a CISO.

That's all I want to know is how much time. But I will say, you definitely can start now. The timeline that you have full control of is you can start now. There is nothing preventing you from actually starting to define the roadmap, the principles, what actually DevSecOps means for your organization, what type of metrics you are going to use

when you are going to measure success. You can start at it right now. And as soon as you do that, you will see immediate changes to what you are aiming for and what you are building. Of course, there is tool, process, and tech, right, to every adventure we undertake. But I think this one is actually quite easy to start for a decision.

Of course, implementation, it will take time. Six months, I wouldn't say that it's feasible to really go fully into every aspect of living, breathing system that you've built over decades. That would be probably a quite challenging task to have 100% completion on. But I would say six months would be quite enough time to get significant advancement to be able to deliver faster, quicker,

and more robust pieces of software that you care about the most. I find myself agreeing and disagreeing at the same time. Isn't this how we started? Was you both agree to disagree with each other? It is, right? Here we go. In terms of timeline,

let's assume you want this to happen within six months. All right, where are we starting from? If we currently are 90% of the way there, yeah, of course, that's trivial. If we're starting from scratch, it depends on the size of your company, it depends on what your other goals are going to be, how much resources, how much money are you going to put into it, all those details.

But the part to me that makes it difficult to stick to a specific schedule is that there's three components to all big transformation. You have your tech, you have your processes, and you have your people. And tech and processes, you can change that over six months. That's more or less trivial. Changing people's mindset over a six-month time frame is an extremely challenging endeavor. Perhaps not impossible. Certainly not impossible, but very challenging.

I think that's an interesting point though, because sometimes I just wish I'd had the two of you for my first day at Relativity, because I feel like I would have gotten a lot done a lot better, a lot sooner if I had. But you make this comment about changing people's minds and so on. Yes, it takes time. I think it depends on how much that muscle was built originally. And so I say this because you could throw anything at the security team and their response is to be like, okay, Amanda's crazy again. Let's do it, whatever. And they kind of just work through it and get through it, right? And I love this quality in people that you either, with change, you either struggle with it,

maintain and get through it, or thrive on it. And I feel like our security team, more people than not thrive on the change. So we threw a lot of DevSecOps into there and everyone was like, okay, here we go, right? Here's the next journey. But there are a lot of people in the org that struggle with it. I think because probably they think it's because they need to create a playbook and they don't see a lot of value and they don't see the, you know, the low hanging fruit and stuff like that. So yes, I think the culture change is probably a big factor and that's an unknown until you get started because you don't know how receptive people maybe are, but you could prepare yourself by making them receptive to change by constantly changing things up on them previously, which we do all the time. Like you don't always

know what's going on because we throw some weird things at people and they're like, okay. So, all right. So I think I've got some main points I'm going to wrap this into. We'll see if we agree to disagree on this one. It seems like closed feedback loops are still important. You can't move too fast without this clear vision and guidance as to what's working and what's not. So you don't want to let the dumplings break. I'm super hungry now for dumplings, Marcin, but okay. Count to Poland.

Always, right? This is next stop. To sell the DevSecOps idea, seeing is believing. You need to see the process and work and the speed that comes from it, the value that's delivered. And it has to have like this upscaling conversation has to work on deeper problems. It can't just be, you're going to make this move faster. It has to be, you're going to fundamentally make things move faster. And I feel like there's a strategic part here too about reducing, it doesn't reduce the total number of interactions you're probably having between teams, but it would change them. And March, it sounded like you were saying it's a different dynamic

and that you just have a changed conversation as opposed to the blocking, and it's much more of that partnership comes out of it because we both want the same thing. We want to move faster securely. I always like to put comma securely. And it feels like this is that great energy, right? But all right. So these feel like my three main things. If each of you gets one main thing that people will walk away from and say DevSecOps means this, what would you say? So it's not your grandma now. This is the

people who are listening to the podcast, which might be your grandma. I don't know. What are you going to say is your one takeaway? I would say that it's all about upgrading the level of discourse across your company and being able to move out of the tiny details that are important and need to be handled into higher order conversations and higher order problem solving. And to pile on that, I think, Rafael, I would agree here, of course, here, only here.

Only, yeah. I would add that the co-owning of the success of the endeavors and undertakings that any business takes is also key. So it's removing the frictions, increasing the depth of those conversation interactions, and finally co-owning the success by every team that is involved. Wow. So finally we have an agreement. We worked so hard to get an agreement, but I love to end on a quote, and this particular one might be the only quote

I'm ever going to use by Ralph Waldo Emerson. I can't stand Emerson and Thoreau and Walt Whitman. This is not my area at all. If you had told me it was a Frank Herbert discussion, I can follow sci-fi. If it's Cthulhu or Lovecraft, I've got it. But okay, Emerson had his moments. So he said,

do not be too timid and squeamish about your actions. All life is an experiment, and the more experiments you make, the better. I think that's going to capture my DevSecOps mode right there. Let's make an experiment. That's very nice. If I may follow that, I also have my own quote ready to go. Is this tattooed on your arm?

Because if it's not... It's not tattooed on my arm, although I might consider it. I'm translating it from French, from the illustrious Marie Curie. In life, nothing is to be feared. Everything is to be understood. Oh, wow. Raphael, talk about the feather on the cap. I can't come back from that.

That is awesome. Thank you for that. I can't come back from that. That is awesome. Thank you for that. Gentlemen, it has been a pleasure. I have enjoyed spending some time with both of you where we were not having to just get work done. So thank you so much for joining and giving us some time to talk about your favorite topic. Thank you so much for having me.

It was amazing. Thanks for digging into these topics with us today. We hope you got some valuable insights from the episode. Please share your comments. Give us a rating. We'd love to hear from you. Security Sandbox is produced by Relativity. Our theme music was created by Monarch.

Find us wherever you listen to your podcasts or visit relativity.com for more episodes.