Jedi Mind Tricks: Application Security for Developers and Executives

welcome to the second talk I'd like to introduce two Jedi Masters for today uh David Brook and Chris white guys Okay so we've kind of um written this talk in a way that it's kind of two talks in one so um I'm going to start off right in uh the first part of the talk here um which kind of talks more about working with Developers and under local management within um an sdlc so people are responsible for delivery and then Chris is going to um talk more about kind of selling uh and getting executive and and management level buying for application security and I guess that's why I'm in the t-shirt and Chris is in the suit today so we can

communicate well to our constituents exactly um and we kind of split it up like that because in our day jobs you know those are the the main areas that we focus on so I would work work primarily with developers and kind of within the development team and Chris obviously is a CTO of an application security company would work a lot with helping people understand how to get that kind of management level Buy in and ultimately spend money on application security okay so I'll I'll start off here so my name is David Rook as you probably seen on the agenda and on on the first slide there um I work as a security analyst for relx payments in

Dublin so my job is is for full-time application security so that would include everything from kind of getting management to commit to doing application Security application security resourcing as well as things like security code reviews threat model pen testing and so on um I guess a lot of people would probably know me be better as security Ninja on Twitter or through the security ninja website um I do a lot of other things as you can see on the screen there the the point at the bottom about a tool called agio that's when I'm presenting on this afternoon if you want to find out more about that so I guess this is my the agenda for my part of the tour and it's really

how can you work with developers and how can you help developers get what they need to help you so how can you give them the information the tools the processes that they need to um write secure code which ultimately is what you want to achieve and then secondly translating what I call application security alien into the business language because as much as I think most probably don't want to get involved with business language and business people they at the end of the day the people who sign off on just about everything so if you want application security resourcing you need money if you want tools you need not always money but you need you know the business to accept the

cost of putting those things into a development life cycle for example so again it's more of taking the things we talk about and and figuring out how we put those things into into a format and definitions that the business cares about so firstly from my experience both at relax and and other places and conferences and so on um maybe that the first bullet point there is not completely true most developers don't come up to me and say I want to write secure code but what I found is i' I've yet to come across a developer who's told me they don't want to write secure code so it's not like you're fighting a completely uphill battle with the

developers um but what you need to understand is that you need to own the application security problems for them in in some ways it shouldn't just be a case of um producing a list of vulnerabilities and then giving it to them and walking away if your job is to produce secure code and secure applications you need to help them achieve secure code and just giving them a report full of vulnerabilities with severity 5 or whatever it might be doesn't give them um a feeling that you're you're as equally eager to get that code written securely as as you want them to be so when I talk about owning the problem with them I don't mean writing

the code for them but I mean help them understand the code they need to write to fix the issues you've come up with and if developers need um a process surrounding that so whether it's you know the fact that you have to get uh security ingrained in the sdlc maybe or the fact that if if things like security uh requirements aren't in requirements document in documents sorry then you could still actually argue the developers is doing their job if they don't write secure code and I know that sounds a bit confusing but if we don't have Security in there as a requirement because we haven't owned the application security problem then they're probably not going to write secure code and

something Chris said to me recently to along a similar vein there was that if they did go and write secure Cod then arguably they're not doing their job because they they didn't build the application as per the requirements and the design that was signed off so owning that and making sure they have everything that they need in place to write the secure code is is vital and um what you can also try and use is developers generally like to write quality code not all of them cuz we've all used products which are are far from being a quality application but in general I found developers like producing something that is quality something that they can gener be proud

of and you'll also find a lot of businesses want to produce quality products now if you can work to in some ways change the definition of quality within your business to include security um then you can use that because if the developers want to write quality code and you can include security as part of quality I'm not saying that the same thing but if your definition of quality or or probably more specifically a good application and your business includes security then you'll find a a lot easier to get them right and secure code and then finally what I found from developers is they want the right knowledge the right practices the right processes and the right tools and I know

in some ways that probably sounds a little bit obvious that they want the right knowledge but then for a second think about if you're a developer or a security person how you do secure development education or what if you're a developer what developer education um programs have you been subjected to to I use subjected as as a word there specifically because some are terrible and they don't give the developers the knowledge they need and that's kind of this comment recently I saw on on a Blog that I was commenting on kind of really reinforced that uh with me that this guy Jim Bird come along and he said look in the context of talking about getting

