rfc1281.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1281          Guidelines for the Secure Operation      November 1991


        and operating systems do not provide the level of security that
        is desired and feasible today.  Three types of advances are
        encouraged:

        (a)  Improvements should be made in the basic security
             mechanisms already in place.  Password security is
             generally poor throughout the Internet and can be
             improved markedly through the use of tools to administer
             password assignment and through the use of better
             authentication technology.  At the same time, the
             Internet user population is expanding to include a
             larger percentage of technically unsophisticated users.
             Security defaults on delivered systems and the controls
             for administering security must be geared to this growing
             population.

         (b)  Security extensions to the protocol suite are needed.
              Candidate protocols which should be augmented to improve
              security include network management, routing, file
              transfer, telnet, and mail.

         (c)  The design and implementation of operating systems should
              be improved to place more emphasis on security and pay
              more attention to the quality of the implementation of
              security within systems on the Internet.

APPENDIX A

   Five areas should be addressed in improving local security:

   (1)  There must be a clear statement of the local security policy,
        and this policy must be communicated to the users and other
        relevant parties.  The policy should be on file and available
        to users at all times, and should be communicated to users as
        part of providing access to the system.

   (2)  Adequate security controls must be implemented.  At a minimum,
        this means controlling access to systems via passwords,
        instituting sound password management, and configuring the
        system to protect itself and the information within it.

   (3)  There must be a capability to monitor security compliance and
        respond to incidents involving violation of security.  Logs of
        logins, attempted logins, and other security-relevant events
        are strongly advised, as well as regular audit of these logs.
        Also recommended is a capability to trace connections and other
        events in response to penetrations.  However, it is important
        for service providers to have a well thought out and published



Pethia, Crocker, & Fraser                                       [Page 6]

RFC 1281          Guidelines for the Secure Operation      November 1991


        policy about what information they gather, who has access to it
        and for what purposes.  Maintaining the privacy of network
        users should be kept in mind when developing such a policy.

   (4)  There must be an established chain of communication and control
        to handle security matters.  A responsible person should be
        identified as the security contact.  The means for reaching the
        security contact should be made known to all users and should
        be registered in public directories, and it should be easy for
        computer emergency response centers to find contact information
        at any time.

        The security contact should be familiar with the technology and
        configuration of all systems at the site or should be able to
        get in touch with those who have this knowledge at any time.
        Likewise, the security contact should be pre-authorized to make
        a best effort to deal with a security incident, or should be
        able to contact those with the authority at any time.

   (5)  Sites and networks which are notified of security incidents
        should respond in a timely and effective manner.  In the case
        of penetrations or other violations, sites and networks should
        allocate resources and capabilities to identify the nature of
        the incident and limit the damage.  A site or network cannot be
        considered to have good security if it does not respond to
        incidents in a timely and effective fashion.

        If a violator can be identified, appropriate action should be
        taken to ensure that no further violations are caused.  Exactly
        what sanctions should be brought against a violator depend on
        the nature of the incident and the site environment.  For
        example, a university may choose to bring internal disciplinary
        action against a student violator.

        Similarly, sites and networks should respond when notified of
        security flaws in their systems.  Sites and networks have the
        responsibility to install fixes in their systems as they become
        available.













Pethia, Crocker, & Fraser                                       [Page 7]

RFC 1281          Guidelines for the Secure Operation      November 1991


A Bibliography of Computer and Network Security Related Documents

United States Public Laws (PL) and Federal Policies

   [1] P.L. 100-235, "The Computer Security Act of 1987", (Contained in
       Appendix C of Citation No. 12, Vol II.), Jan. 8, 1988.

   [2] P.L. 99-474 (H.R. 4718), "Computer Fraud and Abuse Act of 1986",
       Oct. 16, 1986.

   [3] P.L. 99-508 (H.R. 4952), "Electronic Communications Privacy Act
       of 1986", Oct. 21, 1986.

   [4] P.L. 99-591, "Paperwork Reduction Reauthorization Act of 1986",
       Oct. 30, 1986.

   [5] P.L. 93-579, "Privacy Act of 1984", Dec. 31, 1984.

   [6] "National Security Decision Directive 145", (Contained in
       Appendix C of Citation No. 12, Vol II.).

   [7] "Security of Federal Automated Information Systems", (Contained
       in Appendix C of Citation No. 12, Vol II.), Appendix III of,
       Management of Federal Information Resources, Office of Management
       and Budget (OMB), Circular A-130.

   [8] "Protection of Government Contractor Telecommunications",
       (Contained in Appendix C of Citation No. 12, Vol II.), National
       Communications Security Instruction (NACSI) 6002.

Other Documents

   [9] Secure Systems Study Committee, "Computers at Risk: Safe
       Computing in the Information Age", Computer Science and
       Technology Board, National Research Council, 2101 Constitution
       Avenue, Washington, DC 20418, December 1990.

  [10] Curry, D., "Improving the Security of Your UNIX System", Report
       No. ITSTD-721-FR-90-21, SRI International, 333 Ravenswood Ave.,
       Menlo Park, CA, 94025-3493, April 1990.

  [11] Holbrook P., and J. Reynolds, Editors, "Site Security Handbook",
       FYI 8, RFC 1244, CICNet, ISI, July 1991.

  [12] "Industry Information Protection, Vols. I,II,III", Industry
       Information Security Task Force, President's National
       Telecommunications Advisory Committee, June 1988.




Pethia, Crocker, & Fraser                                       [Page 8]

RFC 1281          Guidelines for the Secure Operation      November 1991


  [13] Jelen, G., "Information Security: An Elusive Goal", Report No.
       P-85-8, Harvard University, Center for Information Policy
       Research, 200 Akin, Cambridge, MA.  02138, June 1985.

  [14] "Electronic Record Systems and Individual Privacy", OTA-CIT-296,
       Congress of the United States, Office of Technology Assessment,
       Washington, D.C. 20510, June 1986.

  [15] "Defending Secrets, Sharing Data", OTA-CIT-310, Congress of the
       United States, Office of Technology Assessment, Washington, D.C.
       20510, October 1987.

  [16] "Summary of General Legislation Relating to Privacy and Computer
       Security", Appendix 1 of, COMPUTERS and PRIVACY: How the
       Government Obtains, Verifies, Uses and Protects Personal Data,
       GAO/IMTEC-90-70BR, United States General Accounting Office,
       Washington, DC 20548, pp.  36-40, August 1990.

  [17] Stout, E., "U.S. Geological Survey System Security Plan - FY
       1990", U.S. Geological Survey ISD, MS809, Reston, VA, 22092, May
       1990.

Security Considerations

   If security considerations had not been so widely ignored in the
   Internet, this memo would not have been possible.

























Pethia, Crocker, & Fraser                                       [Page 9]

RFC 1281          Guidelines for the Secure Operation      November 1991


Authors' Addresses

   Richard D. Pethia
   Software Engineering Institute
   Carnegie Mellon University
   Pittsburgh, Pennsylvania 15213-3890

   Phone:  [phone]
   FAX:    [phone]

   EMail:  [e-mail]


   Stephen D. Crocker
   Trusted Information Systems, Inc.
   3060 Washington Road
   Glenwood, Maryland 21738

   Phone:  [phone]
   FAX:    [phone]

   EMail:  [e-mail]


   Barbara Y. Fraser
   Software Engineering Institute
   Carnegie Mellon University
   Pittsburgh, Pennsylvania 15213-3890

   Phone:  [phone]
   FAX:    [phone]

   EMail:  [e-mail]


















Pethia, Crocker, & Fraser                                      [Page 10]