Presentation -- Lock stepping the SDLC: A guide to securing your Agile development life cycle

so you saw me there you might want to go pick some locks or something it's pretty much the same thing so my name is Jason Gila I am a principal security consultant with security as we do penetration testing training various different other types of security consultant worse we're a small company so we tend to just basically do whatever we can to help our goal is always to get to help our clients improve their security posture so that's really our focus I'm an I'm a faculty member yeah so anybody works with my hands but if you do and you might see me in one of their forums they basically have it's like the decision support type of services their

main thing that they do then there's also consulting there as well I've been doing some type of IP stuff before were over 20 years so too long so there I think I'm still seeing this is so things I like to do I do a lot of open source projects when I have time which is also yes so but most of them is bright and code to break things so which is this button right you're gonna you're gonna write some code anyways will write some code to break into stuff so it's going to do but a lot of ministry is in suffer development so why is it important for us to be thinking about security during or like it is from the

beginning of the SLC I know probably everyone in this room really knows the which is it really comes down to a quality thing security testing is basically a specialized type of quality investment quality assurance so if we wait until the software is built and we put it out on the internet or even on the internet and then they're like ok we got this out of your time to sign up for pin tests that's probably the wrong way to go great we all know this so that's that's basically what we even start thinking about well how can we get this to work especially when all the newer cooler ways of buildings that had jobs become huge in the last few years and I talked

to a lot of attention to Reliance which as I had mentioned I when I stopped remember I talked to a lot of their clients in particular about their security teams are trying to figure out how do they communicate with these developers because there's these cultural differences right we have developers they have their timelines so now we're going madge allow it's like oh I'm not doing documentation I'm just I'm just going to build functional software and you just have to figure out how you're gonna test that and you know the securities that were like okay well I mean it's great for building this software and it does all these wonderful things but it still needs to be secure I

mean your application has customer data in it great it has sense of information in it or it's interacting the system system so it needs to be secure and so they're you know constantly butting heads so you might have there's different types of software but my Styles here's our traditional type which looks something like this is just a representation right so you have your waterfall type thing that happens and anybody who works in or as working corporate culture should probably very much understand that wanna be very familiar with it it's it's great on paper right it works really well on paper because you can go up to senior management you can say hey we're doing their requirements

require to them the requirements are done we have okay can you sign them off yeah we can sign them up and send them over it's security they can sign off on great watch the next step and that almost never actually works that way but that's in principle it's supposed to be very easy to understand that way agile kind of different right because now we're we're in this cyclical thing we want to do these spritz typically big range so we some groups doom for like a week two weeks couple months whatever but you're doing this okay well we're never actually done we're going to go through all the same basically if you look at it it's actually a lot of the

senior steps we have an alarm clock going around them over and over again so this is what a lot of dev teams are striving for they're trying to get into this sort of thing because it's it's not just a trend I'll say that right now if you read into it now I'm going to be going over the agile manifesto as part of this talk so you kind of get a feel for where your developers are thinking but it's it actually really does in their minds anyway helps them build better software faster pace so most larger organizations especially or they have some weird hybrid of the two right they're not really doing ads out there they're saying we're going agile

apart way there but there's still kind of really stuck in this they have to have their toll gates right they have to have a you know we reach this point in the development cycle and then we're going to stop and look at everything and decide do we really want to keep funding this project or not so they want to do that it's really hard to actually maintain a decent hybrid up because the these two different life cycles are just so different from each other they're opposite opposite ends of the spectrum so so security in the waterfall is really straightforward because we have these distinct steps and we know exactly where we're going to plug in okay

some companies still don't have that much done but it's it's easy they have an idea where they're doing it so when we're building requirements we know we send our documents off to security and they sign off on it when we are doing our design reviews we can have a security architect take a look at that security architect or security engineer take a look at it and sign up on it when you get into implementation we have tools that plug into the IDE that can say basically they're good quality checking tools like I said before it's quality assurance right so they can say hey yeah it looks like you are [Music] it looks like you are pending on two

strings and that there's a potential for of injection blockers right then you have your static analysis you fortify and whatever that's funny look over all your code dynamic analysis so on and so forth as you get into your actual testing phase and then finally you get your codes employed you set up defensive controls like laughs get your penetration testing done and that's kind of out that goes something like that I know everybody's is different but those that idea plugging all that in like that does that really actually work that job it doesn't really seem like there's a good way to make that just fit right it's a square hole round peg to the center so Agilent challenges so this is

this is some these are all common things that I hear from frustrated security professionals whenever when they're dealing with development teams that are just saying - how so new documentation developers have decided we're not doing any documentation anymore it's the finger barnacles not yet forget it you're not doing that all right so okay so now I don't have any documentation to review what are we gonna do that no tollgates so we're just going to keep doing this project until the developers feel like it's done is that how that works then so and also how do you have like if they developers are building something that you can finally do looking at it you realize whoa wait a

second you know you're using the wrong algorithms airy you're putting into the wrong system that's not no way that security got flaws all over you don't do you have a way that's just stop to say hey wait a sec if you can't move for it this is this is broke daily meetings so scrum meeting standing meetings daily I don't know I don't know about any organization you guys are in but almost everyone except for one because when I talk to that they actually did try to scale up their security engineers so they had one per development team I don't know how they managed to do that or afford it but in most cases that just doesn't scale

right we have usually depending on the company you might you might have a hundred developers and only three or four security people you could have 20 or 30 teams developing stuff and there's just two or three people to go around with those there's no way they can attend a meeting on a daily basis for each one it just doesn't scale testing every time to submit code mean so I know there was the talk before - started getting into DevOps and integrating testing on that I think that's possibly suggesting it was something like that so the manifesto this is the the agile manifesto that work and it's I think that any security practitioner who's getting into a situation where they're

dealing with an agile development team needs to take a really close look at this and try to understand it because this is what's driving whatever form of agile your developers of comp which they've started with something like this and east principles so that you can get inside their mind and kind of kind of figure out where do they come up with this what's driving the decisions that they're making to not do to documentation for example why does that seem so important to them so I'm gonna go over each of those I won't read another right now but basically the important thing that realizes it it's a we values all of this stuff on the right

over the stuff on on the left and that doesn't mean that you don't its am i right yeah I just realized yes so so we value these things over here over these over here that doesn't mean we don't do many of these things it doesn't mean that at all it just means on a case-by-case basis when we are making the decision on how to do something it's going to put more emphasis on the side that we value okay all right so first one here we want to value individuals and interactions over processes of use so a lot of what they do is a citizen pain we have this big monolithic process that we're going to

use to build something it involves going through all these design and design meetings and wakeboarding all of this stuff need to still do some of that they're not going to do away with it but they're also not going to have requirements documents that are distant so so we have individuals and interactions happening as a priority which really makes sense we think about it it's a social thing so we've taken we've taken a group of people just like us who are known to be consider themselves introverts and they basically made this decision of hey if we're really gonna build stuff right we have to do it in a social fashion we have to talk to each

other and that's why they have forced meetings on a daily basis so you think about that it's like well how do we get security to work with that we have to join the conversation all right you need to somehow get into those conversations made that if you can do daily meetings with them that's one thing hopefully that doesn't really come to that but it does mean that you need to be part of that entire development process security needs to be part of that Q is already part of it this should already be if they're doing it right your Quality Assurance should be part of those those teams and they should be involved in theirs because Q ATS know how to test

what's being built they need to know how to test it now this doesn't happen three months later when reaches new testing taste it happens immediately right right from the first sprint in theory so but it doesn't mean we don't use any processes or tools there's still gonna be processing tools involved a lot of those are going to be there to assist with base not we don't lean on them don't rely on those being the only things right so the the focus is on on those interactions now one of the ways that you there's a lot of mentioned user stories because user stories for those who haven't seen them before this is basically Halloween document and communicate things in the

