Timo Pagel -- DevSecOps Maturity Model

0:00Chris RomeoTimo Pagel has been in the IT industry for over 15 years. After a career as a system administrator and web developer, he advises customers as a DevSecOps consultant and trainer. His focus is on security test automation for software and infrastructure and assessment of complex applications in the cloud. In his spare time, he teaches web and application security at various universities. Timo joins us to talk about the OWASP DevSecOps Maturity Model, or DSOM. Timo's the project lead for this effort within OWASP. We explore what are maturity models, what's this specific one, how can you use it, and how can you get started with DSOM. We hope you enjoy this conversation with Timo Pagel. You're about to listen to AppSec Podcast. When you're done with this, be sure to check out our other show, High Five.

0:53Robert HurlbutHey folks, welcome to another episode of the Application Security Podcast. My name is Robert Hurlbut, and I'm joined here with my co-host, Chris Romeo. Hey, Chris.

1:04Chris RomeoHey, Robert. Chris Romeo, CEO of Security Journey and co-host of said podcast. Pretty excited to talk about this DevSecOps-related topic. I know we've done a lot of conversations about DevSecOps. Seems like the 2 things we— 3 things we talk about. OWASP, DevSecOps, and threat modeling. Maybe we should rename the podcast, but it'd be a really long name. The OWASP DevSecOps and Threat Modeling Podcast to the Stars. That's a work in progress on the name. Maybe we'll stay with our original name.

1:32Robert HurlbutThere you go.

1:33Chris RomeoThere you go.

1:34Robert HurlbutWe're also talking about a security maturity model. We've done that before as well. And so, uh, our guest today is, uh, Timo Pagel. Welcome, Timo.

1:43Timo PagelHi, Robert. Thank you for the invitation.

1:46Robert HurlbutAbsolutely. Well, to kick off, we'd like to find out about you. If you could give us your origin story, your security origin story, really appreciate it.

1:54Timo PagelYeah, sure. I started an apprenticeship. That means that in Germany, I go to school, and at the same time, I work in a company as an operator. And I figured out soon that I would like to decide more things, how to implement stuff. So I started to study, and in that time I had in mind to become a database administrator. But then during studies, the database-related things were not as expected. It was about quality assurance, and as a young boy, I wanted to learn more technical things. But there were also professors which I liked in the area of security. So that's how it actually started for me. It started during university that the professor made an impact and an impression. And then I had a lot of freedom also during studies, so I could choose my own projects. For example, I did test automation during studies. That was also very nice, and that's security test automation, obviously. So that was how I started to love it. Nowadays, I think what's very interesting for me in security, and that's why I'm still doing it, because you You need to understand the underlying technology. And then in addition, you need to think about security. So that makes it very interesting and it's not getting boring. That's why I keep doing it.

3:22Chris RomeoSo I'm curious now, what was it that this mentor/professor, what did they do that encouraged you to go down the route of security? Because we got a lot of people that are listening here that have the opportunity to mentor people. And I'm just wondering, like, how can we encourage some other people that are out there about how they can have an impact on perhaps a student's life and end up with another security professional at the end?

3:51Timo PagelObviously, a professor is, or a mentor is the one in a white shirt, right? Coming as a star. And he had the right Technology level, which made me like it. So other were more about management, for example, right? So that wasn't my my style, or it was just programming. So that was too less. You know, when you know how to develop things, yes, you will learn maybe one two patterns, but that's it. And security was the right middle for me. It was not too easy and not too much management.

4:36Chris RomeoSo for all those folks out there, though, that have an opportunity to pour into perhaps a student that might be a part of your meetup or something like Timo's, the result of a professor pouring into him, and now he's a security professional that's had a successful career. And so I just want to encourage people out there, we're always talking about our cybersecurity resource problem. And we can argue about how big it is or how small it is, but, you know, at the end of the day, that's a— when you look back at the end of your career, that's the things that you remember are the people that you've watched be very successful. So I know that's a whole other podcast, but I just thought we would go there for a second. So, Timo, we want to talk about the OWASP DevSecOps maturity model, of which, let me tell you, I'm a big fan. Okay. I've studied it quite a bit and I'm a big fan of it, but for those in our audience who may not have experienced it or have ever looked at it before, give us a high-level definition about what is the OWASP DevSecOps maturity model.

