#securityselfie (size up your appsec program with new metrics)

we have GM O'Leary from Facebook to give us a talk about security selfie or hashtag security selfie I need to say that part don't I thank you for your consideration very nice good you can hear me I can hear myself so you can probably hear me too perfect so thanks coming out welcome back welcome back to the lunch my name is Jim I work at Facebook and I'm here to essentially maybe start some conversation around measuring the beautiful crash that is software security engineering I've been finding bugs and code for a long time and then I've started fixing bugs and code and now more about preventing bugs and codes remember making it into the code base in the first place so if you

kind of bear with me for 30 minutes or so I'll show you some existing work without their right like this isn't a new field for sure like you've been measuring things for a long time people been securing things for a long time I'm hopefully going to give you a little bit of like a newer twist on it and it's like I said you bury me for 30 minutes i'll give you this one hot tricks for securing your code base that you may not realize is super effective and also really easy and every taco bennett so far today people have been like raising their hands to get started so i'd like to do the same thing raise your hand if

you know a kpi Stanfill and shout it out if you're feeling super feisty all right key performance indicator I'll tell you in full disclosure I give this talk at apps at California it was kind of disappointed by the following question here but pki raise hands again ah my people yeah so public key infrastructure one of the core fundamental building blocks of modern security systems to be honestly I gave this talk before and as a cape a KPI like a whole bunch of hands-on up the pki and like nobody said anything and I was like this is perhaps the wrong audience to my talk ok are how about this one all right one more time really soliciting me the input from my

audience here how about this dude right here ok are alright and so with all this kind of like management gobbledygook at some point beyond all this you're going to want to have your code or your code base new systems telling you like how they're doing like it's the work that you're doing producing any meaningful output or are you just doing all this exercise because like you can do it so to bring it through some numbers right like in the world of security this is sort of what we're after all the time right like zero the absence of value you know did anything terrible happened today how many bugs are in the code how many employees are fish tell me my laptop's

got compromised eventually like it all comes down and like you sort of want nothing to happen and then you've won so my homeboy Alexei's over clever doing security putting up those nice template for you all to use this is all my contributions back to you the audience but you know if you're writing security ok I will protect from every possible thing that could ever go wrong and if this all goes well I'll have nothing to show for it and things will fail by virtue of this number right so it's the other side of the binary bits lip one it just takes one person to find one thing to like undo all of the hard work that

you've done leading up to this point and securing your code bases so it's kind of a phenomenon of attack or a symmetry you know you get one of the other speakers here finding all these like sweet Oh days and stuff they need to find one and then you lose so to move beyond this like binary nature of security work there's got to be more than a simple pass/fail grade at the end of the day and I'll bucket what I consider like security engineering work into three main buckets and why some are more enjoyable than others so reactive is what I find could be the most exhausting work this is where something has shipped a production you've become aware of it

and you need to scramble to patch it because we see there publicly known or is actively being exploited proactive is when you've done enough firefighting you stop and you say it would be really great if we found these things ourselves before they started getting exploited in the wild so this is where you might go and engage like a third party pen tester or start doing security reviews of things yourself before they ship and lastly like just mitigating work right and so this is the class of work where you're going to realize that you're still going to have issues in your production code base it's a by product of software development but you do some work to make all these issues less bad

when they actually happen so I mentioned these like vulnerabilities you could go do something like if you're in a services oriented architecture do some jailing or you know firewalling segmentation kind of stuff so that it's something breaks somewhere it doesn't explode and everything falls apart around it I submitted this abstract before I had really done a lot of the work and so it got accepted and I was like I should probably start reading about security metrics as a result so this was my nightstand for a little while and one piece of feedback I heard from this talk when I gave it internally it facebook in a couple other places it the abstract makes it seem as if I'm

going to be like here is all of the KPIs you can just copy paste into your application security program and you'll be fine to run and that's not how I'm pitching this thing at all actually if you're interested in that this book with the frog on it is actually really good at like giving you a whole bunch of template KPIs and all these kind of things just look on the left with the big hand on it and the beginners guide is really good at giving you a broader perspective on like what security metrics means I work on the product security team so I'm really focused on the security of code this is stuff like a traditional a lot top 10 or you know

knocking out the buffer overflows and all this kind of stuff so I'm more focused on apps tech and what I'm about to unveil a little bit later on is more of an asset focus but the size through these really quickly kind of three existing systems that are out there that you might be familiar with microsoft has a history of producing software not the most secure software for a little while there but as the result they put together the secure development lifecycle and then releasing it to everybody as well so if you can learn anything from Microsoft of the early 2000 to something like how to take a software package from the very beginning go through development testing

