How to 10X Your Company's Security (Without a Series D)

hey everyone thank you so much for coming and thank you to the organizers for having me so over the past few years I've spent thousands of hours studying how various companies had scaled their security and not just the one-off ad hoc wins but the things that have truly systematically scale ibly raised their security bar so my goal in this talk is to collect a bunch of tactics and strategies and create a playbook from which you can take different parts and then apply them for yourself in your company you know whichever parts make the most sense so I'm going to be distilling and aggregating a vast amount of information so over 50 different conference talks dozens of tools blog

posts and in-person conversations I've had with security engineers at many many different companies so these are just the logos of some of the companies that I'm going to reference their work in this talk but there's more I also just wanted to say you don't have to like write down every slide or take pictures of it on the last slide there's going to be a link so that you can see these Google slides like right then and also this talk is recorded so you know don't stress out about it you won't be able to read everything so a little bit about me before we get started so I'm a technical director and research director at NCC group we do security

consulting so pen testing for web apps networks and so forth we've also been helping companies with their dedsec ops transformation security automation and things like that so some of this material is pulling from that as well here are some of the things I really enjoy so if you also like those come up and say hi after I'd love to learn from you and chat about it ok so there's some things that I'm just going to sort of assume and not get into a lot of detail I think many people have found the traditional SAST and DAST are overall not as useful given the operational time required from the security team as well as the cost

I assume you're willing to invest a lot of time now or sometime at least in order to reap big security wins later and I assume your security team has a few people but not necessarily dozens or hundreds right so you're somewhere in the middle you're not just starting but you're not maybe say Google or Facebook so again this is not a starting a security program talk but if that's your gym here's some places to start okay so this talk has three main parts so first we're going to talk about some sort of big picture security mindset type things how to think about security effectively and then the book of this talk is the middle section where we're going to talk about

some specific strategies and tactics you can use to scale your security so first some fundamentals that are nice to have then how do you scale that and then finally what might this look like say a couple of years in the future and then finally we're going to tie it all together cool so first some mindsets and principles so first I think everyone would agree with this first one security teams are always time and purse limited so fundamentally you need to automate to scale and one trend I see at many companies is that you have to minimize your nose right you have to build these nice secure guardrails that allow developers to do their job securely as

well as just faster and better I think Austin and the Netflix team talks about this very nicely in their concept of a paved road many companies are choosing to prefer like high signal low noise tools and alerting so it's okay if we don't find everything but when the tools do say something we want it to be actionable and a true positive and I think that's an interesting change in perspective I've seen that a number of companies so when we're building products oftentimes we spend a lot of time thinking about how do we make a nice UI and user experience for users but as security team members I think that we should think of developers as

our customers so how can we fit into their existing tools and workflow can we make the secure way easier faster or just otherwise better than how they're doing it already right we're introducing friction into their world when we're asking them to change how they're already doing things and lastly this concept of self-service security so can we provide tools and services that developers can use without even talking to the security team so I wrote about some of these in a bit more detail in a blog post you can check out and I wanted to make sure that I could connect with the youth in the audience so I included this so to sort of thematically summarize this talk broke is finding

individual bugs and woke is scale ibly reducing risk you heard it here folks okay so in life as well as in security you're always choosing whether to focus on the now the medium term or the long term and in this talk I'm gonna push you very strongly to always be forward thinking about this long term specifically ask yourself of my near and medium-term tasks which of these is going to provide the most long-term strategic value can I do a near-term task a little bit differently to make it more useful later and then also what subproblems can I solve precisely that is a high signal as well as its scale so maybe there's 50 things you want to find but some of them

you can do very precisely such that you just handle them and then you don't have to deal with it anymore and we're going to talk about that a lot soon another thing I like to think about is when you're approaching security there's many different tools you have in your tool belt right so you have static and dynamic analysis you have bug bounty and pen testing you have secure wrapper libraries as well as threat modeling you have runtime detection you have fuzzing of course that's the song and I think the point I want to make here is that depending on what you're trying to do there are certain approaches that are just fundamentally better or worse so

