Skip to main content
MSRC

Microsoft Security Response Center Blog

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.

Analysis and mitigation of L1 Terminal Fault (L1TF)

Monday, August 13, 2018

In January 2018, Microsoft released an advisory and security updates for a new class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown). In this blog post, we will provide a technical analysis of a new speculative execution side channel vulnerability known as L1 Terminal Fault (L1TF) which has been assigned CVE-2018-3615 (for SGX), CVE-2018-3620 (for operating systems and SMM), and CVE-2018-3646 (for virtualization).

Microsoft’s Top 100 Security Researchers – Black Hat 2018 Edition

Wednesday, August 08, 2018

This morning we are excited to unveil the security researcher leaderboard at the Black Hat Security Conference. This list recognizes the top security researchers who have contributed research to the Microsoft products and services. If you are curious on how we build the list, check out our blog from last week on The Making of the Top 100 Researcher List.