5:37Timo PagelSure. Good that you're using it. What is the DevSecOps maturity model? A maturity model in general helps you to prioritize. So there are a lot of things you can do in the area of security. And the question is, how do you start? So first you need to answer what is there, and then how to start. And both questions are answered by the DevSecOps maturity model. It's— I have to say, it's mainly my point of view which I have introduced there, but also others are contributing. So it's Also partially from others. That is what you can do with it. Let me quickly take a look. Brian Glass once for the SAM, which you, I think, also have covered here for the Software Assurance maturity model, has had a very nice definition for security maturity models in general, which I would like to shortly— I have only modified it a tiny bit. So what is a the target of Security Maturity Model. It's analyze current software security practices, build a security program in defined iterations, show progress, progressive improvements in secure practices, and define and measure security-related activities. That is how he defined it, and I really like it because DevSecOps Maturity Model also is about we measure where are we right now, and then we think about where do we want to be actually.

7:16Chris RomeoYeah.

7:17Timo PagelOr what are at least the next steps to improve? You don't need to say, I have this target. It's also okay to say, what are my next activities? When you're more agile, you might not think about your target, which you have in 1 year. You might only think about what do we do in the next sprint? And then you can pick 1 activity.

7:36Chris RomeoSo when we think about DevSecOps maturity model, here's one way that I describe it, and I'm curious to see if if you agree that I'm describing it correctly. I like to tell people it's a road— it'll help you build a roadmap because everybody is focused on DevOps and DevSecOps and integrating security into all of our build pipelines. I look at something like the maturity model and say, hey, it helps me to assess where I am today, and it'll— but it also gives me some guidance for the future to say, I want my build pipeline to be to be enhanced in these particular areas, I don't just have to sit back and go, oh, what are— what could I do? I'll read a bunch of blog posts and see what people in the industry are saying. It gives me a framework to be able to say, okay, here's some categories of things that I can do to improve my build pipelines, for example. Is that a— is that a fair assessment from your perspective?

8:31Timo PagelYeah, that is. That's great. Yeah, I, in DSM, I call the categories dimension, but that is, I think, for the definition you have, it doesn't matter.

8:44Robert HurlbutSo, Timo, what is your recommendation for how someone can use the DSOM, you know, getting started and so forth? How would they do that and use it, really?

8:53Timo PagelIt depends on the person who would like to start it and how big it should be. As a developer, I mostly know already what I have done and what is missing. So you don't need to interview people. So you can easily sit down, think about what, what is already established from the activities in DSIM, and then you pick an area where you would like to improve. While as a security expert, you sometimes don't have the knowledge, so you have to plan first for, for interviews, maybe for scope Depending on how big the company is, maybe you choose which teams you would like to interview because they might use different technologies and you would like to only have the ones which are using old technology or the other way around, which are using the new cool stuff. So there are things to consider here. But in both cases, it ends up with we take a look, what have we already established? So that is the first step. And then you go to DSIM and think about which of these categories, how Chris called it or how it's called in DSIM, dimensions would you like to improve? And then you improve it. One thing about maturity models might be very interesting here. You first should try to get, yeah, in the DSIM it's green. So when you, DSIM actually has 2 parts. One is the maturity model with the data itself, and one is the application. So DSIM comes with an application because I have recognized it's not, it's not so easy to build a maturity model without an application. So I had to build an application for it too. So you can take a look at the application and you can click there on the different activities, and then you, you see a spider web diagram with a heat map which gets more green and green depending on how often you click on something. And in the maturity model, you first try to get the level 1 established, and then you go to level 2. Because when you are only in one dimension and you're only enhancing it, for example, testing, you're missing, for example, the logging or monitoring part completely. And that's not what you should do. You should try to build first all in the level 1, and then you go to level 2. And when you have established there most of the things, you go to level 3. It's okay to sometimes skip things, but then you need to have a reason why you're skipping. For example, the level 1 is more about simple things and simple monitoring and logging in DSIM, and you might say, I would like to have directly the advanced where I have visualization and so on. So it's possible to skip. Sometimes it makes sense, but mostly you should try to first make Level 1 and 2 and then 3 or 4.

12:03Chris RomeoSo for your specific levels then, can you walk us through the first one you kind of described here? Level 1 for a given dimension and sub-dimension is basic understanding of security practices. Walk us through just at a high level, you know, the difference between level 1, level 2, level 3, level 4.

