IATC - A&Q - Disclosure - Katie Moussouris

that's fine no it's fine i just want to know so that i don't tell that story that you wanted me to tell not now tell you later um ok so um my name is Katie I'm asaurus I suppose I should stay microphone my name is Katie mis horas and I am the chief policy officer for a company called hacker one i joined hacker one about nine weeks ago and before that i spent seven years as a security strategist at Microsoft Iran microsoft security community outreach programs and last year launched Microsoft's first-ever bug bounty programs rewinding the clock even further I was a penetration tester for about seven years and before that I was a linux developer so long story short my

career in vulnerability discovery disclosure coordination I have seen the bugs for both sides all sides now and I've done response somebody somebody knows what song I'm talking about okay I did a lot of karaoke last night so I still got the music in me that's not happening on the recording by the way not now so what I'd like to talk about we've got 30 minutes I'd like to actually find out a little bit about what the audience in this room is most interested in hearing I can talk to you from you know it's you know experiences doing security response and vulnerability coordination from an open-source standpoint obviously to a closed-door standpoint and then you know

more about some of the common problems that you will encounter when you're trying to coordinate vulnerabilities with organizations I can also tell you about some ISO standards that i have worked on that have been published this year there's an iso standard on vulnerability disclosure 29 147 that was published in February februari this year took only a short breath of nine years to do a sec six or seven of which i was working on them and there's another iso standard on vulnerability handling coordination 30 111 but some of you already look sleepy so maybe I won't start with ISO standards I know a lot of the people in this room but for the who I don't interact with on a regular

basis tell me a little bit about yourselves are you security researchers anybody in the room find vulnerabilities okay all right yeah I know you okay fine you're allowed to you are also allowed to participate but how many of you work for companies that that have software of some kind any kind any kind of website Wow some people don't work at all okay i'm pretty sure everybody at least has a web presence these days if it's a company but essentially vulnerability response and coordination is something that every organization with any kind of online presence any kind of website even if software making software is not your business there will be opportunities for the research community to identify where

your humanity has crept into your coding experience and you have made a mistake so so so one of the things I like to talk about when i talk about vulnerability coordination and disclosure is the need for empathy in a way when I worked at Microsoft I was I was effectively a bi-directional cultural liaison you know the hacker community might have an issue that they just disagreed with Microsoft on Microsoft might have some issues you know in terms of the complexity of the software interoperability testing application compatibility that might make a fix take longer than a researcher thought it should and part of my job was to kind of negotiate and build empathy on both sides so one of the things that

I think is really important to keep in mind when you're coordinating molnar abilities is understanding where the other party is coming from do you guys have any specific areas that you want to focus on before you leave sir bounties you say I started Microsoft's first-ever bounty program so that's where you want to go with this we can talk about that well then sit yourself back down get on back down there trip and now all right bad touch fine Allen you know what you can leave if you really want to but I can talk about economic incentives which aka bounty programs so how many of you familiar with the bounty programs i started last year okay everyone even you and you were

still gonna walk out on me buddy now I'm bullying ya know alright so so those those programs were unique in that they were created it took about three years to create these programs that were suitable for you know for my former employees a former employers needs and aligning the research community with what they needed in terms of getting the vulnerabilities earlier after release and essentially using a facet of a gap in the market place to provide an incentive where no other players were buying and that specifically I'm talking about the ie11 betta bounty program so that was during the first 30 days of the I you live in beta period it was kicked off last summer and essentially what

what the what the gap in the market was is nobody was really buying browser bugs in beta the reason for that is that customers haven't deployed it so it's not a great target for the black market actors the white market folks who would be using it for defense purposes again not really useful to like let's say as EDI who makes an IDs product because no customers are employing it so there's this gap in the market that we were able to provide an incentive we were the only game in town and we predictably actually moved the spike of vulnerabilities that we normally only get after code was complete and released to manufacturing very awkward time to get all of these

critical bugs we move that to the beginning of the beta period so that was an example of having empathy with what the business actually needed so if you're in a position right now we're trying to convince your organization that a bug bounty is a great idea there are a few different angles you can take to use that is anybody interested in hearing about that or really I was supposed to be talking about disclosure but we can talk about economic incentives everything just change the title on the recording it's fine it's fine um yeah uh-huh

you

okay so the question as i understand it let me know if i'm wrong is how do you prioritize the different classes of vulnerabilities in terms of their importance is it in the context of in terms of their importance for addressing them or in terms of their importance for providing incentives okay well so how do pata organizations generally prioritize bugs so every organization is going to experience a different volume for organizations who experience a very low volume of incoming bugs that makes sense and is practical to just fix all the bugs as they come in just fix mall for organizations that start receiving huge massive internet scale numbers of volumes of bugs my previous employer was

