Chris Romeo -- AppSec Awareness: A Blue Print for Security Culture Change

0:05Chris RomeoThe Application Security Podcast. Here we go. Good day, my friends. For this episode, we bring you a recorded version of my security conference talk from 2016. The talk is entitled AppSec Awareness: A Blueprint for Security Culture Change. I cover the problem space, or why do we need application security, how to create sustainable security culture, and introduce the idea of application security awareness. I had the luxury of building such a program while at Cisco and share my experiences here with the community. There are slides available to correspond with this talk. They aren't required, but some people may want to follow along. If you want to download a copy of the slides, visit speakerdeck.com/edgeroute to get a copy.

1:15Enjoy!

1:16Chris RomeoThe first thing that I think about here is Marc Andreessen had this quote a number of years ago, and I've really— it really resonates with me. And that's just the fact that software's in everything that we're doing. So that really, when someone asks me the question, why should I even care about application security? Well, because software's in everything, and software that's not secure opens us up to so many different types of challenges. Things— think about where software is between mobile apps, cars, smartphones, medical devices, power plants.

1:49Yeah.

1:49Chris RomeoSoftware's everywhere and it's a part of everything that we do. I haven't yet in the last number of years sat across the table from a customer who said, I just don't care about security. Keep this thing running, make it operational, try and give me the best possible features, but I don't care about security. Because I don't think that conversation's happening anymore. People care about security. They want security in everything. It's even being listed in RFPs. I've seen requirements where companies in an RFP are saying, I demand that you follow your process. Seems like a crazy thing to have to put in an RFP, but the point is the demand is there. Folks probably know what the OWASP Top 10 is. If you don't know, this is the top 10 most major vulnerabilities that exist in web applications. The OWASP folks do a great job of defining these and really providing some nice resources to understand them. So I'm not going to go into the depth of what that is, but I gave you a link there in case you wanted to check it out later. I share that to provide some details that came out of Veracode's last State of the Software report. And that's just a breakdown of how bad does different industries respond to the OWASP Top 10. So what these percentage values show you is based on an industry perspective, what is the percentage of applications that Veracode tested that failed some part of that OWASP Top 10 during their initial assessment? And so you look at that number and you say, wow, 58% of financial services failed. And that's the best— that's the folks that were the best, all the way up to 76% for government organizations. And how does Veracode get this information? Well, they have a service that does software-based testing and risk assessments. And so they have an interesting set of statistics to pull from there. This is a— this is one of those no-brainer things. I don't even know why I leave it in here at this point, but we all know that it's going to cost more to fix a vulnerability that has been released to the public. This is based on some numbers that I pulled from NIST that are— that have been shared in many different ways, but this is one of the other major reasons for why we need application security because we have to fix things to the left. We have to build security in and push to the left side. So now if we start to think about security culture, let's think about this idea of the average developer. And what is their mindset about security? What do they know and what do they expect? What I find when I talk to the average developer, I find that they are trying to create code that's bug-free as best as possible. They're measured against, is their code on time, the releases, the features that they're responsible for? Are the features complete? Is it on budget? You know, I think about with developers, a good response that you'll hear, might hear from them is, you know, you can have 2 of the 3 following things: good, fast, or cheap, but you can't have all 3. So you gotta choose what you want us to do. So this is not— so you may know some developers that are super security conscious, and that's great. I think that's a really positive thing. But I think what you'll find is that the average developer in any size company is really not focused on security.

5:09Right.

5:11Chris RomeoBecause I didn't talk about security being a priority for developers because I just don't see that in my travels as I go to different companies and work with different people. The thing is, developers aren't monsters, okay? They want to do the right thing. They would do the right thing for security. The challenge that I found as I was all over the world working for Cisco and now that I work with other companies is They just don't know what to do. So it's not that they're sitting there going, oh, these security people, I'm gonna see what I can do to mess up this code. It's that nobody's taught them. They don't even understand why should I care about security. So developers aren't monsters. The goal that we have, that I have out of any type of security culture work I'm doing or any type of possible changes or things is I want developers that think like security people.

6:03Yeah.

