MSRC Ecosystem Strategy Team : Exploitability Index

Community Based Defense - Redux

msrcecostrat — Mon, 27 Jul 2009 11:18:00 GMT

Handle:
The Crushman

IRL:
Andrew Cushman

Rank:
Security Director

Likes:
Cranberry juice (thanks Jay!)

Dislikes:
Super helpful hotel desk clerks (thanks Raoul?)

OMG it’s great to be back in Vegas again – the shows, the shopping, the nightlife, and let’s not forget the talks at Black Hat, the old and new friends, the excitement and the drama. I can hardly wait to see what develops this year!

Last year at Black Hat, the Microsoft Security Response Center announced three new programs – Microsoft Active Protections Programs (MAPP), Microsoft Vulnerability Research (MSVR), and Microsoft Exploitability Index. I was honestly a bit nervous about how the programs would be received. Would the community ridicule them (and us)? Were the programs as solid as we thought they were? Would they stand the test of time? And most importantly, would they help advance community-based defense?

It’s a year later and I’m happy to report that the programs were not only well received, but have proven to be effective, accurate, and continue to deliver results. MAPP is changing the balance between attacker and defender, MSVR is raising the security of the overall ecosystem, and the Exploitability Index continues to provide customers with accurate, easy to understand, and actionable guidance. Today, MSRC published a report card – “Building a Safer, More Trusted Internet through Information Sharing” – that both summarizes these results and provides specifics around goals achieved. Read all about it here.

Today at Black Hat, MSRC also released a new set of tools and guidance aimed at continuing to advance community-based defense and simplify customers’ management of the risk environment.

First up, the Microsoft Security Update Guide - a one stop shop of information on Microsoft’s Patch Tuesday, including what information we release, best practices, and a framework to help make the complex patch management landscape more clear. It’s available for free download here.

On the tooling front, the MSRC Engineering team (owners of and contributors to the SRD blog) released the Microsoft Office Visualization Tool. Available for free download here, the new tool lowers the barrier to understanding the Office binary file format by allowing IT professionals, security researchers, and malware protection vendors to deconstruct .doc-, .xls- and .ppt-based targeted attacks.

Lastly, we’re pleased to point to the latest updates from Project Quant, a cost model program for patch management response collaboratively lead by Rich Mogulll (Securosis) and Jeff Jones (Microsoft). With the new information released today – Project Quant Report 1.0, Model Spreadsheet 1.0, and the Survey Report – the community is better able to improve their update practices by addressing many of the challenges organizations face optimizing their systems and maintaining security while striving to keeping costs down.

Black Hat is an exciting time and I’m thrilled to showcase the impact and continued progress of MSRC – and even more so to demonstrate how Trustworthy Computing continues to evolve in response to the changes in the threat landscape, and truly helps protects customers through community-based defense and collaboration.

See you at Caesars!

Andrew

The year-end review – well, sort of :)

msrcecostrat — Mon, 27 Jul 2009 08:08:00 GMT

Handle:
Cap'n Steve

IRL:
Steve Adegbite

Rank:
Senior Security Program Manager Lead

Likes:
Reverse Engineering an obscene amount of code and ripping it up on a snowboard

Dislikes:
Not much but if you hear me growl…run

Hey!

It’s that time of year again for all of us to pack up and head out to the desert to reconnect, discuss, and plan for the future, or at least what we think will be the future of security. It’s hard to predict what the next year will bring as the security landscape is ever-changing. This is probably why most of us “grey beards” in the security industry mark the Black Hat/Defcon conferences as the de facto year in review/preview of the next year for the state of security. These conferences have defined a lot of security strategies for a number of people for years. But I digressJ; I started to talk about the year-end review for the security landscape.

Looking back over the year, I am pleased to see that we have executed nicely on a couple of strategies we put into place to change the security landscape. The ones I am talking about are the three programs listed below that we launched last year around this time.

I am going to talk about the first two programs as I have been working on both of them for a bit. MSVR has been worked by my colleague Adrian who will be blogging on MSVR in the near future. He will update you about all the exciting things they have been doing over there.

