From Rogue One to Rebel Alliance: Building Developers into Security Champions

to introduce Peter he's going to talk about Row 1 so hope we're all ready for it alright everyone hear me alright thank you I wear all my very code friends oh wow holy mackerel it's a lot of you guys alright friendly audience alright so be warned I finished this this morning this is a brand new talk so out of my cadence might be a little bit off I'm welcome any feedback you can tweet it at me or give it to me in person or what have you so what I'm here to tell is a little bit about myself I've been an abstract for a while so why am I here talking to you guys I think of myself as the Babel Fish

between security and development I am a developer I've been a developer for 25 years I've been at very code since 2006 built a security program a knapsack program into our application development process so I've been doing that for almost 11 years now and so I understand both sides of the world so I get to go out and talk to customers and prospects about their apps tech programs what I've seen work what I haven't seen work I get to tell them about how we've done it at my company oh yeah and I love whisky by the way so if you ever want to talk to me buy me a whisky elf civil around as long as you want

ok so here's what we're going to talk about I want to tell you a little bit about security champions program who had our so here who here is from security who is a developer in the room about quality all right operations all right awesome so security champions program I've seen these a lot now this is really coming up as a hot topic this is actually the third of three different presentations by three different presenters at my company done from a p.m. point of view from a security point of view and from my point of view so we're going to talk about building one what does it take what do you use you know how do you sell

it etc so why do we even need one how many people have an app set program at that company ok how many people have an app's tech program that has more than and one person all right les hands above women five okay so it starts to shrink let's think about what typical InfoSec or seaso type roles are responsible for and this is really part of the problem because not every place that we go to has an abscess team or an abscess program right so that the security team is responsible for physical security their endpoint security they're responsible for D our intrusion detection and prevention all this stuff right this all looks familiar to you guys and if you do have an AB set

program so if you're an InfoSec guy app sack is like this tiny little part of your job you have so many other responsibilities so many other things for you to worry about that if you do have an AB set guy and you do have an AB set program again you're being pulled in multiple places because let's see from a development point of view Waterfall who's doing waterfall at their current place don't be shy it's ok I know there's at least a couple in here all right they don't want to show themselves about agile about DevOps ok all right some of the same hands so if you think about a large company right I've got dozens I might have hundreds of

teams that I'm responsible for thousands of applications some of the abstract programs that I've seen have five or 10,000 applications that need to be secured to me how the hell do you do that with any size team you need to do risk assessment you're doing maybe who does manual pen testing in their company ok who does only manual pen testing in their company again people don't what if she I don't want to show you need to do external Atta stations if you're a vendor and you're reporting across across the organization so you have all this stuff to support as part of your app sect program so why don't we just hire more people like the giggle thank

you yeah for every four people that are employed there's three job openings is not enough of us out there to go do a credible job at securing this this landscape and as we've heard every company is a software company every single one and we've been saying that where I work for over ten years right FedEx is a software company that delivers packages Amazon is a software company that sells everything on the planet right secure software runs every single business you cannot get as fast or as scaled as you want without software well while we just read team and pen test the applications of death now there's a anyone know Shannon lights she works for him to it she runs their

red team program remarkable she's very very talented very smart she talks about her red team and you know how many people she has on board I think she's got like a team of like 15 people like super skilled and who has the money for that right so we think about Reggie who has a red team program at their company won right it's it's rare it's rare to be able to have white hats inside of your organization that are trying to break in it is so expensive to do and we only want to really do it so for the rest of us that have to rely on third parties to come in and help us with pen testing we

only want to do it on the most critical things write it in by the way it's too late in the process so if you think about a typical AB sec program in SDLC right from the time that i think about it at a time that it's in production if they're sitting there at the gate waiting to release their software that's the wrong time we tell them they got three hundred things to go and fix right it just leads to friction they get aggravated at you they don't want to talk about security they try to avoid talking to you so we need to find a better way of doing that it's also too slow so even if you have internal pen

