Dustin Lehr -- Culture Change through Champions and Gamification

Dustin Lehr, Senior Director of Platform Security/Deputy CISO at Fivetran and Chief Solutions Officer at Katilyst Security, joins Robert and Chris to discuss security champions. Dustin explains the concept of security champions within the developer community, exploring the unique qualities and motivations behind developers becoming security advocates. He emphasizes the importance of fostering a security culture and leveraging gamification to engage developers effectively. They also cover the challenges of implementing security practices within the development process and how to justify the need for a champion program to engineering leadership. Dustin shares insights from his career transition from a developer to a cybersecurity professional, and he provides practical advice for organizations looking to enhance their security posture through community and culture-focused approaches.

Links:
"Maker's Schedule, Manager's Schedule" article by Paul Graham — https://www.paulgraham.com/makersschedule.html

Never Split the Difference by Chris Voss & Tahl Raz —
https://www.harpercollins.com/products/never-split-the-difference-chris-vosstahl-raz?variant=32117745385506

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Transcript

Chris Romeo: 0:00

Dustin Lehr transitioned from a 13 year career as a software engineer and application architect into cybersecurity leadership. With experience in retail, DOD, and video games, he fosters collaboration between dev teams, engineering leaders, and software security advocates to design engaging security programs. Currently, he's the Senior Director of Platform Security slash Deputy CISO at Fivetran, and the Co Founder and Chief Solutions Officer at Katilyst Security, focusing on building security culture and champion programs. He also co leads the Let's Talk Software Security remote meetup. Dustin joins us to discuss the perspective of security champions from a developer's Exploring what makes a developer champion unique. The motivations for becoming one and the benefits of participation. We conclude with insights into effectively implementing gamification that resonates with those same developers. Hey folks, welcome to another episode of the application security podcast. This is Chris Romeo. I'm the CEO of Devici and co host of the podcast. I'm also joined by my good friend, Robert Hurlbut. Hey, Robert.

Robert Hurlbut: 1:50

Hey Chris, yeah, Robert Hurlbut, and I'm a principal application security architect and threat modeling lead at Aquia, and really excited about the podcast today. Always excited about it, but, you know, diving in to some more application security topics.

Chris Romeo: 2:03

Yeah, we've got an old friend, uh, which I'm realizing I've only known for three years, but I feel like I've known Dustin Lair for a lot longer than that. Um, who I think of as one of the brilliant, uh, people in AppSec and, uh, always challenges my thinking. And sometimes I challenge his when he's on stage at a conference and I ask a question from the audience that I probably was maybe harder than I thought it was going to be, but, uh, he handled it brilliantly as always. So, Dustin, it's great to have you back on the show.

Dustin Lehr: 2:33

It's great to be here. Yep. So I'm Dustin Lair. Like Chris said, I've been around AppSec for quite a bit of time and spent a lot of time talking to Chris and Robert in the past about, you know, unique approaches and different approaches to AppSec. So happy to be here.

Chris Romeo: 2:50

Yeah, and you were, uh, on a previous episode entitled Advocating and Being on the Side of Developers. So, if folks want to look up and, and hear your origin story, they'll have to go to the archives to find it. Because we don't, we don't repeat our origin stories a second time, but it also gives us the ability to jump right into the topic, which is always fun as well. So, Dustin, you spent a lot of time focusing on security champions, gamification, um, security culture, the intersection of all of these things. And so I know I've heard, I've heard you on a number of other interviews and talks and things talking about champions, but one of the things I realized is a lot of times those conversations are going from the side of security. So I thought it'd be a little fun today if we flip this around a little bit and we started thinking about this and we, and we collected your answers from the perspective of the developer, the development person who's out there potentially wanting to become a champion, potentially being asked to become a champion. And so to kick this off, go ahead, put your developer hat back on. I know you were a developer for a good part of your career as well. If you're a developer. What's the problem from your viewpoint?

Dustin Lehr: 4:04