So let’s begin. I want to talk to you first about the Exploitability Index. Like I said, the one-year anniversary is right around the corner and we have been getting a lot of positive feedback from customers on this new program. Looking back, I am happy to see that out of the 140 ratings we provided so far that we only had to revise one rating. The one rating we did change went from a high severity to a lower one (1 to 3).

Let me give some of our reasons for this. We are extremely cautious when we rate things and when in doubt, will tend to go with the higher rating. We want to make sure that those who are using our ratings are protected against exploitation. This is kind of like putting a deadbolt lock on your door even though you live right next to the police station – I would rather be safe than sorry. However, we are always looking for ways to improve our ratings, and we tend to seek out the critical areas where we can or need to improve.

There is no better place, in our mind, to get good feedback than from the security ecosystem. So we were extremely happy when iDefense took up the charge to review our Exploitability Index ratings for the first 120 days. I am sure you are thinking, "Is 120 days really enough time?" Well, it definitely gave a decent snapshot into how the program is progressing. I think it’s also a good timeframe for catching early process deficiencies and other issues. So let me highlight a few things that were discovered during the iDefense review.

Overall assessment: iDefense concluded that the Microsoft Exploitability Index was a step in the right direction. They felt that the Index provides clear value to customers in providing more risk mitigation information. iDefense also felt that it helps system administrators with the prioritization of their system-updating efforts, because with the Index, they can use another piece of information to help set their update schedule.

Out of the fifty-seven vulnerabilities reviewed by iDefense, they considered that only fourteen should have been rated differently. This is a ~75% percent similarity between their analyses and our own.

As with all early efforts, they did find some areas where they had suggestions for improvement. One area is with the rating differences mentioned above. We will be reviewing the reasons for the differences and will be looking at our present process to take their suggestions into account. Check out the full report here.

Now let’s talk about the Microsoft Active Protections Program, or as we call it in the hallways of building 27, “MAPP”. The MAPP program goals were to find a way to shorten the attack window for consumers. We wanted to be able provide enough “just in time” technical information on the vulnerabilities that we were updating every month to help defenders provide software protections faster. It didn’t make sense in our eyes to have verified defenders in the same boat as malicious attackers trying to understand and reverse-engineer our updates to build defenses for our mutual customers.

I am glad to say that we have exceeded our goal. In the program to date, we have 47 companies from around the world, with new partners added in Central and South America, Europe, Middle East, Africa, India, South East Asia, China, Korea, Japan, Australia, and New Zealand. This partner network global reach represents software protections that cover a range from tens of thousands to hundreds of millions of consumers. That is nothing to sneeze at! J It doesn’t stop there; we will continue to add more partners to ensure that we arm the defenders with information they need to protect you, our mutual customers. We have some more proof points on how we are shrinking that attack window, but don’t take my word for it, check out the testimonials from the MAPP members themselves in the year-end progress report from MSRC here.

Well, that’s it. Don’t forget to check out the iDefense paper located here and the MAPP paper here. And keep an eye on www.microsoft.com/twc/blogs for more Black Hat blogs from the front lines.

Til next time….

Steve

Making Sense of the Random & Mining For Gold

msrcecostrat — Thu, 12 Mar 2009 10:30:00 GMT

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

Constants and Change

msrcecostrat — Tue, 03 Feb 2009 11:00:00 GMT

Microsoft has been talking about community-based defense for some time now. This week, I want to provide a personal dimension to the campaign, and give an update on recent activities. Curiously, as I started to write this post, a couple of phrases popped up, which despite being somewhat trite, seemed appropriate – "change is constant" and "the more things change the more they stay the same."

Handle:
The Crushman

IRL:
Andrew Cushman

Rank:
Security Director

Likes:
Cranberry juice (thanks Jay!)

Dislikes:
Super helpful hotel desk clerks (thanks Raoul?)

Over the last years my outreach efforts expanded beyond the security researcher part of the security ecosystem to include CERTs and other guidance providers, as well as security organizations and companies. My most recent past and future activities give a view.

Before we get into the trip report, though, I want to spend just a second on a couple of guiding principles and introduce some vocabulary.

I attend a lot of conferences around the world. A number of years ago, I started referring to them as “watering holes” – like watering holes security conferences are the places in the ecosystem that attract a diverse population focused on a common need. The most interesting conferences are the ones with the best “hallway track” – the ones that attract the most diverse and most interesting attendees also typically generate the most interesting hallway (or after hours) discussions.

