Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1244

Site Security Handbook

Pages: 101
Obsoleted by:  2196
Part 1 of 4 – Pages 1 to 23
None   None   Next

ToP   noToC   RFC1244 - Page 1
Network Working Group                                        P. Holbrook
Request for Comments:  1244                                       CICNet
FYI: 8                                                       J. Reynolds
                                                               July 1991

                         Site Security Handbook

Status of this Memo

   This handbook is the product of the Site Security Policy Handbook
   Working Group (SSPHWG), a combined effort of the Security Area and
   User Services Area of the Internet Engineering Task Force (IETF).
   This FYI RFC provides information for the Internet community.  It
   does not specify an Internet standard.  Distribution of this memo is

Contributing Authors

   The following are the authors of the Site Security Handbook.  Without
   their dedication, this handbook would not have been possible.

   Dave Curry (Purdue University), Sean Kirkpatrick (Unisys), Tom
   Longstaff (LLNL), Greg Hollingsworth (Johns Hopkins University),
   Jeffrey Carpenter (University of Pittsburgh), Barbara Fraser (CERT),
   Fred Ostapik (SRI NISC), Allen Sturtevant (LLNL), Dan Long (BBN), Jim
   Duncan (Pennsylvania State University), and Frank Byrum (DEC).

Editors' Note

   This FYI RFC is a first attempt at providing Internet users guidance
   on how to deal with security issues in the Internet.  As such, this
   document is necessarily incomplete.  There are some clear shortfalls;
   for example, this document focuses mostly on resources available in
   the United States.  In the spirit of the Internet's "Request for
   Comments" series of notes, we encourage feedback from users of this
   handbook.  In particular, those who utilize this document to craft
   their own policies and procedures.

   This handbook is meant to be a starting place for further research
   and should be viewed as a useful resource, but not the final
   authority.  Different organizations and jurisdictions will have
   different resources and rules.  Talk to your local organizations,
   consult an informed lawyer, or consult with local and national law
   enforcement.  These groups can help fill in the gaps that this
   document cannot hope to cover.
ToP   noToC   RFC1244 - Page 2
   Finally, we intend for this FYI RFC to grow and evolve.  Please send
   comments and suggestions to:

Table of Contents

 1.  Introduction.....................................................  3
 1.1  Purpose of this Work............................................  3
 1.2  Audience........................................................  3
 1.3  Definitions.....................................................  4
 1.4  Related Work....................................................  4
 1.5  Scope...........................................................  4
 1.6  Why Do We Need Security Policies and Procedures?................  5
 1.7  Basic Approach..................................................  7
 1.8  Organization of this Document...................................  7
 2.  Establishing Official Site Policy on Computer Security...........  9
 2.1  Brief Overview..................................................  9
 2.2  Risk Assessment................................................. 10
 2.3  Policy Issues................................................... 13
 2.4  What Happens When the Policy Is Violated........................ 19
 2.5  Locking In or Out............................................... 21
 2.6  Interpreting the Policy......................................... 23
 2.7  Publicizing the Policy.......................................... 23
 3.  Establishing Procedures to Prevent Security Problems............. 24
 3.1  Security Policy Defines What Needs to be Protected.............. 24
 3.2  Identifing Possible Problems.................................... 24
 3.3  Choose Controls to Protect Assets in a Cost-Effective Way....... 26
 3.4  Use Multiple Strategies to Protect Assets....................... 26
 3.5  Physical Security............................................... 27
 3.6  Procedures to Recognize Unauthorized Activity................... 27
 3.7  Define Actions to Take When Unauthorized Activity is Suspected.. 29
 3.8  Communicating Security Policy................................... 30
 3.9  Resources to Prevent Security Breaches.......................... 34
 4.  Types of Security Procedures..................................... 56
 4.1  System Security Audits.......................................... 56
 4.2  Account Management Procedures................................... 57
 4.3  Password Management Procedures.................................. 57
 4.4  Configuration Management Procedures............................. 60
 5.  Incident Handling................................................ 61
 5.1  Overview........................................................ 61
 5.2  Evaluation...................................................... 65
 5.3  Possible Types of Notification.................................. 67
 5.4  Response........................................................ 71
 5.5  Legal/Investigative............................................. 73
 5.6  Documentation Logs.............................................. 77
 6.  Establishing Post-Incident Procedures............................ 78
 6.1  Overview........................................................ 78
 6.2  Removing Vulnerabilities........................................ 78
 6.3  Capturing Lessons Learned....................................... 80
ToP   noToC   RFC1244 - Page 3
 6.4  Upgrading Policies and Procedures............................... 81
 7.  References....................................................... 81
 8.  Annotated Bibliography........................................... 83
 8.1  Computer Law.................................................... 84
 8.2  Computer Security............................................... 85
 8.3  Ethics.......................................................... 91
 8.4  The Internet Worm............................................... 93
 8.5  National Computer Security Center (NCSC)........................ 95
 8.6  Security Checklists............................................. 99
 8.7  Additional Publications......................................... 99
 9.  Acknlowledgements................................................101
 10.  Security Considerations.........................................101
 11.  Authors' Addresses..............................................101

