After you have the policies outlining what your risk tolerance is, and the process outlining how to evaluate and manage security updates, you can start applying technology to the problem. There are many tools to manage patches. We do not go into all of them here; instead, we restrict ourselves to a few Microsoft tools that are either free or free add-ons for another product and a few third-party tools that are representative of a class of tools. These tools generally fall into two categories: those that enable you to evaluate the security state of your systems, and those that are used to patch your systems. This brings us to one of the fundamental truths underlying patch management:
You cannot manage that which you do not know you have!
In order to know which patches to apply, you must know what is in your environment. There are a couple of ways to do that. The most common, by far, is enumeration. In enumeration, you just query the systems to ask them what security updates are applied and what other security settings are configured on them. Enumeration is relatively simple. It simply gives you a lot of data about the system. A patch scanner enumerates patch state with administrative privileges on the target. This process yields very accurate results, but these results may not be relevant to the security posture of the system because this process ignores the access the attacker would have to the system. A vulnerability scanner , by contrast, scans a target without having administrative privileges. A true vulnerability scanner, such as the ISS Internet Scanner (http://www.iss.net/), focuses on actual security issues that an attacker could use to compromise a system remotely. This yields results much more comparable to what an attacker from the network would see. However, the accuracy of those results is not as good as with a patch scanner, and it cannot scan for particular problems, such as vulnerabilities that are only exploitable locally. You also need to be careful running vulnerability scanners against production systems. For example, to test for denial-of-service attacks, many vulnerability scanners take a very simple approach: They fire off the attack, and if the system still responds afterward, it was not vulnerable.
Agent-Based Versus Agent-Less Enumeration
Some tools used for enumeration and other systems management use an agent-based approach, whereas others do not require an agent. Frankly, there is nothing you can do with an agent that you cannot do without one. For simple enumeration, agents are almost never needed. Virtually all enumeration can be done using remote application programming interfaces (API). However, for actually running code on the system, such as would be required to install a patch properly, an agent is needed. An "agent-less" tool can still perform this task, however, by either scheduling the operation on the remote target or by installing an agent on-the-fly and removing it when done.
The advantage of an agent-less approach is that there is much less management complexity, and that you run much less risk of service account dependencies (see Chapter 8, "Security Dependencies"). It is a simpler solution to deploy. However, it requires the person running the management tool console to be an administrator on all the targets.
An agent-based approach may be implemented in such a way as to allow non-administrators to perform the management task. However, in these cases the tool usually implements its own authorization, which is a nontrivial task. An agent-based system is also more difficult to deploy. Finally, it is subject to significant service account dependencies if the same service account is used for the agent on all hosts . For these reasons, we generally prefer agent-less tools.
WARNING: Running vulnerability scanners indiscriminately against your network could be hazardous to your network healthand your career.
Both patch and vulnerability scanners suffer from one common drawback: They are slow and require access to the system you are interested in scanning. That makes them singularly unsuitable for emergency scanning when a network is under attack, when you may not be able to access the systems you are interested in.
WARNING: Running vulnerability scanners without prior approval may result in your getting fired , prosecuted, assaulted, or some combination thereof. Never run a vulnerability scan against a network unless you have prior written permission from someone authorized to grant such permission.
Reporting systems are preferred by some over enumeration because the clients periodically report their configuration to a central server. Reporting systems require an agent, however, meaning that if you are not careful, they will become a security vulnerability in the network (see Chapter 8). They do generally provide more richness in the data than an agent-less system, because the data is usually gathered through custom scripts. At runtime, you would query the central datastore rather than the systems themselves , allowing you to perform offline analysis of system state. It should also go without mentioning that you need to protect the data generated by these systems. Such data could turn into a blueprint for how to attack your network.
Better than both enumeration and reporting is a standardized configuration. The more control you have over the configuration of your systems, the better your intelligence on their patch state and needs will be. Keep in mind, however, that if you make untrusted individuals, such as your average user , local administrators on these managed systems, they become unmanaged systems, and you can no longer count on the system being in the standard configuration.
Having reviewed this introduction to managing the state of your systems, let us take a look at the tools.
The Microsoft Baseline Security Analyzer (MBSA) is Microsoft's free solution for scanning systems for missing security updates and other potential vulnerabilities. It is available at http://www.microsoft.com/mbsa.
MBSA is a patch scanner, not a vulnerability scanner. Therefore, it requires administrative privileges as well as particular services to be running on the target you are scanning. For example, MBSA requires the Server and Remote Registry services running on the target you are scanning.
By the time you read this, MBSA will be in version 2.0. That version uses the same scanning engine as Windows Software Update Services (WSUS) which should also be released by the time you read this. It will also check additional products and generate more accurate results for the products it can check.
MBSA version 1.x uses an engine developed by Shavlik, Inc. (http://www.shavlik.com). Although MBSA does not actually apply patches, Shavlik's product using the same scanning engine, HFNetChk Pro, does. However, HFNetChk Pro is relatively expensive, at least compared with MBSA, which is free.
For end users, the best security update is one they do not have to think about. The Automatic Update (AU) service of Windows Update (WU) was designed for that environment. Although AU can be used to notify users that new Windows security updates are available, it can also be configured to automatically download and install those updates. This latter mode is the preferred solution because it also works when no administrators are logged on. Keep in mind, however, that if a security update requires a reboot, AU will automatically reboot the system. This quality makes AU singularly unsuitable for servers.
Starting with Windows XP Service Pack 2, AU is actually on by default. During the first boot after installing the OS (or installing the service pack), the machine asks whether to enable AU. The default selection is to download all patches immediately and notify users that they need to be installed.
For really small networks, your best bet is probably to just configure AU on all the clients and then manually update the server(s). However, what if you have custom or rare applications that you need to test the updates against before you roll them out to the entire network? Windows Software Update Services is for you. WSUS is a free download from Microsoft that basically gives you your own WU server. The difference is that whereas WU presents your users with all the available security updates, WSUS only gives them the ones that you have blessed. AU normally scans a system against the security updates published on WU. However, if you have a WSUS server, you can configure AU to scan against it instead, ensuring that all your clients have all the OS updates you want and none other.
Note that although WSUS is primarily designed as a small- to mid-market solution, it can be successfully used in very large environments. A tiered deployment of WSUS servers is also possible to reduce network load, cater to specific departmental needs, and so on. For complete information, refer to the Microsoft Solution for Patch Management (http://go.microsoft.com/fwlink/?LinkId=16284).
At the time of this writing, WSUS has not yet been released, which means we cannot give you a link to it. Also note that this product has also changed names several times during the development cycle. It is possible that by the time it is released it uses a different name . By the time you read this, it should be out, and you should be able to find it at http://www.microsoft.com/security.
If you already have an enterprise management system (EMS) in place, such as Microsoft Systems Management Server (SMS), Tivoli, CA Unicenter, HP OpenView, etc., use that to distribute your security updates for you. If your EMS can deploy software, it should also be capable of patching it. Evaluate the EMS solution carefully , however. These systems are extremely powerfulmeaning they are also notoriously difficult to deploy. Unless you are running a large number of systems500 is the number you usually seean EMS may be too complicated to use. You also should look at how the system connects to the clients. Be wary of introducing service account dependencies (see Chapter 8) through your EMS.
Microsoft's EMS for client management, Systems Management Server (SMS), has a free feature pack (http://www.microsoft.com/SMServer/downloads/20/featurepacks/suspack/) that gives you the same flexibility with SMS that you have with SUS, with the added power of an industrial-strength EMS. It actually does not use SUS, however; it uses MBSA as the scanning engine. Consequently, you will get slightly different results between SUS and SMS. This will be resolved by WSUS.
Obviously, SMS still costs money, but after you have that infrastructure, the feature pack makes using it to distribute security updates much easier.
Generally speaking, if you have no other management solution in place, and you have fewer than about 500 clients to update, SUS/WSUS and Auto Update is probably your best solution. If you have more than 500 clients, consider an enterprise management solution, such as SMS, because this will do more things for you than just updates. If you already have an EMS, investigate whether you can use it to apply updates. If you have a very small network, with no centralized management need, consider using Auto Update configured to query Windows Update, which is the default.
One large advantage of an EMS is that they are basically just giant scripting engines. They can take programs from one place and run them elsewhere. In other words, they are infinitely flexible, and if you simply get good at using them, you should be able to install just about any patch using an EMS. The canned solutions, such as SUS, Auto Update, and WSUS (when it comes out), are not as flexible, but are much easier to use in turn.
You can find more information about how to pick a patch management solution at the Microsoft Web site (http://www.microsoft.com/windowsserversystem/sus/suschoosing.mspx). For more technical and in-depth guidance, refer to the Microsoft Solution for Patch Management (http://go.microsoft.com/fwlink/?LinkId=16284).
By the time you read this, Microsoft should have published the new Microsoft Update Web site, which will supply patches for many Microsoft applications, in addition to the operating system. Since it has not been released yet, we do not know what the link will be, but there will be a redirect to it from Windows Update. WSUS is essentially a local version of the same Web site. For applications that cannot be patched with Microsoft Update, you need to look elsewhere for patches. All Microsoft security updates are accompanied by a security bulletin, which you can find at http://www.microsoft.com/technet/security/current.aspx. For third-party applications, look for the support site on their respective Web sites.