Dustin Lehr & Michael Burch - End of Year Recap 2025

The Security Champions podcast is brought to you by Security Journey. We help enterprises reduce vulnerabilities through application security education for developers and everyone in the SDLC. Learn more at securityjourney.com Hey everyone, welcome to another episode of the Security Champions podcast. We have a special episode, holiday episode in for you and store for you today. I'm your host Dustin Lair, but actually there are two hosts with us today because we've got both hosts of the Security Champions podcast with us. Mike Birch and Dustin Lair. So let's go ahead and get started. Mike, how is this episode going to work? Do you want to give us a little bit of an overview here? Yeah, actually, we've done one like this before. It's kind of driving some of the motivation to do this episode. We're going to be looking at a year in review before we head into the new year. This is actually been, and I think one of our most exciting and filled seasons of the Security Champion podcast. And a lot of exciting stuff has happened. So what we're going to do is we're going to jump in. We're going to have a quick little conversation about an episode and we'll be showing a clip from that episode to show some of our biggest highlights and most important things we think we've talked about throughout the year. Or stuff we just thought was interesting. We want to play again, right? So it's our kind of highlight reel from the entire year that we're going to be doing here. Interesting is when we think about this year, it's kind of changed the way, especially a big thing is Dustin you coming in on the team and becoming a co-host with me. Which is, I definitely started the year, right? Because the first few episodes were me interviewing people. That's just because that's before you came on board and we kind of transitioned after that. Thoughts about that feelings. How was that that kind of coming in and like becoming a basically the rest of the main discussion for the year? I was fantastic because I've been a fan of this whole podcast, right? For a few years and I was actually a guest previously on the podcast as well. So very familiar with the format, how everything went. Speaking of which, I did see the recap episode that was done. Was it two years ago? Was it last year? I think it was about two years ago. I thought it was two years ago. And I really enjoyed it. So I'm really excited to get started and kind of go through the clips for the year. Like you said, it has been quite a year, right? For the podcast because it basically doubled in host size. So it's been exciting. Mike, I think the first episode was yours. Do you want to give a little bit of a recap of it and then we can go ahead and play the clip? Yeah. So the first episode I actually interviewed someone here at Security Journey, one of my senior security engineers. And the topic we talked about was the AI threat landscape. And it was a dive into how AI is changing the way we think about security. And the clip that I actually chose to kind of highlight from this conversation. This is a shorter clip. But it's one I think that was really important to talk about how the rest of the year went was about AI and how it affects cogeneration and leveraging cogeneration. So I think it's a great time. Let's pause this jump in. Let's check out that clip. It's definitely an exciting time. One of the things I actually think that I would I think it's going to redefine our industry and appsack to be honest. I think application security and the way that we think about that's going to drastically change. One of the biggest things I've heard recently is like this people claiming that in 10 years people won't be writing code. It would be AI writing code and people reviewing it. I don't know if I fully believe that, but I definitely think there's going to be a sway of that way. I think there'll be AI writing a lot of the arbitrary code, right, where it will build out our unit tests or it will set up our controllers for us automatically based on what we want to do. And then we're in the functionality. I do think there's going to be a shift of how much code is written by people. So it's definitely going to change the way we need to be thinking about application security and where we need to be focusing on educating people and how to approach that entire problem. Yeah, and it's really tough to especially for, you know, probably the newer generation. 10 years from now getting into the industry, because as you said, "Hey, I can write the code pretty well." Let's just say, but you have to tell it what you want, exactly how, within a necessary scope, the exact specifics, the security controls you want in there. And this all goes back to, you know, the SDLC, you've got to gather these requirements. And in my mind, software developers are problem solvers. And this is just another tool that they can use to solve those problems. I think it's going to speed up a lot of processes. But I think with the more AI code out there, we're going to see more vulnerabilities too, because now it's just going to scale really fast and be rampant everywhere. So it goes both ways and then, "Oh, let's use an AI to fix that one," but I just don't see it going that way just on how the technology is based. It's a, you know, probability based token system. So, yeah, it's interesting. One of the things I want to highlight that was so amazing from that clip is the fact that it still holds true today a year later. The idea of how much software is being written by, by actual AI versus people, that's changing. And it's being way more time being spent on the software development design part by the engineers versus the coding part, which is now being taken over a lot by these AI tools. However, we did predict some other things too. The big thing there was that's going to cause some problems. And whether big organizations will admit or not, I think we've seen a couple problems that might have found some of their roots into AI problems. Indeed, I think your crystal ball there was working because I do think that it's played out very similarly, right, to what you guys were talking about. And I'm not surprised. And I'm actually, I'm excited about it. You know, I spent some quite a bit of time with AI myself. And the things it can do is pretty amazing. And I'm looking forward to seeing where that goes. So great clip. Awesome. And leading on, I think that's going to take me right into my second clip that I chose. This one was actually the entire episode was about secure code in medicine. Second interview, I did actually interview another internal person from my company. And the reason I interviewed Adam specifically is he had spent so much time working in the medical industry, working with those different protocols, understanding their security environment. And that's what we talked about. We took a protocol that was very specific about the way the hospital systems talked to each other. And we talked about his kind of history and the problems that it presented in the real emphasis here was. What does security look like in the hospital system and what does secure coding look like in that environment. So let's jump in. Let's play that clip. Let's see what Adam had to say. This protocol has no authentication or authorization or encryption. It is completely plain text. It's basically tellment. And so my partner at the other site at the hospital who I was extremely frustrated with at the time. You know, he has to explain this to me and teach me as somebody who has worked in there. But the only ways they have of controlling access to this are two fold. Number one, they have overloaded it and wrapped it with TLS encryption, which is not standard in the protocol. You know, you're under HTTP. HTTP doesn't know about HTTPS or TLS. But it's really well built into the servers and the browsers and all that stuff. They have to do it as a transparent port, a transparent bridge. These was never built into the system and it still isn't. And so that's the first one is like it doesn't have TLS. It doesn't have authentication either. Like, you know, if you ended up hacking the ultrasound machine and running arbitrary software on it, you could order me all the fentanyl I wanted. And send that off to the pharmacy if you just form out of the message right because it has no you know, by default, the protocol really has no understanding of whether or not this message is from an authenticated center or not. Or what that's authenticated to do is remember it was designed to be this point to point physically wired hardwired trusted connection. And so what he ended up doing is, you know, they they built TLS onto it is kind of an afterthought. And then as a security measure, they limited us to two TCP connections. I couldn't have any more. And so what would happen is we'd open one. We'd fire some messages off. They'd send us an act and like, OK. But they would also expect us to behave a lot like some of their really old machines and still be there listening. And so we just we'd hang up after this and good to go. And they end up putting the outbound messages onto the wire and we'd have a half half open TCP connection still. And so at the same time they were targeting me as a response, I was dosing them with half open TCP connections. These are only have 32,000 of these or whatever the window stack at that time was. These are what they had. And this is all because this protocol that was built in the probably designed in 70s ratified in the 80s was still present in the 90s. And nobody had done anything significant from to at least across the industry to update it. And I'm going to be very hard here. And the truth is is like they had more modern standards like there was hl 73 with fire, which is an XML version, which don't get me started on XML. I think we have a lesson on externally. entities and XtML I learned about. - Oh, we got a handful of those. - Yeah, yeah, I got my gripes against XML, but I'm like at least in like 2010, they were trying to have a new version of this, but the issue is, is severalfold, right? So the first one is, is the medical vendors had no intention of ever updating the software on these devices unless it was killing people. Like what is the financial incentive? Once you ship a cat scare and ultrasound to actually, whatever it is, that's a lot of investment in software that's probably really the spoke used on 20 machines. The dude who wrote it probably spent his entire career on it and then retired. Like it's a huge investment to maintain them. It's number one, a lot of the software and those devices was never meant to be updated ever. Because, too, well, there's no financial incentive because the X-ray or ultrasound or CAT scan works. Number one, and number two, remember the time I mentioned that it takes to validate, you know, or just data entry systems. I'd spend a month on medical record systems. Can you imagine how long it takes to do an X-ray to prove that that thing after a software update still works like it's supposed to? It's a lot of time. And if you're talking about a hospital, right? Like not only do you have to update the software, but that is downtime. So there's no incentive for the hospital network to update their software because that's downtime, that's work, that's labor, it's expensive. You know, beyond the fact that I love just listening to Adam Talk, he's an amazing storyteller. And he's super passionate about everything he says. So I really love just hearing about all his experiences. But beyond that, one of the things that just blows me away is how far we've come from technology standpoint. So like medical technology is extremely advanced. You see a lot of these different systems that can do some impressive things. But then you actually go to these hospitals and you look at the way they're doing business and how the systems they use to track patients and all these other things. And it's so far behind in the protocols and security around that just aren't at the same scale as the functionality that they're at. And it's a really scary thing because to be honest, let's go back to this. This is life, right? This is hospital as they manage patients. You would expect it to be a lot farther along than it is, it just isn't. - Yeah, it's worrisome. I mean, we have actually seen death at this point that have been attributed to some sort of cyber attack, which is just scary to think about. So if anything, it should be motivating, right? In an industry like this where it is life and death, like you said, we need to make sure that we're getting our security right, you know? So, all right. All right, let's look at next. - And the next number three. Yeah, let's do it. One of the next one. This one I met with Roger Grimes and amazing individual over. He's an advocate or he's a evangelist over at No Before. And our discussion was on quantum cryptography. This topic on this idea of a Q-Day, which is basically when cryptography is all broken and destroyed the way we think about it today, due to quantum computing. So let's jump in and listen to that kind of exciting conversation about what that actually looks like. But Peter Schor in 1994 said, hey, you give me these quantum bits. Think about we go from playing chess to maybe like Star Trek chess three at five levels or something. He's like, if you give me these additional attributes, quantum attributes, I think I can solve that like in a minute. So he announces this in 1994, people back it up. We don't, we get our first quantum computers and from my DM in 1999, 2000. They eventually get like two qubits and the first thing they do is take Peter Schor's algorithm and that's what they factor. They factor five and three into 15. Like, holy, it works. It works. They weren't breaking any big crypto, but they went, the math works. This guy's algorithm was real. Since that day, I remember being written about, and I've read about Peter Schor's algorithm in 1994, then I read about, oh my god, it's backed up in 1999. I sort of paying attention, learning quantum physics, following it. So every day since 1994, we've been waiting for the day when we have sufficiently capable quantum computers that are able to break today's asymmetric encryption, RSA, Diffie Helman, Elga Mal, elliptic curve cryptography. Essentially 90% of the world's information is protected by this. Your Wi-Fi router works using it, your password is protected by it, your multifactor authentication, uses it, your Visa card, people go, hey, does this mean that they can crack Bitcoin? Yes, but let me tell you what, they're gonna be able to crack the international banking system in every Visa transaction, cryptocurrency. Is it tiny, tiny part of that? We're gonna have much bigger problems. So since then, there's been this race that we have this quantum susceptible cryptography. Again, mostly asymmetric, but actually impacts symmetric cryptography, AES and other things as well. You have to double your key size to get the same protection, but it's easy. I go from AES 128 to AES 256 and I'm protected. Easy stuff. AES and Metric stuff has to be replaced. And so NIST created a contest, National Institute of Standards and Technology, a bunch of years ago, probably been eight years ago, 10 years ago, created a post quantum cryptography contest and said, hey, these traditional classical asymmetric algorithms, once we get, you know, so visually capable quantum computers, they're gonna be able to break it. We need to have post quantum cryptography. And that just means traditional binary regular math, it's not quantum. Is this regular binary classical bits that are able to resist quantum, the PUDESHOR quantum attack if we have sufficiently capable quantum computers. And so they put it out there like 80 people, teams of PhDs submitted 80 algorithms. Over the next year, they said, oh, I think they got it down to like 33 or 20. And finally, a couple of years ago, they actually picked the first five finalists, which always loved some of the finalists, their name Crystal Kiber and Crystal, oh, forget the other one, but they're named after things from Star Wars and Star Trek. Crystal Kiber and Crystal Dylithium, that's it. So I love that. And there's some other ones that got picked. And just recently, they actually picked just yet another one, which was good because the other four or five that they picked were all based upon the same type of math, which is called lattice, the hard problem of lattices. And so a bunch of cryptographers are trying to break it. So NIST said, well, we need to have post quantum crypto that is not based on the same math. And so they just recently selected one that was called HQC, HQC, and that used a different type of math. And so we now have these algorithms. And all companies, all companies are getting ready to do a massive multi-year migration of every bit of software hardware and firmware you have to post quantum algorithms. That is happening. And it has to be, per the government, done before 2030, that five years from now, I think that's drastically too late. I think that we're making sufficient quantum headline, or advance that we could already not, the US government or China, those two main quantum crypto people. One of those could have already broken it, have sufficiently capable quantum computers, and we just don't know it, unless it's hidden or something. And I'm one of the few people that believe that, but I think there's a 15% chance the US government or China has broken it, the crypto, what they call Q-Day, some people call it Q-Day. But if not, the US government says we need to be prepared by 2030, and so this could be a multi-year migration. The US government's been saying, you need to do this for like 10 years already. When I ask people, I give these speeches in quantum, they go, who do you hear is doing quantum preparation? Out of 100 people, I get four hands. And out of those four hands, they go, okay, I had a four guys, how do people, you actually have a quantum project where you've assigned a resource leader and you have resources assigned to this project? All their hands go down. Now, the correlation, I think, that's the best here that we mentioned, we use this phrase called the Y2K of cryptography. One thing that we didn't say in that individual clip that I do wanna bring in from another part of the episode we do say, it's like Y2K, but scarier, 'cause Y2K had an exact date. We knew exactly what it was gonna happen and we could prepare for it. Well, Q-Day, the day that all quantum computers get strong enough to break current algorithms, we don't know when that happened, who's gonna do it first. We don't even know if it's even happened yet and maybe nation states are keeping on a wrap. We have no idea. So we should be preparing for this now 'cause it's a really scary thing that's gonna be hard for us to prepare for. Isn't it interesting where, like, we know something like that is coming, right? Just based on the science and all the research that's been done so far, we know when that's coming. It's just a matter of time when it essentially comes to market, when there's products, et cetera, that are actually gonna make it usable, right? By more common, the commoners, right? As opposed to the scientists. Which is some similar that happened with AI, right? You had a lot of research in AI and it was sort of the same thing where everyone was like, "Hey, this will happen at some point, just a matter of a company bringing a product forward, that's going to act. be useful to the end user. So anyway, so that's what I find very interesting. It's like we know this day is coming. We don't know when it is, but it's also very hard for humans, I think, in general, to prepare for something like this. If it's not right in front of us, it's kind of like, I don't know, it's just thing. It could happen far in the future. And I see this a lot in cybersecurity as well, with-- it takes an incident in a lot of cases to sort of get with it, right, and implement the best practices that we need. And I see something very similar happening with quantum computing as well. Yeah, absolutely. I think the biggest thing there is, unless it's directly in front of you, like you said, people don't react. And this is one of those things that isn't going to go well if you wait till it for it to happen. So very interesting episode. That was a great conversation. Well, on to the next one. So this is where things changed a little bit, OK? Because I joined Security Journey. I was invited by Mike to start hosting, co-hosting, right, the Security Champions podcast. So we had a nice conversation actually between you and I. And I do remember this because we talked about the SOMA cube experiment, right? And we talked a lot about motivation in intrinsic, extrinsic motivation. We were talking about using nudges and so forth. So I actually have a SOMA cube in front of me. This, believe it or not, was put together-- I put this together, OK, this morning. And then when I was essentially preparing for the episode, I was like, hey, when I show it, I'll show a completed cube. And it like fell apart in my hands. And I was like, great. So I didn't have time to remake it, but I do have all the pieces here. You'll just have to trust me that I was actually able to complete one of these. But let's go ahead and play the clip. And to start this conversation, I actually have a story I want to talk about. I've been doing a lot of talks really recently. And one of the talks that I give is called Code to Culture. And as part of my primer to get people kind of in the idea of what motivation is and how it works, I give a little bit of story about self-determination theory. And some of the people that wrote the book on it back in the day. Now, as a quick intro to this, we're going to talk about intrinsic and extrinsic motivation. Intrinsic motivation is things that are basically derived for yourself. Your self-motivated do something based on your inner drives versus extrinsic motivation is things like reward systems. Do I get a badge? Do I get money? Do I get a vacation time? Whatever thing that we can throw at somebody who say, hey, do this for us. We'll give you a reward for it. So it's different between inner and outer. So for this, back in the day, there were a couple of psychologists. And there was Edward Desi and Richard Ryan. And they did an experiment with something called a Soma Cube puzzle. What a Soma Cube puzzle is. It's these pieces of a cube that have all taken apart. They have different types of shapes. And you have to put them back together to make the cube. That's all you have to do. And what they did for their experiment is they had a group come in and they paid them. And they're like, OK, you guys have an hour, see how many times you can solve these, we'll pay you for your time depending on how you perform. So they got paid to solve the puzzle. That was the reward for solving the puzzle. They win, and when it's super motivated, everyone knocked it out. It was a great experience. And they bring in a second group. There's no money for all this time. They made it a game. They're just like, hey, go in, compete, sue, can do it the best. They had the people go in, and they were engaged. They were competing. They were trying to beat each other. Super engaged with that, right? And then there was a third trial. And in the third trial, they put both groups back together. And they put a bunch of stomach cubes on the table. No instruction just left. And everybody kind of went over and started playing with it. But the people who were paid the first time quickly started dwindling away. And they started going off, and they started reading magazines or doing other things around the room. But the people that competed the first time, that were just doing it and weren't paid to do so, stayed, and they kept doing it. And they kept that competitiveness. And some of the things they inferred from this is if you're able to build up that intrinsic motivation, that self-motivation I want to perform, you can get someone to do something with the extrinsic motivation. But if you can't tap into that intrinsic motivation, it's going to be short lived. You have to build the want and desire for someone to continue to want to do that. So they wrote a book about intrinsic motivation and self-determination theory. And it's one of the big things that I really champion when I talk to a lot of people about how to get developed as a chain behavior, is talking about giving them the ability to have three main things-- autonomy, competence, and relatedness. And we can kind of dive into those. But Dustin, first thing, right off the bat, hearing that story, what are your thoughts on that? I think that is awesome. And that aligns with a lot of things that I talk about. The way that I typically think about motivation is that the intrinsic motivation that you're talking about, the desire to do it for the sake of doing it, because you actually care about it versus caring about something on the outside, some sort of reward or something that you might get out of it. That would be extrinsic motivation. The way I always think about it is going from-- is to maybe start with extrinsic to sort of get people in the door more or less. But then show them-- I mean, what was interesting about this puzzle is it's intrinsically challenging. There are intrinsic traits about the puzzle itself and the teamwork aspect of working with other people and so forth that go beyond just, hey, maybe you get a piece of pizza if you solve it or something. That's sort of more of this extrinsic thing. However, to get people into that intrinsic mindset, I think takes time. And sometimes you have to start with extrinsic motivation. Hey, if you do show up, there is something in it for you. Maybe you don't know what security is all about. And let me just share what I'm thinking about. Maybe it's like a training or some sort of a webinar or something. Maybe you meet every month and you talk about this as a pretty common model with security champions. Like you meet every month, you talk about some sort of security related topic to hopefully help people learn and so forth. Maybe to get people to start showing up, you need the pizza. Hey, come get some pretty food, whatever. But then you deliver, you bring the goods, you actually during the talk, you share things that are relevant to them, that are interesting to them, that peak their curiosity and they go, oh, I didn't know that. And they start to get interested more intrinsically. So that maybe next time they show up, they don't care about the pizza anymore. They start to care about the topic for the topic's sake. All right, well, I like how we talked about where lasting engagement comes from as well. I mean, I just, I appreciate, you know, you, Mike and all of the insights that you bring to the table. So I definitely appreciated that whole episode. Any thoughts that you had? No, absolutely. And to be honest, I love you in time. So I mean, you get on and do our own episodes sometimes. We have great conversations. So love those conversations. And to be honest, I go back to, I believe security is a 99% of human problems. So whenever we can talk about human solutions to it, love those conversations. Absolutely agree. All right, and then we had my first solo episode essentially. And I invited my longtime friend, David Kusarok, who is just amazing. Okay, he is, I would consider him to be like the abstract strategist. Okay, he's got so many things going on. And he shared some insights, right? So he basically laid out a playbook, right? In terms of bringing people in. And I think that's one of his superpowers, his ability to connect with people across an organization, make people feel like they have that ownership, right? Over, over, absec or security in general. So let's go ahead and play the clip. For your team strategy, you define as a team, what are all the building blocks? And so you already start, when you start building a team, you don't start off and say, this is all the stuff we're doing. You kind of, I think you back off from that a little bit, you find out you interview people, and I kind of talk about this in the book, where one strategy is to understand all of your stakeholders. And that seems like a lot of work. I mean, one company I interviewed 90 people to understand where the team was, and then took it in a direction that it wasn't going in before. I think with your team, when you go to your team, they have to know that, first of all, my manager, my leader understands the company, and they understand the business. Then you say, I want them to know that I have something I want to contribute. So when you start talking about your strategy, you create these building blocks. Now sometimes you can categorize them in list-like categories. I don't think that's as important as listing out the things that you do. And one of the exercises I do with the entire team is, hey, let's sit back and think of the dream team. What's the, if you had all the money and all the resources you would need for an AppSec team, what would you be doing? Security champion program, SaaS, S/C/A, bug bounty programs, red teaming, all these things that you do, it's, if you could probably come up with a list of 50 to 60 things that you would want to do, but you would also include things that your team needs from other teams. So maybe you want some threat intelligence, but you don't want to own and operate the threat intelligence so you want to. collaborate with a SOC team, for example, it might be one example. Then you get, so the team is all contributing to this. So you already get from them the sense that, "Okay, I'm going to be part of what we're going to be doing." Then you take those initiatives, you prioritize them according to the business, and I usually do that with team voting. Now, as a manager, you're responsible. So at the end of the day, you might adjust that slightly, but typically the team consensus is very helpful to set that priority. Then you set ownership of who owns what. I usually start with who wants to own what. There's a lot of complex ways you can pull the votes in and stuff like that. But at the end of the day, most of the time, every person should own one or two things that they're really passionate about. Maybe one or two things that they have to get done. They're not as passionate about, but needs to be done. Then you get a timeframe and they follow that priority. They're responsible for pulling together the strategy to implement that initiative. Meaning, I pull the requirements together. I run POCs, I do the other things. I'm also responsible for managing the budget, understanding how much money I need for that. Now, they may come to me and say, "Okay, David, I figured I need $150,000 for this X, Y, and Z thing. Great. We'll put that in the budget." I'm still owning the budget in that respect, but they're the ones that are determining the quantity and whether and working with the procurement team. I want them to have that experience. Then they're responsible also for designing, "Hey, here's all the metrics that decide whether or not this particular initiative is actually working. Are we moving the direction that we want to move in?" That's again where you provide this atmosphere of you responsible, you own it. Here's how you're measured and here's what get at the end of the day, here's what we should have. My job as managers to hold them accountable to them. Their job now is to mature that program and reduce the risk of the company as quickly as possible. That combination of ownership and responsibility and accountability, all those things fit into having what I call a very sticky team. Sticky team means I'm less likely to leave that team because I know that I'm valued. I contribute to something that's really awesome. Hopefully I'm getting paid well for that. All those things combine to create that sticky team that you want. I loved his stickiness. We talked about stickiness through the entire episode. Then he does do a lot when it comes to showing metrics and making sure that leadership understands the importance of what he's doing. This is what I really appreciate about that episode. By the way, feel free to check out the full episodes here. I think Mike, it would be good for us to post these as part of this episode as well. Oh yeah, absolutely. I think one of my favorite parts, David, such a great individual, met him a few times, especially curious to you and other type of engagements. Love his perspective. I love the autonomous ownership idea of enabling that engineering team. It's the buy-in. That's stickiness. I think some people have a lot of problems with or even just thinking about his often we think as security, what can I get someone to do for me? How can I get them just to own this and be part of it? Such a great part of that clip. For sure. Next I wanted to invite Jacob Salassi on the show. He has a very unique perspective and approach. He led product security for Snowflake for many years. I think what I like about him is he's very pragmatic with his whole approach. He doesn't try to pass everything off to the engineering team when it comes to security. I would just call him empathetic. He has a lot of empathy for what the developer is going through at any point in time. He talks about in this clip specifically, excuse me, how interesting. Engineering has to own essentially the product end to end. The testing, everything. I think the biggest thing that he says here, which you'll see in a minute, is he doesn't like it when people suffer without agency, which essentially means, I don't know, I think about taxation without representation. It's just kind of go back in history here. It's a very similar concept. It's like are you making people pay for something that they don't have any control over? Let's go ahead and play the clip. I think one, engineering owns test. In any engineering organization that claims they're doing test, it had better be also making sure that the things you just said happen. They're not doing test if they're not. You're describing a search space problem. The question I would have is how do you know you're doing a good job of establishing the search space for tests? How do you know you've done a complete job of defining all of the positive and negative scenarios? I'm going to argue, you have to do all those things, but what I'm arguing is that the engineering team needs to own it in the sense that they have to feel the pain when the test fails. It can't be that some other team, which is a pattern I've seen is where their engineering teams don't own test. They don't even necessarily write tests. Someone else writes the tests. For example, you may do no unit testing whatsoever. There is another team who exhibits all of the good values that you just described, but they write the integration tests. When it's broken or whatever, hard, they need to solve that problem. It's never the developer who has to solve that problem. I think that type of approach doesn't make sense to me. I don't think it aligns incentives, but I do think what you said is true. You're not doing test if you're not being rigorous about how you set the search space and how you know how completed it is. I'm not talking about code coverage. That's something else. I'm talking about functionality coverage. I think that's very important. Which would maybe include non-functional requirements there too. Right. Exactly. I'm assuming. What does that mean in terms of an org structure then? What does it, you say, engineering should own test, but does that mean someone on the same team, like Scrum team? Would you go that far or is it like there's a separate QA group that maybe they're loaning QA folks outright to the various development teams? What does that look like in your mind? I don't know if I would torture a dozen. I would say everyone knows what it looks like when incentives aren't aligned. That's when someone is suffering more than the person who created the problem. At any time, if you know the problem started here and there's a disproportionate amount of suffering along the chain, you know your messed up. That's all I can tell you is, I don't know. You figure out your org structure. I don't think it's that hard. I think, yes, probably within a team who has an overall incentive to ship a high quality product, let's imagine that exists in the first place, but like, okay, like probably a decent place to start is within the team. But, you know, we can talk about this more in other contexts. Like, I don't, you know, you can stick someone in a team who does test. Does that mean the developers not just going to treat them poorly and not give them any feedback? You know what I mean? Like, it doesn't prevent any of this perverse non-incentive stuff from happening. So it has to be not only that the team is in a way that it's small enough and everybody has the same incentive, but like, it's kind of like democracy, which think about that what you will at this moment, but like, you got to have like checks and balances and everybody needs to share in the suffering. If you don't suffer, then you don't improve. And so I would, I just, when I look forward, I look for disproportionate suffering with people who don't have agency, like where they're suffering, there needs to be agency. And if they're suffering without agency, then that's bad. I appreciate his perspective. And again, he's got a very unique approach. There were a few other things that came out in that episode that I really appreciated as well, like his approach to threat modeling. He tried to automate the entire process. And I think this was met with a lot of success at Snowflake. So I actually wrote up a whole article with his help. It was a blog post about the episode. So that would be a good thing for you to check out as well. Many thoughts you want to share. No, I think it's great. I think the understanding ownership, right, and understanding the, like, I actually have to maintain and be responsible for my stuff from me to actually be invested in it, right? Like I think the highlight there is like separating out QA all of a sudden, if you take that away from my responsibility or my purview, I have no agency, right? So I think that's a great episode. For sure. So next we had either Ben. So this was also a very unique episode. She works for Microsoft and she had a very unique approach when it came to connecting people's identity, essentially, with cybersecurity, right? She wanted to encourage people to see themselves as contributors to security in general, whether you're developers or just in a position that's outside of the security industry. So she also talked about connecting emotion, right, in terms of the way that you express certain things, right? So making sure you connect with people's emotional side, it kind of reminds me of like Ted Talks, right? Like you may not remember what they said, but you remember how they made you feel, right? And I think it was a very similar approach. So let's go ahead and watch the clip. I'd like to clarify what I mean by identity layer education, right? It's one thing to deliver information, right? This is pushing content and then you're hoping that something sticks. The challenge with that is this is the traditional education lecture. method. The challenge with that is that you are throwing something and there is no soil that you know you are basically throwing the seeds but the soil is not fertile. How the soil becomes fertile is through emotion. That is when you activate some sort of an emotion within a person, that's the soil that they would actually be more willing to absorb that learning. So whether that's why when you deliver a talk or when you deliver content like Netflix or whatever kind of engaging content, there is suspense, right? There is freaking sadness, there is something funny, like humor. This is essentially what attackers also use to trick you into clicking a fishing email, right? They create urgency, they create fear. Like it's always emotion, that like because when a person acts from emotion, they kind of say like when emotions are high intelligences low, because you are activating that intrinsic intuition kind of in your brain that to act. So that's what I'm saying. There are some of these techniques that can be used for good. It's one thing when you, if I'm a developer and you give me like a lecture on cross-size scripting or whatever, I'm gonna be like okay cool, cool, I'm gonna be eating my popcorn and probably forget about it by the end of the day. But if my request, my poor request is broken and I can't merge that code because that and I watch a 30 second video right there and then of why cross-size scripting is bad, here's how to fix it. Guess what? I'm frustrated, I'm interested, I want to watch this because this is gonna help me achieve my goal. So here's where I've attached to emotion. So this is just one example obviously of how we activate a human brain through emotion. But the other thing that I want to mention is what I talk about identity change. This isn't simply pushing information, right? We enable developers or non-security people or empower them to think of themselves and who they are fundamentally differently. So when it comes to identity shift, I think what's important to understand is there is one thing to deliver information to someone, right? Who perceives themselves, I'm a builder. So this isn't something that I really need to know but okay it's great information. So then you've delivered this information, you've given them this one piece of information. But when you actually empower them to view themselves differently and we're talking about people that are not security people, there are builders, developers that are just regular everyday business users. When you empower them to think of themselves as defenders, as my actions, my everyday little actions can have a massive impact, not just on my organization but on the community. Then you're not just delivering information. You're giving them the very fabric that they need to operate from. So then they pursue and they seek out the right information and do the right thing from operating from a different identity because now they're viewing themselves as oh my gosh, you're not just telling me I need to do this, right? I need to do it because I, my actions matter. I am a defender. It doesn't matter what my title says in my company. I am a front-light defender. All right, so the other thing that came out in this episode that I really appreciated as well was building your own identity. Again, the whole thing was sort of about, it had this identity theme to it, which I really appreciated. But how to get sort of your own personal brand out there, how to make sure that you were speaking in a way that's genuine, right, to your own identity, which people I think identify with. I'm really going to town on this whole identity thing. So anyway, so I just really appreciated that episode. Emotional education. Yeah, emotional education. I think that's such a big part of it going way beyond just understanding the facts or memorizing things or just encouraging things, tapping into that emotion so it sticks, like such a powerful thought, especially as an educator. I really appreciate that. For sure. Let's go to the next episode. So Ariel Shin has a very unique story because she was actually a breaker. Okay, she was a pen tester. And what I loved about her story, which came out on the episode is she wanted to shift over to be part of the solution, right? She didn't just want to sort of drop these nuggets and say, oh, you have issues in your environment. Here they are. Good luck. Goodbye. She really wanted to figure out what is the best way for me to jump in and beyond the other side of it, right? More on the solution side. And one thing we covered, which I thought was really interesting was this concept of glue work, which I had actually never heard of before. But it clicked right away because the whole idea was essentially you have this extra sort of work that is required to sort of keep teams moving, right? Keep teams efficient and so forth. And we talked about how this very much applies to application security in general. Not only that, we also talked about the fact that app-sec teams do act as glue in a lot of cases too, because they have visibility across many different teams and many different business verticals. So, really appreciated this episode. Let's go ahead and play a clip. So there's actually so so much to talk about when I'm talking about glue work. But really that term I believe was coined by Tanya Riley. She has a book and a couple of books, but also a blog, where she details this noidea.dog/glue. And when I first read this article, it was mind-blowing to me because I was like, I can't believe a lot of the work I've been doing was glue work. And one thing that they talk about glue work is they can also refer to as non-promotable tasks, especially as a nice see. You do a lot of the work to kind of bring the team together. That's maybe cleaning up the documentation or kind of helping around with some of these team meetings. Her blog goes into a lot more depth of it, but at times it's you pick up these tasks that are needed to keep the team functioning, but don't necessarily demonstrate a clear impact in terms of like your engineering work. And so it can be dangerous at times, especially earlier in your careers in IC to pick up too much glue work. But at the same time, a lot of our work is glue work, where especially as abstract practitioners, we're bringing people together, we're glowing teams together, we're finding out how to bridge it. And so the way I've interpreted glue work is really that's these broader set of skills that you can have. And there are moments in which it can help you really kind of build that social capital needed, bring together groups of people to get work done. But there are other times where spending too much time on it can actually be detrimental to your career because it distracts you from some of that imminent impact that you need to land. So that's fascinating. I am curious if as a manager and as an absec leader or even just an engineer, if more of the job is glue work and if it is perceived as more beneficial or productive to focus on that glue work. Does that make sense? Like you were saying, as an IC, perhaps spending too much time on glue work is not a good thing. But is there more room for working on that as a manager as an abstract professional? I think it depends. It really depends on your kind of how you deliver impact as a manager and that really differs company by company. And so there are some managers that will get rewarded for doing a lot of that glue work and maybe they'll show up in some of the qualitative measures. Whenever they have a survey, do you feel like your team is a well-functioning team? Doing a lot of that glue work will show up and your manager will then get rewarded. But there are other times where that doesn't show up because a manager is measured on different things such as technical depth and breadth where they want that manager to be a lot more technical, a lot more hands-on. So that means they're the ones shipping some code at times. That's not going to be the manager that you want to be doing a lot of glue work to an extent. Can you describe maybe in more detail what is considered glue work? So shipping code is not glue work. What is glue work? So I think maybe I'm also conflating a couple of terms of I really see glue work as some of the tasks that get missed. And so on a team, writing good documentation, cleaning up documentation, that would be considered glue work. It helps your team become well-functioning and work together. But it doesn't necessarily land impact for you alone. So when we talked about abstract as glue, we had just kind of rephrase. It was a bit of a catchy title as well of some of the ways that we have abstract come together to bring together different parts of the org and all of the collaboration that we do in order to kind of move an agenda forward or move like different cultural pieces or programs forward. I see. So this kind of aligns with something I like to talk about and that's that there's a lot of visibility. that the AppSec team has across different teams and silos, and even like business verticals, where we can help connect those dots, right? If there could be certain engineering teams that don't talk to each other that are building similar things as an example, or even just, hey, there's a whole project in this other business unit that's unaware, right? Of another project that's very similar in a different business unit. And since we have that visibility, we can kind of connect those dots and connect those teams and say, hey, did you know that this team is actually working on this? No, I didn't. Well, maybe you guys should talk because it might be more productive to work on it together instead of separately. Is that considered glue work? Is that kind of what you're talking about? - That's exactly what I'm thinking about as well. It's really that having that visibility within the org and like gluing together different pieces of the org, and that skill is something that AppSec folks get really used to because we work with so many different partners, we build so many different relationships. We're not just about like getting the work done or enabling people really quickly, but also building strong relationships that we can lean on again and again. - All right, so yeah, like I mentioned, we covered the fact that AppSec does act as that glue cultivating those cross-team relationships, even sharing things. This has been my own personal experience leading AppSec teams as well, where you just, you learn things, right? You actually go out there and you talk to different teams and you find out where there might be overlap even, right? Like this team is working on something, this team is working on something similar. Do they even know that, right? So you sort of become that person that connects others as well. - I always love hearing from offensive people when we're thinking about defense and the way we build. I think that bringing that perspective of someone that hasn't constantly been in the defensive world is always so powerful. - Yeah, and that's not me. I mean, I've been a defender. I've been a builder and a defender. Okay, I had to learn certainly how to break, but I just don't come from that world and that's what I really appreciated about Ariel's episode. So let's go to the next one. We had a pretty major event that this next episode was leading up to, Mike, I'm gonna go ahead and let you speak to this. - Yeah, this was the security champion summit. It was such a great event that we put on this year. And the idea was to bring together a bunch of people that love and are passionate about security champion programs and have people come in and share stories, create community, have conversations about what works, what doesn't learn from champions and such an amazing job of all the people that came in and shared their stories and made this such a successful event. So really excited to share this clip with you. (whooshing) - So I wanted to continue the conversation. The first part we really talked about what it took to bring the whole thing together. I wanna talk about the actual event itself. How did it go? What were some of the highlights and so forth and then maybe future plans as well. So Mike, what stood out to you? - Well, I think one of the biggest things I would say that stood out to me is, I hear I'm gonna do a call about how it went to be honest, is how many live participants we had on that day one. We were close to 250 people that logged in that day to join us live on day one. The massive adoption, like that was a phenomenal join in, really, really inspired by that. But what I also took away from that that first day, right, is it wasn't just, and it took a minute too. So here's one thing I will say is, is we set up the session so people could have discussion as the sessions went, right? At the very beginning, right, we did our kickoff call, got through low tactical difficulty, got everybody on the same page and we started launching into keynotes, right? And at the very, in the beginning session, I think everyone was kinda like holding back and cautious and not sure they wanted to gauge. Dustin, you did a great job of like, I know you're there, I'm gonna keep putting information out to what do you guys talk to me? Like you saw that throughout the event, right? That was a key part to it. And then it was like a wave broke. And then once that wave broke, it just kept going where that first person made that comment and they joined in the conversation to run a session and we started engaging. And then it went from that, they're just listening to someone talk to people were having conversation live with us, with other attendees, with the speakers that were speaking as we went from session to session, it became this interactive experience that we were able to have conversation while we were having talk. And actually I think that's an amazing value that you don't get from a live conference, right? A live conference, I can't be sitting here chatting with you. Like, hey man, are you saying you grew that? Like you can't do that, right? So I think that one of the engaging parts that I thought that I took away from that first day is it took a moment, but everybody really wanted to be talking about everything that was happening as it was happening. There was a lot of value in that part of the conversation too. Yeah, I think like anything, especially if you don't know people very well, well, you're going to be a little cautious, right? You're gonna kind of dip your toe in a little bit. You're like, what is this all about? What are these people all about? Are they pushing an agenda? Are they trying to make a sale? What's going on here? But I think, you know, what we did that helped people feel more comfortable is we continuously invited people to engage. You know, and I go through this a lot in terms of the presentations that I'll do more in a live audience, where if I would like to request someone's feedback or whatever it is, audience participation, like, all wait, I will wait. You know, you've probably seen speakers go, does anyone have any questions? Okay, no questions, great. You know, let's move on. I don't know, does anyone have any questions? I know you have a question, all wait. Let them sit in that silence. I will sit in that silence. And then what happens is it gives people time to collect their thoughts. And then they're gonna speak up. And it happens almost every time. So I think it happens every time. I said almost every time, but I'm going to say right now it happens every single time. So I think it's about giving people the space, right? To collect their thoughts, but also continuously encourage them. Like, it's okay, you know, not everyone has this perfect, right? Like, you don't have to come with all the answers. If you have a question, go ahead and, you know, share it with us. We can all learn from each other. I can learn from you as well. Maybe that's the situation I haven't run across. So that's what I think we did. And I think it created an atmosphere that people did feel comfortable, right? Speaking up, but it took a little time, you know, like going back to the human behavior thing, right? It's going to take some time for people to sort of warm up and get comfortable to do so. (dramatic music) Yeah, we definitely call this summit a success. Okay, 250, like this is way above what we expected in terms of attendance and participation. So I just, I don't know, I think it was one of the highlights of the year, for sure. And then this episode really did a good job of kind of diving in behind the scenes as well. That's why I really like this episode because it takes a lot of work to put an event like this together and not everything goes perfectly, like every time, right? Like I think we even referenced Jurassic Park in there, you know, if you open any theme park is gonna have major issues, right? And I think we experienced that as well. But it went well, right? It all just to kind of bring that one home. It all ended up really well. All right, so the last episode, besides this one that we recorded this year, was with a friend of mine, Mark McMillan. And he runs the security champions program over at Rocket. And he brings so much energy and passion into this space. I had to have him on the show. He just did an amazing job. He did an amazing job on the episode. And he does an amazing job in general to lead the security champions, right? Like I think this goes into something I say all the time. And that's if you want people to have fun, right? During your program and get involved, you have to lead that. You have to be the one that brings that passion and fun because people are gonna look to you, right? And they're either gonna go, "Does this person really believe in this?" Or are they passionate about it? And if they are passionate about it, people jump right on board. So we talked about using the carrot version of the stick. Anyway, let's check out the clip. (whooshing) - Let's take your example. Somebody clicks a fishing simulation. All right, so now there's probably some sort of remediation for them or maybe if it's your company, they've clicked three fishing simulations in a row. Something like that triggers some sort of remediation. How do you approach that remediation? Because the remediation itself doesn't need to necessarily be a stick, not at all. The remediation could be a game. You bring a game to somebody. So you know what, we're gonna sit down for 15 minutes, we're just gonna play a game. I know there's plenty of games out there that involve cybersecurity or cybersecurity awareness. You could just do that. It's all about the approach that you take. So let's just say, say the approach that we're gonna take, somebody clicked on the fishing sim, they're a repeat clicker, we need to get them an education. The best way to get them that education is in person. So we're gonna say, we're gonna meet up with you and maybe a bunch of other, maybe five, 10 other repeat clickers. We're gonna get you in a room. All right, so what's your approach? What's your approach when you get in that room? Are you gonna start up a slideshow and say, here's what you need to do. I'm gonna lecture you, do this, do that, do this. That's the stick. That's the stick. That's going to make people automatically feel shame. They've done something wrong. They, they, they're stuck in this place with you until you're done. They're really just waiting out the clock. That's the stick. Um, and the stick can manifest in other forms too. It could be, uh, you clicked on three fishing subs. You're gone. You're just simply not in the company anymore. Um, that could be the, the, the stick. We are shying away from that big time, big time. Um, at least in my opinion, that's, that's the wrong approach. Uh, is, is the punishment approach. Now, the approach that I take, the carrot is you get into that meeting room. Same example, you get into that meeting room. Let's have some fun. Let's have some fun. And that all starts with the person who's doing the presentation or, or the, whatever remediation training that is their approach. When I go into a meeting like that, I say, I'm smiling. I'm happy. I want to see these people. I'm so glad because they're my clients. These are my clients. Hey, if I'm a, if I'm a banker and I'm not happy to talk to a client, who's going to give me money, um, there's something wrong. Uh, if I'm a information security awareness professional, a cybersecurity champion leader and I'm not going out and happy to talk to my clients, there's something wrong. Um, so that's the carrot you get in there. You can even have the same training content, the same slideshow. Maybe you have examples of, uh, phishing emails where you call those red flags. Just don't lecture to them. Be like, you know what? If you can spot three of these, if one of you can spot three of these, I'm automatically going to give you points. I'm going to be so proud of you. If every one of you can spot one red flag in all that we go through, I'm going to shout out to your, uh, your director. I'm going to shout out to your director and say, Hey, this is not a problem. Area. Whatever the approach was that got these repeat clicks, we figured that out in this 30 minute meeting of this one hour meeting, um, you want people to feel empowered by the end of that, not lectured, not beaten down, empowered to go out afterwards and do the right things with regards to not clicking on a phishing email, despotting those red flags to, to training their minds to just have muscle memory and see those red flags everywhere they go because that's the future. And then, and part of that also is, is relating to them and, and, and helping them understand that this is the future. Um, I often say, you know, my mom's not the best at, at understanding cyber security. And sometimes it's tough to get through to my mom. Um, we all have people like that in our lives. So if you can make it relatable, uh, it's, it's a very, very good thing. Um, if I'm talking about passwords, it's not phishing. When talking about passwords, I say, yeah, I had a email account back in 1998. And man, was my password bad. You know, I, it was the, the infancy of my use of the internet. And I didn't know any better. I had to teach myself these things. So now you can rely on me to help you teach those things. You have a level up. You have a, a hand reaching out to you to, to pull you to the mountaintop. Um, that's the carrot. That's the carrot. And it takes actual caring about these people. It, this can't just be a job to, yeah, we're here to make money. We're here to do all that kind of stuff. Um, but the carrot is all about understanding that it's for the people. That's it. You don't want to alienate them. So I really, I liked through the whole episode, the emphasis on building trust, right? As well like if you're going out and shaming people, if you're using the stick, um, it just, it, it doesn't buy you any points as a security team. And it basically makes it so that people are, are afraid, right? They live in fear, right? They're afraid that they're going to have to do some more training or something else. It's going to take up a bunch of time because they misclicked a fishing email in an honest way that they could have learned from, right? So there's missed opportunities that I think Mark has certainly tapped into a way to sort of flip the script and use those, right as opportunities, right to teach people, but also to get them involved, right as champions or otherwise. Yeah. I love the idea of shifting from the idea of fear and punishment to like, opportunity and education, right? Like it's a different mindset. And when your security team has a different mindset, everyone else in your organizational feel it. You'll be more approachable. It'll build better relationships, right? Instead of the, oh my gosh, no, the security people, right? The dread and doom doom that we often bring with us. So, uh, yeah, powerful episode. I'm 100%. So that, that was the year. And I think it was an amazing year for the security champions podcast. I'm really excited about next year. I hear Mike that you're going to be jumping on a little bit more often and helping to cohost. So I'm excited about that. But otherwise, um, yeah, any, any last words, Mike, that you want to share? No, I want to thank all of our guests for the time they came and give to us. The one thing I think that's, that's not emphasized enough is people don't just usually show up and wing it for these like people prep. They think about these topics. They've spent years or time, a lot of time dedicating to these, this information that's sharing with us and they're freely giving it to us here. Right? So huge thanks for all that, that those, that our guests have provided. And thank you for all our listeners, the jump on and listen. And I do dedicate to, uh, I'm going to be jumping in a little bit more coming in next year. I'm kind of excited. And I'm going to try to kick us off here in January with our first episode coming in the next year. But such a successful year. We've done so much, so many great conversations, um, really excited looking next year. For sure, I also want to thank the team at security journey as well. Right? Chris, our video editor, Susan, Ashley, for all the marketing work that they do for the episode, um, Adam, I mean, it's just a great team. So it's been, it's been great joining security journey. And I'm looking forward to next year. So I think with that, we can go happy holidays, everyone. Hope you have a good holiday season. And we'll see you in 2026. Security journey is an enterprise class secure coding training platform with lessons that are built on learning science principles to deliver long term measurable results. Learn more at securityjourney.com.