I opened a couple of polls earlier this year that asked the same basic question: "Which patch-release schedule do you prefer." (https://isc.sans.edu/diary.html?storyid=13531 and https://isc.sans.edu/diary.html?storyid=13150)

 My hypothesis was that security folks would prefer the ASAP model, while sysadmins would prefer the patch-day model. Based upon this sample, it looks like I'm wrong (for the stats folks, a two-way chi-square works out to about 1.12 indicating no link between the identified role and a preference of patch-release strategy.)  All that we can really bring from these two samples is that Storm Center readers who chose to participate prefer the "as soon as possible" delivery method for patches.

Out of the comments arose a short but helpful conversation, and a suggestion that I'd like to reiterate and support here: "Why not do both using a subscription model?"

What's so bad about scheduled release?

I'll be honest, the main diver for looking for a different solution comes from the pain I feel on MS Tuesday, especially when it also becomes Adobe and Oracle Tuesday. We don't get a lot of lead time to read through and assess the advisories before they become public, and people start demanding Swa's famous table. So primarily, it's all about me. No, not really, it's about quality. In the current model, we have perhaps an hour to look at 7.25 advisories (on average,) which means we mostly distribute the advisories and compare notes later. I'm certain that the quality of analysis and testing would go up if we instead had all of the handlers looking at one advisory.

There are some advantages to having a predicable release schedule. You can schedule when your patches deploy to limit internal outages, and you get a sense of confidence that patches are getting extra QA testing before they are released.

One undesirable and probably unexpected beneficiary of predictable release schedules are vulnerability marketplaces. While an unpatched vulnerability can demand a high price, as of the 2nd Tue, the vendor knows if they can continue to sell at that high price, or if they need to have a "sale." This makes it easier for them to value their product and extract a higher profit.

"I don't even know how you'd handle the 'as available' model."

So how would a shop that prefers a patch-Tuesday model deal with going back to the as-available model? Large environments don't roll out all of their patches at once, they usually go out in staggered stages. There's also nothing stopping you from setting up your own evaluation and deployment schedule so that patches become clustered and packaged, to be deployed at the schedule that works for your environment. The 2nd Tuesday might be convenient for Microsoft, but it doesn't have to be for you.  The point is, all of the benefits of a scheduled-release model can be preserved in an "as available" model.

"We have different Security Needs"

While everyone is under the constant risk of general web threats, drive-bys, and attacks of opportunity, there are others who are exposed to an extra level of hostile attention. These groups often lack real perimeters to help protect vulnerable systems, they need protection against the many office/application exploits that tend to target these groups and industries. Why extend their window of vulnerability unnecessarily?

Proposal: Have it Both Ways

It's very rare that an either/or problem has a viable "why not both" solution. This is perhaps one of those problems. Is there any compelling reason that MS could not provide a setting to determine when patches are deployed? They already have customizable settings for downloading, and installing automatically. Why not have one that performs a daily pull and update for the most aggressive users, while others might set the 3rd Saturday to be patch day for their builds. Certainly this could be handled by larger firms with WSUS, that would be updated in near-real-time and engineers could set the deployment schedule.

What could possibly go wrong?

First I thought that users getting the real time patches would put the batch-patchers at risk because it would give a new window where patch details are in-the-wild, while others are not patching. While this scenario already exists in environments that do staggered deployment, the vulnerable-population would be much larger in this new case. However, 80% of the advisories that have been published in 2012 acknowledge external parties in the advisories. So, details of the vulnerability are already outside of Microsoft's control, if not actually being exploited in-the-wild before release. Vulnerabilities that don't come from external sources could be scheduled for the regular Tuesday release to help mitigate the risk posed by that set of circumstances.

Adding this new patch feed shouldn't slow down remediation. It should speed it up for at-risk systems, while providing more control for deployment in larger firms and increasing uncertainty in the vulnerability-market. So vendors, please re-consider the predictable-release model.