Szolgáltatóknak

Today, we released security updates to provide additional protections against malicious attackers. As a best practice, we encourage customers to turn on automatic updates. More information about this month’s security updates can be found in the Security Update Guide. MSRC team

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.

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.

Today, we released security updates to provide additional protections against malicious attackers. As a best practice, we encourage customers to turn on automatic updates. More information about this month’s security updates can be found in the Security Update Guide. MSRC team

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.

For the last 20 years, the Microsoft Security Response Center has been an integral part of Microsoft’s commitment to customer security. We are often called on to talk about the work we do and how customers can apply the lessons we have learned over that period to better their security posture.

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.

Today, we released security updates to provide additional protections against malicious attackers. As a best practice, we encourage customers to turn on automatic updates. More information about this month’s security updates can be found on the Security Update Guide. MSRC team

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).

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.