Security Policies

Security policies are created based upon the security philosophy of the organization. The technical team uses the security policy to design and implement the corporate security structure. The corporate security policy is a formal statement that specifies a set of rules users must follow while accessing the corporate network.

The security policy is not a technical document; it is a business document that lays out the permitted and prohibited activities as well as the efforts and responsibilities regarding security. As defined in RFC 2196 Site Security Handbook, the security policy does not dictate how the business is operated. Rather, the business needs dictate the scope and depth of the security policy. Normally, a security policy is divided into several documents that each addresses a specific topic. These "usage policy statements" define the acceptable use of the network and the users roles and responsibilities with respect to the network. The depth and scope of the security policy documents depend on the size of the organization but should normally address the following topics.

■ Acceptable use of corporate assets—This policy defines what is considered to be acceptable use of the corporate network. It should address such items as use of e-mail and Internet access. Acceptable use must be defined so that employees know what they can and cannot do.

■ Server and workstation configuration policy—This policy defines what applications are to be configured on the network and should designate a specific build for each system. This policy is key to ensuring that all systems on the network adhere to a standard configuration, greatly reducing the time required for troubleshooting configuration problems. The definition of testing procedures for configuration/change management may be included in this policy or there may be a separate policy dedicated to that topic.

■ Patch management policy—The patch management policy defines how systems are upgraded and should outline how new patches are tested before being applied in the production environment. After a patch is approved for use in the production environment, it is added to the standard build to ensure that all new systems are configured with the approved system patch.

■ Network infrastructure policy—The network infrastructure policy defines how the infrastructure is to be managed and who is responsible for maintenance. This policy should address the following items:

— Network addressing scheme

— Naming convention

— Configuration/change management

— Quality of service

— Management and monitoring of systems

— Log consolidation and processing

■ User account policy—The user account policy defines what users should be assigned which account permissions. It is recommended that you limit user permissions to ensure that users adhere to the workstation configuration policy.

■ Other policies—The number and scope of policies depends on the organization. Other policies can address such items as data handling, backup, use of encryption, password requirements (length, type, and lifetime), and remote access.

Cisco recommends that three steps be implemented when establishing a security policy:

■ Preparation—When establishing a security policy, you should first create your general-usage statements or a rough draft of the previously listed policy documents. This will give you a good starting point. Next you need to perform a risk analysis to determine what risks you need to guard against and to define a level of acceptable risk. Risk levels are normally broken into high, medium, and low risk, but what is considered to be a risk must be defined for each organization. The final preparation item should be the designation of security team personnel and the definition of their duties.

■ Prevention—This step defines how changes to you security posture are evaluated and implemented. Additionally, this step outlines how the security of the network should be managed and monitored. This should include the handling of log data, correlation and trending of log data, log data archive, and so on.

■ Response—This step defines what actions are taken in the event of a problem on the network. It defines the individual responsibilities of members of the security team and addresses the following topics:

— Reaction to an attempted security breach

— How to isolate and handle a compromised system

— Evidence gathering and handling of log data

— Working with law enforcement authorities

— Network and system restoration

— Policy review to ensure that any newly discovered vulnerabilities are compensated for

Creating the security policy is not normally a task for a single individual. A security policy team should include members from management, legal, and technical. The security policy must have the full support of management and must be enforceable based on applicable laws and regulations.

Finally, the policy must be technically feasible.

Some people question the need for a policy. There is really only one reason to have a written security policy: cost savings. The cost savings can come in a variety of forms, including the following:

■ Savings through not having data corrupted—Preventing unauthorized users from accessing your data greatly reduces the chances of that data being corrupted. The cost of having to restore corrupted data can be tremendous.

■ Savings through not being devastated by a denial-of-service (DoS) attack—Although it is impossible to prevent a DoS attack, it is not too difficult to mitigate the attack by preventing access at multiple points on your network and at the Internet service provider. This type of defense requires significant coordination and cannot be implemented at the last minute.

■ Savings through not having data manipulated—Restricting access to only authorized users greatly reduces the risk of intentional data manipulation. Data manipulation is normally done to embarrass an organization and can have a lasting affect on their public image.

■ Savings through increased efficiencies—An organization that standardizes its operations and clearly defines its practices will function as a more efficient unit.

■ Savings through reduced "unknown" problems on the network—"Unknown" problems on the network can be the result of the introduction of untested systems, configurations, or applications into the environment. By thoroughly testing and validating all practices, procedures, applications, and configurations prior to implementing them in a production environment, you will greatly reduce the changes of creating these types of issues.

Was this article helpful?

0 0

Post a comment