Behind the Scenes and Best Practices for Submitting to MSRC with Jim Hull

Nic Fillingham: Since 2005, BlueHat has been where the security research community and Microsoft come together as peers.

Wendy Zenone: To debate and discuss, share and challenge, celebrate and learn.

Nic Fillingham: On the BlueHat podcast, join me, Nic Fillingham.

Wendy Zenone: And me, Wendy Zanone, for conversations with researchers, responders, and industry leaders, both inside and outside of Microsoft.

Nic Fillingham: Working to secure the planet's technology and create a safer world for all.

Wendy Zenone: And now, on with the BlueHat Podcast. [ Music ]

Nic Fillingham: Welcome to the BlueHat Podcast, Jim Hull. Jim, thank you for joining us.

Jim Hull: Hello, everybody. How are you?

Nic Fillingham: We're doing well. Great to have you. So today, a little bit of a different episode for the BlueHat Podcast. We launched back in July, a new page on the MSRC website that's called the MSRC Researcher Resource Center, and one of the things that's on this page is a video. It's about 24 minutes. You might recognize the voiceover if you listen to this podcast, where we walk through the process and a little bit of context of submitting a case or a submission to MSRC. And so that video, it starts with what is MSRC, the sort of the roles and the functions, the goals, and then we talk about the case management process. And we talk about everything that sort of goes on behind the scenes, and then we finish up with some tips and tricks. And the idea is that this is a new page for researchers that have not submitted to MSRC before and want to learn about the process and what to expect. And Jim, you were the brain behind a lot of this content. You helped us create a lot of this content and helped us demystify and understand some of the processes. So we thought we'd bring you on the podcast and we can talk about that. So could you introduce yourself to the listeners? Who are you and what do you do at MSRC?

Jim Hull: Sure. My name is Jim, Jim Hull. I've been working in this role for approximately four years, and what I do on a daily basis is essentially review reports sent in by researchers for potential vulnerabilities on our products. And from that point, it's a matter of putting those reports into a process, and we'll probably go over that. But that's essentially what I do and ensure that this case, this product vulnerability, is resolved in a certain amount of time.

Nic Fillingham: Are you a case manager? Is that the correct title for what you do, Jim? Or are you doing something else in the process?

Jim Hull: I'm a program manager, and TPM is our title, and we essentially manage cases, but we're reaching across to different organizations, even outside our own company, at times, to resolve issues that are vulnerabilities in our products.

Nic Fillingham: All right. Well, I figured we could sort of step through this somewhat chronologically. We might skip the little introductory part of the video that sort of introduces MSRC and talks about what MSRC does. It's interesting, but it's on the page. We'll put the link in the show notes for folks to go and check that out later on. But Jim, could you just start at the sort of 40,000-foot view? Who is it that is going to submit something to MSRC? What's the scenario where a researcher, maybe even step back from there, like who submits to MSRC? What does it mean to be a researcher? Is that too broad of a question to start with, or is that a good place to start?

Jim Hull: Typically, it's anybody, anybody who has interest in, for example, finding or identifying vulnerabilities in any piece of software product. They can have different, I would say, ilks or walks of life. It could be somebody who just has interest. It could be a professional who does this daily as part of their job, their role. Certainly, the backgrounds vary. There's no specific background that I'm aware of, but I think the fundamental, or the basis for a lot of this, is that people have a keen interest, probably has a fascination for finding the missing piece of a puzzle.

Wendy Zenone: Can anyone be a researcher? Is there a process that you go in and you register to be a researcher? So if someone that might be listening to this maybe wants to jump in and participate, what is the next step they need to take to get to the point of looking for things and submitting findings?

Jim Hull: Sure. So registering, all that sort of thing, that's pretty easy to do. You just essentially have to have an email address and just register through an MSRC portal as a researcher. The products that they want to undertake, most of the time people, are going to regard, look at our MSRC.Microsoft.com blogs and information about which products actually offer bounty. But that won't always be their motivation. Some people, again, just they have the fascination with finding something that's unknown. Just to clarify, once again, if they have any interest whatsoever, they're probably going to pick a specific product, we have so many, and focus on that.