release all these sort of things and hit milestones along the way right so it's kind of like you threat model and then you run some static analysis and then you do some like manual testing and then you release it to production so check that out if you've not done so already and kind of like take the best parts of that and apply it to your security program the besom is the building security and maturity model and this is a collection of stuff that other people are doing to secure their pho basis and so don't treat this as a checklist either kind of go check it out it's like a 70 page PDF when you download it so

you know pour yourself a nice brandy put your smoking jacket on and enjoy Saturday evening with the peace name or something like that but take it pull out all the good parts and then use that to build out your security program as well and then there's Google Chrome health notions that Teresa from google gave a talk about a little while ago about the parallels between the human health system like you know you go to a doctor they check you out on these different axes and then similar like the mapping to the google chrome security space right so it can be stuff like how long it takes you to patch it critical vulnerability gets reported like that's

just a metric that by itself doesn't really mean too much but it's a good kind of like parallel for how you're doing overall so check these these three things out the other issue with these though is that they're like a giant not necessarily checklist but they're a big list or a collection of things that you need to do and there's no good sense of priority like should I be threat modeling or should I be investing more in like moving everything to a more secure stack or should I be spending all my money on static analysis or should I be hiring the world's as awesome as hackers should I start a bug bounty what should I do and so there's no kind of

like collective measurements for how you're doing all this work and if it's actually moving the needle as they say in any positive or negative direction so I need some campaign promises in my abstract that I will be loosely upholding right so the first of which is that well we see here I'm inspired by a modern marvel of our time I call this a selfie this is the photograph taken by a person who is also in the photograph and I like this because I want to use data that you might not realize you already have so the nice thing about this thing about the pitch to everybody is it is like no work involved at all and you end

up with a thing that tells you how secure you are that's because if you're doing any software development or engineering like you've got bugs and you're measuring the bug somehow you're tracking them all and you can take what you've got in your overall like engineering process and then map that to how you're doing on the security side of things and so one of my first maybe scientific principles here is a spectrum of badness and it kind of starts like in the early development lifecycle right like you got an engineer who sits down and he or she are about to go commit the worst security mistake of all time and it's catch you at the very beginning you

can catch it after that and code review if you know you've got another engineers is that this doesn't look like a great idea or maybe you catch it in testing your production but overall there's a sort of traditional good to bad trend in which like you want to catch issues earlier up the stack I've seen it commonly discusses things kind of end on the badness scale at the bug bounty report kind of stage but it actually gets like much worse than that some at Facebook now is Twitter in the early days of the Microsoft before that so I've seen a lot of stuff in production over my career and there's also these additional things I'd like to add where

you get like it responsibly disclose external finding so this is something that doesn't work at your company but they found a security bug me tell you about it you don't have a bug bounty in place and so there's not really any incentive for other people to tell you about the same thing if they find it that could lead to the following two things which is like you know you check your Twitter fees or you turn on the TV and it's like Oh your company is being hacked right now the nice thing about that is that you know about it and so you can go do something about it which would be because this last bit here right like if active

undetected exploitation was going down you don't actually know that you're being owned and you are totally blind to what's happening you'll usually find out about it later on and then you've got a whole lot of cleanup work to do I try to put everything in perspective like so if you I've walked here I took the viewing everything like there's a lot of actual bad stuff going on outside the world of like cross-site scripting and stuff so what am I asked every time I get a microphone is like you know you spent two days here go spend another two days working in a soup kitchen or give some money to some people they need and stuff

like that but that's just because they gave me a mic for 30 minutes I get a chance to save at bringing it back to the world of security that will kind of operate on this scale of like okay it's good to catch things as early as you can and things get worse and more severe as they go down the stack and there are tons of mappings for how bad a security bug is it exists in like open source projects we've got chromium redhead rupal they're all over the place and you probably have some notion of like bug severity in your development but so you can map these numbers to the severity that you're using already so I also care

about only the most severe things you should have a class of issue that's so bad you can call like an incident or a site event or bulletin or something like that but something that is goes beyond the scope of security so like if the whole entire website is down or you've lost all your billing data or something like that like that's impactful for more than just a security reason so there are mappings from overall things that are really terrible to security things and i like to use only the issues that are so bad that they're up into this like incident level so they give you some data right so you can write a script so that will pull

from your bug database or your incident management thing you can suck out some data so this is not facebook data but this is data that I have somewhat manufactured somewhat gleaned over time and this is like what it looks like over a couple years quarter-over-quarter the most severe issues map down to the least severe issues that are still pretty bad the one thing that I'll note about this model is it it doesn't account for the unknown unknown side to call this Schrodinger's security bug so there's a small anam and Schrodinger's cat excuse me real quick will I drink you can invite a cat but there's a security bug in the code and it never gets detected

or never gets exploited is this good or bad I would argue that the data eventually catches up solo and this does get exploited and you do find out about it or you find it later on through some additional testing that you've done it'll play itself out in the metrics right so if you had an unknown bug that you come back and find later you'll have a severity of like zero or someone type issue that you can then account for in the current quarters data set so that's cool but like nobody ever takes a selfie and just like posted it raw right you got I like apply all the filters you got to do like the dog ears and the bunny

rabbit stuff on there and so if you just had this big collection of that you can't really do too much with it although you can just like total it all up right and there's a prerequisite here throughout all of this pitch is that you have like objective honesty so the incentive isn't to get all your developers to sweep their bugs under the rug and not say that anything that says you do want to like continue reporting bugs you want to encourage all your teams to find bugs in the software that they're writing so don't say that like you know our number one goal for the half is to have no issues reported because then nobody will actually report

any issues like you want to set that goal that like will work towards there being no issues in our code base but we realized that we're going to have them and we should always report them when we do and so this is if you take that data from the previous slide you just add it all up you get this purple line which shows you like okay things kind of got bad for a little out there and then they seem to be getting a little bit better it doesn't account for severity or anything like that and so that's why my second kind of hypothesis here something I'd love to give back to the world is this formula which makes it

exponentially bad for the worst things to happen then the things beneath it I'll talk towards us a little bit with the data but so every says 0 now become something that's like 27 times force then a three-issue so you get this really really big spike and this encourages you to work on only the most impactful things they're the worst things that are happening in your code based on your system I don't this I'd be around a few people some of which are dr. Matthew snifter and dr. Charlie Miller so these are like PhDs and computer science and mathematics respectively and they're like a cool like algorithm you got their man but just like sum it all up and do i'll show

you like that the numbers instead of my crazy exponential badness things just get like step level worse as you go up the scale there and so I didn't expect people would likely oh yeah sounds kind of interesting and just like go implemented themselves if you check out those bitly link down here it is a link directly to a Google Doc that has all these like dupid equations and it already and you can just like do file copy and plug your own data in here and then you'll kind of see how you're doing over time and so this is like go check it out see how you are doing over time and it's the work that you're doing is

actually paying off so I had this other part of the abstract about incentivizing long-term secure framework bets and this is a little bit about how you do that and why you should do it so whenever you have a security bug come in or it can be like an architectural flaw or anything like that like you're working in the security space you should ask these four questions about like what happened why did it happen like you know what's ailing was there that led to this issue occurring when in the development lifecycle that it happened and then we're like what code base or what's this them or what part of the environment that it happened in and that should then

inform you and you allow you to work less on the reactive stuff over time and then more on the proactive and mitigating stuff and so this kind of map back to my little wacky data set I had before snaps here was like back in the day maybe we didn't have a lot of users we had no security team maybe we didn't know what we were actually missing it was kind of like chill times and then the company started growing and the code base started growing and the user base started growing and so security vulnerabilities just started like trickling in they were always there but they're just starting to get noticed typically somebody will find like one

issue and that issue is all over the code base so you have tons and tons of repeat classes of issues over and over again hopefully not for a super long time if you can do some works to prevent it so there's this HTTP header that every big browser will honor now called content security policy and you can kind of set this on your HTTP responses so that you'll neuter XSS exploits right so we get there we still care about XSS but what we've done is this engineering work to like dilute the severity of every cross-site scripting issue and then you can move on and like change your text back or work on core fundamental like

foundational work so that you'll get auto escape templating so you can move over to something like mustache handlebars I mean like this where now the developers don't actually need to be thinking about security every time that they're building their code it's happening by default and then you've like accounted for all these terrible times you've had in your life when you were getting paged non stop in the middle of the night or you check Twitter or like the full disclosure list and you see that you were the number one issue they are all the time and this is just the way who it's a trailing measurement I recognize but basically incentivize yourself and your whole entire team to

make things less bad in the code that you're working on one thing that I'll recommend as like a bit of my pitch here and a thing that might be easier and more effective than you might think thank you is this notion of non-obvious api's so like developers are sitting down to write code and they don't necessarily know what they're getting themselves into and something that you can do as a security engineering team of these giant sweeping code mods so you go back in this way that you've got maybe ten different code repos that have the code that powers your company systems and all these different code bases I would recommend taking this approach to basically make

