Tips for immediate patch management after a fresh install
Over the last several years, patch management has become a huge issue for Windows machines. Microsoft constantly releases patches not only for the operating system, but also for server applications such as Exchange Server and SQL Server. Keeping up with patches is one thing, but you also need to consider patch management any time that you deploy a new server. Remember: In a way, a server is most vulnerable immediately after it is brought online. This is because no patches have been installed to counteract known security or stability issues. Here's everything that you need to know about installing patches on new servers.
Patches vs. service packs
Before I get started, I want to take a moment and discuss the differences between patches and service packs. During the years that I have been involved in IT, I have noticed a strange phenomenon regarding patches and service packs. It seems that often administrators are extremely anxious to apply patches the instant they come out. On the other hand, when a new service pack is released, those same administrators will often wait weeks, if not months, to apply it.
In a way, I can understand the rationale behind this. A patch is a small fix that’s usually designed to fix some critical security hole or system stability issue. A service pack, on the other hand, tends to replace the majority of the operating system’s files. It’s only natural to be distrustful of a service pack that is going to overwrite the majority of the system files that your operating system uses. People usually want to wait a little while and see if anyone else has problems with the service pack prior to applying the fix themselves.
The ironic part is that this approach is exactly opposite of what Microsoft recommends. According to a Microsoft TechNet article, the biggest difference between patches and service packs is that service packs are planned and patches are not. According to the article, before Microsoft ever releases a new service pack, they test it for weeks against hundreds, if not thousands of third party applications. The article states that Microsoft service packs meet the same quality standards as the operating system itself (okay, stop laughing).
On the other hand, patches are released on an as-needed basis. For example, if some big security hole were discovered tomorrow, Microsoft would very quickly produce and release a patch for the problem. The patch would have undergone a minimal amount of testing, but remember that Microsoft’s goal is to make the patch available quickly, not to test the patch for every possible situation. Therefore, there have been a lot of cases where patches have been unstable.
When a service pack is released, all of the bugs and security problems that have been discovered and patched since the last service pack are included in the new service pack. The difference is that the service packs are thoroughly tested. Therefore, although a new service pack might fix the same bug as a previously released patch, the service pack might use very different code to fix that bug from what was originally released in the patch.
Patching a new server
As I explained earlier, when a new server is initially brought online, it is at its most vulnerable because it contains no patches. Therefore, I recommend installing the most recent service pack immediately after installing the operating system onto the new server.
Once the service pack is installed, I recommend installing your antivirus software next. The third step that I recommend taking is to update your virus definitions. Next, install any server-level applications such as Microsoft Exchange or SQL Server. Finally, install the latest service packs that exist for your server applications.
Following those steps should make the server relatively secure. Keep in mind, though, that Microsoft releases patches for operating systems and for applications on a regular basis. Therefore, you will want to apply the patches that have been released since the most recent service pack. Because patches receive minimal testing, you will have to make a judgment call; you can either install every available patch or you can install only those patches that fix severe security vulnerabilities or that address issues that directly affect you.
There are good arguments for both sides of this issue. Some people believe that if a vulnerability exists then it should be patched. Period. On the other hand, other people believe that since patches are created on the fly and are largely untested, it’s better to preserve system stability by applying only the patches that you really need. In my opinion, the correct approach depends on your organization. Anyone in a high-security environment, such as the military or a financial institution, probably wants to apply every patch the instant that it becomes available. The rest of us are probably OK picking and choosing though.
What patches do I need?
One question that I tend to get asked a lot is that if Microsoft is constantly releasing all of these patches, how can you figure out which patches you really need. More importantly, where do you get these patches. About a year or two ago, Microsoft released a tool to make patch management much easier. The tool is called the Microsoft Baseline Security Analyzer (MBSA).
The Microsoft Baseline Security Analyzer
The MBSA is a utility that analyzes your server to see which security patches have been applied. It then compares the list of detected patches against a list of available patches that’s contained in an online database. Because the database exists on the Internet, Microsoft can keep it up-to-date. Therefore, you can periodically run the MBSA and see if there are any critical updates that you might be missing.
The MBSA doesn’t come with Windows, but you can get it by downloading it from Microsoft's Web site. The download consists of a 3774 KB MSI file. This means that you can install the utility on Windows 2000, Windows XP, or Windows Server 2003. The installation procedure consists of running a very simple wizard. You can install the utility onto any Windows system, as long as that system has a network link to the computers that you want to test the security for. The utility requires about 3 MB of disk space.
When the installation completes, you will see the main MBSA screen, shown in Figure A. As you can see, the MBSA’s user interface allows you to scan a single computer, multiple computers, or to view reports created during previous scans.
At this point, you’ll see the screen that’s shown in Figure B. This screen allows you to set the various scanning options. First, you must select which computers that you want to scan. You may either enter the name of the domain that you want to scan, or you can enter a range of IP addresses. Using an IP address range tends to be more effective if you have multiple domains that you want to scan. Just keep in mind that the account that you’re logged in with must have administrative privileges on the machine that you’re scanning. Therefore, simultaneous scans of multiple domains will fail unless the account that you’re using has administrative privileges in all domains.
Regardless of which method you use, you need to know that the utility won’t scan all of the computers within the domain or IP address range. The utility will scan only machines that are running Windows NT, Windows 2000 (Professional, Server, and Advanced Server), Windows XP (Professional and Home Edition) and Windows Server 2003.
Beneath the IP address range field is the Security Report Name field. By default, the security report name is set to %domain%- %computername% (%date%). In this report name, the %domain%, %computername%, and %date% variables would be replaced by the actual domain and computer name and the date. Even if you’re testing by IP address, the report name format is OK to use, because rather than generating one large report, the utility generates a separate report for each computer that it analyses.
At the bottom of the window are the various scanning options. As you can see in the figure, several check boxes allow you to control whether or not things like Windows vulnerabilities and weak passwords are tested. Select the desired scanning options and click the Start Scan button
When the scanning completes, you’ll see a list of the systems that were either completely or partially scanned. As you can see in the Assessment column in Figure C, the utility tells you instantly what machines need the most attention. In this particular case, the machine Bart, which was diagnosed as a severe risk, is a Windows 2000 Server running Service Pack 3 but no other patches.
Now, let’s look at an actual report of the machine that was determined to be a high risk. You can do so by simply clicking on the computer name. The report is much too long to fit onto a single screen. However, in Figure D you can see the top portion of the report. Notice that each issue is scored with a red X (danger), a yellow X (caution), or a green check mark (good). Beneath each issue are links for what was scanned in the particular test, the result details, and how to correct the issue. For example, in Figure D you can see that the report indicates that 29 Windows security updates are missing from my test machine.
Of course, just knowing that there are 29 updates missing isn’t enough; you need to know which updates so you can do something about it. If you click on the Result Details link, you will see a screen similar to the one in Figure E. This screen contains a description of the problem and the reason why it was detected (it's usually a matter of the existing file version vs. the correct file version of an operating system file). There is also a link to the Microsoft Knowledgebase article that describes the problem in more detail. Most of the time these Knowledge Base articles also have links for downloading the missing security patches.
Hopefully by now you have decided which service packs and patches you want to use and have applied them. By now your antivirus software should also be installed and up-to-date. The next step is to make a backup or a ghosted image of the server.
Ghosting
No one plans on reformatting a server after a fresh install, but it does happen. Over the years, I have seen a number of situations in which shortly after a server was brought online it had to be taken right back offline because of some critical flaw. In some of these cases a hardware failure was to blame. Perhaps the hard disk failed or bad memory was causing corrupt data to be written to the hard disk. In other cases I have seen people have to reformat a server after a severe virus infection or after a security breach has occurred. My point is that, although you never plan on reformatting a brand new server and starting from scratch, there are situations where it might be necessary.
Because of this, I recommend creating a ghosted image of the server’s partitions once all of the patches and server applications are in place. There are two main reasons for doing this. The first reason is that it is a time-saver. Suppose for a moment that your new server had a critical failure tomorrow. It would be much faster to restore a couple of partitions from ghosted images than to reinstall the operating system, patches, and applications completely from scratch.
The other reason for creating a ghosted image is a little more important than just saving time. Remember, between the time that you bring the new server online and the time that you install the various patches, you are vulnerable to whatever security issues those patches might address. It is unlikely that a hacker or a Trojan would compromise your server in this short period of time, but it has been known to happen—especially if you accidentally forget to apply a critical patch.
Ghosting your server guarantees that if you have to restore the image, then the restored image will already contain all of the patches that had been applied up to the time that the ghosted image was created. One might argue that if this image needed to be restored a week after it had been created, then the image would be invalid because several new patches could have come out in the course of that week.
While it is true that more patches could have come out during the time between when you create an image and when you restore the image, I would still recommend using the ghosted image. That’s because the ghosted image will already contain a number of security patches. You can simply apply the new ones rather than worry about reapplying all security patches. After all, having some security patches in place is better than having no patches.
TechRepublic originally published this article on 8 December 2003.