Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

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

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
4/12/2011 11:34:54 AM

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

Tip

While the focus of this lesson, and of the related 70-293 exam objectives, is on the configuration and deployment of security parameters, your test plan can and should encompass all aspects of network compatibility and performance.


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.

Real World: WAN Testing

While it would be impractical for most organizations to install expensive WAN connections solely for testing purposes, there are other ways to incorporate WAN links into your lab network. For a new network rollout, you might be able to use the WAN connections for the production network during a preliminary testing phase, and then use the same connections for the live deployment when you have completed the testing. You can also substitute lower cost WAN technologies in the lab for the real ones on the production network.

For example, if your network design calls for T-1 leased lines to connect your offices, you can create a reasonable facsimile of the live network in the lab using modems and dial-up connections. Obviously, this type of arrangement does not enable you to test technology-dependent elements such as WAN bandwidth utilization, but it can provide a more accurate representation of your live production network than you could achieve with LAN technology alone.

Creating a WAN testing environment using actual WAN links obviously requires that you disperse the testing facilities among your network locations. Depending on the needs of your organization, you might want to build a lab network at each site, so that the staff at each location can use its own lab network for its own testing and training operations, or you can create a satellite installation at each site, accessible through remote control and intended only to provide a terminus for the WAN connection.


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.

Tip

In many cases, you can use this configuration process as an opportunity to test your deployment plans for hardware, software, or configuration settings. This is just one way you can integrate testing your security configuration into a comprehensive program of testing network administration and rollout.


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.

Important

It is extremely important that your pilot deployment not include technologies or configuration settings that you haven’t previously tested in a lab setting. Modifying the deployment between the lab phase and the pilot phase contaminates the results of the pilot project. If problems occur, you might not be able to determine whether they result from a fault in your original configuration or from the changes you made after testing.


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.

Other -----------------
- Windows Server 2003 : Hardening Servers - Deploying Role-Specific GPOs
- Empowering Users Through SharePoint 2010 Libraries (part 2) - A Brief Tour of a Document Library & Adding Documents to a Document Library
- Empowering Users Through SharePoint 2010 Libraries (part 1) - Using the View All Site Content Page in SharePoint 2010
- Exchange Server 2010 : Prioritizing and Scheduling Maintenance Best Practices
- Exchange Server 2010 : Best Practices for Performing Database Maintenance
- BizTalk 2010 Recipes : Orchestrations - Using the Loop Shape
- BizTalk 2010 Recipes : Orchestrations - Using the Parallel Action Shape
- BizTalk 2010 Recipes : Orchestrations - Receiving Untyped Messages
- Windows Server 2008 R2 : File System Management and Fault Tolerance - Using the Volume Shadow Copy Service
- Windows Server 2008 R2 : File System Management and Fault Tolerance - Backing Up DFS
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server