rather than saying oh how do I make tool X better instead ask yourself is to elect the right even approach for this problem I'm trying to solve and another thing that I think is very important is choosing what to ignore right so there are some fires that you just have to let burn at least for a time so Adams said this on LinkedIn recently that I liked so the question isn't is this thing useful but given finite time and resources should we be doing this versus something else because ultimately security and life is trade-offs okay so another way I like to look at things is targeting vulnerabilities by either the complexity of the analysis required to

find them as well as what vulnerability class they are so let's look at some examples so something that doesn't take a lot of contexts like a lot of algorithmic complexity to find is does this say web app have TLS on it you know is it using the right security headers calling team dangerous functions is essentially just greps but you can have some nice security wins there and then things that take a little more complexity of analysis like standard l wast bugs cross-site scripting and sequel injection and so forth and then on the hard side we have these complex multi-step bugs business logic flaws abusing built-in functionality and so forth so when you're first starting a

security program you might say okay let me just buy a bunch of tools and this is going to handle all of our problems and we'll be blissfully happy or you might say oh let's just pen test all of our problems away but I think as your program develops and becomes a bit more true more mature you're going to want to make it look a little bit more like this where you've built some nice secure defaults which are handling many of the easy cases and a lot of the medium cases and even some of the hard cases you have automated tools that are again catching some autumn low-hanging fruit but sort of less you know medium and high

complexity issues bug bounty definitely plays a very useful role in getting some continuous coverage and then I think the the true value of pen test here is finding these sort of medium and hard complexity bugs the things that require a lot of context and tools may not find and runtime monitoring is useful for finding some things you just can't really find easily other ways so just quickly solve as many of your problems with secure defaults tools are not going to solve all your problems but bounty does give you some nice decent coverage if all of your pen tests are just finding these sort of easy type vulnerabilities you're not getting the most value from it and run time

monitoring for bugs is useful for certain classes that you just can't easily find other ways okay so that was my opinion let's look at how some other people think about it so this is from Patrick and hasta zaps at Cal you talk two years ago so notice how on the left hand side we see manual testing per app threat modeling traditional bowl scanning is de-emphasized and then on the right hand side building a paved road so secure defaults so service and killing bug classes is emphasized they gave an updated version on a different topic but also Netflix Scott and Isha and notice how the heavy emphasis on secure defaults and then notice how that is growing over time so

I think that's very interesting okay so now let's get into the meat of it so these are sort of core tactics and strategies so I'm going to start with fundamentals and these are fundamentals not because they're easy but because they're a if you have a strong foundation in these you can build very high leverage scalable things on top okay so vulnerability management you need to know where you are now and you need to know if what you're doing actually works right something might sound great and you may invest a quarter or two quarters working on it and it may not actually move the security needle so this is very important so some success criteria for this you want to minimize

friction for developers as well as security you want to track vulnerabilities ideally in the same system such as JIRA that bugs are tracked in so developers don't have to go multiple places regardless of how you find the bug whether it's bug bounty and so forth just triage it through the same process and it's nice to attract relevant metadata so what are some examples what code base was affected the team in organ volved what vulnerability class in wasp I think is a little bit too coarse for this I would encourage you to use a slightly more detailed taxonomy maybe of like twenty to forty type things this will let you do some cool stats that we'll show in a second

also how severe was it how much do we care and also how is it found as you're scaling you might care a little bit about you know what was the root cause what code introduced it and where there mitigating factors and so forth okay so as you're sort of leveling up and scaling this if there's parts you can automate that's great many organizations have found some success building a vulnerability or risk dashboard that you can sort of slice and dice by team codebase etc so this gives you a nice high level intuition as to where should I invest my security engineering efforts and a couple of companies have found that it puts friendly pressure on teams

to improve no one wants to be the team where all their stuff is in red so here's some good talks about this and the second one Arkady's talk I like a lot and we're gonna see a couple of figures from it so the first is this one so this is open security vulnerabilities by priority last 90 days so if you are overall getting better if you're mitigations and protections are working they should ideally trend down over time similarly here when you have open vulnerabilities by sub team and priority it very quickly becomes clear oh we should reach out to this team and give them some help maybe there's some systemic issue they're having problems addressing this idea was given to me by