getting over 200,000 non-spam email message messages a year into secure at microsoft com funneling down doing the triage and distilling it down to maybe about a hundred CVEs fixed per year so it's a lot of work on the front end and the funnel and those were all legit bugs at the tail end of it so the hundred CVS obviously all legit bugs the way that a lot of organizations do it is first they establish what could be called a bug bar and that's essentially ranking for severity of what's the worst that could happen if this bug is exploited so Microsoft used critical important moderate low or aka defense in depth and they actually have it published their

bug bar if you go to microsoft com / sdl you can look for a sample bug bar and it gives you the exact criteria they actually split the bug bar between what would count as a critical on on the server verses are critical on the client and there are differences there subtle differences so that's one way to do it another way to do it would be cvss right score the bug a lot of organizations use that there are other factors and these are actually touched on in so standards other factors to consider in terms of bug prioritization are the likelihood or ease of exploit you've got a bug that may be critical if an attacker is able to exploit it critical

consequences right you know full remote code execution very difficult to exploit whereas you might have one that's categorized as important according to your bug bar but perhaps important is for example a sandbox escape the sandbox escape you know basically leaking information that can allow you to bypass a SLR dep or one of the platform level mitigations you're going to end up with something that in and of itself by itself does not lead directly to remote code execution but in combination with another vulnerability that may have been harder to exploit without it enables the exploitation that vulnerability so in a very simple scenario you know the bugs come in you do a very quick you know

prioritization against your bug bar and you kind of fix as you go as you get more and more sophisticated in your Security Response you're going to take some other factors into consideration another factor that does have to do with the topic at hand is intended disclosure so sometimes finders will come to you and they have very hard deadlines in their own disclosure policies maybe they've only worked with open source software that's not really widely deployed a whole lot of testing doesn't have to go into it when I was a Linux developer the way that I would text test fixes is does this compile hey buddy does it compile for you all right good to go let's go hit it you know put it on

the ftp server and then send a note to bug track so and saying that we fixed it that was where we were crowdsourcing our unit testing right so that's a very different model than you no then then enterprise software right it's also going to be a very different model in terms of prioritization around somebody's disclosure timeline if it's something that you are fixing on your own online services so systems that you run and control control the configurations versus if you are a maker of what I would call box product which is something that will run on client systems so you know anything that that a user would have to take some action to install a patch or an update or make a

configuration change in order to remediate the vulnerability those are going to require a lot more testing and a lot more time because essentially you're going to end up with a lot more variants of configurations as opposed to running your own web services it's a very long-winded answer to your question did I get most of it look like close enough all right right on i'll take it how much time do we have and we have time other questions yeah okay so the question as I understood it is a role in the ecosystem of third-party players such as ed I like a vulnerability broker interacting with vendors vendors may supply their own bug bounties those third-party bounties exist is that the

gist of your question and do I see that as evolving what yes yes I do did I plant this guy actually he tried to leave so no absolutely I do I was ecstatic actually when i saw when i saw the evolution of some of these market enabler type companies and my company hacker one is no exception to this what we're seeing is is the fact that there's a recognition that there is an active and healthy vulnerability economy there are many players in it you know in terms of the finders of vulnerabilities who may you know some people will always want to stay white market no matter what no matter how much money is dangled in

front of them some people will will maybe venture into the gray land maybe not care as much how their vulnerability information is used once they sell it and then there's some that are just in it for top dollar they will find whoever the black market broker is who will help them achieve that top dollar and black market you know I'm talking about white gray and black markets even even though all of these markets are actually legal markets when I think about white grain black markets in this vulnerability economy and explain mark place its intended use so for me white market is intended uses defense you're acquiring these vulnerabilities either is the first party vendor or as a zdi

who gives it to the first party vendor to get it fixed practices coordinated disclosure doesn't release technical details until the the issue is fixed etc that's white market to me in this economy grey market is more mixed-use you know there can be some exploit sales to folks and perhaps those exploit sales are used to test defenses maybe or maybe they're not you know and then there's the pure black market use which would essentially be buying vulnerabilities buying exploits that are specifically intended to be used to attack and an ID least a stealthy and undetected for as long as possible so that's what I'm talking about there when I went to get back to your question about the

