Pondering Microsoft's monthly patch cycle conundrum

In a zero-day world when Windows exploits are circulating for months before Microsoft can get patches ready, should Redmond consider a change in its monthly patch cycle?  
The results of a poll in Larry Dignan's first take on this issue (42% prefer "as needed" patches from Redmond) were a bit of a surprise to me so I asked a few prominent security pundits to weigh in.  The questions: Do you think waiting a month to get a patch is too long a window of exposure?  Should Microsoft go twice-a-month?  Or, should they go the Oracle route and release updates on a quarterly cycle?

Dr Jesper Johansson, former Microsoft security strategist
I was very negative to the monthly process when it was first introduced. I thought it would expose customers to needless risk by holding updates that were ready until the next scheduled release cycle. To address those types of concerns, Microsoft did provide for exceptions where updates could be released out of cycle if there was an urgent need. They have used this prerogative about half a dozen times or so if memory serves me right.

The move toward zero-day attacks is clear and very disturbing. It is indicative of something much more sinister that is happening, which is a shift in the types of attackers. The Microsoft release process is flexible enough to deal with that threat, providing they have good enough intelligence. They will not release a patch out of cycle unless they deem that the threat to the user base at large is such that it warrants breaking the cycle, which costs Microsoft a fair bit of money, and costs customers fair more. The factors to consider here are:

(a) can Microsoft generate good enough intelligence on what is really happening
(b) can they respond fast enough to an emerging threat, and
(c) are the broad threats that we have seen in the past really relevant any more.

Addressing these issues in order:
Microsoft has shown a fairly good ability to gather intelligence on what is going on out there. Frankly, they are probably as good as the best out there given their partnership with them.

As for b, that is a much harder one to answer. Microsoft can release an update fairly quickly once it is all done. It is developing the update and the collateral information that takes time. However, that time is invariant. Whether they are on a monthly, random, or interim release cycle, the same material needs to be there. The larger issue is whether customers can get the updates deployed fast enough to counter an emerging broad threat. My personal opinion is that the answer to that question is "no." That answer does not  change whether the release cycle is monthly or not. The monthly release cycle helps customers deploy the regularly scheduled updates faster, but the emergency ones are still lagging.

Finally, are the broad threats relevant? Yes, for the time being, there is still a risk for that. However, the likelihood that someone will burn a true zero-day on it is quite low. Those are far too valuable for attacking a specific target that can generate money, or otherwise benefit the attacker. More likely we will see broad based attacks using "0.5" days; the vulns that are announced on the public mailing lists but still unpatched. Microsoft, as well as other vendors, have a much longer time-frame to counter those, and have usually done a pretty good job of doing so. With a few they have had an update ready to go and have then been holding it to watch the developments.
So, yes, I think the monthly cycle is working better than I thought it would when it first came out. Customers generally like it as it makes servicing more predictable, and I think in the new world of threats, it is working reasonably well.
David Maynor, CTO, Errata Security
I am a big fan of their monthly update cycle for a couple of reasons. The first is that a lot of people don't realize the amount of time it takes to research, fix and QA a security patch. One of the things I like about the Microsoft method is they will evaluate a vulnerability and look for different but similar types of vulnerabilities and eliminate them as well. They basically have a dedicated product pen-testing team called the SWI (Secure Windows Initiative) which I think is dramatically improving the security quality of their product.

I think a monthly cycle is just about right with a quarterly cycle being way to long. The one area I would like to see improvement on is a reaction to bugs being exploited in the wild. It's a bit vague when you see a MSRC blog post saying that there is directed attacks using a client side word flaw. This really doesn't do much but cause a ripple of panic through their user community. What they should do is give more information about the directed attacks; things like what industry has been targeted and the number of attacks they know of. If you find out that 3 people in the banking industry have been targeted, it is not as wide scale as a lot of people think.
Even though there is a lot of effort that goes into the patching and fixing of a vulnerability, I think they should be able to provide a quick fix for some of these flaws in a sort of "first take" at a patch. They can label it with declaimers and what not and provide an easy way to back out of it if something is wrong but waiting for weeks for a patch for an actively exploited flaw is not good.
Joe Stewart, senior security researcher, SecureWorks

I understand the reason for the monthly process -- a regular update cycle appears less like a constant barrage of security flaws. If updates were released more than once a month, it would put administrators into a spin of never-ending patch maintenance.

It's also bad from a customer relations standpoint. With a regular patch schedule, network administrators can better plan their testing/rollout/sleep patterns.