My objective in attending conferences is twofold. I want to foster community support, help make connections between Microsoft and different parts of the ecosystem, and make bridging connections between parts of the ecosystem that might not otherwise mingle. Secondly, I want to stimulate conversation about shared problems, ensure attendees understand what Microsoft is doing and promote discussion about collaborative solutions.

In December, I was in Sao Paulo at the DISI 2008 – Dia Internacional de Segurança em Informática; an event co-hosted the Brazilian Army and FIESP – the Industry Federation of the State of Sao Paulo. This conference was interesting because of the community it brings together and the challenges unique to Brazil. I presented last year and delivered an embryonic call to action for community-based defense. I was very pleased to be able to return a year later and give an update that showed Microsoft’s progress. I pointed to programs like the Microsoft Active Protections Program (MAPP), the Industry Consortium for Advancement of Security on the Internet (ICASI), the Exploitability Index and Microsoft Vulnerability Research (MSVR) to demonstrate that we are walking the walk.

January found me in California at a Bay Area security confabulation whose theme was “Partnerships: finding ways to energize a common defense.” The attendees came from across the industry and the security ecosystem. I found the hallway track(s) exceptionally valuable and especially enjoyed the discussion and presentations on cloud computing security. I presented on ICASI, and gave a behind the scenes look at its goals, formation, and current state. Microsoft, along with Cisco, IBM, Intel, and Juniper formed ICASI in 2008 to drive excellence and innovation in security response and to promote effective industry collaboration to address the rising tide of multi-vendor security issues.

Also in January, I volunteered (and was accepted J) to be the Program Chair for the 2010 conference organized by the Forum for Incident Response and Security Teams (FIRST). I’m a relative newcomer to the FIRST family and realize I have a fair amount to learn – the education starts at the next Steering Committee meeting in Miami and continues at the FIRST 2009 conference this June in Kyoto. I am very pleased by the warm reception and the opportunities this group has to influence and drive positive ecosystem change.

I also took on a new role within TwC Security in January. I handed over responsibility for the monthly security update releases to Mike Reavey in order to better focus on understanding and addressing emerging security threats. The new job is completely different, yet very much still the same. You’ll continue to see me at conferences around the world, I’ll continue to be active in the industry and ecosystem and I’ll continue to promote dialog about the changing threat landscape and what Microsoft can and should do to strengthen Community Based Defense.

-Andrew

One Month Analysis: Exploitability Index

msrcecostrat — Thu, 13 Nov 2008 12:01:00 GMT

Handle:
Silver Surfer

IRL:
Mike Reavey

Rank:
Director, MSRC

Likes:
Warm weather, Battlestar Galactica, and responsibly reported vulnerabilities

Dislikes:
Rain, Rain without end, Clouds with potential for rain, reality TV, and unpatched vulns

Hey folks –

We’ve just released the November Security Bulletins and that also marks the one-month point after the release of the initial Exploitability Index in October. As a result, we’ve had a several questions from customers on “how’s it working?” Well, so far, based off the results from October, and feedback from Microsoft Active Protections Program (MAPP) partners who help check our work before release – it seems to be going pretty well.

October was a large release, with 12 Security Bulletins resolving 21 vulnerabilities, one of those being an out-of-band release.

First – our main measure for success is to make sure we avoid rating something in the index “lower” than it actually should be once under full public review. This is our main concern because it means that customers would be at an increased level of risk than we communicated by the index. The good news is, one month after release, we’ve not had any issues that fall into this category. This also means, that for the four vulnerabilities we gave our lowest ratings, we haven’t seen functioning exploit code in the first 30 days. These include:

- MS08-058 - CVE-2008-3474 - Cumulative Security Update for Internet Explorer

- MS08-058 - CVE-2008-3476 - Cumulative Security Update for Internet Explorer

- MS08-061 - CVE-2008-2251 - Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege

- MS08-065 - CVE-2008-3479 - Vulnerability in Message Queuing Could Allow Remote Code Execution

