I recently returned from the second iteration of the SOURCE Boston computer security conference, and I must say, it was both an intimate conference of less than 250 folks and a high-caliber gathering. As with other conferences that the Microsoft Security Response Center (MSRC) co-sponsors, we see these forums as opportunities that highlight relevant research and showcase how individual strategies can intersect to offer substantial benefits and positive-sum outcomes.
For those of you not familiar with SOURCE, the conference combines business technology and application security tracks over three jam-packed days of presentations from experts in the field. This was the first time that a Security Start-Up Showcase (for all of you VCs/Start up folks out there not taking this economy to heart ;), Discussion Groups, and a Product Education Track were added to the already buff line-up. The attendee make up was approximately 35 percent Security Professionals, 30 percent Executives (Chief Officers), 10 percent Independent Security Researchers, 10 percent Administrators, 10percent Press, and the remainders were Students/Other.
Although there were more talks that sparked my interest than I was able to attend, I did attend some very insightful tracks. One such talk that appealed to me was a panel called The Partial Disclosure Dilemma hosted by Ryan Naraine with SME’s like Dan Kaminsky, Ivan Arce, Katie Moussouris, Dino Dai Zovi, and Alexander Sotirov. For a deeper dive on this subject from the only vendor on the panel, check out Katie’s blog and hear her stress how, "We need more collaboration between those who say the sky is falling, and those upon whom the sky will fall." Throughout this two hour showdown it was apparent that sometimes finding a vulnerability and creating an update is only part of the picture. Often, there has to be a coordinated fix with other vendors and the solution has to then be deployed to protect critical infrastructure. While folks could agree to disagree on the bulk of disputed points, for the most part everyone believed that the industry has got to move forward trusting each other with a more productive and transparent process, whether it be through more peer review among researchers or other communicative and joint mediums. I got a moment of pleasure hearing David Mortman speak out from the audience to say, "I apply MS Patches right away because I know they are going to work and not break anything." W00t!
An earlier talk on How Microsoft Fixes Security Vulnerabilities: Everything you wanted to know about the MSRC Security Update Engineering Process painted a clear picture of the different ways we find variants and work on mitigations and workarounds as part of the Microsoft response process. This talk answered the fascinating question of, "How come some of your in-band updates take a long time, but sometimes you can produce an out-of-band update in a matter of days?" Dave Midturi, Jonathan Ness, and Mark Wodrich dove into some great case studies that showcased in-band updates versus out-of-band updates to answer that ever popular question. For those of you that missed it, I strongly suggest checking it out in the next couple weeks, once it is available on the con site, so you can see first-hand what goes into a Microsoft Security Update, and how out of some 200,000 non-spam e-mails that come in to secure@microsoft.com per year result in approximately 70 bulletins.
All in all, there was a broad range of topics covered that left me simultaneously scared, inspired and contemplative–and I think that sums up exactly what I’m looking for in a security con. And as an added bonus, the con was hosted harbor side in Beantown, not far from Mike’s Pastry cannoli and some good old fashion American history; tea anyone?
-Celene Temkin
*Postings are provided "AS IS" with no warranties, and confers no rights.*
CanSecWest, in beautiful Vancouver BC, is one of my favorite conferences each year. It’s a cozy little security con that brings together security researchers from all parts of the security ecosystem. Like a PhNeutral or a BlueHat, one never quite knows what to expect out of a CanSecWest, but we do know that Microsoft products and engineers will play a prominent role. We’ll be presenting new security innovations and new tools, we’ll be watching Pwn2Own closely for possible hacks, and we’ll be happy to discuss our industry best practices in the hallway track.
Security gatherings such as this allow the ecosystem to exchange information and awareness in order to become more secure. The more we know about the attacks, the better prepared we can be on defense. Presentations like Matt Miller’s “The Evolution of Microsoft's Exploit Mitigations” and Jason Shirk and Dave Weinstein’s “Automated Real-time and Post Mortem Security Crash Analysis and Categorization” demonstrate that as Microsoft learns more about an attack, we incorporate this information into techniques and tools that we share with our developer community. Stay tuned for more news and posts throughout the show.
Again this year, CanSecWest features the Pwn2Own contest – a contest that pits researchers against technologies to see whether technology or human wins. It’s also a contest that presents interesting challenges to Microsoft and a contest which you might think Microsoft opposes. Like many other issues in the security ecosystem – it’s not that simple. The contest exemplifies two basic tenets behind the TwC Security teams’ efforts. You can’t hide from the truth (wishing doesn’t make it so) and every issue is an opportunity to learn and improve.
We recognize that all vendors’ products may be found vulnerable and Microsoft welcomes the contest as another opportunity to engage the security community in productive dialogue around responsible disclosure and effective security engineering. We also see that Pwn2Own provides an opportunity to educate the public and we believe it can showcase Microsoft’s security engineering efforts, both relative to our competitors and in an absolute sense.
The security community is offering knowledge of attacks and defenses that consumers and other vendors can use to stay safe or create more secure products. The rest of the story – and an additional measure the security community could use to evaluate vendors’ products - is what happens after the content ends. Rest assured Microsoft will take this information and apply it towards securing our networks, platforms and applications (hopefully before they ship), and to create strong response process and engineering discipline that are necessary for our communal security. And as always, the MSRC are ready to work to investigate any vulnerabilities that researchers might find during the Pwn2Own contest.
By the end of the contest, co-sponsor Tipping Point will be the owners of many new vulnerabilities. They value the protection of their customers and will need to work with their partners in the security ecosystem to make sure everybody is protected as quickly as possible (one more way consumers benefit). One of the goals of responsible disclosure is for the vulnerability details to emerge at the same time that an update is available from the vulnerable vendor. The CanSecWest conference organizer also has a responsible disclosure policy, as do all of the conference organizers that the EcoStrat team is able to support worldwide each year.
Although innovative contests put some of us in a place that is not always comfortable, it’s valuable for the ecosystem to come together with contests like Pwn2Own and Iron Chef Black Hat, to better understand and solve common issues. It’s yet another example of the “team of rivals” strategy. Let the contest begin!
-Sarah
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:
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?
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