developers to write secure code that's what the blog was talking about he said that he's a software guy and what he wants is he he wants practices and tools that actually work so not just saying oh yeah we'll follow the Microsoft sdl because that might be great if you're Microsoft but if you're a very small company that probably doesn't make sense so making sure that whatever you're putting in place will actually work in your environment and more specifically they must help him get him help them get software out of the door better software that's more reliable and more secure so what can we do to help developers so and we do need to help developers because ultimately they're

the ones will who will determine whether your application security program produce it secure code or not because they're the people writing that code so and then the first bullet point again to me seems like one that's almost too obvious for me to put in the presentation but I'm saying make sure that you help developers understand how to write secure code and again think back to developer education things that you've seen or you've been through and how many of them actually taught you how to write secure code so if you've gone on secure development training courses or whatever it might be how many of them sat you down and actually taught you how to write a secure code in my experience

and from seeing what's out there in the marketplace probably very few of of um the developers who we want to write secure code have actually been taught how to write secure code we teach them about vulnerabilities and then we get them to exploit it in something like web go but then we hope that from there they can kind of figure out how to write their secure code or if we do cover secure coding it's probably for maybe 10% of the time whereas the other 90% of the time we're talking about vulnerabilities and exploits you need to really think about the way you're doing your training and figure out whether you're trying to give them uh a web app

pent testing kind of 101 course or whether you're actually teaching them to write secure code and really if you if your training doesn't include some element of secure coding then your developers never actually going to write secure code because you've not taught them what they need to know and then just to reiterate the point about owning application security problems with them make sure that rather than being seen seen as an auditor within the team that you're seen as a teammate that you're as equally concerned about getting software out of the door you've got your own agenda obviously it needs to be secure software but understand that the thing that I guess drives their bonuses and their

performance reviews is whether they're getting C produced on time if you show concern for that and you show that you're willing to help them do security right but also meet their deadlines then again from my experience that's been very useful and then the final point there is is is very important um don't dictate to them don't go to them with the attitude of um I'm the security person I know about these difficult security problems so I'm better than you um we might not all do that but there are load of people in security do have that attitude who go along with the I'm the security person you must do what I say and don't ever dare question me but

the problem is on on the flip side we're talking about development which means that they actually probably know more about actually writing a piece of code to prevent the issues you're finding than you do so in some ways they could come with that smug I'm better than you attitude as well but from my experience they don't tend to they they mock my code because I'm not a developer and I write code but not in the same way so rather than dictating to them and say you must write secure code speak with them um and help under help to uh learn from them as well so you can learn from each other but then finally when you

learn from them the things you get back from them try and use that information to improve things for them and one example of that at relx was that we spoke with our developers cuz one of the things we did is the security staff for application security sit with the developers in the same team same managers so we we just um the same as those guys in terms of our per uh performance as a department is measured on getting an application delivered on time and security is just part of that but to improve things we spoke with the developers about security testing and what they said was that when we go out of the development phase we've done some

level of kind of functional and QA testing so we at least know our code works um it it it it's somewhat um a way towards doing what it's supposed to do but the problem is when when we look at security testing we've got no idea what you're going to find two or three phases along in the sdlc which is a problem for us is there any way that we can start doing some security tests in ourselves just the same way as we do functional and kind of regression test in ourselves as well so we took that away and we we we had a think about how we could enable that for them and and to cut a story

story short the approach we took was in the the threat models the security staff create um kind of at the design phase of the stlc we write very clear security test cases now really clear um whereas before they were used by the same security staff a lot of the time so they they weren't that useful to developers but now they're very clear and then what we did is we invested in in a license for burp sweep Pro for every one of our developers so all security staff all testing staff and all Developers have a copy of this tool nail um on their desktop and they they're given for every single project the test cases that they

should probably run based on the threats and the risks we've identified in the threat model so again it's a case to speak with them and and learn from them and then improve things from that so then next up is is like I said what I call application security alien and I guess when we talk in terms of things like injections and jackings and pings it probably makes sense to all of us but ultimately all of us in this room and probably many other security people we're not generally the ones who sign off checks we're not the ones who make commitments on fixing these issues if those people don't understand what the hell we're talking about they won't sign

the checks for tools they won't sign checks for resources they won't accept the cost of adding all these additional deliverables into their sdlc if you go to them and talk about these three things then they might think more along these lines you know we're talking of injections and and jackings and ponies so uh if if if in their head if that's what your findings look like um I don't think you're going to get the the commitment you need from the business to address your issues so there are different ways of approaching this so I guess what I'm looking at here is more of um how you get kind of delivery managers or whoever's responsible within like thec for getting

