• No results found

What Makes a Good Security Usage Policy?

In document Mastering Network Security pdf (Page 44-50)

At a minimum, a good security usage policy should

• Be readily accessible to all members of the organization. • Define a clear set of security goals.

• Accurately define each issue discussed in the policy. • Clearly show the organization’s position on each issue. • Describe the justification of the policy regarding each issue. • Define under what circumstances the issue is applicable.

• State the roles and responsibilities of organizational members with regard to the described issue.

• Spell out the consequences of noncompliance with the described policy.

• Provide contact information for further details or clarification regarding the described issue. • Define the user’s expected level of privacy.

• Include the organization’s stance on issues not specifically defined.

Accessibility

Making your security policy public within the organization is paramount to its effectiveness. As mentioned earlier, logon scripts and terminal messages are a good start.

If your organization has an employee handbook, see about incorporating your security policy into this document. If your organization maintains an intranet Web site for organizational information, have your document added to this site, as well.

Defining Security Goals

While it may seem like simple common sense, a statement of purpose, which defines why security is important to your organization, can be extremely beneficial. This statement can go a long way toward insuring that policy issues are not deemed frivolous or unnecessary.

As part of this statement, feel free to specify your organization’s goals for its security precautions. People are far more accepting of additional standards and guidelines when they understand the benefits these can provide.

A sample security policy has been included in Appendix B. Use this as a guide when creating a security policy for your organization.

Be as clear and precise as possible when describing each policy issue. Insure that all language and terminology are as accurate as possible.

For example, do not refer to Internet access in general; instead, identify the specific services the issue addresses (e-mail, file transfers, and so on). If it becomes necessary later to enforce the policy issue, your organization will have a precise description to fall back on. All too often, general descriptions are open to interpretation—and misinterpretation.

Previous Table of Contents Next

Previous Table of Contents Next

An accurate description becomes even more important if your company uses VPN technology over the Internet. Be precise in defining the difference between public hosts on the Internet and hosts located on the other end of a VPN connection.

Your Organization’s Position

Use clear, concise language to state your organization’s views on the described policy issue. For example, adjectives such as “unacceptable” contain many shades of gray. A worker’s performance might be “unacceptable”—but not necessarily in violation of any specific policy.

When describing matters of policy, stick to words that convey clear and precise meanings. Negative examples of such include “violation,” “breach of contract,” “offense,” and “abuse.” Positive

examples include “permissible,” “legitimate,” “sanctioned,” and “authorized.” By avoiding ambiguous terms, you can be certain that the policy meanings—as well as the ramifications of noncompliance—are clear and enforceable.

Justifying the Policy

We have already discussed a general statement of purpose which defines an overall set of security goals; you should also justify each policy issue. This shows your network users why each point in the policy is important.

For example, the statement, “Since e-mail is considered to be an unsecured medium, it is not

permissible to use it for conveying company private information,” simultaneously states the policy issue and justifies the policy.

When Does the Issue Apply?

Be sure to make clear under what circumstances the policy is considered to be in effect. Does the policy affect all users equally, or only certain work groups? Does it remain in effect after business hours? Does it affect the main office only, or field offices as well?

When you set forth clearly how the policy will be applied, you also clarify its expected impact. This insures that there is no uncertainty about whom this policy applies to. You want to eliminate the possibility that any employee will assume that the policy must apply to everyone but himself or herself.

Any chain is only as strong as its weakest link, so be sure to make it clear that all members of the organization are responsible for asset security. Security is everyone’s concern, not just a part of a particular person’s job description.

Be sure to identify who is responsible for enforcing security policies and what type of authorization this person has from the organization. If a user is asked to surrender access to the system, it is crucial that a clear policy be in place identifying who has the authority to make such a request.

Consequences of Noncompliance

What if an employee fails to follow or simply ignores a specific security policy issue? Your

organization must have a reaction or remedy in place if this occurs. Be sure your policy includes a description of possible reprisals for noncompliance.

It is important that this statement be both legal and clearly defined. Stating that “appropriate action will be taken” does not describe the severity of possible repercussions. Many times a reprisal is left vague because the people writing a policy cannot agree on a proper response. It is extremely

important that a proper remedy be assigned, however, because the severity of the penalty can help convey just how seriously your organization views the issue. For example, sending harassing e-mail may be considered grounds for dismissal, while cruising the Web in order to find the best price for a home computer may only warrant a verbal warning. When you identify consequences of

noncompliance, be specific about what actions your organization may take.

For More Information...

It is difficult to formulate a policy that clearly defines all potential aspects of a specific issue. For this reason, you should identify a resource responsible for providing additional information.

Since individuals’ responsibilities can change, identify this resource by job function rather than by name. It’s better to write, “Consult your direct supervisor for more information” or “Direct all queries regarding this issue to the network security administrator” than “Forward all questions to Billy Bob Smith.”

Level of Privacy

Privacy is always a hot topic: your organization should clearly state its views on privacy with regard to information stored on organizational resources. If an organization does not expressly claim all ownership of stored information, this information may be construed the property of the employee. Don’t assume that company private information is private—spell it out. There was a well publicized case a number of years ago in which a high-level executive left his job for a position with a major competitor. Suspecting that this person may have walked off with some private information, the company retrieved and reviewed all of his e-mail messages. They found evidence that this ex-

employee had in fact left with some information that the company considered vital to maintaining its competitive edge.

When the case went to trial, however, the e-mail was considered inadmissible because there was no clear policy identifying e-mail as a company-owned resource. The defense argued that e-mail is identical to postal mail and as such enjoys the same level of privacy.

Previous Table of Contents Next

Previous Table of Contents Next

The judge in the case was well aware that the U.S. Post Office is not allowed to open personal letters without a court order. The defense argued that, in this situation, the company should be held to the same standard as the Post Office, since its resources were responsible for delivering the mail. As a result, the e-mail was declared inadmissible and the company lost its case due to lack of evidence. The moral of this story is that it is extremely important to assert owner-ship of network resources, and to spell out the measures that can be taken to enforce described policy issues.

Issues Not Specifically Defined

When implementing a firewall, two potential stances are possible with regards to network traffic. The first is “that which is not expressly permitted is denied”; the second is “that which is not expressly denied is permitted.” The first takes a firm stance with regards to security, while the latter is a more liberal approach.

These same principles apply to your security policy. You can design your policy to be restrictive (“That which is not expressly permitted is denied”) or open (“That which is not expressly denied is permitted”) with regard to matters that are not clearly defined. This provides a fallback position if an issue arises that is not specifically described by your security policy. This is a good idea, as you will inevitably forget to mention something.

Include a statement outlining the organization’s stance on issues not explicitly addressed within the security policy itself. Which approach is more appropriate will depend on how strict a security policy you are trying to create. Typically, however, it is easier to begin with a tighter stance on security and then open up additional policies as the need arises.

Example of a Good Policy Statement

Now that we have covered the individual points of a good security policy, let’s look at a specific example to see how to tie these points together. You will find more examples in Appendix B. The following is an example of a policy statement excerpt:

Access to Internet-based Web server resources shall only be allowed for the express purpose of performing work-related duties. This policy is to insure the effective use of networking resources and shall apply equally to all employees. This policy shall be enforced during both production and non-production time periods. All Web server access can be monitored by networking personnel, and employees may be required to justify Web server access to their direct supervisor. Failure to comply with this policy will result in the issuance of a written warning. For more information regarding what is considered appropriate Web server access of Internet resources, please consult your direct supervisor.

Now let’s see if this statement includes everything we have discussed.

In document Mastering Network Security pdf (Page 44-50)