a M ray of Salesforce so again if you're tracking you know these bugs were from bug bounty also what vulnerability class they were and how much we paid so you could actually say things like this vulnerability class objectively costed us this much money and this can help perhaps get additional buy-in from upper management in terms of investing time and resources okay here are some example dashboards so this is from a Domino's app sack USA Talk so you can see like Oh which of these sort of micro services might we want to invest more resources in and you don't necessarily need to know the technical details of oh this is what cross-site scripting is like execs can look at this

and have an intuition about what they might care about this is from a Netflix talk again so there's a couple of columns where basically has this micro service used one of the security controls we built for it yes or no is it a high risk service and then you can sort of slice and dice on the right hand side with various filters okay let's talk about continuous scanning so the idea is we want to be able to scan new code with static in dynamic analysis tools usually static is on developers machines and code hosting and then there's a bunch of things you can do in testing QA so due to time I'm not going to talk about any of those however in

the backup slides of which there are about as many as main slides I will talk about all of these in more detail so one of the interesting things I found is this idea of like a continuous code scanning pipeline is one of the most popular ideas in dedsec ops many companies have talked about how they do it here is a number just only a knapsack USA here's a bunch more at other conferences right so this is all companies talking about how they sort of continuously scan code so the details vary by company but let's talk about some things they all generally agree on so first it's very nice to be able for the security team to iterate quickly so

adding and removing tools into the pipeline testing new rules generally people choose to scan pull requests if you scan every commit maybe there's a work in progress commit you don't care about and it's too noisy ideally scan should be very fast you're giving developers feedback while the context is fresh if you're doing more you know in-depth things maybe that can be done daily or weekly generally if you can show tool results within developer systems for example a comment on the PR so they don't have to go somewhere else ideally checks are very high signal if you're going to auto send it to a developer without triaging it you don't want to annoy them because if it's very

low signal and they spend a lot of their time triaging this generally makes them dislike you and it's a lot of overhead time for your team obviously you're going to want to capture metrics so what are we finding what's our false positive rate things like that you'll probably need to build some deduplication and whitelisting logic and then finally being able to MapReduce over all of your code and life systems it's pretty neat and we'll show why in a second ok so also just how to think about this here's a couple of other good talks and one thing I just wanted to dive into a little bit more detail when people think of static analysis a lot of times they

think about one of these two things which are sort of on opposite ends of the spectrum so one is you're doing something very like sort of easy from a analysis complexity point of view right reg X is operating on strings very easy to run and right or you have very complex heavyweight analysis was sort of SAS where you're doing control and data flow so the trade-offs here you can be very fast and not very expressive or you can be very expressive but maybe a bit slow and noisy but there's actually a middle ground doing sort of security linting or abstract syntax tree matching which i think is very interesting so here you are source code aware so you

can say like match the conditional or match this function call so you can do some of the complexity obsessed but you're so fast but you can't do quite everything SAS can do so I think this is a very interesting space that I'm optimistic about a couple of people have given talks about this so Justin Collins the creator of brakeman gave the first talk myself and a colleague gave the second one and Instagram had a pretty nice detailed blog post about how they do ast matching on their Jango mount monolith ok so if you were going to do this yourself generally what you're going to do is go from source code you're going to parse it into an abstract syntax tree and

there's a couple of ways you can parse either with a language specific parser a parser generator like antler or in my opinion the best approach which is a parser that handles multiple languages so if in your environment you have a bunch of different languages you probably don't want to find a separate parser for all of them so let's look at a specific example of this to make this more concrete let's say you have a bunch of node.js code and you want to find calls to exec where the first argument is not a string right so like any trusty security professional you decided to write a regex for it and it might look like this but then you might find code

like this where it's on multiple lines or the end of the function is exact but it's not the one you meant or maybe it's in a comment maybe it's in a hard-coded string and you know quickly you become a little bit sad like what you want to be able to do is say find me all function calls such that the function call is this name right conceptually this is very simple so there's actually a tool that's free it's on github right now called s CREP or Symantec grep and you can think of it like a code aware grep so in this example you could say s CREP - e exec dot and you're just saying find

me a function call whose name is exec I don't care about the arguments and it can also use this idea of meta variables where you might say find me all conditionals where the if and the else body are the same right generally that shouldn't happen it's a little bit weird or you could say find me calls to boto 3 dot clients where there's this dict argument where the values - the secret access key and key ID are hard-coded strings right so you have hard-coded secrets so again the idea is I have an idea in my head how do we express this as cleanly as possible okay so we talked a lot about how so what to

look for one thing is high signal vulnerability checks and security anti patterns for example disabling TLS so if you see this probably it's bad you might want to block banned or dangerous functions for example calls to exec or eval Mozilla has some ESL and plugins to do that maybe it's not a bug but it's just some security additions to the code that's interesting like hey I see you're doing crypto stuff like maybe we want to reach out to this development team you can also alert on sensitive file changes like the authentication or authorization flow the login flow things that probably shouldn't change that much and the security team wants to know about it here's a couple of tools that generally

are not too shabby okay so there's a nice talk by Aladdin of the Netflix security team about how they deal with open source vulnerabilities at scale every language has their own tool there's a bunch of commercial tools you can look it up another thing that's interesting with this move to DevOps and terraform and so forth there's a number of security linting tools for those infrastructure as code things so here's a couple of examples so key takeaways from this you want to have the capability to scan every pull request code base and deployed service ideally you're using high signal checks only and we're not necessarily finding every bug we're just ensuring a security baseline I think that's like a key perspective

shift that's useful right so you might be scanning for missing security controls in security area relevant changes okay that's fundamental so what is it it depends on who you ask but for me it's a list of the things you own so code servers databases and so forth so maybe this is a black box external a point of view where you're using OS int and certificate transparency maybe you give the tool access to your AWS environment and then it's a programmatically it figures out what you own or this last one white box holistic so maybe you give it a key to github as well as other tools you use and it sort of their API is to figure out what is your

environment look like so the core idea is we want to know what we own and how they connect so first thing that's useful is code and cloud and there's many things but I would start here so knowing in each repo what's the owning team who's the security point of contact and so forth and then in the cloud environment what services are we using what do credentials and roles in network kacl's look like and so forth and as you go along it's nice to build capabilities to get visibility into other assets being able to for example track code from when it's in the repo to QA and staging all the way to production is nice and so we're getting visibility

into all these different parts of our ecosystem and being able to query across things is very nice as well so Sasha from lyft talked about this at besides last year and released a tool called cartography and it's pretty neat and then our King they're working on like a commercial version of it basically and then there was a talk by Robin Oscar where they also give some nice overview of the asset inventory space okay so the idea of cartography is basically let's enumerate all of our assets what we own and then represent them in a new approach a database where each node is like an entity and edges are relationships between those so here are some things you can do you could say

which RDS instances have encryption turned off which ec2 instances are directly exposed to the internet and let's look at a little bit more advanced but I think more realistic and interesting example so let's say your company happens to run something like struts and you might know where I'm going with this let's say there's a new critical RCE it has a cool page a cool logo and maybe you're a bit unhappy about it and let's say there's also a curl POC that's been released in terms of like how to diagnose if you're affected so if you have a nice acid inventory and some of these fundamentals what can you do so first you could say okay figure out what

are all the servers I own and where are they you could then again using this sort of MapReduce type functionality run curl on all of those to figure out which of these are actually affected and again you can say oh I know which services are running so I can actually say oh these vulnerable ones I actually know which repo is responsible for those running services from there you can say oh I know the owner for those repos and then you could say oh let's send an automated email or slack message or created your a ticket assigned to those people who are responsible for the repo that is responsible for the struts vulnerability all right so we're taking a incident

