I got up this morning... and got ready for work... Like most days I noted the date on the calendar. Friday, May 11th... excellent. I got in to the office and decided to check out the RSS feeds to see if anything interesting was happening... I came across a post on SearchSecurity and the first thing I did was double check my calendar to ensure it wasn't April 1st. Reading the article, all I could think was, "It's got to be April Fool's Day". Yet it wasn't... it was indeed May 11th and I was supposed to take the article seriously.

The author of the article was submitting the idea that Patch Tuesday should be eliminated... that admins and security people dread Patch Tuesday. Now it's not really a secret that we don't all get excited for Patch Tuesday... given our SLA we generally work a rather long day to get quality coverage to our customers as quickly as possible... but at the same time, at least we know when to expect them and how to co-ordinate our resources. Then I think about the "other side"... what I call corporate security... When you hear about Patch Tuesday you hear that Microsoft decided to take that route because admins were asking for it. They wanted to know exactly when the patches were being released so they could schedule for downtime and resources. I can understand this, when I was an admin at a small business I knew I had a couple days to test the patches and a day or so to roll them out. If I was constantly testing single patches, I'd have never had time to do anything else.

On the subject of testing patches... the author of the article uses that as a reason why patches should be released as they are ready. Apparently if companies perform tests prior to applying patches to production machines they are opening themselves up to serious security issues. Is author's theory that; "if you only get a single patch you don't need to test it first"? Otherwise you'll have the same issues whether or not the patches are released on a schedule and in bulk. Maybe I learned something today... One patch can't cause a production machine to blow up... you can apply it without internal testing... it's only bulk patching that requires initial testing. Now, raise your hand if you think only an idiot would believe that.

Reading these comments makes me wonder if the author has ever been in an enterprise environment; if he's ever had to worry about the deployment of patches across hundreds, if not thousands, of machines. Has he ever had to question what would happen when a ASP.NET patch was applied to a server running a homegrown ASP application? We've all heard stories about how delicate SCADA systems are... Should we simply apply patches to systems running automation software at a manufacturing plant or perhaps the systems responsible for power and water distribution? I foresee a number of problems with just haphazardly applying a patch.

Other issues were brought up... and these two are really good. The first is that there are more public vulnerabilities the day after the patches than the day before... This follows the same principal as patch testing. Even if you have a continuous release as ready patch cycle, exploits will still appear as patches are released. The bad guys have access to the patched and unpatched binaries and with a little effort they can find the source of the vulnerability. Releasing patches independently of each other without a schedule won't stop this... Sure the number of exploits released the day after a patch release may drop but the number of days that patches are released would increase. That makes this yet another moot point in a pointless article.

The second issue is in regards to "time till patch". The author chose the DNS vulnerability as his example... citing that it was used in numerous attacks and that a worm even spread... Other than the initial ISC postings and the initial mention of the worm how often did we hear of this problem? It wasn't making headline news and it wasn't as serious as say the WMF exploit. The worm was so poorly coded that it looked for a single port. Since the DNS RPC Management interface listens on a dynamic port (which you can change by simply restarting the service) it was actually fairly useless. There were also mitigation techniques made available that were 100% effective in curbing this vulnerability. All of this leads to the DNS vulnerability being a really poor example to try and prove that Microsoft's patch timeliness is horrid.

When MS06-040 was released we saw numerous references to the "end of the worm". Yet the author of this SearchSecurity article comments on how many recent vulnerabilities require emergency (out-of-band) patch releases... This article is a page of FUD from start to finish... I'm guessing, given the number of banners on the page, that their revenue comes entirely from pay-per-click sites... and for that reason I refuse to even link to the original article (Instead here's the Google Cache link)... I don't want to be responsible for increasing their revenue by linking to their FUD.

A regulated patch cycle is exactly what this industry needs... and it obviously works well. We are seeing other vendors, such as Oracle, moving to the same scheduled, regular release cycle. I leave the readers of this blog with a simple message: "Beware of FUD". The internet is crawling with it and it will make your head spin and your skin crawl... you just need to be able to distinguish between the drivel and the useful information