it safer through the engineering team coming in and making it more obvious when you're writing code what you're getting yourself into so anybody here works with Django and want to tell me what's a string does and if not I'll tell you but I'll give a moment of silence of you shout it out that's cool so I also got the documentation to tell everybody what it does what's confusing here is though is that it's called safe string and what it does is it takes a string and it marks it as if it's been already cleaned in this safes then for further display and like I heard something gash to the audience and stuff like that like it's just confusing and

maybe it's actively misleading developers like you go down you're about to work with something and it's like a safe string which means this is actually dangerous all you have done is tell it that you know that it's safe so it doesn't make it safe in Marx's fakes and this is confusing enough that I've seen enough cross-site scripting bugs and Django code bases as a result of developer going in explicitly marking something safe because they think it will make it safe and then at least across the scripting bug on the site less misleading but still confusing is this syntax here and so I mentioned the auto escape templating being a really great thing that you can apply to your

code base so that you don't have to remember to escape untrusted user into it all the time so mustache has these semantics that will allow you in your templates to specify that something should be unescape when it's rendered so this is the same as marking it safe you're building out a template for rendering some data back and you say I know that this is going to only contain like bold and italic tags it's not going to attain anything nasty because say that I'm building it up myself the issue here is that a lot of times in big engineering firms or even a small engineering team you're gonna succumb to a time when you want to get

something done and the easiest way to get something done is to look at how somebody else already did it in the code base and so you'll go find a template for like displaying somebody's company name that's always set and it's like okay well this is how we did it this one time over here you're going to copy that paste it into your file and then lose this assumption that the code you're working with before and the data you were working with before is actually safe to display and you're gonna end up with another cross-site scripting book so what my favorite things about working at Facebook is this facebook ism where we're pretty obviously in your face

about not necessarily wanting to call a particular API or method so if you can't read this it's called secret Dom do not use you will be fired this is in the reacts code base that we use open source and I can honestly say that I gonna join facebook i didn't know necessary was going on with this code that I was not incentivized to call into these methods I'll say right like I stopped and I pause for a minute and a lot of times we'll talk about education being the solution to all our problems like only if we had smarter developers we'd be so much better and if we invested in all this training would be so much better

when I peace with that Barry is that there's so many things you need to have top of mind when you write code that needs a scale at like Facebook scale even just code to run anywhere right so you need to keep like performance in mind and internationalisation accessibility and scalability and interop between old services and security by the way and so it's really a pretty heavy cognitive load on somebody sitting down to like think like safe string hmm that makes it safer marks the safe like it's kind of tough whereas this thing is like way more in-your-face about don't call this or if you're gonna call it like think twice about it and we've done this so are contextual auto

escaping library is called xhp it's built on top of like PHP code and if you want to do something where you'll actually like disable the contextual odd escape we have they used to mark something's like a potential XSS hole and so that's the only way you can do it it's in your face and you're not going to trip into this most likely and if you do we've got a security team that kind of like passively watches all the code that's flying through and can match like new pattern matching basically lead upon gifts that are submitted and say oh this looks like something that you probably shouldn't be doing and so one of our helpful product security engineers will

jump in and kind of ask a little bit more about why it looks like you're calling into a particular function but you probably shouldn't be calling it two similar in that react to a base field have dangers we said inner HTML so if you're doing more like JavaScript development you're working in the client side it's easy to introduce Donbass XSS by setting user data is physically to enter HTML on an element in the Dom and so we never want to neuter the platform or like handcuff our engineers so much as I can't do the dangerous stuff if they really really want to do it so get this notion of like dangerously set inner HTML again this is the only way

you can do this it's as dangerous right in the title hopefully you know you're getting yourself into when you do this and so we can kind of hypothesize that this is a good idea but in everybody's like show me the data I want to see data that actually verifies what this works and so an exercise that we did most recently is you know Facebook done a really pretty good job at eliminating the traditional OAuth top 10 stuff so like cross-site scripting cross-site request forgery sequel injection all that like if you find it please tell me about it so into the bug bounty you'll be rewarded handsomely for doing so but logical issues are kind of tough to

catch through static analysis or have every developer really appreciate when they're like building out their prototype code so we had this model where instead of permissions being applied it like the viewer layer like you know you render the page and the page checks if the person viewing this data has actual permission to do the data it actually it's plumbed all the way down to like the object itself and so when you're setting up an object for like a birthday you kind of like specify what can be done as far as like rewrites update speed on that object itself so we could say in the beginning like no permission and what we found is that similar to say string is confusing

like does this mean you don't need any permission to do anything or if you have no permission then you can do everything and so we rename this one of these like big sweeping code mod things so anyone on the internet can modify this is a little bit more obvious and in your face when you do this and so I mentioned this tool we have for checking out every diff that comes by so this week every passion once we get into our main code days and we're like well it's like try measuring this thing and see if it's working about so in the past we would always look at every time that somebody was using like