testers we're talking days or or weeks to get a pen test done and a lot of that time is idle time so who here has studied lean manufacturing Toyota Way kind of stuff couple all right so it's on the reading list of things that you might want to go and look at it's tight it talks about reducing or eliminating waste in the cycle of how you build things and it could be physical things it could be software again it's how long does it sit waiting for the pen tester to come and then they do their work right so that that part is wasteful if we use an external one it could be months for you to line them up

for them to have a coverage call to figure out you know what's the scope of the pen test how do we do it and if you also if you think about it of all the things that they could test it can only test this little tiny amount out of everything a couple of percent maybe unless you're you know you've got a huge team in lots of time it's also not cost-effective for simple vulnerabilities so in the last talk who's talking about some free stuff that will go out and find things doing static analysis will find a lot of those vulnerabilities really early when they're really cheap to fix before the code is actually running you can use

dynamic analysis in the same way you're finding things before you release again it's more cost effective than what you want to use a human for so we do have room for pen testers in this world right we absolutely need them someone to sit in front of a screen and infer what the system is doing behind the scenes right that computers can't do so you need to sit there walk through these workflows say ah I see what just happened there let me see if this is actually doing what I think it is and do some more probing testing again you can't find hire them can't afford them they're super expensive alright so who has a security gate before they really

software in their company ok I saw some of this right so that's the well kinda so which outcome do you see when these guys come to you is it this one ok we how many times have you seen that or it's the you put the gate down and then they cry to their manager who cries to the VP who eventually goes to the CIO and then you get the phone call over the security team say why are you guys standing in the way I need my software released get it out there you have to do this where is this one it's hard gate and they try to go through it they try to go under it usually it ends up like this if

you have a sturdy gate that you can enforce this is the behavior you're going to see right we hope all right so now let's talk about development methodology so people said no one's doing waterfall I don't believe it but okay or they're doing agile fall or something like that so let's talk about calendar time right so if we're talking about waterfall type methodologies I may be doing one to four releases here that's about the best you can do and these are huge teams by the way they release big chunks of software with lots of risk in it right but these you know 100 person teams go really slow usually miss deadlines agile so we're going to start speeding up now right so

we go from a team of like 100 to maybe a team of six to twelve and we're talking about maybe we do it monthly maybe we do it a couple times a month or if we go to DevOps now we're we're cooking right now we're talking about hundreds of releases a year sometimes tens of releases a day so how does the security guy keep up with all that stuff right so if you think back to I only got a couple of them and I've got hundreds of teams and thousands of applications and they're all releasing multiple times a day what's a security guy to do how do you fix that problem so here is the the kind

of DevOps lifecycle so for if you haven't seen this before in a DevOps team the the theory is that the team owns it from cradle to grave so from the time you think about doing a project until the time you retire it and turn it off in production the team owns the whole thing right so where's security in this usually again when you start off with waterfall or agile usually it's there right testing that's when we do our testing we test at the end but really this is what we need to think about and it's the same thing we've learned with agile right so in agile methodologies we combine QA and development to say hey let's think about

quality the whole way let's make sure that when it when we say we're done and me it works okay who is familiar with this couple all right so this is classic chart talks about agile methodology so in a nutshell we start over here on the left with our backlog right this is backlog is put together by someone called a product owner so this is a role on a scrum team in agile this list a list of things is ordered usually by importance usually by amount of money we can make off the feature in again if we look at the waterfall projects we're looking out trying to figure out what people will buy in a year and we're usually wrong what we're

doing here is we're saying hey I know the next couple of weeks or the next quarter what things I need to prepare and get out to the field so that list is smaller more concise and easily seen and viewed and understood so we take that list and we go to our team and we have what's called a grooming session where we talk about these what are called stories so everyone in this is a story so as something I want to do something with this product and it will do great things for me right so this kind of way those things are written we take those stories we go into the team so if this is my agile team over here we're sitting

