A Pentester's Guide To Left Shifting Security

so thanks for coming and seeing my talk I always find the spark of the talk the hardest part so I wanted to start this one with just a little story so I I went through this conference about a year ago maybe a year and a half it was good DevOps tastes like a really awesome event it wasn't an info set conference it was a DevOps conference so I went to go to gets very different perspective of things and that was a guy given a talk and he said who here is in security so I put my hand up so a few other hands go up around her around the audience and then I heard some from the back just go

boo and to me that kind of that told me what some of these other teams think about inverse act right InfoSec is often blockers we're there to say you know you can't go live or your application is broken or you can't do this and you can't do your job and actually I found this this image online I don't know who made it but it kind of it says something right even security these security as the bad guy so I want to try and think about ways where we could stop security from getting in the way stop security from being a blocker and tell me instead turn security into an enabler I think this is at least someone else's

automation because once we can start to automate security we can start to integrate security and when it's integrated it actually becomes a part of a company's ethos and their culture so just quickly I Who am I I'm Jamel Harris some people might know me as J I'm a pen tester for digital interruption so this is the company I started where but was saskia right here um we do penetration testing but also one thing we're going to focus on is is more of this on like deficit hawks type of approach to security so we're developing new tooling and methodologies developers can use firstly I'm interested in things like mobile application security I really like reverse engineering

software-defined radio as well I've given a couple of talks in SDR some Twitter accounts that I think are worth following obviously me but also mentis the gray hats so this is a group I run in Manchester where we put on you know kind of workshops are free workshops on all kinds of topics I'm gonna get a lot of help from Thunder Manchester InfoSec scene there which is pretty awesome we compete in cts we run CTF as well and then the ice security is that company Twitter account where we published our research and things so if you want to keep an eye on you know what kind of things we're releasing as a company I check that out I'm not a developer as

you can see here I'm mostly looking at things from a security point of view and thinking how can I use my skills to help development before moving into security I was a software engineer so I think that's maybe why I have a site down perspective compared to a lot of other other pen testers I speak to so why did I want to do this talk after speaking to some other pen testers and a lot of my friends they always tell me man I hate pen testing pen testing sucks I want to go work in Sainsbury's instead and I got totally get it because I felt this the same way after afternoon pen testing for a little while all right

it's actually really boring right anyone here there's an experienced pen decimos that we spent a lot of time looking at the same types of things there's only so many times finding cross-site scripting is going to be interesting and I really hate being bored and pen testing yeah it can be simply kind of boring um writing low-risk issues as well so when I'm on the test and I find all these kind of low risk you know head is not HTTP headers not set or things like that I've got to put those in the report and that means if the report takes a long time to write because there's loads of those issues which take them to the

next point with no one's gonna fix those right if you are the bad guy report these low risk issues um then they're not worth fixing as the pen tester I need to report those because there's still a risk involved with them so I need the brothers in the report need spend the time right in the report knowing that no one's gonna read it so that's like really the motivating ah so from the pen testers side of point of view we think that is kind of limited value to some organisations and the fact that we still have horrible software it proves that right companies are still getting breached even though they are fantastic so pentesting yeah kind of

coma sites from the develop their developers point of view again the reports get padded with these low risk issues so they're paying a small fortune to have someone come in and do a pen test and what they get back is you know a 50 page document that says we found that the cookie flag wasn't set or some very convoluted but I've an ability that's not actually exploitable because we don't understand the context of the vulnerabilities so when I'm on the test I might be there for a week maybe two weeks or something I don't really understand much about what the application actually does so I can only rate things based on my kind of experience at the time and that doesn't

necessarily fit in with the reality of what the organization needs so I might risk something as as a high-risk but actually the organisation might have controls in place it turns it into a low and I'm not gonna know that all the developers are going to see is a pen test report with a high risk high risk issue that is actually a low risk issue or it could be the other way around I might raise something as a medium and actually it's you know business critical to them as an example I was doing a test on a mobile application where I may have to disable this the security control that to me it didn't raise him that

important but this was a big part of how the company made money so once they saw that you know this thought that I kind of freaked out and I would have only raised it probably as a loan because it was very simple control that I didn't really see was doing much anyway there's a lot of ego insecurity and an info set um I was on site with a colleague of mine this was a few years back so he's honestly one of the most skilled hackers and pen testers in the UK but we were on flight together and blue balloons a code of view and he just starts kind of mocking the developer like artists developer you can't believe you had this

