Why Does the Industry Make Insecure Software - Craig Chamberlain

all right so how we got here so here are the two so over this is something that I developed over the course of literally it's been the last five years so first off anybody have a relative who does not own a computer I have a couple and um I have a couple that had never owned a computer and I think they never will and one of them in particular asks a lot of questions like you know one of them is he's a retired insurance executive and I think he's kind of a product of the Mad Men era a long time ago and and he reads the kind of the security news headlines and reads about things like data

breaches and security disaster isn't he and he says things to me like why do you let this happen why do you run your business this way and so for a long time I really couldn't figure out how to explain to him why these things happen and how we got to this place eventually I did and I'll show you and that's kind of how I went down this road and I'll show you how that evolved secondly I was at a dinner this all started I was at a dinner in Austin about five years ago with a bunch of security researchers and there was some very important people there from DHS and one of them in particular was a

very important person he wanted to start regulating software security and wanted to start immediately and we were trying to he was asking us why can't I just do this tomorrow using product X and I'll just say you need to pass a scan by product X and that's what you have to do or trying to explain to them why I can't do that and that's actually an interesting conversation so as far as the problem statement so we know that by the way I'm going to apologize in advance for my art skills I did not have the support of a marketing department in producing that so this is this is pure research so the good news is this is

pure research with no marketing agenda whatsoever but the bad news is my art skills so um obviously you know we all we have to do is look at the headlines to see that there are security problems and security disasters across the landscape of growing size and intensity as you can see security disasters are actually getting larger as the years go by and more dramatic and if we look at on this is this is a little bit hard to read I apologize because this is a photo and I don't have the original yet but what this is showing us is that done there could have been studying software security metrics for a long time using really large data sets and what they're

finding is that a lot of the metrics are not going in the right direction some of them are treading water and some of them are not getting better in terms of software security quality and this for example what this is showing us is that it turns out that most applications actually fail their first Oh wasp top 10 assessment in terms of do you pass or fail do you have you know have you successfully avoided implementing the top 10 classes of security bugs is defined by wasp most applications fail at that that first time it's not so much fail fail might be the wrong word it's probably more case if they just haven't actually tried to think about doing that yet this

is just another kind of random data point this is a chart of sequel injection vulnerabilities found in PHP questions and Stack Overflow and this is this is going back over roughly the last decade or so and so um over the course of the last five years is that developing these talks we've had lots of dramatic exchanges on Twitter where people like you know the Cisco CEO lots of people like the Cisco CR saying every company will be broken into everything will be broken into eventually everybody's going to have a security problem then we have you know the latest trend in financial services now is there are security teams now that have unlimited budgets which apparently is a

thing in some companies they don't have a budget they just get what they need on their code gives a lot of really data rich talks and one of the one of the points that they make is that one of the trends they're observing is that security is getting so difficult that the tenure for a chief information security officer is actually contracting that the average tenure for seaso is down to about 18 months now just because they have more problems and solutions alright so why do we have soft so going back to my my older relative is never owned a computer it doesn't understand any of what he sees in the news why when somebody like this asks why do we why do

we let this happen why we have why don't we fix software security and just stop just make it stop you know this is a little bit like trying to explain colors to a blind person it's a really hard problem so in order to do that so in order to dig into this first I want to dispense with some of the conventional wisdom which I consider my ecology so this on these four things are really popular conventional wisdom that I've encountered over the course of being a security lead and the chief security architect a number of times just working in in software manufacturers large and small working in both software manufacturers and software producing organizations that created

software for internal use but didn't sell this is not a talk about a particular software manufacturer this is about all software manufacturers these economic forces applied to the entire marketplace not to one company or another so I don't want anybody to try to infer that this is a this is about inside you know acne you know this isn't about inside you know income and software security fail at company X this is about the marketplace so let's let's dispense with this very quickly first so these are the four major myths and I want to just go through them one at a time so first one is it's a network security problem right so we need to go

to black cat and buy all the boxes that we see in a black cat RSA and just buy everything in sight and then we will have security this is a myth that we've been chasing for a long time problem is software security and application security software engineering is not a network security problem it's a it's a code security quality problem so like we can pretty much agree on that next sometimes you see people do is they go in this product they go in this direction of well it's a it's a it's a process or a methodology problem or it's you know well we need a process and then the next thing is what we need a project

