Ask Troy Atwood, our Technology VP here at IT Business Edge, for an added feature, piece of software or a whole new Web site, and he'll begin his answer with, "Good. Fast. Cheap. Pick two."
It's a reasonable way to start the negotiation that will lead to the final solution -- we don't always get exactly what we wanted, or thought we wanted, but we get to (or have to) prioritize the aspects that will most expeditiously solve our problem -- our business need. (It also helps that Troy always says this with a smile on his face.)
The phrase came to mind as I was reading about the aftermath of Microsoft's out-of-cycle patch release on April 3 for the ANI cursor flaw that became public knowledge five days before. The pre-Patch Tuesday release, plus the fact that Microsoft knew about the vulnerability back in late December 2006, kicked off another round of debates about whether it's "fast" or "slow" with patches.
ZDNet blogger George Ou and others are outraged (outraged!) that over three months passed and attacks began before the critical flaw got the official Microsoft patch. Ou flatly says that Microsoft makes it a practice of ignoring zero-day vulnerabilities -- or ignoring threats so long that they become zero-day attacks, as in this case.
On the other side, a smart post by Robert David Graham at Errata Security gently and thoroughly answers the question of why these Microsoft patches can take so long. The thing to remember, says Graham, is that it's one thing for a third-party security firm or programmer with a bit of initiative, know-how and free time to quickly shoot off a fix for a flaw affecting Microsoft products -- they aren't required to test every version of the affected software or all the third-party apps that are going to be affected by the fix. And they probably won't have to clean up the mess they create in the process.
But Microsoft has to. And Graham thinks one week for testing and bug elimination for 30 versions of Windows plus thousands of affected third-party apps is "amazing."
Like I said, none of this is a new argument, on either side, and none of it is a surprise. When you're Microsoft, you can't win for losing and you get no love. So I got to thinking about what would happen if Microsoft gave the people what they wanted when they chose "fast" and "cheap" instead of "good" patches.
When a third party beats Redmond to the punch with a fix, there are always shops that will take the chance that they'll introduce new problems if they roll it out -- depending on the apps involved and the time allotted for evaluation and testing. Sometimes taking that risk makes sense.
What if Microsoft conducted a test the next time a zero-day vulnerability threatened one or more of its products and put out, say, a same-day patch that was as fully tested as humanly possible during that timeframe? No guarantees, but customers could take it if they really wanted "fast" and were willing to take the chance. If not, they could wait for the fully tested, "good" patch to come out.
It's one of those questions that will never be answered, because it will never happen. But I still wonder if it's a risky move that Microsoft could take to silence the critics who will always need it, but never love it.