one ability look what I found blah blah blah and the devil sitting right behind us so again imagine you are the other developer you've gotta work good InfoSec and you're working with people like that you know we have a lot of video and we're hard to speak to and also I think a lot developers understand that I can't stop development right they need to release on time that is the priority when security comes in and says you can't go live while the developer says well you know what this is this is what's making the company money so there's always gonna be this friction between between pen testing so we don't like it as pen testers developers don't

like it I couldn't provide them too much value there's also this problem where people don't even really know what a pen test is and I'm sure a lot of people have seen maybe in an email or something ten test report with a capital P and as if it stands for something cuz I see a lot from them for my clients we've just kind of points out to me that then people don't actually know what pen test is right they just know they they need one I was speaking to speaking to this client recently and we were going through the Skorpion process and he said so how long will this take and I said oh you know he about five

days this is quite basic web app oh five days it's a long time so you just you say you press go and then you get the results back five days later I'm like no there's no there's no hack button it's like five days of doing things but he honestly had no idea what a pen test entailed I just he knew at least he had been told they needed to get one and also we can't even in the industry we can't always agree with what a pen test is in a red team boils down for an assessment you know these things if you speak to any pen tester they can have a slightly different way of thinking about

it or describing likely what that kind of test is so we're confused our clients are confused we say that pen tests don't really provide value they don't really want pen test anyway because of all the things I've spoken before so we're gonna just look at this fictitious company and a bit of a case study and they're called talk squared so they have a number of occasions I'm glad somebody got the joke so number of applications are web applications and one of them was breached okay well yeah they had a pen test so how could something like this happen if they have a kind actually they're secure then again I'm gonna point out that this is it's more of a fictitious bad thing I

mean [Music] sorry I mean I'm not reading too much about smoke here yeah but yeah I mean scope was actually a big thing pentesting is I'm actually a decided by the next time I do this um so fictitious company they have web applications one of them work was breached so they have a traditional development star right so they go through this waterfall methodology which I'm sure everyone or most people here will be familiar with basically we start by gathering requirements design the application implement it and then this is when testing so once the application is implemented and finished then they get tested now this isn't just security testing this is going to be Quality Assurance testing as well and actually

at this point sometimes this is come to the end because the company realizes they have enough budget for security so they can't even think but in this case that's kind of assumed that they do get a pen test and then only after that will they deploy like as I said sometimes in the real world there really isn't enough budget to complete the security testing which is a real shame so we looked at traditional methodologies and so let's look at what I would do in a more traditional type of pen test I would go on site like which I quite enjoy don't I get to wear a suit for like a grown up which is pretty cool um so I got insight

I then have to usually go to a reception and you know go through security get a badge then I wait my contact will come meet me and he will show me the toilet slop and where the coffee is I finally get to sit down I get I get my IP address but I need the test or the application or whatever and then I gotta wait for credentials and the worst I've seen this is I was on site with three other consultants we were there for five days which is a 20 day engagement and we spent the first three days waiting for credentials so the 15 days of the test on so we let credentials we do some

testing when we can wait for some more credentials test a bit more venti we leave and then we send a repeat the PDF report in the end you know with there's been a lot of time with distracting people writing reports et cetera developers tend to feel like this every time you find a vulnerability right because they just think they don't want us to find things so we're there every time we find something they know that they've got to address it or fix it or it's gonna affect their deadlines I'm just gonna make them look bad the companies are kind of throwing money at the problem and testers have large day rates um anytime we find issues the

deadlines get pushed organisation have to decide whether they accept the vulnerability or whether they know they have to need to manage it and etc they're just throwing money away but as a consultant if I'm fine from my point of view so let's take this company and say that we did with some pen tests and we found some vulnerabilities we have some critical vulnerabilities such as remote code execution or sequel injection you know the client-side prices are trusted so in this petition application let's say that is some kind of e-commerce site you know if this trusting prices from the client that that's a big deal and then you know a load of issues I would say a high risk

