Development Process

All sites should have a comprehensive security plan. This plan should be at a higher level than more specific policies such as the one discussed in the example at the end of this chapter. The security plan should be crafted as a framework of broad guidelines into which specific policies fit. It is important to have this framework in place so that individual policies are consistent with the overall site security architecture. Having a strong policy on corporate access from home but weak restrictions on who is entering the building and using the PC in the lobby is inconsistent with the overall philosophy of strong security restrictions on data access.

Two diametrically opposed underlying philosophies can be adopted when defining a security plan: deny all and allow all. Both alternatives have strong and weak points, and the choice between them depends on the need of security for a particular site. The first option is to deny everything and then selectively enable services on a case-by-case basis. This model, which is called the deny all model, is generally more secure than the allow all model. Successfully implementing the deny all model is, however, more work intensive.

The other model, which is referred to as allow all, is much easier to implement, but it is generally less secure than the deny all model. To implement it, simply turn on all services (this is usually the default on a host system) and allow all protocols to travel across network boundaries (this is usually the default at the router level) on a host system. As security holes become apparent, they are restricted or patched at either the host or the network level. Both models can be used at the same time. For example, the policy may be to use the allow all model when setting up workstations for general use but to use the deny all model when setting up information servers.

NOTE

Be careful when mixing models. Many companies adopt the theory of a hard shell and a soft middle. They are willing to pay the cost of security for the external traffic and have strong security measures in place there, but they are unwilling or unable to provide the same protections internally. This works fine if the outer defenses are never broken and the internal users can be trusted. (Refer to the section "Social Engineering" in Chapter 2, "Understanding VulnerabilitiesThe Need for Security.")

To craft an effective security policy, it is important to appoint a development team. For a security policy to be appropriate and effective, it needs to have the acceptance and support of all levels of employees within the organization. It is important that corporate management fully supports the security policy process; otherwise, there is little chance that the process will have the intended impact. When creating and reviewing a security policy, the following individuals and groups should be involved: