From Slashdot:
http://searchsecurity.techtarget.com/columnItem/0,294698,sid14_gci1254457,00.html
http://it.slashdot.org/article.pl?sid=07/05/10/1652200
In specific, an opinion that Microsoft should get rid of their regularly scheduled patch release and go to opportunistic patch releases. The argument stems from the damage the MS-DNS flaw has caused. Microsoft had a patch for it, why didn't they release it or some such.
He closes with the statement:
Some people quibble about how long it takes MS to come up with a patch after disclosure (responsible or otherwise), but that's not quite relevant to this particular discussion. Because it DOES take a while for the Microsoft patch pipeline to produce production-quality code, 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.
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 MS 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. (As a side note, our NetWare servers also benefit from this time window).
Under the old regime we'd get a hot patch from Microsoft on Wednesday morning. It is a patch that fixes a problem that is being actively exploited. I go to my management and explain the situation, and I'd have to convince them that the pain experienced by not patching exceeds the pain of downtime in order to get a patching window approved. Or I have to wait for the next change-management window to get the code in, which may be too late.
One thing that is exceedingly clear these days is that when patches from MS are released, the black-hat community falls on them with glad cries to reverse engineer them. Once they have the underlying flaw, which may even be disclosed by the reporting party on release-day such as what happened with the Exchange iCal flaw this time around, Bad Stuff can be coded up to exploit vulnerable systems, a new Metasploit plugin developed, all that fun stuff. In short, waiting for a week or so after a patch is released is becoming more and more a vulnerability in and of itself.
Microsoft's claim that doing it on a release schedule increases the patch uptake rate is a very valid one. Because so many of those patches require downtime to apply, patch application has to be built into the IT management environment. Microsoft is getting better about no-reboot patches, Windows 2003 is better than Windows NT ever was, but there is still a ways to go. Until it becomes possible to patch a live system with no downtime, a static release schedule IS the main way to go. An opportunistic schedule practically guarantees that major IT systems (I'm ignoring home systems for this, that's a very different management regime) won't get the patch for several days to weeks after release. The black-hats have been forcing us to ever shorter lags between patch-release and "too bad, you're hacked".
Also, doing is opportunistically may very well mean MORE patches from Microsoft. This month's batch included 19 CVN numbers for 7 patches. Clearly, some patches bundle more than one fix. I approve of this, since it means less patches I have to apply, and the risk of multiple patches stepping on each other is reduced.
Windows is a horrifically complex system. Microsoft has had a very long history with providing security patches, and they've had problems with:
Side note: This morning I booted to the openSUSE partition on my home laptop for the first time in a while. Once it got done parsing the list of updates, I had something like 79 packages to update including a kernel update. Just the Security-flagged patches took 20 minutes to apply and that didn't include the reboot. In contrast, this month's Windows patches took under 5 minutes to apply. But then, I don't have MS Office on my Windows partition.
http://searchsecurity.techtarget.com/columnItem/0,294698,sid14_gci1254457,00.html
http://it.slashdot.org/article.pl?sid=07/05/10/1652200
In specific, an opinion that Microsoft should get rid of their regularly scheduled patch release and go to opportunistic patch releases. The argument stems from the damage the MS-DNS flaw has caused. Microsoft had a patch for it, why didn't they release it or some such.
He closes with the statement:
The value of the predictability of the monthly schedule simply doesn't outweigh the danger to customers posed by the flaws that go unpatched for three or four weeks between cycles.There is a problem with this. I bring to your attention a post on Bugtraq yesterday from iDefense about the Exchange 2000 IMAP vulnerability. I quote the key piece, which is in section 7:
VIII. DISCLOSURE TIMELINENote the times there. The disclosure 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.
01/10/2007 Initial vendor notification
01/22/2007 Initial vendor response
05/08/2007 Coordinated public disclosure
Some people quibble about how long it takes MS to come up with a patch after disclosure (responsible or otherwise), but that's not quite relevant to this particular discussion. Because it DOES take a while for the Microsoft patch pipeline to produce production-quality code, 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.
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 MS 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. (As a side note, our NetWare servers also benefit from this time window).
Under the old regime we'd get a hot patch from Microsoft on Wednesday morning. It is a patch that fixes a problem that is being actively exploited. I go to my management and explain the situation, and I'd have to convince them that the pain experienced by not patching exceeds the pain of downtime in order to get a patching window approved. Or I have to wait for the next change-management window to get the code in, which may be too late.
One thing that is exceedingly clear these days is that when patches from MS are released, the black-hat community falls on them with glad cries to reverse engineer them. Once they have the underlying flaw, which may even be disclosed by the reporting party on release-day such as what happened with the Exchange iCal flaw this time around, Bad Stuff can be coded up to exploit vulnerable systems, a new Metasploit plugin developed, all that fun stuff. In short, waiting for a week or so after a patch is released is becoming more and more a vulnerability in and of itself.
Microsoft's claim that doing it on a release schedule increases the patch uptake rate is a very valid one. Because so many of those patches require downtime to apply, patch application has to be built into the IT management environment. Microsoft is getting better about no-reboot patches, Windows 2003 is better than Windows NT ever was, but there is still a ways to go. Until it becomes possible to patch a live system with no downtime, a static release schedule IS the main way to go. An opportunistic schedule practically guarantees that major IT systems (I'm ignoring home systems for this, that's a very different management regime) won't get the patch for several days to weeks after release. The black-hats have been forcing us to ever shorter lags between patch-release and "too bad, you're hacked".
Also, doing is opportunistically may very well mean MORE patches from Microsoft. This month's batch included 19 CVN numbers for 7 patches. Clearly, some patches bundle more than one fix. I approve of this, since it means less patches I have to apply, and the risk of multiple patches stepping on each other is reduced.
Windows is a horrifically complex system. Microsoft has had a very long history with providing security patches, and they've had problems with:
- Patch order
- Service Packs removing in place patches
- Patches applied simultaneously stepping on each other
- Patches not applying the way they were intended
- Feature or bug regressions
- Patches causing problems in seemingly unrelated programs
- Patches changing 'undocumented behavior' exploited by legitimate 3rd party applications (and sometimes, other Microsoft applications)
Side note: This morning I booted to the openSUSE partition on my home laptop for the first time in a while. Once it got done parsing the list of updates, I had something like 79 packages to update including a kernel update. Just the Security-flagged patches took 20 minutes to apply and that didn't include the reboot. In contrast, this month's Windows patches took under 5 minutes to apply. But then, I don't have MS Office on my Windows partition.
I don't hear this mentioned as much, but I would be willing to bet that a scheduled path release is better for the mental health of Microsoft's patch developers and QA teams and otehrs involved in that process.