talking about the story once everyone's agreed that they understand it now we test for understanding so we do something called planning poker in planning poker you actually have a deck of cards they have some virtual ones you use on your phone but the team sits in the room and they say all right based on some standards so let's say that you know this is a 1 again it's just a rant it's a it's a number that's meant to be relative to something else so if this is how big a one is right so this would be a 2 we say all right on the count of 3 you tell me how big this story is and it

goes 1 2 I can't remember now 5 7 its Fibonacci ish 1320 infinity and so we'll pull out cards on three and everyone will show them to everybody else and I'll get a 1 here I'll get a 13 up there I'll get a 5 over here of like well clearly we do not understand what we're doing yet because the whole goal is we need to really understand it because we're real going to commit to doing it so now we'll go through some negotiation we'll ask the guy that said of one it's like why do you think it's so easy that guy said it's a thirteen why do you think it's so hard the guy in the middle what what are

you seeing until we come to some kind of reasonable consensus where maybe we say it's a five or seven s like ha I understand your point I forgot about that it's usually things that aren't written down inside of that story what we call acceptance criteria or story descriptions so now once we've done that we're going to say all right so for this side team we usually do about this many stories so we're going to pull those off the backlog and we're and say this is what we're committing to as a team this is what's different than what you do inside a waterfall in waterfall everyone get their own set of work and we move along and we hope we get to the at the

end and we get something out of it in agile what we do is we say alright we're going to commit to this as a team and once we do that we're going to stand up every single day it's called a stand up whole team gets together and we say well what did i do yesterday what am i doing today what's blocking me it is run by I'm going to call a scrum master again another role inside of a scrum team now this scrum master will say all right well you said you're blocked and you said you finished early so why don't we have you come and help the whole point is as a team we're going to succeed or

fail right we're going to track it visually electronically usually and at the end we're going to reflect on it what do we do well what didn't we do well now usually Security's here right they're looking from afar hoping the things are going well and get to those gates and you know bad stuff happens and what ends up happening is we fight for budget so when they come to us with something that they want to release the Haake ready to ship this water now it's like well you know I found these 10 things it seems like well I want to release tomorrow can we just fix the most important ones who's had that conversation everybody well what if we

just fix the top - is that good enough so you're fighting for budget with those teams and that's not really the role that you want to play that's not really where you want to be so let's look quickly at how DevOps evolved so here's the typical waterfall where we've got these silos of people right so I got my people that tell me what I'm to do the people that do it people have tested and they're the people that run it we have these handoffs so what happens is from the left one we sit right down what we want to do as soon as it clears that wall to the next team we start to lose the focus on what the hell

that was supposed to do so by the time it gets into operations they don't know why we built it they don't know what it's really supposed to do they just know how it works the same thing with the application it works as it's written but not necessarily the way it was intended so they don't have that knowledge they don't understand that and in the opposite sense from our operations team they understand how it works they're the ones fighting the fires every day but that information never really makes it all the way to the team so in an agile what we did was we said let's start breaking down some walls let's put quality together with the

people that write what we're supposed to do and the people that actually do it so now my developers are starting to think more about qualities where you know test-driven development started to come into play let's think about testing from the time that we start to work so what you see now is there's much better continuity from a business idea approach and from how the application works on that team but we still have this reverse problem in operations in DevOps and we'll drop security in here somewhere but this is the typical model right if everyone's on the same team the operations of guys are there when the p.m. or the product owner says hey here's what we want to build here's the

audience that's meant for here's how it's supposed to work they can report back to the team and say hey it's not working the way we intended you guys need to do some changes around this thing and we really have a very good understanding across the board and we end up writing better software all right so we realize we need some more people again moving it earlier is always better we call a shifting left there's a lot of companies out there talking about shifting left which means going to the place where the code starts to get written that's the time or even before that is when we need to get involved so as we sell this program the intent of

