Two Important Changes Today to Our Bulletin Process

Today is the day! At Blackhat in August we announced two significant changes to our bulletin release process and today it is the first time this actually kicks in.

Just to recapitulate: What did we change?

We introduced the Microsoft Active Protections Program which is to me a major shift in policy. Up to now we did our best to make sure that everybody got the information on a fixed vulnerability at the same time. Over time however, the threat landscape shifted dramatically. A few years ago it took the "researcher" (actually the bad guys are the ones we are concerned of) a few days to develop and exploit to any given vulnerability. Today we are at a few hours at best. Therefore we decided to change our policy and make the information about the vulnerability available to a well-defined and limited set of vendors just in time for them to prepare signatures. The idea is that these vendors can then protect their (and with that our) customers immediately at the moment of the release of the update.

I often get now the questions from customers: "We want this information as well, how can I join". As I stated above: We are talking about a well-defined and limited set of vendors. Here you find the set of criteria from the web page mentioned above:

• Execute a Non-Disclosure Agreement with Microsoft.
• Create active application-based or network-based protections commercially for Microsoft products. (Active protections are software security measures that that detect or defer intrusions into a Microsoft system or defend a Microsoft system from exploitation.)
• Serve a significant Microsoft customer base of 10,000 users or more.
• Not be a primary seller of a commercial products used to attack or weaken the security of networks or applications.
• Adhere to and practice some form of responsible disclosure.
• Agree to publish monthly protections only on the date of bulletin release, and not before.
• Not use program data directly in any product. (Copying and pasting program data is prohibited.)
• Agree to be featured as a member of the program in promotional materials about the program.

The second change is the Exploitability Index. This Index will make it easier for you to prioritize the Security Updates to be rolled out in your environment. This is actually something a lot of customers told us over and over again: They like the way we do Security Updates (at least if you can talk of "they like" when it comes to security updates J) but they would like to know how likely it is that we will see an exploit on the net. We are now doing our best to give you our assessment and we start this process as of today. So, if you look at today's bulletin overview you will see the index referring to three different levels:

• Consistent Exploit Code Likely: Analysis has shown that exploit code could be created in such a way that an attacker could consistently exploit that vulnerability. This would make the vulnerability an attractive target for attackers; therefore, it is more likely that exploit code would be created. As such, customers who have reviewed the security bulletin and have determined its applicability within their environment might treat a vulnerability with this value as a higher priority.
• Inconsistent Exploit Code Likely: Analysis has shown that exploit code could be created, but an attacker would likely experience inconsistent results, even when targeting the affected product. While an attacker may be able to increase the consistency of results by having better understanding and control of the target environment, the unreliable nature of this attack makes it a less attractive target for attackers. As such, customers who have reviewed the security bulletin and determined its applicability within their environment might treat a vulnerability with this value as an important update; however, if prioritizing against other highly exploitable vulnerabilities, they could choose to rank this lower in their deployment priority.
• Functioning Exploit Code Unlikely: Analysis has shown that exploit code which functions successfully is unlikely to be released. While an attacker could create exploit code that could trigger the vulnerability and cause abnormal behavior, it is unlikely that an attacker would be able to create an exploit that could successfully exercise the full impact of the vulnerability. Therefore, once customers have reviewed the security bulletin to determine its applicability within their environment, they might prioritize this update below other vulnerabilities within a release.

So, if you look at today's release, the situation looks as follows:

I hope that this really helps to protect our customers and the ecosystem. Your feedback is – as always – very welcome

Roger