INTERNET, FEBRUARY 3, 2011 (ENTERPRISE DESKTOP) By James Michael Stewart - Hosting Web servers on Windows NT or Windows 2000 systems is a very popular solution. However, it's not always the most secure option.

The Windows operating systems and Internet Information Server (the Web server platform) are vulnerable to many attacks right out of the box and even more when combined with other software, poor configuration and less than vigilant patch management.

Testing new software before and after deployment for security breaches and vulnerabilities is always a good idea. Likewise, staying abreast of the latest secure configuration settings helps maintain the protection your Web site desperately needs.

Maintaining vigilance at becoming aware of, researching and applying new security patches from Microsoft can be a full-time job all its own. There never seems to be a month free from at least one mission-critical security vulnerability discovery that requires a re-configuration or application of a hotfix to prevent ultimate disaster.

Fortunately, Microsoft has teamed up with Shavlik Technologies to bring you a free utility: Microsoft Baseline Security Analyzer. This tool is used to inspect a system locally or remotely for all known security vulnerabilities which are corrected by a hotfix or service pack as well as for secure configurations and settings of the OS and GPOs. If you use the tool's GUI, you get a clean report with clearly marked high, medium and low priority issues. If you are a wiz at scripting, you can use the plain text report generated from the command line functionality of MBSA to automatically detect missing hotfixes and automate their installation.

MBSA can be obtained from:

MBSA can be used to scan Windows NT 4.0 and newer Microsoft OS, IIS 4.0+, SQL 7.0+, Office 2000+ and IE 5.01+.

With regular use, the MBSA can greatly reduce the administrative time required to maintain a system at peak security (at least as far as Microsoft patches and baseline security settings are concerned). This tool should be used as a time saver and not as a replacement for solid security practices and an enforced organizational security policy.

Shavlik Technologies offers a commercial version (EnterpriseInspector) of this tool with many more features at

About the author James Michael Stewart is a researcher and writer for Lanwrights, Inc.

Definition of Microsoft patches

In the Microsoft world, patch management included all of the following types of new code introductions:

•Critical Update: This is not a security update but a fix for an issue in broadly applied software. It is publicly available and has an accompanying knowledge base article.

•Driver Update: This updates software that supports and controls hardware. Driver updates may come from either the software vendor or the hardware vendor.

•Feature Pack: Software package that includes non-critical additions to the base software program. It typically appears between major releases.

•Hotfixes: Patches built to address specific issues. Recipients may not distribute hotfixes outside their organizations without written authorization from Microsoft. Get them FREE by calling Microsoft Product Support Services. Hotfixes do not receive the regular testing process.

•Security Update: This is what we traditionally refer to in patch management circles. There is a severity rating included with each update, as is a security bulletin discussing the issue and a Knowledge Base article describing the patch in detail.

•Service Packs: These are cumulative packages of hotfixes, security updates, critical updates and updates. A service pack undergoes both internal and external testing.

•Software Update: This is any update, update rollup, service pack, feature pack, critical update, security update or hotfix.

•Update: This addresses a non-critical, non-security issue.

•Update Rollup: This is a cumulative package of hotfixes, security updates, critical updates and updates, collectively tested for easy deployment.

•Upgrade: This software updates and upgrades an application to a newer version while keeping the settings and data from the prior program. Each of these categories requires the same process and procedures of testing, acceptance and management sign off. Each must go through a process no matter the size of an organization. We will spend the bulk of our time in this document on security updates.

Footnotes: "Description of the standard terminology that is used to describe Microsoft software updates," (Redmond, WA: Microsoft, Inc., 2004).

What is a patch?

Software refers to the instructions mechanical devices receive to process commands in a certain manner. Typically, developers write software to perform a process in a prescribe fashion. However, as with any process deriving from human intelligence, there can be incorrect assumptions made, and the software might not perform as intended.

As Bruce Schnider and Niels Fergurson state in Practical cryptography:

Most engineers have to contend with problems like storms, heat, and wear and tear. A bridge designer only has to worry about three threats -- water, gravity and wind. All of these factors affect designs, but their effect is predictable to an experienced engineer. (This is) not so in security systems. Our opponents are intelligent, clever, malicious and devious; they'll do things nobody had ever thought of before. They don't play by the rules, and they are completely unpredictable. That is a much harder environment to work in. A software designer has to worry about threats from an unlimited number of vectors. This means that the network administrator must consider such risks from these same threat vectors when analyzing a network's need for patches. Can the threats come from outside the organization or only from inside? What potential attack method might exploit a particular flaw? In a later chapter, we discuss resources for determining these threat vectors.

