Forum of Incident Response & Security Teams/Forum_of_Incident_Response_and_Security_Teams_FIRST_October_1994.iso/teaminfo/nist/csl01_94.txt

Text File | 1994-07-02 | 23KB | 453 lines

                           January 1994
                           CSL Bulletin


COMPUTER SECURITY POLICY:  SETTING THE STAGE FOR SUCCESS
Executives and managers are faced with many choices in directing
the protection of computer assets.  Some choices can be based
upon quantifiable tradeoffs, but others involve competing
tradeoffs, questions of organizational strategic direction, or
other parameters which do not lend themselves to quantitative
analysis.  In making these choices, policy is established for an
organization and is then used as the basis for protecting
resources, both information and technology, and guiding employee
behavior.

Familiarity with various types of policy will aid managers in
addressing computer security issues important to the
organization.  Effective policies ultimately result in the
development and implementation of a better computer security
program and better protection of systems and information.

This CSL Bulletin discusses four types of computer security
policy, their components, and aspects of policy implementation.
Program-level policy is used to create an organization's computer
security program.  Program-framework policy establishes the
organization's overall approach to computer security (i.e., its
computer security framework).  Issue-specific policies address
specific issues of concern to the organization.  Lastly, system-
specific policies focus on policy issues which management has
decided for a specific system.  Comparison of an organization's
computer security policies to the types described in this
bulletin will assist managers in determining if their policies
are comprehensive and appropriate.

*****SIDEBAR:  This bulletin summarizes a chapter of a computer
security handbook being developed by CSL.  In August 1993, we
presented a discussion of the establishment and operation of a
computer security program.   Our October 1993 bulletin on
"People:  An Important Asset in Computer Security" summarized
another handbook chapter.  Additional bulletins will be issued as
chapters are finalized.  END SIDEBAR

Types of Computer Security Policy
Organizations need program-level policy to establish the security
program, assign program management responsibilities, state
organization-wide computer security purpose and objectives, and
provide a basis for compliance.  Program-level policy is
typically issued by the head of the organization or another
senior official, such as the top management officer.

Program-framework policies provide organization-wide direction on
broad areas of program implementation.  For example, they may be
issued to assure that all components of an organization address
contingency planning or risk analysis.  They are appropriate when
an organization can yield benefits from a consistent approach.
Program-framework policies are issued by a manager with
sufficient authority to direct all organization components on
computer security issues.  This may be the organization's
management official or the head of the computer security program.

Issue-specific policies identify and define specific areas of
concern and state the organization's position.  Depending upon
the issue and attendant controversy, as well as potential impact,
issue-specific policy may come from the head of the organization,
the top management official, the Chief Information Officer, or
the computer security program manager.

System-specific policies state the security objectives of a
specific system, define how the system should be operated to
achieve the security objectives, and specify how the protections
and features of the technology will be used to support or enforce
the security objectives.  A system refers to the entire
collection of processes, both automated and manual.  System-
specific policy is normally issued by the manager or owner of the
system (which could be a network or application), but may
originate from a high official, particularly if all impacted
organizational elements do not agree with the new policy.

*****SIDEBAR
Tools to Implement Policy:  Standards, Guidelines, and Procedures
Because policy is written at a broad level, organizations also
develop standards, guidelines, and procedures which offer users,
managers, and others a clearer approach to implementing policy
and meeting organizational goals.  Standards and guidelines
specify technologies and methodologies to be used to secure
systems.  Procedures are yet more detailed steps to be followed
to accomplish particular security-related tasks.  Standards,
guidelines, and procedures may be disseminated throughout an
organization via handbooks, regulations, or manuals.

Organizational standards specify uniform use of specific
technologies, parameters, or procedures when such uniform use
will benefit an organization.  Standardization of organization-
wide identification badges is a typical example, providing ease
of employee mobility and automation of entry/exit systems.
Standards are normally compulsory within an organization.

Guidelines assist users, systems personnel, and others in
effectively securing their systems.  The nature of guidelines,
however, immediately recognizes that systems vary considerably
and imposition of standards is not always achievable,
appropriate, or cost-effective.  An organization guideline may,
for example, be used to help develop system-specific standard
procedures.  Guidelines are often used to help ensure that
specific security measures are not overlooked, although they can
be implemented, and correctly so, in more than one way.