this is we're going to have 1 or 2 people on every single team write at least one we like some redundancy so maybe two people if you can afford to that when we talk to manager we need to say hey look we're going to fit into your existing process we're not going to slow you down we want to make sure that you think about security from day one such that we don't end up with this nightmare at the end these kyouno trucks crashing into gates or driving around the driving around the gate so we need to think about this is there's an investment up front right this is not free lunch but eventually what you want

is this preventative measure so if you think about security right the best defect is one that was never written I want to train my developers in such a way that it comes out of their fingers secure so I'm not doing the application security at the end and having to track these defects and fight for budget on the team there's less waiting so we want everything on the team in agile and DevOps what you want is everyone that's responsible and needed to do a project to be there right to be part of this team so we don't have these handoff like we talked about with pen testing and from an individual perspective if you are one of the security champions you're

going to get additional training you become more valuable not only to the company of the ers but the next company you go to right we I was talking to some of my workmates before about that transition from security champion into more of a security role it's kind of the bridge between development and security so this is a good place to start in a place where it might scratch an itch you didn't even know you had so we got to describe the job to them so the job is really about grooming so remember we talked in that agile slide about this backlog in the grooming session so now not only are we going to talk about

stories from the perspective of how is it supposed to work but what are the threats how can this be attacked what kind of security testing do I need to do on this and in some cases static analysis is perfectly fine we'll take that cheap route maybe we want to do dynamic analysis maybe we need pen testing on this maybe this is some kind of critical control this is the place we want to analyze and understand that because in agile what you want is in DevOps as well when you say done really done like I put it down I don't have to pick it up again pencils down test is over kind of thing right so how

do we get them to understand all of the things that they need to do to make sure that it's really done Billo materials so open source risk they need to understand the components that they're bringing into their applications because when we have something like strut shock or shell shock or heartbleed or you know the DC realization problem in Apache Commons you need someone to go to if I have thousands of applications and they announce patchy Commons is now screwed where where is it in your enterprise which teams do I need to go talk to how are we going to fix it on what time frame do I need to put mitigations in place until then that's the thing where

your security champions become part of your incident response and say guys help me out here here's the problem here's what it looks like here's how it can be affected go get me a report back on where you are what you're doing about it and how soon you can have it fixed right so this is right response team here secure code review so we're going to teach them some basics right they're not the be-all end-all they are not security experts but we're going to build some knowledge into them so they can do a lot of the basic stuff that we need to have done on a regular basis in the other conscience of security so they're the

ones that sit in the room and think about it you can't be at every meeting you can't be in every discussion but these guys again we're talking a team of six to twelve people they usually sit near each other usually talking all the time when things go by like up security over here we need to think about this right you need someone to be that eyes and ears for you so recruiting so you recruit these people again we're going to use one to two members volunteers our best but voluntold is okay I don't love I don't love that model but we want to get them to the point where they're like wow I really want to do this because you

want people that that are excited by this challenge a problem that we had initially when we when we did this was we took the people that volunteered but that's not necessarily the people you want we need people that are influential on that team so usually it's your young go-getter that maybe join the company a couple weeks ago or a couple months ago or maybe a couple years ago but it's not really a senior member or an influencer or on that team you need to think about whether or not when they say security everyone looks and says what do you mean security instead of a security and they look elsewhere right so you need the right kind of people so

think about that model and again it doesn't have to be a developer it could be a QA person so let's talk about what you don't want on your team so I guess before a new employee I don't want someone just coming into the company doesn't really understand the product doesn't understand this getting up to speed on so many other things and now we're going to fill them with more training it's going to the message is going to be diluted so we don't want someone that's doing that we don't want an existing scrum roll so the product owner has a job already the scrum master has a job already and they might actually be coding on the team as well

