MSRC Ecosystem Strategy Team : Black Hat

Threat Complexity Requires New Levels of Collaboration

msrcecostrat — Mon, 27 Jul 2009 22:43:00 GMT

When complex security issues that affect multiple vendors arise, calling them “challenging” is an understatement. We created the Microsoft Vulnerability Research Program (MSVR) to meet those challenges, learn from those experiences and strengthen the ties of our community of defenders across the industry in the process. As the state of software security matures beyond straightforward issues such as buffer overflows and elevation of privilege, we are working diligently towards a new level of cross-industry collaboration on a scale never seen before. We must do so in order to provide our mutual customers with the best possible experience on our platform.

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

Handle:
k8e

IRL:
Katie Moussouris

Rank:
Senior Security Program Manager

Likes:
Cool vulns (responsibly disclosed of course), girls with soldering irons, Spanish tapas, quantum teleportation

Dislikes:
Rudeness, socks-n-sandals, licorice

The recent Active Template Library (ATL) issue required us to find a new and more collaborative manner to respond to the developing threats as more information about the vulnerability details became public. MSVR was at the heart of the response and coordination, along with MSRC, to find a solution. As MSRC focused on what it does regularly, which is driving change within Microsoft, MSVR kicked into high gear to coordinate and assist as many third-party affected vendors as possible to help resolve an industry-wide issue.

Several firsts and questions had to be met head-on by our relatively young MSVR program now celebrating its first birthday.

· How do we maintain and respect the overarching tenets of Responsible Disclosure while sharing the issue outside of Microsoft?

· How do we communicate openly and directly with multiple impacted parties while not putting customers at risk by a potential broad disclosure prior to the availability of mitigation?

· How do we translate an issue that we came to understand very well to third parties that may not have the same technical history or security response methodologies and practices that we do?

· Can we coordinate across the industry so that everyone is moving to the same goal of addressing the problem, despite differing development practices and engineering requirement timelines?

The talented security researchers that reported the issue to Microsoft had done so in a responsible manner with the goal of improving the ecosystem and helping us protect our customers. At the same time, it became clear to us that this was an industry-wide problem and that the best way to secure the ecosystem was to notify affected vendors while engineering efforts were underway here in Redmond. Microsoft is a supporter of Responsible Disclosure, which aims to allow affected vendors to understand and try to resolve their respective issues before discussing the details of the issue publicly. In this instance, MSVR’s actions demonstrated a variety of responsible disclosure recently dubbed "partial disclosure," when we alerted third-party vendors who we believed had controls compiled with our vulnerable ATL headers. In the past year of MSVR operations, we have acted in the Responsible Disclosure roles of Finder and Coordinator. The ATL issue required us to act in both of those roles, plus in the role of affected Vendor.

While we knew we had to disclose technical details to a broad group, the clock was also ticking as we began to see more and more details about this issue being discussed and discovered in the security community. The original security researchers that reported the issue to us worked with us diligently and patiently to continue acting responsibly with their understanding of the problem, while we began developing a process and technical tools to analyze our controls and look for a solution. At the same time, we began the process of identifying and analyzing the controls that are most commonly deployed but were developed by other vendors. It is at this point we felt that we had a viable way to individually engage as many of these affected vendors as possible to discuss the impact of the issue as it relates to their potentially vulnerable controls.

Due to their potential scope, library-related vulnerabilities can often stir uncertainty and concern in the industry, so we focused our efforts to understand the true depth and breadth of the impact. Our analysis indicated that the vast majority of controls that would impact our users could be addressed by a few key vendors in the ecosystem. With this in mind, MSVR reached out to vendors who had the broadest footprint in the ecosystem that we believed were affected by the issue. We also felt confident that the defense-in-depth engineering solutions being worked on here at Microsoft would help provide a safeguard against attacks and allow other vendors more time to modify and recompile their own controls.

Overall, our goals and objectives were straightforward, if not exactly effortless, and required us to also leverage many of the key lessons learned by the MSRC over the years. After we distilled the actions and goals down to their most elemental levels, it became clear we had to move quickly on several fronts, including:

