Security Policy

Security policies are an absolute must ground-work for any organization providing the virtual glue to hold it all together. Before we begin about policies, let’s talk a little about trust as a central theme in many policies. Some policies may not be written because there is trust that people will do the right thing but needed because people don't always do the right thing. Ideally you want to trust all resources, but that is unrealistic. Buggy hardware and software are commonplace. Try to implement controls and procedures to minimize the impact when a failure does occur. Trust of employees and users develops over time. Different categories of employees should be trusted at different levels ensuring level of access is commensurate with level of trust.

When looking at trust, you have three basic models: 1. Trust everyone 2. Trust no one and 3. Trust some people at some time. In today's world it is not very common to find organizations that follow the model of trusting everyone all of the time or trusting no one at any time. The most common model is to trust some people some of the time and build trust over time. Also keep in mind that it may be appropriate to apply different trust models to different parts of the organization.

My experience in the field has consistently shown that security policies tend to elevate the level of tension in any given situation with the fact that people don’t like rules and restrictions in their activities. Everyone tends to view security needs differently: 1. Users are concerned about being able to get their work done without a lot of controls. 2. System support personnel are concerned about the ease of managing systems under tight control. 3. Management is concerned about costs versus protection. Getting all to agree of a policy is impossible so best is to try a Win-Win compromise.

To some extent everyone should be concerned of security policies as everyone is affected by them. The system users are typically affected the most as they see the policies as a set of rules to regulate their behavior making it more difficult for them to accomplish their job. The people who have to support the infrastructure are concerned since they are the ones who have to implement and comply by many of the policies. For example, a policy that requires all Windows Servers to be installed according to a baseline security standard would require more work on the part of the system administrators, not only for the initial install, but also for the system upkeep.

When planning policies, some organizations will go overboard and come up with something that will be impossible to implement and comply with. The bottom line for policies is they must take into consideration the balance of protection with the level of productivity hit. Policies should be concise and easy to read and understand. One thing to keep in mind when developing a policy is how it will affect legacy systems and other infrastructure that is already in place. Once the policies are fully approved, they should be made available to all users who are affected. Finally, all policies should be updated to reflect changes in organization or culture.

One of the major goals of a policy is to implement control. Deciding on the level of control for a specific policy is not always clear-cut. The security needs and the culture of the organization will play a major role when deciding what level of control is appropriate. If you make policies too restrictive or too hard to implement and comply with, they will either be ignored (not implemented) or people will find a way to circumvent the controls in the policies.