6:05Chris RomeoSome people, a lot of folks these days, they say, well, I want developers that think like hackers. And I used to think that way, but I've kind of transitioned into taking this new approach saying, I really want developers that can think like security people. I want developers that know how to manage risk or understand what risk is. They know about secure coding principles. They know about secure testing. I'm more interested in what can they learn about how to actually build good stuff. Pen testing is certainly a very worthwhile thing, has a great return on investment. So I'm not anti-pen testing, but I don't want all my developers just necessarily to be pen testers. I want them to also be able to understand how to do things securely. So when we try to get a definition of security culture, so I found this is a really hard thing to define, right? Nobody really has a great definition of security culture. So I happened to find this definition and I added a couple of words to it. This is from Tim Ferriss. Ferriss, who is the author of many different books, but 4-Hour Workweek, and has a major podcast. And so he had this definition of culture where he said, culture is what happens when people are left to their own devices. And so I thought, you know what, if we add with security into that, we can even simplify that definition really to say security culture is what happens with security when people— when no one's looking over a developer's shoulder. When they have a decision to make in front of them, Do they make the right decision to go with security and make the product more secure, or do they take the easy way out and move forward and try to just do whatever gets the release sent out as fast as possible? When I really think about security culture, it really boils down to this: application security is about the people. This is a human problem. This is a human resources problem that we have. It's not that the technology is flawed in itself. We can create technology that's good. It's just that the people don't have the basis in application security because the people introduce the vulnerabilities. Computers don't write code at this point. They don't introduce vulnerabilities. And I get pushback from the tool vendors that might see this and they might say, well, we disagree. Application security is about the tools. I don't dislike tools. But I find that in the beginning that if you take people and you try to give them even the best tools to improve security, if they don't have the foundation in how to do application security or understand the principles, then the tools— they get a report of 30 pages of output from a web application scanner and they look at that and they go, hmm, I don't know what to do with that now. So we got to lay that foundation. Why would we want to change a security culture? Well, a couple different reasons. There's the people. Are the people making some bad decisions, such as the person in this picture here with a beautiful tattoo? Clearly, I've made some bad decisions. What about the process? Do you have a security process at all, or is your existing process broken? Security technology— do you have tools at all or not? Are they tuned? Are they noisy? Do people not use them because they're tired of being constantly barraged with all kinds of different noise, and they say, I really can't get get through this. So these are some reasons why you might need to change. You might not have a security culture, so you might need to create one, or these are some reasons that you may have to make some changes to what you do from a security culture perspective. So here's a couple of different things to think about, and these are the defining features of a sustainable security culture. And it's not a mistake that I underlined that word sustainable, because what I've seen and what I've found in my travels is it's really easy to change security culture today. It's even easy, relatively easy, to get that security culture change to last throughout the weekend. The challenge is, can we get— make adjustments to the security culture that in 5 years from now we can look back and say, wow, that was really a good move on our part. That was a great investment because we're really— look where we were then, look how much— look how security is so embedded into everything that we do now. We really made some progress across that time.

10:24Yeah.

