| |||
|
|
||
|
|||
| |
|
Home > Security News > Scrapping Patch Tuesday a bad idea, say bloggers |
| |
|
|
|
|
| Security News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IT security bloggers have been mostly polite in their reaction to last week's column from my colleague Dennis Fisher, where he suggested Microsoft scrap Patch Tuesday in exchange for a quicker, more frequent security update process. That doesn't mean they all agree with him. In his column, Fisher wrote that instead of leaving flaws unpatched for weeks between cycles, Microsoft should use its resources to produce high-quality patches shortly after vulnerabilities are discovered. I haven't found anyone in the blogosphere arguing that it's acceptable to leave security holes unpatched for weeks at a time. Most people agree the software giant needs to develop a better way to deal with the steady increase in zero-day flaws, many of which have been disclosed right after a monthly patch rollout. One indication that a quicker fix schedule is needed is that some IT shops are starting to rush through their patch testing because they're desperate to get them deployed before the big attack arrives. But a majority of bloggers say the answer isn't to do away with Patch Tuesday altogether. They still like knowing that Microsoft patches will be released consistently the second Tuesday of each month. It's something they can plan around. Nobody wants to go back to the days when Redmond would send out critical fixes without warning.
Instead, they seem to want a quicker method for receiving patches for serious zero-day flaws outside the monthly cycle. Other than the zero-day fixes, however, people seem content saving the rest of the patch load for once a month. New Zealand-based computer programming student Kaiwai Gardiner wrote in his blog that getting rid of Patch Tuesday is a "stupid" idea. The current arrangement, he wrote, is a lot better than the old situation where a large number of patches used to be released in a random fashion. "You either have Patch Tuesday or have patches that are rushed out, resulting in large numbers of patches having to be pulled and re-issued because they either cause [or] expose new vulnerabilities, fail to address the problem, or worse, cause numerous issues in regards to system stability and compatibility," he said. A self-described academic systems administrator wrote in his SysAdmin1138 Events blog that Fisher's argument is problematic because it flies in the face of responsible disclosure. He cited the recent patch process for the DNS flaw as an example of responsible disclosure in which everyone received protection in a reasonable period of time. "The disclosure," he said, "was done to Microsoft in January, and it was in May before the fix was released. The time spent between 'initial vendor response' and 'coordinated public disclosure' was spent by Microsoft developing a fix, testing the fix, and integrating the fix into the patch release pipeline. This is part of 'responsible disclosure,' which is telling the vendor about a problem, and not telling anyone else about it until the vendor has produced a patch." He said that while some people quibble about how long it takes Microsoft to come up with a patch after a flaw is disclosed, it does indeed take awhile for the Microsoft patch pipeline to produce production-quality code, and that "doing a staged release schedule like what they do right now makes all the sense in the world. They can do short-cycle patches, but even then it still takes weeks to produce a patch." He added, "I've been at this game long enough to have been around for the opportunistic patch schedule Microsoft followed before they started regulating when they released. And let me tell you, having a schedule for these things helps immensely. We know patches from Microsoft come out on Tuesdays, so we've built into our schedule a 'change management' window Tuesday night expressly for that. This is pre-arranged with our users, we don't have to go to them to take their systems down so long as we do it Tuesday night." Mike Rothman, president and principal analyst of Security Incite in Atlanta, wrote in his Daily Incite blog that Fisher makes some valid points, but that the monthly cycle is still the right approach for the vast majority of patches and the vast majority of customers. "Any organization of size has huge issues with testing and ensuring the patches won't cause regression issues with the rest of the systems," he said. "Doing any more than once a month means patching is pretty much all they'd do. There are approaches to get patch-like functionality and use IPS signatures to block these attacks until the patches can be worked through the change control process, which does take time. So I hear where Dennis is coming from, but monthly is still the right frequency for patching." To be fair, I did find a couple bloggers who agreed with Fisher. In the Live Journal blogging site, Brian Martinez wrote of Fisher's suggestion, "I'd be all for this, considering how Windows Update brought both of my laptops to their knees during the latest patch-fest." IT professional Todd Towles wrote in his Thoughts of a Technocrat blog that he understands why corporations like Patch Tuesday, but, as Fisher stated, rarely are the patches applied right away anyways. "Plus," Towles wrote, "a good company should have multiple layers of defense against emerging evil. This is why they don't have to patch right away in the first place." Those who like having a once-a-month security update they can plan around will probably be more likely to embrace the process, now that Microsoft has announced it'll start squeezing more detail into the advance bulletins that come out each Thursday before Patch Tuesday.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
| |||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
