Building A Secure Development Lifecycle On A Shoestring Budget

communication resources and faster and more reliable that go higher performing all right and I'm kind of a walker so as long as you guys can see me okay I'll stand down here my apologies to the guy ass tease the camera and follow me all the time yeah my name is John / bah i'm the founder and owner of info secure a local firm that does information security consulting kind of creative on the name and the talk i'm giving today is about building a secure development lifecycle I've done this twice now for companies that I've worked for and I do it quite often now for companies consult with and you know there seems to be this

prevailing concept that one building secure code is difficult and to developing coming up with a secure development lifecycle is a very expensive process that requires bringing in large companies with big bills like digital and I can tell you from my own experience that that's not the case in fact you really can do this on your own without any outside help so that's kind of we're going to talk about today I'm not going to tell you what your secure development lifecycle should be because that's sort of your decision not mine it depends on your culture depends on what you're trying to build it depends on your regulation and so forth what I am going to talk about are some of the

strategies that I've used in the past to build a secure development lifecycle talk about some of the resources that are available to you and answer any questions that you might have as we go along please don't be afraid to interrupt in the middle of the presentation I do have a question how many people here are actually developers write code and then how many are managers and how many are infosec okay all right good great so the first question you have to ask yourself is what is a secure development life cycle and the way I like to talk about it is simplified it's the tools the skills and the process is it that we need to build

increasingly secure code I never say to build secure code because how do you measure that what is secure code what's secure today will not be secured tomorrow the idea is that it's an iterative process having an STL is really all about moving from being reactive to being proactive that's that's all that's all it is reactive well proactive in terms of what hackers are doing today proactive in terms of the the current attacks but also proactive in terms of regulation and other requirements so it doesn't cost significantly more to build secure code than it does to build insecure code because in the end you're typing characters on a keyboard right in the end you're writing a line of code and

you can either write a secure line of code or an insecure line of code takes about the same amount of time what it does take is some knowledge and some understanding of what secure code is and what it looks like the things we'll talk about today we're going to use a lot of water folly terms only because waterfall was first I'm very agile in the way I like to work in the way the teams I like to work with and so forth and everything will talk about will fit well into agile and it does apply it both the one time projects if you're building code for in an IT organization but also for product software that's going to be iterated on

over and over again so in to start out I want to throw this image up on the screen this is the Microsoft sdl and really honestly this is about how simple it is to build a secure development lifecycle sit down and think about the processes and like I said these are very very waterfall processes right in training requirements design implementation verification but if you're agile and I have some slides and appendix if we get to it we will if you're agile you may be doing activities in each of these columns all at the same time you may have a piece of code that's in verification right now while you're implementing something but oh you got to

work in at 9am you have to go do a meeting to talk about requirements with some of your users okay so that's how it kind of fits in in agile as well throughout each of these phases microsoft has some recommendations of different activities you might want to do this is a secure development lifecycle it may or may not be your secure development lifecycle a secure development lifecycle is basic kind of a document that the sky describes a process that includes some or all of these that may have some gates for when you get to exit a given phase whatever works for your organization this is kind of a model for it what we're going to do today is break this

down we're going to go through each of these phases and talk about kind of the goals for each phase and what you might want to do during that phase the things you're going to look to have we'll start with training like I said it's just as easy to write secure code as it is dry insecure code you just need to know what you're doing and that's what training is all about the goal is to prevent the mistakes how do we get training well you know there's a training program that I talked about a little bit here that a friend of mine at Salesforce implemented and now Cisco I was at the IC squared security Congress in October and the

person in charge of the secure development life cycle training at Cisco presented on their program and it's pretty much the same thing they call it the security dojo they did sort of a karate belt approach to training where everyone got fundamentals so it's kind of like your white belt and then people that went ahead and did some oh awesome top 10 by technology got a yellow belt and so on and so forth where you know people who maybe go get their GSS p from sands become kind of the experts once they've done some applied training do you have to go outside to get all this training no not at all we'll talk about that down the road a little bit a lot of

this is stuff you can learn on your own i have i've done a number of certifications you know I've got a G whap cissp I've got some other sands certifications but have actually not done the GSP yet I'm self-trained to read a lot of books I look on the internet I talk to a lot of people when when I find a vulnerability in a client's code we talk about that vulnerability I learned through osmosis and that works very well for me and it works for a lot of other people the key here is to have the commitment to learn I've worked with so many developers that are just like I want to hear about it

you know either a it's not a security bug right I'm the smartest guy in the room you're not it's not a bug or be okay fine it's a bug tell me how to fix it I'm going to go ahead and write this same bug tomorrow and you're going to tell me tomorrow how to fix it because that's how much I care about my career right it all depends on you and your attitude and your team's attitude okay when you move to the requirements phase really the goal of requirements is just to determine how much security is enough security how much do you have to pay to figure that out not very much you have to take some time to understand your

clients your internal expectations and your regulation I have a really interesting conversation with business leaders quite often where I'll sit down and say okay how security we want to be and they say we want to be secure secure everything we want all the security in our code great okay so i think the bill for that will be about seven hundred fifty thousand dollars because here's what we're going to do all of a sudden all of the security things are no longer as important and as you talk costs you begin to figure out what your company really wants to do and what you'll notice is there's usually a gap right you want this much security and your

company wants to pay for that much security alright but really building a secure development lifecycle is part of the requirements face is really figuring out what it how much security is enough and what's your risk and then also setting what the engagement process is going to be like okay so figuring out when the rhythms our feature reviews when when you sit down a look at new features and review them for security how frequently will you do that how will you measure security what's the definition of done when do we know that we're finished with our security these are some of the things that you're going to think about coming into your requirements phase and then put them on

a schedule put them in your backlog if you're agile put them on your calendar otherwise make sure they get written down and that's one of the key themes for your own sdl is that you write it down a lot of people especially people in agile hate that idea and this really is the one place where kind of break with the agile concept of not having a lot of documentation really we want to have the sdl documented and the activities in the sdl somehow integrated into your your processes a lot of people think well I'm agile or I'm a water waterfall agile which I call water fragile or we're just random Cowboys but you know what no matter what

your approach is you actually do have an approach it may not be written down and defined in IBM method blue with a hundred thousand pages of documentation you have a culture then the idea is to figure out how to integrate your secure development practices into your culture so it takes some definition and it takes some observation but it can be done okay design phase this is where we're sitting down and trying to figure out okay how are we going to build this new feature how we're going to build this new product and here's where we start to really talk about how are we going to meet these security and privacy requirements it the idea here is that

we're not backing into the security of our application we're actually planning ahead and thinking about ahead and that's the only real difference with a secure development lifecycle like I said we're being proactive instead of reactive what third-party components are we going to use and let's do a review of them before we do I can't tell you the number of times that I've done pen tests or static code analysis for clients who have taken on third party dependencies and the holes in their applications all came through their third parties because they didn't think about them in fact we had to do a major bit of work because I had a client building mobile applications in the healthcare space and

they picked up a platform so that good right you know iOS and Android at the same time and it turns out that that platform unbeknownst to them was cashing all sorts of data and we discovered it in a pen test and it took them a couple of weeks to really figure out how to get the cash data out and the root root cause analysis for that was simply we picked up a framework because we knew is going to accomplish what we wanted to do but we didn't have the time as developers to analyze the framework to figure out what weaknesses it introduced and that's really what this design phase is all about is figuring out if I'm

going to take on a dependency what's it going to do read the documentation play with it do a little bit of pen testing on your own look into it a little bit and figure out what risk you're taking okay I like to talk about the ABCDE of security when we're doing iterative software processes where maybe it's a product that we've built or something like that I like to ask questions about ABCD and E actors are we going to change in this phase of our product design we're going to change who interacts with the application may be up until now the application was internal only but now we're going to open it up to external clients well that really changes the

world right it changes all of our risk assumptions and it changes the technologies that were dependent upon and so forth B is business so what are some of the changes are going to happen like I've got clients that have come to me and said hey up until now our product does not contain any HIPAA regulated data but we want to change that ok that's a that's a business change channel you know a lot of times we'll build I worked for a company once that you know had a bunch of HTTP applications https applications they wanted to move to mobile so their answer was to take no j/s server and scrape their HTML pages and then manipulate

them into something a mobile application could consume right it's it's a strategy maybe not the best strategy but it's a strategy and it's a decision people need to make and talk about data what data are going to store in the system I have a client who we have always had this requirement that there will never be any pH I stored on a mobile device well they they decided recently that there may be a business case for that so we had to do a business case review and talk about the security of it and by the way this clients very agile very small team there's about 10 developers total we did that business case review it sounds so

