Evaluating Updates

After you learn of a security update, you need to evaluate the update to determine which computers at your organization, if any, should have the update applied. Read the information that accompanies the security bulletin and refer to the associated Knowledge Base article after it is released.

Next, look at the various parts of your environment to determine whether the vulnerability affects the computers on your network. You might not be using the software that is being updated, or you might be protected from the vulnerability by other means, such as a firewall. For example, if Microsoft releases a security update for Microsoft SQL Server and your company doesn't use SQL Server (and it's not a requirement for other installed applications), you don't need to act. If Microsoft releases a security update for the Server service but you have blocked the vulnerable ports by using Windows Firewall, you don't necessarily need to apply the update (although applying the update will provide an important additional layer of protection). As an alternative, you might decide that applying the update is not the best countermeasure for a security vulnerability. Instead, you might choose to add a firewall or adjust firewall filtering rules to limit the vulnerability's exposure.

Determining whether an update should be applied is not as straightforward as you might think. Microsoft updates are free downloads, but applying an update does have a cost: You will need to dedicate time to testing, packaging, and deploying the update. In larger organizations, applying a software update to a server requires that many hours be dedicated to justifying the update and scheduling the associated downtime with the groups who use the server.

Any type of update also carries the risk of something going wrong when the update is applied. In fact, any time you restart a computer, there is a small risk that the computer won't start up successfully. There's also the very real risk that the update will interfere with existing applications. This risk, fortunately, can be offset by extensively testing the update before applying it. Deciding not to apply a security update also has a cost: an increased risk of a security vulnerability being exploited.

Besides testing, you can offset the risk that an update will cause problems by having a plan to roll back the update. When evaluating an update, determine whether the release can be easily uninstalled if it causes a problem that isn't identified during testing. Functionality for uninstalling updates can vary from fully automated uninstall support, to manual uninstall procedures, to no uninstall. If an update cannot be uninstalled, your only option might be to restore the computer from a recent backup. Regardless of the uninstall method required for an update, ensure that you have a defined rollback plan in case the deployment doesn't match the success encountered in the test environment.

To be prepared for the worst, verify that you have recent backups of all computers that will be updated and that you are prepared to restore those systems if the update cannot be removed successfully. It's not likely that an update will cause your systems to fail completely and require them to be restored from backup, but it is a circumstance that you must be prepared to handle.

Choosing whether to apply an update is such a complicated, yet critical, decision that larger organizations should create a security committee that collectively determines which updates should be applied. The committee should consist of employees who are familiar with the update requirements of each different type of computer on your network. For example, if you have separate organizations that manage desktop and client computers, both organizations should have a representative on the committee. If separate individuals manage each of the Web, messaging, and infrastructure servers on your network, each person should have input into whether a particular update is applied. Ask members from your database teams, networking groups, and internal audit teams to play an active role-their experience and expertise can be an asset in determining risk. Depending on your needs, the committee can discuss each update as it is released, or it can meet on a weekly or biweekly basis.

If the committee determines that an update needs to be deployed, you then need to determine the urgency. In the event of an active attack, you must make every effort to apply the update immediately before your system is infected. If the attack is severe enough, it might even warrant removing vulnerable computers from the network until the update can be applied.