we can't burden them with this other thing and in fact we'd like that division of labor I mean security loves that stuff right let's talk about splitting this labor up I want my product owner the person that's writing the stories to be the one that's trying to put security into it as well let's look at it from a different angle training got to train them at at very code there's a two day or two and a half day intensive in-person training what we talk to them about a whole bunch of important stuff all right so we talked about security fundamentals things that they don't think about they were never trained on for the software developers

in the room who took a security course security coding course in college two three okay yeah most of us are not trained in this I did this I graduated twenty five years ago they didn't have any application security or secure coding type constructs it's starting to come about now but it's still this is a workforce that you have to invest in right they don't have this stuff already so we talked to him about CI a we've talked about you know zero trust we trust nothing you have to verify it deny by default defensive depth we do catch the flag II exercises too so every once a week on I think Tuesdays at lunch our security

expert will go into the cafeteria with his laptop they'll have something ready for the team and they'll say hey let's talk about this from the hacker point of view get them to understand the other side to make sure that they understand what they're trying to protect against and how easy it is sometimes to break into these things so a little bit about grooming guidelines again when we talk about grooming in the typical sense and agile we're talking about understanding what functionality is to be provided and this is non-functional requirements we want to talk about how we're going to protect this thing from malicious use so is this and this is a checklist that you can

provide this is just a sample is this a new feature that you're introducing does it have new API endpoints that we want to think about testing their new UI elements that we need to think about how they might be maliciously used new architectures especially who's doing like monolithic application development like being clunking java things yeah who's doing micro-services all right so you need to understand how about containerization there's a big one right so you need to think about those deployment models those architectural models from the security standpoint to say am I just shipping software faster with more security vulnerabilities in it how do I think about that architecture and how it needs to be secured how do I

think about containerization and what containers I start with and what goes into them before they get into production am i introducing new security controls into the application you know is it new permissions new roles new rights new encoders that I want to take a close look at because the last thing you want is to just kind of do those things like oh yeah we understand the security stuff those are points where we want to bring in a security expert to validate that we did it the right way new forms or actions is it a fix for a pen test finding again it's a place where you want to have an expert come in and say yeah you did it right is it

happening in authentication or authorization is it affecting my crypto or my data validation you know all of these things that we worry about it's security professionals we need to enforce and helped those security champions understand that all this stuff is important you know what do you think about cash management how does that get flushed what you know what's the refresh rate on that who gets access to that all these things we have to give them a checklist if it looks like any of this stuff it's a duck I need to talk to you about it all right so before I said where I'd train them to do security code reviews now this isn't like I said this isn't

deep deep deep analysis we're going to give them some of the fundamentals and by the way we're going to guide them through this process we'll start small will validate that they're doing the right things and add more as they go we have some people that have been doing this for years that are excellent at it and some people that are newer to it that are struggling so you need to understand that balance of who you should be spending time with so we'll teach them how to do basic data valid look at data validation or encoding or parameterization logging and error handling we want to do a lot of mentoring with them so some classroom training we're going to give them like a

code review test here's something I want you to go look at tell me what you find then we're going to do some one-on-one meetings with them talk to about the process of a secure code review it's different than a peer code review that you're just looking at the code for you know four simple errors we want to make sure that they understand how to go about this and give them strategies for doing this because they've never had to think of it from this angle usually we'll have them shoulder surf us so we'll do the code review they'll see what the methods that we use then we'll ask we'll do the same thing so that's why Yoda's on the back right he's now

he's shoulder surfing understanding what Luke is doing in his secure code review to make sure that he understands the right way to do things so we're going to give them a little bit of power we want to make sure that they're not going rogue on us and you know going to the dark side they're not all-powerful we need to make sure that they understand you're there to do the basic stuff and the more I trust you the more authority I'm going to give to you but understand that there are places where you're going to have to say above my paygrade outside of my knowledge base please he's come help me that is not a bad

