Windows Server 2003 : Deploying Security Configurations - Creating a Testing and Deployment Plan

Creating a Testing Environment

For the initial testing phase of deploying a configuration, you want to implement your security parameter settings in a lab environment. The lab network environment should closely resemble the actual environment in which you will deploy your configurations, but should be isolated from your live production environment. The testing process consists of the following five basic steps:

• Creating a test plan

• Creating test cases

• Building a lab

• Conducting the tests

• Evaluating the results

These steps are discussed in the following sections.

Creating a Test Plan

For the first phase of the testing process, you should create a test plan that specifies what you want to accomplish and how the testing process will proceed. The specific goals for your test plan will vary depending on the nature of your organization and how it uses the network, but some of the most typical testing objectives are as follows:

• Hardware compatibility testing

• Application and operating system compatibility testing

• Hardware and software product evaluation

• Performance baseline determination

• Security testing

• Documentation of installation and configuration procedures

• Documentation of administrative procedures

In addition to general testing objectives such as these, you will probably also have goals that are specific to your organization and its security requirements. To achieve your testing objectives, your plan should specify elements such as the following:

• The structure of the test lab

• A list of all hardware, software, and personnel required for the testing process

• What tools and techniques the testers will use

• The methodology and duration for each phase of the testing

• How the testers will document the testing process and the results

Creating Test Cases

To test specific elements of your network installation, you create test cases. A test case is a procedure that fully tests a particular feature or setting. For example, if you have decided to use a particular set of account policy values to control your users’ passwords, the test case for those policies might consist of implementing them on the lab network and then having people log on and off those computers, deliberately duplicating common user logon errors and attempting to guess passwords using the brute force method. The results for that test case might lead you to use the account policy parameters as is or it might lead you to modify them to enhance or reduce the security they provide.

As documented in the test plan, each test case should include the following information:

• The purpose of the test case

• The hardware and software required to perform the test

• The installation and configuration procedures required before the test can proceed

• The procedure for performing the test

Creating detailed and complete test cases is one of the most critical elements of the test plan. For the example given, it might be tempting to create a brief test case that specifies what account policy settings to use and, in general terms, how the testing should proceed. However, this practice introduces an element of chance that can jeopardize the validity of the test. If you create detailed, step-by-step testing procedures for your test cases, not only can you repeat the test using the exact same methodology, it is also possible for different people to perform the same test in the same way.

Building a Lab

The nature of the testing lab itself depends on a variety of factors, including the size and nature of the organization, the amount of testing to be done, the complexity of the network, and the duration of the testing process. Security configuration testing is not the only part of designing and constructing a network in which a lab environment is useful. You can use a lab for any or all of the following purposes:

• Developing the overall design of the network

• Evaluating hardware and software products

• Planning performance and capacity

• Determining bandwidth requirements

• Establishing administrative policies

• Training users and support staff

• Documenting deployment and administration procedures

For a large organization, a permanent lab installation can be a worthwhile investment that enables network administrators to continually evaluate upgrades and new technologies, in preparation for their deployment on the live network. For organizations that are not quite so large, or that have limited budgets, the lab can be an ad hoc arrangement that consists of computers and other equipment that administrators will later deploy in a production environment.

The object of creating a lab is to duplicate the organization’s live computing environment as closely as possible, within practical limits. For some organizations, a simple isolated local area network (LAN), consisting of a handful of computers connected to a hub, is sufficient. For larger organizations, a more elaborate lab setup might be necessary. For example, if your network consists of offices at remote locations connected by wide area network (WAN) links, you might want to integrate the WAN links into your lab environment as well.

Conducting the Tests

The ease or difficulty of the actual testing process depends largely on the amount of detail in your test plan. If you create highly specific test cases with step-by-step instructions for the testing procedure, virtually anyone can do the testing, as many times as needed. If your test cases are more general, you might have to count on the insight of the particular individuals who perform the tests to determine the results.

The first step of the testing process is to configure the computers and other components required for the test according to the specifications in your test case. Once you have created the environment you need, you can begin the actual testing.

