Cover Photo by National Cancer Institute on Unsplash
Introduction
In this post, I’m going to talk about becoming a Microsoft Security Researcher. I mentioned this in my last post. I sort of brushed over it but when I was speaking to one of my colleagues and friends about the post just before I published it, he asked me to elaborate a little.
Have you changed job then?
No, I haven’t changed job, nor do I work for Microsoft. Anyone can sign up to be a security researcher as long as they follow the guidelines around doing so.
What made you decide to sign up then?
As I mentioned in that article, as part of building/deploying a solution for a project at work, I (and my colleagues) identified an issue with the security of an Azure VM agent.
Although we worked around it and added our own mitigation to reduce the risk, I wanted to report it to Microsoft and try to improve the products.
Working as a Senior Security Engineer, having a keen interest in improving and ensuring the security of my employer’s systems, and wanting to contribute to the industry, it seemed like the right thing to do.
I may not hunt for bugs/vulnerabilities in my day job nor would I call myself a hacker of any description but that’s beside the point - see something, say something.
The best and correct way to inform Microsoft of a security vulnerability with any of their products is to report it to the Microsoft Security Response Center. Head on over there to read up on what they do.
You mentioned guidelines, what are they?
First of all, does it meet Microsoft’s definition of a security vulnerability?
As a CVE Naming Authority (CNA), Microsoft follows the MITRE.org definition of a security vulnerability which defines a security vulnerability as “a weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, OR availability. Mitigation of the vulnerabilities in this context typically involves coding changes but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).” MITRE.org CNA Rules 7.1
Next up, you should recognise that there are standards of good practice around reporting of security vulnerabilities to allow vendors to understand and remediate them and protect customers against the exploitation of them by malicious actors (criminals).
This is covered by the Coordinated Vulnerability Disclosure process which you can read more about at that link - the key takeaway though is that you should report to the vendor (Microsoft in this case) as soon as possible after discovering the vulnerability and you should not disclose to anyone else publicly or privately until after the vulnerability has been fixed/a patch has been released for it. Always check with the vendor what their policy is and seek approval before disclosing publicly if unsure.
I’ve heard of Bug Bounties, what are they?
In order to incentivise good behaviour, many vendors will take part in one or more Bug Bounty programs. These will offer financial reward for properly reporting security vulnerabilities. They have conditions attached which affect if you will receive a bounty award/payment and how much.
Generally, they are looking for high quality reports that allow the vendor to quickly reproduce the issue reported and assess the impact. They expect you to behave ethically and in accordance with the program rules and their CVD rules (see above).
All vulnerabilities are not equal - for example, as the vulnerability that I reported was in an Azure product, it was assessed against the Microsoft Azure bug bounty program (a full list of current Microsoft bug bounty programs and their rules are available here) - as that program only awards bounties for specific types of vulnerability and also only for those assessed by MSRC as having a Severity of High or Critical, no bounty applies to my reported vulnerability.
However, though that would be a nice bonus, it’s not why I reported the vulnerability anyway.
OK, how do I sign up?
If you decide you do want to report security vulnerabilities to Microsoft, head over to https://msrc.microsoft.com/create-report. You will need to sign in with a Microsoft account (Live Account, Work/School account). You can create one if you have an outlook.com account for example.
The form will guide you through what is required, however at time of writing, you will be asked for:
- Proposed security impact
- Product
- Version/Build
- Title/Short description
- Detail to reproduce up to 10000 characters, you can also upload files
- Acknowledgments do you want to be publicly acknowledged for reporting when it is fixed? Do you have contributors who should also be acknowledged?
What else should I consider?
Do you have permission to take part in bug bounty programs from your employer? Some industries are tightly regulated and prohibit you from taking part. Some employers may not be happy with you taking part, especially if you may get financial remuneration for doing so.
Summary
In this post I talked about my recent signup to be a security researcher and take part in the Microsoft Azure bug bounty program. I talked about my motivations for doing so and what’s involved.
I hope that this has been useful to you!
As ever, thanks for reading and feel free to leave comments down below!
If you like what I do and appreciate the time and effort and expense that goes into my content you can always 