Skip to main content
MSRC

Microsoft Security Response Center Blog

Should You Send Your Pen Test Report to the MSRC?

Monday, November 12, 2018

Every day, the Microsoft Security Response Center (MSRC) receives vulnerability reports from security researchers, technology/industry partners, and customers. We want those reports, because they help us make our products and services more secure. High-quality reports that include proof of concept, details of an attack or demonstration of a vulnerability, and a detailed writeup of the issue are extremely helpful and actionable.

BlueHat v18 Content Now Available

Friday, October 26, 2018

Last month we wrapped up another great BlueHat event. As an organizer, it is great to hear that the content is so strong that we have participants have to make hard choices on what to attend. BlueHat is about the community we build and the experiences we share. To further support that we are making slides and videos of presentations available publicly.

Standing behind “MSRC Listens”

Tuesday, October 02, 2018

Last week at BlueHat’s “MSRC Listens” session, I took the stage with Mechele Gruhn, manager of the Vulnerability Response PM team, to explain how MSRC is changing our communication, workflows, and tooling to deliver an improved user experience for our partners in the security research community. We promised to communicate more about what’s happening in the MSRC that affects our customers and research partners.

Behind BlueHat: The Art

Monday, September 24, 2018

We are just one day away from the opening of BlueHat v18 and excitement is building. One of the questions that I have gotten more frequently the past couple years is about the artwork we use for BlueHat. So yes there is a theme. 😊 Starting in 2014, we introduced the Top Hat logo which the community took to.

Microsoft Security Servicing Criteria for Windows

Monday, September 10, 2018

One of our goals in the Microsoft Security Response Center (MSRC) is to be more transparent with security researchers and our customers on the criteria we use for determining when we intend to address a reported vulnerability through a security update. Our belief is that improving transparency on this topic helps provide clarity on how we assess risk, sets expectations for the types of vulnerabilities that we intend to service, and facilitates constructive dialogue as the threat landscape evolves over time.

Vulnerability hunting with Semmle QL, part 1

Thursday, August 16, 2018

Previously on this blog, we’ve talked about how MSRC automates the root cause analysis of vulnerabilities reported and found. After doing this, our next step is variant analysis: finding and investigating any variants of the vulnerability. It’s important that we find all such variants and patch them simultaneously, otherwise we bear the risk of these being exploited in the wild. In this post, I’d like to explain the automation we use in variant finding.

For the past year or so, we’ve been augmenting our manual code review processes with Semmle, a third-party static analysis environment. It compiles code to a relational database (the snapshot database – a combination of database and source code), which is queried using Semmle QL, a declarative, object-oriented query language designed for program analysis.

The basic workflow is that, after root cause analysis, we write queries to find code patterns that are semantically similar to the original vulnerability. Any results are triaged as usual and provided to our engineering teams for a fix to be developed. Also, the queries are placed in a central repository to be re-run periodically by MSRC and other security teams. This way, we can scale our variant finding over time and across multiple codebases.

In addition to variant analysis, we’ve been using QL proactively, in our security reviews of source code. This will be the topic of a future blog post. For now, let’s look at some real-world examples inspired by MSRC cases.