共用方式為

Why Service Packs are Better Than Patches

  • 發行項
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

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.

On This Page

Same Genus, Different Species

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 Microsoft 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, Microsoft 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).