Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability and compliance on the Microsoft Cloud Platform. Hey everybody, welcome to episode 85. This week it's just myself, Michael and Sarah, and our guest this week, Madeleine Eckert, has here to talk to us about Microsoft Security Response Center and bug bounties. But before we turn our attention to our guest, let's take a little laugh around the news.
I'm going to kick things off this time. It's been a while since I kicked things off. I only have two items. One is from my own backyard in the database area. And that is that we now have available the certificate for our common criteria certification for SQL Server 2022. I know that for a lot of customers that doesn't mean a lot, but for those customers that need to use systems that have been validated to common criteria, then that certificate is now available for you to take a look at.
And the other item is GitHub Advanced Security for Azure DevOps is now available in general availability. So that includes things like code scanning, secret scanning. My God, people have just got to start doing more secret scanning. They really do. The number of issues we see across the industry with secrets being pushed into repositories is just insane. And then the next one is also dependency scanning. It's actually huge. It's called Dependabot.
And it will do things like, hey, you're depending on this particular JavaScript library or whatever. And that's now been replaced by another JavaScript library or another version because of security vulnerability. So this is great to see. It's not just available in GitHub anymore. It's also available as your DevOps. Sarah, what do you got? So I've got a couple of bits. I don't think we've mentioned this yet since it opened.
But registration for Ignite is open at Microsoft Ignite in Seattle in November. So come to Ignite. I get to go. I don't think you're going, are you, Michael? But I am. Actually, watch this space. Something's going on. Oh, OK. OK. Watch this space. So maybe Michael will be there. Michael, does that mean I get to meet you for the first time in person ever? Yeah, I know. Just in case people don't realize, a bit of an inside joke.
Whenever Sarah goes somewhere, I always move away or the other way around or something. So, yes, a bit of an inside joke. Yeah, he's been avoiding me. Yeah, there's actually another conference going on exactly at the same time, and I might be looped into that. So just a couple of bits of other news. We do have a really cool ebook about the Azure Defenses for Ransomware Attack. We'll put the link in the show notes. So if that's something you're interested in, go and have a look.
And then, well, the time that we are recording this, Farzana has just named Microsoft a leader in the Zero Trust Platform Providers Wave Report, which is pretty cool. We're up in that top right hand corner. So, yeah, pretty cool. That's pretty much the news from me. And now we'll move on because it's just Michael and I here. So that's all the news done. And we'll move on to our guest. And our guest is Madeleine Eckert.
I had the privilege of meeting her in person when I was in a hacker summer camp in Las Vegas last month. Madeleine, welcome to the show. Do you want to tell us who you are and what you do? Yeah, I'd love to, Sarah. Well, first off, Sarah, Michael, thank you so much for having me on today. It was a pleasure meeting you, Sarah. So happy that you reached out to set this up for us today.
For everyone else, I'm Madeleine Eckert. I am a senior program manager here on the Microsoft Researcher Incentives Team. And that sits within the MSRC, which is the Microsoft Security Response Center. So Research Incentives is a fairly broad title. But basically what it means is I tackle mostly the bounty program and also our most valuable researcher, researcher recognition program, which are going to be kind of like the two, I'm sure even the two most recognizable areas.
Let's just sort of kick this off with a couple of real simple questions. So you're in Research Incentive programs. So what actually is that? I mean, I've got an idea what it is to do with helping provide funds for people who are finding vulnerabilities in various products. But can you sort of explain to our listeners precisely what that is? Yeah, absolutely. Great question. So as Research Incentives, so incentives can be a few different things. It can be both financial and also nonfinancial.
So you have, for example, the bounty program, which is going to have specifically targeted scope with bounties associated with that scope. And then you which will then, of course, incentivize researchers to come take a look at our product and report security vulnerabilities to us that we can fix them and secure our customers and beat the bad guys, essentially. Then we also have our nonfinancial programs.
That's going to look like our most valuable researcher program, which also features a quarterly and annual leaderboard that then provides some visibility for researchers who are targeting Microsoft where they might not receive a bounty. They then get that public recognition.
And then we also partner with other teams within the MSRC, like the community team, where we then set up researchers to have podcasts, to have Twitter promotions, or to set up with them to come on site and do talks such as that strike our blue hat. Just looking at this, I mean, ultimately what we're trying to do here, and correct me if I'm wrong, but is essentially to protect customers, right? That's the whole point.
So vulnerabilities will be found in products, whether it's Microsoft products, whether it's some other vendors product, doesn't matter. But ultimately what we're trying to do here is essentially to provide an incentive to provide vulnerability information under a disclosure mechanism that will keep the vulnerability researchers happy, but also allows us, or any vendor for that matter, enough time to get the right fixes put in place.
Essentially a responsible disclosure program. Is that a fair comment? That's exactly what we have here. So yeah, everything that we're doing here is to promote CVD, or coordinated vulnerability disclosure. So we are partnering with the researcher community to again, intake those vulnerabilities, well incentivize them first sending in those vulnerabilities, provide an intake mechanism through the MSRC, and then fix those vulnerabilities as quickly as possible.
As a return to the researcher, again, they're going to get that monetary or non-monetary incentive. So that's a great summary, Michael. You did your homework. Michael's just been around Microsoft for too long, I reckon. Well, I mean, at the end of the day, you know, I mean, I hate to say it, but I was there when the MSRC was first formed, right? So very well. Michael, are you sure we shouldn't be interviewing you as part of this podcast?
I mean, that's up with all the happenings and goings on with the MSRC, sort of the machine, so to speak, at all. So no, I mean, I can certainly talk about a lot of the old stuff in the old days, but that's not what we're here for this week. So I'll let Sarah continue with a couple of questions.
Tell us, because there will be some people who are researchers on here, but I think there'll probably be more people who aren't. So what is it? Tell us about specifically, we talked about what a bug bounty program is, but what about Microsoft's bug bounty program in particular? Obviously, there are different ones out there. So what's kind of interesting and special about ours?
I love this question. So I'm actually give you a little bit of background here on myself. So prior to joining Microsoft, I was over at a company that was a vendor or like a managed services for bug bounties.
And the way that programs were run there was that you'd have you'd have engineering teams reach out and ask, hey, can we set up a program on your platform where you will then triage all the cases coming in? You'll work with the researchers, you'll provide guidance on bounties, and you'll also manage any type of mediations that need to happen.
So what Microsoft does differently is that we do all of that in house. And the differentiator there is that the people that are looking at researcher reports are also going to be have they're going to have the access to the engineers internally to accurately and timely provide an assessment on that report, which just improves the relationship that we have with the researcher community and allows for us to triage bugs faster and to get them fixed faster and for researchers get bounties out faster to them as well.
All in all, I'll give you kind of a brief overview. Just kind of thinking about this last year, we actually awarded almost $14 million in bounties, which is a main differentiator. We do award out quite a bit. We awarded out almost 350 researchers and something that I'm really proud of is that we do have a global hacking community.
So we did actually award researchers from over 45 countries this past year. And that is part of, you know, core to Microsoft is we are a global company and our researchers are global as well. Diversity plays such a key role in terms of the type of research that we get in the type of attack vectors that are targeted. And so having a global community of researchers is very important to us.
And I guess the financial rewards vary by the type of vulnerability, right? I mean, not all vulnerabilities are created equal. For example, I would imagine that a 100% reproducible virtual machine bypass would be critical. That's big, right? Versus, I'm making something up, like a simple cross-site scripting that doesn't really get you much. And again, I could be wrong there, but a VM isolation bypass would be worth more than some of the more sort of trivial bugs.
Absolutely. Our highest award is actually in Hyper-V. So we offer $250,000 for Hyper-V specific scenarios. And then we have cross-site scripting that is going to be generally a security impact in all of our other programs. And that's going to be, again, on the lower side as well.
We do have a very wide range of awards. So if you do check out our page, we have 16 plus, and I say plus because we have programs that cycle in and out. Different programs that are running at any given time. We have variable scope, security impacts, severity, awards, and just general bounty payouts available for each of these different programs.
And then within certain programs, we actually have scenario multipliers as well. So if you get a bug, for example, in Kubernetes, you might get an extra 20% bonus. So those are always being updated. There's kind of scope for anyone, depending upon what your interests are. We're going to have something available for you with competitive incentives.
And what about reproducibility requirements? I mean, do you have to show that something is reproducible or can you just show a code bug? I mean, how does that work?
There is a requirement for sending in essentially like a POC that demonstrates that the bug is executable. I would say that the extent to which you go to prove that, the extent to which you would go to prove that, again, would be to use your best judgment. You don't want to violate safe harbor and go so far as to, for example, access customer PII when you're trying to demonstrate like info disclosure.
So it kind of depends upon the vulnerability itself. But generally saying there's an issue in this area without any further explanation would not meet the bar. And POC being proof of concept. Yeah. So, Madeleine, when you get a bug, I know we've talked about this a little bit, but when a bug comes in, what do you do with it? Like talk us through it.
A single bug report that comes in can have a lot of impact, a lot of power. But not only are we taking that single bug and implementing a fix and protecting customers from that standalone issue, but we're also looking at trends and looking to see where can we then, you know, provide that information to our product, to our product security stakeholders and saying, hey, you might want to look at implementing a broad mitigation in XYZ area, for example.
So we're looking to use these individual bugs to then also drive learning. And then our product teams, our partner teams rather, will then use that those insights to advocate for more resources, again, implement those broad mitigations, or potentially even take a look at like overall architecture. A great example being I recently began running a grant with one of our partner teams, and the grant yielded, I think, 20 to 30 extremely high impact bugs.
And that product team now is not just looking at even, you know, a mitigation that would take care of all those bugs, but also looking at how they build their product moving forward, and then also how they build other products that they integrate with as a result of that research. So a single bug bounty award doesn't necessarily just mean that we're paying for that one bug, but we're paying for intelligence as to how we build more secure products long term.
Something that I did want to ask you about and maybe, again, like I said, not everybody who listens to this will be researchers or doing bug bounties at the moment, but what would be your tips for if anyone's listening and they're thinking, oh, I'd like to do a bug bounty? Do you mean from like the organization side, someone like, you know, launch a bounty as part of their org or as someone like a researcher trying to get started?
I think I want to know the answer to both, but let's start with an org. Great, great question. So I would say that you really need to look inward first and assess, is my attack service ready for hackers to come and take a look? Have we done everything that we need to do first, such as engaging internal and external pen tests? Are we, you know, adhering to best practices for security development life cycles?
Are we doing internal hackathons? Do we have the resources to go and fix these vulnerabilities if they come in?
So those are going to be the first things I would say that you need to really ask yourself as a organization before you launch a bounty program, because the only thing worse than launching a bounty program and getting a hundred submissions your first week is launching a bounty program, getting a hundred submissions and then not fixing them for two years, because then you are operating with known risk.
So you need to make sure that you're ready. The next thing I would probably advocate for is probably reaching out to one of those vendor platforms, such as, you know, HackerOne, Bug Crowd, Integrity, and CINAC are some of the leaders in that space. And then potentially doing a review with them. They're going to take a lot of the like the resource heavy side of running a bug bounty program, and they're going to take that on for you.
And they're going to have the expertise to be able to give you insight as to how to launch your program, what scope to include, how to price your awards, and they'll pair you with the researchers that are going to be best for your scope as well. And then once you're on one of those programs, you can then decide, is this something that we want to take in-house and that we want to manage in-house similar to what Microsoft does.
A few other people that manage in-house are Google and also Apple. So it's generally some of the larger organizations in the space. But that's where I would start, is kind of dipping your toes in, doing a readiness assessment, and then using an SME in the space. I can't imagine many people would actually start a bug bounty without subject matter experts and going in with their eyes wide open, right? I mean, this could end up- You'd be surprised.
All right. Okay, let's just skip over that question then. Let's move on to something else. So following on from Sarah's two questions, I'll ask the second question. I mean, so let's say I found a bug or I want to just get into this business of finding vulnerabilities and reporting to Microsoft. What is that process? I mean, what sort of things should people do?
Because at the end of the day, I don't want to find a bug, give it to Microsoft, and Microsoft say, well, there wasn't enough information in there. We couldn't reproduce it. Are you sure you're doing the right stuff? I mean, what sort of stuff should someone do if they found a bug and they want to make sure that- Because you want it to be as frictionless as possible, right?
Provide as much information upfront. The appropriate people within the company talk back to you and say, yes, we found it. Thank you for reporting it. We've reproduced it. We're going to fix it in the end days or the next version, whatever it is. So what sort of best practices do you think people should abide by when they're looking into this stuff?
So if you have your hands on a vulnerability right now, I would recommend submitting it through our researcher portal and you can find out how to sign up and submit that through our bounty page, which will be linked in the show notes. Otherwise, you can also just send in the details through secure at Microsoft.com and then a member of our team will take that information, case it, and then send it on through the normal process.
I would just say by default, if you have something, share it and we will do our best to assess it and also help you demonstrate impact. You make a really interesting comment there because I didn't even think about that. And that is, so I alluded to the fact, well, I alluded to the assumption that, you know, you should provide as much as humanly possible to the response center to help expedite the process and make it as frictionless as possible.
It sounds to me like you're quite happy to work with a researcher to elicit the appropriate information, even if it's not there at the beginning. Yes, we absolutely will work with the researcher. You are incentivized to provide fully flushed out POC. So, but I will say if you have something, don't default on not submitting it because then that just that essentially leaves our customers subject to, you know, security issues within the Microsoft product.
So I would say submit it if you have it, but you are incentivized. You want to hear a story about secure at Microsoft.com? Do I want to hear a story about secure at Microsoft.com? Yeah, I figured the statute, the statute of limitations has run out on this one. So if you guys remember back in the day, there was a vulnerability that led to the Blaster Worm on Windows. It was found by some guys in Poland and they didn't email secure at Microsoft.com.
They actually emailed me on a Friday afternoon with all the information about the vulnerability and that became MS03 026. So there you go. That's my little story about not secure at Microsoft.com. Yeah, rumor weekend. But anyway, that's another discussion. So Madeline, what other advice do you have for people wanting to get started in the security research space?
I mean, there's a lot of researchers out there, but I think there's even more people in my experience who are interested and don't just know even know where to start. I give I give this feel quite a bit. So bear with me as I just go through kind of the checklist of things. It starts off with just getting the right tools. Ultimately, I think that Berkswiet is your best friend. So get it. Even the community edition of Berkswiet will help you get started.
You're also going to need things to help with your recon, like a subdomain enumeration tool. And you're going to use those things to start off by doing some capture the flags and capture the flags are great because you are actively learning while you are like learning how to hack while you're in an environment where you know that there's a solution or there's an answer.
And I think one of the main things that kind of stop people from continuing to hack is that you spend a lot of time hacking and there isn't necessarily always a bug there. But with the CTF environment, you are learning and you do know that there is a solution there. So you are motivated to continue hacking even if it takes you hours. Right. So one of the hacking CTF that I did was Hacker 101. I thought it was absolutely amazing.
And it was a way that I was able to level up being from a business background to level up and really understand some of the reports I was looking at better relate with the hacking community and ultimately really learn how to translate technical impact to business impact within my role. CTFs are where it's at. I would also recommend doing a hacking class.
There are quite a few available now, some that are hosted by some top Hacker One hackers, Google, Microsoft hackers that have decided to kind of branch out into doing consulting or education. Those are really great. And one of the best nuggets of information that I can give people is to go and read published reports. If you want to learn how to write an excellent report, if you want to understand what is considered to be impactful research, go and read some of the published reports.
Go and attend conference talks where hackers have been accepted to give coordinated disclosures about vulnerabilities that they've discovered. And then I would also absolutely recommend networking and also just listening in to the conversation within the hacking community.
You have tons of podcasts that are being run. One of my really good friends, Nahum Sack, has a podcast that he runs where he's always inviting on hackers and business owners, go in and listen and see what other people are doing and have that guide where you spend your time researching and how you research. The hacking community is very small, but it's also very supportive. I feel blessed to be in this community.
I have so many hackers that I can now say I can rely on as a resource for leveling up. And that's generally where I spend my time and how I go about it. To kind of bring this episode to an end, one thing we ask our guest Madeline is if you had one final thought to leave our listeners with, what would it be? I would say that anyone can be a hacker. Anyone can come in and submit vulnerabilities and help protect Microsoft users and customers.
And what I mean by that is some of the most prolific and most impactful hackers that I know don't come necessarily from a stereotypical CS background. They might have been marketers or photographers in a past life. That being said, you definitely need technical chops to be able to do this. But it's really the creativity and the diversity of experience and background that allows hackers to surface some of their most impactful vulnerabilities.
And so that's what I would say. Anyone can get into this. Your point about not necessarily having to have a formal education is just so true. Some of the best people I come across, they just have the fire in their belly. They just have the natural bent for doing it. A lot of them are really good at picking locks as well. Another discussion for another day. I love lockpicking. I just picked it up. I got six seconds at Blue Hat last quarter. Yep. No way. Yep. I love, I also love lockpicking.
It's the best. All my girlfriends had a lockpick. We have wine nights. There are roughly 15 girls roaming around Seattle that can all pick locks at a professional level that have zero technical background. That's fantastic. They work in marketing and sales and they're going around picking locks. So anyone can do it. I remember a few years ago, my wife and I were watching TV one night and I was picking a lock while we were watching TV. She's like, what are you doing? I'm just picking a lock.
She's like, why? I said, because I want to pick a lock while we watch TV. You know, keep my hands busy. Anyway, with that, let's draw this episode to an end. Actually, isn't the MIT, there's an MIT paper on lockpicking is like one of the most fundamental, most read documents on picking locks. Is that right? That's the kind of random knowledge only you would know, Michael.
Okay. I'll provide a link in the show notes. All right. So finally, let's bring this episode to an end. Madeline, thank you so much for joining us. I thoroughly enjoyed this episode. I have such an interest in vulnerabilities, finding vulnerabilities, but also managing that process so that our customers are protected. So my hat is off to you.
To all our listeners out there, thank you so much for listening. We hope you found this useful. Please don't go breaking into people's houses and stay safe and we'll see you next time. Thank you.