formal doesn't it I mean it sounds like we all flew into a major city and you know got a bunch of white boards out and stuff like that nah we did in an hour we just did a phone call documented the results of the phone call this is how we do agile in healthcare world they have these quick calls we do a lot of stuff on slack document it with email and we have a place where we store all these emails so when regulators actually show up we can show proof of oh yeah here's our feature review for XYZ feature finally environment whether if we're going to change in the environment you know what happens today whoo-wee let's

go take advantage of the clouds so we were running stuff in in on-premise servers and we're going to pick those on-premise servers up and move them EMS on the cloud what could possibly go wrong okay so these are all things in the design phase that we think about I love the the idea of just ABCDE just keep driving that home in your mind what's you know what is changing this time around okay when we get to implementation here's where we talk about you know like users what we call requirements and waterfall are the user stories and abuse cases in our agile world all right and during implementation we want to make sure that the code that we've designed and

hopefully we've architected in a secure manner we want to make sure it's implemented in a secure manner right are we avoiding cross-site scripting vulnerability sequel injection vulnerabilities the real easy things this is where I'm a big advocate of static code analysis it is the cheapest way to prevent or find a lot of these low-level simple vulnerabilities and so yeah question I actually my business I own check marks they're actually here if you want to get a demo of them there it's a great tool I work I consult for a major financial organization right now they use fortify I'm a big fan of check marks you can get some of that functionality out of brakeman and lint

and so forth but to really get a good scan you want to invest in a tool or find someone who'll do it as a subscription service for you which is one of the services that I offer for my clients as well and when it comes to the shoestring budget this is where i recommend you break a shoestring spend the money it takes to either acquire a static code analysis tool or to use someone on a regular basis to look at your code and the more frequently you look at it just like anything agile the more often you look at that code the faster you find the vulnerability is the easy it is to fix them okay and you know

this is a great time for all that training to be put to use i teach a course called a wasp top 10 programming countermeasures it's about a six hour course and you would think with all of the talk now about web vulnerabilities and stuff like that you would think that that course would be boring that the developers would never hear anything new I mean how many times have we heard about sequel injection vulnerabilities right it amazes me though every time I teach the course how many things people learn and a lot of times what I'll do is I'll combine I'll do static code analysis and then I'll take the results of the static code analysis and actually

put it into the course as the sample code of what not to do it's hilarious to see the finger pointing right oh my gosh that's Joe's code look at that it's really incredible to see that kind of live interaction and see developers recognizing their own code in their own mistakes the the very simple basics it's the top ten is just the top ten it's not all of the ways you can write vulnerable code however it's the ten most common ways that you can write vulnerable code it's a great way to start for two reasons number one it teaches developers how to write more secure code but to it really just raises awareness developers start thinking about sequel injection

and stuff like that really the goal of your training in this phase or before this phase the goal of them of the impact is to have your developers ask the question what could possibly go around because what is a developer focus on features that's right they never think about the unintended consequences I had a really cool experience this year I got to speak with a company i'm actually going to work for in about a week at CES okay we the company has started a cybersecurity summit at CES which is actually really well attended just probably good thing but i had the opportunity to wander the couple of different floors at CES and look at all

the new devices and all the really new cool things that are out there and i kept picking these things up thinking what could possibly go wrong what are the unintended consequences of this device and it was amazing i mean you've got health care devices you've got shirts that you can wear that have sensors in them right so what happens if i can do something in like actually send shock waves you know electronic pulses through the shirt instead of reading them just all sorts of really wild things the automotive place was really scary self-driven cars people didn't really like me cuz kept asking hey who who does your security like how do you how do you

figure out these things are secure and they didn't really like having security people ask questions about their their product I don't know why and make sure in this you know one of the things that a lot of people have success with is making sure they have unit and acceptance tests integrated into their including security and keep in mind during your implementation phase that secure features are not the same as security features how many times have we had gone to a client and our vp of engineering who used to code tells the client eyewear secara we use we use windows form forms based authentication and HTTPS we're good okay so keep in mind that every feature needs to be