Nic Fillingham: I just want to also clarify the thing that you said there, Jim, is that there's like no qualification or certification or anything you have to have. It's not about -- to be a researcher that submits to MSRC, you don't have to have a particular degree or a cert or something. We say the word researcher, but it's really just anybody who either proactively or reactively discovers some sort of flaw or vulnerability or issue that they think Microsoft should know about and Microsoft should go fix, and then they submit it via the MSRC Researcher Portal. Would you agree with that?

Jim Hull: That's perfectly accurate. There is no pedigree. Anybody who has interest, essentially.

Nic Fillingham: That is awesome. So again, we will put the link in the show notes for this video, which sort of walks through the process that we're referencing today. I want to jump to about, I don't know, a couple of minutes in where we talk about the types of reports that MSRC accepts, and this is sort of an interesting point to start with or an interesting place to start because MSRC, that's the Microsoft Security Response Center, that is the division, the group inside of Microsoft that's responsible for accepting the submissions and for triaging them and then project managing the way that they get addressed and then publishing the fixes and guidance, et cetera. But there are reports or there are submissions that MSRC accepts, and there are also types of submissions that MSRC does not. So Jim, I don't know if you have it up in front of you, but I wondered if we could talk at a high level at what the typical types of report submissions are that MSRC submits, and I can read them out if that would be helpful. I've got them in front of me here. So a couple of different categories. We have security threats, which is really what we call vulnerabilities or generally referred to as a vulnerability. But there's also URL-related threats, IP address-related threats, OAuth application issues, as well as Azure Community Gallery issues that have sort of been discovered. Jim, I think when we were creating this content, one of the stats that you presented was that the vast majority of submissions are in that very first category, vulnerabilities or security threats. Anything you want to say about these types of reports and, for example, like what's a URL-related threat versus an IP address threat, et cetera, et cetera? Anything worth highlighting here?

Jim Hull: Well, I think most of the time our researchers are going to know precisely what you're referring to. The idea is that any report that we receive has to have some requisites, and this is all listed on our webpage, essentially. And the basis for us processing the report during our triage is that we need to have certain things, such as a valid proof of concept, and a proof of concept is going to walk us through what it is that you're reporting. Simple as that, and within the proof of concept, you're going to show us step-by-step what is the way to reproduce this potential vulnerability, and that is almost paramount. That is very important. Otherwise, we're going to go back and forth a lot, and ostensibly, we need to be able to reproduce this vulnerability. Once we have this report and we triage it, which can take one to three days at times, we're going to assess it for progressing it to the next stage. And we want to see step-by-step details, step-by-step how to reproduce, your proof of concept, and most importantly, we need to be able to see it, visually see what you're describing as a vulnerability. That's very important in that we're not going to waste a lot of time on to, again, the magic word is reproduce. Once that is done, we've triaged this report, we've moved it into a case stage. And once the case is essentially created, we're going to engage our reproduction engineer. We call them our reaction engineers. They're going to make sure that they can reproduce it at first level. And it's at that point, often, that we'll go back and forth with the reproduction engineer if they're missing any information that's needed.

Nic Fillingham: Thank you for teeing all that up because we're going to dive into each of those sections much more in the conversation. I think I just want to come back to one little quick thing here, which is about those types of reports that are submitted to MSRC. Because, for example, if you go in the video and you pause, you'll see there's actually -- there's a few things that get called out as things that do get reported to MSRC, but actually isn't technically a vulnerability or isn't technically a security issue, and it's things like spam. If you get sent spam in your inbox, that is certainly something that Microsoft doesn't want to have happen. And there are various teams and groups inside of Microsoft. But there is a bar or there is a breakpoint where an email that you might receive as spam actually does need to go to MSRC because it is abuse of perhaps a Microsoft-owned domain or a Microsoft-owned email service, et cetera, versus just you being the sort of recipient of a piece of junk email. Things like tech support scams, which we know, unfortunately, are all too prevalent, there's a specific team at Microsoft that is responsible for going and chasing those down. And that's actually part of, I believe, the legal group. And then there are other things like if you find a URL that has been flagged as unsafe or potentially unsafe, that's more related to, I believe, the Bing team who keep that massive database of URLs and what's considered safe or not. So just to sort of put a finer point on that one, there is a list of things that MSRC does accept and there is a list of things that MSRC does not but are other teams with inside of Microsoft. And so I think, Jim, as I said, we're going to dive into each of these parts of the case management process. How does someone know when they have something that should be submitted to MSRC versus, as I said, like a piece of spam?

