The Patch Testing and Risk Analysis Process

Before Windows Update, Microsoft Update, or Windows Software Update Services are ever deployed in the network, you should decide on a patch testing and deployment strategy with your client. Most would strongly argue that if you have Windows XP with Office 2003, you should not spend your time or your client's dollars doing any sort of testing for that interaction. Patch issues typically occur with third-party products. If you historically have not seen issues with desktops and patches in your client base, it will probably be acceptable to turn on automatic updating on the workstations either via Windows Update or Microsoft Update or Windows Software Update Services. If, however, you have seen issues on certain desktops or certain applications, or your client prefers more granular control, when you set up Windows Server Update Services, you can easily set up patch zones and determine which machines get updates and when.

The patch testing process in a small firm environment differs greatly from a large enterprise deployment. Large firms typically have a lab setting of identical hardware and similar or identical data. One would think that the best test lab would be identical databases, but in reality, when patching or updating databases, it actually may be more beneficial to set up a batch of test data that can have many more alternatives and variations to test out all sorts of possibilities. Obviously, if your small business client has this type of budget so that you can set up a lab like this, count yourself lucky.

Patch testing process number two includes breaking a mirror of the drive and patching the original drive, ensuring that all is well and then resyncing the mirror. Again this is testing on a real live system with real life data with somewhat of a reasonable quick restore process.

Patch testing process number three is typically used in a small business environment. In this procedure a few key users obtain the patches earlier than others in the office, and they report any issues seen. The people obtaining these patches first should be those individuals in the office that are your "expert users."

Patch testing process number four is referred to as "watching for dead bodies." There are several resources that you can review for issues with patches. In this process someone patches before you and reports any issues. Invariably this process includes someone deploying something as "small" and "innocuous" as a service pack during a lunch hour and expecting it to have no issues. Resources for this process include

• The patch management listserve at www.patchmanagement.org where system administrators report patch issues

• The Community newsgroups for SBS hosted on the Microsoft news server

• The Community listserves for SBS at [e-mail] or [e-mail]

• Finding a local SBS user group in your area to share information (review the ever-increasing SBS user groups listed at http://www.smbnation.com)

This patch testing process relies on not only you obtaining information from these resources but also relating your experiences. Never assume that just because you administrate a number of small business networks that you cannot find unique patch issues that are later seen in larger networks. Time and time again, issues in smaller networks are found sooner and reported earlier than other places. Later in this chapter the resources for troubleshooting patch issues are discussed, but in general remember that any issue with a security patch is a free call to Microsoft Product Support Services.

There is a variation of a patch testing method that many SBS consultants could consider as part of consulting toolkit. That is the process of virtualization, whereby you can use virtual server tools to "snap" an image of the drive and test the patches. Vendors such as Vmware have software that transforms a physical machine to a virtual one. P2V software as it's called, https://www.vmware.com/products/vtools/p2v_features.html, could be used to "snap" an image of a system, patch the image, review log files for proper application, and then patch the real machine. Interactions between hardware and software patches will not be caught with this method but issues with key software may be.

When deciding what tool you will use to patch, you first need to determine the risks in your network. In a typical small business network, the desktops are running with administrative rights such that the user can install anything, the user can browse anywhere, and phishing and browser hijacks attacks can occur often. Thus in a network like this, patching something such as Internet Explorer would be a high priority on the desktops. Conversely, patching Internet Explorer on a server where you are not using the Internet and surfing is not a high priority if the underlying vulnerability has an attack vector of merely surfing. Discuss the end users' computer use with the business owner to best set your patching strategy. Ensure that the firm has an acceptable use policy that forbids such activities as downloading music, downloading unapproved software, or other activities that increase the risk at the firm. Resources for setting up security policies can be found on the SANS.org website at http://www.sans.org/resources/policies/.

In a perfect world, you should be able to read the security bulletins and determine mitigations and workaround techniques listed in each bulletin. You then deploy that mitigation technique and wait for the service pack. In the small business world, it's typically easier to deploy the patch than it is to deploy the recommended mitigation. Consultants need to fully understand the network ports they have open to the outside world to better understand how quickly they need to patch.

In each security bulletin is a section that discusses mitigation options. This also gives you the information about the risk of attack and infection based on the listed rating as deemed by Microsoft, as shown in Figure 22.1. Microsoft's rating system may not always match your rating. For each of your clients, you will build an idea of their risk and risk tolerance based on your interaction with them.

Figure 22.1. Severity rating and vulnerability identifiers in each security bulletinsample from MS 05-039.

Security bulletins have ratings to let you know whether the issue is Critical, Important, Moderate, or Low, as shown in Figure 22.2, (Microsoft Security Response Center Security Bulletin Severity Rating System: http://www.microsoft.com/technet/security/bulletin/rating.mspx).

Figure 22.2. Summary bulletin for August showing severity ratings.

Critical typically means that the items is wormable meaning that little or no end user interaction is needed for this vulnerability to affect you. This can be a risk for you if the port is open on your outside firewall, or, as in the case of Blaster and Slammer, these two worms were brought inside the network on infected VPN client connections and because (at that time) workstations typically were not running host-based firewalls and thus were able to be easily infected behind the firewall and inside the network.

For many companies, a security patch with a rating of Critical is placed on a fast track for patching. However, keep in mind that although a patch may need to be critical for workstations, it may not be critical for servers.

Key words to look for in reading these bulletins for impact of vulnerability are as follows:

• Remote code executionThis means that the vulnerability can come from outside an organization and affect you.

• Elevation of privilegeA user may be able to increase the rights on his or her system and thus into the network with this vulnerability.

• Information disclosurePrivate information about network infrastructure or confidential information may be leaked.

• SpoofingWhat you think you are "talking to" may not be what you are really talking to.

Arguably the remote code and elevation of privilege are the ones to patch the quickest for.

The Open Firm

Many small businesses are in the category of what can be called the open firm. The use of local administrator on the desktop is used extensively in the office, email attachments are needed by all, all employees are allowed to surf without limitations, downloads can be performed, and perhaps employees are even allowed to utilize file swapping sites inside the firm. Most consultants would see this firm as one they would spend time cleaning out malware on a regular basis. For this firm, patching needs to be done quickly and may not be enough to keep the firm clean and secure. In all these sample scenarios, we will assume that antivirus and antispyware are fully installed on the workstations. They may not have data on their network that is regulated, or their network contains highly sensitive data. If they do have on their network sensitive data such as PII or personal identity information, you need to advise them to move to what one would deem category two.

The Moderately Secure Firm

The moderately secure firm still has to maintain full administrator rights on its systems for line of business applications but has begun the process of stripping email attachments. Thus for this firm, an immediate deployment of patches may not be needed, nor warranted. This firm may have data inside its network that is regulated or requires special handling.

The Paranoid Firm

The firm that is paranoid has locked down the workstations so that the end users do not have rights to install software. This firm has properly placed user restrictions such that only those people who need to get into any particular directory or application have rights to that area of the network. For this firm, you will probably gain the most time before you are required to patch.