such as you know coupons might be guessable or likely sent occasionally some pages you know there's always a ton of medium risk issues not everyone him with Nessa agree that all these are medium but that's kind of on the problems right the way that I rate the run abilities is fairly subjective but I think about what I think it should be as a risk so but there are some techniques like the more objective so there's like cbss schools and things but then these have their weaknesses were they don't always capture the right details so sometimes yeah I might write something as medium when and other pen testers wouldn't or maybe I would even rate it as a

different thing on a different day you know sometimes it's just like poor you medium and then loads of low risk issues so we're gonna try and do is let's see if we can take these issues and see how many of those we can automate away okay or we can we can automate so that you no longer will find them during a pen test but before we do that hands up if you would have gone live with with this pen test report so if you had a application with all these vulnerabilities would anyone go live with it what hmm why not yeah and you know what there are tears I see that most companies they will go live when

they know that there are vulnerabilities because again you know they have to make money and making money is that priority which it should be it kind of makes sense so I've definitely been there situations where we've delivered similar reports to this and there's no choice but to our life there's always the idea that they will fix the run derbys fun business later but that rarely happens in fact I remember this one time I was doing a test went back six months later and did did another test for them I guess I'm application to have the same issues so um did you address anything in northern loss pen test you know what happened oh there was a pen test before

that so I think what happened is the teams have changed the PDF report that we send through which is why we do n tests normally must just got lost in someone's inbox so they had no visibility of that at all so they have no idea the offenders that even happened six months prior so the solution I think is we can't ignore security right that would be a problem so we need to pull it hand into the hands of the developers and the test is already in the team so we will left-shift it all right we're fine put your questions for the beginning of the development process so that's been mostly to testing earlier um so it's cheaper which is fantastic but

also there are different ways to test when when it's earlier so our for example unit testing and we look at that in a bit later but unit test is not something that I'm mentally gonna do as part of a pen test but it is totally one of the ways that developers test their applications so let's look at requirements and design part of the the design the methodology I'm kind of team putting these two things together but I think they're related so we're gonna see if we can integrate security in the requirements and the design part of the application development so firstly um I'll say is for some applications you might decide actually you don't you don't really care about

security and that's fine if it's an internal application maybe that has no user data or maybe only trusted users can use it it's probably I probably don't need that much security involved with it so don't worry about it focus your efforts on other things if it's a FinTech application something that's public something that handles payments something that's likely to be attacked these are the applications where we need to add more more budget to do security tests and do them earlier and you pro you the pen test as well in these cases but the the thing is it should be an informed decision to understand your application understand whether it should be tested or not and so I kind of like

how I try to put this in there a bit of a graph right so if there's something that's down here when the greenside forget about it um if this don't often what's more the red side you want to add more security budget more budget should be used for security only it's kind of relevant to each company's risk appetite as to where they want a place or application so firstly let's think about kind of the ways that we can discover threats you want to be able to think like an attacker so in the design stage we want to say say ok so how might an attacker abuse our applications and there are a few different techniques we

can use so we have threat modeling um this is where we start to decompose and understand the application where we want to try and determine the threats and determine the countermeasures that we want to do and this would be more like a brainstorming activity right so we'll sit down and try and and model the threats of the application think about one attacker might have to do where the attackers were coming from what assets are they gonna be after I really like abuse stories don't we like the name is weird after Google a few stories but so this is more like a in fact we'll talk about this on the next line so I'll come back to it one thing that I'd also

recommend is looking at previous pen test reports often times there may be some common vulnerabilities to an organization so if you're developing an application and you've had previous pen test on take a look at those try and understand those maybe there's maybe there's a library that has been used a lot that's introducing fun abilities or maybe there's too certain the coding practices that is kind of inherent within that company so if you can identify those by reading previous pen test reports you have another way of thinking like an attacker to try and improve the next design training of course if you don't want security training send your team on security so many developers and your

testers then they have that they would have an understanding of how how pen testing works and how security testers will go out looking for vulnerabilities and I will say what this might be a good place to to bring in external help but you do need to use external consultants these security firms do it right at the beginning rather than right at the end which is more traditional way you know have them come in and help you to to brainstorm threats to applications so with a few stories they kind of like user stories in scrum but more from the attackers point of view so we can say is as an attacker I want to login to the application

