Home arrow Microsoft
Microsoft Security Response Center
  • Microsoft Bounty Programs Expansion – Azure and Project Spartan

    I am excited to announce significant expansions to the Microsoft Bounty Programs. We are evolving the 'Online Services Bug Bounty, launching a new bounty for Project Spartan, and updating the Mitigation Bypass Bounty.

    This continued evolution includes additions to the Online Services Bug Bounty Program:

    • Azure
      • Azure is Microsoft’s cloud platform and the backbone of Microsoft cloud services.
      • This program will include a number of Azure services, such as: Azure virtual machines, Azure Cloud Services, Azure Storage, Azure Active Directory and much more
    • Sway.com
      • Sway.com is a web application that lets users express ideas in an entirely new way across many devices and platforms
    • Raising the maximum payout for the Online Services Bounty Program
      • We will pay up to $15,000 USD for critical bugs, as always, more for more impactful and better documented bugs.

    We’re also launching a new bounty related to the Windows 10 Technical Preview:

    • Project Spartan Bug Bounty
      • Microsoft’s new browser will be the onramp to the internet for millions of users when Windows 10 launches later this year. Securing this platform is a top priority for the browser team.
      • This bounty includes Remote Code Execution and Sandbox Escapes, as well as design-level security bugs.
        • Always be sure to use the latest version released in the Windows 10 Technical Preview
      • Microsoft will pay up to $15,000 USD for security vulnerabilities reported in Project Spartan, you can see the specifics in the program terms. Don’t hesitate as the Project Spartan Bug Bounty will run from April 22, 2015 to June 22, 2015
        • The bounties for Spartan are tiered by the criticality of the issue reported, as well as the quality of the documentation and how reproducible the issue is.

    The Mitigation Bypass bounty and the Bonus bounty for Defense are both very active, paying up to $100,000 USD for novel methods to bypass active mitigations (e.g. ASLR and DEP) in our latest released version of operating system (currently Windows 8.1 and Server 2012 R2) and a bonus of up to $50,000 USD for actionable defense techniques to the reported bypass. We have one addition to the Mitigation bypass bounty:

    • Hyper-V escape
      • Guest-to-Host
      • Guest-to-Guest
      • Guest-to-Host DoS (non-distributed, from a single guest)

    These important additions to the Bounty Programs reflect the continued shift and evolution of technology towards the cloud. The additions to the bounty program will be part of the rigorous security programs at Microsoft. They will be worked alongside the Security Development Lifecycle (SDL), Operational Security Assurance (OSA) framework, regular penetration testing of our products and services and Security and Compliance Accreditations by third party audits.

    Microsoft has a long history of working closely with security researchers. Having personally done penetration testing and exploit mitigation, I understand that this is intense and difficult work. I can say that we truly value these contributions. Bug bounties are an increasingly important part of the vulnerability research and defense ecosystem and will continue to evolve over time. We will be regularly managing the Microsoft Bounty Programs to help us best protect our many users.

    Mark Russinovich will be sharing some information in his “Assume Breach: An Inside Look at Cloud Service Provider Security” talk. You can also come by the Microsoft Booth at RSA on April 23, 2PM for a Bounty Program Q&A or you can always find the most up to date information about our bounty programs at https://aka.ms/BugBounty and in the associated terms and FAQs.

    I’m looking forward to seeing some great submissions!

    Jason Shirk



  • April 2015 Updates

    Today, as part of Update Tuesday, we released 11 security bulletins.

    We encourage customers to apply all of these updates. For more information about this month’s security updates, including the detailed view of the Exploitability Index (XI), visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate the XI, a full description can be found here.

    We released one new Security Advisory:

    OneSecurityAdvisory wasrevised:

    For the latest information, you can follow the Microsoft Security Response Center (MSRC) team on Twitter at @MSFTSecResponse.

    MSRC Team



  • March 2015 Updates

    Today, as part of Update Tuesday, we released 14 security bulletins to address vulnerabilities in Microsoft Windows, Microsoft Office, Microsoft Exchange, and Internet Explorer.

    We encourage customers to apply all of these updates. For more information about this month’s security updates, including the detailed view of the Exploitability Index (XI) broken down by each Common Vulnerabilities and Exposures (CVE), visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate the XI, a full description can be found here.

    We released one new Security Advisory:

    Two Security Advisories were revised:

    For the latest information, you can follow the Microsoft Security Response Center (MSRC) team on Twitter at @MSFTSecResponse.

    MSRC Team



  • Security Advisory 3046015 released

    Today, we released Security Advisory 3046015 to provide guidance to customers in response to the SSL/TLS issue referred to by researchers as “FREAK” (Factoring attack on RSA-EXPORT Keys).

    Our investigation continues and we’ll take the necessary steps to protect our customers.

    MSRC Team



  • February 2015 Updates

    Today, as part of Update Tuesday, we released nine security bulletins – three rated Critical and six rated Important in severity, to address 56 unique Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Microsoft Office, Internet Explorer, and Microsoft Server software.

    We encourage you to apply all of these updates. For more information about this month’s security updates, including the detailed view of the Exploitability Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate the XI, a full description can be found here.

    We re-released one Security Bulletin:

    One new Security Advisory was released:

    One Security Advisory was revised:

    We also announced changes related to SSL 3.0 and you can read more about these on the IE blog.

    For the latest information, you can follow the Microsoft Security Response Center (MSRC) team on Twitter at @MSFTSecResponse.

    MSRC Team



  • January 2015 Updates

    Today, as part of Update Tuesday, we released eight security updates – one rated Critical and seven rated Important in severity, to address eight unique Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows.

    We encourage you to apply all of these updates. For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

    We re-released one Security Bulletin:

    One Security Advisory was revised:

    For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

    MSRC Team



  • A Call for Better Coordinated Vulnerability Disclosure

    For years our customers have been in the trenches against cyberattacks in an increasingly complex digital landscape. We’ve been there with you, as have others. And we aren’t going anywhere. Forces often seek to undermine and disrupt technology and people, attempting to weaken the very devices and services people have come to depend on and trust. Just as malicious acts are planned, so too are counter-measures implemented by companies like Microsoft. These efforts aim to protect everyone against a broad spectrum of activity ranging from phishing scams that focus on socially engineered trickery, to sophisticated attacks by persistent and determined adversaries. (And yes, people have a role to play – strong passwords, good policies and practices, keeping current to the best of your ability, detection and response, etc. But we’ll save those topics for another day).

    With all that is going on, this is a time for security researchers and software companies to come together and not stand divided over important protection strategies, such as the disclosure of vulnerabilities and the remediation of them.

    In terms of the software industry at large and each player’s responsibility, we believe in Coordinated Vulnerability Disclosure(CVD). This is a topic that the security technology profession has debated for years. Ultimately, vulnerability collaboration between researchers and vendors is about limiting the field of opportunity so customers and their data are better protected against cyberattacks.

    Those in favor of full, public disclosure believe that this method pushes software vendors to fix vulnerabilities more quickly and makes customers develop and take actions to protect themselves. We disagree. Releasing information absent context or a stated path to further protections, unduly pressures an already complicated technical environment. It is necessary to fully assess the potential vulnerability, design and evaluate against the broader threat landscape, and issue a “fix” before it is disclosed to the public, including those who would use the vulnerability to orchestrate an attack. We are in this latter camp.

    CVD philosophy and action is playing out today as one company - Google - has released information about a vulnerability in a Microsoft product, two days before our planned fix on our well known and coordinated Patch Tuesday cadence, despite our request that they avoid doing so. Specifically, we asked Google to work with us to protect customers by withholding details until Tuesday, January 13, when we will be releasing a fix. Although following through keeps to Google’s announced timeline for disclosure, the decision feels less like principles and more like a “gotcha”, with customers the ones who may suffer as a result. What’s right for Google is not always right for customers. We urge Google to make protection of customers our collective primary goal.

    Microsoft has long believed coordinated disclosure is the right approach and minimizes risk to customers. We believe those who fully disclose a vulnerability before a fix is broadly available are doing a disservice to millions of people and the systems they depend upon. Other companies and individuals believe that full disclosure is necessary because it forces customers to defend themselves, even though the vast majority take no action, being largely reliant on a software provider to release a security update. Even for those able to take preparatory steps, risk is significantly increased by publically announcing information that a cybercriminal could use to orchestrate an attack and assumes those that would take action are made aware of the issue. Of the vulnerabilities privately disclosed through coordinated disclosure practices and fixed each year by all software vendors, we have found that almost none are exploited before a “fix” has been provided to customers, and even after a “fix” is made publicly available only a very small amount are ever exploited. Conversely, the track record of vulnerabilities publicly disclosed before fixes are available for affected products is far worse, with cybercriminals more frequently orchestrating attacks against those who have not or cannot protect themselves.

    Another aspect of the CVD debate has to do with timing – specifically the amount of time that is acceptable before a researcher broadly communicates the existence of a vulnerability. Opinion on this point varies widely. Our approach and one that we have advocated others adopt, is that researchers work with the vendor to deliver an update that protects customers prior to releasing details of the vulnerability. There are certainly cases where lack of response from a vendor(s) challenges that plan, but still the focus should be on protecting customers. You can see our values in action through our own security experts who find and report vulnerabilities in many companies’ products, some of which we receive credit for, and many that are unrecognized publically. We don’t believe it would be right to have our security researchers find vulnerabilities in competitors’ products, apply pressure that a fix should take place in a certain timeframe, and then publically disclose information that could be used to exploit the vulnerability and attack customers before a fix is created.

    Responding to security vulnerabilities can be a complex, extensive and time-consuming process. As a software vendor this is an area in which we have years of experience. Some of the complexity in the timing discussion is rooted in the variety of environments that we as security professionals must consider: real world impact in customer environments, the number of supported platforms the issue exists in, and the complexity of the fix. Vulnerabilities are not all made equal nor according to a well-defined measure. And, an update to an online service can have different complexity and dependencies than a fix to a software product, decade old software platform on which tens of thousands have built applications, or hardware devices. Thoughtful collaboration takes these attributes into account.

    To arrive at a place where important security strategies protect customers, we must work together. We appreciate and recognize the positive collaboration, information sharing and results-orientation underway with many security players today. We ask that researchers privately disclose vulnerabilities to software providers, working with them until a fix is made available before sharing any details publically. It is in that partnership that customers benefit the most. Policies and approaches that limit or ignore that partnership do not benefit the researchers, the software vendors, or our customers. It is a zero sum game where all parties end up injured.

    Let’s face it, no software is perfect. It is, after all, made by human beings. Microsoft has a responsibility to work in our customers’ best interest to address security concerns quickly, comprehensively, and in a manner that continues to enable the vast ecosystem that provides technology to positively impact peoples’ lives. Software is organic, usage patterns and practices change, and new systems are built on top of products that test (and in some cases exceed) the limits of its original design. In many ways that’s the exciting part of software within the rapidly evolving world that we live in. Stating these points isn’t in any way an abdication of responsibility. It is our job to build the best possible software that we can, and to protect it continuously to the very best of our ability. We’re all in.

    Chris Betz
    Senior Director, MSRC
    Trustworthy Computing

    [Note: In our own CVD policy (available at microsoft.com/cvd), we do mention exceptions for cases in which we might release an advisory about a vulnerability in a third party’s software before an update is ready, including when the technical details have become publicly known, when there is evidence of exploitation of an unpatched vulnerability, and when the vendor fails to respond to requests for discussion.]




Angelo Castigliola     View Photos of Angelo (8)
    Send Angelo a Message
Sec and Sec-Tech Newsletter
Email:





Upcoming Events