Basic Policy Requirements

This section explores the creation of a sample policy and its essential components. Assume that you need to create a policy governing the use of electronic communications (e-mail). This policy should cover the following subjects:

• Purpose The purpose states what the policy is all about and what it enforces.

• Scope The scope covers to whom the policy applies, what the affected equipment is, and what technologies are utilized.

• Policy The policy is the main content of the document that outlines what is acceptable behavior and what is not allowed.

• Enforcement Enforcement, as the name implies, is a detailed section that explains possible consequences if the policy is not followed.

• Terms or Glossary The terms section is not always needed; however, documents can become quite technical, and readers might not always understand the terms or acronyms within the document. This section is a common area to help explain what the terms mean for clarification.

Sample E-Mail Usage Policy

The following is a sample e-mail usage policy that covers all five subjects previously listed.

<HackMyNetwork.com> E-mail Acceptable Use Policy 1.0 Purpose In the efforts to protect the image of <HackMyNetwork.com>, this policy has been put into place. Every e-mail from <HackMyNetwork.com> employees should uphold the highest standard of professionalism and tact that <HackMyNetwork.com> has always maintained in the public eye. E-mail should be treated as official statements on the behalf of <HackMyNetwork.com> and must be written and read carefully at all times before being sent. 2.0 Scope The scope of this policy covers any use of e-mail sent from <HackMyNetwork.com> e-mail addresses and applies to every employee, vendor, contractor, and agent who uses e-mail on the behalf of <HackMyNetwork.com>. 3.0 Policy 3.1 Prohibited Use. <HackMyNetwork.com>'s e-mail servers, systems, and client programs will not be used at any time for the creation or distribution of offensive or disruptive e-mail content. This content includes but is not limited to offensive comments about race, gender, color, age, hair color, sexual orientation, disabilities, religious beliefs, political beliefs, pornography, or nationality. Any employees who receive such e-mail with offensive content from other <HackMyNetwork.com> employees should report the incident to their direct supervisor immediately. 3.2 Personal Use <HackMyNetwork.com> e-mail for personal use is acceptable on a limited basis. However, personal e-mails should be kept separate from standard company e-mails. Excessive use of <HackmyNetwork.com> for personal use is prohibited. 3.3 Prohibited Use <HackMyNetwork.com> e-mail is never to be used for sending known viruses, chain letters, joke e-mails, spam, and mass mailings unless approved by your direct supervisor. 3.4 Monitoring E-mail at <HackMyNetwork.com> may be continuously monitored without prior notice to any employee. Employees should have no expectation that e-mail sent to or from <HackMyNetwork.com> is private. However, <HackMyNetwork.com> is not obligated to monitor all e-mails. 4.0 Enforcement Any <HackMyNetwork.com> employee found violating this e-mail policy will be subjected to disciplinary action and possible termination of employment. 5.0 Glossary E-mail: Electronic mail delivered typically via the Internet.

Understanding Your Environment

Knowing what constitutes a "normal" routine within your organization can give you greater insight into the potential security risks that exist and any likely barriers to enforcing security policy. What about that database server that all users access using a system admin account because the application vendor said it could not work any other way, or the fact that you can get into the building without identification every morning between 7:30 and 8:00 because the night security guard is out back preparing to leave and the daytime receptionist has not yet arrived?

Balancing Productivity and Protection

Although the overall aim of a security policy is to protect the assets of the organization, a policy that is too restrictive can have the opposite effect. For example, if users are forced to adhere to a complex password policy, you can expect two things: a significant increase in calls to your help desk for account resets, and the proliferation of "helpful reminders" stuck to monitors around the workplace.

The Trust Model

When looking at levels of trust within your organization, three basic models exist:

• Trust everyone all the time

• Trust no one at any time

• Trust some people some of the time

Employing the "Trust some people some of the time" model is most likely to ensure that your security policy will gain acceptance by your user community without compromising the integrity of the policy. At this level, access is delegated as needed while retaining controls (such as comprehensive auditing) to ensure that those trusts are not being violated.

How Should It Be Written?

Write your policy in terms that are simple to understand. Compliance should not be at the expense of productivity; it is important that users throughout the organization understand the reason for the controls you are implementing.

Who Creates the Policy?