Procedures normally assist in complying with applicable security
policies, standards, and guidelines.  They are detailed steps to
be followed by users, system operations personnel, or others to
accomplish a particular task (e.g., preparing new user accounts
and assigning the appropriate privileges).

Some organizations issue overall computer security "manuals,"
"regulations," "handbooks," or similar documents.  These may mix
policy, guidelines, standards, and procedures, since they are
closely linked.  While manuals and regulations can serve as
important tools, they are most useful when they clearly
distinguish between policy and its implementation (sometimes a
difficult process).  This promotes flexibility and cost-
effectiveness by offering alternative implementation approaches
to achieving policy goals.   ***** END SIDEBAR

Program-Level Policy
Program-level policy establishes the computer security program
and its basic framework.  This high-level policy defines the
purpose of the program and its scope within the organization,
assigns responsibilities for direct program implementation (to
the computer security organization) as well as responsibilities
to related offices (such as the IRM organization), and addresses
compliance issues.  Components of program-level policy should
include:

Purpose:  Clearly states the purpose of the program.  This
includes defining the goals of the computer security program as
well as its management structure.  Security-related needs, such
as integrity, availability, and confidentiality, can form the
basis of organizational goals established in policy.  For
instance, in an organization responsible for maintaining large
mission-critical databases, reduction in errors, data loss, or
data corruption might be specifically stressed.  In an
organization responsible for maintaining confidential personal
data, however, goals might emphasize stronger protection against
unauthorized disclosure.

The program management structure should be organized to best
address the goals of the program and respond to the particular
operating and risk environment of the organization.  Important
issues for the structure of the central computer security program
include management and coordination of security-related
resources, interaction with diverse communities, and the ability
to relay issues of concern to upper management.  The policy could
also establish operational security offices for major systems,
particularly those at high risk or most critical to
organizational operations.

Scope:  Specifies which resources (including facilities,
hardware, and software), information, and personnel the program
covers.  In many cases, the program will cover all systems and
agency personnel, but this is not always true.  In some
instances, a policy may name specific assets, such as major sites
and large systems.  Often tough management decisions arise when
defining the scope of a program, such as determining the extent
to which the program applies to contractors and outside
organizations utilizing or connected to the organization's
systems.  The Computer Security Act of 1987 requires federal
agencies to address the security of all federal interest systems.

Responsibilities:  Addresses the responsibilities of officials
and offices throughout the organization, including the role of
line managers, applications owners, users, and the data
processing or IRM organization.  The policy statement should
distinguish between the responsibilities of computer services
providers and the managers of applications utilizing the computer
services.  It can also serve as the basis for establishing
employee accountability.  Overall, the program-level assignment
of responsibilities should cover those activities and personnel
who will be integral to the implementation and continuity of the
computer security policy.

Compliance:  Authorizes the use of specified penalties and
disciplinary actions for individuals who fail to comply with the
organization's computer security policies.  Since the security
policy is a high-level document, penalties for various
infractions are normally not detailed here.  However, the policy
may authorize the creation of compliance structures which include
violations and specific penalties.  Infractions and associated
penalties are usually defined in issue-specific and system-
specific policies.

When establishing compliance structures, consider that violations
of policy can be unintentional on the part of employees.  For
example, nonconformance can be due to a lack of knowledge or
training.

Program-Framework Policy
Program-framework policy defines the organization's security
program elements which form the framework for the computer
security program and reflect decisions about priorities for
protection, resource allocation, and assignment of
responsibilities.

Criteria for the types of areas to be addressed as computer
security program elements include, but are not limited to:

    areas for which there is an advantage to the organization by
     having the issue addressed in a common manner;
    areas which need to be addressed for the entire
     organization;
    areas for which organization-wide oversight is necessary;
     and
    areas which, through organization-wide implementation, can
     yield significant economies of scale.

The types of areas addressed by program-framework policy vary
within each organization as does the way in which the policy is
expressed.  Some organizations issue policy directives, while
others issue handbooks which combine policy, regulations,
standards, and guidance. (See text box on page *****.)   Many
organizations issue policy on "key" areas of computer security,
such as life cycle management, contingency planning, and network
security.