evolution of these third-party players I think there are a lot of broker models out there um one of the things that that I think is sorely needed and as somebody who has done bowlin disclosure in one form or another as I said at the beginning you know either from the finder side the coordinator side the vendor side is the fact that vong coordination in and of itself is not that straightforward for a lot of people even major mega-corporations can't even get the basics down somewhat sometimes and then you also have new researchers coming into the ecosystem who may not know what to expect maybe they had a great disclosure experience that only took you know 48 hours for a tiny

open-source vendor to fix and then they go and they find something in a giant mega corporation they are shocked you know at the time lines at the nuances and all that stuff and I think one of the key things that these these intermediaries are now now looking at trying to facilitate my company included is facilitate that conversation such that it's much more predictable I would never want to see a security researcher approach an organization with a vulnerability and be referred to legal action you know I think that that to me is is probably one of the one of them s uses of you know that some of those intermediaries and whatnot it happens with it happens a lot still it really

depends if an organization doesn't have a response process it's it's quite likely you know it depends on who gets wind of what's happening and how powerful they are in the organization how powerful you know a particular voice of reason maybe you know in the organization but you still see these these really adverse reactions and and essentially I think it's because organizations who have never met a security researcher or hacker before trying to inform them in a friendly way about security issues they just take on a very defensive posture and it can get hostile and escalate very quickly and obviously you can escalate on both sides very quickly which doesn't help the end user in the end I think you had a

question yeah that is a great question how do i see bug bounty programs changing the rule of professionals consulting services so do you guys remember when it was hard to sell a pen test it's hard I mean how many of you are as old as I am at least some of you it used to be hard to sell a penetration tests what are you going to pay hackers to hack us are you crazy you know that was a you know that was heresy and penetration tests are something that are not only normal but they're often required by regulations you know the regulatory requirements for third-party security testing so that industry I feel like is evolving and when when I started

the bounty programs at Microsoft the internal code name for those bounty programs was ad hoc pen testing because it was essentially opening up the pen test world to you know the pen test two instead of consulting companies the entire world and you would only pay for the bugs that they found in a penetration test you know I was one of the artist formerly known as at stake the typical engagement time was two people two weeks so even if you have the best stats takers on a particular gig you've got two weeks to get comfortable with the environment whatever documentation or anything that the client was willing to provide to you and get as many bugs as possible and

often they wanted you to start at black box which meant you got zero info you were coming in as an outside attacker now yes that's useful in telling them is there a lot of low-hanging and highly exploitable fruit that a reasonable attacker can find in a couple of weeks sure that's useful but is it useful in terms of actually finding as many serious security holes as possible now because attackers typically will have you know unlimited time and resources is what we would say about it so what I think in terms of bug bounties it's really opened up the eyes of organizations to understand that even the best penetration testers have time constraints and resource constraints and

potentially skilled constraints you might not get the the exact consultants that would have found that that show-stopping issue on your site or on your platformer in your software but somebody random out in the world playing with your site for you know indeterminate period of time may very well find it and save you and your customers from certain doom so yeah

[Music] so generally I think your question is how how do the constraints in current bug bounty programs compared to constraints for a traditional pen test usually traditional penetration test two tests are done under NDA I have not met any that are not done under nondisclosure agreement some bug bounty programs out there require non-disclosure agreements some don't Microsoft for example did not require any kind of NDA to get paid I paid a hundred thousand dollars out twice no one da but what we were asking was that the researcher worked with us and coordinated with us on any disclosure so you know example of that James Porsche was the first recipient of a hundred-thousand-dollar mitigation bypass bounty which was a bounty for a

new technique he coordinated the disclosure of his blog that explained the technique after some other finders had started publishing some details that were close no cigar but close so it seemed fair that even though the issue hadn't been addressed because his complex architectural issue even though it hadn't been fixed yet well there were some other researchers that were kind of finding the trail of breadcrumbs made sense to have our guy who worked with us the whole time to go ahead and disclose his his you know research around it so it depends on the organization certainly you know I I lobbied for that very hot you know very very strongly in terms of the creation of Microsoft's bounty

programs that intellectual property would remain in the hands of the researcher and that there was no NDA because I didn't want them to have to make a choice right between do the right thing and get paid or keep it for themselves and maybe figure out what they want to do with it later didn't want to have have them make a hard choice there now there are other third-party bounty programs that will make the researchers sign an NDA before joining the platform hacker one does not make the researcher sign an NDA before joining the platform we again we don't want to make it a hard choice the researcher is free go to an organization outside of our

platform like Neil meta did for a coordination of heartbleed right he was the original finder of heart bleed he didn't report it through the hacker one platform but through the internet bug bounty we awarded him fifteen thousand dollars because he's a nice guy he he sent it off to charity yeah sorry I just have to do this ain't no timeline when she's pwned okay sorry I had to we were stop it you do not get give me a yellow card for that you don't even get yellow cards um so so that gets me a red card now right okay um so the lack of timeline I'm sorry I just had to I have the music in me I can't stop lack of

