Maintaining Security by Implementing, Managing, and Troubleshooting Service Packs and Security Updates
This chapter is from the book
This chapter is from the book
This chapter is from the book
Terms you'll need to understand:
-
Codec
-
Certification Authority (CA)
-
Trusted CA
-
Systems Management Server (SMS)
-
hfnetchk
-
qchain
-
Windows Update
-
Windows XP Dynamic Update
-
Certificate revocation list (CRL)
-
Secure Sockets Layer (SSL)
-
Microsoft Baseline Security Analyzer (MBSA)
-
Software Update Services (SUS)
-
Remote Installation Services (RIS)
-
Slipstream
Concepts and techniques you'll need to master:
-
Understanding the need for software updates, including the problems that are caused by updating or not updating
-
Using the Microsoft tools (hfnetchk, SUS, and MBSA) to determine patching status
-
Selecting and using Microsoft tools to update servers and clients
-
Knowing how to install updated systems (by using slipstreaming and RIS, for example)
-
Troubleshooting and resolving problems with attempted updates such as application incompatibilities, permissions problems, and update failure
Not long ago, system administrators had a choice about whether to update their systems. In many cases, they were safe in assuming that internal systems were not at risk. In many cases it was more beneficial to not update than to update because updates were plagued with unsolvable problems. "If it's not broken, don't fix it" was the rule.
Today, this is just not the case. Emerging statistics show that the majority of successful attacks are successful because they take advantage of a known vulnerability—for which there is a patch. Nimda, Code Red, and many versions of Linux SSL took advantage of these types of weaknesses.
The question today is not should you patch, but how are you going to patch, and how fast are you going to do it? Fortunately, many Microsoft tools can assist in solving the logistics of patching. To conquer this topic, you must know the tools (hfnetchk, Windows Update, SUS, and the SMS feature pack) and methods necessary to keep systems patched, and you must know how to troubleshoot the problems the patches may cause, and you need to understand the reasons tools may not work correctly.
Getting Your Patching Program Started
There are actually four processes involved in updating systems:
Determining when updates are available
Evaluating whether the updates are necessary
Testing updates for your environment
Updating systems
The first step in managing service packs and hotfixes is to know when they are needed. Whereas service packs fix multiple issues and are infrequently published, hotfixes are published as the need arises to patch existing vulnerabilities. To find out when fixes are necessary, you should subscribe to a hotfix notification service. For example, you can subscribe to Microsoft's Hotfix and Security Bulletin Service at http://www.microsoft.com/technet/security/current.asp.
When a notification is received, it should be evaluated and then, if approved, applied using some mechanism. Evaluation may consist of two phases—determining whether the patch is necessary and determining whether the patch is safe. You need to know whether the patch will cause problems. Evaluation methods may include the following:
Do no evaluation—You can blindly accept every proffered patch.
Wait for a while to see if others have problems with the patch—This approach is often adopted by small businesses that cannot afford the testing time and systems needed for every hotfix.
Read Microsoft discussions and other resources to determine whether a system should be patched—Some choices are obvious. For example, if the patch is for Microsoft SQL Server and a system is not running this service, the patch should not be applied. Other choices are not as obvious, and you must determine if the patch is necessary. For example, you need to consider what the patch does and whether its activities will prevent critical software from running or critical operations from occurring.
Select a time for patching—It's a good idea to apply patches during idle time, especially if a reboot is necessary. You should evaluate whether there is a situation in which a patch is so critical that you must suspend activity and install the patch regardless of the consequences. Only the administrators and users of the systems can determine this, although management may need to be involved when downtime affects revenue-generating systems such as e-commerce servers.
After you decide that the patch is necessary, you should thoroughly and exhaustively test it to ensure noninterference with existing operations or other hardware/software conflicts. You should install hotfixes on test systems whose configuration mirrors that of the production machines. You can then test the systems for functionality.
After the patch has been tested, you must choose the appropriate way to update systems.