Before you actually implement
security policies on your production network, you must be sure the
settings you choose are suitable for your computer, function properly,
and satisfy your organization’s security requirements. To verify the
functionality of your security configuration, the best practice is to
first test it in a lab environment and then create a limited pilot
deployment on your live network. Then, if the configuration exhibits no
major problems, you can proceed to deploy it throughout your network.
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 it 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
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 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 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.
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 whether 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, you should 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 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 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.