1.  Introduction

1.1  Purpose of this Work

   This handbook is a guide to setting computer security policies and
   procedures for sites that have systems on the Internet.  This guide
   lists issues and factors that a site must consider when setting their
   own policies.  It makes some recommendations and gives discussions of
   relevant areas.

   This guide is only a framework for setting security policies and
   procedures.  In order to have an effective set of policies and
   procedures, a site will have to make many decisions, gain agreement,
   and then communicate and implement the policies.

1.2  Audience

   The audience for this work are system administrators and decision
   makers (who are more traditionally called "administrators" or "middle
   management") at sites.  This document is not directed at programmers
   or those trying to create secure programs or systems.  The focus of
   this document is on the policies and procedures that need to be in
   place to support any technical security features that a site may be

   The primary audience for this work are sites that are members of the
   Internet community.  However, this document should be useful to any
   site that allows communication with other sites.  As a general guide
   to security policies, this document may also be useful to sites with
   isolated systems.
ToP   noToC   RFC1244 - Page 4
1.3  Definitions

   For the purposes of this guide, a "site" is any organization that
   owns computers or network-related resources.  These resources may
   include host computers that users use, routers, terminal servers,
   PC's or other devices that have access to the Internet.  A site may
   be a end user of Internet services or a service provider such as a
   regional network.  However, most of the focus of this guide is on
   those end users of Internet services.

   We assume that the site has the ability to set policies and
   procedures for itself with the concurrence and support from those who
   actually own the resources.

   The "Internet" is those set of networks and machines that use the
   TCP/IP protocol suite, connected through gateways, and sharing a
   common name and address spaces [1].

   The term "system administrator" is used to cover all those who are
   responsible for the day-to-day operation of resources.  This may be a
   number of individuals or an organization.

   The term "decision maker" refers to those people at a site who set or
   approve policy.  These are often (but not always) the people who own
   the resources.

1.4  Related Work

   The IETF Security Policy Working Group (SPWG) is working on a set of
   recommended security policy guidelines for the Internet [23].  These
   guidelines may be adopted as policy by regional networks or owners of
   other resources.  This handbook should be a useful tool to help sites
   implement those policies as desired or required.  However, even
   implementing the proposed policies isn't enough to secure a site.
   The proposed Internet policies deal only with network access
   security.  It says nothing about how sites should deal with local
   security issues.

1.5  Scope

   This document covers issues about what a computer security policy
   should contain, what kinds of procedures are need to enforce
   security, and some recommendations about how to deal with the
   problem.  When developing a security policy, close attention should
   be made not only on the security needs and requirements of the local
   network, but also the security needs and requirements of the other
   interconnected networks.
ToP   noToC   RFC1244 - Page 5
   This is not a cookbook for computer security.  Each site has
   different needs; the security needs of a corporation might well be
   different than the security needs of an academic institution.  Any
   security plan has to conform to the needs and culture of the site.

   This handbook does not cover details of how to do risk assessment,
   contingency planning, or physical security.  These things are
   essential in setting and implementing effective security policy, but
   this document leaves treatment of those issues to other documents.
   We will try to provide some pointers in that direction.

   This document also doesn't talk about how to design or implement
   secure systems or programs.

1.6  Why Do We Need Security Policies and Procedures?

   For most sites, the interest in computer security is proportional to
   the perception of risk and threats.

   The world of computers has changed dramatically over the past
   twenty-five years.  Twenty-five years ago, most computers were
   centralized and managed by data centers.  Computers were kept in
   locked rooms and staffs of people made sure they were carefully
   managed and physically secured.  Links outside a site were unusual.
   Computer security threats were rare, and were basically concerned
   with insiders: authorized users misusing accounts, theft and
   vandalism, and so forth.  These threats were well understood and
   dealt with using standard techniques: computers behind locked doors,
   and accounting for all resources.

   Computing in the 1990's is radically different.  Many systems are in
   private offices and labs, often managed by individuals or persons
   employed outside a computer center.  Many systems are connected into
   the Internet, and from there around the world: the United States,
   Europe, Asia, and Australia are all connected together.

   Security threats are different today.  The time honored advice says
   "don't write your password down and put it in your desk" lest someone
   find it.  With world-wide Internet connections, someone could get
   into your system from the other side of the world and steal your
   password in the middle of the night when your building is locked up.
   Viruses and worms can be passed from machine to machine.  The
   Internet allows the electronic equivalent of the thief who looks for
   open windows and doors; now a person can check hundreds of machines
   for vulnerabilities in a few hours.

   System administrators and decision makers have to understand the
   security threats that exist, what the risk and cost of a problem
ToP   noToC   RFC1244 - Page 6
   would be, and what kind of action they want to take (if any) to
   prevent and respond to security threats.

   As an illustration of some of the issues that need to be dealt with
   in security problems, consider the following scenarios (thanks to
   Russell Brand [2, BRAND] for these):

      - A system programmer gets a call reporting that a
        major underground cracker newsletter is being
        distributed from the administrative machine at his
        center to five thousand sites in the US and
        Western Europe.

        Eight weeks later, the authorities call to inform
        you the information in one of these newsletters
        was used to disable "911" in a major city for
        five hours.

      - A user calls in to report that he can't login to his
        account at 3 o'clock in the morning on a Saturday.  The
        system staffer can't login either.  After rebooting to
        single user mode, he finds that password file is empty.
        By Monday morning, your staff determines that a number
        of privileged file transfers took place between this
        machine and a local university.

        Tuesday morning a copy of the deleted password file is
        found on the university machine along with password
        files for a dozen other machines.

        A week later you find that your system initialization
        files had been altered in a hostile fashion.

      - You receive a call saying that a breakin to a government
        lab occurred from one of your center's machines.  You
        are requested to provide accounting files to help
        trackdown the attacker.

        A week later you are given a list of machines at your
        site that have been broken into.

       - A reporter calls up asking about the breakin at your
         center.  You haven't heard of any such breakin.

        Three days later, you learn that there was a breakin.
        The center director had his wife's name as a password.
ToP   noToC   RFC1244 - Page 7
      - A change in system binaries is detected.

        The day that it is corrected, they again are changed.
        This repeats itself for some weeks.

      - If an intruder is found on your system, should you
        leave the system open to monitor the situation or should
        you close down the holes and open them up again later?

      - If an intruder is using your site, should you call law
        enforcement?  Who makes that decision?  If law enforcement asks
        you to leave your site open, who makes that decision?

      - What steps should be taken if another site calls you and says
        they see activity coming from an account on your system?  What
        if the account is owned by a local manager?

1.7  Basic Approach

   Setting security policies and procedures really means developing a
   plan for how to deal with computer security.  One way to approach
   this task is suggested by Fites, et. al. [3, FITES]:

      -  Look at what you are trying to protect.
      -  Look at what you need to protect it from.
      -  Determine how likely the threats are.
      -  Implement measures which will protect your assets in a
         cost-effective manner.
      -  Review the process continuously, and improve things every time
         a weakness is found.

   This handbook will concentrate mostly on the last two steps, but the
   first three are critically important to making effective decisions
   about security.  One old truism in security is that the cost of
   protecting yourself against a threat should be less than the cost
   recovering if the threat were to strike you.  Without reasonable
   knowledge of what you are protecting and what the likely threats are,
   following this rule could be difficult.

1.8  Organization of this Document

   This document is organized into seven parts in addition to this

   The basic form of each section is to discuss issues that a site might
   want to consider in creating a computer security policy and setting
   procedures to implement that policy.  In some cases, possible options
   are discussed along with the some of the ramifications of those
ToP   noToC   RFC1244 - Page 8
   choices.  As far as possible, this document tries not to dictate the
   choices a site should make, since these depend on local
   circumstances.  Some of the issues brought up may not apply to all
   sites.  Nonetheless, all sites should at least consider the issues
   brought up here to ensure that they do not miss some important area.

   The overall flow of the document is to discuss policy issues followed
   by the issues that come up in creating procedures to implement the

   Section 2 discusses setting official site policies for access to
   computing resources.  It also goes into the issue of what happens
   when the policy is violated.  The policies will drive the procedures
   that need to be created, so decision makers will need to make choices
   about policies before many of the procedural issues in following
   sections can be dealt with.  A key part of creating policies is doing
   some kind of risk assessment to decide what really needs to be
   protected and the level of resources that should be applied to
   protect them.

   Once policies are in place, procedures to prevent future security
   problems should be established.  Section 3 defines and suggests
   actions to take when unauthorized activity is suspected.  Resources
   to prevent secruity breaches are also discussed.

   Section 4 discusses types of procedures to prevent security problems.
   Prevention is a key to security; as an example, the Computer
   Emergency Response Team/Coordination Center (CERT/CC) at Carnegie-
   Mellon University (CMU) estimates that 80% or more of the problems
   they see have to do with poorly chosen passwords.

   Section 5 discusses incident handling: what kinds of issues does a
   site face when someone violates the security policy.  Many decisions
   will have to made on the spot as the incident occurs, but many of the
   options and issues can be discussed in advance.  At very least,
   responsibilities and methods of communication can be established
   before an incident.  Again, the choices here are influenced by the
   policies discussed in section 2.

   Section 6 deals with what happens after a security violation has been
   dealt with.  Security planning is an on-going cycle; just after an
   incident has occurred is an excellent opportunity to improve policies
   and procedures.

   The rest of the document provides references and an annotated
ToP   noToC   RFC1244 - Page 9
2.  Establishing Official Site Policy on Computer Security

2.1  Brief Overview

   2.1.1  Organization Issues

      The goal in developing an official site policy on computer
      security is to define the organization's expectations of proper
      computer and network use and to define procedures to prevent and
      respond to security incidents.  In order to do this, aspects of
      the particular organization must be considered.

      First, the goals and direction of the organization should be
      considered.  For example, a military base may have very different
      security concerns from a those of a university.

      Second, the site security policy developed must conform to
      existing policies, rules, regulations and laws that the
      organization is subject to.  Therefore it will be necessary to
      identify these and take them into consideration while developing
      the policy.

      Third, unless the local network is completely isolated and
      standalone, it is necessary to consider security implications in a
      more global context.  The policy should address the issues when
      local security problems develop as a result of a remote site as
      well as when problems occur on remote systems as a result of a
      local host or user.

   2.1.2  Who Makes the Policy?

      Policy creation must be a joint effort by technical personnel, who
      understand the full ramifications of the proposed policy and the
      implementation of the policy, and by decision makers who have the
      power to enforce the policy.  A policy which is neither
      implementable nor enforceable is useless.

      Since a computer security policy can affect everyone in an
      organization, it is worth taking some care to make sure you have
      the right level of authority in on the policy decisions.  Though a
      particular group (such as a campus information services group) may
      have responsibility for enforcing a policy, an even higher group
      may have to support and approve the policy.

   2.1.3  Who is Involved?

      Establishing a site policy has the potential for involving every
      computer user at the site in a variety of ways.  Computer users
ToP   noToC   RFC1244 - Page 10
      may be responsible for personal password administration.  Systems
      managers are obligated to fix security holes and to oversee the

      It is critical to get the right set of people involved at the
      start of the process.  There may already be groups concerned with
      security who would consider a computer security policy to be their
      area.  Some of the types of groups that might be involved include
      auditing/control, organizations that deal with physical security,
      campus information systems groups, and so forth.  Asking these
      types of groups to "buy in" from the start can help facilitate the
      acceptance of the policy.

   2.1.4  Responsibilities

      A key element of a computer security policy is making sure
      everyone knows their own responsibility for maintaining security.
      A computer security policy cannot anticipate all possibilities;
      however, it can ensure that each kind of problem does have someone
      assigned to deal with it.

      There may be levels of responsibility associated with a policy on
      computer security.  At one level, each user of a computing
      resource may have a responsibility to protect his account.  A user
      who allows his account to be compromised increases the chances of
      compromising other accounts or resources.

      System managers may form another responsibility level: they must
      help to ensure the security of the computer system.  Network
      managers may reside at yet another level.

2.2  Risk Assessment

   2.2.1  General Discussion

      One of the most important reasons for creating a computer security
      policy is to ensure that efforts spent on security yield cost
      effective benefits.  Although this may seem obvious, it is
      possible to be mislead about where the effort is needed.  As an
      example, there is a great deal of publicity about intruders on
      computers systems; yet most surveys of computer security show that
      for most organizations, the actual loss from "insiders" is much

      Risk analysis involves determining what you need to protect, what
      you need to protect it from, and how to protect it.  Is is the
      process of examining all of your risks, and ranking those risks by
      level of severity.  This process involves making cost-effective
ToP   noToC   RFC1244 - Page 11
      decisions on what you want to protect.  The old security adage
      says that you should not spend more to protect something than it
      is actually worth.

      A full treatment of risk analysis is outside the scope of this
      document.  [3, FITES] and [16, PFLEEGER] provide introductions to
      this topic.  However, there are two elements of a risk analysis
      that will be briefly covered in the next two sections:

         1. Identifying the assets
         2. Identifying the threats

      For each asset, the basic goals of security are availability,
      confidentiality, and integrity.  Each threat should be examined
      with an eye to how the threat could affect these areas.

   2.2.2  Identifying the Assets

      One step in a risk analysis is to identify all the things that
      need to be protected.  Some things are obvious, like all the
      various pieces of hardware, but some are overlooked, such as the
      people who actually use the systems. The essential point is to
      list all things that could be affected by a security problem.

      One list of categories is suggested by Pfleeger [16, PFLEEGER,
      page 459]; this list is adapted from that source:

         1. Hardware: cpus, boards, keyboards, terminals,
            workstations, personal computers, printers, disk
            drives, communication lines, terminal servers, routers.

         2. Software: source programs, object programs,
            utilities, diagnostic programs, operating systems,
            communication programs.

         3. Data: during execution, stored on-line, archived off-line,
            backups, audit logs, databases, in transit over
            communication media.

         4. People: users, people needed to run systems.

         5. Documentation: on programs, hardware, systems, local
            administrative procedures.

         6. Supplies: paper, forms, ribbons, magnetic media.
ToP   noToC   RFC1244 - Page 12
   2.2.3  Identifying the Threats

      Once the assets requiring protection are identified, it is
      necessary to identify threats to those assests.  The threats can
      then be examined to determine what potential for loss exists.  It
      helps to consider from what threats you are trying to protect your

      The following sections describe a few of the possible threats.  Unauthorized Access

         A common threat that concerns many sites is unauthorized access
         to computing facilities.  Unauthorized access takes many forms.
         One means of unauthorized access is the use of another user's
         account to gain access to a system.  The use of any computer
         resource without prior permission may be considered
         unauthorized access to computing facilities.

         The seriousness of an unauthorized access will vary from site
         to site.  For some sites, the mere act of granting access to an
         unauthorized user may cause irreparable harm by negative media
         coverage.  For other sites, an unauthorized access opens the
         door to other security threats.  In addition, some sites may be
         more frequent targets than others; hence the risk from
         unauthorized access will vary from site to site.  The Computer
         Emergency Response Team (CERT - see section has
         observed that well-known universities, government sites, and
         military sites seem to attract more intruders.  Disclosure of Information

         Another common threat is disclosure of information.  Determine
         the value or sensitivity of the information stored on your
         computers.  Disclosure of a password file might allow for
         future unauthorized accesses.  A glimpse of a proposal may give
         a competitor an unfair advantage.  A technical paper may
         contain years of valuable research.  Denial of Service

         Computers and networks provide valuable services to their
         users.  Many people rely on these services in order to perform
         their jobs efficiently.  When these services are not available
         when called upon, a loss in productivity results.

         Denial of service comes in many forms and might affect users in
         a number of ways.  A network may be rendered unusable by a
ToP   noToC   RFC1244 - Page 13
         rogue packet, jamming, or by a disabled network component.  A
         virus might slow down or cripple a computer system.  Each site
         should determine which services are essential, and for each of
         these services determine the affect to the site if that service
         were to become disabled.

2.3  Policy Issues

   There are a number of issues that must be addressed when developing a
   security policy.  These are:

      1.  Who is allowed to use the resources?
      2.  What is the proper use of the resources?
      3.  Who is authorized to grant access and approve usage?
      4.  Who may have system administration privileges?
      5.  What are the user's rights and responsibilities?
      6.  What are the rights and responsibilities of the
          system administrator vs. those of the user?
      7.  What do you do with sensitive information?

   These issues will be discussed below.  In addition you may wish to
   include a section in your policy concerning ethical use of computing
   resources.  Parker, Swope and Baker [17, PARKER90] and Forester and
   Morrison [18, FORESTER] are two useful references that address
   ethical issues.

   2.3.1  Who is Allowed to use the Resources?

      One step you must take in developing your security policy is
      defining who is allowed to use your system and services.  The
      policy should explicitly state who is authorized to use what

   2.3.2  What is the Proper Use of the Resources?

      After determining who is allowed access to system resources it is
      necessary to provide guidelines for the acceptable use of the
      resources.  You may have different guidelines for different types
      of users (i.e., students, faculty, external users).  The policy
      should state what is acceptable use as well as unacceptable use.
      It should also include types of use that may be restricted.

      Define limits to access and authority.  You will need to consider
      the level of access various users will have and what resources
      will be available or restricted to various groups of people.

      Your acceptable use policy should clearly state that individual
      users are responsible for their actions.  Their responsibility
ToP   noToC   RFC1244 - Page 14
      exists regardless of the security mechanisms that are in place.
      It should be clearly stated that breaking into accounts or
      bypassing security is not permitted.

      The following points should be covered when developing an
      acceptable use policy:

         o Is breaking into accounts permitted?
         o Is cracking passwords permitted?
         o Is disrupting service permitted?
         o Should users assume that a file being world-readable
           grants them the authorization to read it?
         o Should users be permitted to modify files that are
           not their own even if they happen to have write
         o Should users share accounts?

      The answer to most of these questions will be "no".

      You may wish to incorporate a statement in your policies
      concerning copyrighted and licensed software.  Licensing
      agreements with vendors may require some sort of effort on your
      part to ensure that the license is not violated.  In addition, you
      may wish to inform users that the copying of copyrighted software
      may be a violation of the copyright laws, and is not permitted.

      Specifically concerning copyrighted and/or licensed software, you
      may wish to include the following information:

         o Copyrighted and licensed software may not be duplicated
           unless it is explicitly stated that you may do so.
         o Methods of conveying information on the
           copyright/licensed status of software.
         o When in doubt, DON'T COPY.

      Your acceptable use policy is very important.  A policy which does
      not clearly state what is not permitted may leave you unable to
      prove that a user violated policy.

      There are exception cases like tiger teams and users or
      administrators wishing for "licenses to hack" -- you may face the
      situation where users will want to "hack" on your services for
      security research purposes.  You should develop a policy that will
      determine whether you will permit this type of research on your
      services and if so, what your guidelines for such research will

      Points you may wish to cover in this area:
ToP   noToC   RFC1244 - Page 15
         o Whether it is permitted at all.
         o What type of activity is permitted: breaking in, releasing
           worms, releasing viruses, etc..
         o What type of controls must be in place to ensure that it
           does not get out of control (e.g., separate a segment of
           your network for these tests).
         o How you will protect other users from being victims of
           these activities, including external users and networks.
         o The process for obtaining permission to conduct these

      In cases where you do permit these activities, you should isolate
      the portions of the network that are being tested from your main
      network.  Worms and viruses should never be released on a live

      You may also wish to employ, contract, or otherwise solicit one or
      more people or organizations to evaluate the security of your
      services, of which may include "hacking".  You may wish to provide
      for this in your policy.

   2.3.3  Who Is Authorized to Grant Access and Approve Usage?

      Your policy should state who is authorized to grant access to your
      services.  Further, it must be determined what type of access they
      are permitted to give.  If you do not have control over who is
      granted access to your system, you will not have control over who
      is using your system.  Controlling who has the authorization to
      grant access will also enable you to know who was or was not
      granting access if problems develop later.

      There are many schemes that can be developed to control the
      distribution of access to your services.  The following are the
      factors that you must consider when determining who will
      distribute access to your services:

         o Will you be distributing access from a centralized
           point or at various points?

      You can have a centralized distribution point to a distributed
      system where various sites or departments independently authorize
      access.  The trade off is between security and convenience.  The
      more centralized, the easier to secure.

         o What methods will you use for creating accounts and
           terminating access?

      From a security standpoint, you need to examine the mechanism that
ToP   noToC   RFC1244 - Page 16
      you will be using to create accounts.  In the least restrictive
      case, the people who are authorized to grant access would be able
      to go into the system directly and create an account by hand or
      through vendor supplied mechanisms.  Generally, these mechanisms
      place a great deal of trust in the person running them, and the
      person running them usually has a large amount of privileges.  If
      this is the choice you make, you need to select someone who is
      trustworthy to perform this task.  The opposite solution is to
      have an integrated system that the people authorized to create
      accounts run, or the users themselves may actually run.  Be aware
      that even in the restrictive case of having a mechanized facility
      to create accounts does not remove the potential for abuse.

      You should have specific procedures developed for the creation of
      accounts.  These procedures should be well documented to prevent
      confusion and reduce mistakes.  A security vulnerability in the
      account authorization process is not only possible through abuse,
      but is also possible if a mistake is made.  Having clear and well
      documented procedure will help ensure that these mistakes won't
      happen.  You should also be sure that the people who will be
      following these procedures understand them.

      The granting of access to users is one of the most vulnerable of
      times.  You should ensure that the selection of an initial
      password cannot be easily guessed.  You should avoid using an
      initial password that is a function of the username, is part of
      the user's name, or some algorithmically generated password that
      can easily be guessed.  In addition, you should not permit users
      to continue to use the initial password indefinitely.  If
      possible, you should force users to change the initial password
      the first time they login.  Consider that some users may never
      even login, leaving their password vulnerable indefinitely.  Some
      sites choose to disable accounts that have never been accessed,
      and force the owner to reauthorize opening the account.

   2.3.4  Who May Have System Administration Privileges?

      One security decision that needs to be made very carefully is who
      will have access to system administrator privileges and passwords
      for your services.  Obviously, the system administrators will need
      access, but inevitably other users will request special
      privileges.  The policy should address this issue.  Restricting
      privileges is one way to deal with threats from local users.  The
      challenge is to balance restricting access to these to protect
      security with giving people who need these privileges access so
      that they can perform their tasks.  One approach that can be taken
      is to grant only enough privilege to accomplish the necessary
ToP   noToC   RFC1244 - Page 17
      Additionally, people holding special privileges should be
      accountable to some authority and this should also be identified
      within the site's security policy.  If the people you grant
      privileges to are not accountable, you run the risk of losing
      control of your system and will have difficulty managing a
      compromise in security.

   2.3.5  What Are The Users' Rights and Responsibilities?

      The policy should incorporate a statement on the users' rights and
      responsibilities concerning the use of the site's computer systems
      and services.  It should be clearly stated that users are
      responsible for understanding and respecting the security rules of
      the systems they are using.  The following is a list of topics
      that you may wish to cover in this area of the policy:

         o What guidelines you have regarding resource consumption
           (whether users are restricted, and if so, what the
           restrictions are).
         o What might constitute abuse in terms of system performance.
         o Whether users are permitted to share accounts or let others
           use their accounts.
         o How "secret" users should keep their passwords.
         o How often users should change their passwords and any other
           password restrictions or requirements.
         o Whether you provide backups or expect the users to create
           their own.
         o Disclosure of information that may be proprietary.
         o Statement on Electronic Mail Privacy (Electronic
           Communications Privacy Act).
         o Your policy concerning controversial mail or postings to
           mailing lists or discussion groups (obscenity, harassment,
         o Policy on electronic communications: mail forging, etc.

      The Electronic Mail Association sponsored a white paper on the
      privacy of electronic mail in companies [4].  Their basic
      recommendation is that every site should have a policy on the
      protection of employee privacy.  They also recommend that
      organizations establish privacy policies that deal with all media,
      rather than singling out electronic mail.

      They suggest five criteria for evaluating any policy:

         1. Does the policy comply with law and with duties to
            third parties?

         2. Does the policy unnecessarily compromise the interest of
ToP   noToC   RFC1244 - Page 18
            the employee, the employer or third parties?

         3. Is the policy workable as a practical matter and likely to
            be enforced?

         4. Does the policy deal appropriately with all different
            forms of communications and record keeping with the office?

         5. Has the policy been announced in advance and agreed to by
            all concerned?

   2.3.6  What Are The Rights and Responsibilities of System
          Administrators Versus Rights of Users

      There is a tradeoff between a user's right to absolute privacy and
      the need of system administrators to gather sufficient information
      to diagnose problems.  There is also a distinction between a
      system administrator's need to gather information to diagnose
      problems and investigating security violations.  The policy should
      specify to what degree system administrators can examine user
      files to diagnose problems or for other purposes, and what rights
      you grant to the users.  You may also wish to make a statement
      concerning system administrators' obligation to maintaining the
      privacy of information viewed under these circumstances.  A few
      questions that should be answered are:

         o Can an administrator monitor or read a user's files
           for any reason?
         o What are the liabilities?
         o Do network administrators have the right to examine
           network or host traffic?

   2.3.7  What To Do With Sensitive Information

      Before granting users access to your services, you need to
      determine at what level you will provide for the security of data
      on your systems.  By determining this, you are determining the
      level of sensitivity of data that users should store on your
      systems.  You do not want users to store very sensitive
      information on a system that you are not going to secure very
      well.  You need to tell users who might store sensitive
      information what services, if any, are appropriate for the storage
      of sensitive information.  This part should include storing of
      data in different ways (disk, magnetic tape, file servers, etc.).
      Your policy in this area needs to be coordinated with the policy
      concerning the rights of system administrators versus users (see
      section 2.3.6).
ToP   noToC   RFC1244 - Page 19
2.4  What Happens When the Policy is Violated

   It is obvious that when any type of official policy is defined, be it
   related to computer security or not, it will eventually be broken.
   The violation may occur due to an individual's negligence, accidental
   mistake, having not been properly informed of the current policy, or
   not understanding the current policy.  It is equally possible that an
   individual (or group of individuals) may knowingly perform an act
   that is in direct violation of the defined policy.

   When a policy violation has been detected, the immediate course of
   action should be pre-defined to ensure prompt and proper enforcement.
   An investigation should be performed to determine how and why the
   violation occurred.  Then the appropriate corrective action should be
   executed.  The type and severity of action taken varies depending on
   the type of violation that occurred.

   2.4.1  Determining the Response to Policy Violations

      Violations to policy may be committed by a wide variety of users.
      Some may be local users and others may be from outside the local
      environment.  Sites may find it helpful to define what it
      considers "insiders" and "outsiders" based upon administrative,
      legal or political boundaries.  These boundaries imply what type
      of action must be taken to correct the offending party; from a
      written reprimand to pressing legal charges.  So, not only do you
      need to define actions based on the type of violation, you also
      need to have a clearly defined series of actions based on the kind
      of user violating your computer security policy.  This all seems
      rather complicated, but should be addressed long before it becomes
      necessary as the result of a violation.

      One point to remember about your policy is that proper education
      is your best defense.  For the outsiders who are using your
      computer legally, it is your responsibility to verify that these
      individuals are aware of the policies that you have set forth.
      Having this proof may assist you in the future if legal action
      becomes necessary.

      As for users who are using your computer illegally, the problem is
      basically the same.  What type of user violated the policy and how
      and why did they do it?  Depending on the results of your
      investigation, you may just prefer to "plug" the hole in your
      computer security and chalk it up to experience.  Or if a
      significant amount of loss was incurred, you may wish to take more
      drastic action.
ToP   noToC   RFC1244 - Page 20
   2.4.2  What to do When Local Users Violate the Policy of a Remote

      In the event that a local user violates the security policy of a
      remote site, the local site should have a clearly defined set of
      administrative actions to take concerning that local user.  The
      site should also be prepared to protect itself against possible
      actions by the remote site.  These situations involve legal issues
      which should be addressed when forming the security policy.

   2.4.3  Defining Contacts and Responsibilities to Outside

      The local security policy should include procedures for
      interaction with outside organizations.  These include law
      enforcement agencies, other sites, external response team
      organizations (e.g., the CERT, CIAC) and various press agencies.
      The procedure should state who is authorized to make such contact
      and how it should be handled.  Some questions to be answered

         o Who may talk to the press?
         o When do you contact law enforcement and investigative agencies?
         o If a connection is made from a remote site, is the
           system manager authorized to contact that site?
         o Can data be released?  What kind?

      Detailed contact information should be readily available along
      with clearly defined procedures to follow.

   2.4.4  What are the Responsibilities to our Neighbors and Other
          Internet Sites?

      The Security Policy Working Group within the IETF is working on a
      document entitled, "Policy Guidelines for the Secure Operation of
      the Internet" [23].  It addresses the issue that the Internet is a
      cooperative venture and that sites are expected to provide mutual
      security assistance.  This should be addressed when developing a
      site's policy.  The major issue to be determined is how much
      information should be released.  This will vary from site to site
      according to the type of site (e.g., military, education,
      commercial) as well as the type of security violation that

   2.4.5  Issues for Incident Handling Procedures

      Along with statements of policy, the document being prepared
      should include procedures for incident handling.  This is covered
ToP   noToC   RFC1244 - Page 21
      in detail in the next chapter.  There should be procedures
      available that cover all facets of policy violation.

2.5  Locking In or Out

   Whenever a site suffers an incident which may compromise computer
   security, the strategies for reacting may be influenced by two
   opposing pressures.

   If management fears that the site is sufficiently vulnerable, it may
   choose a "Protect and Proceed" strategy.  This approach will have as
   its primary goal the protection and preservation of the site
   facilities and to provide for normalcy for its users as quickly as
   possible.  Attempts will be made to actively interfere with the
   intruder's processes, prevent further access and begin immediate
   damage assessment and recovery.  This process may involve shutting
   down the facilities, closing off access to the network, or other
   drastic measures.  The drawback is that unless the intruder is
   identified directly, they may come back into the site via a different
   path, or may attack another site.

   The alternate approach, "Pursue and Prosecute", adopts the opposite
   philosophy and goals.  The primary goal is to allow intruders to
   continue their activities at the site until the site can identify the
   responsible persons.  This approach is endorsed by law enforcement
   agencies and prosecutors.  The drawback is that the agencies cannot
   exempt a site from possible user lawsuits if damage is done to their
   systems and data.

   Prosecution is not the only outcome possible if the intruder is
   identified.  If the culprit is an employee or a student, the
   organization may choose to take disciplinary actions.  The computer
   security policy needs to spell out the choices and how they will be
   selected if an intruder is caught.

   Careful consideration must be made by site management regarding their
   approach to this issue before the problem occurs.  The strategy
   adopted might depend upon each circumstance.  Or there may be a
   global policy which mandates one approach in all circumstances.  The
   pros and cons must be examined thoroughly and the users of the
   facilities must be made aware of the policy so that they understand
   their vulnerabilities no matter which approach is taken.

   The following are checklists to help a site determine which strategy
   to adopt: "Protect and Proceed" or "Pursue and Prosecute".
ToP   noToC   RFC1244 - Page 22
   Protect and Proceed

      1. If assets are not well protected.

      2. If continued penetration could result in great
         financial risk.

      3. If the possibility or willingness to prosecute
         is not present.

      4. If user base is unknown.

      5. If users are unsophisticated and their work is

      6. If the site is vulnerable to lawsuits from users, e.g.,
         if their resources are undermined.

   Pursue and Prosecute

      1. If assets and systems are well protected.

      2. If good backups are available.

      3. If the risk to the assets is outweighed by the
         disruption caused by the present and possibly future

      4. If this is a concentrated attack occurring with great
         frequency and intensity.

      5. If the site has a natural attraction to intruders, and
         consequently regularly attracts intruders.

      6. If the site is willing to incur the financial (or other)
         risk to assets by allowing the penetrator continue.

      7. If intruder access can be controlled.

      8. If the monitoring tools are sufficiently well-developed
         to make the pursuit worthwhile.

      9. If the support staff is sufficiently clever and knowledgable
         about the operating system, related utilities, and systems
         to make the pursuit worthwhile.

      10. If there is willingness on the part of management to
ToP   noToC   RFC1244 - Page 23
      11. If the system adminitrators know in general what kind of
          evidence would lead to prosecution.

      12. If there is established contact with knowledgeable law

      13. If there is a site representative versed in the relevant
          legal issues.

      14. If the site is prepared for possible legal action from
          its own users if their data or systems become compromised
          during the pursuit.

2.6  Interpreting the Policy

   It is important to define who will interpret the policy.  This could
   be an individual or a committee.  No matter how well written, the
   policy will require interpretation from time to time and this body
   would serve to review, interpret, and revise the policy as needed.

2.7  Publicizing the Policy

   Once the site security policy has been written and established, a
   vigorous process should be engaged to ensure that the policy
   statement is widely and thoroughly disseminated and discussed.  A
   mailing of the policy should not be considered sufficient.  A period
   for comments should be allowed before the policy becomes effective to
   ensure that all affected users have a chance to state their reactions
   and discuss any unforeseen ramifications.  Ideally, the policy should
   strike a balance between protection and productivity.

   Meetings should be held to elicit these comments, and also to ensure
   that the policy is correctly understood.  (Policy promulgators are
   not necessarily noted for their skill with the language.)  These
   meetings should involve higher management as well as line employees.
   Security is a collective effort.

   In addition to the initial efforts to publicize the policy, it is
   essential for the site to maintain a continual awareness of its
   computer security policy.  Current users may need periodic reminders
   New users should have the policy included as part of their site
   introduction packet.  As a condition for using the site facilities,
   it may be advisable to have them sign a statement that they have read
   and understood the policy.  Should any of these users require legal
   action for serious policy violations, this signed statement might
   prove to be a valuable aid.

(next page on part 2)

Next Section