manager now or a program manager or something like this to kind of manage the problem and you know report on metrics and kind of measure the badness and try to tell everybody what to do I mean this is you know measuring things is good but a project manager alone like throwing a project manager to at the problem in writing reports is not going to change the quality levels of your software next it's a business problem right so this is another popular mythology used to be more popular than it is now where you have people walking around saying well you need you know executive buy-in what you know you need CEO buy-in in order to solve security

this I think is mostly a myth because you know this never happens right this is not our problem right no CEO will ever take this position because he can't or she can't it's not reasonable right but again the CEO the CEO the cxl whether its CEO CTO CRO etc etc they're not the bottleneck the bottleneck is elsewhere no because CXOs do not decide what engineering teams are going to work on this week this month this year they're just there they're floating many levels above that so they're the bottleneck is elsewhere so let's talk about the organization so software manufacturers are organized on differently but there's a there are common organizational patterns in most software manufacturers

so typically we have squads of developers and with a team lead or so you have junior developers senior developers and you have things like principal developers and you'll have something like a chief architect or a lead architect or Li developer you know basically you have you have teams of developers and you have unit leaders of some kind whatever we call them and right and this is not how they decide what to do right this is not how software gets built so this is why the CEO is not the bottleneck by the way these are I'm using personas here from dr. Strangelove because are there there are a lot of personas in this talk as we

talk about stakeholders and organisms and figures in the software manufacturing organization so I'm actually using Strangelove characters as personas just to help us keep them straight also to make it more more fun and entertaining right alright so next it's an engineering problem so how many times have we seen security teams like you know security teams for some reason loves to hate on developers and say well we need to train the developers we need to yell at the developers we need to run you know scan reports and drop 800 pH scan reports you know raw results on them every hour or every day we'll do that until they surrender and they agree to do what we want right this is not

useful no why well where this leads is on actually leads to a really bad place because then what you have is you have in many organizations you have security saying well we need to train the developers and then um you know the Department of security doesn't always have a elaborate budget for this kind of training so security will guide security out will often go and buy you know security or compliance will often buy these kind of box training products that are very rudimentary and very generic and then you have this and this this is wrong right this this has to stop this never happens in my organization's I make sure that it doesn't and this is

something that you know it isn't productive it isn't useful but it also it's kind of a name why because developers are not the developers also are not the problem they're not where the bottleneck is because why because if you think about you know this the reason that this is is in vain it's because most developers are actually highly educated and some of them are actually very intelligent and very experienced and very good at what they do at least many of them are um most most of my developers if I ask them to solve you know an XSS or sequel I or a remote command injection or any number of a hundred other things but ask them

to solve it they'll solve it and they don't need to go back to school to do that because they're good at their developers are good at figuring out how to build what you want them to build because that's what they do so you know training is not you know simple generic training classes and powerpoints and you know computer-animated training things are not the answer now there are exceptions there are things like crypto and key management that get very complex and do require specialized knowledge and even external audits and you may need to go and get somebody like a Don Davis from MIT or somebody to help you figure that stuff out right but fixing an XSS

doesn't require going back to school any more than any any number of other things developers do right so back to organizations so the way that software manufacturers organize is we have we have squads or teams of developers with some kind of a unit leader and then we have the management organization so in here I'm going to use this laser pointer cuz it's really cool so the squads of developers so it's all good so the squads of developers typically roll up into an engineering leader to be a director of engineering or VP of engineering or you know hierarchy and the engineering leader typically rolls up into an EVP and SVP or some very important VP typically rolls up into the

sea level and then there's this another organization there's a whole nother organizational branch in the tree called product management when there may be and there may be many of these there may be product managers there may be product line managers product managers director is a product management senior directors of product management eventually there's a VP of Product Management there might be an EVP of product management and they roll up into an extra-special VP that has an ear and ass in front of his name and they all roll up into the CEO who is really floating above the details here and then you have this kind of weird security guy off in the corner that nobody really