The organization as a whole should be involved in the creation of its security policy. As stated previously, gaining buy-in from key personnel is an important part of rolling out a successful policy. The role of the security officer should be to present a case for security requirements and then to facilitate the introduction of an accompanying policy based on the feedback from the policy team. The team can appoint someone in charge of the policy and policy enforcement.

In addition, the process of creating a security policy helps define the critical company assets and the ways they must be protected.

Types of Policies

You can create a security policy in two main ways:

• One large blanket document containing everything

• Several smaller, specific security policy documents

Either approach is fine. The following sections cover general policy topics you might cover in a large single document policy or for the production of several individual documents.

E-Mail Policies

E-mail is an integral part of a business these days. Most technology business cannot survive well without it. E-mail has also become a great way for people to communicate about nonbusiness-related topics or even spread viruses. Basic e-mail guidelines should be created to prevent misuse that could tarnish the company reputation or allow e-mail to be used to spread viruses onto the network. A list of basic guidelines for an e-mail policy is as follows:

• Do not use office e-mail for personal use.

• Do not send offensive or disruptive messages.

• Do not forward chain letters.

• Open attachments with caution to prevent viruses from spreading.

• Do not send sensitive company information via e-mail.

• Do not conduct personal business with office e-mail.

• The company will inform employees if e-mail monitoring is taking place.

• Keep or store e-mail for only x days.

• The use of encryption is/is not allowed.

Internet Policies

Like e-mail, the Internet has become a powerful standard tool in some businesses. For example, if a piece of hardware or software fails, administrators typically just search the web for quick, free answers. However, the flip side of this is that users spend too much time on the Internet and might even surf inappropriate or offensive websites. Each business has its own ideas about do's and don'ts for this policy. Regardless of what you put in the policy, all users must understand where they can and cannot go and that punishment can result if they violate the policy. Common items in this policy include the following:

• Identify to users whether URL tracking software is used.

• Offer information about installation of content-filtering equipment.

• Provide details of appropriate and inappropriate Internet use.

Remote Access Policies

Accessing the office network from nonoffice locations is more common these days than it has been in the past. A remote access policy defines how, when, and by whom access is allowed. Following are common items in this policy:

• Available methods such as dialup, VPN, and ISDN

• Allowance/disallowance of Telnet, SSH, and Terminal Service

• Employees who are authorized to have remote access capability

• Time of day that remote access is allowed

Password Policies

Passwords are an important element of all computer security systems because passwords provide access to the system. Keeping passwords secure is one of the hardest jobs that a security officer does. If passwords are too short, malicious hackers might have easier access; if passwords are too complex, users might write them down on paper for later use. Every company struggles with these requirements. Following are some basic topics that a password policy should cover:

• Acceptable password length

• Password aging requirements

• User lockout durations

• Password complexity requirements

• Guidelines on how to protect password storage

• Explanation that users should not give passwords over the phone to anyone

• Explanation that passwords should not be sent via e-mail

• Risk of sharing passwords with family members

• Written reminders of passwords in plain sight

Physical Access Policies

Buildings, data centers, and equipment are primary targets for theft and intrusion areas. Typically, large companies have more available funds and often use them to hire security guards and implement surveillance systems. However, all companies should think about physical access to the office and secure areas wherever they can. Common items include:

• Building access

• Data center access

• Wiring cabinets

• Parking lot access

• ID cards

• Whether anyone without a badge or ID should be challenged

• Limited number of building keys

Backup Policies

The need to create backups of data in just about any environment is usually obvious. If data is accidentally deleted or changed, backup tapes need to come out of storage to fix the problem. You need to consider several items in the backup policy:

• Creation of backups of important files

• Documentation of a backup plan and labeling scheme

• Creation of a backup rotation scheme

• Encryption requirements for backed up data

• Definition of a procedure for destruction of old tapes

• Determination of backup retention times

• Implementation of secure offsite storage facility to store backups

• Periodical testing of backups by restoring them

• Purchase of spare restore equipment and backup tables in case of hardware failure

Disaster Recover Policy

Although this document might not seem entirely relevant to your security policy, in the event of total loss of a system, room, building, or site, many aspects of it will have an impact on security. For example, a disaster recovery plan needs to account for how to maintain security during the recovery process. However, the specific contents of a disaster recovery policy are beyond the scope of this topic and are not discussed in further detail here.

Note

Look at the reading room area of SANS.org for more information about the types of security policies, along with some excellent samples.