BSidesWLG 2017 - Kim Carter - Secrets of a Security Focused Agile Team

so so my name's Kim cutter I work as a consultant I do a bit of software network engineering penetration testing well I do quite a bit of sitting up and optimising a cross-functional self-motivating development teams certified scrum master i co organise a couple of the information security conferences in New Zealand a shaker conference in the OAuth New Zealand day so you've got a good contingent in here of the questio con organoids I'm a software engineering radio podcast host in war throwing a book series three-part book series the first two books are done by weighing in at 800 pages so there's quite a bit of content in there and so they focus on improving the security

statue of development teams in in lifting team performance in having us to create predict are predictable releases and helping us to yeah create maintainable and it was it an extensible code in ideally minimising surprises so the context of this talk is in the processes and practices chapter of the first book of my series so some context to set the stage so in the first book there's 30,000 foot view chapter in this chapter we discuss a sensible security model which is which was created by Bruce Schneier we discussed the flow of it we discussed setting up a development team or purple team so basically a development team that knows how to defend itself and attack itself so

that's all part of the development lifecycle in yes so the sensible security model basically is a there's five steps of really simple threat modeling so it basically discusses our assets a risks to those assets countermeasures to the risks the risks of the chosen solution and then costs and trade-offs and then we've take what we've learnt from the thirties are you also in the 30,000 foot view check but the whole idea is to get the developers to and get the heads out of the code step right back and to base yes so they can see the entire security landscape then we take what we've learned from that and then start to hone down on specific areas in the next chapter which

is a 10,000 foot view and then after they've got a torn chapter which we set up by a penetration testing distro I focused on carat Linux we had a bunch of extra tools and we configure some of the existing tools in there and then we move into the processes and practices section that chapter so in this our processes and practices chapter there's two subsections this the first ones are focused on the tackers and the second one's focused on basically your development team are taking the lessons we've learned from the attackers and applying them to the development team and then we move on to all the topic chapters there's two type of chapters in the first book first ones physical and

then people so in all the topic chapters we apply the sensible security model and in the second box covers VPS network cloud and web applications and the third book which I haven't yet started is going to be covering mobile and i-80 also that's the URL for it you can read it online for free or you can download it and pay for it so I've seen a lot of organizations now hire code monkeys rather than professionals so organizations reward those that complete features the fastest thus rewarding technical debt which in turn slows a professional developer down because they can't help themselves fixing and simplifying it managers see that code monkeys are pumping out features and see

decreasing levels of productivity from professional developer due to the increased workload refactoring and simplifying code monkeys code professional developer research is their approach rather than copy pasting from Stack Overflow which again takes longer professional developers creating maintainable extensible code the far greater quality than code monkey but it's unseen from those outside of the development team so sprint review rolls around new features added on top of professional developers code and a new features added on top of code monkeys code sprint review rolls around again stakeholders are happy with the features added on top of professional developers code but they're starting to no get a notice buggy behavior in the features that are added on top of code monkeys code and

it's becoming harder and more time-consuming to fix them so this trend continues to worsen so why would code monkey change when they're being rewarded for the way they work so scram without the additional processes and practices that I'm going to show you exacerbating the wall professional developer seems to be slowing the team down in clearly code monkey appears as a rock star and delivers as features much faster the actual truth is the opposite sustainability is a key principle of the edge our manifesto if we will reward the behavior that creates that we create a vacuum for professional developers so we're going to work through a selection of processes and practices that were birthday out of my own trial and error

as a consultant often call him to help struggling teams with their own performance and security issues so the caveat here some of these secrets are you may be doing already but in order to get the maximum benefits you really need to be doing all and and as you start to do them all you'll probably discover others as well so let's break some mindsets so how do we do this so remember at the start when I gave some context my first book covers I'm a chapter called processes and practices which has two subsections first goes through here the attackers think and work there other basically their lifecycle and the second is a collection of learnings taken from the attackers

but for the software engineers so in the book I discussed the attackers also known as the red team and both black hat and white hat how they think how they attack their processes and a sequence of events and their tolling and techniques so I took what I could from the red team and created a set of development related processes and practices so we then apply these development related processes and practices to your scrum team also known as the blue team or dad defending team and this is essentially what empowers and so so this produces a development team that's capable of delivering the sprint increment with security baked-in see it at the very beginning of the book