12:21Timo PagelAh, I'm thinking how to do that to walk you through. I mean, the levels itself have names, but from my point of view, the names are not so important. Let me maybe start with how do I put things in one activity, and maybe that is the right start. So then you will see why there are multiple levels. Level 1 is about first motivation. So it's, it's more culture part. What I want to do on level 1 is to show people also that they have already established something. So when you start with a DevSecOps maturity model, I think, I hope that you already have some DevOps strategy in place. So that means that you most likely have already something like a defined build process, a defined deployment pipeline, in the best case, because you have burned it in code. So you have infrastructure as code already. And that are things, when you have already a defined build process, you can mark it already. So that is something, some activities which we have on level 1, motivating things which are already there. So you don't see a whiteboard. No, you have already some activities. That is, but that's just on level 1. On level 4, I think there are also some things which are motivating, but mainly this is the part on level 1. And now we come to activities which are not there to motivate. How do I do it in that case? So when I add an activity to DSIM, I think about how easy is it to implement this? Yeah. Because when it's more easy, it will move more to the left, and when it's more hard, I will move it more to the right. So for example, when we come to dynamic testing, when you want to have an advanced setup that are over 100 days of implementation in case you do it by, by yourself, so that is something I'm moving more to the right, while, um, other things I'm moving more to the left, like the defined build processes. That is something which is already there, so that should be easy for everyone. Then another category is which I take into account, how useful is it from a perspective of security? A defined build process is very useful because without it I can't perform my tests because I don't know where the artifacts which I would like to scan are lying or where the code is. When it's defined, I can use my tools to to scan this. And that is how the different levels are defined. I have already discovered that there are not enough levels because when you take a look at level 1, there are already too many activities. So I'm planning one day— it's open source— so one day to add more activities, to add more levels so that you have a more granular view, more granular when you have more granularity when it comes to the first maturity level that, you know, I have to implement these 4 activities. Yeah. And then, when you go up the levels, the things are there because they are more hard to implement or they have less value for security. And that's how— why there are 4 levels currently.

15:48Chris RomeoYeah. Let me trace through one with you just because I want to I want to illustrate the point that you just made here. And so, you mentioned the build, you know, dimension of build and deployment, sub-dimension deployment. So, level 1 has a defined deployment process because— and I'm just going to echo back kind of what I just heard you say in how I explain this and just to confirm I'm understanding as well. So, level 1 is about— it's about the things— it's about motivating the folks to realize, hey, there's some cool things you're already doing. So this basic understanding of security practice. So level 1, you have a defined deployment process for the, for build and deployment. Level 2, you have environment-dependent configuration parameters or secrets. You have usage of trusted images. Level 3, I have handover of confidential parameters. I'm guessing like secrets and keys using some type of key management, you know, key vaults or something like that. Inventory, you're running artifacts, rolling updates, usage of feature toggles. And then level 4, you've got full-on blue-green deployment. And so when I look across these, like, there's a lot of things that are DevOps-specific, right? Like, I mean, blue-green deployment is really not a security thing, but it is a best practice for having an awesome DevOps environment. So I'm seeing, like, how you've got some security things sprinkled in, you know, using environment variables for secrets at level 2, using a secrets vault at level 3, but also you have some DevOps best practices with like level 4 blue-green deployment. So I just wanted, I wanted our audience to see how one of these dimensions and sub-dimensions comes to life. Like, how do the things stack on top of it? So did I get it? Was my assessment right there? Or correct me if I'm wrong, please.

17:36Timo PagelYeah, that's correct.

17:42Chris RomeoOkay. Go ahead, Robert. Sorry.

17:44Robert HurlbutYeah, no problem. So thinking about DSOM and how it works, how is it different from OWASP SAM and BSIM? What are the differences, similarities? Curious.

17:58Timo PagelSAM and BSIM are both more on a higher level. So they tell you that you have to perform security testing, but their focus is not to tell you how. So what DSM does, it's more granular. That's what I mean with more granular. You have activities which actually tell you what you have to do. So when it comes, for example, to dynamic testing, you have the different steps you have to perform. For example, you need to perform authorization. Otherwise, in most applications, you don't get anything out. Or you need to make sure that you're also executing JavaScript nowadays because not every scanner will automatically do that when you just start it. That is something which I have added here. But what I don't want to do, so when this is high-level like SAM, here is the implementation. I don't want to go down to the implementation directly. I don't want to work on the tools. Yeah. Layer because that is too much down. Then I would need to rewrite it every day. That that so it's it's closely to the tools, but so I mention actually tools so that you get a better understanding what I mean because sometimes when you say that and that tool, it helps people to to understand what what they have to do. But it it is described in a way that it's not on the implementation. It's a bit on top. One one thing which is also different. No, but what automatically comes with it is that when you are doing a SAAM assessment, you can say, yeah, this is mostly implemented. You can give something like 75%. You have done 75% of this. In DSIM, I have the feeling you should decide, is it there or not? On an organization level, you can think about, is it 75%? Because maybe some teams have something and some teams not. But when you're assessing a team, Then from my point of view, it's yes or no. So that is something different from my point of view.