understands typically and that's that's me so what is this all about then so this is I - I put this in here because I actually started working on this talk five years ago as I said it's been developing it for a long time working with some advisors and this was this this was a something I was circulating at the time so I had to throw it in this this by the way this this character here is actually dr. Strangelove for those of you that haven't seen the film all right so let's agree to dispense with this method out this mythology and what I'm going to argue here today is that it's actually an economic problem and it's an

economic problem called a social dilemma which is a game theory concept so if we apply game theory so what it happened is after um look well let me not get ahead of myself so anybody who's seen the film might remember this this is one of the I don't want to throw out spoilers here but this is one of the points where the movie gets really silly at the end instead they start talking it you have to see the film to understand this but the reason it's in here is let's talk about so this is by the way anybody ever read an SEC filing like a 10-q where if you're a public company to do an SEC filing once a quarter once

a year I don't know if anybody noticed this but I only I noticed this myself you when you do an SEC filing you're required to do this disclosure about Mine Safety disclosures um if you're a software manufacturer you're required to just you know to state whether or not you have had mine safety disclosures everybody's required to do this um I'm not sure why I'm still trying to figure out exactly why but I'm pretty sure the reason is because the history of this is that the with the mining industry had a social dilemma in the earlier if we go back to the earlier history of capitalism many industries had social dilemmas around safety and the mining

industry is one of the first and the worst examples and so here's the NPR anecdote so driving to New Hampshire to see my older relatives and trying to answer their questions one day I find myself listening to NPR because there's not much else on the radio in New Hampshire where they live and I mean I love NPR it's not a dig against them but so they were doing a story about the early mining industry so if we go back almost two centuries there was an enormous one of the one of the largest highest growth industries and the growth of the nation was mining where enormous fortunes were made in very short periods of time and you know mining was you know

was was as big and as important then probably as software and big data and Internet things are today mining was the thing of its day for a time so what's interesting is that when they arm they decided that there was no business case for safety because to the primitive business science of the day the early capitalist said well my customers don't buy safety features they buy precious metals therefore there's no business case for safety so I don't care about safety so because I only make things that I can sell so we will not spend time and effort or money on safety features why because you know my state-of-the-art business science tells me not to so what happened is the miners

if the miners wanted to have safety features they had to do it themselves on their break time so if you wanted to build an air shaft or a tunnel support you could do it on your lunch break but nobody's getting paid for this and you know if you did this while you're on the clock be fired so um so of course you know miners would rig improvised safety features as best they could which of course will horribly inadequate and there were terrible accidents and loss of life and then we got into this very almost almost Hobbesian state of affairs where the mining Foreman would get engaged in a sort of a grim calculus of well how much loss of life is acceptable

in order to reach my growth numbers and hit my KPIs and and this was considered acceptable in the earlier ages of capitalism at least for a time so eventually things got so bad that miners riot miners would strike and then they'd the mining barons would bring in these private armies that people called Pinkerton guards to break the strikes and then the miners would riot and there would be conflict and loss of life and and it was it was very violent and and it was incredibly tragic at times and then it eventually got so bad that the government had to step in to restore order just to get things under control and so and this one on you know you can

read the history of this it went on for quite a while so eventually of course today you know today we don't operate mines like this because today we've learned that safe mines are actually more profitable at a higher cost basis but they're more profitable because the mines are more productive when the miners don't die right but it took a long time for capitalism to learn that and the same is true in other industries so this is our product our project manager we're going to talk about the product manager in the role of software manufacturers so on anybody know who this character is by the way this is another character from Doctor Strange level this is actually a general buck

purchasing who is the senior military leader in the room so the product manager we're going to look at some the product managers view of the world and I'm going to do this not because I don't want us to hate on the product manager just like developers I want us to empathize with a product manager put ourselves in his shoes and learn to see the world from his point of view because that's what we have to do in order to solve this problem so the product manager is like the mining Baron is a pure capitalist he looks at he wants to build things and Meritage things according to revenue attached he wants to build that which he

can sell because you wanted to make his kpi's grow revenue valuation stock price etc so it's the product manager is where our bottleneck lies because the product manager in many ways outranks the VP of engineering of the engineering leadership because the product manager is one who decides what we're going to build and he decides that according to revenue attached sales in progress deals on the table etc and according to you know features and deals that have the most revenue attached in the sales pipeline and this is not wrong this is capitalism this is business so on this is so how do the product managers see us so this is an actual this is something I've heard more than

