Patch Them

Patch Them!

Step one in securing anything is patching it. If you do not patch, you will get hacked; it is that simple. Unfortunately, patching users is nontrivial, so we largely have to resort to patching the applications they use. Applications, however, are not easy to patch either. First, you have to find out that they need patches. Doing so is not as straightforward as it should be either. Start out by taking an inventory of what is installed on your systems. If you have an enterprise management system, or better yet, a standard desktop environment, you are far ahead of the game at this point. Use those to generate a list of which applications you have and where. If you have some kind of centralized application distribution system, use it to generate a database of what is installed where. If you do not have any of these technologies, use some creative scripting to discover what people are using. When you install applications that are recognized by the operating system, they will create a Registry key underneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Querying that key will give you some idea of what is available. Each uninstallable component listed there has a value called DisplayName listing the name of the application. There are usually many more items listed in that key than what shows up in Add/Remove Programs. This is normal because not everything should show up there. Some of these items are device drivers, others are merely components of a larger piece of software (or suite), and so on.

Patch Scanning

In Chapter 2, "Anatomy of a Hack: The Rise and Fall of Your Network," we spent some time discussing patch scanning. Hopefully by the time you read this, Microsoft has released version 2.0 of MBSA, which includes much better patch scanning for user applications. However, the real killer app will be version 3.0; as of this writing, however, it does not even have a product name yet. Keep an eye on the MBSA Web site (http://www.microsoft.com/mbsa) for these new tools.

There are also third-party tools that do a reasonably good job of patch scanning. One of the most popular is Shavlik's HFNetChk, which uses the same engine as MBSA version 1.x.


Listing applications that can be uninstalled is not sufficient, however. Some older applications do not show up there, and ActiveX controls, which are basically applications that also need patched, do not get listed there either in general. ActiveX controls can be seen in the Manage Add-ons dialog in Internet Explorer (IE) starting with Windows XP Service Pack 2. Figure 13-1 shows this dialog.

Figure 13-1. The Manage Add-ons dialog in Internet Explorer 6.0 Service Pack 2.

The Manage Add-ons dialog is fine, but there is one problem with it: what good does a GUI do us? By the time we run around to every single machine to enumerate all the add-ons, we have probably been attacked already. To programmatically determine which add-ons are in use by IE requires evaluating each user's profile on each system. The class ID (CLSID) for each add-on is listed in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext. You would then have to resolve each of these key names under HKEY_CLASSES_ROOT\CLSID, where each CLSID has a key with information on the actual control involved. Typically, the default value of the key has a string that explains the control. If you have an enterprise management system, such as SMS, this may be feasible ; without that, however, getting this information from every machine is almost not worth the effort. You may just want to consider the Group Policy option of only allowing authorized ActiveX controls to execute instead.

Let's assume that you now have a list of all the applications on your network. The next step is to locate security patches for each of them. If they are Microsoft applications, this is fairly easy. Most security patches for Microsoft applications are published in a security bulletin. In Chapter 2, we talked more about how to find those.

For other applications, it is not as easy. Many vendors, particularly those targeting the various UNIX variants, publish security patch notification on the BugTraq mailing list (http://www.securityfocus.com). Secunia (http://www.secunia.com) also has a relatively good list of security flaws, but flaws do not necessarily correlate with security patches, and in some cases Secunia's database is not completely up-to-date. Mitre maintains the Common Vulnerabilities and Exposures (http://cve.mitre.org) database, which also lists security patches for a number of products; but again, it is not complete. There are also various mailings from organizations such as SANS and CERT that list security patches, but they tend to be both incomplete and focus on flaws more than patches. Then there is each vendor's support site, which usually, but not always, will list security patch information. In some cases, these listings are provided only to registered users or users who register for notifications. In the end, you need to put together a process for finding patches for each of the products you are using. Use any or all of these resources as well as any others that you find helpful. There is no easy solution here, so feel free to innovate and come up with something that works for you. Also feel free to put pressure on vendors to put together a program to notify you of patches. If you spend money on their products, it is only right that they help you keep those products safe.

After you have the patches, how do you get them installed? Chapter 3, "Patch Your Systems," goes into some length about this, and we do not repeat that discussion here, but ultimately, you have to build a process around patching, as well as a process around mitigation.



Protect Your Windows Network From Perimeter to Data
Protect Your Windows Network: From Perimeter to Data
ISBN: 0321336437
EAN: 2147483647
Year: 2006
Pages: 219

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net