Jim Hull: Yeah, that can be a wide, broad array of different products or types of exploits, types of vulnerabilities. So, for example, if you see a piece of spam, and I think at this point, a lot of us are mature enough in our roles and certainly with technology that we're starting to pick up on spam. We're starting to see what the nuances are and more or less disregard or delete them, what have you. But once in a while, you'll see something that looks pretty real, but you still have a caution. You still feel like this is something I need to click on or I need to forward to somebody. That we might want to see. We might want to see what's going on there and, of course, submit that to the MSRC portal. Certainly, if you have URLs, domain names, IP addresses, again, that might be potentially malicious. Who knows? It's just a matter of if it looks like or feels like it's something that just doesn't fit. It just doesn't seem right, let's take a look at that, please because that might be something, an indicator, of two bigger things that are going on.

Nic Fillingham: All right. Well, let's start at the beginning. So, hypothetically, Jim, I've submitted my first report to MSRC. Now we're going to get into a little bit of nuance here in the actual process that you talked about just a minute ago. So, when I hit that submit button, what happens next? At what point is there someone like you, a human being, that is looking at what I have submitted and maybe making a decision as to severity or what the next step is or looping in a React engineer? So, once I hit submit, what happens and what should I expect from that point forward?

Jim Hull: Sure. So once you submit the report, you're going to receive what we call a vulnerability ID. This isn't a case number yet. Vulnerability ID is essentially for you to help track and for us to track a report. So, we have between one to three days to triage this report. And without exception, once we triage the report, we're either going to progress it into a case with all the requisites I discussed, and then once that case is established, it's a matter of the next person in the process is going to be your reaction engineer. They are going to see if they can reproduce this vulnerability on the basis of what was submitted from the researcher. This analysis from the reaction engineer can take up to five to 10 business days at times. It just depends on volume, what's going on, a lot of different factors. But we try very hard to keep it probably within five business days if we can. Once that is done, so we either are going to say this is a critical, important, or moderate or low-impact analysis. MSRC does not handle low or moderate-impact assessments for our products with the exception of our browser, our Edge product. Once this is assessed, then the next thing we are going to do is engage our product engineers, and the product engineers are going to essentially assess this again. And this can take anywhere from, again, like five business days to essentially assess, but again, we're working on a clock at this point. So once that case is established, we have a certain amount of time, depending on the impact on the severity, to resolve this issue. The product engineers will assess this, and then they'll start their activity of resolving or fixing this problem, and this can take anywhere from a couple of hours to six months. It just depends on the severity. It can depend on the complexity of the vulnerability. Certainly, when that is assessed, then they start the fix process, and that can take up to, like I mentioned, fixing also includes the final rollout of the fix. So that timeline is within that fix process, I'll call it, or fix release. Once the fix is released, we more or less contact the researcher who submitted this report to us. And from that point, we congratulate them that this has been resolved and they are free to do what they wish with it at that point, and we close out the case. We complete it.

Wendy Zenone: From the moment that a researcher submits to the point where you reach out and say, you can do with it what you want, we're at that stage, what coms do they receive in between? Does it just go in, and they don't hear anything until that point? Or are there communications between now and then that says, you know, hey, we're at this stage, we're at this stage, or so on and so forth, so they understand what's going on on the back end?

Jim Hull: Sure. We do communicate with the researchers frequently, and that's just to apprise them of where we are with their case. Certainly, this is interactive. In other words, the researcher can see what the stage is in their portal of where we are with this particular case.

Wendy Zenone: Nice.

Jim Hull: But they always typically are going to have questions about what's next or where are you with the fix, and we respond accordingly. But typically, we respond just to keep things fluid and make sure everybody's on the same page and there isn't a lot of guesswork going on at that point.