Yeah. And I think, uh, this'll be good to expand on a little bit as well, because I don't think it's necessarily. Any developer. I think there has to be a little bit of a certain mindset that a developer has that would attract them to something like a security champion program. And what I mean Really lines up with sort of my approach in my career. And one of the reasons that I got into security to begin with is because I always had a focus on kind of the bigger picture, kind of the, the quality elements, not just make the feature work as quickly as possible, hack it together. But can we make something that's maintainable that other people can read? Right. How do we refine our process to be more efficient when it comes to our development? Uh, and then obviously other things like security and performance and that sort of stuff. So I think, you know, finding developers who have more of that mindset. They're already thinking about these things. Um, I think those are your initial allies. Those are your initial sort of security champions that you could, um, start to work with. Um, because I think they already get it to a degree. And I think one of the biggest benefits of a champion program as well is, You know, finding advocates who can help spread the word, right? So you can sort of connect with folks that already sort of get it, uh, and then go from there. And in my view, I think a lot of those, um, developers who do get it, they don't necessarily want to become security people. Like, that's That's not the goal is to like shift them to become security people. They're happy. They're happy as builders. They just maybe want to get a little bit more involved in, you know, thinking about security. And, and I think the other thing I would add to this is I do think security helps to drive a lot of the development quality practices that should probably be. Driven by engineering in a lot of cases, things like a good asset inventory system, uh, you know, better, more efficient SDLC processes. You know, we talk about securing the SDLC. Sometimes the first step is building an SDLC and you'll find developers who are trying to actively pursue that. You know, can we have a better process? They're trying to think about that stuff. So, Again, I think finding those allies and working with them, uh, is kind of the way to go.

Chris Romeo: 6:29

So I need you to tap back into your old development days here too. And think about this, like, what was security pushing you for when you were a developer? Like, that's what I'm trying to get to as far as what's the problem. If I'm a developer, like, we've all got decades of security experience. And so I feel like we have, Can you have security colored glasses? Security is not really a color, but it's, the metaphor works, security colored glasses, because it changes, like, we use terminology, we, we have concepts and things that we all just believe in, right? We don't have to, we don't, you don't have to convince Robert or I about the benefits of a champions program, but if you're a developer who has really not had any exposure to security before, Like, is there a problem that you're seeing when you're looking at, when you, when you're listening to security, say, now you have to do this. You have to do this. You have to run this tool. You can't, uh, how dare you have a bug that's been this long in the queue and not been fixed? What's, what do you, do you see, if you're a developer, do you see a problem or are you just sitting there going, I don't know what these folks are talking about?

Dustin Lehr: 7:34

Yeah. And I think trying to realize that there's different approaches is important too. I do think you'll have people that get it immediately. I think you will have people that say, yeah, that is a problem. I've been trying to get my engineering leadership to think about these types of issues for a long time. Thank you for coming along and saying the same thing. Maybe they'll listen to you better than they listen to me. Right. But I'm not sure that that's the typical developer mindset. Uh, it could be, but I also think there's another class of developers who are like, look, I'm on tight deadlines. I want to build stuff. What is this that you're bothering me with? Like, is this really a problem? And, you know, and I think back from my development days, it's like, I'm very short on time. I've got a million things to do. Unless you can demonstrate that this is, like, an exploitable actual issue, not this, you know, kind of, uh, I don't know, like, some sort of, uh, almost esoteric type thing, like, like this imaginary thing, right? Um, if you can, if you can demonstrate that it's actually an issue, that's what I need to actually take action on it. Otherwise, why would I waste my time? You know, and I think devs are just generally very short on time and that's, that's, that's their mindset. Like I've got deadlines to hit. I've got features to develop. Why would I waste my time on this?

Chris Romeo: 9:04

Cause a lot of times developers say you're living in an agile world. Right? I know there's no real such thing as an, there's no defined Agile world, but you're following an Agile like process. Let's call it that. You, at the beginning of a, of a sprint, You, maybe you have, there's story points or something that are being used, but you're getting a block of work. And the expectation is, by the end of that sprint, you will have moved that block of work to whatever state. Sometimes it's not complete, sometimes things cross over, but a lot of times it's, you have these three tasks, Dustin, and two weeks from now, during, on demo day, you're gonna need to, do a demonstration for us. And so you're, you're, and so that's really what's driven. And from what I've seen in a lot of organizations, that's what your bonus is keyed on as well. It's not keyed on, it's keyed on, you know, how, how well did you meet your sprint deadlines? And so what's been your experience as far as the pressures that developers have? to deal with.

Dustin Lehr: 10:02