10:26Chris RomeoSo here's a couple of things to think about that define that sustainable security culture. The first thing is it has to be deliberate and it has to be disruptive. So what I mean by that is it really helps to have a plan. So you have to write something down to say— you can't just— security culture change is not just going to fall out on you. It's not just— you're not just going to be sitting there one day going, wow, security has really kicked in. People are really into this. And I haven't done anything. So you got to make some plans. You got to go after them. When you make those plans, if somebody's not upset, at least one, maybe more people aren't upset with how far you've gone, then I would say you're not being disruptive enough. So somebody should be screaming at you as you're trying to change security culture and you're impacting and changing how things are done. If you don't have at least one person screaming at you, you need to push a little further. Second thing to think about is Sustainable security culture needs to be engaging, needs to be fun. So security has been known as the department of no for so long, the department of people that don't have fun, the department of people I don't talk to because I don't want them to block this cool thing I'm trying to do. So we got to change that. We have to, we have to be much more engaging. We have to be much more available. We have to become the department of no, but let's figure out how to do something a little more secure that'll still meet your functional needs that you're trying to do. Rewarding. There should be a reward. There should be— we should reward people for making the right decisions for security. And then the last part is return on investment. We need to be able to demonstrate how are we saving money with this security culture changing program? How are we impacting the bottom line? Because ultimately there's executives that are gonna wanna see, they're gonna wanna look at just the dollars and cents and say, we're investing this much money and this many people. Are we getting a return? What is the positive impact on our security culture? So there's some metrics and things that we can use there. So how? Let's jump right into the how. How do we change a security culture? So the first thing that I always go to is we have to open people's eyes. We have to make them— they have to understand that there is even a problem that must be dealt with. And so I think of this as the awareness stage. And I just put a kind of a nondescript ribbon in here because we think of different ribbons that are about awareness. We see that ribbon and we think of a certain cause or— and so I want to get to that level of awareness across the entire organization. I want everyone to have at least some basic understanding of one important question. And that question is, why would somebody want to attack us? Because I find that if I teach an organization the basics of security fundamentals and then across those lessons I teach them why would somebody want to attack us, it changes their whole perspective on the world. Now when they have a design decision in front of them, they start to think, wait a minute, I learned about there's bad people out there that when we deploy this, they're going to attack it. So perhaps I should make a little change to try and do something different. The second piece of this, of how to change cultures, you got to fill their brains with knowledge. Okay, these are the foundational things. I just talked about the fundamental principles. There's other things that we can teach, such as we can go through things like security myths and explain what are the security myths that you have to deal with. There's secure design principles that we want to apply. There is a breakdown of who are the attackers in detail and why would they want to attack you, what are the methods they use to attack you. So these are these foundational pieces of knowledge that we want to get across to everybody.

14:04Okay.

14:06Chris RomeoThe other part of filling their brains is history. And this is where companies can take advantage of what's happened in the past. Take a look at— mine your bug database for interesting security events that have happened in the past and bring those forward. This isn't to shame people, but you should teach based on the things, the bad things that have happened in the past because there's so many lessons to learn. And why would you want to repeat those lessons over again? Why would you want to have to learn them again the hard way by making the the same mistakes. So pour into your bug database and pull out some interesting things and include that in the lessons that you're teaching to everyone. Once again, not to shame, but just to help people see what they could do and what they need to prevent and not repeat the same things over and over again. The last part of filling the brains is one of the keys to changing security culture in a positive way is we have to be very careful that we don't ask people to take learning or view modules or do something that's not specifically tied into what they do in their job. So, for example, if we take the crazy example of saying, well, let's say we had a developer and we have a series of modules. If that's a Java developer, you should never send them to a C or C++ module. So, make sure that any type of culture-changing program that you're going after has some paths that exist within it. Because people are pressed for time as it is. We're already fighting the battle of people are too busy. I don't have time to do anything else. So, we have to be very careful to protect that time and only serve up the things that are truly most important to what that person does in their role in the company. Last, last, or third-to-last part of this, or second-to-last part of this, is you have to task people's hands. So one of the big challenges in training historically is that it's all about we provide people with all these facts and then we send them back to their desk. And so they spend Monday through Friday in training. They're all excited about security like, this is the coolest thing I've ever seen, or I love it. I mean, they're watching security movies throughout the, you know, they're watching The Matrix throughout the weekend, kind of watching Neo travel through and be this hacker. And then Monday morning they get back to their desk and they sit down, they look around, they go, now what do I do? They don't know. There's no application to take what they learned in that class and apply it. So what I'm calling for here is this idea of activity. So any type of culture-changing program has to have learning and knowledge that they can take in, but it also has to have activity. Give them something to do. Measure those activities and help them to take their enthusiasm they're gonna have about security and give them some easy wins, some easy ways to get in and do something with it. The last part of kind of how to change culture at a high level is this idea of community. So, when I was at Cisco, I was part of the, or responsible for, the Security Advocate Program. And what this program was, we had different people that were distributed across all the business units that were given this designation by their management of security advocate. And so this wasn't a functional title. It didn't appear in the directories or anything, but this person, they were responsible for looking after the security of the products that were part of their business unit. And we would meet monthly to do training sessions, bring in people from the outside to lead training, and really it was about motivation, trying to motivate them to do things, kind of grassroots kind of security community within the company. And so this is really the final piece of that, of changing security culture, is You have to have some way to knit the people that are really passionate about security together into this security champions or security advocate type of an organization. And it doesn't have to be official. It can be the type of thing where people are, it's not their official title, but it's kind of what they do on the side, which is a way it works in a lot of places because there just aren't resources to say you're a dedicated security advocate for a product. So when you think about this idea of this application security awareness, it's going to kind of knit together all the things that we've talked about so far. It kind of sits in between security awareness, which when I say security awareness, I think of general security awareness like don't click on that link, that's a phishing problem, don't— watch out if somebody calls you on the phone and tries to trick you. All these are— don't let people follow you into the building by tailgating. These are all general security awareness lessons. Very important. And on the other side of this, you have security training. You have classroom-based training where we're doing secure coding principles and things. There's a lot of e-learning and video type of stuff that's out there now. But the reason I created this format when I was at Cisco was this idea of this video-based format that I'm going to tell you some more about here as we go, is that I found that traditional training is really boring, and I personally really don't like to sit and listen to boring training. And the reason it's boring is because what's happening a lot of times is when you do this e-learning type of stuff, somebody's putting a video or putting a slide up on the screen and they're just talking to it. And instead of really making it engaging and interactive for you, it's really just somebody reading from a script. So they're not even talking to you, but they're just, they're reading off a prepared script, which for me is boring. So this idea of application security awareness was born out of how can we make a format that's a little bit more fun for people to consume? Because if people enjoy the process of consuming the content, they'll come back for more. They'll dig into more of it as they go. So if you're curious about what I did at Cisco, the blog post is still up there. They didn't delete it after I departed the company this past January. So this blog post also has a nice video that gives you kind of a summation of the entire program and shows you some clips from what we did there. So, feel free to check that out and let me know your thoughts after you take a look at that video. So, I really break down this idea of building your own program into 4 pieces. There's a program architecture. There's some things we can do on the content side. I'll talk to you about humor and the importance of weaving story into anything that you do, and then this new principle of gamification that everybody's very passionate about in the world of learning. And I think it's important to stop here just for a second and say, my background is not in the world of learning. So I kind of stumbled into a lot of the things that you see here that I'm going to talk about. And these are not standard learning and development principles. I actually battled quite extensively at Cisco with the learning and development department because they wanted to do things the way they're supposed to be according to the learning and development textbooks and what people that get degrees in this stuff, the things that they wanted to do. And I kind of stumbled onto this format just by saying, I'm going to make something that I would want to watch, and I think other people will probably want to watch it too. So my background is really coming to you as a security person that's kind of stumbled into some things in the world of learning. First thing you got to do here to be successful with building out any type of a program is you got to figure out where we are. So you may know the answer to this right off the top of your head. You may not. You may have to go and actually investigate and talk to some different people. But the types of things that you're trying to figure out here is just, can people even spell security here in our organization? Do they— is there a secure— do we have a secure development lifecycle? If so, are people using it? Do they know what it is? Do they know what's expected of them? And this is a— and you can do this in a lot of different ways. I mean, you can do formal focus groups where you have different— you have full groups of people that come in. You can do surveys and interviews. I even like to do this when I walk into a new company just by walking around a little bit, asking people what I see in the break room. Hey, are you a developer? Yeah, I'm a developer. So what do you know about security? How important is security here? And a lot of times that can lead into some very interesting conversations that's a different perspective than what you might get out of a formal focus group. But after you do your assessment, it's very important to stop and say, okay, what is the problem that we're trying to solve here? And in this case, this is a generic breakdown of what I've used in the past and what I've found in different organizations. But a lot of times the problem is people just don't have any knowledge of application security. Maybe they don't understand what the threat landscape is. Maybe they don't understand that the threats are constantly— new threats are coming out. Maybe they— we have a secure development lifecycle, but they don't understand how to use it. They don't understand the tools. Or maybe there's just no motivation. Maybe management has squashed security as a resource drain, there's just no motivation. So very important to define the problem early because that'll help us to measure the impact that we're having and also just keep us focused in the right direction. So there's some people you can bring onto your team if you're somebody like me who's more of a security person. And the model that I used at Cisco and that I use now with Security Journey is We bring in some outside experts to help with the production of any type of a program. So, if we're creating video modules for a given program as we're building it out, we have external experts that help us on the video side. We have these people called psychometricians that are experts in the learning process. And so, they look at our content and decide what do we need to change to better resonate with different types of learners that are out there. But if you're doing this within, if you're building this type of a program within your organization, it's, it's, this is a great type of a community-built program. So, it's great if you can get some people from across some different lines of business and bring them into this and include them in the process of building any type of culture change that you're trying to do. And the reason to do this is if you bring them into that process early, and then they help you create something, they'll become the biggest advocates that you have once you're ready to release something to the rest of the world. So the first design decision that you have to make about this new program you're going to do is you got to have a theme. And that seems like a strange place to start, but let me explain to you why the theme is so important. At Cisco, we took on the, the nomenclature of the Cisco Security Ninja. And so, if you've been in security for a while, you probably hear that and you think, oh, that's kind of corny. And it is. It is kind of corny. But the crazy thing is it resonated with people across the entire company. People wanted to be a security ninja, and they saw that as something that they thought was positive. So, the theme of your program is, it's really more of a marketing thing. So, you have to think about what is popular inside of our company. What could we choose as a theme that would resonate with people here? And then use that, and that can drive all of your marketing efforts. It can drive your, you know, at Ninja, we at Cisco, we had different ninja characters, cartoons that were drawn and things like that, and it just became a really fun way to do it. Second design decision is levels. So one of the other things that traditional training really falls down on is traditional training is just a lot of times it's just a one-off course. So you take that course and then you go back to your desk, like I said, and you're like, nah, I don't even know what to do now. And I don't even know what to study next. I don't know what the next piece of this should be. So the idea with levels here, using security belts as our metaphor, is that you can have different levels and different types of training and different types of learning that people can do at the different levels. And if you use something like a security black belt, when somebody begins their journey, they can see that security black belt as the goal that they wanna get to. And by laying out that goal, they can then start to count the cost about how much is this actually gonna take me to get there? And they can see that path that they can go through, which is a very positive thing for somebody that can see if I put in this much effort, I'm gonna get this much reward at the end. So from a roles perspective, there are, you can tailor this. So design decision 3 is who are you gonna focus on? And there's— my advice to you here would be figure out what the roles are in your organization and then figure out how many of each type of role there are. So when we did this at Cisco, we started with the software engineers because we had 25,000 of them and that was the biggest population. So we said that would be the right place to go. But the idea of this type of a program is you want to try and capture everyone eventually, even folks in sales, marketing executives, And you might ask, well, what could somebody in sales get from this type of a learning or experience with security culture? When that salesperson sits across from a customer, and I'll tell you, customers are asking this question now, they're saying, hey, what are you doing with security? That salesperson, maybe they're not gonna go into the technical bits and bytes, nor would we ever expect them to. But they, if they can answer at least some high-level questions and describe, well, let me explain to you what we're doing.