written securely not just the security features and by the way we're having some explanation about how to do secure code we're going to jump to how to build an SD l in a minute here so verification phase and I'm running a little bit faster verification phase the opportunity to validate your security features okay so if I built the login let's make sure the login works it's also your opportunity to make sure all of your features are implemented securely this is where you do fuzz testing this is where burp comes in really handy having it knowing how to use it best investment you can ever make in security three hundred dollars for burp it is the most powerful tool in the

world a lot of times I'll do rfps and people will ask me well what tools do you use and i'll say i use burp and the command line and well what about all these you know they list all these dynamic analysis tools and all this stuff and I'm like no I use burp in the command line with what do you need all the other tools for right burp has a great scanner in it actually that works pretty well so it's a good dynamic scanning tool you can check that box but really burp just puts a lot of power in the hands of the person that's using it this is where your agile abuse cases will be used and this is where you

confirm your logging auditing and incident detection capabilities we'll talk about that in a minute the time to find out that you don't have auditing logging and incident detection capabilities is when you have an incident don't don't learn about it then okay I just wrapped up an incident for someone we got away really really cheap on that one but they learned a lot about their systems and what they don't have they were lucky okay release phase this is when you want to make sure you have an incident response plan this is when you conduct your final security review I had a boss that used to talk a lot about the NASA red light green light and this is

really where you want to do your security red light green light have we done everything we need to do to prove that the product is secure enough that I can go out the door alright and then this is also where you want to certify your release and archive your bits why would you want to archive your your code any ideas if you have an incident response and you guys are 17 features down on the on the the main branch and you need to do innocent response and you can't unravel everything you've coded your about 24 17 new features out into production to resolve your issues and I've seen it happen it's very painful and very ugly the other thing that

happens that I've seen work for company I found a wonderful critical vulnerability it was awesome there was a password reset feature and as a convenience to their clients they had this concept of a default password so you know someone forgot their password you could set the default you just reset it say oh well it's the default password and everyone in the company knew the default password was very convenient well the problem was that the default password was actually sent down with the password reset form where you would request the password reset so you'd click it and it would auto populate your next password login screen with the default password really convenient right and it was in the HTML source okay

stupid so we fixed it that's great three months later the new release went out and guess what was back someone lost the change so taking good care in the release face of your bits really important and then finally response face this is not the time to find out that you don't know how to do response it's very very expensive to bring someone in to do response for you my clients are lucky I'm a terrible consultant I don't don't charge what I should but you know if you actually have an incident where you have to bring in an incident response team like and Ian or someone like that you pay through the nose for it and when you

could have prevented it or at least made it a lot easier by actually preparing your it's in a response okay so this is this is what an SD l is ok so now let's talk let's go well any questions to what an SD l is first before we go on this is kind of the core components of a secure develop my life cycle clear as mud right ok good all right so how much is going to cost so you'll notice here my wife yelled at me she's like no one can read that and I kept saying yeah I know that I just want you to remember that we had a slide on training ok right there what

do you think he would need in the training face what's the goal of a training face build competency yep it what sorts of competencies who do you want to build if you were going to train a product organization I was going to stop and get candy bars and I just I ran out of time this morning I love throwing candy bars out for answers

so you want to build awareness of not all the different ways something can go wrong but awareness just of the fact that things can go wrong I like to talk about developers who've not been trained in security I compare them to owning a Rottweiler which you know a lot of people have this really negative impact of a Rottweiler they're just safe or dangerous than any other dog but think about a Rottweiler it's not trained so you have all this power and all this strength with absolutely no self-control welcome to the world of developers okay so here are some basic things that you might want to train about one would be your stl process probably want to teach

people how to follow the sdl you've designed it would actually be very difficult to argue that you have an SD l if you can't produce to a regulator some aspect of training around that s do other things threat modeling right so typical block and tackling aspects of secure code you probably want to teach some secure coding and guidelines and then also offer individual training on coding and testing we'll talk about that a little bit more but you know you probably want to have one or two experts in your company who really really know about secure coding and or who are really good pen testers because they can be on loan those services aren't needed 24 7 but you know what every week or two

someone's going to pull on them so send a couple of your people away to a sans course you probably don't have to have everyone go and get certified in Java or.net but having one or two people do that as a great idea okay so how much this is all going to cost well you know what I mentioned earlier i'm pretty much all self-trained I do have a GU app so you know I spent a fair amount of money on that everyone knows how much sans training costs and you know you might want to probably send someone to a good code training and maybe you know instant response training you might want to get one person with a GC IH certification so