without knowing the password and you can document these and you can just get a list of as many as possible know as a type I want to to get free stuff or as intact there I want to change the ranking of specific products all right so we have a way of documenting the things that an attacker might want to do within the application and of course with each of these they can be broken down further so as an attacker I want to log into the application without knowing the password well we can prove force it right might be after you sequel injection to bypass the authentication mechanism maybe it as part of Reese reset for another user so these things

we've broken it down and again this should be something this was done with the team it should be done with a brainstorming session try to understand as many ways that an attacker might be able to abuse the system so in theory if we did this properly and then design your application based on this on abuse stories there would be no vulnerabilities but of course there will be implementation issues that we need to address later so one thing that I like is security requirements right I when applications of the birth they need to be this requirements document where they slay out what the application should do very rarely do I see security requirements added to that list

so if if we start at things such as web progressively over HTTPS this becomes a requirement the application so now pay a good application and application the meets the requirements a finished application is a secure application but we've added that the security requirements into what complete looks like and we can use some of the previous techniques we saw to do IP security requirements

so with security requirements we're gonna what we try to do is we define design problems early on okay so we've looked at their requirements the design stage we thought about how to try and add security for that about implementation how we're gonna try and add security into the actual encoding side of things I think it's really important to embed security knowledge inside the team again with training right so we if we have developers and testers understanding what security is they they have another kind of tool to be able to to use to detect for security vulnerabilities and they have the the knowledge to write good code write secure code herring is a really like this technique so with pairing you might

have two developers sitting in front of the same keyboard I'm actually coding together and if one of those guys or girls people if one of those I got thought of last time for using these guys so if those coders has security understanding then they will actually be able to must train the other one because you know so one person goes to write some code room for example this they are seeking judging the other person sitting there and sighs they were Beyonce RIT that's a fun ability there you need to change it this way then it's the knowledge kind of being spread within the team the advantage is once the parents are the pair's change now you've got two

people on Social Security and so that pairs will understand it as well so it kind of makes it the security noise mixes within the team the very very sort of non-threatening way security SME started matter experts actually I would like to see more companies hiring people to be the subject matter expert in the team so this will be someone that they can actually developers can actually go to the last question hey you know like what happens if I do this or what is what's the best way to do this or what's the risk of you know handing something this way so this is like it should be a dedicated role I think it's really really important rather than just either

happy to google it or guess it or bring in expensive external contractors security champions so this is slightly different from SME this will be someone's actually part of the team someone that's maybe a developer as well and and they're the person you're highlighting as the person that want to be more involved to security I think is actually really important because when I was a software engineer I was really interested in security and the only way I could really do security stuff was to comment on tester would it would have been awesome if they would have said hey you know what you interested in security how about your the security champion will send you to security conferences

would you know add training around security then they would have had my security knowledge inside the dev team which would have been great and I've seen not like I saw my friends as well have similar backgrounds where they were developers they wanted to do security stuff and the only solution they had was the content tester because where they work did not didn't give them the flexibility to do more security things security code review is a good way to embed security into the team so lots of places they will have some code review process before Cole gets checked in or used and if we're looking at that from a security point of view as well then that's a really good way to pick up

security issues and also to embed this ID of quality security quality inside the code base so developers were actually quite proud of the code they write and but one of the problems is that security has never really become a metric of quality for a lot of them so once that happens with things like code review then quite security becomes a measure of quality and then because I won't be proud of their code that will be a few around a bit is now understand secure ditches a bit more has anyone heard of chat ops before yeah so I came across this some reason I really liked it I worked at a place doing internal pen testing for quite a large company and

there was this there was a lot of developers use slack my turn to the guys in security and said is anyone here on slack and they'll be beyond slack there's just developers and you know the whole team is here anyway so we don't need to mic ok fair enough and I went on slack and I hosted more security questions in slack then I did any other way that was the assumption in the security team that if the developer had a question they would call us up or often as in that email or something but as he is they were mostly just asked the question on slack and hope somebody would answer it and by having someone in

arm in the slack channel who honestly security was he able to to really help them in a way that made sense for them and of course conferences I think companies are really important both from InfoSec so if you're working with developers send them to InfoSec conferences they learn a lot also I think I say if I set people to go to more developer conferences and try and you know it's great if I can talk to other security people about what I do but it's better if I tweet the developers about whitey and get them to understand why security is important um ok so developers they know they want to add security in develop is know have to