code out of the door how do you get them to fix issues you find um Chris is going to cover this a lot more in in his slides of how you take that upper level in the business how do you get management and kind of um SE level people in the business to actually sign off the checks or to even say look as a business as a whole we're making a commitment to write secure code from now on um so it the the things talk about is more kind of aimed at convincing a project manager that he needs to delay his project for a week because the issue You' found isn't well isn't a a golden

My Little Pony but it's actually something that could really be a serious issue for the business okay so it's following on from that a little bit as well as we kind of sometimes te speak what outside of our community a weird languages um but we then sometimes present those things in in weird formats as well formats that again may make sense to us but again we're not generally the ones making the final decision on fixing these things or invest in application security so something that I've spoken about quite a few times uh particularly on Twitter is CVSs and its use um as a way of scoring vulnerabilities can be useful um in certain situations but probably outside

of the applicate or not just the application security but outside of the security team your findings will probably make very little sense to the business so let's take a look at a make believe SQL injection vulnerability and this is the CVSs calculator which if you just you know Google for CVSs the website has got a lot of good information on it I should say I'm not saying CVSs as a way of scoring vulnerabilities is bad I'm just saying that it's not probably the way you want to then present the real risk of these issues to the business so using the calculator you have like a base score so you fill in the base score which is

mandatory and then you have environmental and temporal scores which are um which are optional so you can fill those in they're all put together and they give you a score in fact they give us you know a few different scores as you can see there but what it's telling us is that our seet injection vulnerability which from filling these fields in is exploitable um via the network needs no authentication could lead to a cast catastrophic loss of data to the business um for up to 25% of our systems and a few other things there and that gives us a score of 2.2 now I don't use CVSs very much so I really couldn't tell you what C 2.2 means I certainly

what I could tell you though is what 2.2 is a score in terms of risk means and relx it means that that's never going to get looked at and I'll show you why in a second because you need to look at well before we move on to it I just wanted to put these in in here how those scores are calculated so how do we get to a score of 2.2 well this is how we calculate the base score which for us was 8.3 and then we throw in these as well this one's actually probably the simplest one temporal equation and then the environmental equation so I looked at them and I thought I I'm actually not

even going to try and figure out how we got to 2.2 there um but we did we got to 2.2 but the thing that you need to look at is 2.2 might make sense to you in terms of understanding the vulnerability and how How likely is it to be exploited for example and what is the impact of it but if you take that score of 2.2 to the business does that make sense to them we'll look at in a second why I think sometimes it won't and then again sometimes as a as a community we're sometimes guilty of a feeling security should just happen without really having to justify it because XYZ company got hacked last week we we might use that as

a as a a lever to try and get us elves certain Technologies bought or resources and so on so what you again need to understand is what's important to your business and and then use be realistic about what your expectations are for security and use good justifications and again Chris is probably going to give you more more of a bigger stick to go and beat certain areas of the business with in his talk his slide sorry than than mine so ultimately we need to take this information and we need to speak in in in a business language or or more importantly a language that your business cares about so it will differ from from one business to another but in

general um a lot of things will apply regardless of where you're working so firstly you need to talk about things the business cares about they don't care or even know about in my opinion probably rightly injections and jackings and ponies or if they do we saw what those things might look like in in their heads when we tell them about it which means that if that's what they think about it means you're not going to get what you want so you need to think about what does the business care about and why should it invest in security so they don't care necessarily that you have a secret injection vulnerability but what they do care about is things like less

loss of x% of Revenue and Chris will give you more concrete information of how to start putting those kind of figures in front of Executives in in a short while but then you also need to look at things like you know businesses really care about damage to Brand massively care about that probably even more so nowadays than they would have a year or two ago with things like social networking you know if you're breached you're the news of Twitter in security at least for for a day or a week and you're the example that we always Mark until the next company comes along as as hard as it sounds that's the way it is and you can you can use some of those

things as real world examples I mean look at RSA for example now I think if you Google RSA security last week at least I think about half of the results on the first page of Google or about them being hacked you know that's not you know using food or anything that's actually taking a real example and saying to the business you know we're not maybe as big a brand as RSA but look this is what happened to rsa's Brand after they got hacked um then make sure that we present findings um in a in a format that makes sense and it's important to to think about a format that makes sense to the business rather than necessarily to us

