--- title: "Marc French, Steve Lipner, Maya Kaczorowski, DJ Schleen, Kim Wuyts — Season Six Wrap up" url: https://appsecpodcast.com/marc-french-steve-lipner-maya-kaczorowski-dj-schleen-kim-wuyts-season-six-wrap-up/ date: 2020-05-14 duration_seconds: 1515 guests: ["Kim Wuyts", "DJ Schleen", "Marc French", "Maya Kaczorowski", "Steve Lipner"] topics: ["Cloud and Infrastructure", "DevSecOps and CI/CD", "Privacy and Compliance"] audio: https://www.buzzsprout.com/1730684/episodes/8122606-marc-french-steve-lipner-maya-kaczorowski-dj-schleen-kim-wuyts-season-six-wrap-up.mp3 video: https://www.youtube.com/watch?v=Qame9gks7Dw transcript: true --- # Marc French, Steve Lipner, Maya Kaczorowski, DJ Schleen, Kim Wuyts — Season Six Wrap up *May 14, 2020 · 25 min* with [Kim Wuyts](https://appsecpodcast.com/guests/kim-wuyts/), [DJ Schleen](https://appsecpodcast.com/guests/dj-schleen/), [Marc French](https://appsecpodcast.com/guests/marc-french/), [Maya Kaczorowski](https://appsecpodcast.com/guests/maya-kaczorowski/), [Steve Lipner](https://appsecpodcast.com/guests/steve-lipner/) on [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/), [Privacy and Compliance](https://appsecpodcast.com/topics/privacy-and-compliance/) [Audio](https://www.buzzsprout.com/1730684/episodes/8122606-marc-french-steve-lipner-maya-kaczorowski-dj-schleen-kim-wuyts-season-six-wrap-up.mp3) · [Video](https://www.youtube.com/watch?v=Qame9gks7Dw) ## Show notes Season six closes by revisiting five conversations that capture the breadth of application security. Chris and Robert return to Marc French on the AppSec CISO, Steve Lipner on the history and future of the Microsoft SDL, Maya Kaczorowski on container and orchestration security, DJ Schleen on DevOps and organizational change, and Kim Wuyts on privacy threat modeling. Each segment pulls forward a durable lesson from the original interview and points listeners back to the full discussion. Together they connect leadership, secure development, cloud-native infrastructure, culture, and privacy into a concise tour of the season’s most useful and enduring ideas for practitioners. The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/). About Security Journey Security Journey provides application security education for developers and everyone in the software development lifecycle. → [Learn more about Security Journey](https://www.securityjourney.com/) Connect with the featured guests: → [Marc French on X](https://x.com/appsecdude) → [Steve Lipner at SAFECode](https://safecode.org/) → [Maya Kaczorowski](https://www.linkedin.com/in/mayakaczorowski) → [DJ Schleen](https://www.linkedin.com/in/djschleen) → [Kim Wuyts](https://www.linkedin.com/in/kimwuyts) Mentioned in this episode: → [Microsoft Security Development Lifecycle](https://www.microsoft.com/en-us/securityengineering/sdl) → [SAFECode](https://safecode.org/) → [gVisor](https://gvisor.dev/) → [Kata Containers](https://katacontainers.io/) → [The Unicorn Project](https://itrevolution.com/product/the-unicorn-project/) → [LINDDUN](https://linddun.org/) Chapters: 00:00 Season six lessons worth revisiting 02:00 Marc French on becoming the AppSec CISO 06:07 Steve Lipner on the Microsoft SDL 10:31 Maya Kaczorowski on container security 15:30 DJ Schleen on DevOps and organizational change 22:00 Kim Wuyts on privacy threat modeling 24:30 Closing season six ## Transcript *4,274 words · assemblyai* **0:00 Chris Romeo:** Hey folks, this is Chris Romeo, CEO of Security Journey and co-host of the Application Security Podcast. I'm here to share the news with you that we've reached the conclusion of season 6. We're going to share clips from 5 different episodes. You're going to hear from Mark French, Steve Lipner, Maya Ketcharovsky, DJ Schleen, and Kim Wutz, all very experienced practitioners in their own area of application security. The other thing I realized as I was preparing for this episode is that we've actually done 126 episodes of the Application Security Podcast. We apparently missed the 100th episode show, but I guess we'll just have to make it up when we get to the 200th episode. We hope you enjoyed this conversation with a whole series of guests from season 6. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with learning. We believe that developers need hands-on experience, but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo. We start with season 6, episode 1, where we hear from Mark French on the topic of the AppSec CISO. And the question that I directed to Mark is, what are some tips for someone who wants to become a CISO? And is there such a thing as a CISO school? What are some tips then, Mark, that you would provide for somebody who wants to follow in your footsteps here, become a CISO? What do they do? Do you go to CISO school? Is there such a thing as CISO school? **2:07** There's not such a thing as CISO school. So I guess I'll just ask a clarifying question. So these are folks coming up through AppSec, is that— or just in general? **2:18 Chris Romeo:** Let's talk in general first, and then maybe we'll add a little AppSec spin on it after. **2:23** Yeah, and I'd also like to ask about students. I just recently was talking to some college students, and I Met a couple who said, I'd like to be a CISO one day. Okay. **2:32** Oh boy. **2:34** Okay. **2:35** So let's start with Chris's first one. **2:37 Chris Romeo:** Kind of the general, general nature. **2:40** We'll talk about the general nature of it. You know, I think you've got to— I always tell folks, take a job for the job after this job. So a lot of folks kind of take a gig looking what they're going to provide and not thinking about the longer-term strategy. So everybody that I kind of mentor, I say, You're going to take this job. What job is that going to get you afterwards? So if you think about what a CISO— the breadth of what a CISO needs to understand, you've got to start positioning yourself and really put a plan together to say, all right, I'm in this space. I'm a GRC person, as an example, because I've started in information security and I've got a compliance focus. I really need to learn the other disciplines of of this practice. You don't have to be an expert in all of them. You need to be an expert in one, but you're going to have to have pretty deep knowledge in the other disciplines. So you need to go off and take a role that's going to get you that kind of infrastructure security space or get you some experience with engineering. Because when you get up to the CISO role, there's going to be an expectation that you have some knowledge, and I'll say a little, probably more than some, across all of these different disciplines. So you've got to kind of plan that out and make sure that you're taking roles that are going to kind of fill in the boxes of all the different functions of security. I'll be honest with you, I think the hardest one out there is when you get a converged role. So a lot of— I see this a lot in technology companies— security, security, security. So you've got the CISO who's a tech person, and all of a sudden they say, oh, you're a head of security, you have physical security. And that's not really something that a lot of technology people do, and all of a sudden, you got to worry about what we call Triple G, gates, guards, and guns, and you are thrust into this world of badges and executive protection and the corporate jet and all this other stuff. Sometimes it is hard. There is a little shock and awe when that happens, but I have seen it a lot. How do you plan that out to make sure that you have at least some knowledge of that when you have been given the position to take those things over? So, you know, you really got to plan this through and think about this. So that's kind of my general answer, Chris. **4:48** Okay. **4:50** Now, AppSec, you know, what I would tell you there is, you know, if you're an AppSec practitioner, if I were going to make the next move, I'd probably go into compliance. I hate to say that, but the reason is, is a lot of what gets driven from the top gets driven by the sales organization. A lot of times what happens there is it gets driven by compliance initiatives. Hey, we're going to launch into the healthcare vertical. Well, now you've got to understand HIPAA and PHI here in the US. So, you know, it's also going to help you decide whether or not it's the role you want because it's going to be a very less technical role and it's going to be more indicative of some of the things you're going to do at the CISO role. So if you're a practitioner, I'd almost say Go off and do compliance as your next gig, because that transition to do kind of infrastructure security is going to be easier for you as a technologist. So do that jump after you do the compliance gig, because you want to know right away whether or not you're going to want to be a CISO. So doing the compliance stuff is going to be more like it. Make that gig your next gig, and if you like it, then do the infrastructure. Now you've kind of holistically got all of the checkboxes, and now you can start having the conversation about, you know, kind of evolving into the CISO. **6:07 Chris Romeo:** Up next, Next is Season 6, Episode 5, a clip from Steve Lipner where he talks about the past, present, and future of SDL. I've looked up to Steve Lipner as a giant in the industry for my entire career. And so after some setup here, I ask him for a definition of Secure Development Lifecycle. Yeah, and when I think about all of the Secure Development Lifecycles from other companies, yeah, I mean, every— everybody points back to, to what you and the team did at Microsoft. Like, I mean, I was at Cisco for a number of years and The Cisco Secure Development Lifecycle was built in the same— with the same components, the same pieces, and even a lot of the advice from the folks at Microsoft in how to do it. And that was one of the really cool things about being part of CSDL was that we were able to have those conversations with our peers at Microsoft. And Microsoft was so open to say, well, here's all the things that we've tried. Here's the things that didn't work. Here's the things that were awesome. And you can try the things that didn't work. But we're just going to share that knowledge with you. And so, that was a huge kind of development push for me to be able to see, hey, this is how Microsoft has done it. But I want to back up for a second now. Now that we kind of dive into the SDL side, I want to start with just asking you for a definition of SDL. Kind of what is your definition as somebody who really helped to define what this thing is? How do you define it? **7:40** So I define it as a set of specific activities to build secure software or improve the security of software that are conducted by, executed by a development team and driven by learnings and feedback from the sources of software vulnerabilities. So I think those are sort of the critical things, the fact that secure development or an SDL is driven by actual experience with what results in software that isn't secure. The fact that there are specific requirements or specific activities that make up the SDL, you know, run this tool and fix exactly these bugs, for example. And then the third thing is that the SDL is executed by the developers, not by some outside security team. Those are the 3 things that I think of that make for an effective SDL process or a real SDL process. **8:44 Chris Romeo:** The execution by the developers is such a big deal because when you're talking about an organization the size of Microsoft or other large organizations that have tens of thousands of developers, we know that there's no way we can get to the point where we have enough security people to try and match up with the number of developers that we have. I mean, if you had, say you had 1,000 developers, you'd need, what, probably 100 security people to truly be able to do the work and keep up with them. And so, that whole idea of spreading it across, security is for everybody, is such a powerful concept. **9:22** It depends on the organization and really their culture about how that works. I've talked to organizations trying to create SDLs, and if you have sort of a classic security department or an IT-oriented security department. I shouldn't belittle IT, but a lot of organizations have tended to have their security departments sort of an audit function, come in after the fact and find out what's wrong and make the people who built it fix it. That just doesn't scale. You can't get enough people. You know, you're always too late because if you start at the end, then you're delaying delivery of capability. So there are just a variety of reasons where the only really viable way to deliver secure software is to have the developers design and build secure software. The SafeCode member companies all have processes that really focus on integrating security into development, and that's Very much the way it's got to be done. **10:30 Chris Romeo:** Season 6, Episode 8. Maya Ketcharovsky joins us to talk about container and orchestration security. We brought the issue to Maya about, are containers a security tool? We asked her if she agrees or disagrees, and she gives us her philosophy of container security. I'll throw out a kind of a statement I've heard. I heard somebody say, and I'm curious, Maya, if you're you know, agree with this or you're gonna disagree with it. And certainly happy to hear kind of either side because I don't even know where I stand on this issue. And that is, containers are not a security tool, is what somebody said. And so I'm curious, is that— do you agree with that statement? Do you disagree? **11:15** Why or why not? **11:17** I'm gonna lean towards agreeing, and I'll sort of explain my philosophy here. Containers in and of themselves change nothing in your security model. In fact, if you look at the name of the thing, container, it doesn't even contain from a security point of view. That's a bit misleading already in terms of what it does. Now, that being said, if you adopt the philosophy and a lot of the tools that come with running in containers, things like a microservices architecture, things like a further lockdown CI/CD pipeline, you can actually get significantly higher security benefits than a traditional security model. What I mean by that is, if you're able to lock down your— so before, you had a VM running and you wanted to make a change, so you'd SSH into the VM, make a change live in production probably, and then watch it roll out and see what happens. That's also how you did things like patching, like how you patch things like Heartbleed a couple of years back. Now, if you use containers, you're actually not supposed to change containers once they're running in production. Containers are meant to be immutable. Instead of SSHing in and making a change, you patch, you apply a patch to an existing application, you rebuild that as a new image, and you roll out that image. That rollout has the same canarying, testing, monitoring, all of that kind of stuff, all that tooling, that you have as for any other production rollout you're doing. Any patching now becomes a normal production rollout. What that means is that you can apply a patch at scale across your infrastructure relatively quickly and know exactly where it has and hasn't been patched, which is a bit different from the old model. That's a wonderful blue sky situation to be in, and I've seen a handful of companies be able to actually achieve something like that because you need so many other pieces. You need a CI/CD pipeline that you've— sorry, a continuous integration, continuous development pipeline that you've locked down so that you know what kinds of changes are going in. You need enforcement mechanisms to know that the only things that you're deploying are actually coming out of that pipeline. You need ways of doing what I described earlier, which is a blue-green deployment, which is when you deploy a new workload that, for example, is patched, and you have an old workload that isn't patched, and you move traffic over from the old workload to the new workload, you need lots of these pieces that aren't security-specific pieces. But if you don't have those, you don't get the security benefits. **13:45 Chris Romeo:** So, if I kind of summarize that list, I want to make sure I capture the list of, you know, how containers improve security correctly. And so, you talked about the microservice architecture, just being in that architecture, there's some security benefit in splitting things up. Locking down your CI/CD pipeline, because you've got, you know, with the proper enforcement mechanisms, you're able to push out new versions and then kind of retire the old ones. And then you also talked about kind of patching. So, are there other things that improve security related to containers? **14:21** Yeah, one of the ones I didn't really mention earlier, I said containers don't contain. And I think it's a common misconception that you can't have both, right? People think, oh, I have a container, I can't have strong isolation like I did with a hypervisor or VM boundary, etc. That's true, you can't have exactly the same thing, but you can have other isolation mechanisms that exist, again, in open source, like gVisor, Kata containers, Nabla containers. There's lots of different options out there for providing similar types of isolation. So, as you just said, CI/CD pipeline lockdown, patch management, Enforcement of what ends up in your infrastructure. So being able to actually have a check that says, you know, these containers must meet these requirements before being admitted to my infrastructure. It's what's called an admission controller in Kubernetes. And then workload isolation provided by some of these open source projects. You can get— I guess my top-level message is you can get a lot of benefits for security out of containers. But it's not the container that gives you that benefit. It's the tooling that's been built around containers and/or other practices that you adopt with the adoption of containers that give you those security benefits. **15:36 Chris Romeo:** In Season 6, Episode 10, we're joined by DJ Schleen, and the topic was DevOps: The Sec is Silent. We get into discussing what DJ refers to as DevOps or DevSecOps, Unicorns. I've yet to find an organization where the security people are like, yeah, you know, we feel like we're kind of overstaffed and there might be too many of us floating around here and we don't know what to do. So we're just going to hang out and, you know, in the conference room and do nothing. **16:10** Right. **16:10 Chris Romeo:** I mean, every, every security organization seems like it's understaffed and every functional role is like, boy, we really need 2 more of these, these people. And we have one doing the job of 2 or 3. **16:21** Well, that's the unicorn, right? So if you talk about DevOps and DevSecOps, there's a lot of references to the unicorn. And I look at the unicorn as being, if you find someone who knows development, operations, and security at the same time, that's like, you might as well find a unicorn because it's going to be about as easy to find that as it is an individual who has those skill sets, right? **16:42 Chris Romeo:** Julian Vahent from Mozilla has been on the show with us before. And he had a funny tweet from, I don't know, maybe 2 years ago now. I don't know if you saw it or if you remember it, but he was basically making fun of the DevSecOps name. And he said, you know, hey, DevSecOps, SecDevOps, ops, dev, double sec, and then ops, you know, can't we just call this DevOps with security? And so, that always stuck with me. And I always ask people that are involved deeply in this kind of specific field, because I'm curious on what your take is on that. Do you love the idea of kind of the name DevSecOps, or are you kind of like, hey, it's just DevOps and security? **17:21** You know, it's funny, 'cause over the past 3 years, I've had a love-hate relationship with it. Back at RSA, when I was telling you about being, you know, having conversations with John Willis about it, I remember going off into the trade room floor of the expo afterwards, and there's this one young guy, and he's asking me like, oh, what do you do? And I'm like, I'm a DevSecOps evangelist. He's like, that's not even a word, dude. Like, what are you talking about? **17:47** It's DevOps. **17:47** It's DevOps. It's caused such a— God, it's rattled the industry, right? Because first it was rugged, and then it was SecOps, and then it was SecDev, and then DevSecOps. I always have a slide in my decks now that's like rainbow monkey unicorn pony because I really don't care what it's called, right? It's just programming at the end of the day, but everyone likes putting labels to it. Another interesting tidbit is I met Gene Kim for the first time at GitHub Universe this year, and I got a copy of his Unicorn Project, and he signed it. It's like, DJ, thanks for everything and long live SecOps, SecOps, Sec. And, you know, it's, uh, again, it just shows that, you know, did we create more silos by doing this, um, or are we breaking down silos, right? If we need to label something, um, chances are you just labeled a silo. And, you know, gosh, I, I've gone from the whole idea of DevSecOps to, you know, DevSecOps is the correct way to say DevOps. I think I did a presentation about that. And, and now I just I just prefer DevOps because I think security is silent, right? I tweeted once that I know it's called DevOps, but the sec sells. And it really— like, people can call it whatever they want, as long as they're thinking about developing safer software sooner. That's all that I really care about. But I don't know if we've done the world a disservice by calling it that or if we've called it out enough that it's in people's you know, the forefront of the imagination. Like, maybe in the next decade, it's gonna be called programming again, who knows? Or full-stack development, right? That's what we've always talked about. And wow, now we finally have it, and we gave it 15 names. **19:28 Chris Romeo:** Our final clip from Season 6 comes from Episode 15, where Kim Wutz talks to us about privacy threat modeling. We walk through the Linden Privacy Threat Modeling Framework step by step and So I'd like to walk through the list of categories within Linden. I see one that looks familiar, but everything else, everything else looks like it's kind of some new stuff. And so if we start with linkability, I'll just read— I pulled the list off from the Linden website, which we'll provide as a resource to folks so they can go dive into this a little closer. I will go ahead and just read the description, and I'd love to have you kind of give us some more detail on each of these. **20:13** Yeah, sure. **20:13 Chris Romeo:** some more details behind what this actually means. But when I look at linkability, it says an adversary is able to link 2 items of interest without knowing the identity of the data subjects involved. **20:25** Yes, kind of already sums it up quite nicely. It can be seen as kind of the prerequisite for identifiability. So basically, the more data you collect on one person without necessarily knowing who that is, so when you link all those attributes, you get a more scoped view on who that might be. So you have something that is called the anonymity set, which is a collection of possible identities or persons that might correspond to the data. The more information you have, clearly the smaller that anonymity set becomes. So by linking more information, you would more quickly go to identifiability. But also linkability could lead to attributability, to basically singling out one identity without knowing that identity. So you can all link something to a pseudonym, but you don't know who that is in real life. So it's not identifiability, but you still create a profile. And also it can also be linking data, the same type of attributes but about different people. So for example, when you link information about people who have the same disease, that's also linkability. And that can lead to, yeah, like some more societal harm where an insurance company might use that information to say, well, a lot of people in that area have a higher chance for this kind of disease. So we will ask them to pay more or something like that. So, there are different consequences coming out of that linkability category. **22:09 Chris Romeo:** So, you gave an example of kind of disease as a, I guess, an item of interest. What are some of the other items of interest there? Is it something as simple as like name, address, phone number, or is there something else that you're specifying? **22:24** It can be basically everything or any combination of attributes even. There's not really like saying when you just remove the name, then you're safe for linkability and especially also not for, for identifiability. But it can be basically all types of combinations. You have also something called pseudo-identifiers or quasi-identifiers, which are on their own nothing special. They will not reveal any information. But when combined, they are sufficient to identify with almost 100% certainty everybody in the anonymity set. But it's really hard to state like What type of attributes that could be precisely, it really depends on the data you have and also the additional information other people might have, which is in the current age a lot. So it's not really easy to say it's this particular attribute. It can be, I don't know, your hair color and your size and whatever. **23:29** I've seen an interesting example of this, and it may also fall into identifiability as well. But for example, I've seen some sites, social media sites, that on one hand you were supposed to be anonymous, but on the other hand, if you had an Instagram account or something like that, they would automatically link to it and show photos or something like that. And so people could figure out who you were just simply by connecting the dots, by making those connections without getting your permission to do so. So those sort of fall into that linkability, but also, I guess, potentially identifiability as well. **24:07** There are a lot of examples, like a couple of years ago, I think it was a couple of years, probably more, AOL released a whole list of search queries and some researchers really managed to identify one of the people doing the queries. based on, I don't know, it was some things about her dog and something about her son. And just the unique combination of search queries were sufficient to identify somebody. **24:38 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @appsecpodcast or on the web at www.securityjourney.com/appsecpodcast. application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination. --- Source: https://appsecpodcast.com/marc-french-steve-lipner-maya-kaczorowski-dj-schleen-kim-wuyts-season-six-wrap-up/