test their own code and there's this really useful technique unit testing where we write code to test our code I very rarely see security tests on a unit testing at the testing level is a shame if we can try and integrate secure testing to unit testing again we have a different way of testing for security vulnerabilities so what might a unit test was security one bit he looked like well given the attacker can submit a username and password when they try more than five incorrect passwords then they then the account should be locked so this is following more of like a bdp or behavioral drift and development approach to unit testing but we map out

our requirements that we saw earlier we can map those out to statements like this and when we have a statement like this we can turn it into some code now this is not good code it probably won't work really for the unit test but we can see that we have with setting up the application the way that we want with with doing some kind of action I found logged in five times and then we check if the account is locked so now we have a way that every time that application is built this test will run and the developer instantly knows whether there's weather updating is vulnerable to to brute forcing accounts and I think

the real part is here is that it is run every single time that the application is built so we've got some implementation stuff arm and what about moving off to the testing side of things why I would say is we have tons of Packer tools for hackers right I think we need fewer of those we need are more hacker tools for developers and testers things like birth suite and sequel map and and map awesome tools for a pen tester but they don't really make too much sense for for other people because they don't work in a way that makes sense for the way that they work like as an example I remember there's this open

source tool it's really cool I used a lot for in pen test and the company that created it they tried to make a pro version of it and they added they added a GUI on top of it as I think oh now it's a pro version for developers and no one bought it because it just it wasn't how developers wanted to use the kind of software and how they wanted to test test their code well they want isn't is more like this so it needs to be something to have an API that can be integrated into the build system so when the application is built with Jenkins for example with Jenkins think and then kick off scans correlate

results and then give back a pass or fail to the developer no they don't necessarily want them that has a command-line tool with a cool hacker banner in it and actually I did this a few years ago I took a pen testing tool I use quite a lot and I added a wrapper around it so that it could be run from Jenkins headed a plugin in Jenkins and this was actually kind of cool because what it meant is that when I built an Android application it would run these texts automatically and if the application had the run abilities the field would fail and I'd get kind of instant feedback about that and if the tool I found there was no run abilities

then that the potential passed in the application would build successfully I did write a blog post about this which you can see on my website I think we've actually expanded that since then and we're actually developing this kind of like larger tool around this we do have a web interface make things easy but really are the core of it is this API that means that you know the web interface might change maybe you can run it from Jenkins or you know you can write from online if you want because it's just the Web API but this is the way that I think security tools should evolve do something that is it is programmable some of that could be

controlled by an API because this is how that developers want to test their code in this how they can test their code so there are a few different types of security tooling sassed is static static code scanning tools so what they'll do is they will take a code base and they will just scan the source code what abilities uses pattern matching also my taint analysis where it says that here's the input here's the output and the input is coming from a web request in the output is going into a connector base for example and nothing's happening in the middle so therefore there's probably sequel injections so it will scan the application for or fun abilities but I can't stand the

source code Nick Jones guy we could talk about this at depth at Def Con a few years back and there's tons of tools that do this kind of thing but I'm 40 there's a lot of them are really expensive the open source ones tend not to be so great unfortunately then you've got that which is more dynamic testing so with with that this is running test cases against a live application this can be kind of hard to set up in a way because you need to have the live application there and working before you can start running the test cases against it but you know think about when you're running like standing-room birth suite for example or something where it's

actually sending off whatever requests to the application doing some tests and the same tape is up on a bit here these tools exist but they need to be made kind of aware of the application and they need to understand what risks are so it is and how the application works to to be really effective but they can be funny better for logic floors compared disasters and then I asked is pretty like a new way of doing it but this is cool it's kinda like that's where it's doing dynamic stuff but it's using instrumentation so you have an application maybe that's running and you will the the if' tools will hook it and then add security checks in on the

background the advantage is you can have your normal test cases running or you can just use the application and because these two what by cooking the application is running he is almost doing security test tests for free which is really awesome but there are some downsides as well so we've automated security all good we've got our that's my SAS tools we can finish right I'm 40 it's not quite as easy as that scan times can be an issue so I took a kind of a vulnerable application and run his app and burps we against it the scan times were not super useful took way too long something that's not that people don't really want to add that to their

