A colleague of ours likes comparing software to the Golden Gate Bridge. The Golden Gate Bridge was built in 1935, yet has only needed slight seismic improvements over the past 70 years . That is because, in 1935, we knew pretty much everything there was to know about building bridges. Contrast this with software. Software is by far the most complex thing mankind has ever created. Nothing else mankind has ever done has more interrelationships than software. As hard as we try to produce perfect software, we just do not currently have tools and processes in place to do so. Therefore, at times, a patch is necessary. What proves a software vendor's mettle is not whether they have to release patches, but how many and the quality of them.
A perfect patch would be one that is applied completely silently, without a moment's downtime, and no application compatibility impact. At this point, it is also just a dream. Patches are issued to resolve particular vulnerabilities that attackers could exploit. As such, they are typically issued on a much tighter schedule than a typical product release. There simply is no time for a beta program or extensive compatibility testing. Obviously some testing is done, but it is not as extensive as what happens with an interim release like a service pack, or a full product release. This means that, occasionally, patches cause problems. A small, seemingly innocuous change in one component could very well introduce problems for some other piece of software. This sometimes happens with patches just like with any other software upgrade. It is unfortunate, but the truth. The best patch is one you do not have to apply. The second best is one that does not destroy any existing functionality and fixes the problem it was intended to fix. The rest of the book deals with how to protect your network, in some cases in ways that mitigate the need for patches. However, all systems will eventually need patches, so in this chapter we discuss how to manage them.