2. Security Policies

< Day Day Up >

Throughout this document there will be many references to policies. Often these references will include recommendations for specific policies. Rather than repeat guidance in how to create and communicate such a policy, the reader should apply the advice presented in this chapter when developing any policy recommended later in this book.

2.1 What Is a Security Policy, and Why Have One?

The security-related decisions you make, or fail to make, as administrator largely determine how secure or insecure your network is, how much functionality your network offers, and how easy your network is to use. However, you cannot make good decisions about security without first determining what your security goals are.

Until you determine what your security goals are, you cannot make effective use of any collection of security tools because you simply will not know what to check for and what restrictions to impose.

For example, your goals will probably be very different from the goals of a product vendor. Vendors are trying to make configuration and operation of their products as simple as possible, which implies that the default configurations will often be as open (i.e., insecure) as possible. While this does make it easier to install new products, it also leaves access to those systems, and other systems through them, open to any user who wanders by.

Your goals will be largely determined by the following key trade-offs:

Services offered vs. security provided. Each service offered to users carries its own security risks. For some services the risk outweighs the benefit of the service and the administrator may choose to eliminate the service rather than try to secure it.
Ease of use vs. security. The easiest system to use would allow access to any user and require no passwords; that is, there would be no security. Requiring passwords makes the system a little less convenient but more secure. Requiring device-generated one-time passwords makes the system even more difficult to use but much more secure.
Cost of security vs. risk of loss. There are many different costs to security: monetary (i.e., the cost of purchasing security hardware and software such as firewalls and one-time password generators), performance (i.e., encryption and decryption take time), and ease of use (as mentioned previously). There are also many levels of risk: loss of privacy (i.e., the reading of information by unauthorized individuals), loss of data (i.e., the corruption or erasure of information), and the loss of service (e.g., the filling of data storage space, usage of computational resources, and denial of network access). Each type of cost must be weighed against each type of loss.

Your goals should be communicated to all users, operations staff, and managers through a set of security rules, called a "security policy." We are using this term, rather than the narrower "computer security policy," because the scope includes all types of information technology and the information stored and manipulated by the technology.

2.1.1 Definition of a Security Policy

A security policy is a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide.

2.1.2 Purposes of a Security Policy

The main purpose of a security policy is to inform users, staff, and managers of their obligatory requirements for protecting technology and information assets. The policy should specify the mechanisms through which these requirements can be met. Another purpose is to provide a baseline from which to acquire, configure, and audit computer systems and networks for compliance with the policy; therefore, an attempt to use a set of security tools in the absence of at least an implied security policy is meaningless.

An Appropriate Use Policy (AUP) may also be part of a security policy. It should spell out what users shall and shall not do on the various components of the system, including the type of traffic allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding. For example, an AUP might list any prohibited USENET newsgroups. ^[2]

2.1.3 Who Should Be Involved when Forming Policy?

In order 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 especially important that corporate management fully support the security policy process; otherwise, there is little chance that it will have the intended impact. The following is a list of individuals who should be involved in the creation and review of security policy documents:

Site Security Administrator
Information technology technical staff (e.g., staff from computing center)
Administrators of large user groups within the organization (e.g., business divisions, computer science department within a university, etc.)
Security Incident Response Team
Representatives of the user groups affected by the security policy
Responsible management
Legal counsel (if appropriate)

The list is representative of many organizations but is not necessarily comprehensive. The idea is to bring in representation from key stakeholders, management who have budget and policy authority, technical staff who know what can and cannot be supported, and legal counsel who know the legal ramifications of various policy choices. In some organizations, it may be appropriate to include EDP audit personnel. Involving this group is important if resulting policy statements are to reach the broadest possible acceptance. It is also relevant to mention that the role of legal counsel will vary from country to country.

2.2 What Makes a Good Security Policy?

The characteristics of a good security policy are:

It must be implementable through system administration procedures, publishing of acceptable use guidelines, or other appropriate methods.
It must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible.
It must clearly define the areas of responsibility for the users, administrators, and management.

The components of a good security policy include:

Computer technology purchasing guidelines that specify required or preferred security features. These should supplement existing purchasing policies and guidelines.
A Privacy Policy that defines reasonable expectations of privacy regarding issues such as monitoring of electronic mail, logging of keystrokes, and access to users' files.
An Access Policy that defines access rights and privileges to protect assets from loss or disclosure by specifying acceptable use guidelines for users, operations staff, and management. It should provide guidelines for external connections, data communications, connecting devices to a network, and adding new software to systems. It should also specify any required notification messages (e.g., connect messages should provide warnings about authorized usage and line monitoring, and not simply say "Welcome").
An Accountability Policy that defines the responsibilities of users, operations staff, and management. It should specify an audit capability, and provide incident handling guidelines (e.g., what to do and who to contact if a possible intrusion is detected).
An Authentication Policy that establishes trust through an effective password policy, and by setting guidelines for remote location authentication and the use of authentication devices (e.g., one-time passwords and the devices that generate them).
An Availability Statement that sets users' expectations for the availability of resources. It should address redundancy and recovery issues, as well as specify operating hours and maintenance down-time periods. It should also include contact information for reporting system and network failures.
An Information Technology System and Network Maintenance Policy that describes how internal and external maintenance people are allowed to handle and access technology. One important topic to be addressed here is whether remote maintenance is allowed and how such access is controlled. Another area for consideration is outsourcing and how it is managed.
A Violations Reporting Policy that indicates which types of violations (e.g., privacy and security, internal and external) must be reported and to whom the reports are made. A nonthreatening atmosphere and the possibility of anonymous reporting will result in a greater probability that a violation will be reported if it is detected.
Supporting information that provides users, staff, and management with contact information for each type of policy violation; guidelines on how to handle outside queries about a security incident, or information that may be considered confidential or proprietary; and cross-references to security procedures and related information, such as company policies and governmental laws and regulations.

There may be regulatory requirements that affect some aspects of your security policy (e.g., line monitoring). The creators of the security policy should consider seeking legal assistance in the creation of the policy. At a minimum, the policy should be reviewed by legal counsel.

Once your security policy has been established, it should be clearly communicated to users, staff, and management. Having all personnel sign a statement indicating that they have read, understood, and agreed to abide by the policy is an important part of the process. Finally, your policy should be reviewed on a regular basis to see if it is successfully supporting your security needs.

2.3 Keeping the Policy Flexible

In order for a security policy to be viable for the long term, it requires a lot of flexibility based on an architectural security concept. A security policy should be (largely) independent from specific hardware and software situations (as specific systems tend to be replaced or moved overnight). The mechanisms for updating the policy should be clearly spelled out. This includes the process, the people involved, and the people who must sign off on the changes.

It is also important to recognize that there are exceptions to every rule. Whenever possible, the policy should spell out exceptions to the general policy that exist. For example, under what conditions is a system administrator allowed to go through a user's files? Also, there may be some cases when multiple users will have access to the same user ID. For example, on systems with a "root" user, multiple system administrators may know the password and use the root account.

Another consideration is called the "Garbage Truck Syndrome." This refers to what happens to a site when a key person is suddenly unavailable for his job function (e.g., illness or left the company unexpectedly). Despite the fact that the greatest security resides in the minimum dissemination of information, the risk of losing critical information increases when that information is not shared. It is important to determine what the proper balance is for your site.

^[2]Appropriate Use Policy is referred to as Acceptable Use Policy by some sites.

< Day Day Up >