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." ( and

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)

ISC Feature of the Week: Handler Select News Feed

Published: 2012-08-04
Last Updated: 2012-08-04 04:49:44 UTC
by Adam Swanger (Version: 1)
0 comment(s)


This week's feature just went live so keep checking back as information is added and subscribe to the RSS to keep updated in your favorite reader! Introducing the Handler Select News feed at listing news items highlighted by the ISC Handlers.


The top summary explains the page in detail and links to one of the news sources at

Subscribe to the Handler Select News RSS feed! links to an RSS feed at

Sort By -> Title, URL(linked in title), Date or Handler Rating.  Click again to reverse sort order.

Select News lists the current Handler Select News items

  • Title links out to the full post
  • From is the source of the news item
  • Stars are the average rating from 1-5 by the handlers
  • Full date/time of when the item was added to the Handler Select Feed

We have awesome additional features planned for this so stay tuned!

Post suggestions or comments in the section below or send us any questions or comments in the contact form on
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Stom Center


Keywords: ISC feature
0 comment(s)


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives