BLUE TEAM VILLAGE - Hacking Your Dev Job to Save the World: Where Programming and Hacking Meet
Pereyda, Joshua
Have you wondered whether developers can play any significant role in the security world? Come hear from a diehard programmer and hacker who loves to break and loves to build, and learn how a regular programmer can make major contributions to security from the trenches. This presentation will dive into the intersection between development and security. You will learn about the SDL - Secure Development Lifecycle, and why in the world a hacker would care about processes and procedures. You will learn how "processes" and "lifecycles" can be useful - and how they can be a complete waste of time. Included are real world success stories of organizational hacking - getting other engineers to change their practices - and real world fail stories. Attendees will come away with knowledge of how development and security intersect, and how they can use their programming day job to save the world. If you are a developer who cares deeply about security, enjoys exploits, and wants to make the world a better place, this is for you.
 So what we have before us is Joshua Pareda. He's going to be talking about hacking your dev job to save the world. Give him a round of introduction and applause. Short people, the adjustment here. So I guess a little background, how many of you are sort of developer types in here? Good bunch. Okay. Maybe half almost. Okay. Probably more of you have worked with code if that's not your main thing. So this is basically the talk I would have liked to have heard my first year at DEF CON. First of all, thank you for coming out and taking a few minutes out of your DEF CON adventure. Hope that it's worthwhile, maybe inspiring. If not, just leave halfway through. I won't be offended. So quick outline. Just going to talk about the background of why I'm talking and what my story is. Talk about a talk that changed my life or at least my career. Talk about SDL. How many of you have heard of secure development lifecycle? Okay, quite a few. More than raise their hand for developers. Sweet. So I won't spend a lot of time hammering through that. It will be real quick because that's not what the talk is about exactly. I'll talk about how making things happen and then some random tips at the end depending on whether you want to become the obnoxious security guy or change how your organization does things. So a little background. I'm from Moscow, Idaho. Yeah. Woo! I worked at an ICS manufacturer. Big business for a small town. Not a noticeable business by big city standards. Developer background as interest in security. The end of it is I ended up making what I think is a big difference within a pretty big business. So I got fuzzing adopted and doing this kind of from the bottom rung of the management tier. I got fuzzing adopted and standardized within this whole organization of over a thousand developers. I think changed the way we did authentication across some of our big product lines. Really changed our company's security strategy in one aspect. Quick plug for B-Sides Boise if you're in or around Idaho. Any B-Sides Boise people? Yeah, no. Okay. Good deal. He knows what's up. So how did I get there? So I was developer. I was kind of opinionated and detail-fixed and that's what got me interested in security is like seeing the corner cases. I worked at a company that cared. So dollars and human lives are on the line in a real way and that helps to have a company that really has an interest in security, right? I started hacking and stuff and so I got hired to do fuzzing and realized that every time I fixed a bug it was like fixing one bug. Nothing to be ashamed of but as like this isn't going to scale very well. It's not going to change very fast if all we're doing is finding and patching, right? If all we're doing is fixing what we find. So then I learned about threat modeling which is I'm guessing most people have heard about before, right? So it's like this born design time activity. It was new for me at the time. It's like you don't get any elite zero days or cool CVEs next to your name but you can actually have a lot of leverage. You can save dozens or hundreds of issues in the time it would usually take you to find one which is what I think is cool about it. Right? You guys have heard about this before but threat modeling is basically like what are we building? It's like what could go wrong with that and how do we fix? What could go wrong with that? At least that's kind of how Adam Schostack breaks it down. I really like his book. It kind of cuts through the craft and he goes through a lot of like this is the stupid way to do threat modeling that the SISB exam tells you about and it's like here's why it's kind of dumb. So it cuts through the craft even though it seems like a boring topic. Then I heard the talk that changed my life which is from Steve Lipner, the security development life cycle. Has anyone seen this particular talk? Okay. A couple guys back there. I think it's super cool. Really changed how I thought about this topic. Steve Lipner was at Microsoft for a long time. At least a couple decades. I guess coming up on a couple decades if he's still there. He really was instrumental in changing how security happened at Microsoft. Really big change and it's cool to just hear him. This talk is not about SDL itself. It's about how he got it to happen at Microsoft. So inspiring. I'll talk a little bit about that. Just the 50,000 foot view. Around 1999 is when Steve Lipner started. There's a changing threat landscape. The internet comes up. All the assumptions we had in the 80s no longer apply. Now we've got new assumptions, a new threat model. So their basic thing was like, okay, we'll start patching the bugs that people report. So that's like impact from the days of loft. Microsoft not even patching things. So making some progress there. They had what was called the secured windows initiative. Very fascinating strategy. They had three program managers review all the components in windows that are being written by thousands of developers. So they file some bugs. The devs fix the bugs and you got a secure product, right? Anything wrong with that? Maybe? No? Make sense? Okay. Okay. So hopefully you don't buy that. So they released XP in 2001. How did that go for them? Well, they had code red and NIMDA. So kind of as bad as it gets is like all your machines get worms throughout the whole world. Kind of bad. Plus, of course, that was the area when everyone, kind of your average person was getting computer viruses all the time, right? And that's when the normal non-technical person was introduced to the fact that your computer just gets hacked, right? And that's just kind of how we thought things were. So around 2002, Bill Gates sends out this trustworthy computing memo. He and Craig Monday worked on it. I'm going to keep asking, who has read the trustworthy computing memo? Okay, a few people, a few more, right? So very cool tidbit. Half this talk is like plugging other things I think you should check out. A cool tidbit of internet history is, so Bill Gates did this every few years, he'd send an email to the company and say, everybody, we need to pile on.NET. Okay, everybody, we need to work on the internet. That's the new wave. Okay, everyone, we need to work on security. And that's what this was in 2002. So a couple interesting quotes here. I'll draw your attention to the bottom one. This is Bill Gates talking to his employees at Microsoft. When we face a choice between adding features and resolving security issues, we need to choose security. It's like maybe you didn't know Bill Gates ever said something like that, right? So he did and that was, you know, whether or not they followed through just having the president or whatever CEO of your organization say that makes a big difference. So you can see how the strategy here is both top down and bottom up. So they didn't just talk to Bill Gates, but they also worked on the technical side. So around this time, they were pushing the initial iteration of SDL before they called it that. They did like threat modeling and code review and static analysis and a few different things. Sort of ad hoc. And so they had some initial success with those which enabled them to make it into a mandatory process. So but they had enough success that they were, they had a meeting with all the executives, right? And it's like 30 minute meeting, the executives say, okay, everyone's doing SDL now, mandatory process. And it was an easy meeting because the executives knew about it and it was easily accepted by the developers because the developers knew about it, right? So it wasn't like this rule that came out of nowhere. Their initial version of SDL came out in 2004. It's been updated regularly. I call out fuzzing in particular so it's like this cool vulnerability analysis technique really didn't become significant until a couple years into the process, right? So they, it's like they were doing all these basic things and you might think, oh, we need to do this cool fuzzing stuff. It's like, well, they spent the first couple years getting on top of threat modeling, code review and static analysis, right? So it was pretty mature by 2007. And if you haven't seen the Mac versus PC commercial, just go check it out. So around this time, Apple starts this campaign of, hey, here's why your PC is terrible and Mac is way better. And this was one of the commercials on TV was saying, hey, look at PC. They're so dumb they have viruses. Ha! Right? And really, there's some genius, some marketing genius here. So they took all the pent up, kind of vague, undirected discontent that people had and pointed it all at Microsoft. They said, it's not computers that are the problem, it's Microsoft. Right? And so this is kind of how they got their popular reputation among non-technical people of being the thing that has all the viruses where Mac is way better. Even if Mac security may not have been a lot better. Right? And so we're coming around 10 years later. Nowadays, people say, hey, don't bother with antivirus. Like, Windows Defender is pretty good. Your antivirus is going to be annoying. Just use Windows 10 the way they ship it. Right? At least that's what a lot of people say in my philosophy because I don't like Mac-a-Phee. So what you had here is kind of a 20-year cycle. So you're thinking, like, okay, they started in 1999, took them maybe 10 years to really get on top of the process. By 2007, they might be the most secure in terms of their development practices in the world, way beyond the average in terms of code quality and security. And yet their reputation is going down the drain. Right? And it's not until, like, people sort of forget. Like, nobody realizes that it gets better. It's like people don't talk about it as much anymore. And their reputation sort of heals over time. So, you know, going back to math class, your security practices are sort of the derivative, the velocity of your code quality. Right? And your code quality is the velocity of your reputation. Right? So by changing your security practices, all you're changing is the acceleration of which way your reputation is going. So around 2007, they had these top-of-line security practices. Reputation is still going down. It's like it's too late to help the reputation thing. You're going to have to wait 10 years for it to kind of pop back up. Right? So that's just something to keep in mind from the reputation side. It's like you need to hit it ahead of time. So that's basically the history of SDL. We'll go through a quick intro. We'll kind of buzz through this. So standard requirements would, there's a thing for every phase in the development cycle. This is straight off Microsoft's website. So you do like training and stuff and you have standard requirements. These are the security requirements that our products have. You got bug bars, which I think this is super cool. So you can Google like Microsoft sample bug bar. And they have this huge page with this huge table. And this is an excerpt from the server software table. So if you have server software and you have an elevation of privilege bug that's usable by a remote anonymous user and it has these certain right access violation properties, then it is a critical security vulnerability. Right? If you have denial of, but if it's authenticated elevation of privilege, then it's important. If you have denial of service and it's anonymous and persistent, then it qualifies as an important bug. Right? And if it's temporary denial of service, then the question is what kind of amplification do you get with that denial of service attack that classifies the severity. This all matters because they agree ahead of time to hold releases or drop features for certain severities of bugs. So they talk about it ahead of time. I'm really impressed. I haven't seen this up close. Right? But it's like you have this framework so there's no uncomfortable meetings. Everybody knows when we're going to stop release because of a bug. Super cool. The modeling we talked about, attack surface analysis is basically with our modeling with attack surface emphasis. Implementation, these are the kind of things that developers will tend to do even if they're not really working on security in particular. I guess that's kind of like static analysis or coding standards. Hopefully your developers are working on that or interested at least in a coding standard. And then you got like Fuzz testing and you, and pen testing is, they, they call it an optional step in their process. Reason being pen testing doesn't scale super well. So if you're putting out a lot of software, it's hard to pen test all of it in an effective way. Right? You could do rubber stamp pen tests where you're doing like two-day engagements all the time, but you're not actually going to do meaningful work. So you need to leverage your pen testing, either focus it on the things that matter or use your pen testing results and leverage them to effect change. So that's a thing that you need to be strategic about. And I just bring that up to say it's not all, not all about pen testing. Like that's one aspect of the process. If you're looking at it from a software development point of view. And then you have like incident response plan and responses like, well, you implement your response plan. That's surprising. So I talk about this diagram. So I view this as the crux of like where I fit in as sort of the intersection between development and an offensive red team security. Right? Like this is where, where the balance point is and there's different aspects of different roles that contribute. But ultimately you're trying to make the software more secure at the end of the day. Right? We're not just pen testing for fun. Well, maybe we are. But that's not what the company wants. So a couple, all right, making it happen. So basically I think you need good soil and then there's a few details about how you make things happen if you want to change how a business does things. So you need a company that cares about security and, and, and or quality or safety or something like that. Not all companies are incentivized the same way. That's okay. It's like if you want to get into it more, find someone who cares about security. And there's two sides of that. You, you need a business reason to care. Right? That's how you, or else you're not really helping the business. And then you need people in the business that just care in general. My, my old boss used to say you can never pay someone enough to care. So you just need good stuff to work with. Random, don't make, don't mistake lack of concern about your opinions for lack of concern for security in general. I've seen people do this. People reject my ideas. Therefore they don't care about security. It's like no, maybe you have bad ideas, maybe you have good ideas, but you didn't talk about them very well. Maybe their priorities are different than yours. It's like that doesn't mean they're a bad person. Right? So you, you got to distinguish between do they just not care or do I need to communicate better? So some of the details which is really just a couple stories of what I saw. Some things that worked for me or didn't work. So I'm working at a company that cares. They tell me, hey, do some fuzzing please. And I, I said, okay. And then they didn't really tell me to like do SDL. So I'm learning about it, reading about it, watching videos online. And I start pushing it within my own group. So I'm like giving these presentations about here's what our company should do. Giving it to the like three people on my team. Telling them what, you know, like, hey, you know, maybe we should do this as a company and getting our whole team on the same page. Seeing if that's appropriate. Seeing, you know, what people's ideas are. And then, so what I ended up doing was kind of doing the SDL thing with one activity which was fuzzing in my case. Pushing it within my own team. So little comment about inward communication. Cool random inaccurate quote from somewhere that I don't remember. The most effective CEOs are the ones who spend the most time on internal communication. So being a superstar CEO does not equate to being successful with regard to how your company actually performs. Maybe successful with getting your company funding which makes your company successful. Right? But it's like if you want things to run smoothly, if you want your company to go places, it's like it takes work, takes a lot of time just to communicate and get people on the same page. I guess I don't really know if that's statistically accurate but it makes sense to me. Become the domain. So what I did was I got good at fuzzing. Then I like started talking to people about fuzzing. And I started saying, hey, this is what fuzzing is. Our company should do it. Hey, this is what fuzzing is. It's important for security. Come back a couple months later. Hey, here's some like cool fuzzing stuff that we did. Here's some bugs that we found. Come back a few months later. Hey, here's some bugs we found in actual products. Here's the money that we saved by doing this activity. Right? And so you're exposing people to it, creating a culture of normalcy around this practice. It's like you want people to get the impression that they ought to be doing this. You want people to want to do it. And it's like really people should be wondering why they're not doing it. Like your average developer should be like, huh, shouldn't we be fuzzing? Like they've been talking to us about that. Why aren't we doing it? And once you get that, it's then you can make it into a kind of a process or a rule. Right? And this is why I think processes are cool or how they can be cool. It's like if you don't do it this way, the processes can be this sort of bureaucratic, annoying thing that doesn't help anybody. But if it actually reflects what's useful in the company, right, what you get out of making it a process is a few things. You keep people from falling through the cracks. You kind of burn it into the cultural, the organizational memory. And then you also get that last 10% of people who won't do anything unless you make them do it. Right? So there's hopefully a minority of people that you're forcing into it. Most people already are doing it. Then like we found some bugs and I made up some numbers that we saved a whole ton of money. In our case that was because release cycles are expensive. So I was like, hey, we saved this many bug releases. We saved this much money. Not to mention maybe millions in opportunity costs because it takes a lot of time to spin firmware. So I was like, woo, we saved a lot of money. Justify my existence in my role. So that was kind of a win. Again, I was like, I'm doing this from like a low level employee. I'm not trying to like exalt myself here. I'm just saying like this is what worked for me. This is how I found I could have an impact within my organization from the bottom. So then there was this other security feature. It is basically an authentication strategy for our entire product line. Somebody else had the idea. Not my idea. I heard people talking about it. I'm like, hey, that's a good idea. And they're like, yeah, we think so. And then it wasn't moving forward. So it was solved for a solid year. This idea was kind of sitting on the table. No one was doing anything about it. A lot of people were frustrated. It's like the security people are like, man, why don't you do this thing? It's so obvious. So why was it not moving forward? This is kind of my post-mortem of what happened. There was a good idea in too few details. So maybe because of people's other priorities or people are busy, they don't hash through the details. They don't hash through the details. So they don't have answers to questions. What happens is if you can't answer the questions, you look wrong. And then if people come back three months later, you still can't answer the questions. You look really wrong. And then if you come back three months later and tell them again the same thing and you still can't answer the questions, people are about ready to flip the table and leave the room because you haven't answered their questions. So if you don't get into those details, you don't have, it's like you got to answer questions. Even when it's kind of a dumb question, you're like, that doesn't matter. That's just a detail. It's like people want the answer. And it's like it doesn't make sense to them without the answer. I observed kind of a false belief that being right, just because I'm right, that means others need to listen to me. It's like, no, you could be the most correct person in the world. And if you're a bad communicator, no one's going to listen to you and they shouldn't because it's going to be a waste of their time to try. Right? So you must be a good communicator. So there's going to be times when you're right and others don't get it. It's like it's okay. Nobody committed a crime. It's like work on your presentation, come back. You know? So not too tricky. There's a tendency to think, I think, in security in general. And actually I kind of got this idea from Rob Graham on Twitter. He talks about this. He's like, hey, sometimes security people are like, you know, if you don't do what we say, you are wrong morally. It's like you need to confess your sins to the security priest because you've been a bad person because you didn't do what I said. Like, well, no. It's like maybe they don't understand. Right? Maybe their priorities are different than yours. Maybe it's not a good idea. You know, it's technical disagreement. So it's like if you, I've seen people and I think we probably have all seen people get into that mindset. People don't listen to me because they're wrong morally. And it's like you become the guy who sits in the corner ranting at everybody and nobody listens to them. So don't want to be that guy. And then I also observed an apprehension against taking on responsibility, feeling like it's somebody else's job. Or sometimes it is. So what ended up happening was we're in this meeting and it's like half the room thinks this idea is great. Half the room is like, I don't know. I got all these questions. I don't want to do it. It's like I don't even think you really know what you're talking about. So we got this like impasse and someone says, hey, we need someone to like make a proposal and hash out all the details for us so we can analyze this. So I raised my hand and said, oh, our team can do that. We can do that. And they said, great, Joshua, you will do that. See you in two weeks. Oh, okay. So I practiced, again, coming back to internal communication. So I practiced with colleagues, teammates, friends, old coworkers, like buddies. So I'm kind of calling in favors from everyone I know whose opinion I even mildly respect. You know, salespeople, technical sales engineers, whatever. And like, come listen to the idea. Does it make sense from what you know? It's like, do you think customers will like this? Do you think they'll do it? Do you think it's a good idea? Does it make sense? And so I was kind of using some social capital there. But also people like to be early adopters, right? People like to have an opinion. If you tell them, hey, there's this idea, might change our company's whole direction, can you come give some input? Like, oh, yeah, cool. And people like giving feedback too. So I didn't really have to use a lot of social capital. It's just, especially technical people like to be early adopters. So I practiced full time, a couple weeks, presented it to the people I said I was going to present to. They're like, mm-hmm, kind of maybe. Maybe. And then they had some questions I hadn't thought of. So presented again a little while later. And I presented again and again. And then I ended up eventually in meetings with like the head of R&D with, you know, with my manager and my team. And we're like saying, hey, this is what we're going to do. Working out the details. My proposal moved up the management chain. It got to the head of R&D. And that's when they stopped inviting me to the meetings. Like, no, you don't get to talk to the executives. You've done a good job. You can go home now. But it worked. I think that was good. Because it's kind of a whole different skill set. You get high enough and it's, it becomes a different game. And then another plug is this deaf contact. So around the same time I'm doing this stuff, I hear this talk last year from the social engineering village, change agents, how to affect corporate culture. And they're talking about the same thing. They're like, they're at the bottom. And they're like, how do you push something up all the way to the CEO? Get the company to do something different. And it's kind of a fun game if hope you get the opportunity to play it sometime. Fun. So as the idea progressed, right, so eventually, you know, the end of the story is, hey, we agreed to do it. Everybody's happy. My boss is happy. As the idea progressed, I became more involved, went from just like proposing it to kind of doing it, writing the specs at our company, writing the specs is like one step shorter writing the software. It's like you write the software. It's like you just fill in the blanks at that point. Right. So that was a big process, writing the specifications, basically saying what it's going to do, what's the API is going to look like. Stop just short of writing the code myself, partly because I switched jobs at that point. But if we had gotten to that point and I wasn't a developer, not sure what would have happened. Right. So we wrote the specs before anyone like approved us writing the specs. It's like we know this is going to places. They're going to want the details. We're going to have the details ready for them. Right. So if I didn't, this is, I'm just saying like, hey, how can you be helpful as a developer? It's like if I didn't have that development background, I would have been like, I don't know how to write a spec or I don't know how we do software here. Can someone else do that? Right. And it may not have happened because there wasn't anyone else to do it at the time. It was like we didn't have, they weren't giving us money to hire a team. Right. So like you can leverage your skills that way. And it's like I needed the technical details at that point. And then we, you know, we did it. So cool security feature. Kind of changed the, I would say changed the security strategy of our whole company's $100 million business. At least one aspect of the security strategy. So that's like my stories about making it happen. Stories about how it, why it didn't happen for a long time. And I'll close with a couple tips depending on what kind of person you want to be. So if you wanted to become obnoxious and useless for a long time, you may have thought you couldn't, but you can. And I will tell you how in eight easy steps. There's a premium program you can enroll in for a small monthly fee. So please contact me if you're interested in and I can help you get there. And specifically the obnoxious and useless process guy that nobody likes to and everybody works around. You know that guy. You can, so tip one, just burn through these real quick. Make things into mandatory processes. This is like the fast track. You want to get it done. Just like make a bunch of rules before people know how it works. And then like beat them over the head when they don't do it, right? So it's a good system. Especially helpful if your organization is big and you can't possibly explain it to people in enough time for them to get it done. Top down, don't ever talk to the devs. They are not worth talking to. Go to your boss with grandiose schemes that you don't really understand. Be pushy. Remember, you are the genius. It's all about you. If your boss doesn't listen to you, it's because he's dumb. That's another good trick. Do bad at your current job. This one I would say is important. Don't forget to daydream about all the cool things you would do if you had a different job. If that's not your thing, though, you can also do okay at your current job and you can still become annoying. It's important to daydream, though, and voice your opinions loudly without thinking about them. Or you can even do slightly above average at your job. You're getting kind of in the risky territory at this point. It's like you're in high danger of becoming useful. But if you keep on telling people they're wrong, you can still do it. So just kind of doing a little above average. Yeah, make rules that people, this kind of goes along with the first one that they don't learn about until right before they release. Then try to get them to push their release date back and don't like say it's your fault. Make sure they know it's their fault. Turn every piece of advice into a moral crusade with vindictive condemnation. Now, these are all running together. So if you do these things all at once, you're going to be on the fast track. So if people don't listen to you, it's because they're a bad person. And you can get mad at them. You should get mad at them. Take ownership of your baby. And this might sound contradictory because you're trying to get other people to do things, but you can still take ownership of your baby and not let anyone else have input on it. Right? So it's like it's your baby. And the goal here is to kind of have a creepy vibe. Like maybe you hiss at people or kind of like lash at them. And your goal here is to like kind of get this fence of people being repulsed and wanting to stay away from you and your project. Right? And if you're lucky, you'll get funding to kind of be, not bother anyone. Of course, the opposite of that would be trying to work yourself out of a job. That's dumb because then you're not going to have a job, right? So, but if you don't want to be that kind of guy, I do have a few tips for moving the organizational needle in a real way. So first is to do awesomely at your job. Unless awesome is an adverb, then just do awesome at your job. I don't use that phrase too lightly. Like people should be impressed. Right? You all know that guy in the office here. Everyone's like, man, that guy's super smart. And it's like, why is it always how the right answers? And how can he's always thought about everything before we ask him? How can he's always learning more stuff and has opinions about what our company should do and they make sense? And how come he's good at explaining? It's like, you want to be that impressive guy if you're trying to do this kind of thing. And it's like, I don't mean to be like, this is not very egalitarian, right? It's like, some people are kind of on the lower side of the average and some people on the higher side. If you want to change things, you want to be on the higher side of the average. If you're not, if you're working hard and you find that you're below average, it's like, maybe you need a different specialty, right? Or a different angle. But most people can become above average in a lot of things just by working hard. Because not everybody does. Take time to get good at explaining. If you have a hard time explaining, it's likely because you don't understand yourself. No, you're not a genius. You're overconfident and maybe a little, maybe you talk too much. Right? It's just in general, you know, some people are better at this than others, right? You can kind of practice at it. My practice is like every presentation I practice it a whole bunch of times. Otherwise, it isn't smooth or it's not as smooth as it could be. But even if you're not like an expert explainer, it's like, if you got technical people, if you have capable people in the room and they're honestly listening, it's like you should be able to, you know, they should be able to get it with little time. So it's like if you have people that are being patient, asking honest questions and you can't get the idea across, it's like you need to work on that presentation. I'm a big fan of presentations. Maybe this is not a technique that everyone uses. But if your company has like brown bags or lessons learned or whatever, as like leverage those, present multiple times if you really want people to do something, it's like burn it into the memory and keep them short presentations. Random tidbit from Paul McMillan tweeted one time, one new security control is one new employee. So like don't kid yourself on what you can accomplish. So if you're one person, if you're not a manager, Steve Lipner, when he was doing this, he had kind of a little organization he was working with. Right? It's like if you're one guy, you can basically do one thing. And that was kind of what I ended up doing with fuzzing. It's like I didn't even think fuzzing was the most important thing. That was just what they gave me to do. And I took it as far as I could. Right? And so if you're a manager, like don't give your team of two people 20 things to do. And obviously, like not very hard, but I think that saying that it's like one control, one thing is one person. It's like if you're stretching it, most times you're stretching it too far. If you're giving people two or three things to do, it's like it might seem like static analysis isn't that hard. Like can't you do static analysis and threat modeling? It's like you're going to hurt yourself. Support people, don't complain, make things better. I got a little time here. So like one slide on software sign off. Who's like heard the term software sign off before? Okay. If you guys could like talk to me afterwards, I'd love to hear about it. Because I've heard about it like two times and I don't know very much, but I think it's super cool. So my understanding is it's an extension of engineering sign off. Right? So if somebody builds a bridge and we're talking about software that needs to be secure, somebody builds a bridge and engineer signs off on it. It's like I'm the engineer, I say it makes sense. Or you got contractors working and something looks sketchy, they call an engineer, the engineer signs off and says if you do these things, it's safe. Right? And then if the bridge falls down, people die, people can go back and say who was the engineer? Did they do something wrong? It's like why'd you sign off on it? Can you defend what you did as being safe even though something went wrong? The idea is not to hang people, but you can, it can vindicate people. It's like you document what you did and you show that you did a good job. So this is something that I think would be cool. And I've, it's like I've seen kind of sort of halfway done, but it's like when you have sign off processes and checklists, sometimes they become a rubber stamp. And the key here is like making sure that people take ownership of what they sign off on. Right? And to do that, you need a mature process where people can feel confident in what they're doing. It kind of like hooks into code review. Like my philosophy is if you're, if you approve the code, it's your code, you're responsible for any bugs that happened in it. Right? Kind of like golf style. It's like the guy who signs off is responsible, helps like root cause analysis. That fits in somewhere here, but I don't know where. So that's like all my ideas and what I think the intersection of developing and hacking is. So in conclusion, to change the world as a programmer, do really good at what you do. Work for a company where it can be appreciated. Find something to improve. Other random tidbit, if you're kind of a blue team, develop a background. It's like find a cool security tool that open source and people aren't working on it and is like work on it. It's like you can leverage your skills in that way if you don't want to do the organizational like business-y approach. Be a patient explainer. Really definitely check out Steve Lipner's talk. I highly, highly respect him, especially in this talk. Read threat modeling. And I'll just close saying high quality developers can make a difference. This is what I see as being sort of the crux of the intersection. And there's all sorts of sides to that, like where you can contribute. So hopefully that was helpful for some people. Thank you very much for your time. Thank you.
 So what we have before us is Joshua Pareda. He's going to be talking about hacking your  dev job to save the world. Give him a round of introduction and applause.  Short people, the adjustment here. So I guess a little background, how many of you are sort  of developer types in here? Good bunch. Okay. Maybe half almost. Okay. Probably more of you  have worked with code if that's not your main thing. So this is basically the talk I would  have liked to have heard my first year at DEF CON. First of all, thank you for coming out and  taking a few minutes out of your DEF CON adventure. Hope that it's worthwhile, maybe inspiring.  If not, just leave halfway through. I won't be offended. So quick outline. Just going to talk  about the background of why I'm talking and what my story is. Talk about a talk that changed my  life or at least my career. Talk about SDL. How many of you have heard of secure development  lifecycle? Okay, quite a few. More than raise their hand for developers. Sweet. So I won't  spend a lot of time hammering through that. It will be real quick because that's not what the  talk is about exactly. I'll talk about how making things happen and then some random tips at the  end depending on whether you want to become the obnoxious security guy or change how your  organization does things. So a little background. I'm from Moscow, Idaho. Yeah. Woo! I worked at an  ICS manufacturer. Big business for a small town. Not a noticeable business by big city  standards. Developer background as interest in security. The end of it is I ended up making what I  think is a big difference within a pretty big business. So I got fuzzing adopted and doing this  kind of from the bottom rung of the management tier. I got fuzzing adopted and standardized  within this whole organization of over a thousand developers. I think changed the way we did  authentication across some of our big product lines. Really changed our company's security  strategy in one aspect. Quick plug for B-Sides Boise if you're in or around Idaho. Any B-Sides  Boise people? Yeah, no. Okay. Good deal. He knows what's up. So how did I get there? So I was  developer. I was kind of opinionated and detail-fixed and that's what got me interested in  security is like seeing the corner cases. I worked at a company that cared. So dollars and  human lives are on the line in a real way and that helps to have a company that really has an  interest in security, right? I started hacking and stuff and so I got hired to do fuzzing and  realized that every time I fixed a bug it was like fixing one bug. Nothing to be ashamed of but  as like this isn't going to scale very well. It's not going to change very fast if all we're doing  is finding and patching, right? If all we're doing is fixing what we find. So then I learned about  threat modeling which is I'm guessing most people have heard about before, right? So it's like  this born design time activity. It was new for me at the time. It's like you don't get any elite  zero days or cool CVEs next to your name but you can actually have a lot of leverage. You can  save dozens or hundreds of issues in the time it would usually take you to find one which is what  I think is cool about it. Right? You guys have heard about this before but threat modeling is  basically like what are we building? It's like what could go wrong with that and how do we fix?  What could go wrong with that? At least that's kind of how Adam Schostack breaks it down. I  really like his book. It kind of cuts through the craft and he goes through a lot of like this is  the stupid way to do threat modeling that the SISB exam tells you about and it's like here's why  it's kind of dumb. So it cuts through the craft even though it seems like a boring topic. Then I  heard the talk that changed my life which is from Steve Lipner, the security development  life cycle. Has anyone seen this particular talk? Okay. A couple guys back there. I think it's  super cool. Really changed how I thought about this topic. Steve Lipner was at Microsoft for a  long time. At least a couple decades. I guess coming up on a couple decades if he's still there.  He really was instrumental in changing how security happened at Microsoft. Really big change and  it's cool to just hear him. This talk is not about SDL itself. It's about how he got it to  happen at Microsoft. So inspiring. I'll talk a little bit about that. Just the 50,000 foot view.  Around 1999 is when Steve Lipner started. There's a changing threat landscape. The internet comes  up. All the assumptions we had in the 80s no longer apply. Now we've got new assumptions, a new  threat model. So their basic thing was like, okay, we'll start patching the bugs that people  report. So that's like impact from the days of loft. Microsoft not even patching things. So  making some progress there. They had what was called the secured windows initiative. Very  fascinating strategy. They had three program managers review all the components in windows that  are being written by thousands of developers. So they file some bugs. The devs fix the bugs and  you got a secure product, right? Anything wrong with that? Maybe? No? Make sense? Okay. Okay. So  hopefully you don't buy that. So they released XP in 2001. How did that go for them? Well, they  had code red and NIMDA. So kind of as bad as it gets is like all your machines get worms  throughout the whole world. Kind of bad. Plus, of course, that was the area when everyone, kind of  your average person was getting computer viruses all the time, right? And that's when the normal  non-technical person was introduced to the fact that your computer just gets hacked, right? And  that's just kind of how we thought things were. So around 2002, Bill Gates sends out this  trustworthy computing memo. He and Craig Monday worked on it. I'm going to keep asking, who has  read the trustworthy computing memo? Okay, a few people, a few more, right? So very cool tidbit.  Half this talk is like plugging other things I think you should check out. A cool tidbit of  internet history is, so Bill Gates did this every few years, he'd send an email to the company and  say, everybody, we need to pile on.NET. Okay, everybody, we need to work on the internet.  That's the new wave. Okay, everyone, we need to work on security. And that's what this was in 2002.  So a couple interesting quotes here. I'll draw your attention to the bottom one. This is Bill  Gates talking to his employees at Microsoft. When we face a choice between adding features and  resolving security issues, we need to choose security. It's like maybe you didn't know Bill Gates  ever said something like that, right? So he did and that was, you know, whether or not they  followed through just having the president or whatever CEO of your organization say that makes a  big difference. So you can see how the strategy here is both top down and bottom up. So they didn't  just talk to Bill Gates, but they also worked on the technical side. So around this time, they were  pushing the initial iteration of SDL before they called it that. They did like threat modeling  and code review and static analysis and a few different things. Sort of ad hoc. And so they had  some initial success with those which enabled them to make it into a mandatory process. So but  they had enough success that they were, they had a meeting with all the executives, right? And it's  like 30 minute meeting, the executives say, okay, everyone's doing SDL now, mandatory process. And  it was an easy meeting because the executives knew about it and it was easily accepted by the  developers because the developers knew about it, right? So it wasn't like this rule that came out  of nowhere. Their initial version of SDL came out in 2004. It's been updated regularly. I call  out fuzzing in particular so it's like this cool vulnerability analysis technique really didn't  become significant until a couple years into the process, right? So they, it's like they were doing  all these basic things and you might think, oh, we need to do this cool fuzzing stuff. It's like,  well, they spent the first couple years getting on top of threat modeling, code review and static  analysis, right? So it was pretty mature by 2007. And if you haven't seen the Mac versus PC  commercial, just go check it out. So around this time, Apple starts this campaign of, hey, here's  why your PC is terrible and Mac is way better. And this was one of the commercials on TV was  saying, hey, look at PC. They're so dumb they have viruses. Ha! Right? And really, there's some  genius, some marketing genius here. So they took all the pent up, kind of vague, undirected  discontent that people had and pointed it all at Microsoft. They said, it's not computers that are  the problem, it's Microsoft. Right? And so this is kind of how they got their popular reputation  among non-technical people of being the thing that has all the viruses where Mac is way better.  Even if Mac security may not have been a lot better. Right? And so we're coming around 10 years  later. Nowadays, people say, hey, don't bother with antivirus. Like, Windows Defender is pretty  good. Your antivirus is going to be annoying. Just use Windows 10 the way they ship it. Right?  At least that's what a lot of people say in my philosophy because I don't like Mac-a-Phee. So  what you had here is kind of a 20-year cycle. So you're thinking, like, okay, they started in  1999, took them maybe 10 years to really get on top of the process. By 2007, they might be the  most secure in terms of their development practices in the world, way beyond the average in  terms of code quality and security. And yet their reputation is going down the drain. Right? And  it's not until, like, people sort of forget. Like, nobody realizes that it gets better. It's  like people don't talk about it as much anymore. And their reputation sort of heals over time. So,  you know, going back to math class, your security practices are sort of the derivative, the  velocity of your code quality. Right? And your code quality is the velocity of your reputation.  Right? So by changing your security practices, all you're changing is the acceleration of which  way your reputation is going. So around 2007, they had these top-of-line security practices.  Reputation is still going down. It's like it's too late to help the reputation thing. You're  going to have to wait 10 years for it to kind of pop back up. Right? So that's just something to  keep in mind from the reputation side. It's like you need to hit it ahead of time. So that's  basically the history of SDL. We'll go through a quick intro. We'll kind of buzz through this. So  standard requirements would, there's a thing for every phase in the development cycle. This is  straight off Microsoft's website. So you do like training and stuff and you have standard  requirements. These are the security requirements that our products have. You got bug bars, which  I think this is super cool. So you can Google like Microsoft sample bug bar. And they have this  huge page with this huge table. And this is an excerpt from the server software table. So if  you have server software and you have an elevation of privilege bug that's usable by a remote  anonymous user and it has these certain right access violation properties, then it is a critical  security vulnerability. Right? If you have denial of, but if it's authenticated elevation of  privilege, then it's important. If you have denial of service and it's anonymous and persistent,  then it qualifies as an important bug. Right? And if it's temporary denial of service, then the  question is what kind of amplification do you get with that denial of service attack that  classifies the severity. This all matters because they agree ahead of time to hold releases or  drop features for certain severities of bugs. So they talk about it ahead of time. I'm really  impressed. I haven't seen this up close. Right? But it's like you have this framework so there's no  uncomfortable meetings. Everybody knows when we're going to stop release because of a bug. Super  cool. The modeling we talked about, attack surface analysis is basically with our modeling with  attack surface emphasis. Implementation, these are the kind of things that developers will tend to  do even if they're not really working on security in particular. I guess that's kind of like static  analysis or coding standards. Hopefully your developers are working on that or interested at  least in a coding standard. And then you got like Fuzz testing and you, and pen testing is, they,  they call it an optional step in their process. Reason being pen testing doesn't scale super  well. So if you're putting out a lot of software, it's hard to pen test all of it in an effective  way. Right? You could do rubber stamp pen tests where you're doing like two-day engagements all  the time, but you're not actually going to do meaningful work. So you need to leverage your  pen testing, either focus it on the things that matter or use your pen testing results and leverage  them to effect change. So that's a thing that you need to be strategic about. And I just bring  that up to say it's not all, not all about pen testing. Like that's one aspect of the process.  If you're looking at it from a software development point of view. And then you have like incident  response plan and responses like, well, you implement your response plan. That's surprising.  So I talk about this diagram. So I view this as the crux of like where I fit in as sort of the  intersection between development and an offensive red team security. Right? Like this is where,  where the balance point is and there's different aspects of different roles that contribute.  But ultimately you're trying to make the software more secure at the end of the day. Right? We're  not just pen testing for fun. Well, maybe we are. But that's not what the company wants. So a  couple, all right, making it happen. So basically I think you need good soil and then there's a  few details about how you make things happen if you want to change how a business does things. So  you need a company that cares about security and, and, and or quality or safety or something like  that. Not all companies are incentivized the same way. That's okay. It's like if you want to get  into it more, find someone who cares about security. And there's two sides of that. You, you need a  business reason to care. Right? That's how you, or else you're not really helping the business. And  then you need people in the business that just care in general. My, my old boss used to say you  can never pay someone enough to care. So you just need good stuff to work with. Random, don't make,  don't mistake lack of concern about your opinions for lack of concern for security in general. I've  seen people do this. People reject my ideas. Therefore they don't care about security. It's  like no, maybe you have bad ideas, maybe you have good ideas, but you didn't talk about them very  well. Maybe their priorities are different than yours. It's like that doesn't mean they're a bad  person. Right? So you, you got to distinguish between do they just not care or do I need to  communicate better? So some of the details which is really just a couple stories of what I saw.  Some things that worked for me or didn't work. So I'm working at a company that cares. They tell me,  hey, do some fuzzing please. And I, I said, okay. And then they didn't really tell me to like do  SDL. So I'm learning about it, reading about it, watching videos online. And I start pushing it  within my own group. So I'm like giving these presentations about here's what our company should  do. Giving it to the like three people on my team. Telling them what, you know, like, hey, you  know, maybe we should do this as a company and getting our whole team on the same page. Seeing if  that's appropriate. Seeing, you know, what people's ideas are. And then, so what I ended up doing was  kind of doing the SDL thing with one activity which was fuzzing in my case. Pushing it within my  own team. So little comment about inward communication. Cool random inaccurate quote from  somewhere that I don't remember. The most effective CEOs are the ones who spend the most time on  internal communication. So being a superstar CEO does not equate to being successful with  regard to how your company actually performs. Maybe successful with getting your company  funding which makes your company successful. Right? But it's like if you want things to run  smoothly, if you want your company to go places, it's like it takes work, takes a lot of time just  to communicate and get people on the same page. I guess I don't really know if that's  statistically accurate but it makes sense to me. Become the domain. So what I did was I got good  at fuzzing. Then I like started talking to people about fuzzing. And I started saying, hey, this  is what fuzzing is. Our company should do it. Hey, this is what fuzzing is. It's important for  security. Come back a couple months later. Hey, here's some like cool fuzzing stuff that we did.  Here's some bugs that we found. Come back a few months later. Hey, here's some bugs we found in  actual products. Here's the money that we saved by doing this activity. Right? And so you're  exposing people to it, creating a culture of normalcy around this practice. It's like you  want people to get the impression that they ought to be doing this. You want people to want to do  it. And it's like really people should be wondering why they're not doing it. Like your average  developer should be like, huh, shouldn't we be fuzzing? Like they've been talking to us about  that. Why aren't we doing it? And once you get that, it's then you can make it into a kind of a  process or a rule. Right? And this is why I think processes are cool or how they can be cool. It's  like if you don't do it this way, the processes can be this sort of bureaucratic, annoying thing  that doesn't help anybody. But if it actually reflects what's useful in the company, right, what  you get out of making it a process is a few things. You keep people from falling through the  cracks. You kind of burn it into the cultural, the organizational memory. And then you also get  that last 10% of people who won't do anything unless you make them do it. Right? So there's  hopefully a minority of people that you're forcing into it. Most people already are doing it. Then  like we found some bugs and I made up some numbers that we saved a whole ton of money. In our case  that was because release cycles are expensive. So I was like, hey, we saved this many bug releases.  We saved this much money. Not to mention maybe millions in opportunity costs because it takes a  lot of time to spin firmware. So I was like, woo, we saved a lot of money. Justify my existence in  my role. So that was kind of a win. Again, I was like, I'm doing this from like a low level  employee. I'm not trying to like exalt myself here. I'm just saying like this is what worked for  me. This is how I found I could have an impact within my organization from the bottom. So then  there was this other security feature. It is basically an authentication strategy for our entire  product line. Somebody else had the idea. Not my idea. I heard people talking about it. I'm like,  hey, that's a good idea. And they're like, yeah, we think so. And then it wasn't moving forward.  So it was solved for a solid year. This idea was kind of sitting on the table. No one was doing  anything about it. A lot of people were frustrated. It's like the security people are like, man,  why don't you do this thing? It's so obvious. So why was it not moving forward? This is kind of my  post-mortem of what happened. There was a good idea in too few details. So maybe because of  people's other priorities or people are busy, they don't hash through the details. They don't  hash through the details. So they don't have answers to questions. What happens is if you can't  answer the questions, you look wrong. And then if people come back three months later, you still  can't answer the questions. You look really wrong. And then if you come back three months later and  tell them again the same thing and you still can't answer the questions, people are about ready to  flip the table and leave the room because you haven't answered their questions. So if you don't  get into those details, you don't have, it's like you got to answer questions. Even when it's kind of  a dumb question, you're like, that doesn't matter. That's just a detail. It's like people want the  answer. And it's like it doesn't make sense to them without the answer. I observed kind of a  false belief that being right, just because I'm right, that means others need to listen to me.  It's like, no, you could be the most correct person in the world. And if you're a bad communicator,  no one's going to listen to you and they shouldn't because it's going to be a waste of their time  to try. Right? So you must be a good communicator. So there's going to be times when you're right  and others don't get it. It's like it's okay. Nobody committed a crime. It's like work on your  presentation, come back. You know? So not too tricky. There's a tendency to think, I think, in  security in general. And actually I kind of got this idea from Rob Graham on Twitter. He talks  about this. He's like, hey, sometimes security people are like, you know, if you don't do what we  say, you are wrong morally. It's like you need to confess your sins to the security priest because  you've been a bad person because you didn't do what I said. Like, well, no. It's like maybe they  don't understand. Right? Maybe their priorities are different than yours. Maybe it's not a good  idea. You know, it's technical disagreement. So it's like if you, I've seen people and I think we  probably have all seen people get into that mindset. People don't listen to me because they're  wrong morally. And it's like you become the guy who sits in the corner ranting at everybody and  nobody listens to them. So don't want to be that guy. And then I also observed an  apprehension against taking on responsibility, feeling like it's somebody else's job. Or sometimes  it is. So what ended up happening was we're in this meeting and it's like half the room thinks  this idea is great. Half the room is like, I don't know. I got all these questions. I don't want to  do it. It's like I don't even think you really know what you're talking about. So we got this  like impasse and someone says, hey, we need someone to like make a proposal and hash out all the  details for us so we can analyze this. So I raised my hand and said, oh, our team can do that. We  can do that. And they said, great, Joshua, you will do that. See you in two weeks. Oh, okay. So I  practiced, again, coming back to internal communication. So I practiced with colleagues,  teammates, friends, old coworkers, like buddies. So I'm kind of calling in favors from everyone I  know whose opinion I even mildly respect. You know, salespeople, technical sales engineers,  whatever. And like, come listen to the idea. Does it make sense from what you know? It's like, do  you think customers will like this? Do you think they'll do it? Do you think it's a good idea?  Does it make sense? And so I was kind of using some social capital there. But also people like to be  early adopters, right? People like to have an opinion. If you tell them, hey, there's this idea,  might change our company's whole direction, can you come give some input? Like, oh, yeah, cool. And  people like giving feedback too. So I didn't really have to use a lot of social capital. It's just,  especially technical people like to be early adopters. So I practiced full time, a couple weeks,  presented it to the people I said I was going to present to. They're like, mm-hmm, kind of maybe.  Maybe. And then they had some questions I hadn't thought of. So presented again a little while  later. And I presented again and again. And then I ended up eventually in meetings with like the  head of R&D with, you know, with my manager and my team. And we're like saying, hey, this is what  we're going to do. Working out the details. My proposal moved up the management chain. It got to  the head of R&D. And that's when they stopped inviting me to the meetings. Like, no, you don't get to  talk to the executives. You've done a good job. You can go home now. But it worked. I think that was  good. Because it's kind of a whole different skill set. You get high enough and it's, it becomes a  different game. And then another plug is this deaf contact. So around the same time I'm doing this  stuff, I hear this talk last year from the social engineering village, change agents, how to affect  corporate culture. And they're talking about the same thing. They're like, they're at the bottom.  And they're like, how do you push something up all the way to the CEO? Get the company to do  something different. And it's kind of a fun game if hope you get the opportunity to play it sometime.  Fun. So as the idea progressed, right, so eventually, you know, the end of the story is, hey, we  agreed to do it. Everybody's happy. My boss is happy. As the idea progressed, I became more  involved, went from just like proposing it to kind of doing it, writing the specs at our company,  writing the specs is like one step shorter writing the software. It's like you write the  software. It's like you just fill in the blanks at that point. Right. So that was a big process,  writing the specifications, basically saying what it's going to do, what's the API is going to look  like. Stop just short of writing the code myself, partly because I switched jobs at that point.  But if we had gotten to that point and I wasn't a developer, not sure what would have happened.  Right. So we wrote the specs before anyone like approved us writing the specs. It's like we know  this is going to places. They're going to want the details. We're going to have the details ready  for them. Right. So if I didn't, this is, I'm just saying like, hey, how can you be helpful as a  developer? It's like if I didn't have that development background, I would have been like, I  don't know how to write a spec or I don't know how we do software here. Can someone else do that?  Right. And it may not have happened because there wasn't anyone else to do it at the time. It was  like we didn't have, they weren't giving us money to hire a team. Right. So like you can leverage  your skills that way. And it's like I needed the technical details at that point. And then we, you  know, we did it. So cool security feature. Kind of changed the, I would say changed the security  strategy of our whole company's $100 million business. At least one aspect of the security  strategy. So that's like my stories about making it happen. Stories about how it, why it didn't  happen for a long time. And I'll close with a couple tips depending on what kind of person you  want to be. So if you wanted to become obnoxious and useless for a long time, you may have thought  you couldn't, but you can. And I will tell you how in eight easy steps. There's a premium program  you can enroll in for a small monthly fee. So please contact me if you're interested in and I  can help you get there. And specifically the obnoxious and useless process guy that nobody  likes to and everybody works around. You know that guy. You can, so tip one, just burn through  these real quick. Make things into mandatory processes. This is like the fast track. You want  to get it done. Just like make a bunch of rules before people know how it works. And then like  beat them over the head when they don't do it, right? So it's a good system. Especially helpful  if your organization is big and you can't possibly explain it to people in enough time for them to  get it done. Top down, don't ever talk to the devs. They are not worth talking to. Go to your boss  with grandiose schemes that you don't really understand. Be pushy. Remember, you are the genius.  It's all about you. If your boss doesn't listen to you, it's because he's dumb. That's another good  trick. Do bad at your current job. This one I would say is important. Don't forget to daydream  about all the cool things you would do if you had a different job. If that's not your thing,  though, you can also do okay at your current job and you can still become annoying. It's  important to daydream, though, and voice your opinions loudly without thinking about them. Or  you can even do slightly above average at your job. You're getting kind of in the risky territory  at this point. It's like you're in high danger of becoming useful. But if you keep on telling  people they're wrong, you can still do it. So just kind of doing a little above average. Yeah,  make rules that people, this kind of goes along with the first one that they don't learn about  until right before they release. Then try to get them to push their release date back and don't  like say it's your fault. Make sure they know it's their fault. Turn every piece of advice into a  moral crusade with vindictive condemnation. Now, these are all running together. So if you do  these things all at once, you're going to be on the fast track. So if people don't listen to you,  it's because they're a bad person. And you can get mad at them. You should get mad at them. Take  ownership of your baby. And this might sound contradictory because you're trying to get other  people to do things, but you can still take ownership of your baby and not let anyone else  have input on it. Right? So it's like it's your baby. And the goal here is to kind of have a  creepy vibe. Like maybe you hiss at people or kind of like lash at them. And your goal here is to  like kind of get this fence of people being repulsed and wanting to stay away from you and  your project. Right? And if you're lucky, you'll get funding to kind of be, not bother anyone. Of  course, the opposite of that would be trying to work yourself out of a job. That's dumb because  then you're not going to have a job, right? So, but if you don't want to be that kind of guy, I do  have a few tips for moving the organizational needle in a real way. So first is to do awesomely at  your job. Unless awesome is an adverb, then just do awesome at your job. I don't use that phrase  too lightly. Like people should be impressed. Right? You all know that guy in the office here.  Everyone's like, man, that guy's super smart. And it's like, why is it always how the right answers?  And how can he's always thought about everything before we ask him? How can he's always learning  more stuff and has opinions about what our company should do and they make sense? And how come he's  good at explaining? It's like, you want to be that impressive guy if you're trying to do this kind  of thing. And it's like, I don't mean to be like, this is not very egalitarian, right? It's like,  some people are kind of on the lower side of the average and some people on the higher side. If you  want to change things, you want to be on the higher side of the average. If you're not, if you're  working hard and you find that you're below average, it's like, maybe you need a different  specialty, right? Or a different angle. But most people can become above average in a lot of  things just by working hard. Because not everybody does. Take time to get good at explaining. If  you have a hard time explaining, it's likely because you don't understand yourself. No, you're not  a genius. You're overconfident and maybe a little, maybe you talk too much. Right? It's just in  general, you know, some people are better at this than others, right? You can kind of practice at it.  My practice is like every presentation I practice it a whole bunch of times. Otherwise, it isn't  smooth or it's not as smooth as it could be. But even if you're not like an expert explainer, it's  like, if you got technical people, if you have capable people in the room and they're honestly  listening, it's like you should be able to, you know, they should be able to get it with little  time. So it's like if you have people that are being patient, asking honest questions and you  can't get the idea across, it's like you need to work on that presentation. I'm a big fan of  presentations. Maybe this is not a technique that everyone uses. But if your company has like  brown bags or lessons learned or whatever, as like leverage those, present multiple times if you  really want people to do something, it's like burn it into the memory and keep them short  presentations. Random tidbit from Paul McMillan tweeted one time, one new security control is  one new employee. So like don't kid yourself on what you can accomplish. So if you're one person,  if you're not a manager, Steve Lipner, when he was doing this, he had kind of a little organization  he was working with. Right? It's like if you're one guy, you can basically do one thing. And that  was kind of what I ended up doing with fuzzing. It's like I didn't even think fuzzing was the most  important thing. That was just what they gave me to do. And I took it as far as I could. Right?  And so if you're a manager, like don't give your team of two people 20 things to do. And obviously,  like not very hard, but I think that saying that it's like one control, one thing is one person.  It's like if you're stretching it, most times you're stretching it too far. If you're giving  people two or three things to do, it's like it might seem like static analysis isn't that hard.  Like can't you do static analysis and threat modeling? It's like you're going to hurt yourself.  Support people, don't complain, make things better. I got a little time here. So like one  slide on software sign off. Who's like heard the term software sign off before? Okay. If you  guys could like talk to me afterwards, I'd love to hear about it. Because I've heard about it like  two times and I don't know very much, but I think it's super cool. So my understanding is it's an  extension of engineering sign off. Right? So if somebody builds a bridge and we're talking about  software that needs to be secure, somebody builds a bridge and engineer signs off on it. It's like  I'm the engineer, I say it makes sense. Or you got contractors working and something looks sketchy,  they call an engineer, the engineer signs off and says if you do these things, it's safe. Right?  And then if the bridge falls down, people die, people can go back and say who was the engineer?  Did they do something wrong? It's like why'd you sign off on it? Can you defend what you did as  being safe even though something went wrong? The idea is not to hang people, but you can, it can  vindicate people. It's like you document what you did and you show that you did a good job. So this  is something that I think would be cool. And I've, it's like I've seen kind of sort of halfway done,  but it's like when you have sign off processes and checklists, sometimes they become a rubber  stamp. And the key here is like making sure that people take ownership of what they sign off on.  Right? And to do that, you need a mature process where people can feel confident in what they're  doing. It kind of like hooks into code review. Like my philosophy is if you're, if you approve the  code, it's your code, you're responsible for any bugs that happened in it. Right? Kind of like  golf style. It's like the guy who signs off is responsible, helps like root cause analysis.  That fits in somewhere here, but I don't know where. So that's like all my ideas and what I  think the intersection of developing and hacking is. So in conclusion, to change the world as a  programmer, do really good at what you do. Work for a company where it can be appreciated. Find  something to improve. Other random tidbit, if you're kind of a blue team, develop a background.  It's like find a cool security tool that open source and people aren't working on it and is like  work on it. It's like you can leverage your skills in that way if you don't want to do the  organizational like business-y approach. Be a patient explainer. Really definitely check out  Steve Lipner's talk. I highly, highly respect him, especially in this talk. Read threat  modeling. And I'll just close saying high quality developers can make a difference. This is what I  see as being sort of the crux of the intersection. And there's all sorts of sides to that, like  where you can contribute. So hopefully that was helpful for some people. Thank you very much for  your time.  Thank you.
DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_0_2183.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_2184_3347.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_3348_4199.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_4200_4679.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_4680_5279.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_5280_5939.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_5940_7103.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_7104_11339.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_11340_12083.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_12084_16415.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_16416_17123.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_17124_21143.png DEF_CON_26_BLUE_TEAM_VILLAGE_-_jtpereyda_-_Hacking_Your_Dev_Job_to_Save_the_World_XsJi_1LabJw_21144_54041.png
So what we have before us is Joshua Pareda. He's going to be talking about hacking your dev job to save the world. Give him a round of introduction and applause. Short people, the adjustment here. So I guess a little background, how many of you are sort of developer types in here? Good bunch. Okay. Maybe half almost. Okay. Probably more of you have worked with code if that's not your main thing. So this is basically the talk I would have liked to have heard my first year at DEF CON. First of all, thank you for coming out and taking a few minutes out of your DEF CON adventure. Hope that it's worthwhile, maybe inspiring. If not, just leave halfway through. I won't be offended. So quick outline. Just going to talk about the background of why I'm talking and what my story is. Talk about a talk that changed my life or at least my career. Talk about SDL. How many of you have heard of secure development lifecycle? Okay, quite a few. More than raise their hand for developers. Sweet. So I won't spend a lot of time hammering through that. It will be real quick because that's not what the talk is about exactly. I'll talk about how making things happen and then some random tips at the end depending on whether you want to become the obnoxious security guy or change how your organization does things. So a little background. I'm from Moscow, Idaho. Yeah. Woo! I worked at an ICS manufacturer. Big business for a small town. Not a noticeable business by big city standards. Developer background as interest in security. The end of it is I ended up making what I think is a big difference within a pretty big business. So I got fuzzing adopted and doing this kind of from the bottom rung of the management tier. I got fuzzing adopted and standardized within this whole organization of over a thousand developers. I think changed the way we did authentication across some of our big product lines. Really changed our company's security strategy in one aspect. Quick plug for B-Sides Boise if you're in or around Idaho. Any B-Sides Boise people? Yeah, no. Okay. Good deal. He knows what's up. So how did I get there? So I was developer. I was kind of opinionated and detail-fixed and that's what got me interested in security is like seeing the corner cases. I worked at a company that cared. So dollars and human lives are on the line in a real way and that helps to have a company that really has an interest in security, right? I started hacking and stuff and so I got hired to do fuzzing and realized that every time I fixed a bug it was like fixing one bug. Nothing to be ashamed of but as like this isn't going to scale very well. It's not going to change very fast if all we're doing is finding and patching, right? If all we're doing is fixing what we find. So then I learned about threat modeling which is I'm guessing most people have heard about before, right? So it's like this born design time activity. It was new for me at the time. It's like you don't get any elite zero days or cool CVEs next to your name but you can actually have a lot of leverage. You can save dozens or hundreds of issues in the time it would usually take you to find one which is what I think is cool about it. Right? You guys have heard about this before but threat modeling is basically like what are we building? It's like what could go wrong with that and how do we fix? What could go wrong with that? At least that's kind of how Adam Schostack breaks it down. I really like his book. It kind of cuts through the craft and he goes through a lot of like this is the stupid way to do threat modeling that the SISB exam tells you about and it's like here's why it's kind of dumb. So it cuts through the craft even though it seems like a boring topic. Then I heard the talk that changed my life which is from Steve Lipner, the security development life cycle. Has anyone seen this particular talk? Okay. A couple guys back there. I think it's super cool. Really changed how I thought about this topic. Steve Lipner was at Microsoft for a long time. At least a couple decades. I guess coming up on a couple decades if he's still there. He really was instrumental in changing how security happened at Microsoft. Really big change and it's cool to just hear him. This talk is not about SDL itself. It's about how he got it to happen at Microsoft. So inspiring. I'll talk a little bit about that. Just the 50,000 foot view. Around 1999 is when Steve Lipner started. There's a changing threat landscape. The internet comes up. All the assumptions we had in the 80s no longer apply. Now we've got new assumptions, a new threat model. So their basic thing was like, okay, we'll start patching the bugs that people report. So that's like impact from the days of loft. Microsoft not even patching things. So making some progress there. They had what was called the secured windows initiative. Very fascinating strategy. They had three program managers review all the components in windows that are being written by thousands of developers. So they file some bugs. The devs fix the bugs and you got a secure product, right? Anything wrong with that? Maybe? No? Make sense? Okay. Okay. So hopefully you don't buy that. So they released XP in 2001. How did that go for them? Well, they had code red and NIMDA. So kind of as bad as it gets is like all your machines get worms throughout the whole world. Kind of bad. Plus, of course, that was the area when everyone, kind of your average person was getting computer viruses all the time, right? And that's when the normal non-technical person was introduced to the fact that your computer just gets hacked, right? And that's just kind of how we thought things were. So around 2002, Bill Gates sends out this trustworthy computing memo. He and Craig Monday worked on it. I'm going to keep asking, who has read the trustworthy computing memo? Okay, a few people, a few more, right? So very cool tidbit. Half this talk is like plugging other things I think you should check out. A cool tidbit of internet history is, so Bill Gates did this every few years, he'd send an email to the company and say, everybody, we need to pile on.NET. Okay, everybody, we need to work on the internet. That's the new wave. Okay, everyone, we need to work on security. And that's what this was in 2002. So a couple interesting quotes here. I'll draw your attention to the bottom one. This is Bill Gates talking to his employees at Microsoft. When we face a choice between adding features and resolving security issues, we need to choose security. It's like maybe you didn't know Bill Gates ever said something like that, right? So he did and that was, you know, whether or not they followed through just having the president or whatever CEO of your organization say that makes a big difference. So you can see how the strategy here is both top down and bottom up. So they didn't just talk to Bill Gates, but they also worked on the technical side. So around this time, they were pushing the initial iteration of SDL before they called it that. They did like threat modeling and code review and static analysis and a few different things. Sort of ad hoc. And so they had some initial success with those which enabled them to make it into a mandatory process. So but they had enough success that they were, they had a meeting with all the executives, right? And it's like 30 minute meeting, the executives say, okay, everyone's doing SDL now, mandatory process. And it was an easy meeting because the executives knew about it and it was easily accepted by the developers because the developers knew about it, right? So it wasn't like this rule that came out of nowhere. Their initial version of SDL came out in 2004. It's been updated regularly. I call out fuzzing in particular so it's like this cool vulnerability analysis technique really didn't become significant until a couple years into the process, right? So they, it's like they were doing all these basic things and you might think, oh, we need to do this cool fuzzing stuff. It's like, well, they spent the first couple years getting on top of threat modeling, code review and static analysis, right? So it was pretty mature by 2007. And if you haven't seen the Mac versus PC commercial, just go check it out. So around this time, Apple starts this campaign of, hey, here's why your PC is terrible and Mac is way better. And this was one of the commercials on TV was saying, hey, look at PC. They're so dumb they have viruses. Ha! Right? And really, there's some genius, some marketing genius here. So they took all the pent up, kind of vague, undirected discontent that people had and pointed it all at Microsoft. They said, it's not computers that are the problem, it's Microsoft. Right? And so this is kind of how they got their popular reputation among non-technical people of being the thing that has all the viruses where Mac is way better. Even if Mac security may not have been a lot better. Right? And so we're coming around 10 years later. Nowadays, people say, hey, don't bother with antivirus. Like, Windows Defender is pretty good. Your antivirus is going to be annoying. Just use Windows 10 the way they ship it. Right? At least that's what a lot of people say in my philosophy because I don't like Mac-a-Phee. So what you had here is kind of a 20-year cycle. So you're thinking, like, okay, they started in 1999, took them maybe 10 years to really get on top of the process. By 2007, they might be the most secure in terms of their development practices in the world, way beyond the average in terms of code quality and security. And yet their reputation is going down the drain. Right? And it's not until, like, people sort of forget. Like, nobody realizes that it gets better. It's like people don't talk about it as much anymore. And their reputation sort of heals over time. So, you know, going back to math class, your security practices are sort of the derivative, the velocity of your code quality. Right? And your code quality is the velocity of your reputation. Right? So by changing your security practices, all you're changing is the acceleration of which way your reputation is going. So around 2007, they had these top-of-line security practices. Reputation is still going down. It's like it's too late to help the reputation thing. You're going to have to wait 10 years for it to kind of pop back up. Right? So that's just something to keep in mind from the reputation side. It's like you need to hit it ahead of time. So that's basically the history of SDL. We'll go through a quick intro. We'll kind of buzz through this. So standard requirements would, there's a thing for every phase in the development cycle. This is straight off Microsoft's website. So you do like training and stuff and you have standard requirements. These are the security requirements that our products have. You got bug bars, which I think this is super cool. So you can Google like Microsoft sample bug bar. And they have this huge page with this huge table. And this is an excerpt from the server software table. So if you have server software and you have an elevation of privilege bug that's usable by a remote anonymous user and it has these certain right access violation properties, then it is a critical security vulnerability. Right? If you have denial of, but if it's authenticated elevation of privilege, then it's important. If you have denial of service and it's anonymous and persistent, then it qualifies as an important bug. Right? And if it's temporary denial of service, then the question is what kind of amplification do you get with that denial of service attack that classifies the severity. This all matters because they agree ahead of time to hold releases or drop features for certain severities of bugs. So they talk about it ahead of time. I'm really impressed. I haven't seen this up close. Right? But it's like you have this framework so there's no uncomfortable meetings. Everybody knows when we're going to stop release because of a bug. Super cool. The modeling we talked about, attack surface analysis is basically with our modeling with attack surface emphasis. Implementation, these are the kind of things that developers will tend to do even if they're not really working on security in particular. I guess that's kind of like static analysis or coding standards. Hopefully your developers are working on that or interested at least in a coding standard. And then you got like Fuzz testing and you, and pen testing is, they, they call it an optional step in their process. Reason being pen testing doesn't scale super well. So if you're putting out a lot of software, it's hard to pen test all of it in an effective way. Right? You could do rubber stamp pen tests where you're doing like two-day engagements all the time, but you're not actually going to do meaningful work. So you need to leverage your pen testing, either focus it on the things that matter or use your pen testing results and leverage them to effect change. So that's a thing that you need to be strategic about. And I just bring that up to say it's not all, not all about pen testing. Like that's one aspect of the process. If you're looking at it from a software development point of view. And then you have like incident response plan and responses like, well, you implement your response plan. That's surprising. So I talk about this diagram. So I view this as the crux of like where I fit in as sort of the intersection between development and an offensive red team security. Right? Like this is where, where the balance point is and there's different aspects of different roles that contribute. But ultimately you're trying to make the software more secure at the end of the day. Right? We're not just pen testing for fun. Well, maybe we are. But that's not what the company wants. So a couple, all right, making it happen. So basically I think you need good soil and then there's a few details about how you make things happen if you want to change how a business does things. So you need a company that cares about security and, and, and or quality or safety or something like that. Not all companies are incentivized the same way. That's okay. It's like if you want to get into it more, find someone who cares about security. And there's two sides of that. You, you need a business reason to care. Right? That's how you, or else you're not really helping the business. And then you need people in the business that just care in general. My, my old boss used to say you can never pay someone enough to care. So you just need good stuff to work with. Random, don't make, don't mistake lack of concern about your opinions for lack of concern for security in general. I've seen people do this. People reject my ideas. Therefore they don't care about security. It's like no, maybe you have bad ideas, maybe you have good ideas, but you didn't talk about them very well. Maybe their priorities are different than yours. It's like that doesn't mean they're a bad person. Right? So you, you got to distinguish between do they just not care or do I need to communicate better? So some of the details which is really just a couple stories of what I saw. Some things that worked for me or didn't work. So I'm working at a company that cares. They tell me, hey, do some fuzzing please. And I, I said, okay. And then they didn't really tell me to like do SDL. So I'm learning about it, reading about it, watching videos online. And I start pushing it within my own group. So I'm like giving these presentations about here's what our company should do. Giving it to the like three people on my team. Telling them what, you know, like, hey, you know, maybe we should do this as a company and getting our whole team on the same page. Seeing if that's appropriate. Seeing, you know, what people's ideas are. And then, so what I ended up doing was kind of doing the SDL thing with one activity which was fuzzing in my case. Pushing it within my own team. So little comment about inward communication. Cool random inaccurate quote from somewhere that I don't remember. The most effective CEOs are the ones who spend the most time on internal communication. So being a superstar CEO does not equate to being successful with regard to how your company actually performs. Maybe successful with getting your company funding which makes your company successful. Right? But it's like if you want things to run smoothly, if you want your company to go places, it's like it takes work, takes a lot of time just to communicate and get people on the same page. I guess I don't really know if that's statistically accurate but it makes sense to me. Become the domain. So what I did was I got good at fuzzing. Then I like started talking to people about fuzzing. And I started saying, hey, this is what fuzzing is. Our company should do it. Hey, this is what fuzzing is. It's important for security. Come back a couple months later. Hey, here's some like cool fuzzing stuff that we did. Here's some bugs that we found. Come back a few months later. Hey, here's some bugs we found in actual products. Here's the money that we saved by doing this activity. Right? And so you're exposing people to it, creating a culture of normalcy around this practice. It's like you want people to get the impression that they ought to be doing this. You want people to want to do it. And it's like really people should be wondering why they're not doing it. Like your average developer should be like, huh, shouldn't we be fuzzing? Like they've been talking to us about that. Why aren't we doing it? And once you get that, it's then you can make it into a kind of a process or a rule. Right? And this is why I think processes are cool or how they can be cool. It's like if you don't do it this way, the processes can be this sort of bureaucratic, annoying thing that doesn't help anybody. But if it actually reflects what's useful in the company, right, what you get out of making it a process is a few things. You keep people from falling through the cracks. You kind of burn it into the cultural, the organizational memory. And then you also get that last 10% of people who won't do anything unless you make them do it. Right? So there's hopefully a minority of people that you're forcing into it. Most people already are doing it. Then like we found some bugs and I made up some numbers that we saved a whole ton of money. In our case that was because release cycles are expensive. So I was like, hey, we saved this many bug releases. We saved this much money. Not to mention maybe millions in opportunity costs because it takes a lot of time to spin firmware. So I was like, woo, we saved a lot of money. Justify my existence in my role. So that was kind of a win. Again, I was like, I'm doing this from like a low level employee. I'm not trying to like exalt myself here. I'm just saying like this is what worked for me. This is how I found I could have an impact within my organization from the bottom. So then there was this other security feature. It is basically an authentication strategy for our entire product line. Somebody else had the idea. Not my idea. I heard people talking about it. I'm like, hey, that's a good idea. And they're like, yeah, we think so. And then it wasn't moving forward. So it was solved for a solid year. This idea was kind of sitting on the table. No one was doing anything about it. A lot of people were frustrated. It's like the security people are like, man, why don't you do this thing? It's so obvious. So why was it not moving forward? This is kind of my post-mortem of what happened. There was a good idea in too few details. So maybe because of people's other priorities or people are busy, they don't hash through the details. They don't hash through the details. So they don't have answers to questions. What happens is if you can't answer the questions, you look wrong. And then if people come back three months later, you still can't answer the questions. You look really wrong. And then if you come back three months later and tell them again the same thing and you still can't answer the questions, people are about ready to flip the table and leave the room because you haven't answered their questions. So if you don't get into those details, you don't have, it's like you got to answer questions. Even when it's kind of a dumb question, you're like, that doesn't matter. That's just a detail. It's like people want the answer. And it's like it doesn't make sense to them without the answer. I observed kind of a false belief that being right, just because I'm right, that means others need to listen to me. It's like, no, you could be the most correct person in the world. And if you're a bad communicator, no one's going to listen to you and they shouldn't because it's going to be a waste of their time to try. Right? So you must be a good communicator. So there's going to be times when you're right and others don't get it. It's like it's okay. Nobody committed a crime. It's like work on your presentation, come back. You know? So not too tricky. There's a tendency to think, I think, in security in general. And actually I kind of got this idea from Rob Graham on Twitter. He talks about this. He's like, hey, sometimes security people are like, you know, if you don't do what we say, you are wrong morally. It's like you need to confess your sins to the security priest because you've been a bad person because you didn't do what I said. Like, well, no. It's like maybe they don't understand. Right? Maybe their priorities are different than yours. Maybe it's not a good idea. You know, it's technical disagreement. So it's like if you, I've seen people and I think we probably have all seen people get into that mindset. People don't listen to me because they're wrong morally. And it's like you become the guy who sits in the corner ranting at everybody and nobody listens to them. So don't want to be that guy. And then I also observed an apprehension against taking on responsibility, feeling like it's somebody else's job. Or sometimes it is. So what ended up happening was we're in this meeting and it's like half the room thinks this idea is great. Half the room is like, I don't know. I got all these questions. I don't want to do it. It's like I don't even think you really know what you're talking about. So we got this like impasse and someone says, hey, we need someone to like make a proposal and hash out all the details for us so we can analyze this. So I raised my hand and said, oh, our team can do that. We can do that. And they said, great, Joshua, you will do that. See you in two weeks. Oh, okay. So I practiced, again, coming back to internal communication. So I practiced with colleagues, teammates, friends, old coworkers, like buddies. So I'm kind of calling in favors from everyone I know whose opinion I even mildly respect. You know, salespeople, technical sales engineers, whatever. And like, come listen to the idea. Does it make sense from what you know? It's like, do you think customers will like this? Do you think they'll do it? Do you think it's a good idea? Does it make sense? And so I was kind of using some social capital there. But also people like to be early adopters, right? People like to have an opinion. If you tell them, hey, there's this idea, might change our company's whole direction, can you come give some input? Like, oh, yeah, cool. And people like giving feedback too. So I didn't really have to use a lot of social capital. It's just, especially technical people like to be early adopters. So I practiced full time, a couple weeks, presented it to the people I said I was going to present to. They're like, mm-hmm, kind of maybe. Maybe. And then they had some questions I hadn't thought of. So presented again a little while later. And I presented again and again. And then I ended up eventually in meetings with like the head of R&D with, you know, with my manager and my team. And we're like saying, hey, this is what we're going to do. Working out the details. My proposal moved up the management chain. It got to the head of R&D. And that's when they stopped inviting me to the meetings. Like, no, you don't get to talk to the executives. You've done a good job. You can go home now. But it worked. I think that was good. Because it's kind of a whole different skill set. You get high enough and it's, it becomes a different game. And then another plug is this deaf contact. So around the same time I'm doing this stuff, I hear this talk last year from the social engineering village, change agents, how to affect corporate culture. And they're talking about the same thing. They're like, they're at the bottom. And they're like, how do you push something up all the way to the CEO? Get the company to do something different. And it's kind of a fun game if hope you get the opportunity to play it sometime. Fun. So as the idea progressed, right, so eventually, you know, the end of the story is, hey, we agreed to do it. Everybody's happy. My boss is happy. As the idea progressed, I became more involved, went from just like proposing it to kind of doing it, writing the specs at our company, writing the specs is like one step shorter writing the software. It's like you write the software. It's like you just fill in the blanks at that point. Right. So that was a big process, writing the specifications, basically saying what it's going to do, what's the API is going to look like. Stop just short of writing the code myself, partly because I switched jobs at that point. But if we had gotten to that point and I wasn't a developer, not sure what would have happened. Right. So we wrote the specs before anyone like approved us writing the specs. It's like we know this is going to places. They're going to want the details. We're going to have the details ready for them. Right. So if I didn't, this is, I'm just saying like, hey, how can you be helpful as a developer? It's like if I didn't have that development background, I would have been like, I don't know how to write a spec or I don't know how we do software here. Can someone else do that? Right. And it may not have happened because there wasn't anyone else to do it at the time. It was like we didn't have, they weren't giving us money to hire a team. Right. So like you can leverage your skills that way. And it's like I needed the technical details at that point. And then we, you know, we did it. So cool security feature. Kind of changed the, I would say changed the security strategy of our whole company's $100 million business. At least one aspect of the security strategy. So that's like my stories about making it happen. Stories about how it, why it didn't happen for a long time. And I'll close with a couple tips depending on what kind of person you want to be. So if you wanted to become obnoxious and useless for a long time, you may have thought you couldn't, but you can. And I will tell you how in eight easy steps. There's a premium program you can enroll in for a small monthly fee. So please contact me if you're interested in and I can help you get there. And specifically the obnoxious and useless process guy that nobody likes to and everybody works around. You know that guy. You can, so tip one, just burn through these real quick. Make things into mandatory processes. This is like the fast track. You want to get it done. Just like make a bunch of rules before people know how it works. And then like beat them over the head when they don't do it, right? So it's a good system. Especially helpful if your organization is big and you can't possibly explain it to people in enough time for them to get it done. Top down, don't ever talk to the devs. They are not worth talking to. Go to your boss with grandiose schemes that you don't really understand. Be pushy. Remember, you are the genius. It's all about you. If your boss doesn't listen to you, it's because he's dumb. That's another good trick. Do bad at your current job. This one I would say is important. Don't forget to daydream about all the cool things you would do if you had a different job. If that's not your thing, though, you can also do okay at your current job and you can still become annoying. It's important to daydream, though, and voice your opinions loudly without thinking about them. Or you can even do slightly above average at your job. You're getting kind of in the risky territory at this point. It's like you're in high danger of becoming useful. But if you keep on telling people they're wrong, you can still do it. So just kind of doing a little above average. Yeah, make rules that people, this kind of goes along with the first one that they don't learn about until right before they release. Then try to get them to push their release date back and don't like say it's your fault. Make sure they know it's their fault. Turn every piece of advice into a moral crusade with vindictive condemnation. Now, these are all running together. So if you do these things all at once, you're going to be on the fast track. So if people don't listen to you, it's because they're a bad person. And you can get mad at them. You should get mad at them. Take ownership of your baby. And this might sound contradictory because you're trying to get other people to do things, but you can still take ownership of your baby and not let anyone else have input on it. Right? So it's like it's your baby. And the goal here is to kind of have a creepy vibe. Like maybe you hiss at people or kind of like lash at them. And your goal here is to like kind of get this fence of people being repulsed and wanting to stay away from you and your project. Right? And if you're lucky, you'll get funding to kind of be, not bother anyone. Of course, the opposite of that would be trying to work yourself out of a job. That's dumb because then you're not going to have a job, right? So, but if you don't want to be that kind of guy, I do have a few tips for moving the organizational needle in a real way. So first is to do awesomely at your job. Unless awesome is an adverb, then just do awesome at your job. I don't use that phrase too lightly. Like people should be impressed. Right? You all know that guy in the office here. Everyone's like, man, that guy's super smart. And it's like, why is it always how the right answers? And how can he's always thought about everything before we ask him? How can he's always learning more stuff and has opinions about what our company should do and they make sense? And how come he's good at explaining? It's like, you want to be that impressive guy if you're trying to do this kind of thing. And it's like, I don't mean to be like, this is not very egalitarian, right? It's like, some people are kind of on the lower side of the average and some people on the higher side. If you want to change things, you want to be on the higher side of the average. If you're not, if you're working hard and you find that you're below average, it's like, maybe you need a different specialty, right? Or a different angle. But most people can become above average in a lot of things just by working hard. Because not everybody does. Take time to get good at explaining. If you have a hard time explaining, it's likely because you don't understand yourself. No, you're not a genius. You're overconfident and maybe a little, maybe you talk too much. Right? It's just in general, you know, some people are better at this than others, right? You can kind of practice at it. My practice is like every presentation I practice it a whole bunch of times. Otherwise, it isn't smooth or it's not as smooth as it could be. But even if you're not like an expert explainer, it's like, if you got technical people, if you have capable people in the room and they're honestly listening, it's like you should be able to, you know, they should be able to get it with little time. So it's like if you have people that are being patient, asking honest questions and you can't get the idea across, it's like you need to work on that presentation. I'm a big fan of presentations. Maybe this is not a technique that everyone uses. But if your company has like brown bags or lessons learned or whatever, as like leverage those, present multiple times if you really want people to do something, it's like burn it into the memory and keep them short presentations. Random tidbit from Paul McMillan tweeted one time, one new security control is one new employee. So like don't kid yourself on what you can accomplish. So if you're one person, if you're not a manager, Steve Lipner, when he was doing this, he had kind of a little organization he was working with. Right? It's like if you're one guy, you can basically do one thing. And that was kind of what I ended up doing with fuzzing. It's like I didn't even think fuzzing was the most important thing. That was just what they gave me to do. And I took it as far as I could. Right? And so if you're a manager, like don't give your team of two people 20 things to do. And obviously, like not very hard, but I think that saying that it's like one control, one thing is one person. It's like if you're stretching it, most times you're stretching it too far. If you're giving people two or three things to do, it's like it might seem like static analysis isn't that hard. Like can't you do static analysis and threat modeling? It's like you're going to hurt yourself. Support people, don't complain, make things better. I got a little time here. So like one slide on software sign off. Who's like heard the term software sign off before? Okay. If you guys could like talk to me afterwards, I'd love to hear about it. Because I've heard about it like two times and I don't know very much, but I think it's super cool. So my understanding is it's an extension of engineering sign off. Right? So if somebody builds a bridge and we're talking about software that needs to be secure, somebody builds a bridge and engineer signs off on it. It's like I'm the engineer, I say it makes sense. Or you got contractors working and something looks sketchy, they call an engineer, the engineer signs off and says if you do these things, it's safe. Right? And then if the bridge falls down, people die, people can go back and say who was the engineer? Did they do something wrong? It's like why'd you sign off on it? Can you defend what you did as being safe even though something went wrong? The idea is not to hang people, but you can, it can vindicate people. It's like you document what you did and you show that you did a good job. So this is something that I think would be cool. And I've, it's like I've seen kind of sort of halfway done, but it's like when you have sign off processes and checklists, sometimes they become a rubber stamp. And the key here is like making sure that people take ownership of what they sign off on. Right? And to do that, you need a mature process where people can feel confident in what they're doing. It kind of like hooks into code review. Like my philosophy is if you're, if you approve the code, it's your code, you're responsible for any bugs that happened in it. Right? Kind of like golf style. It's like the guy who signs off is responsible, helps like root cause analysis. That fits in somewhere here, but I don't know where. So that's like all my ideas and what I think the intersection of developing and hacking is. So in conclusion, to change the world as a programmer, do really good at what you do. Work for a company where it can be appreciated. Find something to improve. Other random tidbit, if you're kind of a blue team, develop a background. It's like find a cool security tool that open source and people aren't working on it and is like work on it. It's like you can leverage your skills in that way if you don't want to do the organizational like business-y approach. Be a patient explainer. Really definitely check out Steve Lipner's talk. I highly, highly respect him, especially in this talk. Read threat modeling. And I'll just close saying high quality developers can make a difference. This is what I see as being sort of the crux of the intersection. And there's all sorts of sides to that, like where you can contribute. So hopefully that was helpful for some people. Thank you very much for your time. Thank you.
save the world. Give him a round of introduction hammering through that. It will be real quick This talk is not about SDL itself. It's about how significant until a couple years into the their development practices in the world, way from a software development point of view. And I fit in as sort of the intersection between you're trying to make the software more secure at more, find someone who cares about security. And my ideas. Therefore they don't care about details which is really just a couple stories of is. It's important for security. Come back a Right? And this is why I think processes are cool or how they can be cool. It's like if you don't like work on your presentation, come back. You and I wasn't a developer, not sure what would with the first one that they don't learn about just do awesome at your job. I don't use that explaining. If you have a hard time explaining, and hacking is. So in conclusion, to change the don't want to do the organizational like saying high quality developers can make a