build times I tried running the version 2 of but again it's the same application that found I don't think actually finished the scan it just didn't have a handle the app so I could be quite naive to just say run a scanner and you will get all the results you do get some good things right you say you do find a lot of stuff but it doesn't find everything and again you need to be able to tune the tool properly to really get the most advantage out there I've seen so many development teams just take this app for example and they just they just put a URL in this app hit Stan and then they

assume that's going to give them full cooperativity application in 8,000 it needs to be solved properly so they understand two authentication and you know in switch pages to use and you know all kinds of stuff they take a long time to configure it correctly and many dev teams might do that so our with QA testing again we can try and add security into this as well QA testers can be really good at automating tests but often they ignore security I was speaking to the test at once and she said to me I asked you know DeeDee security testing I'm as part of your mobile testing she said security isn't my job so okay well actually it's kind of a bonus job

interestingly I'm like a month or two ago she messaged me said you know asked on your own security is everyone's job and it's awesome that that that she thought you changed her mind and understand the security is totally accessible and it's something everyone is take responsibility for and it means that they can use the techniques that they use the tests to do security tests which again normally would just happen during a pen test and if we can we can use them to to help us with automated automating our testing as well so if we have the security requirements that we look at at the beginning we can actually turn these into test cases all right we

can we it will be easy for a QA test or easier for a th tester take these test cases and make a test and they don't actually even need to understand the ins and outs of security you know they can they can make a test case to see that will requests are goin over HTTP without understanding why that's important and what that means is these are going to be fewer vulnerabilities that I find in a pen test and actually I got this message from somebody recently I was Gabe a the torque at of the workshop our mobile application security testing at a conference good test bash and they ever talk this person actually they won't

even act my workshop I was just talking about security this for like days because honest I won't shop about it so I got this message from them and they said you know I found my first phone ability an application we were testing an application and I realized that it was sending the password over HTTP well you'll a school like this is not a super complex run ability but the fact that they are after listening to me thinking that ok security is not a big scary thing I actually managed to find a funny bit in one of the applications they were testing proved to me that actually this kind of approach can work and again it's one fewer thing I need to

write in the pen test rapport I want to try and minimize as much as possible we've spoken about applications all that infrastructure side well once we have infrastructure as code which is one of the keys to DevOps we can start to use some of the same tools we can use the SAS tools to scan all sort of the scanner code infrastructure code we can compare the configuration files to a good baseline and we can say you know we know this this service this service you only have what 80 open or 4 4 4 3 open or whatever with the config files that's used to generate that infrastructure we can make sure that that never changes if it does

change it can be highlighted it can be highlighted with an selected therefore all the odds person understand that there's been a change that is against the baseline if you can't do something like this there are other options such as using hacking tools like nmap vanessa's like we saw before you're right wrappers around them and try to integrate them into into your process but that's gonna have some challenges running these tools in a an automated way that's quick and easy to pass the results from this is harder than more about the infrastructures code type of thing so we instead that we've changed our security checks into something that's more like this alright so the developer would commit some code

so that source code repo and this will start bills that bill system might check for vulnerable dependencies right and then it will run some source code scanning stuff maybe the source code scan will actually run on the developers box as well so as they're developing in the IDE they get instant feedback about any security verses that introduce him dynamic tests might get run and may be that the volume it has only run once a week because they take more time but they can be run as part of the build system and only if all these things are successful the build gets deployed on in the point deployed in production so we have a way of pushing straight to

production which developers want to do we also have security in place so now security has become something that can help developers get into production with less risk it's also repeatable no these are these checks will happen every time that dedications gets built you know gonna have a pen test every time that liege in this bill so that working had more of this traditional approach around well as we're trying to move more into something like this but where does hem testing fit into something that is continuously being deployed I tried to do pen testing a company where they had a very agile approach to their development and they want us to pen test their application that changed every

week it was it was almost impossible testing became mostly just doing code reviews right to try and see what's changed you know how can we try and find some run abilities in this area oh wait note the codes changed again so where does like pen testing and things fit into actually this type of the saved well what I would say is remember this side where we said that some applications do require pen testing which is totally true I'm gonna say something that we pushed into our clients as well and actually there might be something in this room the dynast really agree with what I'm gonna say and if you don't want me it oh yes but if we