There were also four security vulnerabilities where we anticipated consistent and functioning exploit code would be released publicly (excluding CVE-2008-2947, which was public at bulletin release), and for which this prediction came true. These include:

- MS08-059 – CVE-2008-3466 – Vulnerability in Host Integration Server RPC Service Could Allow Remote Code Execution

- MS08-062 – CVE-2008-1446 – Vulnerability in Windows Internet Printing Service Could Allow Remote Code Execution

- MS08-066 – CVE-2008-3464 – Vulnerability in the Microsoft Ancillary Function Driver Could Allow Elevation of Privilege

- MS08-067 – CVE-2008-4250 – Vulnerability in Server Service Could Allow Remote Code Execution (this was the out-of-band-release)

For each of the aforementioned issues, functioning exploit code was released publicly within the first two weeks. Customers using the index to help make deployment decisions would have been able to anticipate this, prioritize these updates over others, and roll them out within their environment. Before we had the Exploitability Index and providing this additional layer of analysis, these security bulletins would have had no special indication that attacks were likely.

This is probably the most significant impact the index can have, as we’ve always said it’ll never be 100% accurate, but that the goal is to give valuable information to help customers make prioritization decisions.

For the remaining five issues that were rated “1 – Consistent Exploit Code Likely,” we’ve not seen functioning exploit code posted publicly. While this may seem like we’re wrong in the prediction, we actually feel pretty good about this.

Let me explain: Some customers express concern that when we released the Exploitability Index, by observing the environment, we’d be changing it. Basically, they were worried that we’d raise the amount of exploit code present in the ecosystem by highlighting the issues most likely to have exploit code developed.

So even though we think it’s likely that functioning exploit code could be released for the remaining seven, the fact it hasn’t means that we’ve not significantly changed the threat environment in a negative way. And we haven’t told customers to worry less about a given vulnerability when in fact, they should have. In fact, it may even be that the increased attention led to faster deployments to protect against these vulnerabilities and that in turn made these less attractive.

A full list of all the vulnerabilities, Bulletin Severity Ratings, and Exploitability Index ratings, along with “how we’ve done” is listed below. As always, you can find the Exploitability Index on the Security Bulletin Summary page each month. You can even find additional supplemental information by referencing our Frequently Asked Questions and How to Use the Exploitability Index on several Microsoft Web sites.

We’ll continue to watch how we’re doing in providing this information, make an effort to engage more with the community to help us check our work.

However, one month in, based on the data and feedback from customers, it looks like the Exploitability Index is panning out to be a very helpful tool for customers.

- Mike Reavey

Share this post :

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

Black Hat Follow Up: Answering the Hard Questions

msrcecostrat — Tue, 14 Oct 2008 12:01:00 GMT

It’s October! And for those who remember Black Hat 2008 in Las Vegas, this means the programs we announced have launched. These programs include the Microsoft Active Protections Program and the Microsoft Exploitability Index, which begin with today's October Security Bulletin Release. Microsoft Vulnerability Research is also continuing to run a formalization of our ongoing efforts as responsible researchers in the community.

Following the announcement, there was a discussion on the Daily Dave security mailing list, where folks wanted to ask us more questions than were asked after we announced our three security programs at Black Hat 2008. We responded, asking folks to send their questions our way.

We didn’t answer some questions from the thread about future product development and our relationships with specific researchers. However, below are answers to questions about the three specific programs announced at Black Hat to make sure folks understand them fully.

We appreciate the feedback on these programs. They are all focused on increasing collaboration and information sharing to tilt the advantage in the favor of the defenders of networks as they combat attackers.

So, here are the questions, and the answers:

Questions about Microsoft Active Protections Program (MAPP)

1. Can you fully define 'offensive' or 'attack' software? Is a security assessment tool that does not exploit categorized as such? Consider a tool like nmap or Nessus, would that discount Fyodor or Tenable?

Of course, absolute definitions in this space are challenging. However, an example of pure offensive or attack software is any software that weakens for a prolonged or permanent state, the security integrity of a system to either exploit it or pilfer it (steal data, credentials, toe holds for further exploitation (rootkits)). Tools like MPack would be one example I would categorize as pure attack tool. With that said Nessus or Nmap (tools many of us here have used when doing security consulting) would not be considered pure offensive/attack tools.