· Coming up with our own defense-in-depth solution to help protect customers and mitigate the threat.

· Taking steps to identify quickly the affected third-party vendors who we thought had the broadest impact on our platform.

· Finding the right security contacts at the vendors who met those criteria.

· Packaging and disseminating the vulnerability information to them securely.

Our goals in doing so were to:

· Alert as many of the community of vendors who have affected controls as possible that there was an issue with ATL.

· Provide the third-party vendors with technical details necessary to perform the broad analysis of all of their controls to look for the vulnerability in their products.

· Support the third-party vendors in their analysis, answering their questions, and clarifying the issue when necessary.

· Coordinate with the major affected third parties in both the release of the updates, as well as with guidance for our mutual customers.

We learned a lot during this process. After all, evolution requires change in the way we think and in the way we act, which leads to growth. We will incorporate these lessons into MSVR processes moving forward. We have formed stronger relationships across organizations that MSVR has worked with on other issues in the past, and we have forged many new bonds with security teams across company boundaries. Overall, we are very pleased with the positive industry response, and we salute our counterparts in the security organizations of all the third-party vendors we have worked with during this historic collaboration, including but not limited to Adobe and Sun. We are also incredibly thankful and appreciative of Ryan Smith and David Dewey, the original security researchers that reported the issue to us responsibly, as it was a multidimensional challenge that required significant patience and understanding on their part as we determined how to best address the problem.

As we move forward toward the next challenges on the security horizon, we can anticipate deeper integration among the community of defenders, whether they work for Microsoft or a third-party vendor, whether they are security researchers or are members of a CERT – we can expect more collaboration. After all, progress towards securing our platform, as has been made with our own SDL, will naturally lead to attacks being more complex, more dependent on how applications interact with each other and with the underlying operating system, and therefore will require us all to look past our company logos and focus on that threat horizon.

I’m Adrian Stone, who ran the ATL coordination and is the new driver of the MSVR program since July 1, and I’m Katie Moussouris, founder of the MSVR program, and together with the security community, we look forward to advancing community-based defense and helping to usher in this new age of collaborative security for the good of all our customers.

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

Black Hat USA: Hoping what happens in Vegas doesn’t actually stay in Vegas…

msrcecostrat — Wed, 22 Jul 2009 19:27:56 GMT

Handle:
Security Blanki

IRL:
Sarah Blankinship

Rank:
Senior Security Strategist Lead

Likes:
Vuln wrangling, teams of rivals, global climate change - the hotter the better

Dislikes:
Slack jawed gawkers (girls are geeks too!), customers @ risk, egos

This week our team is preparing to travel to Black Hat USA in Las Vegas Nevada, a hotspot (literally and figuratively), and one of the largest gatherings of security professionals in the world. Black Hat brings together diverse security communities to discuss, debate, deploy, and disseminate security information. It is a week of breaking bread with our friends and rivals, learning from others around the world and bridging the roles of researcher and vendor to raise our security awareness.

Within Microsoft, we have a community of security defenders.

Our internal community also discusses, debates, deploys, and disseminates security information. We don’t always agree; our perspectives and backgrounds are as diverse as the world we live in. We strive to understand and mitigate flaws in our own products and platforms, and also responsibly research vulnerabilities in third-party software most commonly used by Windows customers. We focus on many different areas, working on not only improving the security of Windows, but of the entire Windows ecosystem.

For me, security is more than a mindset or an end state, it is a mission. Security is a theme that has the power to unite organizations and individuals across teams across geographic and company boundaries. Within this mission, I, along with our internal community, strive to help ‘secure our planet’ by building bridges and creating opportunities for technical information exchange.

As we look to meeting with our security comrades from around the world in Vegas, we thought it would be interesting to highlight the perspectives and backgrounds of individuals within our internal security community of defenders and present them in short videos to be rolled out over the next week.

The Microsoft security community folks profiled answered two questions:

How did we become involved in security at Microsoft?

What changes have we seen at Microsoft security over the years?

As our challenges have evolved and become a great deal more complex, our collective communities must also rise to the occasion, evolving our security awareness and response. From our security community to yours, we hope you enjoy learning a little bit more about us as we work to understand more about you all.

And remember, in this digital age, what happens in Vegas doesn’t actually stay in Vegas. ;-)

Stay Secure!
Sarah

P.S.: Check out our new Trustworthy Computing blog aggregator! (http://www.microsoft.com/mscorp/twc/blogs/default.mspx) This handy aggregator is a one-stop TwC resource for security and privacy blogging news at Microsoft. Add it to your RSS feeds to stay up to date on security updates, privacy, malware response, security science news and more.

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

Chills and Thrills at FIRST

msrcecostrat — Wed, 11 Feb 2009 09:00:00 GMT

Sveika! Hey Steve here, been a while since I posted on the EcoStrat blog. With all the security events that happened during the latter half of 2008, I have been very focused on working with the security update releases and Microsoft Active Protections Program (MAPP).

You are probably wondering what an EcoStrat guy has to do with security updates and other technical deliverables. Well, I want to take a moment to explain why this makes sense. Before taking on the role of working with the monthly security release team and the MAPP program team, I primarily worked with the partner outreach team, managing ecosystem changes through industry partnerships. The partner outreach team’s goals/focus, within the scope of the EcoStrat team, is to work with industry to establish partnerships and initiatives to protect consumers. One of the most visible results is the MAPP initiative. This is a program that works with the security industry ecosystem to create an effective conduit for inbound and outbound information flow.

This was a large effort to affect ecosystem change externally, but what about internally? Microsoft is a large company that has an interesting culture and ecosystem of its own with developers, technology evangelists, security engineers, program managers, marketers, etc...

It became very clear that external ecosystem changes weren’t going to be enough without an effort focused on internal ecosystem changes as well. We needed a number of ways to effectively drive internal change with information we were getting from the external ecosystem while still following one of our core tenets to focus primarily on efforts that protect customers. One way we can do that is by releasing monthly security updates. Within the Microsoft Security Response Center (MSRC), we have an exceptional security release team that manages this large and complex effort. The team’s main focus is to make sure quality security updates are delivered to customers in a consistent manner. We noticed that a way to accomplish this was to become what we call “change agents.” Change agents influence change on a large scale most of the time without the formal authority to do so. This made sense as the release team manages the monthly release via a process that doesn’t have them building/owning any binary packages for release. They effectively were driving ecosystem changes just internally. So it made sense to have someone bridge both the internal and external sides of ecosystem change efforts.

So I’m grateful, and excited, to be in a position to work on both sides of the coin to effect change. And, I get to work with folks currently managing MAPP and the security release every month to help make these changes possible. Their good work also makes it possible for me leave Redmond and engage directly with the community in crucial industry events. Just recently, I had the chance to jump back into my partner outreach role within the EcoStrat team and had the chance to travel.

I am starting to really understand the need to be multicultural in the job we do here on the EcoStrat team. Many times it’s the cultural differences that sometime make or break the security messages we are trying to get across. This is one reason why this team travels a lot to target every place that Microsoft technologies are prevalent. It’s also the number one reason why I pick myself up and out of the day-to-day operations to understand these differences.

Last month, I got to put back on my FIRST Steering committee hat, and I traveled to the beautiful but cold city of Riga, Latvia. The FIRST Steering Committee has four meetings a year to get work done for its members. We usually use the technical colloquiums (TC) as good times to get together and partake in the great “watering hole” activities described in Andrew Cushman’s last blog.

The TC is organized by a local host. The local host for this one was Trans-European Research and Education Network Association (TERENA) computer security incident response team (TF-CSIRT). TERENA is an organization that focuses on offering a forum to collaborate, innovate and share knowledge in order to foster the development of internet technology, infrastructure and services for the research and education communities. They present and train at the TC server to educate security teams, highlighting new techniques to deal with relevant computer security issues. Usually I get to just sit back and enjoy the presentations but his time was a little different. The majority of the presentations were centered on the latest Conficker worm. Not familiar to you? Well, cruise on down to the following Microsoft Conficker page and relevant posts on the MSRC and MMPC blogs.

Being the lone Microsoft guy and a member of the Steering Committee was very interesting to say the least. After this conference, I personally know almost every European CERT or CSIRT contact after fielding some good and frank questions about Conficker.

Like I said, I spent most of the day fielding questions about Conficker and Microsoft’s actions to help security teams in their effort to protect consumers from this threat. Microsoft has a robust process when it comes to our response to issues so I was well prepared with information that went above and beyond the out-of-band security update that was released for this issue back in October (MS08-067)

Although the frank questioning felt like on-the-spot cavity cleaning, I was extremely happy to have the chance to clear up some of the myths and give some actionable information to these important security stakeholders. It also allowed me to understand information that the MSRC usually doesn’t get a chance to receive first hand. Also, having a response guy from Microsoft at FIRST allowed the security teams to understand that we are taking the problem seriously. One internal ecosystem change that was supported came about from feedback from this trip. One clear feedback item was to make sure that we had a single authoritative source/place for Microsoft efforts on Conficker. This information added more key data points to indicate that the teams in Microsoft managing the Conficker efforts were doing the right thing in moving forward with creating a single place for outlining Conficker resources. This is just one example of using external information to aid in driving change to help the greater ecosystem at large.

My Trip wasn’t all fun J

There was the 3 ½ days worth of Steering Committee (SC) meeting to decide various organizational things. One major topic was the 2009 Annual FIRST conference (AGM) in Kyoto, Japan. The AGM gives us the opportunity to meet and share presentation on a number of security topics. The logistics of putting on a large conference are mind boggling in my opinion. I am glad to say, I will enjoy watching our own Andrew Cushman figure out some of these issues firsthand as he was named the 2010 Program chair for the 2010 Annual First conference.

I love the fact that Microsoft makes a point to work with the security community at large and truly values community-based defense. Our consistency and trusted relationships make it much easier to have the conversations at the proverbial “watering holes” to get messages across to the security ecosystem that we do care and take the job of securing customers at all level as our main priority.

Now that I am settling back into a groove, I look forward to heading out and doing more in my EcoStrat role. Stay tuned for more from me as I travel to CanSecWest and Black Hat Europe.

Later...

Steve “Capt Steve” Adegbite

Share this post :

*Posting is provided "AS IS" with no warranties, and confers no rights.*

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

MS08-067: Example of Need for Increased Collaboration

msrcecostrat — Thu, 23 Oct 2008 17:05:00 GMT

You've probably heard that we released an out-of-band Security Bulletin for a vulnerability in Windows (MS08-067). By now you have probably also heard of the Microsoft Active Protections Program (MAPP). Let me take a moment to talk to you about how they worked in concert for this issue. As announced at Black Hat in August, prior to release of the monthly security updates, MAPP members receive technical details on vulnerabilities in order to speed the development of protections. Due to the unique threat from this vulnerability and because the issue was released out-of-band, we decided to not only share the information in advance but to also make our security engineers behind the SVRD Blog available for questions with MAPP partners.

During this meeting, we outlined technical details on this update and allowed for more in-depth questions on the information provided. We did this to ensure full understanding of the issue so that timely protections could be provided. We are happy to say it worked nicely, and that most MAPP partners had protections out shortly after the bulletin published and the rest should have their protection available by end of day. If you have questions about which partners have protection, see the links to their pages here.

This is a great example of the kind of community-based defense we discussed at Black Hat and I’m pleased to see us working together to collaboratively protect the ecosystem.

For more information about this release see the MSRC Blog here: http://blogs.technet.com/msrc/default.aspx

Steve “Capt Steve” Adegbite

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

The Valley Between Black & Blue

msrcecostrat — Thu, 21 Aug 2008 20:05:00 GMT

Handle:
C-Lizzle

IRL:
Celene Temkin

Rank:
BlueHat Project Manager

Likes:
Culinary warfare, BlueHat hackers and responsible disclosure

Dislikes:
Acts of hubris, MySpace, orange mocha Frappaccinos!

I affectionately call this time between summer conferences, the black and blue phase, where I wear security like a Hypercolor t-shirt, changing colors depending on where we are in our conference shipping and planning cycles. We just shipped a successful Black Hat and we are within T-minus 60 days until BlueHat v8.

Although the BlueHat v8 schedule has yet to be formally announced, there has been some early buzz around the speaker line up and I can assure you the two days of cutting-edge content will not disappoint. Please keep an eye out for speaker line-ups, abstracts, and bios, which will be posted on the BlueHat TechNet Security Briefing Page in the next couple of weeks. As always, keep up with the rolling thunder of the BlueHat Blog, which highlights internal and external BlueHat speakers from past, present, and (hint, hint) future.

But let’s back up for a second, what is BlueHat and what are the goals of this conference in the ever-evolving security industry?

First, we believe in educating our own because only when we truly comprehend our security reality, can we begin to defend ourselves and anticipate mitigations for the looming threats on the horizon. We educate our own by making BlueHat an invitation-only conference where our Microsoft developers, security engineers and product teams can receive security training credits for attending. Since security is not a spectator sport, we also encourage Microsoft employees to present alongside the external researchers recruited to present. We try and stay as transparent as possible with all our speakers, so none of the talks are under NDA.

Second, we use BlueHat as a vehicle for our partner and product teams to outreach to the security community. At every con out there, everyone knows that the “hallway track” is often the most fruitful and interesting. We seed our hallway track at BlueHat deliberately to maximize everyone’s experience. Countless introductions and targeted outreach occurs on the sidelines while the talks are going on. Researchers meet developers, speakers meet architects, CERTs meet security strategists—you name it, everyone’s engaging and the best part is it can take new relationships to a completely organic state far beyond our wildest expectations. Only at a venue like BlueHat could we pair two independent security researchers to do research on Silverlight in conjunction with the Silverlight & Adobe teams, and then have them present the results. Their presentation went so well that Manuel Caballero and Fukami won the “International Tag-Team Patches Award” at the BlueHat v7 Community Dinner, highlighting this alliance.

Third, BlueHat promotes Microsoft’s responsible disclosure policy, with the goal of coordinated release of an update and public disclosure of the vulnerability details. We also promote responsible disclosure with all of the conferences our team sponsors worldwide and ask conference organizers to promote vendor notification and the coordinated release of updates and vulnerability information.

The BlueHat Planning Team strategically invites security product vendors, security researchers, security officers, members of security response teams and past BlueHat speakers to engage while propelling MSRC values in real-time with a human face.

An almost overwhelming pupu platter of submissions sits before us; limitless in possibilities and all the better to educate our developers and execs with. Along with the great privilege of reviewing these submissions with the fellow members of the BlueHat Planning Team, comes the bittersweet burden of nailing down the final talks to exceed our audience’s expectations. The cool part is we get to immediately start working on the next BlueHat as it’s the best way to stay current on the latest trends around security and privacy.

- Celene Temkin, BlueHat Project Manager

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

Threats in a Blender, and Other Raisons d'être

msrcecostrat — Thu, 07 Aug 2008 18:35:00 GMT

There are times when one must look toward the best interests of the customers above any competitive strategies. Security is one of those themes that has the power to unite teams across company boundaries. As the EcoStrat team builds and strengthens relationships with researchers and partners, we are sometimes faced with unique challenges that we’ve never encountered before.

In the days of the big worms, we as a company and an industry had to rise to the occasion. Today our challenges have evolved, and are a great deal more complex. As we as a collective industry rise to the occasion once again, our awareness and response must evolve as well.

Enter the dawn of the Blended Threat. Mix one part third-party vulnerability with one part Microsoft vulnerability (and blend over ice) – it sounds like a drink vying to replace the Mojito.

It’s not like these types of threats didn’t exist before, but much like format string vulnerabilities that had been lurking in code for years, no one has been talking much about blended threats in a widespread way – until now. Sure, AV vendors used the term, but they were speaking of malware displaying multiple characteristics and using several techniques to achieve their goals. We’re talking about vulnerabilities that are comprised of two or more less severe vulnerabilities.

It started not with a bang, but with a whisper -- A couple of researchers each independently reported two low/moderate severity issues to two separate companies. On their own, they seemed to both companies to be relatively low-risk. But the researcher who reported the issue to us thought of combining the two vulnerabilities, to allow remote code execution.

In a historic collaboration, both companies came together against our common enemy: security threats. Microsoft Security Advisory 953818 was born of this blended threat, and the Ecosystem Strategy Team was there with a new initiative, announced today at Black Hat: Microsoft Vulnerability Research (MSVR).

Microsoft Vulnerability Research was created as part of the evolution of Microsoft Trustworthy Computing’s work in Security Response, SDL and Security Science. This program is one of the company’s many efforts to not only improve the security of Windows, but of the entire Windows ecosystem, responsibly researching vulnerabilities in third-party software most commonly used by Windows customers. While the source of the vulnerabilities will usually come from original research at Microsoft, the program will also handle third-party vulnerability coordination for blended threats reported to us by responsible researchers, as was the case with Microsoft Security Advisory 953818.

So what's really news here? If we've been practicing responsible disclosure for years, why are we making a big deal about it now? Well, think about when you've performed a penetration test on a company's application and you happen to find a vulnerability in the underlying commercial database. That's traditionally how we used to find third party vulnerabilities--through the course of our normal security work. Now, with MSVR, we're expanding our security research focus to specifically look for third party vulnerabilities.

The MSVR program will formalize the company’s responsible disclosure efforts of working directly with affected vendors, confidentially providing them specific vulnerability information and helping them to create updates.

So in the case of this recent blended threat, along with teams across Microsoft and externally, MSVR allowed us to coordinate with the finders, and across the companies to ensure the best possible outcome for our mutual customers. Technical contacts, PR contacts -- all were involved in this effort. It was new ground for all parties, as we had never attempted a joint response to a mutual security threat that was borne of smaller vulnerabilities from each of our products.

We are often asked what our team does. This is part of it. We are the ones who can fast-track security responses that affect not just our users, but users of other people's software to make a significant impact on the safety of the entire Windows ecosystem. We help make the impossible possible. We do it with a *lot* of help from our friends, and some from our rivals. One thing is certain: While this incident may have been the first, it will not go down in history as the last. Blended threats are the new black. And we will all collectively have to become the new Chuck Norris.

Like the countries of the world uniting against a hostile alien invasion, we of all people understand that we can't do it alone. We rely on the kindness of researchers, competitors, partners, and strangers to make it all come together to help us secure our ecosystem. We are irrevocably intertwined, and so the threats that face us all are blended by their very nature.

My name is Katie Moussouris, and if I am Leia, the security ecosystem is my Obi-Wan Kenobi.

Help us, Obi-Wan Kenobi, you're our only hope.

For my final thoughts on Black Hat and more, come join me at http://twitter.com/k8em0.

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

DNS: An Example of Ecosystem Partnerships

msrcecostrat — Wed, 06 Aug 2008 15:37:00 GMT

Handle:
Zot

IRL:
Zot O'Connor

Rank:
Program Manager 2

Likes:
Taking on the enemy with partners, Automating processes, good scotch and bourbon

Dislikes:
Poor reporting, FUD, miscreants, dangling participles

My name is Zot O'Connor and I am a computer genius. Really, the Seattle Post-Intelligencer says so . Okay, not directly, but I was one of the group of "computer geniuses" converging on our campus back in March because of this DNS issue. I am not a programmer, so what was I doing there? Fulfilling one of the roles of the EcoStrat team, being a trusted advisor and helping prove it "Takes an Internet Village."

Shortly after Dan Kaminsky discovered the design issue, he and Dave Midturi (the MSRC Security Program Manager working on the issue) realized that this was an industry issue and holding a summit at our campus right after CanSecWest would maximize the opportunity for getting the real geniuses in the room. They came to me and Katie Moussouris for help with organizing and making this process successful.

Our team swung into action, taking care of the hosting details (which we do for events like BlueHat), reviewing the list of invitees, and offering advice when asked. We knew this could be rough: we are talking about a coordinated release of open source, proprietary and embedded software, each with different distribution methods and issues. We are also talking about a diversity of personalities, philosophies and skills.

At the event itself I was impressed with how everyone checked their egos, emotions and issues at the door and focused on the grave problem at hand. A plan was formed, a schedule set and communication channels determined. Everyone left knowing what we had to do, except maybe Dan and me.

Personally, I set up channels to inform more partners as the update was rolled out. I've been spending a lot of time getting folks to understand the gravity of the situation and to pass the word to the rest of the communities. As the details and exploits have emerged, that task is easier, but laying the groundwork certainly sped up adoption rates.

This issue goes to the heart of community-based defense. No one DNS server provider can fix the problem. A combination of our experience in working across boundaries, the dedication of the convened group and the support of global security communities showed how we can collectively provide protection for the ecosystem.

I enjoyed Dan’s talk today here at Black Hat, worry about attacks that may come, and wish I could wave a magic wand and get everyone to update their systems. In the meantime, I will continue to work with the ecosystem: together we are monitoring for attacks, analyzing information, coordinating data feeds and sharing information that can help protect users.

Once we get a handle on that, I’ll try to figure out how to add "computer genius" to my official title...

- Zot O'Connor

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

Security through Collaboration: Microsoft Active Protections Program

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

Yut!!! Nothing like a motivating US Marine Corps yell to get your attention. Hey Steve Adegbite here, just wanted to drop some words and give you my perspective on some of the News we (Microsoft) announced this morning.

You may have seen already we launched a trusted information sharing program for security software providers. It’s a program we created in hopes of actually helping the defenders get a leg up on protecting consumers. The Microsoft Active Protections Program will allow vetted security software providers early access to the technical details on the vulnerabilities we are addressing with each monthly security update. Microsoft is doing this in hopes that we can give the defenders more time to produce timely signatures. Basically, in doing this, we’re betting that cutting out the time to reverse engineer our security updates will give valuable time back to the defenders to focus on protection enhancement and faster delivery.

Most of the security community knows me from my work with the military and government before coming to Microsoft (i.e. founder of the USMC Information Assurance Red Team). One thing I harped on was that I believe security has to take a community-based focus. One aspect of this community-based approach is the establishment of a "trusted information sharing" program. As a red teamer, my job was to find the vulnerable points and feed that information to the defenders via trusted information channels. This helped the defender shore up their defenses or at least let them know where weak spots existed.

Microsoft Active Protections Program is doing a similar thing, just in a "commercial" way, and without me looking for vulnerable spots in code/networks at 3:45am. It’s not enough to point the finger at one entity and say “Fix it.” Those of us who belong to the security ecosystem must own the problem, and share in the solution.

I believe in this so much that when the opportunity arose to run for the steering committee at FIRST, I couldn’t miss it. I am glad Microsoft saw the same value, as they have allowed me to do this as a two-year commitment. That shows tremendous dedication to the idea that security at large is an ecosystem problem. But more on that in another time on this blog.

The point here is that everything can be addressed with the right collaborative effort. Microsoft gets that and is doing its part. The next upcoming year you’re going to see a lot of that action shining through in all arenas we engage on for security. Stay tuned and remember it takes a village to raise a child...but the digital village is where I live, and we are working together to raise a great and safe cyber ecosystem for consumers to enjoy.

For more of my insight live from Vegas check me out on twitter at www.twitter.com\SteveAdegbite

- Steve Adegbite

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