Yeah, I think it's just like you described. I think there's expectations that you deliver something specific in a sprint. You know, you story pointed it, you planned it out, and you have to deliver it at that point. Uh, and there's really nothing else. Like I remember very very many occasions where even a meeting or an email is too much, right? Like, can you just clear my schedule? Do you want this feature to get done or not? Why do we have to have a conversation? You know, and I think we'll get into this in a little bit, uh, a little bit later, but, um, You know, I was very heads down. I think a lot of developers are very heads down to the point that some security person reaches out for any reason. And they're like, first of all, you broke their concentration. Like, I think this is a huge thing for non developers to understand. It takes a lot of concentration to be able to code correctly or code accurately. Right. You got to think about how your little piece of code is going to fit into all the other moving parts. You keep all this stuff in your head, you're in the zone. Any sort of interruption that comes in is annoying, breaks your train of thought, has to essentially lead you to context switch, which is a very expensive thing to do. Um, I also remember lots of like troubleshooting, you know, hey, there's a production issue, can you look at this? And then if it's a high visibility issue, Engineering leadership or even leadership from other departments are like pinging you. Hey, how's it coming? What, you know, is there any progress? It's like, okay, do you want me to make progress or do you want me to answer your question? Right. So, and I think that's the mindset. So anything that comes in sideways is like pretty immediately annoying for a developer. How's that for

Chris Romeo: 11:56

me think of, you guys ever seen the uh, Maker vs. Manager article? I think it's an article, I don't even know where it originally was posted. You should look it up, it's fascinating. It's this, it's, it, it speaks to that exactly. Cause like people either have a Maker schedule or they have a Manager schedule. Manager schedules are based on filling up your calendar with meetings. So that you can understand what's happening and you can manage better. And maker schedules are all about freeing your calendar of all of those things and giving you blocks of time to do what you just described about getting in the zone and, and being able to put out some good, decent code that works because nobody's bothered you and caused you to, to make an error in the code because you got interrupted. And by the time you came back, you missed something. Oh, I was supposed to validate that input, but I just, I missed it because it was, uh, I got interrupted so many different times.

Dustin Lehr: 12:46

Yeah, now that said, I think, you know, again, I spent a good part of my career in that mindset. But I would say that since then, I've learned the importance of communication. I actually have a rule. It used to be like 90%, you know, heads down, work, leave me alone. Uh, Maybe 10 percent was allocated to meetings and emails and everything else. Um, I think to a certain degree, you're limiting your career if you take that approach, okay? Like you're a builder. Great. You're getting stuff done. My rule of thumb now is, is 50 50. Even for tech people, like you need to be talking about what you're building and sharing with other people and mentoring and doing that kind of stuff. 50 percent of your time, uh, 50 percent coding heads down, leave me alone. But I do think for the first part of my career. I didn't, I wasn't able to go as far as I could have if I did spend more time sharing what I was building, because otherwise people, you know, people aren't going to know, like you, you just refactored this entire piece of code to make it more efficient, but you didn't tell anyone about it. You know, there's, there's a few problems with that. Like you haven't communicated that people, the next person that goes into that piece of code is going to be like, what the heck just happened?

Chris Romeo: 14:10

yeah.

Dustin Lehr: 14:11

You just made a quality move that needs to be communicated more broadly. Why did I refactor this? Because I found it was unmaintainable. It was basically tech debt. Well, what's tech debt? Well, let me help you understand that because that's important. And maybe we can better align our development team to focus on things more like tech debt. And if you, again, if you don't say anything about that, it's not going to go anywhere. You know, you can't just be like this silent hero working in the background and never telling anyone, you know, what you're doing.

Chris Romeo: 14:46

Yeah, it's it makes me think about like the rise of the staff engineer that we've seen over the last couple of years, and I think, you know, I mean, I was at Cisco for a long time, and we had principal engineers, which were effectively what, you know, I think people are calling staff engineers now, but really the difference between a staff engineer and a senior engineer, staff engineers can code. They can both code at a super high level, probably the same level. A staff engineer can bring five other people with them on the journey. So the staff engineer is the one that can be interrupted during the day when somebody says, uh, I just don't, I don't know how to design this right. Can you help me? And the staff engineer is the person who can look at it and say, okay, here's what I would do. One, two, three, this would be the order how I do these things. Hopefully it'll help you. So they're, they're able to draw people forward and make them better. And so I think that's a good, good point from your side. Like the, the fact that you can definitely hinder yourself in your career. It doesn't matter if you're a developer, if you're a security person, it doesn't matter what you do. If you are, if you can only put your head down and say, I need 90 percent of my time to put my head down to be successful. You're never going to move beyond, you might get to a senior engineer because you can, you can still be a senior engineer and, and not be as good at communicating, but that's going to be the end of the road for you. There's no, there's no place higher you're going to be able to go.