thing want to make sure we give them that opportunity to do that so a good goal for year one is to take over that security grooming we provide on that checklist it's going to be different based on every team there's some basic stuff in that it's going to look the same we're going to want to do slow deliberate mentoring with them we're going to kind of transfer it to them gradually and if you're really starting out a program for the first time this is where it's going to be painful for you is giving them that that one-on-one time we need them to know that there's again in the toyota way they call the engine cord right something broke I don't

understand it I'm going to stop stop what's going on and have someone come in they need to know that they need to call us when it gets past what they're used to past their comfort zone because the costs of not doing that are huge for the company and we're giving lots of training that classroom time is the beginning of it we have e-learning that we put them through and we want to make sure that they're doing it so we're going to monitor that over time we're going to measure them we're going to measure individuals and teams so from the security champions portion we're going to look at their code review skills we're going to try to certify

them so we've created some certification programs to say hey you're good at these particular areas here's the parts where you want to improve if you don't measure it you're not going to improve it so let's make sure that we're looking at how good they are at what they're doing so you need to do spot checks with that especially on the people that have been doing it a while it might get a little lazy about it so goals for the team so we looked at open Sam and B sim as possible models for doing maturity models for our application teams it didn't really suit our needs it didn't drive the behaviors that we wanted so we

kind of created our own custom one and I've created lots of different security maturity models for different companies to drive certain behaviors so we create our own and we've asked the teams to go off and grade yourself tell me where you are and your maturity curve and let's talk about goals for getting better so we'd love everyone to be up at a maturity level five but we know we don't start there and that's okay one of the things that you know I'm a soccer coach for a very long time I always tell my kids the first day when they just meet me is like look you don't have to be bad to get better when I'm

giving you instruction when I'm correcting things it's not because I think you're terrible is because I think you have you have skills and possibilities and I want to help you get to those so we're going to baseline we're going to update that I think that like every quarter is probably a good cadence for that to understand are your team's getting better or not this is kind of where you become responsible for this so if you think about application security there's the preventive stuff that we do which happens before check-in right so am I using the right tools am i following the right process do I have the right controls in place do I understand the the things that I'm

supposed to have before I'm done so again we want to try to secure before that that's my preventive and then everything that happens after that so if I do static analysis and dynamic analysis and pen testing those are all assurance those help me sleep at night to know that my teams are doing the right thing right make sure you understand what you're expecting out of your teams and you're getting that give them solid measures clear goals and and help them along that path we need to reward them to training opportunities it might be they come give a talkative b-sides or they go attend to b-sides or some security InfoSec conference or what have you that's kind of their reward for

doing the security stuff as they get new training get exposed to new ideas teach them the hack so we talked about doing those capture-the-flag activities this really were engineer stuck light up right I'm a problem solver I love to solve problems I love to understand things when I see something happen that I don't get I want to delve deeper into it so by having these kind of activities for them to do we're kind of stimulating their brains swag is always good I was at a healthcare customer this past week that gave out water bottles with their their logo their application security logo on it again swag is engineers love free stuff they love free pizza they

love free clothing hats water bottles we you know whatever so it's also back on you guys so as we think about building out these security champion teams this can't we can't be like deaf to the things that they're challenged with right these teams face real challenges that we are not helping with today so we've got to learn about their world so reading who's read the Phoenix project excellent good anyone that hasn't it should be on your reading list it's really short read it's a you know it's a kind of funny little story it's a quick read for you it will help you understand this DevOps problem this DevOps solution the DevOps handbook is the next

one and there's actually for real some security stuff in there I don't agree with it all I don't think it goes far enough but you know it's in the right direction go to your scrum teams attend some ceremonies so there are things in scrum called you're either a chicken or a pig all right so the chickens don't talk you come into the ceremony you could just watch what's going on I encourage you to do that go into those ceremonies and just stand there and watch what goes on watch the things that they live with every day they're different that the things that you live with and the more that you're compassionate about the problems that they face the more of an