agile scrum type of situation right so instead of having this big requirements documents that we try to update all the time we have a user story so the way these face of the user story is as a whatever role right I want whatever capability so that you can achieve whatever goal right that's basically how it works so an example of one and this is you know there's some basic when I came up with so as an admin user I want to see a timestamp log so that I can see who recently modified permissions okay and that's that's a Hoosier story it's a positive story of a piece of functionality we're describing that we want in our product in our solution is

this one also happens to be a I guess a security story right because we're talking about security role so this is one of the roles and one of the stories that you might want to try to integrate into a solution that's being put out there essentially there's probably a bunch of them in fact depending on what business you're in you might have a bunch of security stories that are actually pretty common you want them across all of the software development that's going on so you need to get those into their process these these they might have different ways of doing them sometimes people use software some groups will actually write them out on on post-it cards and stick them up on a

wall somewhere so you need to get into those another another consideration you don't have to do this but another will look at it if you're developers are open to this is basically it's kind of like sort of like a negative story of malicious user story right so what we're saying here is name we have some malicious of indicated user who wants to see what's in the admin log but they don't have the admin role so that they can you know see who's asked us something or use it to gain access or something like that so the way that you would want to present this is hey this is these are not regular user stories these are kind

of negative stories we want to make sure that this is not there's no way we're putting great protections in place so the purpose of these stories is to lead a conversation all right it's you're not taking you know twenty pages of requirements and then saying okay well let's try to boil that down to just one sentence that's it's not exactly what we're doing it's more - okay this is to lead a conversation for that time frame that we're working on this functionality it's a way of noting that and so there's going to be additional information that will be added to it other conversations other meetings might occur whiteboarding whatever so would you say it is a

mischaracterization republic's requirements like I have 50 of those and a sheet yep those are requirements yeah no it's not I don't think there's a style now it replaces the way requirements are handles food and and part of it actually goes into the next room so I'll go on to the next one errors if this leads straight into it which is we value a working software over comprehensive documentation so using those stories we can say okay and this is print that's coming up next over the next couple of weeks we're going to work on these however many stories maybe you're working on cysts specific stories and make sure that those work all right so we're going to make we're going to

incorporate those into our software we're going to make sure that I'm sure those were so that's that's kind of one episode the biggest thing I've worked in this environment the single biggest thing that basic does is at the end of every sprint you have fully working software someone's feet shirt may not it may be sprint but it didn't make it as a partial work-in-progress and hold up the release everything that's in there is done yeah and that that is huge for rapid iteration so we're saying hey we value working software over comprehensive documentation when we first hear this the first time we hear this we might be thinking oh this this is horrible I mean you know my

documentation how does anybody actually ever know what's gonna be done it sounds awesome we're making it up as you go great but it's the software itself defines what your glitcher building like that that is the product that you have defines it and the weird thing is does that's really always been the case in when's the last time any of you that worked on a big waterfall project have had this like where they have all the the DRDs requirements documentation all that and in the functional requirement specifications and then you get to your end of software and it's built and then you compare it back to what was originally specs and it matches perfectly and nobody ever updates that

stuff maybe it's time for this right so so although this like this is what I was saying the beginning this seems to make sense and it's easy to explain to people to do things in a waterfall way with all of the documentation but it saw them actually really works anybody who's been in software development pretty like the time and I have been in suffer design for a long time I haven't been in recent years but I've been through a waterfall of this projects and it's it's insane how much emphasis is on the specification in the documentation and all of that and it all seems to make sense while you're doing it but then look back at it later you realize this

stuff doesn't match up what we ended up building in the end is not exactly just an injustice anyway so there's probably a faster better way so and this doesn't mean we don't do any documentation that's not a report so you just still going to have bits and pieces of documentation they usually they be somehow tied to those user stories it's just not going to be written like a specification yes yes pretty much security plans so that's it that was actually a very valid point so the worst case scenario is when you have one group doing agile and another doing waterfall and somehow they have to meet they got an API that needs to talk to each other