Robert Hurlbut: 16:07

So, Dustin, you mentioned a couple things that, um, for yourself in terms of what you saw, what, you know, quality and so forth that was important to you, but what else would you say is unique about a developer that would lead them to becoming a champion?

Dustin Lehr: 16:25

Yeah, I mean, I was mentioning before, I do think that sort of bigger picture view is important. I think realizing that communicating and, and that you can learn from other people besides just heads down research. Um, Realizing that you, you don't know what you don't know to a degree. There's this sort of humility that I think is important as well. Um, you know, do I think I know everything or, or is there room for things that, you know, that I don't even know that I should know? Um, I think that's important. I also think there has to be this sort of care for, um, communication and then sort of the people side to a large degree as well. Like, How do I help other people learn? You know, I just learned some stuff that I didn't know I didn't know, you know, I think having a desire to help other people be enlightened with that stuff that you learned, I think that's important as well. Um, you know, so there's a bit of a care for your fellow developers, um, and, and sort of wanting to help them too. And I think that's, that's important. That's important because of how champions are typically positioned. And that's, they're the representation of security within their teams. They're learning stuff that then they're expected to turn around and share with their teams. Um, so I, I do think that mindset is important as well.

Chris Romeo: 17:53

Can a developer become a champion with zero security knowledge? There, you get a developer, they're like, you're on a call and they're like, OWASP top who? Is that somebody who can become, can they become a champion in your

Dustin Lehr: 18:06

Why not? Yeah. So I, I actually get this question a lot is, is it, you know, is the opportunity to become a champion only for senior level people, right? Only for people who understand security. And what I find is there are benefits to actually having less experienced people be part of it too, especially if they, uh, start to, you know, drink the Kool Aid a little bit and they get excited about it and they start to go down that rabbit hole. I don't, I don't know how, and maybe we can talk about your experiences with this, but when I started going down the security rabbit hole, uh, I didn't know anything at first. I read a book on, uh, what was it? Um, PHP security of all things, uh, way back in the day. And I was like, this is fascinating. And it just led me down this path towards security. You know, I think finding someone that's sort of just getting into it and. Starting to go down that rabbit hole, uh, is, is awesome. And I think, you know, bringing these new, fresh ideas, uh, from someone who's less experienced is a great benefit to your champion program. And frankly, it's a great benefit to our security industry in general. I think there's this archetype mindset where, you know, there's this model. Purple unicorn. person that should be a cybersecurity person, but I actually think there's a whole lot of positions, marketing and sales, and I don't know, psychology, that have a lot to give to cybersecurity, you know. So even if they know very little, I think, and I talk to folks about this all the time, like bring, bring your unique, Uh, background into cybersecurity. And we should welcome that because it's going to force us to think of things in different ways. So, yeah. So I think that answers your question.

Chris Romeo: 20:08

Yeah, I was, I was smiling a little bit when you were, as you were going through there, only because I was remembering some past champions that I've worked with who were more senior security knowledge people, and they tended to be more challenging. And the newer people who are, cause they were, they were, I mean, let's face it. Security does make us a little, it hardens our edges a little bit, right? We get a little cynical. Um, you know, I mean, I've been doing this for 26 years at this point and I look at things and go, it's, it's half empty, not half full, right? Like

Dustin Lehr: 20:43

They're skeptical.

Chris Romeo: 20:44

Yeah, I mean, that, that just came from, and to some degree, I think that helps you as a security person. But when you're thinking about something programmatically, where you're trying to positively influence change, being cynical is not a, it's not a good thing because, you know, your first answer is, well, they're just gonna screw it up. You know, like, and that's not my, my, I'm cynical when it, from an architectural perspective in security. I'm not cynical about the people side. But a lot of the senior people that I work with. We're more of a challenge to get them to play nice in the pool with everybody else. Whereas junior people were more open to, you know, having that humility saying, I know what I don't know, but also being ready to just dive head first into the pool to solve things and then bring other people with them through the process.

Robert Hurlbut: 21:35

What does, um, what would a person who became a champion, where do they get out of it? I know we've talked about what they offer, uh, their perspectives, and, and I agree with that, that, uh, even if they have zero to very little experience, it's, it's good for them to be interested and join, but what do they get out of being a champion?