one product manager and sales leaders say and and and in a way they're right because again this is not a dig this is more or less fair because as security teams as software buyers found as you know security teams tasked with managing risk in a supply chain and reviewing software purchases we typically don't have the budget and ability to say yeah we will you know we'll pay two percent more if you'll tack on these security features we typically security teams typically have the ability to say no that's unacceptable risk but they don't typically have the ability to say yes we need this feature and by the way we'll will kick in a little bit of extra

revenue for it um this is another quote so um when prioritizing so from a security perform a product managers perspective all features are equal there are no sacred cows because they're capitalists any feature may be arbitrarily raised or lowered in priority at any time according to the revenue attached and the business benefit that it brings so you know when you go to product manager and we say well we must have two-factor authentication immediately this is just one example reaction is you know none of his customers are going to none of his customers who are business leaders are going to come to him and say I love that you have to factor auth now shut up and

take my money right that is never going to happen so from his perspective it's a low priority feature not because it's security but because it's just one of hundreds of low priority features that have no incremental revenue attached all right so here's another paraphrase and this is on this is a paraphrase from a software it's actually more of an engineering lead than a product manager but this is you know more or less how it looks from the other side of the table so and and in this case this particular individual had a really good point because this is the case where they were already 1/3 of a way into their project trying to ship a new product they had

already had their resources and their their headcount had already been cut their budgets have been cut their timetable had been accelerated they're on a death march already trying to ship this thing on time to satisfy their masters and then they get all a bunch of security requirements dropped on them after this process that they had no idea we're coming and so basically and you know if you think about it if this weren't security if somebody did this to us with an on security feature well most of us would probably act the same way if you want us to do twice to work with 25 percent less people and you're increasing my deadlines and you're giving me no new resources well how is

that fair well you know it isn't most the time it really isn't fair so why do we do that so here's this is the heart of the dilemma so there is a convention that safety is free so when you look at conversations between software manufacturers and software buyers most software buyers say I do not pay for safety because safety is free either because it's an aspect of quality or its cultural mori that safety is free I do not pay for safety I do not pay for security I get that for free you need to give that to me software manufacturers look at and say well you know you've got 12 or 24 pages of security requirements

in the contract and some of those things are big-ticket items that have millions of dollars in cost attached and you know work isn't free and software isn't you know things are not free that isn't fair so in a way where they who is writing and who is wrong I'm not here to answer that I'm not here to solve this I'm here to explore the problem so I want to talk about my focus here is not so much on what should they be doing it's more about what is actually happening today so a social dilemma so I had to go back and study game theory and game theory is really complex so I had some advisors on this to help me and I'm

no expert by any means but game in game theory a social dilemma is where both parties choose to act in rational self-interest but this creates a bad outcome for all it's a very interesting paradox so in this case it's a social dilemma because both parties choose the selfish option which is not to pay for secure it for better software security and then what we get is we get worse software security which is a bad outcome for all which is not the outcome we want but that's what we get so it's a situation where individuals think they'll profit from selfishness unless everyone chooses the selfish alternative in which case the whole group loses and and they they get worse outcomes and

they want too many group members choose to pursue individual profit and immediate satisfaction which is rational if you're thinking as an individual but thinking as a member of a group system it's actually not rational so this is something so I'm in game theory um most of us are probably heard of the prisoner's dilemma it's probably the most cited game theory problem example I believe that the stag hunt model is actually what we're talking about here and this is this is something that is a little bit less known but the stag hunt the stag hunt game means that there are two or more parties to a hunt so we're out in our hunting clothes and horses

and we're hunting you know with we've got pounds and we're hunting for things so if the if the parties to the hunt cooperate they get a stag which a stag is just I think it's just another name for a deer I think is some of this game theory was stuff was written a long time ago so if the parties cooperate they get a stag which is a lot of food so we get to eat for like a week that's great everyone's happy if the parties don't cooperate then then each individual party gets a hare which a hair is a word for a rabbit so a rabbit is a little bit of food so you get maybe like one meal and then you're