because the CVSs might make sense to some of us but that doesn't make sense to the business so we need to translate that into a language and a format that they care about and Mak sense to them so one of the the biggest um things I figured out when we were trying to really ramp up application security relx a couple of years ago was the most important thing I ever did was understand how the business SCS risk and what we found was that the business in all the other areas of the business whether it's resourcing in projects whether it's operational whether it's Finance whatever it might be they all scored risk in the same way the the

rankings were slightly different because they had you know um definitions specific for a project so you know this project might sleep slip by five weeks or from a finance point of view it might be losing 10 major customers in a month but then our security rankings were not even anywhere close to matching up to what the business spoke about and what they ultimately made decisions space time so let's take that same SQL injection again and look at look at it in terms of a much simpler but very common way of scoring risk you know probability times impact it is a fairly simple way of scoring risk but if that's the way the rest of your business scores

risk then that's the way you should at least present your findings to the business I'm not saying dump things like CVSs I'm saying when you take that data and want to get the business to look at it put it in a format that they they use they care about so if we look at this if we take we were just making up numbers here I guess to some degree we give it a probability of three which might be this happens every 6 months uh and it's an impact of five cuz we're saying when we put it in cbss that it's a catastrophic loss of data it's up to 25% of our system doesn't require authentication

and so on so it could be an impact of F and the impact part is really where you need to work with a business and understand what an impact of five means for them so an impact of five for finance might be loss of a million pounds of Revenue or might be losing the top five customers all within a month you can put a security definition in there so it might be someone on exploiting the SQL injection vulnerability and dropping the whole of your database or stealing the card numbers or whatever it might be in your business as long as it makes sense and the business accepts that yeah that's a five then an impact of five

makes senses on whether they're looking at as a a finance risk business risk an operational risk or an application security risk and if we look at this here we get a total score of 15 the business has an appey of 12 so we're immediately getting their attention if you go in here and say it's 2.2 they'll look at that and say that goes to right to the bottom of the pile and we'll get to it if we address these other hundreds of risks we've got so ultimately you need to speak their language um not all of the time because I don't think any of us could really cope with doing that all of the time but at times where you want them to

make decisions uh make decisions that you want them to make make sure that you're giving them the information that they need in the format that they want to see and then ultimately understand that application security or security as a whole is no exception when it comes to resourcing it actually doesn't really matter that there's you know the trouble we have with the economy at the moment um regardless of that there you need to justify your resources and be realistic with it don't if you go away from here today and you you look look at your application security program or Implement one then you'll probably find hundreds of issues if you go to the business with a list of hundreds of

issues long they might just look at that and say that's too big for us to deal with or you might look a bit like the boy who C wolf so again be realistic with your expectations score risk and score those issues in in terms that they care about and take your most critical issues to them um and then you might start to see things being addressed and then ultimately try to keep everything simple what I try to do whatever I do with application security is follow the kiss principle so keep it simple stupid or keep it short and simple depends on I guess who you're explaining kiss principle too um and just try and keep everything as simple

as possible it doesn't matter I suppose in in how you do your analysis and how you come up with your results you can do that however you want but it's how you present that out to the people you want to make decisions try and keep that as simple as possible um ultimately speak with your developers and understand what they need to write secure code it it isn't just a once a year um refresher on what the OS top 10 is it's much more than that but you need to understand and listen to what they're telling you they need to write secure code and then lastly you know work with the business understand their languages understand

their formats and understand what they actually care about okay so I'll hand over to Chris now where he he'll kind of carry on up the chain within the business so thanks sta some to you um so if you don't know me back in the 9s I was W pond at The Loft and I was sort of on the offense side doing vulnerability research um writing tools to hack systems um but now I have a professional PR team I've which means that you know I can win Awards now because if you don't have a professional PR team you're never going to get these right um and uh you know my job is basically to help people

um write secure applications put together application Security Programs so their organizations can produce uh secure code whether internal or uh they're a vendor and they're selling that code so you know why do we need Executive buyin is because to do application security we typically need resources um we need tools um we need training um and also it's going to have an impact on the business it's probably going to at least in the beginning change change development schedules um and uh we don't want it to be voluntary right we don't want some development teams to say we're going to do secure code and another ones say it doesn't really matter to us um if it if

it matters to the business it it can't be voluntary so because of this we're going to need money and we're going to need um Authority or it's just not going to work so this is why we need to get executive Buy in we just can't get Buy in from the development team so it's really a top- down and bottom up uh process to get uh application security uh working within a business so the uh David talked about uh you know speaking speaking the language of the business and I'm going to make it even more simple here this is the language that CEOs understand CFOs understand and cios understand it's very simple speaking the language of the business

