I'd like to share this article with the list... I think it's important. > Why Service Packs are Better Than Patches > > When most people think about keeping their systems secure, they think about > security patches rather than service packs. In fact, one of the most frequent > mistakes people make when performing security maintenance is to over-rely on > patches and under-rely on service packs. You may be surprised to know that > there are significant differences between the two, and that service packs, > rather than patches, should be used for the heavy lifting. In this article, > we'll discuss the differences between patches and service packs, and the most > effective strategy for using them. > Same genus, different species > Similar to the way plants and animals can be classified into family, genus, > and species, Microsoft software can be informally classified to indicate its > scope and purpose. From top to bottom, here are the terms we generally use: > * A product family is a collection of products that have a related > purpose. For instance, the Windows® product family includes all Windows > operating systems, such as Windows 3.11, Windows 95, and Windows 2000. > * A product is one member of a product family. For instance, Windows NT > is a product in the Windows family. > * A version is an instance of a product. For instance, Windows NT 3.5, > Windows NT 4.0 and Windows 2000 are different versions of the Windows NT > product. > * A service pack is a periodic update that corrects problems in one > version of a product. For instance, there have been six service packs for > Windows NT 4.0. Some Microsoft products use the term service release rather > than service pack, but the terms mean the same thing. > * A patch is an update that occurs between service packs. A patch is > sometimes also referred to as a hotfix. Most patches are built to correct > security vulnerabilities, but we also build patches to correct critical > stability or performance issues. In this article, though, we'll only discuss > security patches. > You can see that service packs and security patches are closely related. Both > are vehicles by which Microsoft corrects bugs in its products. But the > similarities end there. Patches and service packs have completely different > scopes, and if you understand the differences between them, you can use each > most effectively. > Service Packs are Strategic Deliveries > The chief difference between service packs and patches is that service packs > are strategic deliveries, where patches are tactical. > > That is, service packs are carefully planned and managed, and the goal is to > deliver a well-tested, comprehensive set of fixes that is suitable for use on > any customer's system. In contrast, patches are developed on an as-needed > basis to combat specific, immediate threats to our customers' security. > > The key thing to remember about service packs is that they are planned > releases. Everything about a service pack is planned - how many there will > be, how often they'll be released, and how they'll be delivered to customers. > > The reason all this planning is needed is because, in our view, every > customer should apply service packs as soon as possible after they're > released. > > Service packs have a carefully-selected scope and are delivered at > carefully-selected intervals. If we were to produce lightweight service packs > at rapid intervals, administrators might judge that they were not worth the > time and effort required to apply them to hundreds or thousands of machines. > On the other hand, if we were to produce very large service packs at > infrequent intervals, administrators might be leery of installing such a > large code change. We try to reach a "sweet spot" in which the service packs > are just the right size and are delivered at just the right interval so that > administrators will install them promptly. > Patches are just the opposite. Because we can't easily change the scope and > frequency of service packs, we develop patches to provide interim solutions > to security issues that arise between them. Patches are by their very nature > unplanned - and we always hope we'll never need to build one. But software > development is an imprecise science, and we know that there will always be > bugs - some of which affect security. As a result, there will always need to > be patches. But they're not a replacement for service packs - service packs > have two enormous advantages over patches. > Service Packs are Comprehensive > Service packs have a significantly larger scope than patches. This can be > measured in three ways: > * Service packs address a wide variety of bugs. Every service pack > addresses not only security bugs, but also bugs affecting stability, > performance, proper operation of product features, or other areas. In > contrast, a patch is tightly focused on one and only one issue. > * Service packs resolve minor as well as major bugs. On the other hand, > we know that customers have things they'd rather be doing than installing > patches, so we only develop patches for issues that warrant the disruption > they cause. > * Service packs are cumulative. Every service pack is a "roll-up" of all > previous service packs for that product - for instance, Windows NT 4.0 > Service Pack 6a includes every change made in Service Packs 1 through 5. > Moreover, whenever we release a patch, we always include it in the next > available service pack. > > The net result of all of the above is that service packs are the best way to > keep your system in top condition. Patches certainly have their place, but > even if you were to install every patch Microsoft ever released, it wouldn't > eliminate as many bugs as simply installing the most recent service pack. > Service Packs are Better Tested > Because they're planned releases, service packs are quality-driven. That is, > we won't release a service pack until it meets the same quality standards as > the product itself. Service packs are constantly tested as they're built, and > then undergo weeks of rigorous final testing that includes testing in > conjunction with hundreds or thousands of third-party products. If the > testing reveals bugs that will prevent us from meeting our quality standard, > we'll delay the release of the service pack. > In contrast, response time is the paramount issue when we build a security > patch, because security patches are built in response to a clear and present > danger to our customers. As a result, we have to balance the thoroughness of > the testing against the need to deliver the patch as soon as possible. The > amount of testing varies depending on several factors: > * Is the issue public? If it is, it significantly increases the time > criticality of the issue and reduces the time available to test the patch. > This is one reason why responsible security professionals work with the > vendor whenever they find a security vulnerability - it results in a better > patch. > * What functions are affected by the patch? A patch for a vulnerability > affecting a core operating system function requires deeper testing than one > that affects an isolated part of the system. > * What third-party products will the patch affect? A patch that changes > how third-party products work with ours requires much more testing than one > that doesn't. > We always test our patches as thoroughly as we can, within the constraints of > time in which we have to operate. But, in the end, patches are more likely to > contain regression errors than service packs are. > Getting the Best of Both Worlds > It's probably obvious by now that the best way to secure your systems is to > stay up to date on service packs, and use patches for their intended purpose > - protecting your system until the next service pack is available> . But what > exactly does this mean? > First, it means that you need to plan to adopt service packs. Running an out > of date service pack, and then piling patch after patch onto it is simply not > an effective way to keep your systems up and running. (Although it's a lot > better than running an out of date service pack and not installing patches). > Consider setting up a test lab to evaluate service packs early, and develop > plans and policies for rolling them out promptly. You might even want to > enroll in service pack beta programs when possible, just as a way of getting > an early look at what's coming. > Second, be choosy about the patches you install. One of the reasons we > accompany every bulletin with a FAQ is so customers can understand exactly > what risks a vulnerability poses, the effect it could have, and the machines > that are primarily affected. If a vulnerability doesn't apply to your > environment, don't apply the patch. Also, consider categorizing patches > according to the risk the vulnerabilities pose. If a vulnerability poses a > serious risk to your systems, apply the patch right away. But for minor > vulnerabilities, consider having a regularly-scheduled update process that > allows you to install several patches at once. This will make life easier for > both you and your users. > Following these simple guidelines will give you better uptime, happier users, > more free time and, best of all, better security. It's just a matter of using > each tool to its greatest advantage. > Scott Culp is a security program manager in the Microsoft Security Response > Center (MSRC).