ally you're seen as learn their tools maybe you should be in you know github who does security and does coding at the same time so understanding those tool chains understanding CI type servers and Jenkins and and bug tracking systems and all those things and all those integrations play out using their ID ease rote unless all right so I found my first error on my own right security stories help your team by actually living that life so a lot of the security guys at our company actually are certified product owners what makes a good story for an agile team and by the way I keep mixing going back and forth between agile and DevOps usually DevOps is run on an agile methodology

because we think differently about what the cadence of release is between those two but the methodology is usually an agile one so write some security stories code try to do this stuff see how hard it is because it's not easy your job isn't easy for the developer and if you try to do theirs you'll find the same thing all right so you don't have to customize this this isn't like a one-size-fits-all program where you can say hey this is the way we're going to do it this is what I saw on the slide deck you have to think about your own culture a lot of times when I go in and talk about AB SEC programs you know one

of the biggest gaps is usually mandate right so the reason they get to drive around the gate that we saw before is because there isn't a strong mandate from the development side of Alex you don't have backing from the VP's the CIO it's one of the critical things to giving a successful app SEC programs that have the developers actually be measured on this so getting these things in their goals and have it affect their salary is a key to getting them to do the right make the right behavior modifications again empathy their job is hard to they face different challenges you should be in those teams looking at them trying to live that life trying to

understand it a little bit better over communicate so this reporting that we talked about of you know where we are from maturity model standpoint how good your teams are how good your security champions are you want to make sure that you're you're constantly communicating about security in a way that is friendly to those development teams and this is a critical one be extremely responsive it's going to a lot of your time to build this program and they don't want to feel like you let them on the islands like okay are in charge of security see you later I got other stuff to do eventually you get to move from the tactical of the strategic but you need

to start with the tactical you need to train these people up you need to have some level of trust in them such that you can let them go and say all right you are now responsible for this much anything over this please call me and when they call you got to pick up the phone you have to be there for them stay engaged with this program right those capture the flag exercises it may seem like Drudge work to you yes I've already done this one or I built this one years ago but it's new to these guys be incredibly engaged with them go out to lunch with them take them on little team trips sometimes that team-building so in

in some companies they call them guilds so usually an agile team wants to have all the people that need to do everything so I'll get development and security and quality and operations and stuff but those teams then cross pollinate other teams so the the guy that loves security will get together with the other ones like birds of a feather type engagements it will build these guilds build that teamwork so they're working with each other maybe mentoring each other alright anybody have any questions I do for time shorter than I thought yes more towards okay right so most of the time it's above your pay grade as was pointed out right all of this stuff is is risk

versus reward right so these end of the quarter things are into the year type things yeah I've seen a lot of those you need to make that strong case if you have better information so if we know that Apache Commons is or let's take the struts vulnerability which was under active attack the second it was launched if we start showing them the landscape and the in the surface area that's being attacked and helped them understand exactly what could happen put a little bit of the fear of God into them they're going to think differently about saying no no we got to have stability here like no we're kind of get breached if we don't fix this stuff you need to build

that case and understand that you're not always going to win right so you need to come there with your security champions behind you that are more Pat that are passionate about like you are so if you you build that army of people they're going to be in that room saying no really I need to fix this and we need to fix it now so it's about building up and having enough data it's like well I think we're vulnerable though I know we're vulnerable in across our landscape 50% of our applications are in risk of breach right now what else yes sir

right so what so what I was pointing out is is what I see in most organizations there are organizations that do it well that understand how to bake that into stories that might not be a place where we need a security champions program it's the people it's like one InfoSec guy that has a little tiny bit of stuff that they're supposed to do around AB SEC with everything else they're supposed to do that needs to go out and build this this this army to go help them get this job done because they can't attend in the case of hundreds of teams all of the grooming ceremonies and make sure that security is there it is

and that's where we want it we want it baked in there what I've shown you is the reality of what I see at most companies anyway else all right