Check the locks work for your house

The analogy of an operating system as a house that I introduced a couple of weeks ago seems to have caught the fancy of quite a few readers. You’ll remember that we were talking about security, patching and its consequences. That is, if you don’t lock your doors the “bad guys” can just walk in. Patches, in this analogy, become not only stronger locks but also automatically locking locks. They’re a “good thing.”

But there can be problems. As long-time reader Jody Combs points out:

“With most houses, locking the front door doesn’t cause the dining room to suddenly shrink, a new wall to spring up in the middle of the living room, the driveway to change locations, or the house to suddenly disappear from the neighborhood.  Locking the front door hardly ever results in being evicted from the house and having to head to the nearest lumberyard to start building a new one.  This can and unfortunately does happen with operating system patches.”

That’s all still true, unfortunately. The problem is that operating systems and the hardware they run on have become very complex. I often hear Microsoft being compared unfavorably with Apple in the matter of operating system patches. One reader replied to the “house” analogy by remarking on the “bullet-proof” OS/400 operating system from IBM. But there’s a major difference between Microsoft on the one hand and Apple and IBM on the other – Microsoft doesn’t make the hardware!

While there have been instances of a Microsoft patch “breaking” a Microsoft service or application, it’s very rare – it happens about as often as a Macintosh patch “breaks” an Apple application or service. There are standards that hardware manufacturers and independent software vendors use when constructing platforms, services and applications for Microsoft operating systems. But the sheer number and variety is a road block to successfully testing a patch, should it be desired to have the patch go into circulation during my lifetime.

When a bug, or flaw, is discovered (and this goes for any software from Microsoft, Apple, Novell, IBM, Adobe, Sun, whoever) it must first be reproducible in the vendor’s lab. Then the circumstances are investigated to find the cause of the problem. In the event of a serious security problem, sometimes a “work-around” is released so that some security is restored while waiting for the patch to be developed and tested.

Developing the patch is relatively easy, once the problem is identified. The hard part comes next: testing the patch in as many possible scenarios as you can. Only you know the makeup of your servers and networks, so only you can truly test it in your “real world” environment.

But vendors try very hard to recreate as many combinations of hardware and software as possible to test the interactions of the patch with the environment. There’s a full round of alpha and beta testing, just as there is for a new release. Even release candidates get extensive testing before one is chosen. This all has to happen in a very short timeframe, however, because the press, the users groups and the competition are clamoring for action ASAP. It’s very hard to draw the line that delimits when there is “enough” testing.

Nothing replaces the testing you should do yourself in your own test environment which mimics, as closely as possible, your production network. That’s the bottom line. Now if you’ll excuse me, I have to go figure out where my driveway has disappeared to.