you've got you know any level of investment but really honestly all of that stuff is available freely as long as you find someone who's passionate about them and give them the opportunity to be trained or to train themselves that's what's important so your training budget could be anywhere from zero to 24,000 if you want to send people to what three or four sans courses or higher if you want to send more okay so here's your shoe string budget training where are you going to find your best training owasp is a great source for we're going to talk about sources in a minute but just you know it's out there it's everyone on the internet requirements what do you what

are your goals during the requirements phase and what do people need to do to accomplish those goals ideas so the requirements phases where we're trying to figure out how secure our application has to be we've got to understand regulation and again you can bring in consultants and sometimes it's a good idea right if you have someone if you're moving into the hip of space and you can reach out to a consultant and pay them three or four thousand dollars to come in and help you understand how HIPAA will impact you that may be a cost savings but on the other hand you may want that training internalized into your team so you might want to train

have someone spend time reading up on HIPAA reading up on how to how to write secure codes in the HIPAA secure code in the hip of space in fact that's a book i really want to write i wish i had time to do it you know it's it isn't rocket science actually there's just there's not a lot of regulation around it it's more about documenting what you've done this is also when you want to have the ability to write good user stories and the definition of done what's interesting is when it comes to user stories there's a project called safe code it's a little bit old it's been around for a while basically Microsoft Adobe some of the big vendors five or

six years ago realized they missed the ball that owasp had really beat him to the punch and a lot of this stuff so instead of piling all their energy into helping owasp they said let's build a room so they built one called safe code it's very redundant except they have a fantastic list of users you use cases user stories for agile you can literally copy and paste them in depending on your organization's maturity safe code is the link okay so you know how much does it cost to define what done is a half an hour and well I'm sorry let me try it again half a day arguing a bunch of developers testers and program managers

right it's not that big of a deal all right in the design phase design needs really again this is a zero dollar investment you need to understand you your security review and documentation how are we going to conduct a security review what is a security review that's looking at a feature and asking yourself what could possibly go wrong with this feature based on the answer what our requirements to make sure the feature isn't broken okay it's this is a low-cost thing that you just design into your SD l during the implementation phase this is one place where like I said earlier I advocate spending money static code analysis is probably the cheapest way to prevent vulnerabilities

either by engaging with someone who will scan your coat for you on a regular basis or by purchasing static code analysis tools you can start small lint is a great start brakeman is a great start right there's some things that you can do almost for free if you're running a mobile application you can do sort of a combination of static binary dynamic analysis quark is a tool that was built by linkedin that's now open source it's a great tool for analyzing android binaries to look for most common vulnerabilities things like you know intense and so forth that kind of stuff so there are some free tools out there they're not going to cover everything but they'll get you started while you're

trying to make decisions on other tools so that's your big spenda static code analysis but other things you do code review how much does it cost to learn how to do a code review not much at all sit down look at the code I one of my favorite code reviews that I ever did was was my very first one and we were looking at the logic for the login page and in the log in class there was a boolean is authenticated equal to true and then I went through a series of checks and if it failed to check it set it to false okay upside-down logic what happens if I break somehow in the middle

of that authentication process before true gets set to false it's true if I can break out of it I move forward okay that's the kind of stuff that you do in a code review doesn't take a lot of money to train it you just have to decide we're going to do the code review and then sit down and get it done okay security unit tests also need to be written at this point by the way I call out in in design phase I called out security standards an implementation I call out security guidelines standards and guidelines documentation if you're agile you're freaking out about this right and in most cases i agree however in an

organization that writes software as a main component of their business having written standards that say things like we will only use the following encryption would be a great idea drown how many people heard about drown less was last week right okay if you had a security standard for what ssl you would support six months ago what would your standard have set minimum level for ssl/tls 1 point 0 are above SSL itself no would you be vulnerable to drown now how many people have a standard for what level of support they give to SSL a couple a couple do there's a lot of value in writing those standards and also guidelines how many times have you

