 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 applause. Short people 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 life cycle? Okay. Quite a few. More than raise their hand for developers. Sweet. So I won't spend a lot of time hammering through that. We'll 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. I worked at an ICS manufacturer. Big business for a small town. Not a noticeable business by big city standards. Developer background as interested 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. 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 a 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. That helps to have a company that really has an interest in security. I started hacking and stuff. 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 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. If all we're doing is fixing what we find. So then I learned about threat modeling which I'm guessing most people have heard about before. 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. 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. 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 CISB 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 for 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. So 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, 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. So hopefully you don't buy that. So they released XP in 2001. How'd that go for them? Well, they had Code Red and Ninda. 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. 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 just like, maybe you didn't know Bill Gates ever said something like that, right? So he did. And that was 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 they had enough success that they had a meeting with all the executives, right? And it's like a 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. 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. So 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 the 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-fee. So what you had here is kind of a 20 year cycle, so you're thinking like, hey, 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, 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 the 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. Threat modeling we talked about. Attack surface analysis is basically threat 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. So it'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 pen testing is 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 where 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 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 will 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 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 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 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 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 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 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, hey 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. Pushed it within my own team. So there's a 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. 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. 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 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. 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, 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 and 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, we saved a lot of money, justified my existence and 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, but 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 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 solid 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, it's like they don't hash through the details. They don't hash through the details and so they don't have answers to questions. What happens is if you can't answer the questions, you look wrong, right? And then if people come back three months later, you still can't answer the questions, you look really wrong, right? 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, right? So if you don't get into those details, you don't have it's like you've 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 to answer. And it's like that 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 and 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 to crime, it's like work on your presentation, come back, you know. It's not too tricky. There's a tendency to think I think in security in general and that actually I actually kind of got this idea from Rob Graham on Twitter, he talks about this, sometimes security people are like if you don't do what we say, you are wrong morally. 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. Well, no. Maybe they don't understand, right? Maybe their priorities are different than yours. Maybe it's not a good thing. 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 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've got this like impasse and someone says hey, we need someone to make a proposal and hash out all the details for us so we can analyze this. So I raised my hand and said our team can do that. We can do that. And they said great Joshua, you will do that. And I said great, I'll 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, sales people, technical sales engineers, whatever. I'm like, come listen to the idea, does it make sense from what you know? It's like do you it? Do you think it's a good idea? Doesn't 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. Especially technical people like to be early adopters. And so I practiced full time, a couple of weeks, presented it to the people I said I was going to present to. They're like, okay, maybe that's it. 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 proposal, moved out 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 becomes a different game. And then another plug is this DEF CON talk. So around the same time I'm doing this stuff I hear this talk last year from the social engineering 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. I 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 agree to do it. Everybody's happy and 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. 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. And I wasn't a developer. I'm not sure what would have happened. So we wrote the specs before anyone 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. So if I didn't have, I'm just saying, 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 that. It may not have happened because there wasn't anyone else to do it at the time. It's 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 hundred million-dollar business at least one aspect of the security strategy. So that's like my stories about making it happen, stories about 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. Um, obnoxious and specifically the obnoxious and useless process guy that nobody likes to and everybody works around, you know, you know that guy. Um, uh, 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. Don't do it, right? So it's 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. Um, top down don't ever talk to the devs they are not worth talking to. Uh, go to your boss with grandiose schemes that you don't really understand. Uh, be pushy. Remember, you are the genius. It's all about you. If your boss doesn't listen to you, it's cause he's dumb. If you're doing 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. But 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 into risky territory at this time. If you keep on telling people they're wrong, you can still do it. So I'm 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. Oops. Turn every piece of advice you're going to be on the fast track, right? So if people don't listen to you, it's because they're a bad person, right? 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 people, 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 that's dumb because then you're not going to have a job, right? So so if but if you don't want to be that kind of guy, I do have a 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. And 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 does it always how can he's always learning more stuff and 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, you're at an 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 that. 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've 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 give, 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, it's like leverage those, present multiple times if you really want people to do something, it's like burn it into the memory, 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. 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. If you're a manager, don't give your team of two people 20 things to do, obviously. Like not very hard, but I think that saying 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 gonna 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 has like heard the term software sign off before? Okay, if you guys could 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 up, 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 on your computer or you got contractors working and something looks sketchy, they call an engineer and the engineer signs off and says if you do these things it's safe, right? And then if the bridge falls down people can go back and say who was the engineer? Did they do something wrong? It's like why did 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 it can vindicate people. What I think would be cool and I've seen 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 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 hooks into code review. My philosophy is if you're approved the code 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 developer background. It's like find a cool security tool that open source and people aren't working on it and it's 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 approach. Be a patient explainer. Really definitely check out Steve Lipner's talk. I highly highly respect him especially in this talk. Read threat 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.