Vendors: More Patch-Release Options Please

Published: 2012-08-04
Last Updated: 2012-08-04 18:55:24 UTC
by Kevin Liston (Version: 1)
3 comment(s)

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)

First Poll
Scheduled Day 416(23.9%)
ASAP 1326(76.1%)
Total 1742
Second Poll
  Sysadmin Security  
Scheduled Day 124 112 236(35.2%)
ASAP 210 225 435(64.8%)
  334(49.8%) 337(50.2% 671

 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.

3 comment(s)

Comments

"Why not do both using a subscription model?"

Because reverse engineering a patch is a method of finding exploits. You -must- always do the release as broadly as possible all at once, since a windowed release system will serve to punish the people not in the first window by giving the attackers a group of systems with a vulnerability that can be sure has no available patch in many cases.

While the vendors will work with companies before a patch is released, they're usually doing it because that company found the problem and wants a fix. If that company wanted to exploit it they never would have reported it. Letting the patch be released to anyone else could be offering that person a tool to attack huge numbers of computers on the internet. Who do you trust to not either use or sell that kind of information? Do you also trust the college interns that do that company's patching? How would the other customers who are not on this list of special people feel about being left vulnerable?
That's exactly the risk I was trying to describe. Once the patch is released, it lowers the bar for developing an exploit. That's the big downside for the hybrid model-- this is not present in either pure model.

I don't follow the "list of special people" since there would be no restriction-- it'd just be an option in your windows update software. Does that change your concern?
Option 3 - Increase the frequency of the scheduled patch model. By releasing patches twice a month (instead of the normal 1 for MS), you would (theoretically) cut the number of advisories that need to be reviewed in half while allowing for a more timely distribution model.

Diary Archives