or something like that and it's chaos and that's kind of what I was saying is it's really hard to actually make a hybrid of these work you kind of have to if you're going to go at Johnny a pre-image have to jump in and do it there's still there's no halfway I had one system completely went places the waterfall is all XML and the test plan was generated from the requirements dock and they had the match on for Sam on the documentation route itself and everything good a whole lot of comments they know it was traditional power quality work awesome didn't look like still like your partner's test papers like the fins pretty much generate auto

generated by script well it's not pretty much at home said yeah that's extreme and that's I mean that's where a lot of that adult and along with DevOps kind of head sports right it's this idea that we're going to define all of this stuff as much as possible we're going to start automating things right even evening solution would be truth a drought - yeah you want all this stuff generated you want to rename and exactly so how do we get the working software I don't know it's working for one thing I mean it's one thing to say hey it works on my machine right it's testing yeah so when as we're building the software we're also building the test suite to a

stop are you Steve huh and Steve talked before this one okay that's the idea so we do a whole bunch of testing we're going to automate as much of it as we can you know that makes sense to do so QA should be involves and security can be involved in that as well so part of that automating this if you have security stories in there it's up to partially in some way up to the security team help figure out how we're going to test these to make sure that you know authorization checks are actually being done on every single call it's got to be a way that we can test that and hopefully there's a way to make that

test right so that's really what we're after there by the way the biggest thing

[Music] yeah all right that's a good point so when you have when you have all that testing in place then making a change is less detrimental because your automated testing will tell you if it broke something and automated testing we're really awesome security because if you test robles automating you can see they're changing this role didn't affect the other one yeah that makes a big difference this one here I think probably maybe has a little less of an impact on security maybe I don't know I keep trying to think about this one so they value customer collaboration over negotiation and to me this sounds a lot like the first point which is you know this is really about interactions it's

about having a conversation now security is part of this part of the overall process of building the software it should be but you're also if suddenly as a customer right so oh they're great up goods here so so we need to is we need to try to figure out you know how do we how do we integrate it so how do we need to be treated as a customer or not as as a and as a afterthought that's that's typically what happens in a lot of scenarios as security ends up being the afterthought security testing is oh yeah we were supposed to do that I forgot but it really needs to be part of you want

to be part of the overall conversation again the other thing to think it kind of sort of is on carries security or the security party organization probably has a set of standards of baselines that have to be followed for various different things and you can get caught in a bit of a you're actually going to create more friction I guess if all you do is take those and say hey you guys need to do it this way right there needs to be a conversation there and you need to be part of it and this I think really Falls is in play with my talk isn't about that ops we just calls in the dev ops where we're security teams should be

involved in actually defining what that infrastructure is going to look like in the entire staff and set up on there because they can incorporate those in and you're basically enough your your baselines instead of being a document view reference that's sitting out on a portal summer it ends up being actually defined as basically as software's it's checked in the source control it's something that you can actually make changes to you need to change controlled fashion that's it's very strictly monitored everything so it's it's actually better for us that way okay I like this one so they value their dads I'm gonna Festo responding to change over following a plan initially we're thinking over what we're not going

to plan it stuff but you think about it we excel at this in our industry we're responding to change all the time right zero day comes out what do we do do we plan for that you know we didn't plan for that we work on the piles of tightness as security practitioners that's what we do right a lot of it is not really Tran so so this actually shifted in really both with powering cultures so you take that into account the fact that hey we're not we're not gonna decide hey let's totally plan on exactly what the software is gonna look like what it's going to do from the very beginning and then hopefully in 12

months when it's finally finished it looks like what we initially planned that's not in the old old point own agile this is descent hey we're gonna build this in iterations we're going to make mistakes but we have a we have a method to address those as they occur right we're going to big changes our requirements are going to change we're going to find out that maybe we start putting a couple of features on their product and then the feedback we're getting back from the people who are using it is how you know this isn't really work for us we need something a little bit different can you change this can you change that and you're actually

able to adapt to that adjust to it and you adjust all of your Testament working with so