hungry the rest of the day so if you cooperate you get a lot of food really good outcome game theories are measured in rewards of measuring what's called utils so if you cooperate everybody gets many utils if you if they don't cooperate they get one you tell which is a small amount of food so in the software world if we switch from a stag hunt to a security hunt this is what it looks like so if the software manufacturers and the software buyers cooperate we get much much stronger software security agree and I'm not going to say we get software security because that's another question but we get better software security relative to what we have now and I know if you can

do this because I've done this myself so I know it can be done it's not easy but it can be done um if they don't cooperate then we get relatively weaker security which is what we have now so caught what does cooperate mean so cooperate means for the software manufacturer the product manager decides to increase investment of resources and time for security features meaning they raise priority of security features they take them out of the backlog they put them in a sprint and they make them first-class features and you know which means rather than just having a security sprint occasionally here there we're talking about many security Sprint's with like you're not doing much more

engineering on security for the software rings the software buyer cooperation means invest by paying higher prices a grant it doesn't mean like we're not talking about necessarily doubling or tripling the price of software but there needs to be an incremental if we're going to be building you know software features that are very expensive there has to be an incremental increase in prices because this is business so if both parties cooperate and they invest we would get much stronger we would get relatively stronger software security if the parties don't cooperate we get weaker software security which is what we have today makes sense so so where do we go then so this leads directly into the regulation debate

which is the conversation I was having with that the DHS minister of software guy five years ago so let me preface this by saying I'm actually not here today to try and sell you a regulation scheme because I don't think there is a winner amongst the regulation ideas that are competing in the marketplace of ideas there's not a consensus and I don't think there is a clear winner but the fact that there isn't the fact that we don't know what to do about this is really interesting so I'm going to propose I'm going to explore two options here one of which is regulation I'm going to propose on a private sector solution that is going to be probably a

little bit controversial and may even upset some people but I just let me just purchase this by saying that I'm not advocating we do this I'm exploring what the options look like finally I do actually have a concrete recommendation to make so the regulation debate has been going on for at least six years remember seeing a panel debate this at RSA 2011 and it's been debated for me now maybe closer to a decade and there are strong proponents on both sides so what does regulation means so regulation itself can mean a lot of things it can mean government regulation of the software security quality it could mean a market-based approach that isn't it's not a private sector approach which has

significant problems of its own and then finally on the faith-based solution anybody this is a term where I don't find anybody remembers but during the the Bush administration's both Bush junior and senior sometimes you hear people talk about what we need faith-based solutions as an approach to as an alternative to more government so I'm going to actually explore what that looks like as well so what does regulation mean so one definition of regulation is if you talk to there a number of parties to this if you talk to them to say yes we need regulation we need to regulate software security research and make it stop and we need to do that immediately so that's one point

of view on that obviously just hides the problem it's not a solution then there's another camp that says well we need to regulate the supply of software security bugs but through economic incentives either through law and standards and bureaucracy or possibly through a private sector solution which I'll show you what the heck that looks like so you know this is kind of we kind of get stuck in this mode today where we have people saying yes yes we need regulation as in you know make it stop just make make everybody stop publishing bugs and breaking all the things because if you would just stop publishing the bugs then I could quiet the noise and I

could get back to building the products would I want to build that I can sell and you know so this is a very short-sighted kind of non solution but we do kind of tend to get stuck here and you know there's been over the years of course there's been enormous discourse on this issue on Twitter obviously most security researchers argue that that criminalizing security regulation or legalizing it is is you know not the answer but this conversation you know the fact that this conversation is still going on just proves that we are still very much learning about the problem some people this isn't it this is one actually EULA this is a Euler from a commercial

software product that is thought to discourage security research I've heard them a number of researchers tell me that they don't do research in this product because of this EULA and because of the legal departments so aggressive and then their end result is what we see is that a lot of the research and I'm not going to name this product because I haven't been provided a lawyer for this talk but it's also not important what product this is you know the point is that what happens here is that a lot of the security research on this product comes from places like Russia which you know if you ever tried to do if you ever tried to work with law enforcement or