response scenario that might take hours or days to respond to and cutting that down to ideally only a couple of minutes so this is for incident response but it could be applied in many ways okay so let's talk about scaling our efforts we'll talk about a couple of areas so many companies find they can't threat model every story so what do you focus on there's been a bunch of work in this space but I think it boils down to three main areas so one is having developers fill out self-service security questionnaires basically here's what I'm thinking about doing here's the sensitive data it touches here's sort of the risk of the types of things I'm

doing in terms of like parsing XML maybe parsing URLs and so forth and then basically it spits out here are some things you should make sure to do and a risk score so the security team can prioritize or you could have some lightweight lightweight threat modeling in the sdlc itself maybe after they talk about what features are required for acceptance criteria you could say oh also how could this functionality be abused and then how can we prevent that and then there's this idea of threat model as code so the idea for all of these is basically what should we spend limited apps like engineer time on okay so security engineering the core idea here is building libraries and tools

that are secure by default for developers and I want to emphasize that framework and tech choices really matter right so if you make the right choices here this can mitigate whole classes of vulnerabilities later so I included this picture of the wild wild west because that's basically where we were in web security in the early 2000s and I believe the core reason for that is that developers had to manually parameterize queries they had to manually output in code basically they had to remember to do something in order to not screw it up but with object relational mapper --zz default output encoding all these things have sort of systematically reduced these types of issues over time so when you're

thinking about where do we focus these efforts generally managing secrets anything related to crypto authentication authorization sequel file system access all of these things are good areas to start but really it's broader than this these are just some examples so just some case studies I know one company who ported their front-end code to react and that essentially killed cross-site scripting another wrote this data model wrapper library where all data access had to go through in order to access any customer data and that basically killed sequel injection and the core idea here is if something is hard to do securely if you have to just be aware of various threats just like build is secure by default

implementation and then how everyone use those one quote from asti like a lot is hit your security wagon - developer productivity right so this secure version ideally have has an even better developer user experience than the old way another key insight is if you integrate security at the right points you can get adoption much easier so say for example there is a new project starter template where every new say going microservice just clones that and then starts building if you can put your security controls into that then everyone who builds from that is going to get it for free and you don't have to sort of convince them to adopt it ok let's talk about detection in response

so this idea I think is pretty mean VI essentially it's when a fishy event occurs maybe a developer is running some command on a production server you send them a slack message and say hey was this really you and then they have to say you know yes or no and you only send it to the sock or IR team to investigate if they said no all right so essentially again we're trying to free up security engineer time as much as possible so what I like about this is we see slack writing a blog post about it in 2016 then Dropbox writing a blog post about it and releasing some POC code in 2017 and then Pinterest talking about it at a

different conference in 2018 so we can see this idea sort of moving across companies which i think is pretty neat ok so here's a blog post I like from Dropbox about how they handle threat detection and so basically if something the sketchy happens there is a cop-caller which messages this other system call it alert box which then grabs information from disparate systems basically all the context you might want to know then it sends that to this micro service called for Rumer forerunner which is running some sort of heavier analysis and running a steps in a jupiter notebook that say for this type of event this is how we respond and then the analyst is then given the stupider notebook

environment where all of the data has been gathered there's all these clear steps that have already been taken so it's easy to repeat across every analyst because the steps of what to do are documented and also any additional investigation they do is then saved in the notebook so you can go back later and say oh did we do we do the right thing should we maybe change this process in the future another idea is automating sauk run books so basically rather than manually responding to everything define your response process and then have some lambdas automatically spin up to either call the relevant security products right run custom scripts and so forth so Twilio released a tool called sockless auth0 talked

about this as well and then the AWS security hub has a nice blog post about this idea also ok so core takeaways here if you can push first line triage to developers or people who are just not the security team that's nice any context that the human analyst needs to proceed just gather this automatically and ideally you want to document run books for how you respond to different events so that you have some standardization and then automate them ok cool we're doing so well we're almost there I paid a graphic artist a lot of money to make this because I was like security endgame we should have should have a cool thing boom so yeah so that so these

