Information Security Basics

This chapter is from the book

TICSA Training Guide

Learn More Buy

This chapter is from the book

This chapter is from the book 

TICSA Training Guide

Learn More Buy

Security Administration—The Importance of a Security Policy

• Describe, recognize, or select good administrative maintenance and change-control issues and tools.

A comprehensive security policy shouldn't be limited only to your computer network. A good security policy encompasses a range of activities across your entire organization, including workstation configuration, logon procedures, and building access procedures.

Understanding Security Policies

In its simplest form, a security policy is a single document (or more commonly, a set of related documents) that describes the security controls that govern an organization's systems, behavior, and activities. At the highest level, security policies do not specify technologies or particular solutions. Instead, they seek to define a specific set of conditions to help protect a company's assets and its ability to conduct business.

In fact, any good security policy must address the following concerns:

• Prevent waste or inappropriate use of organization resources (especially computing resources).

• Limit or eliminate potential legal liability, be it from employees or third parties.

• Preserve and protect valuable, confidential, or proprietary information from unauthorized access or disclosure.

Any well-crafted security policy is enshrined in written form, and provides a way to instruct employees about what kinds of behavior or resource usage are required and acceptable, and what is forbidden and unacceptable. A security policy defines marching orders for IT staff and security professionals to help them enact access controls, authentication methods, and accounting techniques. A good security policy also provides information for rank and file employees as to how to help protect their employer's assets and information, and provides guidelines as to acceptable (and unacceptable) practices and behavior.

Building Security Policies

Like most significant development efforts, building a security policy involves more than an afternoon's work. In fact, this effort is best described using a formal life-cycle model. That is, most security policies cycle through three phases of activity, more or less continuously:

• Development. At some point, a security policy must be created for the first time, or changed so significantly from a previous incarnation that it might as well be a first effort. The activity that drives the formulation of a security policy is called risk assessment, where the fundamental goal behind a security policy is to identify potential sources of risk, and then determine ways to eliminate, reduce, or transfer such risks. Because a broad audience—including executives, IT staff, and end users—must be able to read and understand a security policy, it's important to make it as simple and readable as possible.

• Enactment and enforcement. After a security policy has been defined, it must be deployed. This requires not only enacting its provisions and requirements, but also communicating clearly that it is desirable for all employees to heed its provisions. Although this may seem harsh, it's also often necessary to state—and when necessary, to impose—consequences for those who either fail to heed or knowingly violate the terms and requirements of the policy. This explains why many employers clearly state such consequences in employee handbooks, employment agreements, and other documentation that employees must read and heed on the job.

• Monitoring and maintenance. As in most life-cycle models, this phase is the most active of the three. In other words, IT and security professionals must make sure that security policies are monitored and updated to remain relevant to today's activities and concerns—and ultimately, to manage today's and anticipate and forestall tomorrow's potential risks.

Creating a security policy is the result of completing a set of interlocking activities. Risk assessment comes first and foremost, wherein key business resources, assets, activities, and capabilities are identified, and ways to manage potential exposure to loss or harm are considered.

Next, it's necessary to identify various roles in an organization, in which each role requires its own certain kinds of access to an organization's resources and assets. Thus, you might choose to identify executives, IT staff, salespeople, marketing staff, development staff, and technical support staff as roles sufficiently unique such that each warrants creating its own individual security profile. Of course, a consequence of this activity is that you must analyze each such group's security profile, determine which resources they may access, and what kinds of operations on those resources they will be allowed to perform.

The following list represents a basic, recommended set of steps to follow and build on to create a security policy. Keep in mind that this list is by no means complete or exhaustive. Much of the information gathered in these steps is based on security fundamentals that you learn in the following chapters of this book and during your security research for your own organization's network.

Step by step

3.1 Designing a Security Policy

1. Determine whether your company already has security policies in any form. If it has security policies in place, review them and make changes as necessary to update them to meet current needs and to reflect any new principles or additional security measures that you have developed. This is an ongoing process that must be updated as the security in your organization changes. If you don't already have them in place, now is the time to convince upper management of their importance (the importance of the policies, that is—upper management is certainly aware of their own importance!). You need their support to successfully implement a policy. After you've won them over, put together a multidisciplinary team composed of representatives from all departments in the organization to help you compose the policy. It's much more likely that the policy will be practical and effective if the users assist in developing it.

2. Determine the scope of the policy. Will it pertain to the entire corporation, a specific division or department, or just relate to a specific activity or system?

3. Outline user guidelines that may dictate a particular direction in the security policy—for example, email-usage restrictions. If your company has a network-usage policy in place that limits access to certain information on the servers or does not permit sending personal email, it may affect how you design and implement your security policies. For example, you may want to install and configure a firewall to prevent users from accessing certain Web sites that users are not allowed to view. If your company does not have a network-usage policy, consider working with users and management to determine what defines appropriate use of network resources.

4. Assess current minimum requirements for security based on installed servers, services, operating system software, and other equipment. This varies from site to site, but using everything that you gathered in the first three steps and based on the long-term security goal of the company, you can usually determine the minimum acceptable level of security. This can entail something as simple as ensuring that users change their passwords every 30 days and installing antivirus software on every workstation and server.

Using the information gathered in Steps 1–4, you can more readily create a security policy. You must ensure that such a document contains enough information to be useful, but not so much information that the intended audience has a hard time understanding it. The policy should be a high-level document that doesn't contain so much detail that it requires constant updating. This general policy must include items, such as:

• Password policies

• What to do in case of an intrusion

• What operating system and software updates must be installed, and how often

In addition, you must define consequences for users who do not follow the policy. In short, anything that must be put into words and followed by an organization's users, IT staff, and management must be recorded here. Even something as minor as specifying that users must shut down their systems before leaving at the end of the day should be considered and, if called for, included in the policy.

Recruit Users and Management to Review the Security Policy

After the policy is created, ask other members of the IT staff and, if possible, other management personnel to assess that policy for accuracy and completeness. You must continue this review process throughout the life of the policy to keep it up to date.

You should also select a group of users (with a wide range of skills and experiences) to test its implementation. You'll be able to detect most bugs or growing pains before rolling it out to the entire organization.

Within that selected group, educate them about the "hows and whys" of the security policy, and implement it as necessary. Allow these users to try out these policies and provide feedback. You should record their comments as well as comments from the IT staff who support them during this test phase.

After you complete the testing phase, use any pertinent information from your testers and the IT staff to make whatever changes are necessary to clarify, simplify, or streamline that policy. You can then ask the same group or a different group of users to test the policy again. Only when you are confident that your policy will work for your entire user population, should you educate the entire user base and implement the finalized policy. Quite often, you're better off implementing that policy one group at a time to avoid a high volume of support calls from users who have issues with new security policies.

Keep up with the changes to your organization, configuration, and user needs to ensure that your security policy is current and effective. Most experts recommend that such policies be reviewed as part of routine monthly maintenance activities; in smaller organizations, quarterly reviews may be adequate.

Security Policy Examples

As mentioned earlier in this chapter, a security policy is quite likely to be implemented as a collection of documents, rather than as a single monolithic document. Here, we provide a list of typical documents that will together comprise an organization's security policy, along with pointers to numerous sample security policy templates (blanks that are ready for you to fill out) and examples (actual or sanitized security policy documents) online.

A typical collection of security policy documents is likely to include some or all of the items found on the SANS Institute Web Site (http://www.sans.org/newlook/resources/policies/policies.htm#template), depending on an organization's size, infrastructure, and needs.