Dustin Lehr: 21:57

Yeah. I think there's a handful of things I think to start. They're enhancing. a portion of their knowledge that is very valuable these days, you know, being able to, and frankly, if I was an engineering leader, uh, this is what I would look for in folks that I would hire too. Like, great, you can write code. Okay. But can you write it? You know, in a way that is secure, like, are you going to think about things beyond just making it work? Um, and I think there's a lot of benefit becoming a champion to learn that stuff, to learn more about security. So essentially it's a resume builder, you know, to sort of put a pin in that one. Um, besides that, again, if people are interested in going down the rabbit hole, I think there's a lot of intrinsic value in just learning more about cybersecurity and, you know, Is Hackers the movie accurate? Is this really a thing? Or is it A little different than maybe they first expected, you know? Um, and how do they bring these concepts into their personal lives? I, you know, I see this a lot with champions where, you know, maybe not even just the technical ones, but the, the folks who are from sales or something, you know, they learn more about. general good security practices, password managers and data sharing and phishing emails and that kind of stuff. And they bring it to their personal lives, you know, and they help, they help grandma, uh, you know, secure her situation. And so I think there's a lot of benefit from that perspective as well. Um, and then I think when you're designing your champion program, you need to think about what are the sort of rewards and incentives that you're going to offer. You know, is security part of your performance review in some way? If you can make it that way, then there's a lot of benefit, obviously, for, for champions in terms of career growth. Um, and then I also think, you know, things like recognition, like being, doing the extracurricular things. Uh, I think is always something that is, you know, kind of held as, um, a good reason for promotion or, or just that this person goes above and beyond. Not only are they killing it coding, but they're also a security champion as well. And they represent our team from a security perspective. Um, it's a really easy case to make that this is clearly a leader on our team. So there's a lot of recognition and so forth that comes with that too.

Chris Romeo: 24:25

Yeah, I can say one of the, one of the biggest rewards in my career has been. Watching champions succeed, go from developer to joining a security team. I had a bunch of folks that came out of the Cisco program that were developers, different levels of engineers inside of Cisco, and they either migrated to security roles at Cisco, or a lot of them went to other companies. And LinkedIn as they're developing. Progressing through their security careers. And so that's, that's just, that's just one of the side benefits of, of being around these things is we all know we need to be building the next generation, but the champions program gives you the ability to participate. And, and follow, then follow along for the years into the future while you watch these folks getting promotions and taking on new roles and stuff. And it's like, oh, that's really, this is really cool. I remember, I remember that person when they were just starting out. What about gamification? So I know that's something that you think about a lot, Dustin. Um, but let's think about it from the developer side. Like how, how are developers influenced and impacted by gamification?

Dustin Lehr: 25:37

Yeah, it's funny you mention this because I get some skeptical questions around gamification sometimes where folks are like, do people care about games? Like what, why would gamifying this have any sort of effect whatsoever? And my response to that is, um, what do you think your developers are doing when they're done with work these days? What are they doing? Right? They're gaming people. So, you know, if we're thinking, well, do points matter? Does status matter? This sort of stuff. They're building their World of Warcraft character on the side. Like these are things that I think, and maybe it's a generational thing, but we are seeing more and more people really sort of embrace this. Sort of gamer mindset. Now, let me be clear that gamification does not mean necessarily turning something into a game. There's a bit of a misrepresentation of that term. It's not my favorite term, to be honest. I prefer, um, sort of more of a human focused design type of thinking, where you're appealing to our drives, like our actual human drives. And one of the reasons that we look to games for that is because you don't have to play games. Why do people do that? You don't get money from it. I mean, you could in some situations, but for the most part, yeah, right? Uh, but for the most part, you're playing it because it has appealed to your drives in some way, right? There's urgency with it. There's scarcity. There's, uh, meaning or, or even just the feeling of accomplishment, you know, that, that is appealing to people. So the idea behind gamification is how do we take those elements that the game industry has clearly mastered. and apply those to non game situations. Uh, and that has just been a fascinating thing. I've gone down this road of studying this now at this point for, for years. And, um, I will say that the more that I can sort of understand humans through these drives and by thinking about the techniques that games use, the more success I've had in terms of building great experiences where people keep coming back and they do crazy things like. We, you know, I've had non security people start book clubs and start other clubs, and it makes me think, like, how would we get there without, without this sort of, uh, motivational element? Could you imagine a CISO asking some regular non security person to start a book club? Like it just doesn't work, right? So they have to basically be inspired to do those things themselves. And you know, you know, you've succeeded when you've set up that recognition and sort of reward system that does, um, incentivize that behavior. So it's pretty, the whole field is just fascinating.