By the same token, however, it means that computer criminals can also better plan the timing of their attacks for maximum payout in terms of the number of exposed systems -- so there is a tradeoff.

Personally I'd like to see Microsoft keep the monthly patch cycle, but release out-of-cycle, less-tested "beta" patches when zero-days are afoot.

I see these as something that would not be part of the Windows Update service, but could be mass-deployed in an enterprise via SUS. That way, administrators can choose the amount and type of risk (stability vs. security) they are comfortable with.
Dr Jose Nazario, senior security researcher, Arbor Networks
I think the one-month window of exposure is about as balanced as it can be. The constraints they have to work with include the limits of what the largest enterprises and businesses can roll out realistically. Bear in mind these companies have teams that review the public information, private information, and try and look for exploits and knowledge of attackers out there. They use this to score vulnerabilities as to when they need to apply the patch, from ASAP to next scheduled window.

Because some of these, firms have massive amounts of equipment to keep running, much of which is mission critical, downtime is a major concern for these teams. Also, they have to test these updates to ensure that there are no issues introduced. Downtime is costly for these folks, and impacts everyone (ie these include our banks, our phone companies, and the like). The major driving factor here isn't the home user, but instead the large corporate customers. I think its more a matter of impact than how much they're paying, too.

A few years ago I had a great chance to talk to a CISO from a major global finance company, and this was a few months after the Sasser worm came out. They had rushed this through their teams (evaluate, test, go back to Microsoft with issues they found, retest, and roll out) and it still took them nearly 3 weeks to get it completed. That was a rush job, too, and was a rush job against every Windows host they had. This is the kind of scenario that cant do this sort of thing more than once a month.
As such, I think that once a month is probably the best balance that we can find. We know when these will be released so we can ensure all parties have their plates clean for that day (and that week, no less).
Microsoft has shown flexibility in this case and justly so, and their response so far has been about right. They've only done this a few times in the past year or two, but every time has been justified. As for when they haven't and some thought they should, they've also done a decent job of being right on that point, too.
Contrast this to semi-random updates that we see with most other vendors, or the quarterly system that we see with Oracle, and given the set of constraints they have to work with, I think Microsoft's position has been sound. The other vendors I can think of that should look at something similar include Cisco and Juniper, each of which is a major player on the Internet stage. It is simply untenable to have such critical resources updated without being able to anticipate when this may occur so you can schedule reviews, testing, and outages.

Susan Bradley, partner, Tamiyasu, Smith, Horn and Braun
I call it the patcher's lament...

I want patches right before I am truly at risk.  If I'm not at real risk, please do not disrupt my working network by making me patch unnecessarily. And while those zero-day things may be a risk to a high-profile network and thus they might need patches as soon as they are ready, me with my risk and threat level don't need them until they become common place.
The problem is that my risk tolerance and threats that I'm subject to are different than say, the Department of Defense, so for their level of risks they need them NOW. Since I'm not being targeted for zero-day, I don't need them... the patch will actually disrupt me more.
But there's no easy answer to this because, while I can say that I don't think my risks are the same as the guys in the DOD,  I share the same pipe, and I don't have real quantifiable things to point to to say that I'm not at risk.  I don't think so, but am I 100% sure?  Nope.  Can I ever be 100% sure.  Nope.
Combine that with "zero-days" becoming a headline grabbing event and it's getting harder and harder to distinguish real risk from perceived risk. In business, I'm aiming to ensure I meet perceived risk.  I'd like perceived to match real risk, but I'd be naive if I didn't state that the two are sometimes not anywhere close to one another.
Combine this with additional non-Microsoft applications that are not providing patch administrators with acceptable ways to patch vulnerable applications (i.e. Apple QuickTime which requires folks to launch a separate updating launcher thereby ensuring that I cannot control this patch process firm wide and that machines have to run as admin to get patched, both of which are unacceptable), and I'm doing a lot more "do I need that app?" No? Then remove it.  "Can I ACL it or some other mitigation?"  Yes?  Do that. "Am I running as non admin so there's less of a risk and I can wait?"  Good, I can.

So to answer, I don't think there's an easy answer.  As long as I share the pipe with the guys that ARE getting specifically targeted and as long as none of us can quantify the risks worth a darn AND as long as security vendors grab headlines by freaking us out...there's no easy answer here. 

Alan Paller, director of research, The SANS Institute

The reality today is that you are waiting, on average, close to four months for a patch.

That's about how long vendors know about the problem before they release a patch, so bunching them up monthly is a great idea as long as they also act quickly to patch zero-days.