When testing security configurations, your two main objectives are to determine whether the parameter settings you have chosen provide the security you need and whether the settings interfere with normal operation of the network. Your test cases should include procedures that duplicate all the network’s standard functions with the security parameters in place. For example, you should have testers run all the applications and access all the network shares your users need, to ensure that the security parameters don’t inhibit access to these resources. Then, the testers should attempt to bypass the security measures you have implemented, to see if they are secure enough, and duplicate typical user errors, such as incorrect logon passwords, to document the system’s reaction.

Evaluating the Results

One of the most important elements of the testing process is careful documentation of every action and its results. Once the testing process is finished, you should have a complete record of everything that occurred, to be used in evaluation. With detailed test cases and well-documented test results, it is even possible for individuals not involved in making the decisions to do the testing, leaving the evaluation to the organization’s policy makers.

As a result of the testing, you might decide that your security configuration parameters are acceptable as is, or you might have to modify them, in which case you should repeat the tests using the new settings. It is when you have to repeat the tests that you realize the benefits of creating detailed test cases. When you document the testing procedures completely, you can repeat them exactly and compare the results with the original tests.

Creating a Pilot Deployment

The one element that is extremely difficult to duplicate adequately in a lab environment, no matter what your budget, is network activity. While there are ways to generate traffic on a lab network, it is hard to duplicate actual working conditions. For this reason, it is a good idea to follow up your lab testing with a pilot deployment. A pilot deployment is an implementation of your actual configuration on the production network in a limited and controlled fashion.

The object of a pilot deployment is to select a small sampling of network users, deploy your tested hardware and software configurations on their computers, and have them work under normal operating conditions. A limited deployment like this enables you to monitor the performance of the network more closely and react quickly to any problems that arise. In addition, the pilot program enables you to refine and practice the deployment process you will use on the entire network; it is also an opportunity to train the help desk and other support personnel who will troubleshoot problems when the configuration goes live.

Creating a Pilot Deployment Plan

As with the testing phase, planning and preparation are crucial to a successful pilot deployment. The users in the pilot program are not as rigidly controlled in their activities as the lab testers are, so there is no need to create specific user procedures. After all, the object of the pilot deployment is to have users work as they normally do. What does require careful planning, however, is the selection of the pilot users and creating a support system for them.

Selecting Users for a Pilot Deployment

There are three factors to consider when selecting the users who will participate in your pilot deployment: the nature of the configuration parameters you are rolling out, the users’ roles in the organization, and the users’ own capabilities. Depending on what parameters you are testing, you might want to select a single workgroup or department for the pilot plan, or you might want to select a cross-section of users throughout the organization. A single group or department is easier to monitor and troubleshoot, but a cross-section provides a better picture of the new configuration’s effect on the entire network.

The users participating in a pilot plan should not be performing critical roles. The users must be able to tolerate some down time, should problems occur, without unduly affecting the company’s business or reputation. In addition, the users you select should have temperaments that enable them to deal with problems without panic or hysterics.

Training Users and Support Staff

Your pilot plan should specify the training your selected users need to work with the new configuration. For a pilot deployment of new security parameters, the user training might consist of nothing more than a new logon procedure, but if you are deploying new applications or operating systems, more extensive training might be necessary. You can treat the user training as a dry run for the enterprise-wide deployment that is to follow, so the pilot program should include a complete training plan, including a curriculum, and identifying who will be performing the training and when.

Providing Technical Support

Because problems are likely to occur during a pilot deployment, your plan should also specify what technical support the users will receive and who will provide it. Depending on the nature of the deployment, you might want to have your regular help desk staff handle the pilot users’ problems, or you might want to assemble a support staff specifically for the pilot project. If you choose the latter, you must create an entirely separate support network and inform the users how to report problems and to whom. As with the users, you might have to provide additional training for your support personnel, if you are introducing new technologies in the pilot deployment.

The support staff for the pilot deployment must have protocols in place for rapidly escalating problems, particularly those that point to problems with the new technologies you are deploying. If serious problems occur, it might become necessary to abort the pilot deployment and return the network to its original configuration.

Creating a Rollback Procedure

Because of the limited scope of the pilot deployment, any problems that occur as a result of undiscovered incompatibilities or misconfigurations will not be widespread and should not have a serious effect on network productivity. However, you should always have a rollback procedure as part of your pilot deployment plan, so that you can return to your original network configuration if serious problems arise that demand further development and testing. Your plan should include detailed procedures for the rollback, plus specific conditions under which the rollback should occur.