2. What if a company makes multiple products, some aggressive and some passive? eEye or Tenable would be examples, where each has defensive products designed to act as IDS/IPS as well as assessment tools.

We would still allow such a company, provided they met the criteria, in the MAPP. They would still have to abide by the criteria that states that "protections" built with MAPP data must be held until the security update is publicly released. This ensures that someone doesn't get the signature and reverse engineers it to discover the issue being updated then releases Proof-of-Concept (PoC) on it. Now, I think where you are going is that there is a potential that the same company can use this information in their assessment products prior to the release of the security update. This is correct but it would be a violation of the MAPP agreement, and if discovered, we would terminate their membership. However, early on we realized that assessment tools play a big role in the enterprise and consumer security space. We will continue to work on this area. Right now, we’re focused on giving customers better active protections as they work to deploy our security updates.

3. What about companies that clearly make defensive products, but also have other questionable activities? Consider TippingPoint which has an IPS solution, but also does the ZDI Initiative, where they share (sell) vulnerability information to their clients.

We would evaluate their defensive business first and do a risk analysis of other activities to ensure that it does not harm the same customers we are trying to protect. This is not a "pure" solution but it is a real world one due to the nature of some security firm’s business practices. If at any point any MAPP member is found engaging in activities that hurt our customers, they will be removed immediately.

4. If an organization is found to have leaked information inappropriately, what are the consequences? Being kicked out of the cartel seems like a given, but by potentially putting millions of computers at risk prematurely, would Microsoft also pursue the company legally?

The company would be removed from the MAPP immediately. I can't speak on any legal action but I can imagine our legal department would review the matter. Also, please remember that one of the key operational goals of MAPP is to provide information “just-in-time.” Therefore, any negative actions only have a short window before the updates themselves are released for customers.

5. Would Microsoft comment and give a rough number of companies that have been accepted into MAPP to demonstrate the interest?

The MAPP has been receiving a fair amount of application as you can guess. We are still processing and getting people officially in, so no definitive numbers are available yet. Rough guesses are still matching up to what I said on the stage of about 20 to 40 companies by launch.

Questions about Microsoft Vulnerability Research (MSVR)

6. Are these people finding third-party vulnerabilities also looking at Microsoft products?

Yes. The people looking for third-party vulnerabilities are primarily in our security engineering teams, and they do look for vulnerabilities in our own products, along with conducting other security research and response activities. Some vulnerability finders within Microsoft are in other teams with other responsibilities, such as in various product teams.

7. Is this done using automated tools (proprietary or otherwise), by hand or a mix?

A mix. An overall goal of MSVR would be to not only help increase security by finding instances of vulnerabilities that are present in third-party software, but also in sharing methods we’ve learned in how to uncover these vulnerabilities. So if we can identify an opportunity, we will also share the principles and methodology we’ve developed as part of the Microsoft Security Development Lifecycle (SDL), which can include tools and manual techniques.

8. What disclosure policy do you adhere to, and is it published?

Our goal is to follow the OIS guidelines, found here: http://oisafety.org/guidelines/Guidelines%20for%20Security%20Vulnerability%20Reporting%20and%20Response%20V2.0.pdf .

9. Once the vulnerability is fixed, vendors frequently issue advisories or mention the fix in a changelog and credit the person/company who reported it. Can you cite a single example of this? If not, why not?

Yes we can. Engineers at Microsoft had been reporting vulnerabilities to third-party vendors long before MSVR was founded. MSVR is both a formalization of how we handle vulnerabilities that are casually found during the course of someone's normal work (as was the case for years), as well as an expansion of research focus to third-party software specifically to look for vulnerabilities. Before MSVR, finders at Microsoft either reported the issues they found to the vendor directly, or asked the MSRC to help them do so. They are individually credited in the affected vendor's advisories. Try searching for Tom Gallagher in some ISVs security bulletins.

Question about Microsoft Exploitability Index

10. If there are only a handful of people who can make a reliable exploit for a particular vulnerability (or not) and none of them work for Microsoft, how can Microsoft accurately determine whether an exploit for a particular vulnerability will be somewhat reliable or totally reliable (or not possible at all)?

