BLUE TEAM VILLAGE - Hacking Your Dev Job to Save the World: Where Programming and Hacking Meet

Video thumbnail (Frame 0) Video thumbnail (Frame 1312) Video thumbnail (Frame 2183) Video thumbnail (Frame 3348) Video thumbnail (Frame 4192) Video thumbnail (Frame 5272) Video thumbnail (Frame 7051) Video thumbnail (Frame 8563) Video thumbnail (Frame 11012) Video thumbnail (Frame 12078) Video thumbnail (Frame 12767) Video thumbnail (Frame 16446) Video thumbnail (Frame 18574) Video thumbnail (Frame 20399) Video thumbnail (Frame 21137)
Video in TIB AV-Portal: BLUE TEAM VILLAGE - Hacking Your Dev Job to Save the World: Where Programming and Hacking Meet

Formal Metadata

BLUE TEAM VILLAGE - Hacking Your Dev Job to Save the World: Where Programming and Hacking Meet
Title of Series
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
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.
Adventure game Type theory Process (computing) Roundness (object) Code Software developer Computer programming Quicksort Hacker (term) Lattice (order)
Authentication Suite (music) Computer font Standard deviation Line (geometry) Software developer Multiplication sign Authentication Video game Line (geometry) Computer font Product (business) Product (business) Mathematics Data management Strategy game Different (Kate Ryan album) Self-organization Förderverein International Co-Operative Studies Information security Information security God
Area Personal digital assistant Software developer Line (geometry) Information security
Mathematics Scaling (geometry) Film editing Building Multiplication sign Control flow Right angle Endliche Modelltheorie Stack (abstract data type) Process modeling Software bug
Mathematics Computer font Software developer Video game Video game Bit Information security Information security
Computer virus Code Connectivity (graph theory) View (database) Multiplication sign Virtual machine Product (business) Software bug Neuroinformatik Strategy game Internetworking Computer programming Data Encryption Standard Endliche Modelltheorie Information security Area Software developer Code Product (business) Component-based software engineering Data management Internetworking Right angle Arithmetic progression Window Computer worm
Axiom of choice Greatest element Code Multiplication sign .NET Framework Neuroinformatik Fluid statics Strategy game Internetworking Different (Kate Ryan album) Endliche Modelltheorie Information security Default (computer science) Service (economics) Email Axiom of choice Mathematical analysis Code Process modeling Wave Self-organization Right angle Iteration Quicksort Information security
Code Software developer Mathematical analysis Lattice (order) Rule of inference Revision control Fluid statics Process (computing) Revision control Fuzzy logic Right angle Endliche Modelltheorie Vulnerability (computing)
Computer virus Standard deviation Code Multiplication sign Software developer Graph (mathematics) Neuroinformatik Antivirus software Type theory Mathematics Process (computing) Term (mathematics) Velocity Average Phase transition Revision control Right angle Cycle (graph theory) Quicksort Information security Window Social class
Web page Surface Standard deviation Server (computing) Injektivität Dependent and independent variables Multiplication sign Mathematical analysis Drop (liquid) Route of administration Machine vision Product (business) Software bug Usability Computer worm Software framework Aerodynamics Endliche Modelltheorie Implementation Fuzzy logic Information security Vulnerability (computing) Server (computing) Sampling (statistics) Code Core dump Computer network Denial-of-service attack Lattice (order) Flow separation Repeating decimal Process modeling Information privacy Category of being Fluid statics Website Formal verification Software testing Right angle Authorization Cycle (graph theory) Information security Table (information) Physical system Reduction of order
Point (geometry) Standard deviation Surface Implementation Dependent and independent variables View (database) Multiplication sign Compiler Mathematical analysis Code Fluid statics Mathematics Different (Kate Ryan album) Software testing Diagram Aerodynamics Endliche Modelltheorie Implementation Fuzzy logic Information security Dependent and independent variables Standard deviation Scaling (geometry) Software developer Surface Chemical equation Mathematical analysis Planning Sound effect Incidence algebra Process (computing) Software Fuzzy logic Formal verification Software testing Right angle Quicksort Resultant
Randomization Group action Presentation of a group Existential quantification Greatest element Code Multiplication sign Direction (geometry) 1 (number) Numbering scheme Disk read-and-write head Software bug Programmer (hardware) Fluid statics Mathematics Sign (mathematics) Strategy game Different (Kate Ryan album) Semiconductor memory Videoconferencing Endliche Modelltheorie Office suite Extension (kinesiology) Information security Physical system Boss Corporation Software developer Feedback Lattice (order) Entire function Hand fan Social engineering (security) Data management Process (computing) Angle Telecommunication Chain Self-organization output Right angle Quicksort Cycle (graph theory) Information security Point (geometry) Web page Slide rule Trail Game controller Sine Existence Pay television Open source Real number Letterpress printing Online help Expert system Checklist Rule of inference Product (business) Twitter Number Time domain Latent heat Goodness of fit Root Causality Bridging (networking) Term (mathematics) Average Software cracking Firmware Metropolitan area network Domain name Authentication Dependent and independent variables Key (cryptography) Projective plane Mathematical analysis Expert system Line (geometry) Software Personal digital assistant Fuzzy logic Game theory Table (information)
so what we have before us is Joshua parada he's going to be talking about hacking your dev job to save the world give them a round of introduction applause short people adjustment here but so have I guess a little background how many of you are sort of developer types in here good bunch okay maybe a half almost okay probably more of you've worked with code if that's not your main thing so this is basically the talk I would have liked to have heard in 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 half way through I won't be offended so quick
outline just gonna talk about the background of why 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 ok quite a few more than raise their hand for developers suite so I won't spend a lot of time I hammering through that 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 I yeah it worked at an ICS manufacture 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 as I got fuzzing adopted and doing this kind of from the bottom rung of the management here I got fuzzing adopted and standardized within this whole organization of over a thousand developers god I think changed the way we did authentication across some of our big product lines really changed our company's security strategy in in in one aspect quick plug for b-sides
Boise if you're in or around Idaho any be size Boise people yeah no okay good deal he knows what's up so how how did I
get there notice eyes develop areas kind of opinion Aidid in detail affixed 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 that helps to have a company that really has an interest in security right right started
hacking and stuff and right so I I got hired to do fuzzing and realize that every time I fixed a bug is like fixing one bug nothing to be ashamed of but as like this isn't gonna scale very well it's not gonna 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 there's boring design time activity it was new for me at the time it's like you don't get any leet zero days or cool CVEs next to your name but right 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 is cool about it right you guys have heard about this before but fair 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 I Adam show stack breaks it down I really like his book it kind of cuts through the craft and he he goes through a lot of like this is the stupid way to do threat modeling that this is the exam tells you about and it's like here's why it's kind of dumb so he 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 lifecycle has anyone seen this particular talk before okay a couple guys back there I think it's super cool really changed how I thought about this this topic so he Steve loopner was at Microsoft for a long time for at least a couple decades I guess coming off on a couple decades if he's still there and and 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 STL itself it's about how he got it to happen at Microsoft so
inspiring and 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 right 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 and so their basic thing was like okay well we'll start patching the bugs that people report right so that's like impact from the days of laughed like no Marcus off 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 and windows that are being written by thousands of developers and so they filed some bugs the devs fixed the bugs and you got a secure product right any anything wrong with that maybe no makes sense ok ok so I hope hopefully you don't buy that so they released XP in 2001 how'd that go for
them well they had Code Red and in DES so kind of as bad as it gets is like all your machines get worms throughout the whole world it was 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 the normal non-technical person was introduced to the fact that your computer just gets hacked right and
that's 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 gonna keep asking who has read the trustworthy computing memo ok 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 hey everybody we need to pile on dotnet 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 faced a choice between adding features and resolving security issues we need to choose security which is like maybe you didn't know Bill Gates ever said something like that right so he did and and that was we know whether or not they followed through just having the president or whatever CEO of your organization's 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 they had some
initial success with those which enabled them to make it into a mandatory process so but they had enough success but 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 STL now mandatory process and it was an easy meeting because the 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 STL 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 I was 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 his way better and and this was one of the commercials on TV was saying hey look at look at PC they're so dumb they have viruses ha right and and really there's some genius some marketing genius serious so they 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 Teknik non-technical people of being the thing that has all the viruses where Mac is way better even if Mac's secure and you may not have been a lot better right and so we're coming around ten 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 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 McAfee so what you had here is kind of a twenty year cycle so you're thinking like Kay they started in 1999 took them maybe ten years to really get on top of the process by 2007 they might be the most secure most secure in terms of their development practices in the world way beyond the average and type 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 your your security practices are sort of the derivative or 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 gonna have to wait ten years for it to kind of pop back up right so that's that's just something to keep in mind from the reputation side it's like you need to hit it ahead time that's basically the history of STL
we'll go through a quick intro we'll kind of buzz through this so standard requirements would there's there's a thing for every phase in the development
cycle this is straight off microsoft's website guys 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's sample bug bar and they have this huge page with this
huge table and and this is an excerpt from the server software table so if you have server software and you have an elevation of privileged 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 cert but but if it's uh if it's authenticated all vision elevation and 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 severity zuv bugs so they talk about it ahead of time I'm really impressed I haven't seen this up close right but yeah it's like you had this framework so there's no uncomfortable meetings everybody knows when we're gonna when we're gonna stop release because of a bug super cool threat 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 so it's like 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 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 in tests where you're doing like two-day engagements all the time but you're not actually gonna do meaningful work so you need to leverage your pen testing either focusing on the things that matter or use your pen testing results and leverage them to affect change so that's the thing that you need to be strategic about and I just bring that up to say it's not all not all about in 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 I
talked about this diagram so I view this is 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 but 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 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 they 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 carries they tell me hey do some fuzzing please and I so okay and then they don't really tell me to like do STL 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 I 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 any communication cool random and accurate 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 may be 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 I become the domain so what I 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 and 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 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 to make people want to do it he's like really people should be wondering why they're not doing it like your average developer should be like hah shouldn't we be fuzzing I think they've been talking to us about that why are we doing it and 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 process is very 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 and then like we found some bugs and I made up some numbers that we saved the 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 a firmware so I was like 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 but just saying like this is what worked for me this is how I found that could have an impact within my organization from the bottom so and 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 like yeah we think so and then it wasn't moving forward and so it was stalled 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 and there was a good idea into few details so maybe because of people's other priorities or people are busy it's like they don't hatch through the details they don't have to do 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 the answer and it's like that doesn't make sense to them without the answer I observed a kind of a false belief that being right just cuz I'm right that means others need to listen to me like no you could be the most correct person in the world and if you're a bad communicator no one's gonna listen to you and they shouldn't because it's gonna be a waste of their time to try right so you must be a good communicator and so there's gonna 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 not too tricky there's a tendency to think I think in security in general and that actually I kind of got this idea from Rob Graham on Twitter I was like he talks about this is 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 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 main 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 just like you become the guy who sits in the corner ranting at everybody and nobody listens to him so no don't want to be that guy and then I have also observed an eye prehension against taking on responsibility feeling like it's somebody else's job or sometimes it is so what ended up happening we're in this meeting and it's like half the room thinks this idea is great hath 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 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 so I practiced getting coming back to internal communication so I practiced with colleagues teammates friends old co-workers like buddies some kind of calling in favors from everyone I know whose opinion I even mildly respect you know salespeople Technical Sales Engineers whatever I'm like come listen to the idea doesn't 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 it 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 you tell them hey there's this idea might change our company's whole direction can you come give us some input like oh we got a cool and people like giving feedback too so I didn't really have to use a lot of social capital is just especially your technical people like to be early adopters so I practiced full-time a couple weeks I presented it to the people I said I was going to present to there like maybe and then they had some questions I hadn't thought of some presented again a little while later and 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 gonna do working out the details the 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 it worked I think that was good because that'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 Def Con talk 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 has the date 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 and 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 short of 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 that was a big process writing the specifications basically saying what it's going to do what's the API is gonna 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 places they're gonna want the details we're gonna have the details ready for them right so if I if I didn't this is I'm just saying like hey how can you be helpful as a developer I was 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 it's like I needed the technical details at that point and then we you know we did it so cool the security feature kind of changed this yeah I would say change the security strategy of our whole companies hundred million dollar business at least one aspect of the security strategy 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 obnoxious and specifically the obnoxious and useless process guy that nobody likes to and every everybody works around and you know 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 it's a good system especially helpful if your organization is big and you can't possibly explain it to people and 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 done that that's another good good trick do bad at your current job this one I would say is important I 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 now you're getting kind of in a risky territory at this point it's like you're in a high danger of becoming useful but 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 it was 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 gonna be on the fast track right so if people don't listen to you it's cuz they're a bad person right and you can you can get mad at them you should get mad at them take ownership of your baby and it might say 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 like right so it's like it's your baby and the the goal here is to have kind of a creepy vibe like maybe you hiss at people or kind of like lash at them and you're 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 a system because then you're not gonna have a job right so so at 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 and just do awesome at your job yeah 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 like why is it always have the right answers and how come he's always thought about everything before we asked him how come 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 is 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 and a lot of things just by working hard because 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 I know you're not a genius you're an 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 print 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 all these 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 you 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's like burned it into the memory keep them short presentations random tidbit from Paul McMillan tweeted one time one new security control is one new employees 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 I 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 um right if your manager like don't give your team of two people 20 things to do it obviously like not very hard but I think that saying is 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 it's like it might seem like static analysis isn't that hard like can't you do static analysis and threat modeling is like you're gonna if you're gonna hurt yourself right support people don't complain make things better and 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 cuz 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 right so if somebody builds a bridge and we're talking about software that needs to be secured somebody builds a bridge an engineer signs off on it it was like I'm the engineer I say it makes sense or you got contractors working and something looks sketchy they call an engineer and the engineer signs off and it 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 any 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 hits sort of halfway done but it's like when you have sign-off processes and checklists sometimes they become a rubber-stamp and and the key here is like making sure that people take ownership of what they sign off on right and 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 and that fits in somewhere here but I don't know where so that's like all my ideas and and what I think the intersection of developing and hacking is so in conclusion to change the world as a programmer I 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 the 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 II approach be a patient explainer really definitely check out Steve loopner's talk I 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 all sorts decides to that like where you can contribute so hopefully that was helpful for some people think thank you very much for your time [Applause]