John Benninghoff - Tapping Other Fields To Approach Security Differently

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 are kicking things off here in 2026 with a special guest, friend of mine, John Benningoff. So I'm really excited to get into it. I'm your host Dustin Lair and John, how you doing today? I'm doing well. So I think a really good place to start is to talk about you, our guest, our star of the show. Tell us more about your background where you came from, even start to get into the philosophy about what you think about AppSec and so forth. Yeah, yeah. So it's, you know, I've been doing this a long time. So I, when I first started out, I kind of marked the beginning of my career when I went with my future boss to my first security conference, a SANS conference in Orlando and I guess it was 1997. So this was quite quite some time ago. It was a great time to be getting into security because there was lots of interesting things going on. You know, Marcus random was a kind of a prominent speaker network flight recorder. If anybody remembers that was out and it was an amazing tool and you know, we were just starting to get into the early days of real internet security. So not long after that, I did go into security full time. The woman I worked for my boss and mentor was a great boss for me because she'd already been doing security for about 10 years herself, you know, starting out in mainframe security, which you know, as, you know, we work for a financial services company was something that was needed even that long ago. And from her, I kind of learned two very important lessons. One, I kind of already knew which is securities very much a people problem and much less a technology problem and understanding people and organizations is kind of a key to success. And the other thing was that I learned, you know, that security doesn't, you know, that there's limits to security security needs to be good enough. But I've said later is that, you know, a security amateur knows how to secure things a security professional knows when you don't have to. That's really about understanding how to prioritize your time for maximum impact. So for about, you know, the first 10 years of my career, so I worked mainly on infrastructure security firewalls. I worked on the network and network and Tusion detection system. I ran our companies first vulnerability management program scanning with with NASA spec when it was still a free tool before it became tenable. And then later, moved into application security. I was never paid to be a software engineer. But since about 2009 or thereabouts, working much more with with developers, helping them be successful, met a group of folks at Target when they were early in their application security journey and learn quite a bit and a lot of those folks were developers more recently. So I've actually been learning teaching myself software engineering skills. So I have a much deeper appreciation for that. And also went back to school a couple of years ago and got a master's degree in safety science, which is the study of accidents and accident prevention. And I think has a lot to offer a lot of those lessons can be adapted to security. That is fantastic. There's a lot to unpack there. Okay. The first the first thing that stood out, which we talk about a lot on this show and I generally talk a lot about. People are a key to success. Do you think a lot of folks that join cyber realize that? Is it a little bit of like a bait and switch? Hey, it's going to be really fun. There's a lot of technology involved. Oh, sorry. It's actually more of a people thing. I don't know. I mean, I think I don't think it's so much a bait and switch as it is kind of like it's I think it's a story of many professions. So one of one of the interesting papers I read when I was in school in my master's program was about automotive engineers. And you know, the kind of the early engineers are kind of focused on making sure that they hit the specifications like the specs are what's most important. The kind of the and this these are like, you know, engineers ability as judged by their peers to kind of the next level up is engineers kind of thinking about integration. So how does everything integrate together and the very best engineers, you know, they're kind of miss they kind of describe their job as focusing on the driving experience. Right. So how does all the technology translate into the driving experience for the driver. So I think, you know, that as you improve as a security security professional, you know, you're just going to naturally focus more on kind of on the people over time. Yeah, I think I do think you find that in software engineering too, at least this was my experience when I was more of like an architect type, right? I've got 10 years of development under my belt. I can now contribute differently. And it goes way beyond the tech, right? It's how to influence leadership. It's how to talk about tech debt. Right? It's all these other things maintainability and performance and all the things that go into building software that are beyond just making it work. Right. Right. And I'm glad you mentioned the term driving experience because a lot of people talk about the developer experience. Right. Something that should be focused on in appsec as well. So I don't know if you want to expand on that a little bit more like how do you take what you just said around the driving experience and sort of translate that into the developer experience in appsec. Yeah, no, I mean, I think, you know, one thing that I found that the best security analysts have in common is curiosity. Right. So I've watched security analysts, activists and basically just like here's, you know, here's the list. Here's the compliance checklist. You have to follow. I'm not going to listen to you. Like I'm, you know, even if they're asked for like advice on doing it correctly. The answer is, I don't know. That's your job. You know, whereas if you, you know, the better analysts, they're genuinely curious. They asked a lot of questions like, what are you doing? How are you doing it before really giving the security advice? Right. You know, I kind of realized this is the approach that I took after the fact. Right. I've seen other people do it now and I was like, I've always kind of done this way. Like, you know, somebody called me on the phone once and he's like, I need the encryption. Like, really, tell me more. Why do you need the encryption? What's the problem when you're trying to solve? And as we got into it, talking through it. What they really needed is access control. Right. That that was all that they needed. There's some simple access control around some sensitive files that they wanted to protect. And they just didn't know the language to be able to convey that. So I've actually run into something similar where I had folks consistently asking for a pen test. We need a pen test. They call you up. We need a pen test. We need a pen test. And that's like all that they can say or think of. And it's like, ask some questions, try to figure out what they're actually after in order to deliver something that, you know, is useful for them. And that's where I think your experience comes in to is being able to ask those questions and really get at the heart of what they're going for. I actually remember back when I was a developer, there was a database guy, data database designer, right. And beyond a DBA, I would say, but it was the same kind of thing where I was like, hey, I need a table that does this right. I'm trying to write an app, etc. And I remember him very clearly sitting down with, it was me in a team of developers. And I was just asking a lot of questions until he was able to figure out what we actually needed. Right. And it was awesome. And I took that as a lesson of like, okay, as an expert, right, slow down, try to figure out what they're actually after and then try to provide a solution that's going to get them there. Right. As an expert, you can't just give them the solution. You have to help them define the problem. Well said, that's exactly right. So tell me more of this, this, this safety journey that you want to. Sure. So you studied safety. I did. Why? How does this apply to security or these same like, I'm really curious about this. Yeah. So it, you know, it's, my interest in safety started, you know, probably has probably. Well, over 15 years ago now, it started, I think, you know, around the time I switched over to Absek, around 2009. I was interested in safety first because, first because my grandfather flew planes for a living. He was born, I want to say, like in like 1919, started flying planes, you know, and I think even when he was like 15 or 16 years old, and flew professionally, starting at age 18 in South America because he was too young to fly in the US. But, you know, flew for American Airlines for, you know, for his whole career in, you know, essentially the golden age of flight, right, of commercial pasture flight. And I remember he, you know, he would take my brother and I up for rides in his, you know, little SESTA because he always had a private plane that he, because he loved flying. And, you know, as an adult, I realized, you know, like when he took us on with the plane, he always ran the checklist. He actually had a physical checklist and would go through, you know, all the pre-flight checks, you know, before take off. And I'm like, this guy's been doing this a long time. If he, if he does this, you know, actual, you know, pen and paper every time not from memory, it must be really important. And I read the checklist manifesto. I later read a book by a safety scientist named Nancy Levison, engineering a safer world, at least part of it. You know, I, you know, just became interested in safety because as a form of risk management, it's been very successful over time. Aviation safety has gotten better every year. Fire safety keeps getting better. Security doesn't really, it's actually getting worse unfortunately. Like the, you know, the risk from cyber security is not improving over time. So why not actually adapt lessons from a discipline where it is getting better over time. Yeah, I've been doing some research on that too. I have some talks coming up. And it is very interesting that security does seem to be getting worse beyond seam. Like by the numbers, it is right from records exposed, passwords exposed, right. Dollar amounts, right, breaches increasing gear over year. So we need a change, you know, we need something to, to, to be different. And that's where I'm familiar with your work around security differently, as well as I think that's a derivative of this safety differently. I love to talk about that. Let's actually pause for a minute though because I want to hear from our sponsor now that I teed the whole thing up. So, you know, we'll be right back for that. How do you create security champions? Security journey is the solution most adopted to provide application security education to help developers become security champions and produce safer applications. Content extends beyond developers to reach the entire SDLC, creating a security first organization, learn more about our enterprise security training at security journey.com. All right, and we are back. So I teed up a nice conversation, I think, for us to continue. It's already been a fantastic conversation. So, I think, to this security differently concept that I believe you came up with that was a derivative of safety differently. So can you tell us more about that? What's safety differently? What is security differently? Yeah, so safety differently. I guess the way I would put it is it is a particular, a particular way of talking about modern safety science. So, by a prominent academic Sydney Decker, Sydney Decker is one of the, let's call them well known safety scientists in the field has written a lot of books as actually has flown as a commercial pilot himself and is now teaching in, I want to say, teaching in Australia. So Sydney has has written books that actually have been fairly influential in the site reliability engineering space drift into failure, the human, the field guide to human error, two books that talk about that. So, the most important of safety differently is that in a kind of traditional safety is defined by the absence of accidents and you kind of have the pattern of policies, controls and assessments to basically kind of constrain workers and prevent mistakes. So, there's a kind of flip set on his head, it says, well, no, you know, variability of performance and making mistakes is a normal human thing. What we need to do instead is actually, you know, recognize that the workers who are working on the front lines are actually the ones that create the safety and, you know, basically empower them to be successful in working safely. There's he actually has done a couple of like documentary films about this based on his work in one example, they he was talking to a grocery store chain. And they decided, well, let's let's try and experiment and it's like let's remove all the safety rules from some of our stores and let the people in the store decide, you know, like how to work safely instead. And it has turned out like, you know, the folks that both were the kind of centralized rules were removed and they were given kind of some training in some of the safety differently concepts and principles. They actually had a better they had better outcomes in terms of reduced number of accidents. So, you know, the flip and fall are very common in in grocery stores, as you can imagine, like, you know, flat floors, you spill a lot of water on there, customer slips and falls, you know, or, you know, like you're working in the deli and you might cut or something like that. So, but yeah, the safety, the safety outcomes in terms of reduced accidents actually, you know, things got better when you actually remove the rules. That is fascinating. Why do you think that is going to go one layer deeper there? Yeah, I mean, I think I think the, you know, the. I think the, you know, like, again, I think it's it's a it's a fill of this a philosophical shift. I think, you know, it's I mean, I guess I that maybe a good way of explaining it is to talk about like, how would this actually work in software development. And I think, generally speaking, for, you know, experienced software developers, people who've been doing it, you know, long enough to get past kind of that, that, you know, that five year, you know, five year horizon, you know, that's kind of a, you know, like kind of like that. Somewhere between five and 10 years, you know, you actually really start understanding what you're doing. I think for the most part, they actually know what they need to know to write secure software. What management needs to do to support that is give them the time and the space to do it. And potentially some tooling, some other assistance to actually help them, you know, manage all the complexities of that, right, because, you know, as as someone who worked for me said once, you know, it's tough being a software developer today. There's just so much to remember. And it's pretty much impossible to remember all the things all the time. So, you know, developers need a lot of help. Right. And that's that's why we, you know, that's the value in the security tooling that we have is kind of, you know, giving developers, you know, reminding them of what they already know in many cases and kind of pointing out things that they need to do. And they may not be aware of. Yeah, I've seen, and maybe this just evolves for me as a software engineer. I was always the one fighting for more time to focus on the stuff that matters, writing quality software. You know, all of the troubleshooting that we were doing, firefighting and so forth. And for me, it was about, well, how do we prevent, I'm not enjoying this. I don't like the engaged. How do we prevent all this? How do we get ahead of it? How do we be more proactive about the whole thing? And then I was the one fighting. I'm using that term on purpose leadership for the time to do these things, right, bringing more visibility into the fact that look, you could save actually a lot of time and money that we're wasting by running around fighting fires all the time if we just get it right up front. And I see, I see apps X role, at least my role in apps, I could being that advocate for developers, right, to have the right conversations at the leadership level to buy developers time to build things the right way. But I would also like to see more developers doing that. Like everything you're saying around, they already know if they're in the right place. in a certain experience range, they already know the right thing to do. So what is preventing them from doing it, right? Leadership, imposing certain requirements and constraints and so forth. Features only, right? We gotta get this out the door. We don't have time to work on that. - Yep. - I would like to see developers, and maybe this is a call to action. Maybe not fighting, but I'll say fighting back, or at least raising the visibility, right? Like speaking up in terms of what's needed as the professionals who are on the ground and can see the systems that they're building and maintaining, they are in a unique position, I think, to tell leadership, hey, things will go poorly if we don't have the time to do this. - Yep. - So that's something I certainly would like to see more developers do. - Yeah, and it's interesting. I think that can be challenging. I think that can be more challenging in larger environments, right? In large enterprise environments. So in our co-working space here, I've gotten to know a small company. It's a team of four, right? That's it, four people, right? Three engineers and a designer. And they do agency work. I.E., they build apps and apps for your phone and websites for companies of all sizes. And there's two engineers that have done it for a long time, including the principal, the owner, and I see me not be the exclusive owner, but it doesn't matter. But they actually, that's part of how they build applications. So they actually, because they're it, they know that they wanna do a good job for their clients. And they know they have to take time to build quality and do the maintenance and do, you know, address security issues. And that's built into what they do. I actually did a security interview with them, kind of like asking them about their habits. And it was amazing. They were really doing all of the things that they needed to do to kind of keep their own systems and their own kind of environment secure. The one thing that I suggested that they did actually take me up on was, you know, like, hey, so you have this weekly meeting where you talk about all of the work that you're doing. Have you thought about just asking any security concerns in the meeting? And, you know, Robert was like, he's the lead. He's the principal. He's like, I love that. And they've started doing it. And, you know, it actually in one and one meeting was like, oh, yeah, there was this new vulnerability reported in a library that we used. And so I looked at it and we didn't actually, we weren't actually vulnerable to the bug, but I just upgraded to the new version anyway across the board. And he said, you know, I kind of always suspected that was happening, but it was good to, you know, have confirmation that it was and have the time and the space to talk about it. So, you know, small organizations, especially a lot of the kind of the people I've met through the co-working space who are kind of more innovators, working smaller orgs, they kind of, they have more power to actually kind of carve out that time and space. I think it can be harder in a large enterprise. Yeah, I could see that. I thought developers didn't care about security, though. John, have you heard this? I have heard that. So, you know, it's interesting, probably my most viewed posts on LinkedIn was, let's call it accidental rage bait. And, you know, I guess in retrospective, could be considered insulting, but I'm actually not feeling too bad about it anymore. So my post was, it was actually after I had actually done the interview with that team. I posted, if you're a security analyst with less than five years experience, sitting across the table from a senior developer with 10 or more years of experience, they know more about security than you do. And the reaction I got, like I posted it and then I didn't think about it. And then like over the weekend, like it just completely blew up and people were posting angry comments and telling me this completely wrong developers don't care at all about security and how years of experience is a bad measure of expertise and all these other things. And, you know, there were some fair points in there. But, you know, what I meant when I said that, it was, you know, that essentially that they know more about security in the context of doing their job. And I also, you know, like, you know, I tried to phrase it in a way that it was like someone who's actually built up that requisite level of expertise. And as somebody pointed out, like I think, again, in larger enterprises, and I think this is just, this is not like crashing large enterprises. I think it's just very difficult to run a large enterprise successfully. It's just an inherent problem. You know, you can have developers that maybe just kind of hide out and they're not very good. But, you know, like the kind of their disc, you know, it's not, it's not handled well by the organization. So, yeah, that's an interesting, I could see how that would blow up and potentially offend folks if you're ever comparing the knowledge of one side versus another side. I think you're setting yourself up for a good debate. But, that doesn't mean it's not worth it. Like, I think, I think that's an interesting point that you raise. And I think there's a lot of merit to that argument because I do think developers are expected to be magical and just make things work in a lot of cases, which means they need to know a lot of things, not only know a lot of things, but they have to be constantly learning new things as well, right? And that's, it's very explicit. Like, as a developer, I will attest to the fact that it is not magic. And I don't have some skill or, I don't know, magical tendency, right, that other people don't have. It's just a matter of, I just go figure it out, you know? Like, hey, can you, can you do this? And I go do it. And to them, they're like, cool, I needed a thing. He magically created the thing. But all the sweat, everything that I did in the background to figure out how the hell to do this was very real, right? And that's my experience. And that's what I think devs struggle with, you know? Like, it is a struggle to be a dev. It's constant work, you know? So it's Googling stack overflow. Yeah. Or stack overflow. Yeah. Yeah. Yeah. Yeah. It's, it's reading the docs. Exactly. Yeah. But it's also the confidence. It's so true. It's also the confidence, though, that you build up over the years that you can learn it. You know, and I've got so many lessons around that too. Like, there's always a reason. Like, when you're troubleshooting something, I've got that in my head. There's always a reason, right? It's not magic. It's not, it just broke for no reason just to piss you off or give you a bad day or something. It's like, somebody changed something somewhere for this to happen. And those are the lessons that you learn. It's just a matter of finding that thing in troubleshooting like a scientist. It would, you know, one experiment at a time until you figure out what the actual issue was. So anyway, it's not magic and it's hard to be a dev. It's a lot of work. I want to come back to safety differently and security differently, though. So it sounds like you shared a lot about safety differently. How did that translate into the stuff that you're trying to do with security differently? And what is security differently? Yes, security differently is me. It's a company. It's an LLC that I started so that I could do consulting work. I very much believe in the mission, right? So the mission is to help people both measure security differently and then integrate that into how they do their work. So how can I actually measure that I'm measure my security performance? And how can I support the security performance of my organization? And so part of that, one of the key insights that I had, I don't really know how it came to me, but it came to me when I was putting together a presentation for a talk after I finished my masters. And I realized that, hey, if you start with the premise, as I learned from safety, that you can't have a science based on the non-accurrence of events. That is, you can't define your security success by absence of breaches. You have to define it in terms of performance when you encounter some kind of threat, threat actor, right? Security is-- excuse me, safety is not a perfect model for all security, because if you're a nation state, if you're like the US, and you're not. you're worried about military secrets and the like, it's a little bit different, right? But for most organizations, the security threats that they face are actually fairly static over time, right? So, going back a few years, SQL injection to SQL injection, and it works pretty much the same way. And until the, until the, until the stops working, the attackers are going to keep trying to exploit it, right? So, you know, like, you know, like, you know, 10, 10 years ago, you know, 20 years ago, how good are you at, you know, at defending yourself when your website got hit with a SQL injection attack, right? So like, when you're exposed to those threats, how well do you do? And then if you look at kind of security performance, it overlaps a lot with other aspects of performance, right? So in many cases, you know, security performance is not something that is really even done by the security team, right? So if you think about vulnerability management as I have, today, you know, vulnerabilities are essentially like, I haven't patched my stuff or I haven't updated my libraries, right? It's like, my stuff's not up to date. My technology needs to be updated. So, you know, your, your software engineers are the other ones doing the library updates. Your infrastructure staff and sometimes your software engineers now are the ones doing the operating system updates, right? So that, you know, that work that actually contributes to security is essentially maintenance and it's all being done by your engineering team, not by the security team. And you know, for this, I've argued and, you know, like, I haven't gotten a lot of pushback that, you know, vulnerability management as a practice shouldn't exist at all. Like, you know, at best, it should be kind of a monitoring function to give feedback on the level of maintenance that you need. That is interesting statement. I think where in my mind, AppSecSits is certainly not the ones like you pointed out doing the heavy lifting in terms of doing the upgrades and fixing the code and so forth. But I think our responsibilities lie a little bit more on the validation and the verification side, right? Making sure that the software is up to date, making sure that there are no vulnerabilities. When I think of vulnerability management, that's what I think of, not AppSecSixing them, but AppSec, having the tools in place to check on them, right? And to encourage the developers and others to take action. Yeah, no, I agree with that. And I think I would add that, you know, like, I think the focus shouldn't be on fixing the vulnerabilities, honestly, right? Like, you know, I think the focus should be on, so what I think, you know, when I think of measures of vulnerabilities, the age of vulnerability doesn't really matter, right? Like, how long, you know, like, if I have a vulnerability on my website that's been there for 10 years, you know, the fact that it's been there for 10 years and doesn't change the fact that, you know, doesn't change the likelihood that it will get exploited in the future, right? Like, that's the, you know, that's the gambler's fallacy. If you, if you, oh, it's the longer it's been around there, the more likely it is. Well, not, not exactly, right? Like, if I flip a coin 10 times and it's come up heads every time, I'm not due for tails, right? It doesn't work that way. The coin doesn't have a memory. So, you know, but looking at the vulnerability rate, right? So like, how many, you know, how many vulnerabilities that are that matter, right? And that has important. A lot of vulnerabilities aren't important. They're not going to lead to kind of like any kind of compromise. How many vulnerabilities do you have that matter per like 100 machines, right? And have you gotten that to kind of an acceptable level because you're never going to get it to zero because there's always going to be something out there. But how do you get it to an acceptable level? For me, this is something that I've talked about in the idea of a security level objective, right? So you, as with the stakeholders in the organization, right, including leadership and engineering, you negotiate. Okay, like what do we think is an acceptable level of a rate for like number of vulnerabilities per 100 machines or per 100 endpoints, exposing or however you want to define it? All right, as long as we're below that rate, you just keep doing, you be you do whatever you need to. If it goes above that, then it tells us we need to shift more resources towards maintenance or towards automation to kind of keep that under control. And that's always going to be a push and pull. Absolutely. Absolutely environment changes for whatever reason. Yeah, I totally agree. I think the length of time that a phone is open to me demonstrates a certain level of maturity though. And there's a there's an exposure window risk there too. Like how quickly can you go from finding out that there's a vulnerability to actually fixing it? There's a lot of moving parts in that. You know, you need the tool to detect it. You need to be able to communicate that to the right team. They have to be able to know how to fix it. They have to apply the fix, which means shifting priorities temporarily to focus on that. Like there's a lot of moving parts there that I think you can demonstrate that you have a mature process if that window is is shorter. Right. That to me is really where it comes into play. But to your point, if you have a vulnerability that's been open for 10 years, that's a totally different conversation. Right. So yeah, no, that's good. I definitely am curious around. We were talking earlier about the the fact that security seems to be getting worse. Right. You're over a year, right? The dollar values of breaches and ransomware and so forth are going up. Number of records exposed are going up. How do we turn this around? You know, solve security for us. Yeah. I won't. As part of this question, I'm curious where AI and tech does fit into that conversation. So what do you think? This is so I'm going to come. I'm going to maybe go a little bit, a little bit of a left turn on this one. My undergraduate degree is an economics. And that's given me a unique perspective on the world to say the least. I mean, I think you're some might say, like, you know, if you've studied economics, you know, you have permanent brain damage as a result, right? But I actually honestly think the answer is what we need more than anything is regulation. And why say that is is because security spending, I think has a lot of positive externality. That is, if I as an organization, you know, like spend more on security, more of that benefit actually falls on the other organizations I interact with, the people that I interact with, you know, like, so if I'm Google and I spend more money on security, you know, that helps everybody that all of everybody who uses Gmail, everybody who Google services, it also helps people who are partnering with Google and running on their Google Cloud products, right? So, and because of that, companies are always going to tend to underspend on security as a result, right? So the only way around that is some kind of regulation that could be government regulation, or it could be some kind of private regulatory scheme. So it could be like insurance is actually a form of regulation that could bring that to the forefront. And, you know, like insurance, insurance premiums are basically a way to kind of shape behavior in at large scale. And actually, I think we're starting to see that happen. I guess the other way and this kind of ties back to engineers taking on greater responsibility is that professionalization of software engineering I think can help with that too, right? So in structural engineering, there was an accident in, I want to say, the early 80s, I think, Kansas City Plaza. There was a hotel there that had a walkway, a double-decker walkway over a ballroom that collapsed during like a New Year's Eve celebration. A lot of people died. It was because there was a change in how that was being built that had not been reviewed by the structural engineer who was supervising the project. And it led to reforms where that structural engineer has to sign off on changes, right? Because life safety is at risk. So I think if engineers take on the position that they have a moral and ethical professional obligation to build safe and secure software, especially if it's backed by some kind of professional association, that gives them standing to push back. So if they don't have that moral obligation today, their bosses can tell them to do something that they know is unsafe and insecure. And they don't really have any ground to stand on. If they have, hey, my professional code of ethics forbids me from doing this, or I could lose my license, or I'm gonna report you to my professional association for asking me to do something that you know is unsafe, that's a different conversation. And one last thing, interesting enough, the IEEE has a software engineering body of knowledge and security is part of that. So I think they're recognizing this and they're kind of at least starting down that journey. - I have so many questions when it comes to this. How about I start with this? - Sure. - How does that compare to the new trend of vibe coding? - Okay, so these are completely opposite. You're saying software engineers should be an official licensed position with ethical and moral standards and so forth and all that, right? The complete opposite is anyone can use AI to write code. So how does this compare in terms of what we should be aiming for and how do they, should we force one to be the other? Should we allow for both? Like how does this work in your mind? - Yeah, I think there's absolutely room for both, right? So, you know, like taking, you know, the structural engineering example, if you're building a bridge, you want a structural and professional license, structural engineer overseeing that project, 100%. Right? If you're building a tree house in your backyard, does anybody care? No, not really. I'm building a shed in my backyard. Like, do I need a structural engineer? No, right? Like, you know, it really depends, right? Not all code needs to be professionally engineered, but I think clearly some code does, right? Like the code running, you know, major financial transactions, just to be professional engineered, right? It has to do with the impact of failure, right? Like if I'm vibe coding some game and it doesn't work, right? Who cares, right? That's, I think that's fine. And I think it's good that we don't require, you know, professional engineers for any code that's created. Some code can be done by people who aren't professionals. Absolutely. Yeah, 'cause there's a creative differentiating factor there too. I want to create a business, right? I'm able to use the tools available to me to create some new app that's groundbreaking. Like, it's kind of what makes the economy go round, right? If you will. But I also think, so there's a bit of, like the structural engineer question is really based on a concept of like safety, like lives could be affected, right? Life and death lives. How do we translate that? And maybe this is just more awareness or something, but how do we make people more aware of the fact that if they share their personal information with these vibe coded apps, that there is a very real possibility that that could lead to something that affects them. Maybe it won't kill them. Okay. But it still affects them in terms of identity theft or, you know, some other thing. That could even affect their pocketbooks, right? Financial implications of losing your information. I think there's good news and bad news there, right? I think the good news is that I've actually saw something recently that suggests that the, you know, the personal risk of cybersecurity is actually pretty low, right? That if you're just a regular consumer, there's a lot of, you know, non-technical controls and protections in place, right? Like, so like, if I'm the victim of some types of bank fraud, that's reversible, right? Like, unless it's a wire transfer, which even wire transfers can be reversed if you catch it soon enough, you know, like your individual risk is pretty low, right? I think the bigger risk is more for organizations, right? So businesses, especially small businesses are more likely to actually suffer, you know, a breach. And while catastrophic breaches are rare, they do happen, right? There was a UK logistics company that got hit by ransomware, like a few months ago that actually went out of business, right? Like, they shut their doors completely. Even though I think they had cyber insurance, they were gonna negotiate the ransom, but it didn't matter. They were out operations long enough that their whole business just went into receivership. So it is very rare, but it does happen. And I think, you know, like you said, it's harder to be, you know, like, life safety is something that triggers greater moral outrage than cyber security. But there's certainly a real financial impact to it. And I think it's the right about, you know, drawing the line as a society and deciding what's, you know, what's an unacceptable level of loss of cyber crime. So it is life or death, but to the business, right? It can be sometimes, yeah. Could be the death of your business, right? Or something, or something like that happens. Well, that does tie back into what we were talking about around vibe coding allows you to build a prototype, create something that's creative and is a differentiator in the market, et cetera. But if you don't take the steps once it does catch on to protect the user's data, you know, et cetera, you might find yourself out of business at the end of the day. And I think that's the real risk to the point that you're trying to make. It's more to the business, not necessarily to individuals, but there has to be a bit of an individual risk there too. You're just saying it's sort of minimal, right? There isn't a huge impact. Yeah, potentially unless you're targeted specifically, right? I think someone who has your data is after you for whatever reason can do a lot of damage to you. Yeah, that's true. And that advice, I mean, that's true for the average person, right? There's certain people who are at much higher risk of personal cyber attack, right? So like if I have large amounts of crypto, (laughs) have I have a lot, if I'm sitting on top of millions of dollars at Bitcoin, my personal risk of a cybercrime is gonna be a lot higher than somebody who just has traditional banking. Yeah, you may not want to publicly announce all of that, right? Just how much you're into Bitcoin, that's right. Yeah, you could become a target if you do that. So well, we talked a lot about your pursuit of safety and how safety applies to security and what ways, et cetera. I've personally noticed there's a lot, like security is like this multidisciplinary thing. Like it pulls from a lot of other fields. And I'm curious if you see the world that way as well, you must just based on the safety side. But what other fields can be drawn from to help us make things better? Sure. So I think, I mean, it's helped many. I mean, I think it's, you know, security is a problem that many, many people can help us solve, right? So, you know, design factors into security, right? Like are we actually designing our systems well? Are we, you know, like are we giving good security warnings to end users? And they've definitely gotten better over the years. I think there is a lot of affinity between IT operations and security. They have very similar goals, right? And let's be honest, that's probably a similar relationship with the developers too, right? It's not, there's some natural conflict built into that relationship. That's actually one of my talks that you can actually go see for free right now. I gave a talk at SRECon, and that was, is the S in SRE for security. And it was really making the case that, you know, like your incident responders and your operations team, a lot of the tasks that, you know, as I talked about, between the operations team and the security team overlap, right? So they both care a lot about observability, right? For maybe some different reasons, but, you know, like the logs and the logging and the monitoring is very important for both groups. You know, handling responses. I think security teams would benefit a lot if they were more open in incident response at including their experience incident response team, right? So you definitely want your security experts there, but when you have, you know, an operations team that's used to responding to incidents like on it, like weekly or daily basis, depending on how large of an organization you are, that's a lot of skill in managing incidents and organizing the people getting them on the phone if you fail to take advantage of that. I think you're doing yourself a service. Yeah, that's great. When I think of some other fields that Security benefits from I think of three. Okay sales Oh, how to sell security. I heard this years ago when you become a security person You become a salesperson. Yeah, you have to sell this con you have to influence people to Change and I think that's my second one is is change management Organizational train change right organizational transformation digital transformation all right like all these disciplines that come into that Very much apply to security as well and then the last one that is top of mind for me as well is marketing like how a new product or technology Propagates across the market is a very similar model to how this new Security culture change or whatever change you're trying to make is adopted across your organization as well Right diffusion of innovation curve or the technology adoption life cycle very much comes into play when you're trying to make a change across your Org so just a few more examples from from my mind Thoughts about any of those No, I would I would agree with all those again. I think I Any it all depends on this situation. I think you know, I think I You know sales for me. I think I I think yes and no I have a little bit of a reaction to that just because you know for me you know I've always been of the mindset that security is decision support right so like are you helping your leaders? All the way up to your CEO make good decisions about the level of security performance that they have in terms of the risks that they're facing Are they managing the risk to an acceptable level which both means that they don't have too much risk But they could have too little risk too right like You know a friend of mine was asked that by a let's say an enlightened CFO once like do we have too much risk? Do we have too little risk and the point is well taken right like if you if you have no exposure to risk That's going to impact your growth and your profitability right like you know exposure to risk is it's part of life It's part of doing business. So You know what that reminds me of is companies hire pricing professionals to right to come in and help them figure out how to price their goods and services. Yeah You actually want to lose people on price Because price is a factor because that shows that your price is not too low right so there's like this nice middle ground and I what you just set around You know do you have too much risk versus do you have too little risk is is the same like are you doing enough? But also are you allowing for enough risk because you're trying to do things that are different or innovative Etc. I think that's an important point. So that's great How do we get leaders to Help encourage Higher quality software in general like we were talking a little bit before around yeah There's a major benefit in terms of being proactive to prevent Issues down the line right trouble shooting or fighting fires How do you frame that conversation is that something that you've run across before? Um, I think that's a tough one That's a really tough one You know, I think I Think so it's interesting. I think it's it's more than just about buy in from from leadership right so When I talked about the need for quality and the need to give developers the time to do it right At a previous organization You know, I I had a leader stood up in a full auditorium and said absolutely you know what John said is true like I Want you to take the time to do you know the security updates to do the maintenance like you know like they was prompted by a question like I'd love to really be able to update my software But you know like my immediate supervisor tells me we don't have time to do that. What do I do? And I basically said we'll do it anyway because it's you're part of your job as an engineer and Then one of our BP stood up and said yes, absolutely right so it was interesting You had the leadership at the top wanting to do it right? You had the the engineers wanting to do it right But what I found and I kind of was you know thought about this when I reflected on it is The people that controlled the budget right that kind of mid-level managers the middle management that was responsible for the budget There were the ones telling me I can't spend that much on maintenance because my budget doesn't allow it So I think it's really important to you know how you know like basically that has to be baked into how you make decisions throughout the organization right So like you know like you know, you know, if you're the C so you know, it's it's a lot like You know an HR role or a C or a CFO role right you're there to kind of like show the budget Show where things are deficient show the risk And I think in the end the the method that I've seen that works best is Honestly speaking business terms which often means risk quantification and talking in dollars and cents right so that You know like if you're the C so if you're essentially the head of security You should understand the impact of security failures to your business and express things in terms of that You know, that's what you know success your but you know your job as a security professional is to support the business mission And if you can talk in terms of how security supports that business Business mission. I think you'll you'll get better results and There are now you know like increasingly better methods of risk quantification and how to do that you know you then it's scale so That makes a lot of sense, but I would like to offer something that has come out in my experience many times and that's people will say it like leaders Have no trouble saying security is important right do that fix that The problem is when I think the rubber meets the road in terms of The time required to do it the way that you're saying to do it right Which could affect some of the other business goals that they have potentially right now in the long term out argue That they're actually going to going to be able to increase um Production of new features etc if they do it right to begin with I would make that argument But I think again the problem comes down to yeah, you know fix it like the person that stood up and supported you But what does that mean does it mean developers work over time to fix it? Yes fix it Or we can't really give you any extra time to fix it So we're still going to say fix it, but it's not actually going to translate into an allocation of time to actually You know Pursue the fix. What do you think of that? I mean, I think that's very true. I've seen the same thing Okay, I mean, I think it's it's a very tarp. I'd like to give you a better answer I don't really have a good answer to that yet. That's That's something I think is very challenging that I think um, you know most experienced security people have to have to deal with Um Yeah, we're just we're just not there yet. I think You know one of the big challenges with with security um is that You know like security incidents are you know, you know, in large impactful security incidents are very rare So if you're at a single organization, you're not going to have ever have enough data to really understand what works And how much you know, that's you know, how much risk does that really reduce right? It's only by looking across organizations that we get that and thankfully because you know more and more companies are buying cyber insurance and filing claims The insurance companies. I'll say there's still very early on um Uh, given by the presentations I've seen including by insurance companies Um, but they're starting to actually starting to figure out they're starting to understand what what does work in cybersecurity So yeah, it's great Hopefully we can start to bring those concerning numbers down The trend is going the wrong way. Let's let's let's do it fix that All right, well, we are running short on time unfortunately. I've really enjoyed this conversation I would like to leave the audience with a takeaway from the conversation from you specifically do you have anything that you want Uh, to sort of stick out in people's minds as they walk away from the episode here Sure, I think you know the the one thing that you know kind of really stood out for me um In the role of a safety professional in terms of kind of modern, you know modern safety science is that That I would bring to security and then I've kind of brought to security throughout my career is Deke to understand how work is actually done right so that means be curious You know like Go talk to the people who are doing the work that you know that matters right so if you're a security person Go talk to your operations team go talk to your software engineers, you know like even sit down and kind of watch, you know, like say, hey, can I just like, you know, watch it work for a while, right? Like you can learn quite a bit just by actually trying to understand like how they do their work. And you know, with that that gives you, you know, with your expertise that gives you what you need to know to help make their work more secure. I love that. I appreciate that, John. I mean, it just makes me think of your, like someone's comfort level in terms of what they know versus what they don't. And I think there's a curiosity that comes with or just through knowing more, you know what I mean? It's almost like done in Kruger, right? The less you know, the more you think you know. So I think the more you learn, the more curious you're going to get. And I definitely would encourage that as well. So anyway, John, I really appreciate it. This was a really fun conversation. So thanks a ton for coming on the show. And I hope you have a good rest of your week. Yeah, thanks for having me. 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.