Vulnerabilities and asset management
There's a little buzz going around right now over Microsoft's latest Security Advisory - "Vulnerability in Microsoft Word 2000 Could Allow Remote Code Execution".
A few people are irritated simply that there's an attack doing the rounds, and yet there's no patch to download.
Sure there's a patch - it's called "Office 2003". And in a couple of days, it'll be called "Office 2007".
Whenever a software developer produces new versions, they move features around, deleting old code and writing new code, and often in the process, removing bugs (as well, of course, as adding some!) As a result, some bugs from earlier versions don't make it to newer versions.
Also, the architecture of portions of the software may change, including the interface presented to users. This results in software that simply can't be exploited the same way (and, ideally, can be exploited in fewer ways than before).
So, even when developers aren't consciously fixing known bugs, a security-aware development team is naturally going to remove security vulnerabilities almost "by accident", as a natural consequence of the way they design, write and rewrite code.
It's not a surprise, then, to find that Office 2000 is vulnerable, but Office 2003 is not.
But this vulnerability should serve to remind you of another issue - that of your software asset management. Office 2000 is past mainstream support. Sure, it's on extended support until July of 2009, and that does mean that you'll get security updates for free - but it means you will have to pay for all non-security support calls (even if you have some "free calls" left over), as well as all non-security updates.
The Daylight Savings Time changes for 2007, for instance, are an example of a non-security update. How much will that set you back for Windows 2000? About $4,000 - that's right, four thousand dollars to turn your clocks forward an hour. Seems a high price to pay, yes? It's the price to hire Microsoft staffers to continue supporting an operating system that they wrote last century.
How can you avoid paying such a high price? Simple - keep ahead of the game.
Your asset management team should be tasked with knowing when products are going to cross phases of support during their lifecycle - the page for Microsoft is easy to find at http://microsoft.com/lifecycle - and should kick-start projects to upgrade your systems before they head into the sunset. Remember that it may take up to a year or two for your business to test a new operating system for compatibility with existing applications, so that means your projects need to start a year or two before your existing software drops off support.
Then, you'll never be faced with a security patch that you can't apply yet, because you're not on the base version the patch requires as a bare minimum.