sue somebody in Russia you find out that you know Russian legal authorities can't cooperate with themselves never mind anybody else right so you are not going to sue security researchers in Russia and get anywhere so you know moving it to nations moving it into the gray market areas is obviously probably not a better outcome for us um there have been things like the Wassenaar agreement changes to the Computer Fraud and Abuse Act most of this I think is made by I think the real problem here is that the law makers who are working on this stuff really need a lot more help from the technology community and understandings issues framing the debate and trying to figure out a workable

approach and that's on us I think we need to help them so if you look at poor regulation arguments I don't think with RSA 2011 but there was a heated debate they are in a panel Bruce Schneier said that yes we need to regulate software because what we have today is like consumers testing their own food right which doesn't make any sense it's like the food industry in God you know 19 you know a century ago in the food industry they had serious safety problems and people would actually die from eating food on a regular basis and there was another social dilemma so um opponents will say yes there is a problem but regulation is has too many

too many unsolved issues to be sorted out and in fairness there are some so proponents will also point to the fact that other other industries have had social dilemmas around safety that none of which could be solved from within they all required external regulation by government or by the state and software is no different they will argue that this is only only external economic forces can affect this this is one of my favorite quotes enough anybody saw this from this was black cat two years ago I think and you know software has never been subject to liability for various reasons that are too dense to go into here and so obviously there there is no

reliability touch to software and there's no liability attached to software security so the counter-arguments the major argument here is that nobody knows how to regulate software security like how do we actually do that well the truth is nobody really knows so the counter-argument from the software lobby is well you know first of all we already self-regulate and that's working fine but if you field regulate researchers as in make them stop that'd be great we'd like you to do that right then the next argument is well there is no actionable plan here they would argue that we don't have that the software I'll go say we don't have the manufacturing science to make perfectly reliable software we don't even know how

to do that much less make software that is demonstrably secure and to be secure to what standard because we don't know how to make software that is secure a period and then if you push them far enough you'll start hearing about what's sometimes called the nuclear option and what that means is if you really push for this you'll start to hear things like well if you're going to regulate software we're going offshore we're not coming back and so you know all those high-paying tech jobs in your district senator you can say goodbye to and good luck so you know obviously nobody wants to talk now is this a real threat or an empty threat well nobody

really knows but nobody wants to find out so the other the reason that there's no way forward here is because by the way this is used by permission from a really great Ola spraining class called practical web application pentesting by tim tomes and i'm going to include a link to him and the acknowledgments that i'll put in the blog post for you but basically this is this is the short answer of why can't we why isn't there a way for it well because static and dynamic analysis tools are great at finding bugs and they're useful but a lot of the really serious security flaws that we find still come out of manual testing this is slow it's expensive it

requires very specialized knowledge there are only a few thousand people in the world that are really good at this probably less than 10,000 so this is slow and it's hard to scale so we get into this problem it's like okay well let's declare software security regulation okay and so then what like what is that what what standard do we engineer to you know first of all you know the first problem is is nobody can agree on what the standard should be for software security or you know can we attach a liability to that there's no consensus on this and there's there's no consensus in sight so um this is a very snarky comment I made when on Twitter

and you know this is another cot that software security debate has been taking place on Twitter for a long time you know I made this comment is you know if we do declare software security if we you know if if we just declare yes you shall make your software secure or else and we put some agency in charge of that and probably probably what happens is that nobody then knows whether they can ship anything or not and so now we're perfectly secure because there is no software right so the other counter regulation is that the first counter-argument you get is that self-regulation is working and you know I think we can agree that given the kind of security disasters that we

see it's pretty clear that self-regulation is it may be doing some good but it's not going to move the metrics and it's not going to solve the problem any more than self regulation could solve social dilemmas around safety and other industries so software manufacturers will argue though that self regulation is effective it's optimal and it's working and the point of things like well we have processes we have you know dashboards product managers we have you know we do a pen test once a year and then we you know put that in a backlog there's an increasing trend towards bug bounties and I think bird bindings are very promising in terms of making pen testing and security research more accessible to