20:06Chris RomeoYeah, I think that makes sense too. From— it's a lot more cut and dry to just be able to say, hey, this is 1, we have it, 0, we don't. And because, you know, when I look at DSOM from what I'm seeing and how you put it together, it's not as much about A top-level score. Like when I think of SAM or BSIM, they they're kind of like a funnel that comes down into you know all these things play in. At the end of the day, I get a score that tells me how I did in each of these categories. And DSOM, when I look at this, it's more of just a hey this is a list of a roadmap of best practices, and you're either doing them or you're not. And it's you're not getting partial credit because it doesn't matter if you get partial credit. It's about you know, getting to the point where you have as many of these individual best practices for security and general best practices for DevOps integrated into your build pipeline. So there's no scoring at the end of it. It's just a, hey, this is driving us towards the best practices that we need to do.

21:08Timo PagelThat's also why we have white spots. SAM is very, very, very structured. So you can present it in a nice way to the management. All the areas have the same amount of activities and levels. DSOM has same amount of levels, but I don't have the target of putting an activity in every level. So there are sub-dimensions with levels which are white where there is no activity because I haven't found an activity so far which fits in there.

21:37Chris RomeoAnd you're not feeling the pressure to have to put one in every individual category. So I had another question about the connectivity of DSOM to other OWASP projects. I know, like, in application hardening, you reference ASVS and Mobile ASVS Level 1, kind of, you kind of, you kind of include portions of these other OWASP projects by reference. So instead of restating them, you're just bringing them in. So tell us a little bit more about how you're connecting with the other OWASP projects with DSOM.

22:13Timo PagelYeah, one, one thing where I'm connecting is actually the usage. I have a usage page in it. It's also readable directly in GitHub. You don't need to start the application where I have grabbed from the OWASP Integration Project some guidelines, also from a project, a research project which is called AppSec.NRW. It's a German research project where they had to develop a maturity model and they based their maturity model on DSIM. So there is also a lot of things to grab from, which I also included, for example, in the usage. Yeah, both, I think, are allowed me to copy. At least I hope so. And then when it comes to the activity, as you mentioned, application hardening level 1, there is a description why you have to do it. And then I'm referencing to these, referring to the other both OWASP projects. And also we have additional information where I, when there is good information out there, I also sometimes copy and paste it there and give the source where it comes from. In addition, what we also have with this is kind of Yeah, a tool inventory, we could say, because whenever I have an implementation like the OWASP SVS, I put it in here as a link. So, and I did do that for, for all the activities. I can't say it's complete, but you will always find OWASP projects or other open projects here. In case there is no open project, you might find commercial tools, but that's how they play together, I would say.

24:08Chris RomeoOkay. Yeah, that's helpful. That's something that I noticed as I was studying it. And I think it's a great best practice though. And we're starting to see lots of OWASP projects do that where instead of like, why restate something that's already been stated well in another document, just point to another OWASP document like ASVS for the application hardening. and let them keep updating that section. You know, it's, it's, it's making for a more integrated OWASP set of projects. And I think, you know, you mentioned the OWASP integration project as well. Like, they're doing a lot of great work there of just— and that's not easy work. It's, it's a lot of times it's hard to, to go through and try and figure out, okay, how does everything map together? But I'm, I'm glad they're doing that work because it's powerful. And if I want to go trace something through, I can watch it. I can trace concepts all the way through all the different OWASP projects that are being considered?

24:59Timo PagelAs you mentioned, application hardening, it wasn't there from the beginning. In the start, I didn't have it because I thought the definition is of a DevSecOps maturity model that I include only things which are not there in application security directly because I thought it's already there. So I don't need to mention it. But people started to use TSM and say, this is our complete framework, so also application security is in there. But I had to correct, no, it's not. It's about testing, for example, and the new way of logging and monitoring, but it's not about application security itself. So that's why I added this to highlight you also have to think about how you make secure development.

