Service Packs and Patches

  • From: "Julio Danoviz" <jedanoviz@xxxxxxxxxxxxxxxx>
  • To: <exchangelist@xxxxxxxxxxxxx>
  • Date: Wed, 24 Jul 2002 10:19:27 -0300

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


Other related posts:

  • » Service Packs and Patches