have this more our automated way of doing testing where security testing where we know we have a a known good application is going into production we might say that maybe every you know ex deployment I have after X number of months or something then we actually just have a tick box pen test now I'm a pen tester that's saying that in this case if all these things are set up a tick box pen test might be okay it's gonna be cheaper right because I don't require as many skills it's a good way to get new people into security so it's gonna open up a new set of roles where they go in and look for kind of

known issues they're gonna say it's more like a verification to say okay we know that these tools have been working correctly and there's been no big changes that the tools hasn't picked up or you know things like that so it's not about discovering new issues but mainly verifying everything that you know about is correct and again I think this is going to be a real I realize a real way to kind of change the way that pen testing happens but also I think what it would mean is that when the more experienced pen testers come in they can work in a way that's more like this right they can do more like a red team

continuous type of thing where we're not necessarily limited by to the scope of one specific application instead we might be monitoring an organization looking for in a book that one weakness that pops up at some point they can have like an internal security team this just content in looking at everything and being able to feed that back into the development process so they find you know this issue being deal not picked up by on the tick-box pen test will the cheaper tick-box pen test not be if I buy the tooling this kind of continuous style of testing we'll pick that up and they feed that back into the development team where they can fix it and this is

where you look for kind of more complex logic issues or new bones things that take a bit more understanding of security and kind of more experience in security and you need to be able to tie that all together all right so we have now we have security coming in but not just with pen testing at the end but we kind of coming in from the continuity running with the staffs and the desk to coming from the QA testers and more this red team approached our to continuous security as well and you know bug batteries might fit into that and security test cases and that was all coming into a central database which Jenkins or the build system is using to

to decide whether the applications should be deployed or not but in a way it will happen as it currently is a PDF that gets most in someone's mailbox and I think this is a way better solution so if I people say to you to me that won't work well some things they say is need to be a really leet hacker to find security probabilities and I think like that's not true right you can be you'd have to be very skilled in security to file security vulnerabilities checking that something is going over HTTP doesn't require lots lots of skills checking whether sequel injection lock fittings bundle sequel injection doesn't necessarily require lots of skills to understand it and to

exploit it and to you know take that and leverage and be able to do something kind of cool or something that's arm like shove off the the issue might require more experience but just don't detect it or to find it oftentimes it's just putting a couple of characters into a box and seeing what happens so automated test won't find everything that's true but I don't find everything either honestly if I've had a bad night's sleep I might not find some some run abilities if it's a new technology there will be things I'm just I've never seen before often I've seen juniors do testing like testing application and that's the only pen test that happens again that don't

have the experience to find everything either so it's okay to not find everything so as long as we can find a lot of things or more things than would happen without running it without going into automated tests then you can do them better either pen test to be secure well that's not the pen tester make sure you secure it's fixing the run ability so anything that we can do to increase the number of other bits we find early the better position we're going to be in and the pen test as I mentioned is only a point in time right so if we have a pen test and they fix everything that's cool but a year later they're gonna

introduce new probabilities unless they have a way of I'm continually monitoring for those new issues they can be in just just a bad position so that's it either not much time we got left 15 minutes okay so arm chapters yeah yeah I want to ask them any questions so could we still up that time so smokey someone any question yeah so it was that this one yeah so that yes there is um there's a really good one um I can't remember its name it's called okay so so that's like systems like that there do exist and thirty pieces one I've used in the past and I enjoyed it I thought it made sense but basically yeah is it it allows you

to quite easily write tools that will import into it and so everything is just in one central place yeah I mean so anyway that kind of make sense for the company I don't think there's like one answer it really depends on how the organisation one so the question is about how these these issues then get fed into the dev team yeah it depends on like if it is a large company is it a small company is it you know a dev heavy or they're doing other stuff as well I wish there's no really one answer you design some kind of policy that makes sense for that team the hard part is really to get the developers to be

involved with it I've worked the places before where you know they brought us in to try to help invest security into what the developers doing that is they want to but also they got stuff to do and any change is it's met with resistance because they just know it's going to take them time to to have to work efficiently so yeah well we did use threat fix it was really more about like this is now the process that there will be three things and then they get exported zero zero and then it becomes part of their normal while handling process to one issue that one thing I see a lot is that the PDF goes over to