Robert Hurlbut: 28:36

Let's talk a little bit about, uh, on the, on the security side, we talked a lot about developers, but for the team, the, the, The organization that's trying to justify creating a champion program. How would you, or even developers talking to, uh, the VP of engineering, how would they help justify a need for a champion program?

Dustin Lehr: 29:03

Yeah. I mean, I think this is sort of a culture shift that has to be. Um, pursued with care, right? So the way that I always try to talk about this stuff is what is the ultimate problem that you're trying to solve? I always use the term, I'm going to say this on this show, and I'm, I'm going to get a look from Chris, but this whole concept of shift left, I think makes sense if you think about the right side activities as contributing to those shift left concepts. So let me say it like this. You need to prove that there's an issue in your environment before you make a change, right? So I always say start right, which means do a pen test, look at Prod, look at, you know, like set up scan tools, understand that you have issues, you have vulnerabilities or risks that have been introduced in your systems in prod today, because from there you can start to make a case. Well, do you want to prevent those things from existing? Do you want to fix those A and B? Do you want to find ways to prevent those from happening again? And that's when you can start to have a conversation around. How do we actually shift some of our activities to earlier in the cycle, or left, um, to start to prevent those things? And that's kind of where training and security champions and threat modeling and that, those sorts of activities can be justified. Because I think something to think about as a thought experiment is, if you literally hire someone to do a pen test, you set up scan tools, you look for issues in prod, And you don't find anything, you're not going to have any luck building a business case for some of these left side activities. So, I do think it starts with that. Um, it's a pretty hard conversation to have though because, um, a lot of folks will say, Well, that can't happen to us. Or, is that really real risk? You know, is ransomware really going to happen to us? And I think that's pretty important. Yeah, you just need to, that's, that's a hard problem to solve. So I'd be curious to know your thoughts about that too.

Chris Romeo: 31:14

Well, first I want to put my VP of engineering hat on and I want to, I want to have a little conversation. I'm going to, I'm going to, I'm going to give you this for my take. And I'm curious, you can now play the role of security leader, which you are in real life. Uh, you don't have to play a different role, but let me, let me kind of, let me, let me spin it to you how I perceive it as a VP of engineering. And I'm curious to see how you would convince me or what, what you would give me to think about. So, uh, Dustin, I'm. You know, I, I get you from the security team, but product is driving what we do. Product drives, everything product hears from the customer product tells us what we got to build. And so I've only got, I don't have enough resources already. to keep up with all the things that they want to build. And so now you're telling me that you want me to, to, uh, put some people in a champions program. You want me to add these tools. You want me to do, you want me to, you want to take a slice of my resources here, but I don't see a path forward for me to take a slice of those resources and, um, still get what the customer slash product wants. And my fear is I won't be here in six months. If I take your, if I, if I take a slice of my, my folks time and try to apply it to what you're, what you're doing. So give me some justification. Give me some rationale for what, how I can keep my job six months from now.

Dustin Lehr: 32:33

Yeah, so I do think there has to be a lot of alignment in terms of leadership here, and that's where I would say I would definitely work with the product team to help this engineering leader, Chris, understand that it is actually something that we need to pursue, because for instance, we've got customers who are asking for this. We've got customers who are asking, what are our SLAs in terms of fixing vulnerabilities? Uh, what, what sorts of risks do you have? You know, they're, they have to fill out like SIG lights and, and that sort of stuff. You know, I would say the compliance folks on our team can only help so much. We need to turn around and actually implement best practices when it comes to this so we can keep them honest as possible, you know, um, so I'd say customers are a big reason. I would also say that the, uh, compliance requirements themselves has a lot to do with customers too. Like there are strict requirements from, you PCI, and those are even expanding a little bit more. I think there's a lot of dancing around that happens. This is a whole nother conversation. Probably. There's a lot of dancing around that happens in terms of answering these types of questions to auditors, um, without any sort of feedback back to engineering, what I would like to see is VP of engineering. Um, we just told the auditor this, but we don't do this consistently. What do you want to tell them next year? They gave us six months or something to correct this. If we don't correct this, we're losing our cert. You know, and I think a lot of folks are suspicious of certs as sort of being this, this checkbox. But I think if you use them correctly, you can make differences in your org. So yeah, an imminent threat. Sorry, one other thing. Imminent threat of a customer or prospect not purchasing our product. because of some sort of security concern. Like the more you can highlight those, you know, VP of engineering, we just lost this deal because they didn't like our security practices.