are the you know aggressive long long term stuff ok so the first thing as one of my favorite tools and ideas by Travis of Netflix so when you create a new service at Netflix it's given a base set of permissions and then essentially what repo kit does is it watches how it behaves over time and then if it doesn't need permissions it's given it just takes them away and then watches if the app starts failing so basically without talking to the security team every app is gradually converging to least privileged and apps that don't need any permissions converge to zero so this is pretty awesome more recently a canard from Salesforce wrote a tool called policy sentry that comes

at it from a different angle like how do we make lease privileged policies from the beginning rather than removing permissions later so let's look into that a little bit more detail why is that so awesome so the ongoing time requirements from the security team are essentially none other than maintaining the tool but the security benefit and the risk reduction is huge right like how much work would it be to manually look at every single micro service in your company and say oh like what exact permissions does this need in AWS right that would both be point in time difficult and just impossible over time so anytime you can find opportunities like this you should take them specifically we're trying to

maximize the ratio of security ROI to the ongoing time requirements for the security team ok targeting vulnerability classes again this is another slide from our Cadiz talk so this is vulnerabilities by category so again when you're doing vulnerability management you could say oh these are the issues we have the most maybe we want to start there ok so a number of projects at NCC started like this hey we're not getting a lot of value from this popular SAS tool can you look at how we're doing things and just you know help us get more value so the initial ask was like how do we get more value what does that actually mean probably it means something like how do

we find more bugs of higher criticality with less manual time but if we take a step back I think what we care about really is just how do we find bugs more efficiently regardless of the approach and taking another step back given limited apps ik engineer time and budget what's the best way for us to overall reduce risk and again this is not tool or approach specific ok so how to do this at your company so aggregate your vulnerabilities over the past couple of quarters or a couple of years group them by the vulnerability class is well how you found them and you want to probably wait by you know how much you care how severe were they and then think

what can either find or prevent them at scale so the goal here is minimizing costs either you know bug banning pentesting directly or to a licensing as well as app set time in terms of finding manually triaging results and so forth so is one method finding all of your issues have you had other success stories in your company that you can leverage and learn from these are useful things to think about so let's say again another example if you can see where are all the vulnerabilities come from you might be able to say oh we see this tool or this say pen testing or bug bounty is finding most of the issues that are high-impact that we actually fix or this

approach is finding things that usually we just mark is don't care so maybe we want to deprioritize that so let's look at a specific example let's say you did a time audit of your app SEC team and you're like this is sort of how we spend our time we spend a fair amount of time dealing with xxe a little bit manually running security tools and so forth so let's say hey we were spending a lot of time on xxe let's like drill into that more like whoa what are the subcomponents of that so you might say okay well we're doing some developer training we're triaging bug bounties submissions we're working with developers to fix the issues as well as

validating that the fixes actually worked we're configuring both SAST and DAST tools to do that and the point here is all of these are continuous ongoing recurring operational time costs right these are things that you're doing that are preventing you from doing other things so what if we were to instead say build a safe by default wrapper library for parsing XML that disables dtds and basically if you use this version you're safe and then you teach developers about this library and then roll it out everywhere and then you have lightweight scanning for every poor request which basically says hey if you're doing XML parsing like are you using the library we wrote for you and then if not maybe

warned or block and then basically you're done right by construction you don't actually have to do all of this complicated bug finding analysis because you've just eliminated it by construction so Morgan Roman from DocuSign gave a nice talk about this approach where he describes how they eliminated regex das xx EE open redirect as well as SS RF basically by secure by default libraries as well as ensuring their use right it's a simple idea but I think very powerful so let's go back to your app set time so where we were previously spending time on xxe we've essentially eliminated that so now that time we were spending there we can now start devoting to other areas

so we might say oh we're manually running security tools like maybe let's automate that a little bit and then boom now 50% of your time that you used to be spending on other things is now free to invest again in further high-leverage activities so the point here is we're basically trying to build a apps X snowball where we are systematically becoming more effective and our efforts more scalable over time right rather than playing whack-a-mole a bunch of places we're trying to have compounding returns on our efforts so again what I like to say is security engineering is the compound interest of security right so you might be putting in some time here this week and maybe in the next few