seen encryption implemented poorly oh I forgot to salt it right or you know just a number of different ways that you can break it up so having written guidelines and this is a concept that I've come up with called sdl in a box and I swear if I just had a year to sit down and do it I would wear you you know you could just inherit these standards and guidelines instead of having to write them yourself they're kind of out there the OWASP developer guide is pretty good a lot of the cheat sheets for OAuth spar great so that stuff is available really you want to grab it there are there these are just patterns right there just security

patterns instead of patterns for accessing a database or patterns for logging people in and so forth okay you want to write those down that's that's in a time sink but it's worth the effort it really is a verification phase this is where you're going to do feature level pen test so I wrote a new feature I'm going to give it to my pen test people to have them look at it do we pen test every single feature know what we do is back in the design or in the requirements phase and in the design phase we tag user stories that have security implement implications so we know when it hits verification that feature needs to be pen tested every

once in a while we want to do a full pen test we also want to do some fuzz testing a dynamic analysis this is another phase where I would recommend that you kind of break your shoe string budget pay someone to pen test your application a lot of companies will say well we've got a guy who knows how to do pen testing in house okay that's great how many hours are you going to give one of your developers who knows how to pen test how many hours will you give that person to test your app any guesses I mean do you think you could strip a developer away for eight hours how about for 60 hours okay it's not going to

happen so this is a place where I recommend making an investment maybe it's self-interested because I do a lot of pen testing but i really recommend that you bring in outside help for two reasons number one your internal staffing requirements will not allow you to dedicate the amount of time that needs to be dedicated to do a real pen test number two someone a pen test day in and day out will find stuff that your internal guy won't that's just the way it works so you know is how often is often enough annual is probably the minimal amount that you want to do with the third party and then depending on the sensitivity of the data you're in or

the regulation in your industry you might want to do it more frequently or a combination I have a lot of clients who do their own internal pen testing and then they'll have me do an annual pen test for them and that works out really well okay so you want to make sure at some point that you do some pen testing and this is where I would say you want to spend some money all right in your release phase again releases zero dollar cost to get ret to build into your sdl you just have to stop and think about it what are your release gates we talked about defining the definition of done up front this is where you make sure you're

actually done before you go out the door so you do your final security review you make sure you have a response plan if you've decided to use a vendor for Incident Response you make that decision who it's going to be make that decision here sign the paperwork here I did an incident response recently where I actually dug in and we we stopped the bleeding but their internal contracting process to two weeks and it just SAT for two weeks on hold and their CEO kept asking what's going on what's going on where we hacked where we hacked where we hacked and we saying they kept saying we don't know yet we haven't gotten through contracting so if you're going to

contract for an external people do it do it now before you need it and then monitor verification so this kind of weird concept for people that we might actually want to monitor stuff that's going on in production more than just who's clicking we're right we talked to product owners and their idea of monitoring is mixed panel whoo I know that users go from here to here to here to here that's great okay the real monitoring that you want to do is up time on your servers right because that's important if you're in IT and you're being measured by it but also you want to monitor activity and you don't know if it's going to work the you don't

want to find out whether it works or not when you push it to production so here's we're going to do your final verification of that and then you do really sign off ok this is process oriented this requires agreement if you're in an agile world how long does it take for you to say hey did all of our security user cases get executed half an hour someone looking at it right how long does it take to say we have a response plan okay well you had to write one and you might have to go and review you might have to spend an hour to reviewing it not a lot of time invested there and monitor verification that

might take a little bit more time that's some testing to make sure this monitor is going to work and can integrate into your organization interesting side note so I mentioned I'm working for a major financial firm we just had this big breakthrough because a person I went to high school with years and years and years ago well before there was managed code let's just put it that way is now a sim engineer and was just hired and we sort of just realized at some point that we were working at the same major financial firm which is kind of cool anyhow we were chatting and I was chatting one of my co-workers about how I knew this person who was a sim

engineer and he he was all exciting is like oh that's our phase three we really want to figure out how to tie our applications into the sim so it actually works so we want to build a living breathing almost self-aware system okay that's this concept of what's going on in your release face it's a maturity thing if you're brand new to doing a secure development lifecycle making sure your application team is writing to tie into your sim is probably not something you're going to do the first time out okay all right and then in your response phase here you know you might spend a little bit of money buying response tools the most important thing is to tabletop your