Chris Romeo: 34:43

then you can tie revenue to, potential revenue to, once again, now we're talking about a business case because we lost money and as long as it's clear, everybody knows we lost it because we didn't have the right security.

Dustin Lehr: 34:56

even entire sectors. And this is kind of where the product conversation comes in. Do we want to appeal to, you know, public sector type companies, uh, government agencies and so forth. If that's part of our plan this year, we need to get our stuff together when it comes to security.

Chris Romeo: 35:17

Are you hearing anything different? Um, we can leave the role playing. We can shift back to just normal conversation here. I'm not the VP of engineering anymore, that's what I'm saying. But I'm just curious, like, are you hearing Anything else other than from customers other than what you just kind of described as far as I get the, I get people are asking for certs, they're asking for SOC 2, they're asking for us to fill out um, these what appears to be uh, infinity length uh, questionnaires where you answer a question and then it branches out to eight more questions. Like no, I just answered one, how do I now have eight that I haven't finished? That's a whole side topic as well. Uh, but other than certs like SOC2, um, SLAs, uh, compliance driven type of stuff, anything else like our, is the modern customer, how savvy is the modern customer, or modern buyer I guess

Dustin Lehr: 36:12

Much more so than we've seen. I think, you know, in terms of what I see at, at, uh, at Fivetran and what I've seen in other companies as well, I do think that There's just generally more awareness around this stuff. I think the, the press, uh, around this stuff, the, the, the government, the White House focus on a lot of this stuff has really helped increase that awareness where people are asking harder questions that they may not have asked, you know, five, five or 10 years ago. And that is putting a lot more pressure on, on vendors, um, to, you know, or really, you know, depending on your perspective on, on companies, you know, to make sure that they're, um, following what their prospects and customers expect. So that's really, I think, done. Uh, you know, a lot of favors for the security industry in general. So we need to get out there more though. I, you know, I think we're heading down that path, but I still think there's a pretty major lack of awareness, especially when it comes to the business side of, of a lot of companies, they just don't realize to what extent there is a risk that they need to pursue. Um, and that's all of us, you know, in the security industry. I think we need to continue to highlight, uh, concerns, you know, and, and increase awareness.

Chris Romeo: 37:32

Yeah. So, uh, Champion Success Guide. And Katilyst. I wanna, I wanna hear about both of these things as far as where they are right now. I know you wrote the Champion Success Guide a couple of years ago now, so I'm curious to hear about how that's progressed. And then I also wanna hear about this thing called Katilyst. Which, the way, for the audience's perspective, I'm giving Dustin an invitation to speak about. He's not speaking about, I'm, I'm, I'm asking him to.

Dustin Lehr: 38:00

fantastic. Thanks for clarifying that. Um, yeah, so security champion, uh, success guide I wrote almost two years ago. And really it was an opportunity to just literally write down everything I know when it comes to building security champion programs so that I could help others, uh, build security champion programs. And I think the main reason for that is, um, I've just seen them be so successful in the past that I want other people to be able to build something that is successful as well. So that's why I named it the success guide. I think that's the exciting part about it. So it's all free. It explains what a champion program is. It sort of gives you a step by step procedure for building your own champion program. And one of the approaches that I wanted to take with it is to. you know, kind of nod to the fact that every culture is different and you can't necessarily just prescribe a solution. Hey, do these three things and it's going to be awesome. No, it's more make sure you methodically plan for building something unique for your culture. So that's kind of the unique spin that that guide provides. And then, um, yeah, Katilyst. So I started Katilyst to actually me and a co founder started Katilyst about three years ago now, and we have basically just been helping people shift culture and, uh, build security champion programs. Uh, we noticed that there wasn't necessarily a company that was focused on that specifically, so we decided to take that on, and it's been growing ever since, and definitely getting very exciting. Uh, we have a handful of services that we provide, um, including designing your program, Helping with things like training, you know, if you have brown bags and so forth, we can help bring folks in to host those. Uh, we help with some of the administration, which there's a lot of time, uh, that you should be putting into, uh, your champion program if you're going to make it work. So we help with that. And then we're actually building a product as well that helps to essentially gamify your program, uh, which is a pretty unique offering as well. So

