Evaluating a New Security Policy
Last week I saw something that really bothered me. While visiting a friend at his office, one of the IT staff members told me about a security setting that he had just read about on the Internet. After telling me about the setting, the guy implemented it on the production network. The reason why this bothered me was because the setting was applied on a whim with no planning and little, if any thought as to the repercussions.
A Better Solution
Rather than recklessly making changes to your organization's security policies, I recommend taking a three tiered approach to security policy changes. The first tier involves lab testing, the second tier consists of a limited pilot deployment, and the final tier consists of a full scale deployment.
Before you attempt to implement a policy on a production network, you should use a lab to test the effects of the new policy. Ideally, your lab environment should closely mimic your production network, but should be completely isolated from it. After all, you wouldn't want a glitch in the lab to impact a production server.
A lot of companies shy away from testing labs because it has traditionally been very expensive to build a lab that accurately mimics the production network. Think about it for a moment... If you wanted to accurately simulate your production network, you would need servers, switches, routers, workstations, and a lot of software. Although you will still need some powerful hardware, you can greatly reduce the cost of building a lab by using server virtualization. Server virtualization allows you to use a product such as Microsoft's Virtual Server to simulate multiple servers on a single computer. Obviously, the virtual servers won't run as fast as they would if you ran the server operating systems directly on a physical machine, but you will save a fortune in hardware costs.
Even if you virtualize your servers, you will still need software licenses for your lab environment. You can save money on software licenses by ordering an MSDN subscription from Microsoft. MSDN is a collection of software for use in development environments. You will have to check the Microsoft Web site to make sure that the MSDN license requirements are appropriate for your lab, but MSDN can save you a lot of money since it contains operating systems and applications.
Once you have constructed a test lab, you must configure the lab servers to behave in the same way as your production servers. The easiest way to accomplish this is to restore the backups of your production servers onto your lab servers. Keep in mind though that some applications may not work correctly unless the lab servers have the same hard disk configurations as their production environment counterparts.
OK, so you've got a lab network that mimics your production network as closely as possible. How do you go about testing your new security policy? I recommend that you begin by testing the most obvious effects of the policy. For example, if you are testing a password length policy, try changing your password to one that's exactly the required length. While you are at it, try changing the password to a short password or a blank password. Don't make the mistake of only testing a single user account either. Depending on how your network is set up, a higher level policy may override the recently established policy for some users, so you will want to experiment with a variety of user accounts.
Once you have done some basic testing to confirm that the new policy works, it's a good idea to look for side effects. Remember that some applications use password dependant service accounts. Try borrowing a few users and have them to sign on to a lab PC and do a little bit of work to make sure that everything still works the way that it is supposed to.
Before I go on, I want to point out one thing. I have been using a password length policy change in my example. Although modifying the required password length can have an unexpected impact, spending dozens of hours testing a password length requirement change in a lab probably isn't practical for most organizations. In real life, the extent of the testing that you do would correlate to the complexity of the change that you were making. Even if you aren't doing anything complex right now though, it might still be good to create a lab because you can use it to test just about anything that you plan on doing to your production network (such as upgrading an operating system or deploying a new application)..
Assuming that your lab closely resembles your production network and that you have spent enough time testing the new security policy, you should have a pretty good idea of how the new policy will effect the production network. As long as the new policy seems to be working as anticipated without any major negative side effects, you can implement the policy on your production network. Remember though that it's difficult to adequately test every possible situation in a lab, and it's entirely possible that the users will encounter conditions that were never simulated in the lab. That being the case, it's a good idea to initially perform a pilot deployment rather than a full scale deployment.
There isn't any right or wrong way of performing a pilot deployment. The actual method that you will want to use depends largely on how your network is configured. The main thing that you should try to accomplish is to create a pilot test group consisting of users with many different types of jobs. The idea is that users with different job responsibilities use the network differently, and the wider variety that you select, the more likely your pilot program will be to discover any bugs that may be present in your new security policy.
Over the years, I have seen pilot deployments performed in a number of different ways. For example, if an organization has a lot of branch offices then it might be appropriate to designate one of the branch offices as a testing ground for your new security policy.
If your organization doesn't have a lot of branch offices, then a better alternative might be to designate one specific domain as the pilot deployment group. I have also seen a few administrators create an organizational unit and assign the new policy to it. They then move a random sampling of users into the newly created OU. The OU method works very well, but it can be really impractical for organizations that already have multiple organizational units.
What ever pilot testing method you choose to use, you must understand that there is a very real chance that any or all of your test users could experience problems. You and your support staff need to be prepared for a possible flood of support calls, and you must be prepared to remove the new policy if it is determined to cause problems. More than likely though, if you have done a good job of the lab testing, the new policy will work fine in the limited deployment, and you can move on to a full scale deployment.
Full Scale Deployment
Hopefully by now, you've got a clear understanding of exactly how the security policy change will impact users, computers, and applications. Once you are comfortable with the way that the new security policy setting behaves, you can deploy the setting to the remainder of the organization. Depending on the nature of the new policy, you might also consider sending out a memo letting users know that a change has occurred and what effect the change will have on them. Of course a memo is optional, but it has been my experience that any time I have ever made a noticeable change to a production network and not informed everyone in advance, the helpdesk gets flooded with phone calls.
In this article, I have explained that although Windows makes it easy to make changes to your network's security policy, minor policy changes can have dramatic repercussions. I then went on to explain how you can use lab testing, and a limited pilot deployment to test the effects of a proposed security policy change prior to a full scale deployment.