If your organization is Microsoft-centric, you've probably wondered whether or not Microsoft's patch management (PM) offerings suit your needs. There are several factors to consider when making the decision to go with Microsoft or another vendor's offerings.
Microsoft's primary enterprise patch management application is included in its System Management Server. SMS 2003 includes the Microsoft Baseline Security Analyzer (MBSA), a scanner that examines and reports on operating system configuration and patch levels; Office Update inventory capability; and more sophisticated centralized reporting. Although Microsoft does not require Active Directory (AD) to use SMS, most of the enterprise management functionality, including the most granular patch application mechanisms, are based on AD.
Before deciding whether or not SMS is right for you, let's take a look at the architectural questions that can guide the implementation of a patch management infrastructure.
- How many servers, desktops and laptops do you have to worry about?
- Servers tend to get administrative priority because they're highly visible within the organization. They also serve and protect vital information and business processes. These are good reasons for rapid action, thorough testing and staged deployment.
- Desktops ought to be the most straightforward machines to manage. They stay in one place, and the relative risk of induced downtime (due to forced reboots or application problems caused by the patch) is low.
- Laptops are particularly challenging, because they're not persistently connected to the local network. Also, they're used in less secure environments (like the airport).
Why this matters: PM systems should at a minimum provide the capability to treat each of these categories differently; ideally they'll be capable of highly granular update administration. SMS allows you to base your patch management policies on a variety of criteria based on classifications within Active Directory, so you can fully leverage your existing investment in Microsoft's system management infrastructure.
- What operating systems does your organization support?
Why this matters: Cross-platform support is limited in third-party patch management solutions and non-existent in Microsoft's offerings. SMS supports only Windows operating systems.
- What management tools do you already have in place? If you're already using Active Directory to manage organizational units and group policies, you have a huge head start on deploying centralized patching. Conversely, if you're looking at Microsoft PM systems and don't have AD implemented, your implementation costs are going to be higher than you've probably anticipated; the most useful SMS functionality is only available in an AD environment.
Why this matters: Determining appropriate classification of machines in your organization, constructing machine inventories for the organizational units in your network and determining responsibility for management of those machines can be the most politically sensitive, and therefore time-consuming part of deploying a PM solution. If you're already using AD you've presumably done this. If you're not using AD, you probably want to look at non-SMS-based patch systems, because the implementation will be easier.
- Are your core applications managed centrally? If so, you'll want a patching system that's able to deal with third-party applications as well as operating system updates.
Why this matters: Although the boundary between "operating system" and "applications" is sometimes a bit blurry on Windows machines, they both provide opportunities for an attacker to compromise a machine. You'll want to track machines and enforce updating policies centrally. SMS can maintain software inventories as well as manage OS and application updates for both Microsoft applications as well as those from third parties.
Patch management clients
All patch management clients must confront the issue of administrative privilege requirements. Security best practices suggest that end users should interact with their machines using unprivileged accounts, and administrative access to general purpose machines should be limited to system administrators.
However, many aspects of patch management, including determination of patch levels, application of operating system updates and many application patches, require administrative privileges. Installing PM agent software on client machines can eliminate the need for a local user to have administrative rights and provides other benefits, including the ability to provide accurate, ongoing hardware and software inventories. Of course each operating system requires a specific agent, which may not be feasible in some heterogeneous environments. In those cases, an agentless solution that can be run by a remote user with administrative privileges may be the only answer.
Finally, you don't want the patching process to make your machines more vulnerable, so the patch management client should not install services that listen on the network or require you to enable potentially insecure remote-management services on the client machines (like Remote Registry on Windows or rsh on UNIX boxes).
The verdict
If your organization is already significantly invested in Microsoft enterprise management tools, in particular SMS, then leveraging that infrastructure to include patch management is a pretty good idea. Much of the functionality you'll need, including centralized inventories, integration with Active Directory and granular patch administration, is available in SMS. If you're running a Windows network but have not yet deployed Active Directory, you can still use SMS, but you'll miss out on most of the patch management capabilities you're likely to need. If you're supporting a variety of operating systems in your organization, third-party patch deployment and maintenance tools will probably be easier, more flexible and less expensive to deploy.
About the author
Tina Bird, Ph.D., is a computer security officer at Stanford University and co-moderates the Patch Management mailing list.