Software flaws threaten an organization in various ways. The most critical give an attacker full rights to a system. Many of these flaws stem from buffer overflows. Traditionally stack-based buffer overflows have been the largest category of security issues, and are places in the software where more data enters the system than the software is asking for. If the software designer did not anticipate this, the system would "crash." Perpetrators target buffer overflows to dump the processes to ensure that the system remains at an "administrative privilege" level, thereby forcing the system into "handing over the keys to the kingdom." When a patch bulletin indicates that the worse case scenario is that the attacker can "run code of his choice," this is the equivalent to that person logging in as administrator to a system.

Software patches themselves are also threats. After each security bulletin release, even with the rigorous testing done by the vendors on those applications typically broken by previous security updates, issues still occur. Documentation accompanying a security update addresses any known issues likely to develop following release of the update. Remember that issues directly caused by security updates qualify for a no-charge support call. In the United States, call 1-866-PC-SAFETY. To resolve International issues contact a local Microsoft office.

Testing patches, ensuring that they do not adversely affect systems and that they protect systems as intended, as well as applying patches, requires approval from management and may even require approval from critical line of business vendors. We discuss change management processes later and in detail. Nevertheless, you need adequate resources if these testing, ensuring, and applying processes and procedures are to work correctly.

Footnotes: Ferguson, Niels and Bruce Schneier "Practical cryptography," New York: John Wiley & Sons, Inc., 2003; "10-step emergency response plan for security attacks," Redmond, WA: Microsoft Corporation, 2004.

Patch testing on a budget By Brien Posey

More years ago than I really care to think about, I was working as a network administrator for a large, enterprise-class, company. To this very day, one of the things that really sticks out in my mind about that job is the way they handled hardware and software upgrades. The company had a lab that was an exact replica of its server room, complete with matching equipment. This duplicate network existed for the sole purpose of testing upgrades.

The idea was that no upgrade (hardware or software) was ever done to the production network unless it was first done to the test network and monitored for adverse effects. And that was actually pretty smart for the company to set things up that way, because doing so ensured that there were never any surprises on the production network after an upgrade. The thing that really made an impression on me, though, wasn't so much the testing procedure. Rather, it was the amount of money that the company spent on the lab.

The infinite resources method

Every time the company needed a new server, it would buy three of them. One would go into the production network, one would go into the lab and one would be kept in the box and saved in case of a catastrophic hardware failure on the production or test network. In addition to buying duplicate hardware, the company also purchased duplicate software licenses for the test network, although the test network didn't require nearly as many client access licenses.

The point is that the company had a great system for testing patches and upgrades prior to deploying them, but between the cost of duplicate components, duplicate licenses and having to pay the IT staff for the extra hours spent maintaining the lab, the company spent an absolute fortune on testing.

A lot of years have passed since then, and today I work for myself. I have to admit that I would love to have a duplicate network set up for testing purposes, but doing so is, to say the least, a little beyond my budget. That doesn't mean I don't test patches prior to deploying them though. I don't have nearly as elaborate of a setup as my former employer, but I have found a few tricks for testing patches on a much more modest budget.

Reducing hardware costs

The biggest costs related to creating a test lab are hardware and software. Although both are necessities, there are some ways that you can really hold down the costs. Let's talk about the hardware first. One way you can economize on hardware is to purchase PCs instead of servers. If all you do is test the impact of occasional patches, then you don't need things like multiple processors and RAID arrays. You can save an absolute fortune just by using a basic PC with plenty of disk space and memory for testing purposes.

Another cost-saving technique is to use virtual machines. Products such as Microsoft's Virtual Server 2005 and VMware from VMware Inc. allow you to simultaneously run multiple virtual computers on a single physical computer. As you can imagine, running multiple virtual computers simultaneously requires a lot of computing power. Therefore, if you are thinking about using virtual machines, make sure that the physical computer on which you are hosting the virtual machines is as powerful as possible. Specifically, the physical computer will need lots of processing power and as much memory as possible.

Reducing software costs

So what about saving money on software? As I said, you can save money because you won't have to buy as many client access licenses for your test network as you would for the production network. Even so, the software can still be expensive.

There are some ways to cut cost though. If you are only doing a quick test, try using evaluation software in your lab. Microsoft offers 120-day evaluation copies of most of their products for free. Therefore, if you are testing a configuration, patch, upgrade or whatever for less than 120 days, you could just download some evaluation software and not have to worry about the cost.

If you are going to be testing for an extended amount of time, one option is to get an MSDN subscription. A subscription to MSDN Universal costs about $2,000. That sounds like a lot of money but, along with the subscription, you receive multiple licenses for almost all of Microsoft's products. I don't know what Microsoft's official policy is regarding using MSDN software in testing labs, but because MSDN is intended for developers, I'm pretty sure that using MSDN software in a test lab would be allowed by the license agreement.

As you can see, you don't have to have a huge budget to create a test lab. All you really need is a PC or two -- and some imagination.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal Web site at

Chief News Editor: Sol Jose Vanzi

All rights reserved