Nic Fillingham: Jim, so you talked about the amount of time and you said some fixes take a matter of hours and some can take a matter of months. That's obviously a huge range, and I assume many submitters, finders, researchers, they're going to want to know where they're going to fall on that spectrum and how long their case may take to resolve. In this video that we keep referencing to, and if you're joining the podcast now, there will be a link in the show notes. You can find it on the MSRC website. It's called the MSRC Researcher Resource Center. We do talk about this. We talk about, okay, how long does it take and what factors can influence duration? And so, Jim, you and I spent a lot of time talking about this when we were creating this video, and my understanding is that the left-hand side of this range of sort of the shorter time frame and the right-hand side obviously being the longest time frame. So the shorter time frame to address issues, that's going to be when things are a cloud service. So something that's sitting in Microsoft's cloud, something that is current and obviously public and in production, and then there's also an element here that the researcher -- and there's two other elements here. So, it's in the cloud. It's a cloud service. It's a current production service. There's evidence of an active exploit, which can often be a little hard to assess, but we can talk about that, and then the severity rating is critical. So that's on the left-hand side of the shortest time possible to potentially resolve. And on the opposite side, you have on-premises software, and the difference here being that that means that the owner of that infrastructure, whether it's a private cloud or an endpoint, they have to go and actually install or make any sort of changes to deploy the fix. Non-current versions, so obviously stuff that isn't the latest release, exploits or vulnerabilities where they can't actually see or find or show that it's actually active in the wild, and then low severity or moderate and low severity. So is that the right way to think about that range of on the left-hand side, cloud, current version, active exploit, critical severity, and then on the right-hand side, it's on-premise, non-current version. So, is that too cut and dry, too simple, or is that a good way to think about the range?

Jim Hull: No. That's a perfect way to see this. Certainly, in your cloud services, if you would have a critical vulnerability presented by a researcher, we're going to focus on that right away. There's a lot of implications there, and typically, they're going to get resolved within one to two weeks. That's typical, if not shorter, and on the other end of the spectrum, like you discussed, you know, low severity, there are probably going to be issues that are added to the product engineering products organization's backlog. So they can eventually get to that and address that low severity vulnerability. So what's here is perfectly right.

Wendy Zenone: Is there anything researchers can do to impact case duration?

Jim Hull: I think from the onset, when they submit, if they can provide all the requisites that we ask for a high-quality report, the more information we have, the faster this will go and the more accurate we can be with the assessment. It's real important to get a good, high-quality report.

Wendy Zenone: I assume that's a honed skill. You're first starting out something that you learn from others and maybe see other examples and you grow with your submission over time.

Jim Hull: Yeah. So, what we're trying to do with this particular activity here is we're helping researchers or potential researchers to understand the differences between a low and high-quality report.

Wendy Zenone: Yeah.

Jim Hull: Low-quality reports are not going to have all the requisites. Most of the time, we're going to go back for more information. So, there's a delay. Because we're on a clock, we're on a timeline to fix whatever has been presented. That can eat away at our time. We might have to go back and ask for more time from the researcher as part of our CVD. Certainly, high-quality reports, they're going to allow our Reaction engineer to quickly assess what the issue might be, and certainly, it's going to help out our product engineers. There's not going to be a lot of back and forth as far as what is actually being discussed here. That's really, really, important.

Nic Fillingham: This would be a good time, I think, maybe, Jim, to actually dive into some of these elements that make up, you know, these high-quality reports. First of all, so low, medium, high-quality reports, so that says to me that there is some sort of assessment that happens at some point where it's decided this submission is high-quality because it has everything on the checklist. This submission is medium quality because perhaps it's missing key elements, and then this submission is low. Does that happen in the process? Or is this something that's sort of determined after the fact, this low, medium, high assessment, and then we'll talk about the individual elements?