lots more organizations but you know again the bug bunnies most of the time we're testing things after they've been released and they've been shipped and so you know if you're finding lots of security flies after products been shipped those may or may not get fixed you're also not going to find things like design flaws typically in a bug bounty you're probably not going to find design flaws or logic errors or other serious issues that would not typically be found by a pen tester coming in on a black box model so they're those are really useful but I don't think that those are going to save us so the pro regulars will say yes you know you're dead bunnies in your process

is good but this is only as sophisticated as your customer Scruton demands and the software buyers lack the sophistication to really measure software product quality is one they don't have access to your product source trees and your backlogs and threat models and they simply don't have what they need to do a meaningful assessment they can't and to the customers you know the software buyers that are going and buying a two-week pen test and pointing that at you that is informative but a two-week pen test looking for things like sequel and XSS is not really it doesn't really go deep enough to make a real judgment about software security quality so of course the nuclear option exists

that if you regulate software the entire software industry is going offshore and the software industry will kind of get together and they'll buy the an island and I'll call it software land and they'll move everything there and this is probably an empty threat because these software software manufacturers are not going to abandon the major markets that are talking about regulation so this is probably an empty threat but nobody wants to find out obviously we don't want to go there so just like about a private sector solution so what would it look like what would an alternative to government regulation look like well I don't know if people realize how many people realize this but there actually are

exploit exchanges operating today that have been for years and these are kind of unofficial semi secretive exchanges where exploits are bought and sold by exploit brokers now we can't see any of that today because it's all very it's very invisible to us but if you I actually interviewed the CEO of an exploit brokerage and and looked at this and the course of developing this talk and if you do that it gets really interesting because there's a lot of data in there that we could make a lot of derivation from if we could see it but we can't so so first off the first question though is can we make derivations about product security quality from equity training data that

we already have like stock price well let's look at that so here is a company this is one of the most prolific software manufacturers tried it over approximately 20 years this is this is stock price this is volume and these are these are the weird metrics that the analyst on CNBC talked about so I dine this way because I started learning about I started learning about finance and stuff about four years ago and how I got into these ideas so I anybody want to guess who this is there's right this is 1994 I made this chart a while back so it ends on more than a year ago but it is Microsoft so you know if you look at this

Microsoft kind of invented what we call the security development lifecycle somewhere in here and then we went sideways for a while so if you're a if you're an MBA from Harvard or a Wharton or someplace and you're looking at that and saying well where's the security list where's the security bounce it's really unclear where it is here's another one another prolific software and hardware manufacturer one of the most prolific in history charted again over approximately 20 years anyway let me recognize this this is apple an apple you know if people argue about whether Apple has an SPL I mean they clearly they have a significant security engineering process but no they haven't they haven't been as

you know doing as many STL like things and SQL evangelism say Microsoft but I mean look at them you know without a net they don't have an STL and look they've gone to the moon so you know where's this where's the security you know downside there in fairness Apple actually has a really good security practice as well see in a moment this is another software manufacturer that had a serious data breach about four years ago right about here and buddy anybody recognize this this is a public record breach obviously that we've all heard of no it's not target it's actually a software it's a software it's actually a security product manufacturer sorry I said so

obviously had to breach here and they definitely it definitely had an effect it you know cut them by a third but they've since recovered and in fact it's the in fact they've since recovered and gone on to all-time highs so anything any exploit exchanges let's power through this so we know that there are very very large scale buying and selling of exploits going on in the in the secret markets and so this is actually pricing data from a few years ago that the CEO of an exploit brokerage provided to the media and int interesting that you can see there's a wide range of pricing starting at about five K and ranging up to a quarter million and

what's interesting about this is is this sort of meshes with my expectations as somebody who's been in the trenches for a long time in terms of where do we see more or fewer exploits relatively you know Microsoft is it's gotten has become a much harder target over the course of the decade some of these other things are still relatively exploitative relatively expensive and then things like iOS is has consistently been a very hard target and if we look at this is more recent data where we see there's a range here now the price range is higher we're ranging between 10,000 and 1.5 million the street price for a remote route exploit for Apple iOS is well into the

millions now which is amazing and so when I look at this I see it we can sort of derive that there our supply and demand zones here so what if we allowed again this is a controversial idea and I'm not proposing we do this but I mean this is what I want to explore what a private sector solution would look like what if we opened up these you know what if we closed the dark markets and we move them into the public domain and said trade exploits on the Chicago Mercantile Exchange like commodities well commodities are all public data is where we can see price we can see volume and we can see dozens of other metrics