Keep in mind the criteria stated above for the types of areas
that should be addressed in program-framework policy.  If the
policy (and its implementing standards and guidance) is too
rigid, cost-effective implementations and innovation could be
stifled.

As an example of program-framework policy, consider a typical
organization policy on contingency planning.  The organization
might require that all contingency plans categorize criticality
of processing according to a standard scale.  This will assist
the organization in the preparation of a master plan (for use if
the organization's physical plant is destroyed) by facilitating
prioritization across intra-organizational boundaries.

Policy in these areas normally applies throughout the
organization and is usually independent of technology and the
system or application.  Program-framework policies may be
comprised of components similar to those contained in program-
level policy -- but may be in a very different format (e.g., in
organizational handbook directives).

Issue-Specific Policy
Issue-specific policies focus on areas of current relevance and
concern (and sometimes controversy).  Program-level policy is
usually broad enough that it requires little modification over
time.  Conversely, issue-specific policies require more frequent
revision due to changes in technology and related factors.  As
new technologies develop, some issues diminish in importance
while new ones continually appear.  It may be appropriate, for
example, to issue a policy on the proper use of a cutting-edge
technology, the security vulnerabilities of which are still
largely unknown.

A useful structure for issue-specific policy is to break the
policy into its basic components:  statement of an issue,
statement of the organization's position, applicability, roles
and responsibilities, compliance, and points of contact.  Other
topic areas may be added as needed.

Issue Statement:  Defines the issue, with any relevant terms,
distinctions, and conditions.  For example, an organization might
want to develop an issue-specific policy on the use of
"unapproved software," which might be defined to mean any
software not approved, purchased, screened, managed, and owned by
the organization.  Additionally, applicable distinctions and
conditions might need to be included, for instance, software
privately owned by employees but approved for use at work and for
software owned and used by other businesses under contract to the
organization.

Statement of the Organization's Position:  Clearly states the
organization's position on the issue.  To continue the example of
unapproved software, the policy would state whether use of
unapproved software is prohibited in all or some cases, whether
or not there are further guidelines for approval and use, or
whether case-by-case exceptions will be granted, by whom, and on
what basis.

Applicability:  Clearly states where, how, when, to whom, and to
what a particular policy applies.  For example, the hypothetical
policy on unapproved software may apply only to the
organization's own on-site resources and employees and not to
contractor organizations with offices at other locations.
Additionally, the policy's applicability to employees travelling
among different sites or working at home who will transport and
use disks at multiple sites might require clarification.

Roles and Responsibilities:  Assigns roles and responsibilities.
To continue the software example, if the policy permits
unapproved software privately owned by employees to be used at
work with appropriate approvals, then the approving authority
would be identified.  An office responsible for compliance could
also be named.

Compliance:  Gives descriptions of the infractions which are
unacceptable and states the corresponding penalties.  Penalties
must be consistent with organizational personnel policies and
practices and need to be coordinated with appropriate officials,
offices and, perhaps, employee bargaining units.

Points of Contact and Supplementary Information:  Gives the name
of the appropriate individuals to contact for further information
and lists any applicable standards or guidelines.  For some
issues the point of contact might be a line manager; for other
issues it might be a facility manager, technical support person,
or system administrator.  For yet other issues, the
point-of-contact might be a security program representative.
Using the software example, employees need to know whether the
point of contact for questions and procedural information would
be the immediate superior, a system administrator, or a computer
security official.

System-Specific Policy
Program-level policy and issue-specific policy both address
policy from a broad level, usually encompassing the entire
organization.  System-specific policy, on the other hand, is much
more focused, since it addresses only one system.

Many security policy decisions apply only at the system level.
Some examples include:

       Who is allowed to read or modify data in the system?
       Under what conditions can data be read or modified?
       Are users allowed to dial into the computer system from
          home or while on travel?

To develop a comprehensive set of system security policies, use a
management process which derives security rules from security
goals.  Consider a three-level model for system security policy:
security objectives, operational security, and policy
implementation.

Security Objectives:  First, define security objectives.  While
this process may start with an analysis of the need for
integrity, availability, and confidentiality, it cannot stop
there.  A security objective must be more specific, concrete, and
well-defined.  It also should be stated so that it is clear that
the objective is achievable.

The security objectives should consist of a series of statements
which describe meaningful actions about specific resources.
These objectives should be based on system functional or mission
requirements, but should state the security actions which support
the requirements.

Operational Security:  Next lay out the operational policy which
gives the rules for operating a system.  Following the same
integrity example, the operational policy would define authorized
and unauthorized modification:  who, (by job category, by
organization placement, or by name) can do what (modify, delete,
etc.) to which pieces of data (specific fields or records) and
under what conditions.

Managers need to make decisions in developing this policy since
it is unlikely that all security objectives will be fully met.
Cost, operational, technical, and other constraints will
intervene.

Consider the degree of granularity needed for operational
security policies.  Granularity refers to how specific the policy
is with regard to resources or rules.  The more granular the
policies, the easier to enforce and to detect violations.  A
policy violation may indicate a security problem.  In addition,
the more granular the policy, the easier to automate policy
enforcement.

Consider the degree of formality you want in documenting the
policy.  Once again, the more formal the documentation, the
easier to enforce and to follow policy.  Formal policy is
published as a distinct policy document; less formal policy may
be written in memos.  Informal policy may not be written at all.
Unwritten policy is extremely difficult to follow or enforce.

On the other hand, very granular and formal policy at the system
level can also be an administrative burden.  In general, good
practice suggests a granular formal statement of the access
privileges for a system due to its complexity and importance.
Documenting access controls policy makes it substantially easier
to follow and to enforce.  Another area that normally requires a
granular and formal statement is the assignment of security
responsibilities.

Some less formal policy decisions may be recorded in other types
of computer security documents such as risk analyses,
accreditation statements, or procedural manuals.  However, any
controversial, atypical, or uncommon policies may need formal
policy statements.  Atypical policies would include any areas
where the system policy is different from organization policy or
from normal practice within the organization, either more or less
stringent.  They should also contain a statement explaining the
reason for deviation from the organization's standard policy.

Policy Implementation:  Determine the role technology will play
in enforcing or supporting the policy.  Security is normally
enforced through a combination of technical and traditional
management methods.

While technical means are likely to include the use of access
control technology, there are other automated means of enforcing
or supporting security policy.  For example, technology can be
used to block telephone systems users from calling certain
numbers.  Intrusion detection software can alert system
administrators to suspicious activity or take action to stop the
activity.  Personal computers can be configured to prevent
booting from a floppy disk.

Automated security enforcement has advantages and disadvantages.
A computer system, properly designed, programmed, and installed,
consistently enforces policy, although no computer can force
users to follow all procedures.  In addition, deviations from the
policy may sometimes be necessary and appropriate.  This
situation occurs frequently if the security policy is too rigid.


*****BLOCK  Helpful Hints
To be effective, policy requires visibility.  Visibility aids
implementation of policy by helping to ensure that knowledge of
the policy is diffused throughout the organization.  Use
management presentations, videos, panel discussions, guest
speakers, question/answer forums, and newsletters, as resources
permit.  The organization's computer security training and
awareness program can effectively notify users of new policies.

Introduce computer security policies in a manner that ensures
that management's unqualified support is clear, especially in
environments where employees feel inundated with policies,
directives, guidelines, and procedures.  The organization's
policy is the vehicle for emphasizing management's commitment to
computer security and making clear their expectations for
employee performance, behavior, and accountability.

Computer security policy should also be integrated into and
consistent with other organizational policies, such as personnel
policies).  One way to help ensure this is to thoroughly
coordinate policies during development with other offices in the
organization.  *****END BLOCK

Conclusion
Formulating viable computer security policies is a challenge for
an organization and requires communication and understanding of
the organizational goals and potential benefits to be derived
from policies.  Through a carefully structured approach to policy
development, which includes the delegation of program management
responsibility and an understanding of program-level, program-
framework, issue-specific, and system-specific policy components,
your organization can achieve a coherent set of policies.  These
will help produce a framework for a successful computer security
program.