we discuss the specialities and required in the dev team to basically establish a purple team so you've got a selection of people in your scrum team and they hit and they need to have different specialities in order to create a successful purple team at least one of the team members needs to have an attackers mindset and be capable enough of producing a tech sequences this is often the security champion which we'll discuss soon so you bring the security focus from the most expensive place in the software development lifecycle often retrofitted at the end of the project to the least expensive place which is within the sprint and we make it as part of our dish definition of done so we

augment your scrum process with security focused processes and practices so on the right we've got our scrum events artifacts and transparency most of the developers in here doing scrum will have seen these on the left as the additional security focused processes and practices are they at weird so by doing this we dress we reduce the cost of finding not just security defects but all defects so this is the average cost of fixing defects based on when they're introduced versus when they're detected putting the practices that's finding the defects and the right order can reduce costs I can reduce the cost of defects by up to 100 times so what you see there is if you

find a requirements defect in the requirement stage so you're essentially finding in fake as its introduced it's got a certain cost so if that same defect is not found in fact until the architecture stage it's going to cost you three times as much to do so and Ageing see all the way through to post released where it's going to cost you 10 to 100 times as much just to fix the defect that could have been fixed when it was introduced in the same sort of thing applies for architecture and construction constructions a little bit less but still fairly big numbers to take faults at the stage with the least time consuming and costly to correct this is

just a graph of the same thing okay so you might be thinking this ends like madness so what can we use now to find the process for fixing defects and make it cheaper so just before we dive into the processes and practices remember we need to use a sensible security model as defined in the books first chapter so the idea here is the development can take the book and apply it to their to the way they work in to their teams

so here we create a Tom box team exercise which we identify and write down the air sets for your organization let me create a time box team exercise again because that's what scrum teams do and we identifying write-down risks to the assets are you just identified at this point you'll be starting to know your assets and understand the risks to them then we create countermeasure product backlog items so countermeasure PB eyes are like any other BB ID are the East may table independent testable they should promote collaboration and they must fit within a sprint by the time they're properly groomed your countermeasure product backlog items also need to reference the risk that I created Duty that's providing a context

and urgency information counter me to put it back log items are then integrated into your usual product backlog and ordered based on the risk ratings and it's discussed in the first chapter basically how you go about doing that so the fit modelling now becomes part of your sprint process now the following is some of the prices and practice I've found that when used together our then the scrum teams can become a game changer so first steps established a security champion social security chairman is a bit like a scrum master and that they're a servant leader in a mentor but with the relevant security skills they must be a team member so part of the development team

and not be external like part of a security team in coming into the development team to help so the idea is to find someone that really enjoys technical challenges and let them pull the roll on them rather than pushing the roll on because mandating roles doesn't work so well so the security champion will be able to bring change to within the development team and the organization handcrafted penetration testing so this is costly when performed late in the cycle but many times cheaper when performed within each sprint this the security champion can also help other team members up skill on that sort of thing and myself and other security professionals can help are trained the champions

there's lots of guidance on how to do this in my book there's also a besom OWASP Microsoft and Intel have a lot of guidance on this peer programming so two-brains on your codes not just twice as good as one especially when one has a security focus code reviews you can augment your usual code review process the likes of jeaious lending tools as part of your build and source control pre-commit if you're not already doing this and as a collection of static and dynamic analysis tools it i've elicited in my book that you can automate as well we cover techniques for asserting a discipline and inherently undisciplined languages such as JavaScript we cover flow and typescript and this gives us

static type checking which is the implementation of design by contract also known as DBC now the D is the D and the solid acronym now we can measure cyclomatic complexity and reward those who are juice it and then we move on to the consuming free and open source so this is in the and the web applications chapter my book now this is addressed by OWASP a nine of the top ten are using components with known vulnerabilities so this is often not thoroughly tested or reviewed it's often created by amateurs that can and do introduce vulnerabilities and it's also an attack an effective attack vector forgetting an attack as malware and others working systems it doesn't

