Microsoft Needs to Rethink Windows Security
In October 2003, Microsoft formalized “Patch Tuesday” as a phenomenon. Next month it will turn 21 with no indication of the stream of security issues being fixed in Windows each month ever slowing down. Patch Tuesdays have institutionalized a habit of fixing symtoms rather than root causes, with an impressive list of catastrophic outcomes for thousands of Microsoft customers over the years. We are still receiving new “fixes” for security hole categories that were known in the mid-to late nineteen-nineties. Microsoft is desperate to avoid breaking backwards compatibility, but this is actually causing trouble for the entire rest of the world.
What we would really need to see - on a company-wide basis in Microsoft - is a system similar to what Toyota implemented in their production lines: When someone discovers a problem, “stop the outflow of defective products”, then “build quality into products by (…) preventing [issues] from recurring”. Again, I know backwards compatibility is Microsoft’s big thing, but has anybody actually paused and thought about the cost of this backwards compatibility? To Microsoft? To their millions of customers? At what point would it actually be cheaper to update legacy software to use new APIs - or replace it outright - than to have tens of thousands of Microsoft employees and IT staff alike around the globe spending tens of thousands of hours every month doing busy-work, putting additional layers of band-aid on obviously fundamentally broken products?
The issue here isn’t that imperfect humans make mistakes. That happens in all programming. Neither am I arguing that we shouldn’t allow software to keep evolving - a process that in itself is bound to introduce new errors. The issue is that we repeatedly see security issues in areas where we know how to do things better, but for monetary reasons Microsoft are choosing not to. For them, it’s not even short-term monetary reasons: A significant portion of IT professionals out there have never expierienced a world where you didn’t get critical bug fixes on the second Tuesday of every month. I’m sure I’m not overly cynical if I suspect that a large part of Microsofts recurring revenue comes from sales of support contracts sold to companies who need to know that their software is as secure as possible. In fact, to a certain kind of person, a steady stream of monthly fixes indicates that they’re getting value for their money.
But for us who make or influence software choices in a corporate setting, it’s time we took some time to think about why we should even want to use a system that’s permanently critically broken.