Skip to main content
MSRC

Microsoft Security Response Center Blog

Azure Security Lab: a new space for Azure research and collaboration

Monday, August 05, 2019

Azure is exceptionally secure. To help keep it that way, we are doubling the top bounty reward for Azure vulnerabilities to $40,000. But we aren’t stopping there. To make it easier for security researchers to confidently and aggressively test Azure, we are inviting a select group of talented individuals to come and do their worst to emulate criminal hackers in a customer-safe cloud environment called the Azure Security Lab.

Corporate IoT - a path to intrusion

Monday, August 05, 2019

Several sources estimate that by the year 2020 some 50 billion IoT devices will be deployed worldwide. IoT devices are purposefully designed to connect to a network and many are simply connected to the internet with little management or oversight. Such devices still must be identifiable, maintained, and monitored by security teams, especially in large complex enterprises.

Recognizing Security Researchers in 2019

Tuesday, July 30, 2019

Who’s going to be on the Most Valuable Security Researcher list at Black Hat USA 2019? We’re not announcing the names—yet—but this is how we’ll determine who’s there. How do we define the Most Valuable Security Researchers? The list at Black Hat will be the top tier of researchers based on not just the volume of the reports, but also the impact and accuracy of their reports.

It’s Official – The Way We Recognize Our Security Researchers

Monday, July 29, 2019

We deeply appreciate the partnership of the many talented security researchers who report vulnerabilities to Microsoft through Coordinated Vulnerability Disclosure. We pay bounties for research in key areas, and each year at Black Hat USA, we’ve recognized the most impactful researchers helping to protect the ecosystem. That’s not changing; we’re continuing to expand our bounty programs and will continue to recognize researchers with the greatest impact on the security ecosystem.

Microsoft Announces Top Contributing Partners in the Microsoft Active Protections Program (MAPP)

Thursday, July 25, 2019

Today we announce the top organizational candidates for Vulnerability Top Contributors, Threat Indicator Top Submitters, and Zero-Day Top Reporting for the period of July 1, 2018 – June 30, 2019. The Microsoft Active Protections Program provides security and protection to customers through cooperation and collaboration with industry leading partners. This bi-directional sharing program of threat and vulnerability data has proven instrumental to help prevent broad attacks and quickly resolve security vulnerabilities in Microsoft products and services.

Why Rust for safe systems programming

Monday, July 22, 2019

In this series, we have explored the need for proactive measures to eliminate a class of vulnerabilities and walked through some examples of memory safety issues we’ve found in Microsoft code that could have been avoided with a different language. Now we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available.

We need a safer systems programming language

Thursday, July 18, 2019

In our first post in this series, we discussed the need for proactively addressing memory safety issues. Tools and guidance are demonstrably not preventing this class of vulnerabilities; memory safety issues have represented almost the same proportion of vulnerabilities assigned a CVE for over a decade. We feel that using memory-safe languages will mitigate this in ways that tools and training have not been able to.

A proactive approach to more secure code

Tuesday, July 16, 2019

What if we could eliminate an entire class of vulnerabilities before they ever happened? Since 2004, the Microsoft Security Response Centre (MSRC) has triaged every reported Microsoft security vulnerability. From all that triage one astonishing fact sticks out: as Matt Miller discussed in his 2019 presentation at BlueHat IL, the majority of vulnerabilities fixed and with a CVE assigned are caused by developers inadvertently inserting memory corruption bugs into their C and C++ code.