Chris Romeo: 40:07

Yeah, very cool. I've been, I've been following along. I've been a fan, so I'm, I'm curious to see where, how, as the product progresses, um, as somebody who's run a champions program at large, at scale, um, a lot of the things you described there are the challenges, right? Like, it's easy to start a champions program and run it for three months. Anybody can do that. The question is, what do you do in year three, when you're like, who is gonna talk to these people this month? Like, you have to build, you have to build a strong, uh, team that can drive this thing, because you really want that champions program to exist years into the future, not just be, so many champions programs are a flash in the pan. It's like, uh, we tried it, but it just kind of fizzled out. Like how many times have we heard that it's because they haven't done the things you're talking about here as far as having a way to get speakers, having some type of tool that helps them, you know, get the right behavior from each other. So, um, very cool. Definitely be following along. I'm a big fan. Um, but with that, we have to transition to the now, is it famous or infamous? I can never remember the lightning round led by Mr. Robert Hurlbut.

Robert Hurlbut: 41:15

So in the lightning round, we asked three questions. Uh, first is a controversial one. What's your most controversial opinion on application security and why do you hold that view?

Dustin Lehr: 41:26

Yeah, good one. I would say this, that I grew up in my career as a tech person, uh, so very focused on tech type solutions, as I mentioned before, writing code and so forth. But I think people are the way. I think that peop that Learning how to influence, learning how to, um, focus on what people need, and so forth, um, that's going to, uh, make or break your AppSec program, period. You could have the coolest tech, but if you can't reach people, you're in trouble.

Robert Hurlbut: 42:05

All right. Second question. What would it say if you could display a single message on a billboard at the RSA or Black Hat conference?

Dustin Lehr: 42:12

Yeah, so here's where the, uh, cynicism that we were talking about earlier comes in. I think I'd probably say something in line with what I was just talking about. Um, 80 percent of breaches are caused by human error. So let's just go buy some tech and basically ignore that problem, right? Which I've seen this a lot, like, just to expand on this, I've seen people say, That sucks. And then they just go buy scan tools and they just ignore the problem. So I'd probably hold that up at, at RSA or Black Hat.

Robert Hurlbut: 42:44

Perfect. And then the final question is, what's your top book recommendation and why do you find it valuable?

Dustin Lehr: 42:52

So no surprise here. I'm going to go with the people side as well. And specifically around negotiation. I think that this book, which I just read recently, uh, has had a major impact on the way that I approach, uh, conversations and negotiations. Never split the difference. Have you heard this

Chris Romeo: 43:14

I've read it. It's good.

Dustin Lehr: 43:15

you've read it already? Yeah, it's very good. It's very good that, you know, things come out of sort of left field where, as an example, the, you know, the faster you can get someone to say no is actually in your benefit. What, so there's sort of these mind blowing type, types of approaches that come from the book and I just really enjoyed it.

Chris Romeo: 43:37

Good stuff. Might have to add that to my list to reread. It's been a few years for me since I read that one, but definitely a great, uh, great choice. So, Dustin, we come to the end of our conversation. What's a key takeaway, a call to action, something you want to send our audience away with?

Dustin Lehr: 43:56

Yeah, just in line with what we were just talking about, I would say don't, don't give up on the side. I think that you can approach the the people challenge, uh, or opportunity with science in the same way that you might approach tech solutions. There are fields that are dedicated to this psychology, behavioral science, and so forth. There are answers out there for how to influence people, how to reach people, how to encourage people, how to motivate people, and so forth. And I would say, spend the time, look into that. It's going to bring a lot of benefit.

Chris Romeo: 44:31

Excellent. So, uh, Dustin, thanks for joining the application security podcast for another episode here. Um, you're brilliant. I'm a big fan and I can encourage folks to follow you on LinkedIn because you're always good for a question that gets the brain churning. Sometimes you put them out too early on a Monday morning, but that's okay. Um, I'm often, I often reply to those and jump into the mix and those, cause they're always very helpful. Very good questions that give us a number of different ways to debate on a particular issue. So I'm a big fan of those, so people should look you up on LinkedIn. Folks, thanks for listening to the Application Security Podcast.