This question makes a good point, and that is, much of the Exploitability Index accuracy is based off of who is doing the work versus a strict scientific methodology. We realize there’s a chance we might not be 100% right all the time. However, we’ve done a few things to try and make sure this index is accurate enough to help realize its goal of giving more actionable information to customers to prioritize their deployment.

First, it’s most relevant for the first two weeks to 30 days after release. Meaning, exploitation science may change, and there may be private methods under discussion, but for customers making deployment decisions, it should provide enough information to help make a more informed prioritization than before. Second, we do have the folks from the Security Vulnerability Research and Defense (SVRD) team working on the vulnerability from its initial report, until the release, and they’ll be assessing exploitability as part of their normal process.

That’s not all, as we’ll also be following methodologies discussed at BlueHat conferences so using similar approaches which the community uses when analyzing our updates. And finally, we’ll leverage the community established through MAPP to check our work before we release the index. With three layers of people and processes, we expect Exploitability Index to provide valuable information to customers in their decision making.

- Mike Reavey

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

Leaving Las Vegas: A Black Hat Salute

msrcecostrat — Fri, 08 Aug 2008 12:00:00 GMT

Handle:
The Crushman

IRL:
Andrew Cushman

Rank:
Security Director

Likes:
Cranberry juice (thanks Jay!)

Dislikes:
Super helpful hotel desk clerks (thanks Raoul?)

What can I say? Once again, Black Hat did not disappoint. And that’s not just post-party speak. The conversations were good, the input was invaluable, and the support for the new programs we launched—well, it’s been overwhelming. The vibe in the MSRC “Helping Secure the Planet” presentation was great, the audience was engaged and had plenty of questions and Mike, Katie and Steve demonstrated the depth of talent and commitment in the MSRC. We’re excited to take that momentum and move it forward.

Our hats are off to the awesome Black hat team for putting on another great conference. I only wish I could have made it into more sessions. Among briefings with media on our news, reconnecting with old friends and making new ones, and fielding a steady flow of invite requests for the party, the time just flew by. But hey, I did manage to introduce Rod Beckstrom for his keynote and got a tweet in on that.

And how about Twitter? I didn’t imagine I would enjoy it so much and who'd have thought it would drive so much conversation at the show? We had fun participating and watching the discussions unfold. It’s been a great channel to share news and carry on further about some of the presentations and event happenings. I especially enjoyed Ryan Naraine’s play-by-play at the Pwnie Awards.

And about the Pwnie Awards, I want to echo my thanks for the “Most Epic Fail” Honorable Mention. Rest assured we’ll be back next year with the same commitment to security engineering!

