The Composition of a Patch and the Notification Process

Before beginning the discussion of tools used to deploy patches and service packs, a discussion of the foundation of what is included in a security patch and a service pack in the Windows 2003 operating system must be given.

Microsoft Knowledge Base article 824684 (Description of the standard terminology that is used to describe Microsoft software updates: http://support.microsoft.com/default.aspx?kbid=824684) defines a Security Update as a "broadly released fix for a product-specific, security-related vulnerability. Security vulnerabilities are rated based on their severity. The severity rating is indicated in the Microsoft security bulletin as critical, important, moderate or low." Security patches are needed when a bug that has security implications has an issue. Included in these patches for the Windows 2003 platform are several bundles of code (Description of the contents of Windows XP Service Pack 2 and Windows Server 2003 software update packages: http://support.microsoft.com/default.aspx?scid=kb;en-us;824994]).

For server patches you will see the following codes in the patches that let you know which version you have:

• Srv03_rtm.Indicates that the file came from the original release to manufacturing version of the file and has not been updated

• Srv03_gdr.Indicates that the file is from a security update, critical update, and so on, and has not been updated by a hotfix

• Srv03_spx.Indicates that the file has been updated from a service pack

• Srv03_qfe.Indicates that the file on your system is from a hotfix

The security patch process normally begins when a researcher contacts the software vendor and indicates that there is a software flaw or vulnerability (Microsoft TechNet Security: Definition of a Security Vulnerability: http://www.microsoft.com/technet/archive/community/columns/security/essays/vulnrbl.mspx), or the vendor discovers it on his own. Historically, many of these flaws were of a type called buffer overflows. In this type of flaw a part of the code expects a certain data input, and the container is purposely overflowed with data causing the system to break and "dump" the attacker in a position usually enough to take over the system remotely. Recently, more patches have been needed for types of files, such as various types of image files.

After an update to the software program is coded, tested, and prepared for release in the number of language versions supported by the particular software, the vendor notifies those affected by the software fix. This coding and testing process can be as short as several weeks to as long as several months depending on the underlying affected code and the dependencies of other software on that code. And then the patch is deployed and all is good, right? Unfortunately, if it was as easy as that, this chapter would be one page long. The reality is that you are introducing new code into an established system. Although the code has been tested by Microsoft to meet a certain standard, it has not been tested for your specific environment. Furthermore for small firms, it is difficult to make a duplicate, identical system. Although Microsoft has increased its patch testing process to include outside partners and independent software vendors to increase the reliability and dependability of patches, the probability is that Microsoft has not tested your clients' line of business applications.

Many ask whether the world will get to a day when patching is not needed. In general, most experts say that we are getting to the day when it's less needed, but given that human beings write code, and other human beings review the code and make it do things the original authors and developers never intended, we will always have security flaws. The analogy is always to bridge designers and software developers. The bridge designer knows the design constraints she is up againstgravity, weather, and so onand these constraints remain basically constant. Now look at software. Computers use as their foundation for communication a software design model that was assumed to be on a trusted network. Browsers were designed to offload computing power to desktops to help ease the load on web servers. Yet one could argue that your desktops that browse are one of your riskiest attack positions in an SBS network, and thus you should perform a risk analysis of your need for timing of patching based on the surfing habits of the end users and historical security incidents.

Service packs are bundles of cumulative packages of hotfixes, security updates, critical updates, and improvements. A service pack undergoes both internal and external testing. Many in the security industry believe that you should apply service packs, but only apply those security patches that you deem necessary for your environment under the theory of reducing the amount of new code in your network that you need to be concerned with. (Microsoft TechNet Security: Why Service Packs Are Better Than Patches: http://www.microsoft.com/technet/archive/community/columns/security/essays/srvpatch.mspx.) They believe that you should review the patches, prioritize the risks, identify the attack vectors, review exactly how the attack would be done, examine the security vulnerability listserves to see which ones have active exploit code, and prioritize patching accordingly. Most small business specialists would argue in the SBS environment that there are just not enough resources to perform this type of analysis, nor does one see enough issues with patches to make this sort of blanket statement. Either the consultant patches everything, or he secures as best as he can and deploys in a delayed fashion. The customer of the small business consultant will not see the value in the deployment of a patch when it breaks things.

Best Practice: Understanding Service Packs Versus Security Patches

Service packs are more tested and are expected to be fully supported by Microsoft partners on the day they come out (especially large vendors that rely on Microsoft platforms for revenue streams).

Security patches go through much less rigorous testing, and vendors do not obtain patches before releasing to test.

Your clients may have a specific line of business application that requires you to perform additional analysis or may not support the application of patches. Be aware of this Catch 22. For many line of business applications in healthcare, banking, and accounting, have your client review the patch supportability on the key line of business applications. Consultants typically find that vendors only certify applying service packs and only some security patches. Therefore, if necessary, discuss the patching strategy with your customer. Discuss the risks of not patching with that of supportability. Help to guide your customers into asking vendors to support patching if they do not already do so.