Jim Hull: Yes. So, our Reaction engineers, our handoff to start this process, is that they are going to assess this case at this point as to what is the impact it's going to make on this product or service? And without a doubt, the more information, the better we're going to understand something, and the less information is going to be us trying to address everything. So it kind of eats away at time. Again, we're on a clock. It's very important that we move this along. So, high-quality reports are going to have several different items, such as, certainly, we want a good description of what it is that you're reporting. There's several others in the checklist, but I'm just giving you a high level, a very good description about what it is and what it can do to the product. What is this vulnerability capable of? Then we're looking for, and I mentioned this previously, a good proof of concept. What is it that you're trying to tell us that is a vulnerability in our product? And walk us through, show us what you're discussing, what you're presenting. And then this report needs to have steps. You know, step us through what it is that you're wanting us to see. Details are important. You don't have to write a book here, but relevant information is very important. When we get off into lower-quality reports, well, there's things missing. We're actually, I would say at times, going back and asking for videos. You know, videos really kind of work the best, I think, at least what I've seen, or a series of images that, again, are kind of stepping through what the issue might be. Medium reports, medium quality, they tend to leave out one or two key issues or key items, such as they're missing a proof of concept. They have wonderful description write-ups about what it will do, wonderful description about the steps to reproduce it, but we're missing the key part. And from that point, you might have an email back and forth with your TPM asking for additional information, and that just delays things to a degree. But high-quality reports, they tend to get things done quickly.

Nic Fillingham: So I've actually got the list here in front of me, Jim, and I thought I might just sort of read it through because all of the elements that make up a high-quality report, so it's including the product, service, or the component that's impacted. So it's correctly identifying what is the product, the service, or the component, and that includes the version, and being very clear on the subversion or the very, very specific version of what's being impacted. It is the vulnerability type that you believe you've discovered. It is the impact of that vulnerability. It is the target environment, which includes the reproduction environment necessary for that vulnerability. The detailed reproduction steps, as you said, Jim, the proof of concept and a working proof of concept, and I like here that you talked about video as being a really great tool or a great asset to show a working proof of concept. And when you are in the researcher portal and submitting your findings, there is a way to upload video assets, images, et cetera, et cetera, that can help support your case. But then also, we really want from you, the researcher, a detailed analysis of the findings. And I'll pause there, Jim. I often give you credit for saying this. I'm not sure if it was you, though. You can take the credit. I remember someone telling me a while back that, oftentimes, when a researcher has found something that they are submitting to Microsoft, at that moment in time, they're actually probably the expert on that very, very specific thing that they've found. They're the first person to have found it. And so, a lot of the times, the submitter actually knows the most about this very, very specific scenario that they have discovered. In some ways, it seems counterintuitive because you would think, oh, well, the engineers who build the product or build the service, they're going to be also at the same level or sort of depth, and that is absolutely true in some sense. But when the submitter is finding this vulnerability, this exploit, this issue for that very specific thing that they have discovered, they are the expert. And so, we actually need them to brain dump to us everything that they know because they're actually the expert. I think -- I give you credit for that, Jim. Is that something that you've said in the past?

Jim Hull: I'm not sure I did that, but you're very much spot on there. At that point, when they're looking at some potential vulnerability, they are indeed the expert, and it's really a matter of how can they convey that to us so that we can see what they're seeing because we want to? And whatever they might offer as, for example, a potential remediation. What do you think? Because again, they're the ones who've seen this. They observed it. They've reproduced it, and what do they think is a potential way of seeing this differently? How did you find it? That's always important to us because we're not going to exactly trip over this. We're going to have to watch this methodically to reproduce it.

Wendy Zenone: Do you ever have it where a researcher submits a finding, and it's graded, whatever it's graded in the severity level, but in communicating with that researcher, they come, and they explain what it is they saw and why they feel it should be into a different category. Does that ever happen, and do we have that conversation and go, okay, we didn't see it in that light. Yes, you're right. It should go that way or absolutely not. This is still a level whatever. Does that interaction happen?

Jim Hull: Absolutely. This does happen. It doesn't happen often, but I don't think we would get a lot done if we're going back and forth constantly for reassessment, but we do ask for additional clarity. For example, we assess something as a moderate impact. So typically, we don't handle moderate impacts or low impact. So the researcher will say, yeah, I really believe this is an important impact, and we ask for, well, what else can you provide or what else other insight can you give us that'll help us elevate that to an important impact assessment?

Nic Fillingham: Okay. So the person listening to this podcast hasn't submitted before, or maybe they've submitted once or twice, but let's assume they haven't submitted. They've found something. Could be proactively they were looking, could be they stumbled upon it. They're going to submit their first-ever report. They might not necessarily know if they have all the elements for a high-quality report. Where should they absolutely, bare minimum, make sure that they invest their time and energy? If you're submitting something for the very first time, make sure no matter what you do, you don't skip which elements? I don't want to say like which elements can be skipped, but I think it's more like I'm a first-time submitter. Where should I be prioritizing my time in the documentation assets I'm creating for a submission?

Jim Hull: Yeah. Well, first of all, we're not always going to know who's a first submitter. So let us know. We're always happy to learn that.

Nic Fillingham: Oh, that's a good point.

Jim Hull: I would think without exception, we really need to have a valid proof of concept, and if you can include a video, that will really be a great starting point for us. If you're unable to, for example, give us the detailed written step-by-step instructions, at least in the proof of concept, walk us through. Oh, this is step one. This is step two. Walk us through this so we can reproduce it, but without exception, that's what we're certainly looking for, and including video or images, as well.

Nic Fillingham: That's great, and I think Wendy asked early on is we're not expecting every researcher for their first submission to have this beautiful, perfect, flawless, you know, case-study-level submission. It's a process, right? So, you know, invariably, someone submits their very first report, and they haven't done it before, and so maybe they inadvertently are a little too brief. And then Jim, someone like you or on the team comes back to them and says, we think you've got something here, but can we get some more information? And then over time, they'll invariably, the finders are going to be providing more detailed information. Do you see that sort of evolution with researchers that have submitted multiple times?

Jim Hull: Absolutely. We've had young folks who submitted reports before, people who were in school. Again, the different walks who -- or walks of life that it will submit reports is various. It's all across the board. But yeah, when they initially start their first report they submit, I would see quite a few mention, this is my first report, and that's totally exciting for us, actually, and we love to learn that. But yeah, please get a proof of concept in there. Please detail as much as you can about what you're seeing. That will help us.

Nic Fillingham: Fantastic. Wendy, you had a question?

Wendy Zenone: I was just wondering if there are any age restrictions. Can anyone become a researcher? Is there an age limit that you require? You know, like is there a 10-year-old out there that decides to poke around and find something? Do we say, hey, we really would like you to be 16, 18?

Nic Fillingham: I think on our page there's a mention of an age limit, but I think anybody, you know, they can work through their parents, that sort of thing. They can certainly make sure that that's okay and submit what they have. There may be some restrictions or just additional steps to go through for minors if they've qualified for a bounty and receiving a bounty payment. That may make things a little bit more complicated, but there's no gate that I'm aware of, Jim, for actually submitting a report. So as you say, Wendy, like middle schooler finds a bug in Edge, like submit it. Let us know.

Wendy Zenone: That's awesome.

Nic Fillingham: So we're coming up on time here, and I thought we could finish on a graphic at the very end of this video. Again, link is in the show notes, which is tips and tricks for submitting to MSRC. With three columns here, it's things to do, things to not do, and then the third column is reminders or things to remember throughout the process. Obviously, in that first column at the very top, it says "Always create and submit high-quality reports." And I think just to clarify that from what you said there, Jim, like, you know, that's the best-case scenario. If you can submit all the elements of a high-quality report, if you have all those elements, if you know all those elements, don't skip them. Please, please, please, submit them to us. But if you don't, or this is your first time, that proof of concept, that working proof of concept, as well as steps, that's the critical thing. Is that right, Jim? Would you agree with that?

Jim Hull: Yes, I do, and without a doubt, this high-quality report is pretty much the basis for a lot of additional things. Like in this particular tips and tricks, you could end up, you know, presenting this at BlueHat, for example. Certainly, your bounty award could be based on the quality of the report, and we can make a safer product all around. So if we really understand what you're presenting to us, that helps.

Nic Fillingham: There's another point here that maybe isn't super obvious. Maybe we could just sort of touch on it, which is about using the researcher portal for all communication with MSRC, and that is compared to using email or social media. Can you just briefly talk about that, Jim? Why is it so important to use the researcher portal versus email or Twitter or whatever?