so so how do we get from what we were talking about the waterfall to actually work inside of our agile type of cycles it actually it actually fits in just fine it's not really that bad and I talked about those these already so security requirements those basically we're going over the stories and building the stories and discussing them so at some point ideally what you need to be doing is actually getting involved in those discussions and maybe that doesn't mean that you're a part of those discussions every day you know that they're their daily meetings but what you do want to do is you want to make sure you've heard those discussion asked discussions as they pertain to security

requirements that are being built so if there is a security story that's being worked on in that sprint you need to have some representation of the table on that in all the dresses now goes into this question use it comes up as well what if I'm one of those in two security engineers and there's 20 projects going on there's no way I can cope with all of that so the compromise that it takes time to do this but the compromise that a lot of companies are moving towards for this is you basically have a security champion person I guess on those development teams so something over time you get somebody who's actually on those teams usually you want

somebody who's a little bit more senior our detectors up there who's already involved in those meetings count them be the ones who are looking up or for security scores so you kind of bring them into your fold and make them responsible for making sure that happens so in that that can take time it really depends on the maturity of the the development teams and I guess the level of understanding of security that your architects how does this work or not when you're making changes building off all good rum spread the ability system from Jack now you got a whole bunch of business requirements and know you're also layering on security requirements that this requirement space

and the whole process will say well can you make it yeah which oh I didn't need these well I think we've out these business well and so you're still you're still going to have some friction there there's still going to be at some level somebody needs to make the decision of what's the priorities right so did you have something that yes do you make the right a failing test and want happen so for example and start with the super basics I don't I can't talk about this perfect popular so just gonna go like seriously you have vacation and access control sure it's real that and then make them right at that step user age cannot access user ease data that's not

particularly onerous and if you get that in that early yeah has to be you have to get in at the beginning of this so it can't be a room we're on spring 20 we've been working on this project for a year and then we started adding the security but at some time at some point the currents have to be long enough basic self done they can't do to me to start well well here's the thing though so there are some features that might take more than one scripted or freely it just won't be in the product until it is and that's okay so as long as your software isn't already out the door and a deploys

are where real users are using it so it could still be we you can you can go through many Sprint's on a software project before you reach a point where you say hey this is great for primetime he's a quitter on the internet now so that's pretty much

witness the oh yeah okay so that's design review this actually is very similar the requirements and requirements in design you know kind of flows into the same sort of conversation in that job right so it's hear her story English hot water story okay well how we're gonna build that same thing with just security testing on there - you have your implementation so at some point during the cycle there - they're writing Capote well you can do their syntax checking in your code reviews as part of that you should already be doing code reviews throughout your dev cycles anyway so part of that code review you talked about security code reviews if that's something different or special

but it's really the same thing right it's supposed to be part of the same process and this is actually another good benefit to having your security architects actually know sit here they're certainly experienced that's your developer architects who are actually part of the development team actually understand enough security so that they know where to look or I mean they're doing a code review you're looking over is because it should be you're seen in people looking at making sure that people are doing things the right way and they should say oh you know we're doing a great database single injection law here and so they should they should be able to do that better than I do

QA okay so it's actually something that's not on here and I have been thinking more about it but hey there's seven else's dynamic analysis penetration testing so you can have your QA in here acceptance testing a lot of this hopefully is on you can take your static analysis I have dynamic analysis tools and those can be somewhat automated I mean there's usually a lot of setup and faults in them and rooting out your false positives and tuning and that sort of stuff but ultimately you get yourself to a point hopefully where where most of that is automated so winning would a build gets it doesn't necessarily have to be every single time somebody commits code and go through because those to be

pretty heavy but maybe you do it when certain tag is added or something right but the other part of this too is if you're looking for help on how to get more of this done manually but more than that sort of manual testing zone to a if they're already doing some manual testing or maybe they're maybe they're really tech savvy and they have they're using selenium and automated tools basically to do all of their testing if they're at that stage you can teach them how to find the security issues to Venus is not that hard to show a QA person how to look for a process scripting flaws it's pretty simple most the cross-site scripting clause can