this no permission attribute and we say hey do you really want to be doing this we go in and we go back and forth and clarify if they really wanted to do it or not and so I'm always in the business of like engineering myself out of a job so I can go do something more interesting than my current job and so jamming back and forth on these no permissions dislike wasn't super interesting we had this idea like I let's rename it to this more obvious thing and it seems like things are trending down there so there's also a couple glitches to explain this data we do like by annual performance reviews and so in July and December everybody

stops writing code for like two days and they write their reviews and then they go back up and they like crank out a whole bunch of code that they've been sitting out for a few days so those are those two dips right there and it seems to be working so maybe had when I write all this stuff down and a blog post someday i'll give you the thrilling conclusion mr. like whether or not this thing worked but let me add two more things that I think are important and like I said before with the dangerous is that inner HTML you never want to just be the security bad guy team that tells you no take everybody's toys away and

never give them back so we found you know in like going back and forth on these disks with people why they were doing it is that they really just wanted to move fast and iterate quickly and not think about this complex privacy model when they're just prototyping stuff and so we're like oh cool like it's kind of a missing feature that we don't have thing that will run and like the development environment with everything like totally wide open so you can jam on it you can work with design you can do whatever you want to do but it's never going to make it to production with this wide open model and so we like introduced development only and we saw

people picking that up more and more and then after that I saw in the devops talk or a few other talks like it's true that there's no place quite like production right like you've got different systems there you've got real user traffic you've got all these other things so we also allow people to ship stuff to production with an employee only attribute so that means that you can get stuff in our real production environment and you can dork around with it and employ only mode but we're never going to put any like real user data at risk because everything's going to fail clothes all the time lastly and bring it on home I got a couple minutes left here

the selfie taken never shared is like you know a total waste of selfie so my pseudo code thich here and some embarrassing whiteboarding that i'm happy to share with you although is it once you got all these bugs you can pull in so this is some janky PHP or hack code that looks at this collection of bugs that we've got it pulls from a particular tag right so basically we tag all our security plugs with three 1337 so we know that their security bugs well initialize all these maps so like a map of all our employees recursive employee maps plug-in with that in a second and that for the team and the office and so

we load all these things in then for every single bug will add to or inclement if it's already in there one of these owner objects to the map right and so now we've got this big giant map of everybody that's ever written a security bug in our engineering team we also do a recursive fetch for everybody in their reporting chain so that we can say like hey this is VP over here is responsible for ninety percent of the security bugs in our code base let's go have a conversation with him or her and then after that you can get stuff like office location maybe we need to go send an engineer to Seattle for a couple

weeks or particular code base or anything like that so grab this data lastly I'll caution though that there's this fantasy Navy of there being one rogue developer somewhere offshore that's like responsible for all your security bugs I think if you do this exercise you'll find out that's not the case at one point we were looking at a particular set of bugs and we like who's responsible for all these stupid security bugs it was like the security team going in trying to fix up other bugs they were like lower priority and as well is kind of like you know bull in the china shops thing where they're just like kicking over making a big mess and

so we're like how we're going to get those wrestling developers and with all US making those mistakes and so you know sometimes time that this is kind of like because I like looking in the mirror and you'll see that you yourself are responsible for all these issues so a little bit of a call to action here as I wrapped my 30 minutes up and I think I've got time for questions take this like apply your own data and then like let me know how it's going i think that this meme was relevant maybe six months ago with the yo gotti song came out now I think it's more catch me outside how about that that you want to have a

conversation because I really do think that it would be great to jam on this as like a collective industry share the results and then like I said incentivize these kind of long-term bets so that you're not spending all your time doing reactive firefighting i think that the heroics to come along with that are great but they're also exhausting and it's much better to be able to have a chill friday saturday evening you can go sit down and read the besom with your whiskey of cigar rather than like hot patching for ducks in systems like that so that's all I've got I'm Jim likes it Jimmy oh I also have yet to regret telling an audience full of security

people that I have enabled the option to say like accept direct messages on Twitter from anybody or they're not they following so you can hit me up on Twitter anytime catch me around here ask me questions I'm going to take a selfie because it's the name of the talk after all but in the meantime I'll try to navigate this room despite the blinding light in my face to answer questions of two columns and if not I think you've got another speaker in seven minutes all right well I'm gonna pull this we went off real quick all right cool thank you all thank you Jim so on behalf of Fitbit and bass at ssf we'd like to first venture with a

Fitbit Alta where motivation is your best accessory [Music] you