months and you don't necessarily see a lot of value immediately but over time you are investing in things that you can build upon and you're just becoming more effective higher leveraged over time also when I wrote this slide I wanted to point out that quoting yourself is kind of awkward obviously Ghandi said that okay so targeting bolon classes use your vulnerability history to determine where to invest effort consider the vulnerability classes like what's finding them what's their impact what's the most effective way in terms of time and money to reduce risk and solving bug classes amplifies your effectiveness okay last topic enforcing invariance so I think this idea is super neat and the idea is essentially you want to

enforce or alert on things that either should always or never be true in your environment for example you might say AWS instances should never be accessible on all ports to the whole internet we should just never do that so a David dog had a nice blog post where they essentially described a system where a lambda will spin up and auto shutdown any ec2 instance with this policy you might say oh we have all of our developers using terraform so manual changes should never be made through the AWS console this should just never happen so Arkady has a nice blog post about how to do this with cloud trail another idea is we should never use

these regions or these cloud services like in our company we always use a u.s. East in these three AWS services and we never use anything else so if something spins up in another region or another service this is probably a red flag either a developers doing something new that they maybe shouldn't be doing or it's an attack you can also go further and do this perhaps per app or per service and this was described as well as a bunch of other excellent ideas not this most recent but the app set Callie before that by will and Travis of Netflix ok so the idea here is what are things in your environment should that should either always or never be true

either with your cloud environment or your security controls or code and so forth and then which of these can you programmatically enforce or alert on and the key intuition behind this is that if you don't need any context to make the decision right there's no sort of like oh well sometimes this is ok but you know there's all these other mitigating factors which like a human needs to make so if there isn't that then you can just programmatically enforce it and then there is no operational time for the security team so you just sort of you know whack that mole once you just don't have to deal with that anymore and then you spend your time on other things so

again we are trying to knock off things from our plate to become strategically more effective over time so I would encourage you to think how is what we're doing now making us more effective in the future right so if it's not I would consider D prioritizing it and then obviously Gandhi also said this okay so we covered a lot so let's put it all together so I'm going to talk about some things you can start doing immediately like say this or next week some things you can do in the medium term and some things you can do in the long term okay first step one is assess figure out where you are now so evaluate

the fundamentals are you tracking all of your vulnerabilities in one system are you tracking the right metadata etc for continuous scanning what sort of capabilities do you have can you roll out a new tool or remove a tool very quickly and easily then asset inventory what visibility do you have into your environment and I would encourage you to set up a meeting with security leadership as well as developers subject matter experts and figure out you know based on where we are is there vulnerability or asset inventory information that we would like you know is there promising projects we should do and then in the three to nine month three to nine months start building based on what you've assessed so nail

the fundamentals so here's where we are here's where we should be to have all of these covered to build a strong base from which we can build in the future and then take on one bite-sized project based on your historical vulnerability data and your company's business factors and risk so the key thing here is bite-sized project right you don't want to necessarily say oh let's do this crazy complex massive project that's only going to be valuable like two years from now ideally it's something you can do in a few weeks or in a few months so that you can prove to yourself as well as management and executive leadership you know it pays to invest in things you

know we spent time building this thing and look at all the security benefit we're getting in the future you know we used to spend a lot of time you know triaging and fixing all of these issues now we can spend that time on all these other things and then in the future so you've assessed you've built and now you start scaling so you want to be more highly leveraged with your time ideally you can target specific vulnerability class and just eliminate them categorically you can invest in projects with security high security ROI and minimal ongoing time requirements for example automating lease lease privilege or invariants and again you want to focus on areas that meaningfully raise your security bar

right so there's things that might be technically very interesting there's things that might be fun to work on that seem like they're going to be good but are they actually going to move your security needle are they going to raise your security posture ok so let's just quickly wrap up for some reason I decided it would be good idea to watch every apps at Kali 2019 talk and write a detailed summary of them the clancer the question you're thinking is it took hundreds of hours but if you would like to benefit from that you can read it right there for free also I have a newsletter where I summarized talks linked to tools and resources I find

