May You Live in Interesting Times

Handle:
StoneZ

IRL:
Adrian Stone

Rank:
Senior Security Program Manager Lead

Likes:
Predictive Analytics, Game Theory, Databases, Sports Cars, NFL Football, Direct People

Dislikes:
Losing, Liars, Posers, No Talent Clowns

It was two years ago at Black Hat that my colleague Katie Moussouris announced the launch of the Microsoft Vulnerability Research (MSVR) program. Shortly thereafter I assumed ownership of the fledgling program to start making our goals a reality. The primary goal as it was defined sounded simple enough: Protect the larger ecosystem by reporting vulnerabilities in a coordinated manner that were identified by Microsoft resources, with MSVR assisting other vendors as they worked through the challenges of addressing vulnerabilities by sharing some of the lessons learned by Microsoft and the MSRC.

While MSVR’s core mission has stayed the same, in the two years since the program’s inception, the program has grown to take on other challenges as they’ve presented themselves. We’ve done so both because those challenges needed to be addressed and because the coordinated nature of MSCR was the best tool for the job. Some examples of those challenges include MSVR’s role in coordinating several large-scale cross-industry vulnerabilities identified by other external security researchers, such as the DNS Rebinding issue disclosed in 2009 by Dan Kaminsky. Microsoft and MSVR also faced a unique situation in coordinating the remediation of a vulnerability in Microsoft’s own code that affected vendors across the ecosystem as a result of the ATL Killbit Bypass vulnerability discovered by Ryan Smith and David Dewey. .

MSVR has also assisted in reporting to vendors instances of zero-day attacks against their products, which were discovered as a result of the telemetry and other threat-detection resources built into the fabric of the MSRC’s response process. MSVR is not intended to serve as a CERT entity; however, we felt leveraging MSVR for these cases was imperative because a vulnerability affected code in both Microsoft and other vendor products.

So what have we learned? For starters, the security maturity of vendors across the ecosystem varies wildly, as you might expect. Sometimes just finding the right organizational entity or person inside a major corporation to report a vulnerability to can be the toughest part of the mission. In other instances, MSVR has had to take on the role not just of vulnerability reporter but also of response educator, as vendors were unaware or unsure of the best ways to communicate the information their customers needed about the vulnerability in their product. On more than one occasion, we encountered statements and questions similar to “what should we put in an Advisory?” -- or, even more challenging, the assertion that “we do not believe this issue warrants an Advisory or public release.” That second response in particular requires MSVR to painstakingly go through the merits of educating the vendor about why notifying customers is important. Touchy work, but worthwhile.

(Interestingly, in the last two years, it has become clear that nothing serves better as the universal vulnerability translator than calc.exe. Sometimes all the man-hours and time spent packaging up what appears to be a cohesive and solid vulnerability report to a vendor devolves to utter exasperation when the response received is “Not a vulnerability”… that is, until the follow-up response from MSVR is the PoC needed to pop calc. Shortly thereafter, it seems like we are suddenly cooking with gas in the MSVR-to-vendor conversation.)

We have also learned that engineering processes across the ecosystem are unique to each company, and each comes with its own challenges that can make engineering a fix complex. Consequently, the timelines vendors require to engineer a fix is unique relative to each vendor and each product in order for them to get it right. To put it more bluntly, a universal time-to-fix mandate from MSVR (or any other vendor) is just not realistic. The speed with which the vendor of a cloud service offering can move to address a cross-site scripting vulnerability doesn’t compare to the time required to address a vulnerability in client-side code in a more traditional boxed product. This statement still holds true even when it is the same vendor who is responsible for both boxed and cloud version of a vulnerable product.

Finally, it has become clear to us that sharing hard data with vendors about the risk posed to our mutual customers can be key to getting traction. Throughout the last year we have leveraged the MSRC’s telemetry-gathering capabilities, both internal to Microsoft and via our MAPP partnerships, to help provide clarity to vendors during situations in which we believed our mutual customers to be at real risk from zero-day vulnerabilities of which they may not have been aware. This has required us to communicate clear and validated data that vendors could use to better prioritize and expedite their engineering processes relative to the trade-offs that they have to make.

It has definitely been a wild ride over the last two years – interesting times indeed. Along the way, we’ve tackled many of same problems that security researchers face when reporting vulnerabilities to vendors, and we’ve learned valuable lessons that will continue to not only make MSVR better, but also that we can channel back to our colleagues in the MSRC. We’ve forged stronger relationships with other security response teams and vendors throughout the ecosystem as well as with the talented security researchers both internal to and outside of Microsoft.

We’re thankful to all of the researchers and MSVR partners, such as MMPC and various MAPP participants, who have chosen to work with us and provided us with needed assistance when called upon. The next two years will hold even bigger challenges and bigger opportunities for MSVR, and it will also come with challenges I am sure I cannot begin to conceive of yet. Interested? I definitely encourage you to check out the whitepaper. And if you’re here at Black Hat drop by the Microsoft booth and let’s talk.

Adrian Stone