I’m also really excited about our new EcoStrat blog (http://blogs.technet.com/ecostrat/). The team has written some great posts. The blog provides an opportunity for the EcoStrat team to “show our work” and provide a good look behind the scenes on what we’re doing and how we’re working with the broader security community. We will continue to take advantage of opportunities so as to continue a dialogue.

This week really has solidified a fundamental shift for Microsoft and it’s been refreshing to see that shift in perception and reception towards us at the conference—from what used to be a focus on free drinks and invites to a genuine interest in what we’re offering and how we’re engaged in the security community.

I’m sure good times were had by all here at the show, and our hope, and commitment, is that what happened in Vegas, particularly what we announced in Vegas, does not stay in Vegas.

- Andrew Cushman

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

Helping Secure the Planet: New Strategic Initiatives from Microsoft

msrcecostrat — Wed, 06 Aug 2008 12:02:00 GMT

Tomorrow, Steve Adegbite, Katie Moussouris and I will give the first ever Microsoft Security Response Center (MSRC) talk at Black Hat, Las Vegas. Yes, Microsoft has presented at Black Hat before, and actually has a pretty long history of participating in this con, but this is the first time the MSRC itself has hosted a talk.

So what’s the big deal?

Well, as you may have heard, we’ve announced a couple new programs this week (See Microsoft’s Virtual Press Room) that mark a real shift in how we approach the issue of security. This talk will disclose all the juicy details of all three programs (yes, there’s a third program...Katie will tell you all about it!), include demos of the vulnerability information we will share as part of the Microsoft Active Protections Program Steve’s created, show you what our “Exploitability Index” looks like, and give you all the context you’ll need to understand the how’s, why’s, and where’s that led us up to this stage!

While saying we want to help “secure the planet” is a bit assuming, the reality is that we realize no one can address evolving security threats alone. One of the key themes of the talk, and indeed one of the key themes of our continued commitment to taking Trustworthy Computing to the Internet, is that through collaboration and shared intelligence, the security industry can better anticipate, respond and work together to address threats. This talk will illustrate how these innovative programs come together to help enhance security through collaboration and information sharing.

So if you’re here on the ground, come join us tomorrow at 3:15 in Roman Ballroom. And, of course, if you’re unable to catch us at the conference, the best bet is to follow us on Twitter:

http://twitter.com/mreavey

http://twitter.com/SteveAdegbite

http://twitter.com/k8em0

- Mike Reavey

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

Update: Room #.

Predicting the Future - Microsoft Launches an “Exploitability Index”

msrcecostrat — Tue, 05 Aug 2008 16:01:00 GMT

Hey all – Mike Reavey here. I’ve been with the Microsoft Security Response Center (MSRC) for over five years now, and working in security for over a decade. One of the reasons I’m truly passionate about this type of work is that it’s always changing, and very exciting.

However, in some ways the security ecosystem is a very predictable place.

For example, I can almost guarantee we’ll see a lot of charts at Black Hat with arrows going “up” showing that things are still rough in the security space. And in fact, if you read George’s thoughts in a ZDNet guest editorial you’ll see things are going “up” in a lot of areas.

One other predictable activity is that following every 2^nd Tuesday, after we’ve released our security updates, there’s a community of folks reverse engineering our updates and creating exploit code. Consequently, another very predictable activity is that customers always ask us which of the vulnerabilities we’ve fixed have had exploit code released each month. That’s a key factor in their risk assessment.

When we reviewed why they asked that question, one thing we realized is that not every vulnerability we release updates for has functional exploit code created. And that’s in the face of very competent people like those behind tools like Metasploit, Immunity CANVAS and Core’s IMPACT - who have systems and people geared up to produce exploit code every time we release updates.

When doing the math, roughly 30 percent of the vulnerabilities we fix each year have exploit code released. You can see more details on this analysis in the SIR (www.microsoft.com/sir). There’s a lot of reasons it’s not at 100 percent - some just aren’t interesting from an attacker’s or a pen tester’s perspective, and others only affect products that have low penetration, but some are more challenging to exploit given the way the vulnerability manifests itself. For example, a defense in depth approach may make a particular vulnerability especially hard to exploit consistently, maybe /GS causes the process to crash without any data aside from the /GS cookie being overwritten, or maybe it’s just an area of code where the system memory isn’t structured in a reliable way to gain execution.

This morning, we’ve announced an “Exploitability Index.” The Microsoft Exploitability Index is designed to provide additional information to help customers better prioritize the deployment of Microsoft security updates. This Index will provide customers with guidance on the likelihood of functional exploit being developed for vulnerabilities addressed by Microsoft security updates.

This index will attempt to predict if a vulnerability is likely to have functioning exploit code released, or have inconsistent exploit code released that wouldn’t work every time an attacker attempted to used it. We’ll even highlight vulnerabilities where we think it’s unlikely that functioning exploit code will ever be released.

The first question I get when I talk about this is, “How are you going to make this assessment? “

Well, first we’ll review our understanding of the vulnerability and what it would take to exploit it with folks like our Security Vulnerability Research & Defense (SVRD) team as part of our standard MSRC process. Second, we’re also incorporating the same methodologies we’ve seen used in the community for years – some of these we’ve even had presented at our own conference, BlueHat, by folks like Halvar Flake and Lurene Greenier. And third, since, as Steve says, “it takes a village” to raise a healthy security ecosystem, we’re asking members of the Microsoft Active Protections Program to also review the vulnerabilities to check our work before we release the index each month.

Bottom line… we are giving customers more information to help their risk assessment, and that, we think, is a good thing. And a very reasonable request, given the security ecosystem’s emerging shift towards more collaboration.

I’ll be talking more about this and other Black Hat happenings at my Twitter feed: www.twitter.com\mreavey

- Mike Reavey

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