the client of the phone abilities and there's no one knows what to do with it if we can start to treat them as normal bugs then they just get picked up and they get triaged and rated as they would with other other non-security but nothing that that's really one of the he's you know he everything gets fixed as other bugs [Music]

yeah i think i think i am empathetic I know because I've been there where I work so when I was doing my first internship I was doing development and I said to my boss I have written this application like you asked me to but it's not cross-site scripting in and he's like it doesn't matter I'm like what does another like Krypton is like yeah but to use it you've got to be on the secure network and there's there's like five users anyway so I just don't worry about it like oh okay that makes sense I think ever since then I realized that security is not the most important thing you know you need to understand the other factors

there as well security is super important but if it's on an entire network and evil to be trusted to get there then yeah there's there's more that there's other things you can do rather than certeyn a hack some brochure where website

okay so the question was the biggest barrier to seeing the stuff imprinted in industry um I think InfoSec the way that we positioned security we always say that you know you've got to be super elite to find security issues I think for the work I've done in the past where I've told people that that's not true has been where I've seen the largest impact where they can actually they have the confidence to look for vulnerabilities our team after digging like indium phosphate sometimes we can be very the vehm in us and it should be more us all right well over the end of the day if I'm up hired by a company I'm I feel

like I'm there to help make that product better I'm not there to tell them that they're wrong they've they can't code or that they suck is that I'm here to you know you guys do the Badminton really well and IT security really well so we're working together to make something good and I think once you start having a more of like just an ass attitude to things the knowledge starts did change so security InfoSec understands more how developers work and the Vipers on security so the question was about the layers of yeah I'm just wondering whether or not you kind of map these kind of layered security tests into the profiles okay I'm so I don't really

um one thing I try to say is you know understand who your but on sample your threat is you probably don't want application online does vulnerable to script kiddies or you know anything if you can find the front a bit about running blog sweet other people can do that too and if that is what your threat is for some organizations that's all they're worried about you know it's maybe it's like a 10 10 person organization where they just that budget is tiny just make sure that that's not gonna happen that's not you fine have run pups we get on the phones run a busy space and you're probably fine if you are more worried about that yeah I need to do more things

quick I've never really thought too much about like yeah so might better have a better you know the questions differs from yeah so when you're working with applications that yeah that you are developing in cycles where you're moving around lot really I think the only thing you can do is to try and automate stuff doing any kind of manual testing there becomes really difficult like as I said when I was brought in to do my new testing a company that was costly changing applications it was really really hard so said what they should have focused on is having asked worked with the testers that they already had that had the test cases that and a way of testing

applications we should be working with them to develop security test cases instead of having us coming in to do pen testing in it yes I think I think that's probably the more sensible approach if you have way of doing testing try and add security into those Rob will happen like a manual security test yeah the questions yeah good question so the question was about how clients react to have a new way of doing security stuff ah honestly that is one of the the harder things when we first ID'd with Rochon we as I said we're not gonna defend testing we're only gonna do this kind of stuff and I didn't last very long because I

love our I said oh we want a pen test fine we'll do it with the defenders um so I think we keep more people to talk about this and once it becomes easier to do it this way there's gonna be adopted the companies I've worked with where they have tried to do the stuff the biggest problem was not getting the technology as place it was just getting the developers to work in that way so that's why I needs to become from this like really embed it it's a way that they're doing so again with training with using the tools of they're familiar with I think what they don't want to do is have like all these new tools they need

to run if it's stuff that already using Jenkins Jenkins already kicking off scans and doing things then adding another one not the screws down is not really a big deal saying here's like this other you know here's this other tool you pull around the gates there because some pens have tried to do GUI to some pen test tool that best becomes an issue so yeah there is um companies are slowly moving for this idea but a lot of companies it's ready lots of the smaller companies they just they're told they need a pen test because that customer is asked for the pen test report and that's their driver hand security and for those described companies I think it's only

ever gonna be pen testing is the Cummins that really want to have a highly secure applications that might look like this so yeah good question honestly it's like when we slide like no pen testing we're not gonna do it yeah yeah exactly exactly what people to pay anything else cool thank you very much guys