be found through a lot and be found easily through automated tools and even on single page apps we talked about that last night if you're in the training last night even in single page apps if you have to either manually click through or you're using a tool that can activate all of the JavaScript on there then equal finds you can change it to find cross-site scripting Clause as well so that can be done so recruit your QA people and then you get into the appointment that that person's the same in you know I think the the main thing that thats different on here is see where I have this evaluation prioritization this is partly how I

manage out those things because we're there thinking hey we're working in cycles at some point in every cycle we need to evaluate what's all what are all the stories we have let's go that have those half-baked what so fortunately we have this ready to go what needs to come next and so there's these decisions that are means on script by Sprint cases and so there's there's basically this risk breaking activity that occurs so you need to be part of that because you want to make sure that your security features are high enough priority list right all of your security stories the other thing too is you'll notice that all of what's different this is also different than though they don't

find that same article at all is that all of these steps would snuff grace that gets thrown into consideration on their risk ranking and evaluation so when tests fail and you mentioned that earlier hooah tests fail that causes repercussions on the next sprint and that's what we want as security practitioners we want that to happen so as soon as something that's a security feature grace it gets back into that cycle into a window module it stops the deploy if you're doing continuous integration yes especially again if you're doing CI along with it do this integration if you have a test fail on it that's basically saying this is not ready to go so there's that conversation

with what we talked about earlier where in waterfall you have a link to manually emphasis whole meaning is it declines we finished our requirements phase now we're going to do the total need make sure that it can we continue to fund this and B are all the security requirements met that we need and that's going to basically happen every sprint so there it actually is a totally it's just not called a toll gate and the toll cave is automated it's when tests fail that feature is not going to make it themselves and that will pull the whole list so some takeaways for this one is if you're getting involved in with development teams are doing a drop don't

be a dumping on a roadblock if you kind of you know draw a line in the sand and say hey this is secure and you got to do it our way which is you know a very typical traditional approach to it it's not fun to work with these guys they'll probably ignore you so you really need to join composition that's what it comes down to you have to collaborate with the developers think if you don't write them at least think about the malicious user stories and try to figure out how we can get the developers thinking about the security features and functionality and controls that need to be in every single piece of software that they're writing so I mean

from the basics how are we doing the identification how we're doing an authorization chest how we making sure that all of our data is in a notice being sanitized properly so that we don't have injection flaws and cross-site scripting flaws and things like that test automation is an ongoing battle as it just tastes yes it can take a lot of time and energy and effort to make automation work but it's it's worth it in the long run especially if you're talking about like a larger project that's going to go on for a long time into your automated tests because you may have to dedicate people to start working on those and it's probably really good idea to collaborate with

especially QA or for automated testing QA some of some of these QA teams out there now I don't know how many of you guys deal with them directly but some of them are come up with brilliant ways of testing based so we tend to think of QA is or four years anyway the problem is the people who were somewhat technical but not really technical enough to be a developer so they're doing the testing right and it's it's said that you can put them that way but that's best best has been a bit of a prejudice I guess in history a few years and the reality is is their job is actually quite important and a lot of them have become extremely

good at to appoint the damn stuff to teach us so and that for example interesting whiten that those people have turned into quarters in your own writing the automation to do the test is that how that need another skill editor exactly so in a lot of cases if they are getting into the others just be able to exactly exactly it so they've learned how to code they learn how to automate tests that takes scripting skills right so triage your sprints repent testing this is really a thought on you know if you're going again in that case where there's two of me and there's a hundred developers you're gonna have to try to figure out come up with some ways to determine

winner you really need it because you don't want to be in every daily standing meeting just there's no way in the scale that this security champion and talk about that to get that architect or whoever to work with you and use the backlog I didn't really use that term earlier but basically that's that prioritization and evaluation step so as things basically is the list of things that still needed it out it's in that block okay so as you go through cycle stuff gets thrown into the backlog and the NICUs not necessarily address but it gets prioritize on the nests say all and that's that's really it so I think I finished my time for lunch if you have

questions I'm going to just let everybody go start eating and if you have questions all [Applause]