which few of us understand but they talked about on CNBC all day so looking at that if we look at things like price and volume for software exploits then the analyst could make simple derivations about product security quality because if you're in a demand zone and an exploit cost millions you're probably doing a relatively better job on security than something where an exploit cost five or ten thousand and they're in a supply zone now there there are some problems with that to work out for example the first problem is if you ask the product manager if there's any idea they hate more than software security regulation they'd say no with the possible exception of this if you

ask them would you mind if we trade yours your software vulnerability exploits on the commodity exchange and you probably get this so this is not you know this is pretty much a non-starter but an interesting idea so first off we probably can make derivation problem we can make derivations about software security quality there is the problem that exploits are intangible goods you know there really isn't a way to stop you know you from to stop me from copying my exploit and giving it to all of you for free that's a hard problem things like you know intangible commodities like futures those are also intangible but those exist in a server in the ledger in a server in a brokerage somewhere and so

I can't just copy that you know give it to all of you because it you know the state exists in a place that's controlled and like software there's also the problem that demand for a particular exploit may briefly spike astronomically if the military says well I need to get that I need to pop that computer right now you know I don't and I don't care what it costs give me an exploit for this then demand may there may be transient spikes in demand we can solve this with something called open interest because the commodity exchange published open interest which is the number of contracts outstanding so if we see that there's a huge spike in price

but there's a there's no increase in open interest or you know open interest increased by one or two and we can assume that it's unofficial spike the other problem is intangibility now how do we stop people from copying exploits and giving them way there's also the problem that we're selling exploits which you know as as we can agree from the news today well we have zero day exploits we have very serious zero day exploits in circulation right now which are being used to do great harm across the world you know selling exploits publicly is as a problem the bigger problem is that the major customers for the exploit brokerages are governments their governments and sovereign

militaries and they are not interested in a public exploit exchange they're interested in a private one where these things remain secret because when they become public their value tends to evaporate so even if we even as Congress declared that exploits will now be sold on the Chicago Mercantile Exchange the feedback I've been given is that the government's the military's would ignore that and they would still buy these things in the underground or the private exchanges and even if Congress outlaws that they'll still do it because they can go and get what's called an oh you I which is an a no you I stands for actually stands for I don't know what it stands for but an oh you eye is

basically like a permission slip to go and do something illegal that you need to do for reasons of national security so that's what I've been told now the other problem is who so if the governments are participating in the brokerage then who are the customers yes all right so we have to wrap up the problem here is that it you know governments are sort of legitimate customers for weapons and things like well we can debate whether they are whether that is legitimate or not but the state has jurisdiction on the use of force so they kind of have the right to buying these weapons but if the governments aren't the customers here then who are the customers and what

legitimate use do they have to be buying exploits so we probably have unacceptable moral hazard here which is completely unworkable so finally I'll leave you with this um if we decide that we need a faith-based solution I would argue that the faith-based solution is what we have today that we don't apply policy or economic forces in a way that drives change instead we we evangelize security because we believe in security and we have people called evangelists whose job is to evangelize security and try to try to have no security revivals and and persuade the business to believe in security and take it more seriously and you know if we decide now granted this is this is I'm getting myself in

more trouble here because this is probably a controversial thing to say but I think the question is valid is are we practicing a religious approach to an economic problem if we are that's not rational that's not rational and that's not going to help and so we need to think about that on the proposal I'll leave you with is that this is a quote from Justice Brandeis on what I'll say and it quickly is that all of these approaches were talking about are designed to try to surface this information into the hands of software consumers and software buyers to make more informed decisions but they're all very convoluted and direct ways of doing it why don't we just surface this

information why don't we say okay software manufacturers you need to publish your security backlogs and tell us what you know and what's sitting in your backlogs for products that you're shipping not always that is not public and then software consumers can read analyst can write about this and who's doing a better worst job on security and then consumers can vote with their feet and that would be something that's relatively simple and implementable so I will follow up with a blog post with these acknowledgments but that is my talk [Applause]