In-Depth

Manage Patches and Updates

Round out your new or updated security strategy by establishing a process to evaluate, manage, and deploy patches in your network. Here are some guidelines and tool recommendations.

There are two final keywords crucial to systems and network security: proactive and responsibility. The first deals with the management of software patches and updates—something everyone must learn to live with regardless of what technologies you use. The second deals with who you are as an IT professional. Both help round out your new or updated security strategy (see the sidebar, "10 Security Keywords").

Stay Proactive
Proactive systems management means verifying and installing patches as soon as you can. Ideally, this is as soon as they are available, but this is rarely the case. Too many administrators still have the lingering feeling they should wait and see before they do something with an update. While this is valid in some extreme cases, it is also the cause of many of the attacks we face today. Recently, most of the attacks we've suffered were from known vulnerabilities for which the manufacturers provided corrections. The problem is that everyone has not applied those corrections. When you consider that attacks on known vulnerabilities occur within days of the vulnerability being announced and fixed, you realize that the opportunity window administrators have to view and evaluate a patch is quickly dwindling to nothing. That's why it is important to put in place a specific process for patch management. If you haven't implemented one yet, then you should as soon as possible. If your management does not understand the value of patching, then convince them. Numerous documents outline the return on investment from any patching strategy. All you need is to be hit once to quickly see the value of patches.

Microsoft recommends using a four-step process for patch management (see Figure 1). The first step is preparing your infrastructure. This means ensuring that your patch management technology works and works right the first time. You also need to have a baseline inventory of all of the machines in your network. This means knowing which patches and hot fixes have already been applied to each system. The best tool for this in Windows is the Microsoft Baseline Security Analyzer. It covers the entire network and analyzes any Microsoft product. While you're preparing this inventory, you can also set up your patch management team and make sure members are trained for the job at hand. It is also a good idea to review your infrastructure to make sure you're aware of the types of vulnerabilities and threats you might face (remember the process keyword).

Once this is done, you can move on to the identification phase. This is where you first identify available patches and then determine if they are required in your environment. It is a good idea to use a rating system for patches here because not all patches are created equal. A four-level rating system is sufficient. You should deploy critical patches as soon as possible; the emergency response team should treat them. You should deploy important patches through your normal infrastructure but treat them as a priority release. You should roll up moderate patches into your normal deployment schedules, and include low-level patches in basic installation images whenever you update them. If you deem that a patch is required, you should forward a patch deployment request to your patch management team.

In your patch evaluation, you should determine the impact the patch will have on your systems. There are some great tools that can help you do this. For example, InstallShield's Patch Impact Manager is designed to help you determine the precise impact a patch will have on your network. If you don't have a commercial evaluation tool, you should at the least have a testing strategy in place. Deploy the patch to these test systems and determine if any negative impact on your software exists. Once this is completed, you can proceed to set a release timeframe for the patch and pass it on to the patch deployment team.

Before you deploy the patch, you should communicate with the affected community of users. Make sure you are ready for patch rollback in the event of untoward system behavior. This shouldn't happen if you tested the patch properly, but just in case, it pays to be prepared. Once you roll out the patch, review the entire patch management process to determine if you can make improvements.

If you use one of the Microsoft solutions for patch management, especially the free version—Microsoft Software Update Services (SUS)—you've probably quickly realized its limitations. SUS only works for security patches and only for operating systems. Microsoft is readying a new patch management toolkit, Windows Update Services (WUS), which should be out by early next year. Windows Update Services (see Figure 2) will continue to support the update and application of patches to operating systems, but will include applications as well. In its first iteration, WUS will help you manage various versions of Windows, Office, Exchange, SQL Server, and the Microsoft SQL Server Desktop Edition (MSDE). In the future, support for other Microsoft products will be added to WUS without changing versions of the product. It will simply be included in your deployed WUS interface as Microsoft makes them available. You'll just need to subscribe to these new product updates as they come online.

WUS will also support the deployment of non-critical patches and upgrades, as well as driver updates, something sorely lacking in the current edition of SUS. It should also scale more easily and support more complex distribution architectures, making it a more solid enterprise-enabled application. To make all of this work, Microsoft is revamping the Windows Update site to include patches and updates from all of its products. Users that want to update their systems by using the Web site alone will be pleased to see it identify all the Microsoft products installed on their systems and offer applicable updates for each of them.

This doesn't mean you should wait for the release of WUS before putting your patch management strategy in place. No, in fact, if you don't have a tool in practice today, you should proceed with one immediately.

Realize Your Responsibility
The last keyword is responsibility. As an IT professional, it is part of your responsibility to make the IT world as a whole a safer and more secure place. Your responsibility does not stop with your workplace. IT is a profession, just like nursing and medicine. Your job and your responsibilities do not stop when you leave the office. Just as doctors or nurses are professionals always willing to help in emergencies, you should also treat your profession the same way. This means it is your responsibility to educate your friends and family to help make the Internet more secure.

You might recommend acquiring and installing Windows XP to your family and friends. You might tell them to install Service Pack 2 for XP when it becomes available. You might get them to use Outlook 2003 with its integrated anti-spam and attachment blocking features. It's true that this will most definitely put more money in Microsoft's pocket, but if your entourage has chosen to use Windows, then they should use a secure version of Windows. Windows XP will be secure with Service Pack 2.

It's not easy and often annoying trying to fix some arcane problem on a family member's unmanaged system. But think about it. If our industry as a whole gets more serious about security, then we should have fewer threats to deal with on an ongoing basis. After all, that's every security expert's ultimate goal, isn't it?

About the Author

Danielle Ruest and Nelson Ruest, both Microsoft MVPs, are IT professionals focused on technologies futures. They are authors of multiple books, including "Microsoft Windows Server 2008: The Complete Reference" (McGraw-Hill Osborne Media, 2008), which focuses on building virtual workloads with Microsoft's new OS.

Featured

comments powered by Disqus

Subscribe on YouTube