undergo the same requirements analysis defining of scope acceptance criteria test conditions and sign-off that our commercial software does and some countermeasures on that also I'm Debbie Edwards from IBM I'm had an excellent podcast around us sitting up a a team that a committee that would basically look after the white list of external dependencies within a company or organization and I'm the idea of the area's each development team I really needs to have a person from that committee within team so that when they're working away within their sprints and they get road blocked well the idea is that they don't get roadblock so I when they need to call in a dependency and and they realize it's not on the whitelist

already they can get that specific person to talk to the committee or whatever and get it fast-tracked I get it put in the whitelist or something else find someone else find something else that's going to do the same sort of job rather than getting rather than them than blocking the team so this automated processes that you could run over your code base as well to check that no libraries I used that there are in the whitelist in other simple initiatives like downloading and reviewing packages before running them this MVM show to check for mbm hooks and being careful of doppelganger packages don't install nodejs the official way piping arbitrary script strictly from the Internet to your root shell was

asking for trouble now the tall and landscapes starting to fill out we've got NPM outdated NPM chick David which uses your package Jason and provides a get our badge informing you of out-of-date packages we've got to retire jeaious just been around for quite a while you can run that as part of your continuous integration it's got a chrome and a Firefox extension grunt and a gulp you know task of burping as that plugin in an online scanner we've got the node security platform also known as in SP which has a CLI a gulp task a code climate engine and get a pork wrist integration and we've got snake which is a similar feature set to NSP with a few

extras and a slightly larger price tag and there's some others so when you usually run your test condition workshop when the developer pulls a pulls the product backlog item into work-in-progress you start thinking about what types of testing are going to be most suitable and developers create test conditions so we've got given wins and ends for any of you that and familiar with these these are basically yes a you'll have one or two developers developers that will pull a sprint backlog item into work in progress and I'll sit around and crates missed conditions you Givens are your initial state your wins are changes to that initial state usually made by users and you expected outcomes of the aliens

they are pretty much helped as we're developing our software as specifications - they work quite well for that and you can automate them and we also create evil test conditions so basically just the same just for the security focus and the idea there is that if the developers are struggling to come up with tech scenarios because often developers do that's where the security champion comes in and can lead the rest of the developers by hand and teach them how to think offensively and after a while that does rub off test conditions lead into TDD BDD perfectly evil test conditions lead into security focused TDD BDD just the same so TDD test-driven development and here at leaf

oh I creates testable code testable code is not about testing it's about loosely coupled designs it should be easy to maintain but it helps us to to create a code that is easy to maintain streamlines continuous delivery allows us to make changes faster with confidence if it's hard it forces us to evaluate why it's hard and thus I reduce the code complexity and in here only forces us to embrace many good architectural principles and all with the added benefit of driving out security defects a totally as the codes being written and then we can throw that into our continuous integration which provides another continuous security g-major test speed and reward those who create fast running tests you know

traditionally penetration testing and security in general is often thought about at the end of a project unbelievably often once the solutions delivered and imagine if this was done with any other form of QA so what you've got here is you've got security defects being created by developers and it could be weeks days weeks months even years in some cases before those defects are found and for a developer to get back to that point to be able to actually fix the defect that can take several days often to unwind the architecture and all the code and work out what other areas are going to be affected by the changes that they make and also to build up the

context and their heads so that's why it's so expensive then so by converting that Eirik effort into something that can be used in parallel with development we significantly reduce the costs and lift the quality so having a solid purple team that's a development team with the security focus this far more effective then are then penetration testing at the end of a project so this all sounds great right but how do we do this so this brings us to secure aggression testing with SEP a P I and note go this is a proof of concept that I did about about 18 months ago and have since gone on to do something more elaborate for a large international

client and it's worked out really well for them so what we've got here remembering that just this is just a proof of concept I'm going to show you some proof of concept code in a demo so we've got two projects they're both Aiwass projects so most of us aware is that it's just nice to be intercepting proxy with a large collection of known defects and exploits for those defects also here's a restful api that we can use to program against and we've got no gate which is a purple node web application that comes with a set of tutorials covers the OWASP top 10 and it's got its got fixes in the code that are commented out in quite a

