rfc1244.txt

RFC 的详细文档！

   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.





Site Security Policy Handbook Working Group                     [Page 6]

RFC 1244                 Site Security Handbook                July 1991


      - 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
   introduction.

   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



Site Security Policy Handbook Working Group                     [Page 7]

RFC 1244                 Site Security Handbook                July 1991


   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
   policies.

   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
   bibliography.





Site Security Policy Handbook Working Group                     [Page 8]

RFC 1244                 Site Security Handbook                July 1991


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



Site Security Policy Handbook Working Group                     [Page 9]

RFC 1244                 Site Security Handbook                July 1991


      may be responsible for personal password administration.  Systems
      managers are obligated to fix security holes and to oversee the
      system.

      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
      greater.

      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



Site Security Policy Handbook Working Group                    [Page 10]

RFC 1244                 Site Security Handbook                July 1991


      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: