rfc1244.txt

RFC 的详细文档！

         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.






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


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

      The following sections describe a few of the possible threats.

      2.2.3.1  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 3.9.7.3.1) has
         observed that well-known universities, government sites, and
         military sites seem to attract more intruders.

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

      2.2.3.3  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



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


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

   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



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


      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
           permission?
         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
      be.

      Points you may wish to cover in this area:



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


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

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

      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



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


      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