Making Sense of the Random & Mining For Gold

As the newest member to the EcoStrat Team, I guess I will start with the basics. I am Adrian Stone. I have now been in the Microsoft Security Response Center (MSRC) almost four years. My current job you ask? I work to make sense of the random and controlled chaos that is the MSRC. If my team and I do our jobs right, we often find nuggets of gold buried in the middle of it all. I have often joked that MSRC is like a box of chocolates. You never know what you’re going to get from one day to the next:

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

A new 0-day released into the wild?

A hard engineering security issue that affects vendors throughout the ecosystem?

Someone “hacked” your password and stole your MSN Messenger Account?

Aliens are reading your e-mail from the planet Remulak?

Yeah, my team gets them all. And we engage the right people and the right parts of the MSRC process to handle the issue.

I manage the part of the team that is responsible for reading every e-mail that comes into the secure@microsoft.com e-mail address, which is usually the entry point for vulnerabilities that are responsibly disclosed to us by external security researchers. In 2008, we reached a new benchmark of 75% of the vulnerabilities we received being reported to us by responsible disclosure. The vast majority of those reports were sent to secure@microsoft.com. On average, we receive around 200,000 legitimate e-mails a year, including reports that range from the very real security issue to the absolutely bizarre. Of course, this number does not include the SPAM that still requires individual verification to make sure that filtering hasn’t caused us to miss a potential report, which can easily happen with foreign language Unicode based text.

If we grow complacent or aren’t digging into a report, we run the risk of missing a potential security issue. Often times we will engage with the security researcher to ensure we understand the concern or the type of issue from their point of view. There are no auto responders in our world. I can attest to the fact that a person with a qualified security background is sorting through it all 365 days a year. Mining these e-mail reports in all their various languages and the data contained within them is invaluable to help ensure, that like a field medic, we accurately assess and assign the right priority and engage the right product teams within the company to investigate the issue more deeply. As if all of that wasn’t enough to keep us focused, we also monitor various other resources for signs of issues that may impact the security of Microsoft’s customers.

Another component of my team is responsibility for the MSRC’s infrastructure and data analysis to make sure that what we learn about a vulnerability report, and the corresponding fix, can be leveraged to improve future products through the efforts of our colleagues in the Security Development Lifecycle (SDL) Team.

Ultimately my team serves as the bookends to the process driven by the Security PMs and the Release Team that starts with vulnerability disclosure and ends with what most of our customers see as the monthly security bulletin release.

I also serve as Editor and Chief of our security bulletins and advisories. It’s that part of my job that most of our customers see in the end result of in their day to day operations. The security bulletins and advisories serve as the vehicle by which we notify our customers of a newly uncovered vulnerability in our products and the steps that they can take to remediate the issue. Just as security vulnerabilities are an issue that span across the industry, so are the use of bulletins and advisories to communicate the issues. Sometimes though calling something a bulletin or an advisory is where the similarities in communication begin and end. The rest in between can be anyone’s guess.

Understanding the content of a security bulletin or advisory can vary wildly from one vendor to another. When comparing one vendor to another, the accuracy and the level of the depth about the underlying vulnerability and the potential mitigations and workarounds can vary relative to the vendor. The data sets and terminology may be completely different. For example what one vendor may call a remote code execution issue may be referred to as a remote elevation of privilege vulnerability by another. This could leave a customer asking: "Are these things the same or aren’t they? Which one is worse?"

As you can see this leaves the customer trying to decipher the different nuances in terminology, technical documentation, and the content itself. Eventually all of the information in its various forms is digested by customers to perform and execute on a Risk Analysis and Risk Remediation Plan. This is often a very manual task requiring cross referencing of vulnerability identification numbers and comparing differing and competing scoring systems. At best, it is time consuming; at worst, it can be a total pain if you are dealing with a heterogeneous computing environment supported by different vendors. We constantly leverage focus groups and mine the feedback on our security bulletin and advisory content that we receive from customers and partners to optimize and improve its usability. While this helps us and our customers with respect to the information we provide, it unfortunately does not address the various nuances from vendor to vendor for the customer.

This brings me to a project that I am involved in that has been started by ICASI members: to create an industry-wide Common Vulnerability Reporting Framework (CVRF) with regards to how we present vulnerability data and articulate security related issues. The CVRF end goal is to present a form of extensible XML framework that can be easily parsed by both humans and tools. The benefit for both vendors and customers is that some of the ambiguity is removed for consumers of the data. The structure can be leveraged by vendors to help streamline the data recording they need internally to help identify and develop updates to address security vulnerabilities. While the project is still in its infancy, it is awesome to see it getting traction and the various members working together to solve a problem that, prior to my coming to Microsoft, was the bane of my existence as a Security Analyst. I wish I could say I escaped it when I received my card key to the building, but the truth is it now occupies my thoughts as a member of the MSRC for a very different set of reasons. Now it regularly presents challenges for my team in how we manage the flow of our vulnerability data within the company and externally with partners like Microsoft Active Protections Program (MAPP) members. It is important to note that CVRF is not intended to replace various scoring methods to determine the impact of vulnerabilities, but rather to serve as a common framework to structure many of the data elements that can be used by such scoring systems. I can definitely see how CVRF will help us get even better and of course, through this process, we’ll continue our engagement in CVSS and the CVSS SIG. Hopefully, if we do it right, there will be a little more order and a little less chaos in the security ecosystem. That can be as valuable and as rare as refined gold on some days.

Later,

-A

Share this post :

*Postings are provided "AS IS" with no warranties, and confers no rights.*