useful as well as write about things I work on so at least one person doesn't hate it so you might like it too ok so thank you so much for your time these slides are live already you can go right there I'm happy to chat on Twitter as well as LinkedIn again there's a link to the newsletter if you think that that robot is cute I have an egregious number of stickers in my pocket and in my backpack that I'd be happy to give you and there's some key insights from sort of the whole talk in case that helps you with your question asking and actually since I have time I just wanted to say a big

thank you to all the people who did the work that was referenced in this talk you're really pushing the industry forward and I and others have learned a lot and I appreciate it and there's a number of people who reviewed early versions of this talk and gave me excellent feedback so if you like this talk you know big thanks to all these people for making it happen so yeah I believe I have a few minutes left for questions and also when time runs out I would be happy to chat here in the hall etc so thanks again so much for your time

all right everyone um please give me join me in giving Clinton big thanks for joining us if anyone has any questions just raise your hand real high and I can bring you the microphone you went over here hey great dockland you talked about fret modeling as code can you explain a little bit more what that is and how it's different from just traditional trip model yeah that's a good question so the question is can you provide a little bit more detail about threat model less code so there are a number of backup slides that you can see on this but the idea is can you express security properties you want or abuse cases of the system in

sort of a security integration type test such that they are continuously run as the application is built that's basically the core idea there's more details but yet they're questions raise your hand real high leave a cos in the front if someone is gonna start an application security rave from the beginning like it's just a free-for-all what would be a good way for them to start if you could give them one or two things to do what would be a favorite advice that you would give to a company okay thank you so if it's a free-for-all where should you start I think one thing that I didn't talk about as much in this talk because it didn't quite fit in his theme

but I think building really good relationships with developers is absolutely essential if you can have just the culture of the company be aware of security and even have the intuition of like oh this is a thing that might have security implication let me go proactively talk with the security team then that can go a long way before you necessarily have built the infrastructure to have like continuous say asset inventory type visibility into who's pushing code and what it's doing so I would say definitely a bad I think you can get a lot of nice wins by tracking vulnerabilities in terms of like what type of vulnerability was this how much did we care about it and and things like that

there's various metrics and high-leverage things you can do but only once you have the data so the earlier you can start collecting it the sooner you can start doing that but yeah thanks so much for the question I think we have time for one or two more I'll see one right here I don't necessarily disagree regards to suggestion that if you found these kind of vulnerabilities let's keep looking for these kind of vulnerabilities when you're trying to optimize your time but isn't there a risk that you're looking for the things the low-hanging fruit maybe is starting to be whittled down and there's you won't find it there and you maybe have blind spots other places how do you

balance sort of looking for the things you haven't discovered versus spending more time and I've a live with that low-hanging fruit yeah that's a that's a really good question and I I don't think there's necessarily a simple answer but yeah so the question is here's the issues you've had in the past if you just focus on those maybe there's important things you're blind to yeah I think it definitely is easy to get caught up in like oh here's the historical vulnerability data let's focus on those and not necessarily have this be sort of continuously changing over time I ideally as you're getting better there are things that were comparatively less of a problem that you

can now focus on and I think one interesting unintuitive point that some people don't think about is like as you get better at a lot of these things you're going to start finding more issues that have always been there you just didn't know they were there so in the short term as you're improving from a metrics point of view in terms of number of vulnerabilities found it can actually look worse right so I think one security metric that is it initially you might think is great like number of vulnerabilities found can be deceiving in that as you get better at finding them you're gonna find more but yeah so I agree with your point in that you

don't wanna be overly focused on just like these issues are things we've had in the past I think one way to get around that is sort of holistically maybe by annually or quarterly like taking a step back and thinking are there important business risks that we are ignoring based on our current process there's a like mitre and mist have this for example the cybersecurity framework has like different areas and levels of investment and things that you can sort of have a standard to compare yourself against similarly with open Sam but yeah I think the key is to sort of continuously relive that re-evaluate where you are and what makes sense yeah that's a really great question thank you

all right I think we are just about out of time unless anyone has one last quick question No okay well then please join me in thanking Clint Clint thank you so much for being a speaker IP side thank you