27:41Yeah.

27:42Chris Romeobecause they've learned in whatever program you have, that's huge. That's a huge win for your customer, and they're gonna get a lot of perspective on what you're doing and have a lot of— they're really gonna be happy with being able to hear about the types of security things you're doing. 4th design decision is activity. So I talked about the importance of security activity in this whole process. So, I break these activities down usually into 4 different categories: build, enrich, explore, and implement. And the idea here is you got to tailor some activities that you want to— you want people to take that knowledge you've given them and then allow them to implement it and try it out. It comes down to looking at these different activities and then doing something with them. And what I normally like to do is If I like to make the activities be a part of the program and but make them in part of the higher levels. So like for in this example, for a yellow belt and a white belt, I would have folks go through a video-based learning program. But then when they start, or maybe even include that for the green belt as well. But when they want to earn a brown belt and a black belt, they have to start doing some of the activities on this list. They have to be mentoring people. They have to be forging partnerships and they have to be looking at different security issues. And the way you measure this is you just provide them, you just need to provide a tool and I like to use a points-based system. So you assign points for different levels of things that these activities and behaviors that they're doing and you award those points and when they reach a certain level of points they get to their brown belt. They reach the final level of points they get to their black belt. And you want to make that so that it's not too easy, but you also don't want it to be impossible. You don't want people to— this journey to a security black belt in your company should not be a 10-year plan because it should be something that is a reasonable amount of time that you can actually be able to do it. Recognition is huge. There's different ways you can recognize the people. Lanyards is a way I've done it in the past. I would print the security white belt on that lanyard. That's an example of what a blue belt would look like, but you've got You've got some swag that you could hand out. I found that creating certificates is a popular thing. I've also done some things with just direct emails that go to the person who earned a belt and also to their manager just to say, hey, this has been a really good thing, a really positive experience. And then money. Cash is never going to be a problem as a way to reward people. Lots of people are motivated by money. It's just, it's the universal thing that you can use to reward people. So I'm a firm believer that if you can, if your culture supports it, give somebody $100 for earning a security white belt, the most basic of the belts. I look at it this way. I say that $100 is a very small investment when I think about how much a single vulnerability costs that we have to release to the public. I would argue that most companies that have to release a vulnerability to the public through their product security incident response team and all the publication that happens there and all the customer fallout, Most companies, that's gonna cost more than— it's gonna cost $1 million for most of those public types of vulnerabilities after all the rework that goes into doing the fixes and all the pieces that add up. So that $100 is a very small investment to try and embed some foundational security principles in folks. It's just a very small investment to make. So then if you, So Schedule C, I mean, the important thing I wanted to share here is that this security culture change stuff, this is not something you're gonna say, well, we'll just do that in the 4th quarter. In those 3 months, we're gonna crank out a security culture and stuff's just gonna be awesome at the end of that. Maybe if you're lucky or if you have a really small organization, but this is a multi-year thing. And that's why it's so important to measure it and keep track because this is something that is gonna take you, I mean, the program at Cisco, it really took us till, it was a 5-year rollout before we had all those belts, yellow, white, all 5 of the belts kind of rolled out to the entire population took 5 years. We could have done it faster, but we were learning a lot as we went, and we were almost doing the validated learning approach by changing things that didn't work and applying it in the future. Content is king in this type of a system or type of a scenario. And the idea is that I'm really a firm believer in using video as the content to get these messages about application security, the foundational pieces, out. When I started this at Cisco, I had a population of, like I said, 25,000 developers or engineers. I had a total of about 70,000 people in the company. So me getting on an airplane and flying to conference rooms all over the world, I would not be able to even meet with and present to 0.1% of the entire company. I might be lucky if I could do that in a year. But video was a format that would scale and could reach far and wide and catch a lot of people. But the catch is video has to be done well. And the format that we ended up creating and that we use still, it's with Security Journey, is it is conversational. So we use an interview-based format. So you're going to see us most of the time while we're talking about security topics that we love. We use PowerPoints as a backdrop just to ensure that we can cover a particular topic in a relatively short amount of time. But this type of format, this type of content is about bringing security people on camera that are really passionate and love what they're talking about. Because just like with The Tonight Show, if you watch The Tonight Show, Jimmy Fallon interviews people and They're usually relatively interesting because they're not reading off a script. In the movie that they were in, they're reading off a script, but when they're talking and sitting there having a conversation, it's just interesting to listen to some of the time because you don't know what they're going to say next. And so we tap into that talk show kind of a mentality while still providing the important subject matter, but giving it in a way that it's easier for people to consume. You've got to test people after each module. I always recommend have some type of a quiz. It should not require a PhD in security to answer. It should be based on the content and tie back to the lessons that you think are the most important. Resources. Important to have some different resources that allow people to dive deeper into the topic that you just covered. And the idea here is when we have somebody, for example, and what you see on the screen here, talking about perhaps resources for a threat modeling module. If somebody watches that module and they're like, wow, this is really cool, I want to learn more, I want to give them some curated links to places that I think really do a good job with additional information on that topic. I don't want them to just go Google threat modeling because if they do that, they might find some people that are maybe not doing threat modeling in the way that we want to do it in our organization. So that's what the resources are about. Here's a couple of different things that I always, I always recommend people include in that Level 1 or in that white belt. Security fundamentals is just the basic vocabulary stuff. I talked about attacks and attackers. Security development lifecycle is a good thing to just brief people on. Privacy and customer data protection is a huge one now. It's becoming more and more crucial for everyone in the organization to have a basic idea of what is privacy and What do we need to do to protect our customer data? And then security business case. I like to try to capture a high-level view of what is the return on investment for security, because so many times people see security as a resource drain instead of seeing what the positive impact is going to be. So I try to break that myth there that this is all just about slowing you down. It's really about saving us money in the long haul. And then if you think about level 2s or yellow belts or green belts or whatever, here's some examples of my thoughts on What would I put in a role that was for a web developer? So I'm gonna have them cover that OWASP Top 10 in a relatively deep and profound way because I really want them to understand and be able to not only describe what those issues are but see them in their code. And then do some secure coding for whatever languages they're working in. Give them a little bit of the ATT&CK side and then cover foundational principles of development for security like input validation. Ensure that they know what that means and what that looks like in their language. This just shows you kind of a view of what I— the way I create content now, the way I've done it in the past, and the way I still do it today. You'll see that I like to go from an outline to— you'll see 2 different instructional design reviews. That's where I bring in the learning specialists because I'm a security person that I think I'm fairly decent at creating content, but a lot of times those instructional designers will look at something and say, the way you read that picture, the way you drew that slide, it doesn't make sense to the majority of the population. So the instructional designers really help us from the outline perspective as well as looking at the individual content that's completed at the end and making sure it's gonna be— 'cause we don't want learners that are gonna sit there and not understand it. We wanna have the best possible content that we can. This shows you just a picture of— I just pulled this out of one of our— one of the security journey modules that we have now, the security fundamentals. This is the type of connections that I'm trying to make. I was trying to get the point across to people. The first goal was to explain just so they know at a very high level what is a vulnerability, what's an exploit, and what's an attack. And then during the conversation, I tie those things together and kind of walk through the chain to say you can't really have an attack without a vulnerability, and you can't have an attack without an exploit either. And I find that even though I may think that people would know what these things are, the average person inside of even a tech company, but I find that they don't. So that's why it's so important to lay these foundations. Okay, humor and story are huge, and I like to try and find ways to inject humor into the content process itself, and what that looks like, there's a lot of different ways it can resonate. Cartoons are a great way to do— to mix some humor into this. In the past, I've done— I've actually done full-motion cartoons. Those are pretty expensive to create, but I have a cartoon series of that where an artist created myself and a number of coworkers as cartoons, and then we did the voiceovers on them. You can also do spoofing videos. I've done lots of that in the past where you add a security twist on a movie or do a ripoff of The Matrix, or you can even, you can do different movies. But the idea here is that we're gonna add a little bit of content that's just goofy fun, that just puts a little bit of a more fun spin on the world of security. Because it shouldn't just be all about serious content and serious discussion. We add a little bit of fun in here to keep people coming back and Programs I've done in the past, I've received the great feedback by people saying, sometimes I just came to the next module just to see what the heck you people were going to do. Like, were you going to be more over the top than you were in the last one? So that this metaphor, this gives you that room to add a little bit of fun into your content program. Quick word of caution here, not everyone in the world of of the corporation thinks the same things are funny. So I try to strive for a PG rating on anything that I do. We had a relatively famous scriptwriter actually write those cartoons that I was talking about earlier, write the actual lines and things that were happening in discussion. And I got the initial version from him and I read through it and I went, oh boy. We— and I had to send it back and said, we can't, we can't record this. If we do, I won't have to worry about working here anymore because they will fire me. The script was great, it was funny, but it was rated R. And I told him, I said, hey, you gotta, you gotta tune this down. I need TV-PG so that I can— this can be funny in the corporation. And, and he understood and he was able to adjust it and it was still funny. It just, it just wasn't as edgy as what he had made it to be. So gamification, this is a series of principles for how do we make— how do we engage our learners learners inside of the learning experience so that they have some type of rewards, they have some type of levels they're working from, they have badges. They just— there's a certain amount of fun that we can add in through the gamification side. And so the belts themselves in a program like what I'm describing become part of the gamification because they define your levels for you. And just remember that gamification, when you hear that, it doesn't mean that you're turning your experience into a video game.