25:48Chris RomeoYeah. Makes sense. So let me give you a scenario here and I want to get your, I want to get you as the project lead for DevSecOps maturity model. I want to get your, your advice, I guess. So a number of people that are going to listen to this podcast, perhaps they haven't even heard of DSOM before. And, but now they're like, ooh, something I can do. I can, I can assess my DevSecOps build pipelines and our overall approach to DevSecOps in our company. What are a few things that you would recommend for them if somebody's brand new, they're just getting started with using DSOM? What's some advice that you would give them based on your experience as the project lead?

26:30Timo PagelIt depends where this— as I said in the start, what position this person is. Let us assume it's a developer in a team. So in that case, I would recommend this. You have already your scope, you want to assess the maturity of your team. You don't care about the organization. So you think about what have you already done from level 1 and 2. You don't, you don't take a look at 3 or 4. Uh, you just take a look at 1 and 2. And in case you're not having enough time for that, you're just focusing on level 1. So you see, you assess what you have already. Um, and then you, uh, start, um, in a planning to convince your other team members what are things we would like to implement. You just pick 2 or 3 from, from the possible things. You don't put everything on the table because it's too hard to explain. Um, some people tried actually to, in big organizations, try to talk with teams to let them say what are the next things, but it took too much time to explain every activity, so they had to break that up. So that's why I say pick level 1 and 2, make the assessment there, and then present 3 things you would like to enhance to your team and try to integrate at least one in this sprint and then the next one in another sprint.

27:57Chris RomeoYeah, that's helpful. I think that's, you know, that's going to help a number of people kind of get as they're trying to get started. And I like that idea of starting slow, starting small. That's what I always recommend to everybody that does anything. or in an organization is because so often we look at it, we're like, let's, let's just implement the whole thing. Like, let's do level 3 of DSOM here. Let's just get it done. Let's have it done by Tuesday. And like, it's just not realistic. And so what happens is people, they, they get discouraged through that process and then they're like, you know what, we're just not going to be— we're not going to be successful. And then they let stuff like this drop. So Yeah, I mean, Timo, I'm a giant fan of DeSum. I've studied it quite a bit and really appreciate the efforts that you put into— and I appreciate all OWASP project leads because most people, you know, I think most people realize like Timo's not getting paid. OWASP is not sending Timo a royalty check for everyone who downloads DeSum, like he's getting like, you know, $10 American for every time someone downloads it. It's—

29:00Robert HurlbutYeah.

29:01Chris RomeoOWASP projects are labors of love, and the only reason that OWASP continues to succeed is folks like Timo who are out there working probably in the middle of the night sometimes because it's not your day job, but updating. So we definitely appreciate the efforts and stuff that you put in.

29:18Timo PagelWhen you have recommendations of what to enhance, you're always welcome to create a pull request.

29:25Chris RomeoOkay, that's awesome. Yeah. And I'm sure you're making that— that's for everyone in the audience as well. Like, that's one of the other things about OWASP projects that's so cool is it's open, it's open source, and it's in GitHub so you can create a PR. And I know I owe you a few PRs, Timo, based on some things that I saw. And so I'm gonna get out and do some work to help enhance some of the things that I saw that I think I can add some value to in that. So definitely looking forward to doing that. Well, what about, What are the key takeaways for our audience here? Like, what are the— or a call to action. If you want our folks that are listening to do something, you can give them homework here. I mean, we give you permission. You're the teacher here at this moment.

30:08Timo PagelYeah, I think the takeaway is that it's very easy to start. So you just need to sit down and start. It doesn't take much time. Level 1 are only a couple of activities which you can grab really fast and then assess, see where points are missing and just implement them.

30:28Robert HurlbutVery cool.

30:31Chris RomeoYes, that's actionable direct advice for how folks can go out and put this thing into use. So, that's your homework, listeners, is to go review the DSOM, understand it, and then as Timo said, start cranking on Level 1 and then start looking over at Level 2 once you get Level 1. kind of figured out and in line. So, Timo, thank you for being a guest here on the Application Security Podcast. Appreciate all that you do and look forward to seeing you soon somewhere at a conference somewhere in the world.

31:02Timo PagelThank you. Sure. Next year, I think we start to go to conferences again, right? And in real. So I'm looking forward to that.

31:10Chris RomeoYeah. Hopefully OWASP Dublin is on the books right now as Kind of the first big OWASP event back in Europe. So looking forward to being a part of that in the future. Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @Edgeroute and Robert @RobertHoffman.

31:41Robert HurlbutPearlbutt.

31:42Chris RomeoRemember, with application security, there are many paths but only one destination.