means putting things in monetary terms um this is how Executives think how am I growing my business how am I growing my top line it's dollars right it's not like how many states am I in how many countries am I in it's how how how how many what's the revenue number of the of the business um when they talk about lowering costs obviously that's money too but mitigating risk they think in terms of dollars when when we think about mitigating risk it's really it's it's technical what is the likelihood that this is going to be uh exploited or you know can I make it so that the impact is less um and and and we speak

in technical terms they speak when they talk about Executives talk about risk it's almost always translated into monetary terms so we have to figure out a way to translate this into monetary terms or it's not going to make sense and um you know David brought up some some points of like you know what is the LW sales going to be you know it's got to be translated into some numbers so here's some other examp examples of areas of risk in in that that Executives need to think about they they think about legal risk right when they're doing something um that uh you know might might be risky from a legal perspective the lawyer has his own

language or her own language that they speak in um just like we have our own language but at the end of the day so that executive can make a decision on whether to sue someone or not not not uh run some part of the business because it's too risky from a legal perspective the lawyer puts the risk into monetary terms what are the court costs going to be what is a potential fine going to be what will be the settlement costs of of this so the legal risk gets translated into monetary terms same thing with uh compliance risk there all kinds of different um things you need to comply with um um employment regulations environmental regulations you know we we

think about compliance as you know all it Focus but there's a lot of compliance that businesses have to deal with and if they're not complying you know um what's the Lost business what are the fines that's that that that's what it comes down to and and um even even fuzzy things like brand risk marketing people translate this into dollars what is my lost uh business um going to be um because our brand got tarnished somehow you know we're we're getting sued by the government you know we're we're seeing we're seeing we're measuring how that's impacting uh the business to the to the brand risk so for security risk how do how do we do what these

other professions are able to do right um they're they're probably uh more mature as professions but they figured out a way to communicate what they want to get done and what they think has value to the business to Executives so um one way that uh this is a model I'm working on it's obviously not not um perfect um this is a challeng in um thing to do but translate technical risk into into monetary risk using some data data sources that are that are out there so to actually take you know the the technical risk which is those vulnerabilities in your application portfolio um because speaking at a high level here the the business cares about

all its applications not just one which a development team might care about um and look at expected loss derived from those vulnerabilities threat space data out there um and actual breach costs so um breach costs is something that um there's really not enough data out there um if your organization has been breached before you can you can use that you can understand um what your costs were you know what were your fines what was your remediation costs um things like that and translate it uh in the vulnerabilities that led to that breach and translate it to the other vulnerabilities in in your organization um but if your organization hasn't been breached by application security you probably don't have this

data so um the the pamon Institute ponymon Institute uh did a survey um last year of these different Industries um and uh they they they broke it down into detection escalation notification expost response and lost business um and came up with um the average and then per capita um which which is per per record stolen this is kind of record based so it's kind of a pii um Centric uh view of the world which is both good if that's the risk your business is is getting pii exposed it's not so good if if if your business is not that um if it's not you probably have to find some breach costs that are more related to um your business and the

risks in in your business but um since this is the best data out there I use that and you can see the down here I don't know if you can see in the back but there's different Industries like uh Financial it's $248 per record is the cost of a breach whereas consumer it's only 159 um Pharma it's 310 so different you can see right away that this is this is has some value to an executive because they're seeing like peer uh industry verticals what were their costs from from breaches you have to make it you have to make it as relevant um as possible um and then a a a way to make vulnerabilities real is not to not to

deal with them in isolation but to actually look at threat space data and see what are attackers actually exploiting and that's actually leading to leading to compromises that are impacting um real businesses um this data comes from last year's um Verizon data data uh breach report and um these were real real uh real incidents that had a real impact in the business they had it they had to um investigate them um whether they were compelled to do it um because they're regulated or or um they needed to call someone in to you know actually clean it up and figure out what happened but Verizon collects this data and U these are the different attack types um that are used and um one

of the attack types that's used quite often is is hacking um and this adds up to more than 100 because a typical attack will have multiple multiple stages there might be um you know there might be hacking in order to install malware and then you know so there's two or there might be social engineering to install malware um but 40 about 40% of the uh attacks packed some sort of issue uh in in software and uh over here is the root the different root causes um back door control Channel SQL injection command injection proide scripting authentic

for