response exercise case in point this hack that happened a couple of months ago for my client the IT team had absolutely no clue what they were doing their response to their WordPress server being taken over was to reinstall from backup okay what did that do well number one it reintroduced a vulnerability that caused it in the first place number two it absolutely wiped out every single piece of evidence the only thing I could tell them was I have log data up until this date and I have log data after this date so clearly you were owned for these 35 days how no idea I can't tell you because I can't look at the logs because

you wiped him out what did they do I don't know how do they attack you I think it was this right so if you tabletop your response and include your entire response team it will be a good idea what will happen is your IT administrators will realize they're absolutely clueless about what to do during a response and you'll teach them the five things they can do to preserve evidence simple right your management is absolutely clueless they have no idea how long it takes I swear managers think we're going to call this guy he's going to come in an hour later we're going to know what happened right it's like I'm pulling my car into the the tune-up

place and then going to open the hood and connect a computer to it they're going to tell me what's wrong with it that's not how it works incident response takes a fair amount of time especially when you have either a lot of data or no data because with no data I keep looking and looking and looking and looking okay so you really want to spend the time to do a tabletop response how much does it cost for you to do that take an afternoon buy some pizza buy some soda get everyone in a room come up with a mock incident and then start talking about okay how are we going to where are the logs what logs do we have

what tools are going to use to go through those logs so on and so forth okay all right we're moving right along resources when it comes to the building in stl the whole I love Jax slide about standing on the shoulders of giants don't do your own sdl Microsoft has three different s deals that you can work with they have the microsoft sdl which describes how we built software internal to Microsoft I used to work at Microsoft on that they have the simplified sdl which is basically whoa that's kind of the crawl walk run approach simplified sdl is just easier and then they have the sdl a which is aimed toward agile sdl activities be sim

is a great resource as well and by the way all of these resources are free besom is it is really kind of the sdl that everyone models themselves after the nice thing is it's a maturity model which means you can rate yourself in maturity and figure out where you are so if you're just getting into it you'll pick their easiest maturity level and it's like two or three things from each category it's pretty easy to do it represents a great ramp up in your initial six months that kind of thing so besom is fantastic and then I mentioned safe code earlier safe code has some good documentation a lot of it's kind of a repeatable you'll see on on the

Microsoft stl and BCM but they have those user stories and those use of stories are really valuable if you're sort of a formal agile shop those user stories will really integrate well into the into your processes okay what if some other resources like I said best $300 you'll ever spend is burp sweet I've tried owasp zet attack proxy I'm not really thrilled with it doesn't work well for me maybe I don't know it I mean you know it's like it just reported my reformatted my Mac I've been a lightroom user for years and years and years I tried nikon capture for about 20 minutes and threw it out I'm sure I can do everything with capture that I do with

Lightroom it's just that I know how to use Lightroom okay or another analogy i used i skied all through my childhood when i moved to utah i tried snowboarding and I was like tumbling down these blue circle runs thinking to myself why am I doing this I just want my skis on again okay so you go with what you're comfortable with but burp is just an awesome tool owasp developer guide in the OWASP tester guide if you can read if you can have your developers read these or if someone can prepare training for the developers based on these documents you have gotten probably twenty thousand dollars worth of commercial training for free just the amount of time it takes to build stuff

you know build slides around it very very thorough resources okay and then the Microsoft file fuzzer is an example of a tool is available out there so if you have a web application that accepts file formats use the file fuzzer it will fuzz all sorts of different file formats for you and you'll find all sorts of great problems with your with your application okay so really the idea here is that number one in building an STL it's already been done it's already been thought of grab those documents read through them pick what works for you what doesn't work for you come up with a plan we'll talk about this in a second kind of a step-by-step plan to get to

the point where you're mature with your security the other idea here is that there are a lot of tools HP and IBM want you to believe that the only tools out there that are going to work for you are super super expensive and they come with a forced workflow process okay that's that's really not true they're good true they're good tools they were great tools before they got integrated into all the other tools that people want to sell you but there are tools out there that are inexpensive that work really really well or even free all right so kind of a wrap up slide here things to do yourself look you can do your own training right Oh

Hospital developer guide tester guide technet apple developer android java one of the things I was doing was writing the mobile security guidelines so I wrote over the course of the last few months 20 different guidelines that included sample code how to do things securely can you guess where that code came from most of it came off the apple developer website and off the android site and was then modified okay these are great resources to go for code when it comes to stl design we already talked about that tools we've talked about as well things to consider buying it might make sense to pay sands or someone else to do more advanced stuff or if you're

