Black Hat Follow Up: Answering the Hard Questions
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
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: https://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.*