timeline that is an organizational maturity issue okay when you think about it what what a vendor's do they they make stuff to sell it to people if a if they spent their engineering resources on bug fixes and testing and whatnot that has to come out of somewhere and usually that comes out of building the next product so that doesn't mean that they get away with not fixing anything but it's a matter of educating an organization that may not be prepared to deal with servicing their vulnerabilities in an appropriate time frame I was talking about this a little bit yesterday these these devices right here commercially the the manufacturers of these devices want you to buy a new

one every year does that make it highly motivated for them to want to go ahead and patch everything that's out there not really so when you talk about embedded devices this is a fairly replaceable version of an embedded device yes there are some update capabilities some better than others but let's say there's a architectural flaw on the chip they're not going to recall your phone that they really want you to buy a new one next year they're not going to recall your phone and so anybody who is left with the older version of the phone is going to be vulnerable forever so there is a frustration there is a balance and there is an educational component when it

comes to having especially hardware type manufacturers who are dealing in you know their software is firmware having them understand the importance of the ability to do some sort of an update or recall or something like that if something is particularly egregious I think that when they are building their software as part of their security development lifecycle the very end of the security development lifecycle says something about have a response plan and in that that little square of the sdl at the end that's actually where all of the vulnerability coordination stuff happens that's where you you've done you've made your product and you've released it what's your response plan you're never going to fix any bugs that come in I

mean you could have that as your responsible and not recommended but you know as organizations get more mature their our abilities to put response plans in place that are a little more sane than that that have that right balance for that the organization can absorb between staying commercially viable and servicing their products and their customers yep

[Music]

great what they're still doing that huh yeah so okay so you touched on a couple of different topics there but I want to pick on last one the cease-and-desist as a response to security researchers when I was just answering the previous question that is not a good response plan that is not a good way to service your vulnerabilities is too I know what we'll do we'll just threaten lawsuits every time that's called what I what I would say being stuck in the anger phase of the five stages of vulnerability response grief so no that's not going to work the thing about that it so but you were you were saying at the very beginning about how big companies who

have learned their lesson actually made changes based on customer pressure right and you're saying that industrial control systems are either not listening to their customer pressure or not caring or not getting any customer pressure what is it all

[Music]

you got it right there they're building systems that aren't throw away these are 30 year plus devices you know a customer came and lectured us when I still worked at Microsoft and it blew my mind this customer was a company that invested in equipment that needed to last them 50 years it was 1 billion dollar investment in a certain piece of refining equipment that ran on Windows XP and they were never going to move off of it because they're all of their revenue one hundred percent of their revenue depended upon this 1 billion dollar investment that was designed to run for 50 years they were afraid to even install patches let alone upgrade the base operating system

so that was in nuance that was completely lost to me until I worked for the biggest software company in the world with a bunch of critical infrastructure depending upon it sometimes it's the customer the vendor might have provided the fixes might have provided whole generations of fixes but if the customer is too afraid of actually wiping out their business or tremendously you know affecting their business negatively by applying the fix or by upgrading or whatever it is the bottom line is the security of that device the security of that system is affected in a bad way I mean just think way back slammer that fix the patch was out for six months before that worm took

over the internet we're still in that same boat today so I think what you the colonel would I would really like to draw out of your comment your question is that customer education and enabling customers to also have a strong security servicing model for themselves is actually a really important part of the vulnerability response ecosystem as a whole we talked about finders and vendors the customer is a absolutely a hard participating party in all of this and it was due to customer pain that the biggest software security in the company in the world stopped all its developers cold from writing another single line of code when Bill Gates were the trustworthy computing memo and 2000

to and said no more code writing until you all get trained in security that was unprecedented as a move then and now I still have never heard of anybody else doing that thousands of developers stop making us the next generation of money and and invest you know insecurity so i think it was customer pressure that drove that change that cultural change and if its industrial control systems where the customers are either unaware or unaware of the implications or are aware but in fact it threatens their commercial bottom line they are commercial bottom line then there needs to be ways for us to work together as an ecosystem to help them out of that messy and have them be a part of the security

servicing solution if I have time for one more note i will be around he'll be around all through until I'm leaving Monday so I'll be around Def Con if you guys are going to be there I'm certainly over a black hat if not if you have any questions I'm k8e m0 on Twitter Katy mo not Kate emo and home and I'm also katie at hacker 1.com thanks very much