really really pressed for time and you don't have the time to do those basic fundamental training courses then bring someone in you can find people who come in and do that relatively affordably okay requirements you may want to consider looking to consultants who have expertise in an area that you're moving into if you don't have the expertise there it's not required again it's a trade-off between time and money I really feel strongly about static code analysis break your bank on static code analysis break your bank on pen testing have a third party coming into your pen testing right so how to get started how we doing on time poop scope your project what are your goals why are you doing

this why do you care about this figure that out to determine what your the how you're you know that you're building the right sdl okay if it's if it's compliance with a regulatory board then you're probably gonna have to go look and see what their sdl requirements are as opposed to we just want to build good secure code congratulations that's great okay maturity start small be realistic leverage existing knowledge and then the key here is to document it have it written down and have your executives by in on it and be part of it okay I wrote the most beautiful secure development lifecycle I have ever in my career I spent on a couple of weeks researching

it taking some of the expertise I had at Microsoft in other places and putting it together and it had absolutely zero support from management so it was shelf where don't don't do these projects without getting approval and buy-in because it's just a waste of your time you might as well game all afternoon designing and implementing your stl is an iterative process it's a crawl walk run process figure out what your goals are pick your framework figure out what you already do find your gaps address those gaps implement it and then do it all over again step by step by step eventually you'll come to a point where you have enough security and you'll know that you have enough security you'll

feel right about it management will feel right about how much time and money you're spending you that's when you know you've arrived at least for that week and then the next week everything will change okay so that's the end of the presentation are there any questions that I can answer yes

good and bad examples in a secure agile environment of what how to know when you're done huh that's a great question so the bad examples are easy the bad examples is our that you haven't measured anything the good examples really I would say are those teams that push user stories into their rhythm and in fact here I'll show you really quickly here so in agile this is the Microsoft diagram they have this every sprint requirement they have the idea of buckets so they got one time things that you do once for your product design they have every sprint things you do for every single sprint buckets that you do every once in a while okay a good

process is where you've defined those items and you're actually following them what those items are will change by team and by technology and so forth but that's the best really the idea here is that you're proactive and you've thought your way through it

Oh

I

mm-hmm

you should be up here it's great answer great answer good other questions yeah

do it recommendations in terms of technology or strategy or all of it that could probably be a talk in and of itself but first my first recommendation is do it and start with you know it's funny windows what's the default logging for windows logins what is it only log by default anyone know successful okay so my client got hacked what is the first thing I do I go look at the windows event logs and guess what I find nothing well all successes right I couldn't find any evidence of failure yeah so so log your failures they're more important they're more interesting repeated failures right or if you're using something like iptables and failed a man log your log things that break the

threshold things that go above the signal-to-noise ratio is that helpful it's a good start there's that's a long conversation we could have other questions so let me wrap it all up by saying what I started with I can't in an hour teach you what to do in your secure development life cycle because number one there's not enough time and number two it's different for everybody it really should be different for every team hopefully we had a really high level overview of what a secure development lifecycle is training requirements design implementation verification release and support right and then we talked about I tried to show hey look really all you have to do is think about these things and write down

your plan you don't have to spend a lot of money to get that done a couple of places where you do probably want to invest money but most of it is just stepping back and building an organized approach and the last thing we talked about were some of your resources out there there's all of this stuff has been done it's published it's free it's out there all you have to do is grab it synthesize it for your organization and get into it step-by-step crawl walk run into it okay hopefully I complished the mission and you feel like you're our was well spent if you have any questions feel free to contact me my email address should be on

every slide but it's not so we'll go back to the beginning here I unfortunately can't stick around today I've got some things I have to do at work so I need to leave otherwise you know grab me in the hallway if you could but my address is John info secured I oh and I'd love to answer questions I give away you know all sorts of information all the time because that's I like i said i'm a terrible consultant so hit me with an email hit me with other whatever questions you may have these slides I will be putting them up on the what is it join join in sight but also have them on my info secure site in a few days so

you can go there and actually I'm going to annotate the notes so there's a little bit more information some of the talking points that we had all flesh out so go grab the slides you know at some point and feel free to ask me any questions so with that word up