few places and it also comes with videos on how some of the attacks can be played out so I just took a note goat as the system under test and put a coat I say put a test on the Edit test the profile route and this was part of the proof-of-concept also yeah so I'm a second block our book is now complete so what I'm going to do is I'm going to try and take this proof of concept and turn it into something a little bit more consumable so that we can actually just the idea is that we can just consume it and do some configurations and get some security regression testing running over code bases without doing all the work

that I have it have had to have done Zep can be run heedless as well there's also a docker image for it and I set up a double a docker image for node goat as well so you can have those running quite easily together in the idea here is is that you put them into a nightly build so developers introduce a defect today they come in tomorrow and they're told that they've introduced a defect rather than waiting weeks months years until they find out that they've got a defect because the penetration testers found stupid mistakes that we as developers should have shouldn't have put there in the first place so I'm just going to show you some code can everyone see

their doc so we've got the so the zip target up here this is just yeah our system under test just made up of the HTTP protocol the config dot host name which is wherever it's running from in the port then we've got the zip zip zip target app which is made up of yeah similarly the system under test protocol plus the config dot CA post name so basically about what I'm saying here as as either of them can be running pretty much well anywhere now we've got some selenium code here this is proof of concept code it doesn't need to be here it's just to get up and running for this POC you can do all the proxying suzette

programmatically without selenium but but yeah this is pop code so this is the profile we are so what we're doing is we're going to be practicing this first request through zip in it you'll see something that it'll build up the site's tree over here we don't actually run this and we're just filling out these fields with these values and we've got fish hold yep so this'll it's threshold here so we've got a hypothetical scenario I'm a development teams taken on a brown fields project it's got three defects baked into it currently we want a passing test when we start and then they can start to whittle away on those defects now once they get moving

we've got a cleanup we've got some cleanup oh dear yes so this is just I wasn't using the mocker test framework I'm obviously JavaScript we create a new session once we're finished this is nice mostly so that you can actually see what's happening because I because I use this for dinner now for workshops and that sort of thing we also use as a proxy client so there's there's a handful of clients for don't languages that are supported so you can just use the client to talk to the zip API then we've got yes the most important parts in the succinct series if you can focus on the green function names they pretty much tell you what's happening so we do

a bit of spider in there we sit an authentication method and yeah this sit logged and indicator I think as a visual thing see it forced user mode basically means how when Zach comes across an area a route that needs to it needs all the indication to access it forces Zach to logon and then we supply their credentials down yeah and then we check under the active skin so the active scan is quite a high level skin yep so what we do is we run this active skin Oh couple minutes and yeah so this stuff here is just polling this tells us how far through the skin we are and then we just rights I'm now

results out using zet proxy caught HTML reports which you know it's support for us so let's run this now and I'll just talk it through so I've got the zip your idea and no go it's going to be you'll see it there so I just receipt reseeding node goats database here to a known state and starting node either no goat and just ran grunt air security did we know we're about to

yeah so that's just selenium they're logging in and it's going to go to the profile we're out and send some parameters through there and then we're under the active skin and now zaps active scanning the node application it gave us some feedback across there you you won't have a UI and a nightly build so we get feedback in the terminal as well and so the developers introduced some defects this tells us what's actually happening about to wait with a port and then it says writing report to tells us where the reporters and it says search the generated report for the probe a foot profile to see the seven vulnerabilities that exceeded the user-defined threshold of three so if we

open that report this shows us what those it shows us what the attacks were shows us the parameters that shows us the URL gives us all the evidence we need in order to I find with it defectors and to reproduce it and there's their existing 3d fix so I'm just going to yeah there's some information on the air if you want to use the POC on how to fix your core site scripting defects so I'm just going to fast forward dear okay so we've receded the database run the app again run the test

yeah the idea here is that the developer comes in the next morning sees the defects and here's the passing hours Oh ceases defects I reached the report knows exactly where to go to defects the defects and then I runs it again and we have a pass and resolve so that's that yeah and in the we see just their existing three defects that we had when we took over the brownfields our project no yep so here to set up in how to use is on my github in my book I don't think we've got time for questions but if anyone has any questions oh do we do we have time for not no time for questions

if anyone's got any questions come and see me afterwards Cheers [Applause]