41:21Game.

41:21Chris RomeoGamification is about using the principles that make video games fun and applying them into a given program. And one way you can do this is from a user interface perspective. Whatever you end up with as your theme— remember way back in design decision 1, about 10 or 15 minutes ago, we talked about choosing a theme for your program. So this is a kind of a corny representation. I'm not much of an artist. But this is an idea for what I would do if I was going to continue with the Security Ninja theme. And so this could be— and this is designed to be the interface that the user sees when they come into this course. I mean, how many times have you gone to a course in your corporate learning management system and it's just a webpage with a bunch of text and links on it and it's not fun at all? You click on it and it just opens up the next thing that you have to do. This idea of application security awareness, security belt programs, it's about bringing the fun And the marketing and the characters and all the things, wrap it all into what you do. Embed it in the content, embed it in the user interface, embed it in the marketing materials, the emails you send out, whatever. Wrap this whole thing in fun. Okay, last one before I wrap this up with some takeaways here. The last part that I include this as part of gamification, and this is the idea of competition. Because games are all about competition. This is something that I recommend that teams do usually in their second year, and that is to create a dashboard. And this dashboard should be as simple as it should provide statistics from your organizational chart hierarchy that shows how many different levels or belts have been achieved within that hierarchy. So you should be able to click on this dashboard and see— go all the way down to see yourself and see what belts you've earned. But then you should also tally these statistics up as you go and look at the higher levels of the statistics. And what this does is it becomes a built-in place for competition to occur. And you can take this, you can, when you're speaking to one executive, you can in good-natured fun say, well, I just wanted to point out on this dashboard here, if you look at this, one of your peers here, they have 90% people that have achieved a security wipeout. And your percentage is about 14%. So yeah, they're kind of kicking your butt. And just leave it at that. Walk away. The dashboard becomes the engine to cause the organization to try and move forward in pushing more people through the training program, through the process. Some people might get forced to do it because of this. That's okay. They're part of that group that probably wasn't going to do it on their own anyway. So, but the big idea here is the dashboard is the place where you provide that statistical-level tracking. And you can use it to allow people to compete against each other. So just kind of landing the plane here, I guess, on our time. The key takeaways that I get from this are vulnerabilities, we all know they're real and everywhere. Changing security culture, there's a couple different principles you can apply. First thing, open the eyes. We want the developers, the testers, the program managers, the product managers, we want their eyes to open. They want— we want them to be aware. Then fill their brains with specific knowledge and history about security and the principles that are important and what's happened in the past and how we can avoid those things. And then task their hands. Give them something to do with that knowledge. Let them put it into action. And then we talked about how to turn this into a program from content, from humor and story, from applying gamification. And I guess the big takeaway for you here is that this is something you can build on your own. I've been talking about this topic in public for 2 years now, and I know of a few different companies that have actually sat in one of my talks in the past and then without ever talking to me again applied these principles and done this type of, this type of a program. And I think that's definitely a positive thing. Now one of the things that Security Journey does is we actually are taking the principles that we learned at Cisco building these types of organizational programs and things and turning that into our own Security White Belt. So our Security White Belt is live now. It is, it does exist. It's made up of these 14 individual modules. Each of these is a maximum of about 15 minutes long. It's using the interview-based format, using our really high-end content that we've— this process that we've developed over the years. And so I guess the big takeaway here is that this is available now. So we do a free trial from the website. So you can go to the website. sign up and you can see the first 2 modules, no cost, no credit card or anything. Just check it out and you get an idea for— you'll get to see a lot of the principles that I talked about today kind of played out in how we, how we put them into action.

46:16Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Vorian TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast. AppSec Podcast, or on the web at www.appsecpodcast.org.