--- title: "Chris Romeo -- Security Culture Hacking: Disrupting the Security Status Quo" url: https://appsecpodcast.com/chris-romeo-security-culture-hacking-disrupting-the-security-status-quo/ date: 2018-12-10 duration_seconds: 1935 guests: ["Chris Romeo"] topics: ["OWASP Top 10", "Building an AppSec Program", "Security Culture"] audio: https://www.buzzsprout.com/1730684/episodes/8122660-chris-romeo-security-culture-hacking-disrupting-the-security-status-quo.mp3 transcript: true --- # Chris Romeo -- Security Culture Hacking: Disrupting the Security Status Quo *December 10, 2018 · 32 min* with [Chris Romeo](https://appsecpodcast.com/guests/chris-romeo/) on [OWASP Top 10](https://appsecpodcast.com/topics/owasp-top-10/), [Building an AppSec Program](https://appsecpodcast.com/topics/appsec-programs/), [Security Culture](https://appsecpodcast.com/topics/security-culture/) [Audio](https://www.buzzsprout.com/1730684/episodes/8122660-chris-romeo-security-culture-hacking-disrupting-the-security-status-quo.mp3) ## Show notes Changing security culture requires more than distributing policies or buying another training platform. In this recorded AppSec USA presentation, Chris Romeo shares practical ways to influence how an organization thinks and acts about software security. He explains why every organization already has a security culture, how to assess it, and why the assessment must lead to action. The talk explores speaking the language of developers and executives, sharing information openly, building a champions community, and recognizing useful behavior. Chris also describes learning experiences that fit developers’ work and demonstrations that make application risk concrete for leaders. He closes by connecting culture change to observable outcomes, including whether teams resolve security problems more quickly over time. The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/). About Security Journey Security Journey provides application security education for developers and everyone in the software development lifecycle. → [Learn more about Security Journey](https://www.securityjourney.com/) Connect with Chris Romeo: → [Chris Romeo on LinkedIn](https://www.linkedin.com/in/chrisromeo-appsec/) Mentioned in this episode: → [OWASP SAMM](https://owaspsamm.org/) → [OWASP Juice Shop](https://owasp.github.io/www-project-juice-shop/) → [WebGoat](https://github.com/WebGoat/WebGoat) → [DevSlop](https://github.com/DevSlop) Chapters: 00:00 Security culture hacking at AppSec USA 08:05 Every organization already has a security culture 09:53 Transparency and sharing security knowledge 10:07 Assessing and measuring the starting point 11:39 Turning assessment into an action strategy 12:34 Learning developers’ language and methods 13:49 Speaking to executives about risk and value 14:24 Communication and security’s own assumptions 17:37 Building a deliberate security community 18:06 Champions programs and learning sessions 19:57 Recognition and incentives for useful behavior 22:45 Developer-friendly learning and hands-on practice 27:43 Educating executives about application security 29:04 Demonstrating risk and measuring improvement ## Transcript *6,574 words · assemblyai* **0:00 Chris Romeo:** Greetings, friends. Season 4, episode 20 of the Application Security Podcast. On this episode, we are playing a talk I did at AppSec USA on security culture hacking. I went through 20 different ideas that I use when I go into a company or an organization where I focus in on how do I positively change and impact security culture. So, I hope you enjoy. The Application Security Podcast. Security Podcast. Here we go. All right, so the name of this talk today is Security Culture Hacking: Disrupting the Security Culture. status quo. So what we're gonna find here is I got a lot to say in 35 minutes, so I'm gonna keep moving and I'm gonna try to land the plane here with about 5 or 7 minutes for questions at the end. So a little bit about me. I'm the CEO and co-founder of Security Journey. So our focus is on application security training at scale. So how do you train 5,000 developers? That's kinda what I do in my day job right now. I've been around the world of security for a long time, and I'm also the co-host of the Application Security Podcast. So show of hands, who's heard the Application Security Podcast? Okay, a couple people. There's a fan in the back. That's always good to have one fan, right? Yeah, so our focus with the podcast is really we just interview a lot of different OWASP people doing cool things for chapters and different projects, so it's a good way to learn more about kind of what's happening around OWASP. But I'm also part of the OWASP Triangle chapter leading that, So here's what I'm gonna talk to you about today. So I wanna introduce this idea of security culture hacking and then talk about the kind of the, what does a security culture hacker actually look like? I'll talk about what we need to do before we start and then I've got 15 specific security culture hacks plus one that I learned at lunch today that I'm gonna throw in for free. But so I've got 15 different hacks that I've kind of put together over the years in influencing security culture. And then we'll talk a little bit about metrics you can use to measure your success, and then I always like to leave you with an apply slide that tells you here's what you could do if you wanted to take the things I'm talking about and go back to work on Monday and start executing against these ideas. I'll give you some things to think about. So I spent 10 years of my career at Cisco, and 5 years of my time there was focused on changing the security culture at Cisco, so I've actually done this at scale. And I've also done this with small startups in the last couple years. So I've had a chance to do it with 25,000 developers and 5. And so that's where a lot of my thinking is coming from, is from that perspective. So I guess first we have to think about when we say security culture, what do you even think that means? What does that mean to you? Do you think the impact of a single attack or a single event or some type of social engineer? When I think of security culture, it's not about a single, it's not about a person, it's not about an attack, it's about how does everybody in our organization approach security across the board, everybody from end to end. And we don't fix that with a single team or a single person because I have yet to find a company where they say, yeah, we have the same number of security people as we do developers, right? Nobody in here is gonna raise their hand and say that. Like maybe even if you had one, maybe. Maybe if there was like one developer and then one security person, I'd buy that. But if you told me you had 100 and 100, I'd be like, no, you don't. That's a lie. So it's the security culture change is about how do we get everybody on board with this whole security thing. And so this is a definition that I put together of security culture. And I actually put this together collaborating with a relatively famous person named Tim Ferriss who has a podcast called The Tim Ferriss Show and The 4-Hour Workweek and everything. And so the extent of our collaboration was he wrote this great definition of culture and then I added with security into it. And so that was the extent of the collaboration. What happens with security when people are left to their own devices, that defines your security culture. I don't care anything else you wanna talk about, about any of the programmatic things. When that developer is sitting there at 4:35 on a Friday, because we always have bad things happen at about 4:30 on Friday. When they're sitting there and they have to make a decision when you're not looking over their shoulder, that defines your security culture. Do they make the right decision? Do they say, you know what, I can't ship this feature. I'm gonna have to hold off and wait. I'm gonna have to wait till Monday. The customer's gonna be unhappy, my boss is gonna be unhappy, everyone's gonna hate me. Do they ship the feature or do they hold back and say I'm gonna wait and do the right thing and fix it? Or do they ship it and say let's make it happen? That defines your security culture right there. That's the only, the best way I can think of to define it. When we think security culture, this is a people problem. This is not a process problem. You gotta have process to support your security culture, but it's not a process problem. It's not a tool problem. So if you're a tool vendor out there, get ready to throw something because you don't solve security culture with tools. Sure, tools are good, tools are supportive, but they're not the answer. It comes down to the individual people. The people are the ones that make the changes that we need to impact security culture. So when I think about security culture, here's a couple of the goals that I have. And sometimes I get to go into an organization and they say, our security culture is not good, will you help us change it? So here's some of the things that I'm trying to do when I'm working with those organizations, and you can apply this directly to your company as well. So the first one, I want everyone to have a shared responsibility of security. I don't care what their job function is. If you ask the question, who in this company is a security person? I want every hand to go up from everybody across the board. Does everybody have the same responsibility level? Of course not. Everybody has their own piece, but if we have a culture where everybody's thinking, yeah, I own a little piece of this, and I gotta do the right thing here when I have the chance. I wanna see a culture of, a mentality of security first. That's a bigger hurdle than a lot of the other things that I even have on this list, but that's what I wanna strive for as a goal. I also want everyone to have a base level knowledge of security. We do these things where we're like, we're gonna get all our developers to do security and we're gonna be more secure, and then you don't teach them any of the basics. So they're just supposed to what, figure it out on their own, right? I mean, developers are smart people, but they're not gonna go learn application security on their own. They're not gonna go define vulnerability, exploit, and threat and write out a paper on that without a little bit of a push or you providing something to them. The last piece is we have to know the impact of investment, right? Everything we do has to tie back to business. And we're gonna talk about executives here in a little bit, but everybody should understand the fact that we're making an investment in security, and what are the results, what are the returns gonna be based on that. The other thing here is we gotta avoid the security status quo. And when I think of the security status quo, it's like I hear people like, ah, you know, I just wanna be average. I don't wanna be the best. I don't wanna have the best application security, but I certainly don't wanna have the worst. and be seen as one of the worst data breaches and things that are happening. And so how do they measure that, being average? Well, I wanna have less breaches than my competitors. That's a terrible metric, right? For doing anything. Like, oh, I just wanna just not give up as much PII as the next people. I wanna have less vulnerabilities. The lack of security as a competitive advantage. And here's something for you to think about. If you're sitting here today and you're thinking, yeah, this security culture thing, this sounds kinda interesting. **8:04** Yeah. **8:05 Chris Romeo:** But I don't actually think we have a security culture in my organization. Heh, got news for you. If that's the case, you have a security culture, just it sucks. That's the difference, right? Because if you think you don't have one, you do. Everybody's got one, right? It just comes down to how actually good it is. Now does security culture take time? Of course. It's not gonna be like an episode of NCIS where we can hack something in 15 seconds, right? Security culture change is a multi-year effort. It's a 1, 2, 5-year plan. I mean, it was only 5 years into my time trying to change the culture at Cisco where I really started to see cool things happening. I had to spend all those kind of dark years going, man, I don't think this is even working. I don't think anybody's even paying attention. And then slowly over time, we saw more and more people get excited about it. So it's not as easy as hacking something kind of one at a time. Here's a definition of security culture hacking. So applying a series of shortcuts or tricks for getting an organization to focus on security. Look at that catch at the bottom. One person at a time. One person at a time is my kind of approach here. Sure, we gotta do things on the macro level. We gotta get everybody involved. But it really comes down to influencing each individual person as we go. Okay, so I borrowed this from Facebook. I thought, wow, they've got this really cool thing called the, kind of the Facebook way or whatever. And I started thinking about it, it's like, there's some really cool stuff there if we cross off build social value and add security value in there. But focusing on the impact, impact of security, the same thing applies from a security perspective. We do wanna move fast, be bold, be open. So many times in security, what do we do? We're always about, well, we can't tell you that 'cause that's top secret. You have to have a level 20. **9:53** Right. **9:53 Chris Romeo:** to understand that piece of information, right? No, why can't we be transparent? If we wanna play in a DevOps world, what happens in a DevOps world? We're all there now, right? Do DevOps, is DevOps successful if you hide all the information from each other? **10:06** No. **10:07 Chris Romeo:** No, it falls apart. It doesn't even work if you hide all the information. So as security people, we gotta be more open. We can't be so afraid to share our information and share our experiences with the people that we're working with. Okay, next up we have this idea of measurement. So if you're gonna change your security culture, you gotta know where you are today. And the nice thing in the OWASP universe is we have this tool called OpenSAM. And so OpenSAM is a tool for measuring the current, I guess, capabilities and assessing how good we're doing for a software security program. Nice thing about OpenSAM is it also gives you a pretty nice security culture metric or readout as far as where you are. Some of the things in the OpenSAM are gonna be more specific in that you're going to be talking to developers and asking them questions about how they experience security. That's a part of what you're gonna measure in your assessment. But it's definitely something that you have to do. And the important thing with this type of assessment is you can think of the OpenSAM as It's a good way to capture where are we today. It's also a great way to capture where do we want to go tomorrow. So it's got a roadmap kind of built into it. You can go through there and say, okay, for education and guidance, we're at a level 1, but we want to be a level 2 by next year. Look at the activities under the level 2 that we have to do. You can almost reverse engineer your culture and do the necessary things to try and kind of move yourself forward along the way. **11:37** Great. **11:39 Chris Romeo:** So that assessment really has to become a strategy though. Don't be one of those organizations where you assess the crud out of everything, but you never actually do anything with the results of it, right? You have to, this assessment has to become a strategy, and so I'm gonna share with you 15 different hacks that I've experienced in different companies. You gotta choose the ones that you need to use now, and just know that you can't use them all simultaneously. It's just not gonna work. There's just too many things out there that you gotta do. So let's start with some basic hacks. And so, just so you know, there's, there's probably some people in here, in the room that are thinking, you know, this is way too, this is gonna be way too beginner for me. And so I thought about yesterday, I was listening to some other talks. I thought, should I go back through and take out all the basic stuff? And I said, you know what, I shouldn't. 'Cause I'm gonna give you my perspective on it. And some of these things you may already know, but I guess what I'm telling you is you will take something out of this list of 15, even if you've been doing this for 20 years. **12:33** Yeah. **12:34 Chris Romeo:** There's something in this list of 15 that you didn't know. I wish I could give like a giant prize if someone could come back and argue with that with me, but I didn't have a big prize budget for this. So what button do I press to hack someone? So the first hack that I have in this is learn the methodology and lingo of the groups that you're going to try to influence. That seems kind of simple, right? Too many times I've seen people that are trying to influence developers, But yet they can't answer that stack of bullet points right there as far as what, they can't tell you the difference between frontend and backend. They can't tell you what responsive design is or an API or frameworks and why they're important or DevOps versus Agile. You have to speak the lingo of the people that you're trying to influence. If you come to the table with developers and they're frontend people and they're using React.js to build their frontends and you ask 'em, What's React? Right, you've just, they've already, they've canceled you out. You don't exist anymore, right. They're not even gonna talk to you anymore. They're like, whatever, like, you're, you're a non-factor. The same thing applies when you're gonna imp— impact executives. Cause we gotta impact both groups here. Developers and executives. How do executives think? Do executives love the greatest, coolest new technological thing? **13:49** Sometimes. **13:49 Chris Romeo:** Sometimes, but not usually. What do executives care about? What's the risk? How much is this gonna cost me? How much is this gonna make me? That's really all they care. So when you're talking to them, if you start talking about, hey, we got these new great static analysis tools, you know what happened? Their eyes glazed over after about 10 seconds because they don't care. They care about how much money we're gonna save or how much money we're gonna make based on this great idea you have. And so you gotta speak their language as well. You gotta speak revenue generation and risk and cross-functional integration, executive summaries, all of these things fit into hack number 1. **14:21** Yeah. **14:24 Chris Romeo:** So hack number 2, communicate and don't believe the hype. Some of this is a, I guess, a mindset that I think we have as security professionals. We think we got all the answers. And I think that's one of the things that really, oh wait, we went a little too far here. Look at that, I'm jumping ahead. Ha, right back there. Yeah, so don't believe the hype, right. So we think we have all the answers figured out. We don't, we think we can't really learn from these developer people. We're here to tell them what it is, how it's going. I guess something I've learned over the last maybe 5 or 10 years is that I got something to learn from everybody. I don't care who it is. Everybody's got something to teach me about their specialty. I really learned this when I started to do a lot of threat modeling, and I realized I kinda understand the threats, but I'm not the expert in how this developer's creating this particular feature. They're the expert. So let me ask them a whole bunch of questions and learn everything about their thinking for how they're doing it. So hack number 2 is just learn how to listen and collaborate with the people you're trying to influence here. Stop trying to think like you got all the answers and everybody needs to kind of listen to you because you're from security. After the break, we'll pick back up with hack number 3 in security culture hacking. The Application Security Podcast operates with support from Security Journey, a security belt program provides the 3 pillars of successful AppSec training: learning, application, and experience. Visit us on the web at www.securityjourney.com to learn how you can teach and empower your developers using a new kind of security training. Now we're picking back up with security culture hack number 3. Okay, here's another one that I like to do. This is working all the levels on the communication side. So we talked about developers, we talked about executives. They tend to be at different ends of the organizational chart, right? The executives are kind of at the top and the developers are on the, kind of on the ground floor. And so when I think of hacking a security culture, we have to do different things to reach both levels there. We should specifically be trying to focus on the developers who are on the ground. What do we need to do to get them excited about security and get them to push it forward? But then there's also a different conversation with the executives about why these things are important and why they need to focus on them. And it's not the same message. If you go to both of them with the same message, good luck. One of them is gonna laugh you out of the room. I'm not sure who would laugh louder, if it would be the executives or the developers, but one of them would laugh you out of the room. And so personally, I'm more of the bottoms-up type of person. That's just how I approach this, this, security culture change. I like to work with the people on the ground and basically force the hand of the executives when you get to a certain kind of critical mass of people that are excited about security. Then the executives will stand back and be like, yeah, this is a great idea. We should do security. And then I'm just standing there going, yeah, we should. That's a great idea. I'm glad you thought of that, boss. Good idea, right? Because it's already— but I'm okay with that. I just want to change the security culture. **17:36** Yeah. **17:37 Chris Romeo:** I don't care who gets the credit for it. So community-based hacks. So how are we gonna build, bring our group of people together? And so you've heard this a bunch of times already about building deliberate security community. I guess my, I guess what I'll add on top of it is there's a couple of case studies you can look at. If, say you have a security champions program but you're just, it's not where you think it needs to be. I'm not gonna tell you what that is for purposes of this session. But there's a couple of different companies that have been really good in the security community side. **18:05** Yeah. **18:06 Chris Romeo:** Adobe, Salesforce, and Cisco have all robust security champion-style programs and have been willing to talk about them in more depth. And so the point is you gotta do some amount of deliberate security community. You can call it whatever you want, advocates, guilds, champions, ambassadors, I don't know, whatever. But the idea is teach a core group of people and invest heavily in them and then send them out to do good and teach more people across their organization. So that's community. Okay, everybody, or most people that do champions do this already, but I'm gonna say it anyway 'cause I learned something new about security office hours as well. But another hack you can do is if you're doing any type of security community, you have to have some type of monthly gathering. That is the cadence of the security champion of your community-based efforts. You have to do something where you're bringing everybody together once a month and you're teaching them. And here's a bit of a, a bit of a something you may not have even thought about doing before. But if anybody, if you run these type of sessions, what are you always doing? You're always hunting for content all the time. Like it seems like a full-time job. Who we got speaking next month? What I found is that if you reach out to people in the industry, many people will join a 30-minute web conference. Many people that speak at conferences will come and speak to your security champions for 30 minutes. over a web conference if they can do it from their office in their space. Now, if you want them to get on an airplane, forget it. They're not getting on an airplane to come and talk to your people for 30 minutes. But they'll do a web conference. Almost anybody will. I've done a few of them in the last couple years, where people just reached out and said, hey, would you come and do that talk for my group? And I'm like, yeah, is it a web conference? They're like, yeah. I'm like, is it a time when I'll be awake? They're like, yeah. Okay, then sure, why not? It's 30 minutes of my time. I already have the talk prepared. I don't have to do anything other than dial in. So it's a 31-minute commitment. I gotta dial in a minute early, and then— **19:56** Yeah. **19:57 Chris Romeo:** jump into the session. So if you're running this type of community, don't be afraid to reach out to people that you saw talking at this conference right now. As long as it's a 30-minute window you're asking for, you're gonna be, it's gonna be tough to find somebody who, find people that'll be like, no, I don't have time for that, right. I don't wanna help move the community forward. Security-focused office hours too. I've seen this work in a couple different organizations and for whatever reason, some developers are a little bit reluctant or a little bit afraid of interacting with the security department. I think that's part of our department of no and the fact that we're not super maybe approachable. But I've seen some organizations do this idea of security office hours, and you can do it virtually, you can do it in person if you have an environment where everybody's kind of working together. But security office hours is just like it sounds. It's like, you know what, for 2 hours on Wednesday afternoons from 2 to 4 or whatever, we're gonna be hanging out in this public area. Come and ask us questions. Come and stump us. That'd be awesome if you came and asked a question and we couldn't answer it. That would be such a cool challenge. So the idea is just being available where the developers can actually meet up with you and have some discussions with them. All right, number 6, host a security-focused hackathon. And so I met somebody at lunch and he was telling me this idea that they had about doing— so hackathons is let's get the champions all together, let's hack GShop or something else that exists in OWASP. He said that, and this is, I don't think he's in the room, Fredrik from Stockholm who I met over lunch. One of the companies he was aware of is doing an internal bug bounty for developers. And I, yeah, aha, I said the same thing all of you did. Oh, so then a developer can create a bug and then collect money for it? He said, no, they give away candy. Candy is what they give away. So there's, who's gonna game a system for a piece of candy, right? So it's, it's using, somebody, would somebody say yes, they would? Oh, right here, the guy in the back, come on. How big a piece of candy? Like, does it have to be like giant Hershey's Kiss or something? I mean, come on. **21:58** But— It's just candy. **21:58 Chris Romeo:** Yeah. I mean, it, but listen, if it was $100, then you gotta worry about nefarious people going, hmm, I can just make this bug and find this bug and I get $100. But for a piece of candy, it's all about bragging rights amongst that development team. I just, I thought that, and, and there's another pitch for why we come to these conferences, right. And don't just sit with all the people that you know. I didn't know Fredrik from Stockholm when we started to eat lunch. We started talking about this subject and that was his, he goes, oh, I saw this, something really cool happening. I'm like, that's cool, I'm gonna talk about that, thank you. Okay, content-based hacks. So when we approach teaching developers about security, there's, we've done a lot of injustice in the past in that we have tried to teach them using really terrible materials that are out there, like things that we call e-learning. I know we all kind of shudder when we say e-learning, ugh, come on. **22:45** E-learning. **22:45 Chris Romeo:** What I found in working with developers is that if you can give them something that's more fun for them to consume, something that fits better across what they're trying to do, so it's not like we're trying to take them— it's really hard to take a developer for a week and put them in a classroom, right? In the way that modern software is delivered right now, it's just— we're asking a lot of them. Then the last part of that, using modern approaches here, is how do we give them some type of hands-on experiment? It's great to teach them about things, but then you gotta let them do things. And that's when they get back to their keyboard after they've had this experience with you where they start to do things a lot differently. Okay, hack number 8 here is gamify and provide a path with security education. So this is the 3 companies I talked about in the champions as well. What they do is they have security training programs that have various levels, and then people begin working towards their white belt or their apprentice. Whatever reason Salesforce on the right flipped their chart upside down. They didn't get the memo. They're supposed to start with the lower at the bottom and work up. But on the far left over here, my left, your right, is Adobe. In the middle is Cisco. And on the last one here is Salesforce. What the hack that exists here is when you approach security education, you have to give the developers a path. Don't just throw them into this class, 'cause then when they get back from the class, they sit back at their keyboard and they go, now what am I supposed to do? Back to work as normal, right? Give them a path that takes an amount of time to go through. And they learn different levels and different lessons as they go. And so there's 3 great examples from some big companies about how you can actually do that. So then on the recognition side, I gotta say, this is one that I've always struggled with a lot, just because I like, I don't know, I'm kind of of the opinion like, just do your job and that's reward enough. But what I found in what I did at Cisco was when somebody would achieve something in our kind of champion program, I had an automatic way to send them an email and then send their boss an email too. And it looked like it was a personalized message from me, heartfelt, all that other good stuff. It was a script. I wrote the heartfelt message one time to somebody and then I copied it and turned it into the script, okay? But it still, to them, it was a small touchpoint. It cost me almost nothing. And then what I also did is I'd recommend their manager give them some cash for something cool that they did. Why not, right? I mean, $100 is, what does it cost for a data breach? What's the average? IBM's latest study says what, $3.8, $4.3 million, somewhere around there is what a data breach costs. $100 that I give somebody for doing something to improve security, if that even stopped, if we even stopped one event per year, I gotta give away a lot of $100s before I get to $4.3 million. It's gonna be hard to give away that much money. Okay, so if we're gonna focus specifically on developers, number 10 is all about using the OWASP Top 10 in a lunch and learn format. We all know the OWASP Top 10, no reason to really dive into it here. It just makes, it's a great lunch and learn style format. Take one of the OWASP top 10 items, go through it, dive deep into it. This means you gotta understand it though, 'cause you know what those developers are gonna do? They're gonna start asking you hard questions just to see if you know what injection actually is. So don't be afraid to say, I don't know the answer to that, let me look it up. I say that all the time. Hack number 11 is unleash the proactive controls on your organization. I have been shocked as to how few people actually use the proactive controls with their developers. And I, I guess I'm shocked partially because I didn't even know the proactive controls existed until about 18 or 24 months ago. It's, it was out for a long time before I even knew what it was. And so, if you don't know what it is, this is the answer to the OWASP Top 10. This is the things we need to do to prevent the OWASP Top 10 issues in the code. It's written for developers by developers. It's an OWASP project. It's an awesome thing. Check it out and figure out how to roll it into your program. I like to do those once a month for the proactive controls. 'Cause they're a little more complex as, because they're all the fixes and things we have to do. You know what, in this day and age, at this conference, I probably don't need to say threat model. Threat modeling's not even really a hack anymore. It's something that we just have to do. And then hack 13 here, give them something to break. Developers like to break stuff. Usually we think that they like to build stuff. They like to break stuff too. And so the idea here is OWASP has these multiple different projects that are available. They have Juice Shop, they have WebGoat, they have DevSlop, which is a new microservices-based application that Tanya Jenka and Nicole Becker are working on in the OWASP, from OWASP. DevSlop is all about microservices. How do you have vulnerable microservices? 'Cause we're all going that direction. We've all got microservices for everything now. And so let's have a vulnerable way. So the point here is give them something to break though. Let them break this stuff and then be able to, they can actually experience a SQL injection. So it's more than just me telling you and lecturing you about SQL injection. Now go do it. And that's when that light bulb goes dink, turns on over their head. They get it. **27:42** Yeah. **27:43 Chris Romeo:** All right, executive-specific hacks. If there's any executives in the room, I need to ask you to leave now. Just in case any humor ensues, and I don't want someone to chase me around the conference again. I mean, happens one time, everyone talks about it, whatever. Hack number 14. So, you gotta educate your executives about application security and product security, but they don't have as much time as everybody else does. They don't have as much time as a developer. So you cannot give them a 2-hour-long thing to listen to, 'cause they will listen to exactly 17 seconds of it. And then they'll get busy and do something else. So create something that's tailored towards your executive team that prepares them to understand that business side. So the things I'm talking about here, business case of security, culture and mindset, I'd like them to understand the things I'm talking about right now about how important culture is and how they can set that kind of bottom, or that top-down culture perspective. Talk about resources. I mean, these are the things that I wanna see the executives understand. And my final hack, Break whatever you build in front of your executives. If you wanna see executives figure out how much they care about security, break whatever it is that you build right in front of their eyes. We did this at Cisco. We had an internal penetration testing team come in. We had a time in Cisco's history where people didn't, executives weren't giving security the right amount of attention. So what we did is we set up a high table across the front of the room. We had about 30 executives. **29:03** Wow. **29:04 Chris Romeo:** 40 or 50 executives in the room, SVPs, VPs, kind of high-end people, and the pen testing team set each of their products up on this table, and they went one by one on the overheads and hacked each one of them in real time. And you've never seen so many mouths just hanging open. But it was a moment, it was like bang, it was like a flashpoint, 'cause they were like, oh. That whole idea of we don't really care that much about security anymore changed in an instant, 'cause they were like, Whoa, isn't that the thing we build up there on the left that that guy just broke into in 2 seconds? Okay, so I'm almost out of time here, but here's some things to think about from the overall measuring security culture change. So the metric that I really like the best is I like the kind of security bug fix rate. That's what I think is the best measurement of culture is how fast are these actually, these issues being fixed? Are we, is our time to fix going down over time? Like when we start, maybe it's 200 days. Do we get it down to 100 days, 50 days? That's what I think of as a real solid metric. I mean, we can look at flaw prevalence and who's been educated and how many things we're doing, who's engaged with our community. Another one that nobody really ever does is measure positive engagements with the security team. Give the developers some way to react to an engagement with the security team to say, whether it was a green or red type of an event that happened. So there's all 15 of them in one collection. I should jump down so you can have my picture in the bottom if you want to take a picture of this. I could hang off the stage, but that might be dangerous. So the slides will be available from OWASP too. I still hear some flashes going off. All right, let's talk about the apply slide real quick. So what do you do with this? Like I said, you gotta start with the assessment process. You have to understand where you are from a security culture perspective. Don't assume you are where you think you are. You gotta do that assessment and go through and ask, don't just ask executives, don't just ask managers, right? Ask the developers. Ask them how we're doing with security. Get the executives' and managers' perspective as well, but don't rely on that only. That can be dangerous. Pick a couple of basic hacks for your first 3 months. Work out your rewards and recognition. You can use that to feed all the other things that I'm talking about here. All of those pieces can come together. And brainstorm at least about what you're going to do with your community. How are you going to form it if it doesn't exist now? How are you going to make it successful? Within 6 months, you, you really need to launch that community, take that rewards and recognition and roll out, and then start picking more things off the list that you can apply along the way. **31:44** Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org. --- Source: https://appsecpodcast.com/chris-romeo-security-culture-hacking-disrupting-the-security-status-quo/