Jim Hull: Yeah. At times, this does happen, but we really want to work with the researcher one-on-one. If you're, for any reasons, not getting a response from your case manager or TPM, send us an email to secure@microsoft.com, and just mention you're not hearing anything from your TPM on your case. If you're not getting anywhere, then that's probably the best place to reach out and try to contact somebody, and you will get a response. I'll almost guarantee it. We want to understand if there's additional issues. We want to work with you on the vulnerability disclosure. We don't want you to, for example, submit a case to us. Then for whatever reason, you might want to go ahead and give this, basically, disclose this vulnerability to the world. We want to work with you. And please, by all means, send an email if you're not getting a response through the portal, but your portal is the best place. That's where we interact with you, particularly on a secure message medium. So that's the place where we need to work.

Nic Fillingham: So security is certainly one of the reasons, and then also being able to have those sort of one-to-one conversations and engagements with researchers. That's what the researcher portal is there for, as well as it being a very secure medium for those conversations. Yeah, anything else that stands out on that list there for you, Jim, that you want to highlight for either things to do or things to not do with regards to submitting?

Jim Hull: Sure, and just the third item in this, know which products are in bounty. It's all listed on our MSRC website, which platform, which specific products are bounty eligible. If you look at the presentation, the webpage, is going to be something like, we reward for so much for this product, depending on the impact that the vulnerability will make, so that's real important. And I think we get a lot of back and forth with researchers on bounty eligibility, and take a good look at that. If it's not understood, then let us know. We'll explain it better, certainly.

Nic Fillingham: Awesome. I think we're almost done here. I think just maybe finally wrapping up, there's a couple of good things to remember in that final column, and I think, Jim, you've touched on all these. The first is that not everything that is submitted turns into a case, and you talked about, if there are low or moderate-severity issues, sometimes those don't get turned into a case, or if there isn't enough information necessary to warrant the creation of a case, there are a number of factors where a submission that MSRC receives won't result in a case being created. So it's important to remember that, but that doesn't mean it's the end of the story. That just means that it's an opportunity for that submitter to provide more information to help create the justification for a case. Jump in if you want to clarify anything there, Jim.

Jim Hull: Sure. Just -- these are good points. It's something to remember. So not all cases or all reports are accepted and cased, and that's true. You go back to what are the requisites? What is it we need to see? Not all cases are eligible for bounty. We have certain products we want more focus on. So there's going to be additional focus on that product and if it's bounty eligible or not. That's true. Bounty awards are targeted for the highest impact. That's true. Good thing to remember. We have a timeline we discussed, and certainly, we'll let the researcher know when we are in the development stage of the case and when we go into potential release for the fix. So we try our very best to share this with the researcher, and we respond to messages.

Nic Fillingham: Awesome. I think we might close with the final point here on the tips and tricks, which is if you have feedback on working with MSRC, we would love to hear it. If you have watched this video that we keep referring to, and you feel like there's some opportunities for clarification, if you would like to learn more about how something works, if you have had a positive experience you would like to share, we'd love to hear that. If you've had an experience that you think we need to learn from to improve, that's also very important. And so we have an email address that's set up for just those conversations and that is msrclistens, msrclistens@microsoft.com. I believe that just goes straight to Jim's inbox, and he's going to respond to each of you personally. Is that right, Jim?

Jim Hull: Yeah. No.

Nic Fillingham: That goes to a team of people. Please, if you have feedback on the process, positive, negative, or neutral, we would love to hear from you, and we also want to make sure we're creating great content that help researchers. So if you need to know more about the process, you need more breakdowns, you need more tips and tricks, please let us know. Jim, anything you'd like to leave us with?

Jim Hull: Just really appreciate the opportunity to speak to the researchers, and this has been fun.

Nic Fillingham: All right, Jim Hull, thanks so much for joining us.

Wendy Zenone: Thank you.

Jim Hull: My pleasure.

Wendy Zenone: Thank you for joining us for the BlueHat Podcast.

Nic Fillingham: If you have feedback, topic requests, or questions about this episode --

Wendy Zenone: Please email us at bluehat@microsoft.com or message us on Twitter @msftbluehat.

Nic Fillingham: Be sure to subscribe for more conversations and insights from security researchers and responders across the industry --

Wendy Zenone: By visiting bluehatpodcast.com or wherever you get your favorite podcasts. [ Music ]