home *** CD-ROM | disk | FTP | other *** search
/ Forum of Incident Response & Security Teams / Forum_of_Incident_Response_and_Security_Teams_FIRST_October_1994.iso / papers / criteria / internet.txt < prev    next >
Text File  |  1994-06-26  |  23KB  |  563 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Pethia
  8. Request for Comments: 1281                Software Engineering Institute
  9.                                                               S. Crocker
  10.                                        Trusted Information Systems, Inc.
  11.                                                                B. Fraser
  12.                                           Software Engineering Institute
  13.                                                            November 1991
  14.  
  15.  
  16.           Guidelines for the Secure Operation of the Internet
  17.  
  18. Status of this Memo
  19.  
  20.    This memo provides information for the Internet community.  It does
  21.    not specify an Internet standard.  Distribution of this memo is
  22.    unlimited.
  23.  
  24. Preamble
  25.  
  26.    The purpose of this document is to provide a set of guidelines to aid
  27.    in the secure operation of the Internet.  During its history, the
  28.    Internet has grown significantly and is now quite diverse.  Its
  29.    participants include government institutions and agencies, academic
  30.    and research institutions, commercial network and electronic mail
  31.    carriers, non-profit research centers and an increasing array of
  32.    industrial organizations who are primarily users of the technology.
  33.    Despite this dramatic growth, the system is still operated on a
  34.    purely collaborative basis.  Each participating network takes
  35.    responsibility for its own operation.  Service providers, private
  36.    network operators, users and vendors all cooperate to keep the system
  37.    functioning.
  38.  
  39.    It is important to recognize that the voluntary nature of the
  40.    Internet system is both its strength and, perhaps, its most fragile
  41.    aspect.  Rules of operation, like the rules of etiquette, are
  42.    voluntary and, largely, unenforceable, except where they happen to
  43.    coincide with national laws, violation of which can lead to
  44.    prosecution.  A common set of rules for the successful and
  45.    increasingly secure operation of the Internet can, at best, be
  46.    voluntary, since the laws of various countries are not uniform
  47.    regarding data networking.  Indeed, the guidelines outlined below
  48.    also can be only voluntary.  However, since joining the Internet is
  49.    optional, it is also fair to argue that any Internet rules of
  50.    behavior are part of the bargain for joining and that failure to
  51.    observe them, apart from any legal infrastructure available, are
  52.    grounds for sanctions.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Pethia, Crocker, & Fraser                                       [Page 1]
  59.  
  60. RFC 1281          Guidelines for the Secure Operation      November 1991
  61.  
  62.  
  63. Introduction
  64.  
  65.    These guidelines address the entire Internet community, consisting of
  66.    users, hosts, local, regional, domestic and international backbone
  67.    networks, and vendors who supply operating systems, routers, network
  68.    management tools, workstations and other network components.
  69.  
  70.    Security is understood to include protection of the privacy of
  71.    information, protection of information against unauthorized
  72.    modification, protection of systems against denial of service, and
  73.    protection of systems against unauthorized access.
  74.  
  75.    These guidelines encompass six main points.  These points are
  76.    repeated and elaborated in the next section.  In addition, a
  77.    bibliography of computer and network related references has been
  78.    provided at the end of this document for use by the reader.
  79.  
  80.  Security Guidelines
  81.  
  82.    (1)  Users are individually responsible for understanding and
  83.         respecting the security policies of the systems (computers and
  84.         networks) they are using.  Users are individually accountable
  85.         for their own behavior.
  86.  
  87.    (2)  Users have a responsibility to employ available security
  88.         mechanisms and procedures for protecting their own data.  They
  89.         also have a responsibility for assisting in the protection of
  90.         the systems they use.
  91.  
  92.    (3)  Computer and network service providers are responsible for
  93.         maintaining the security of the systems they operate.  They are
  94.         further responsible for notifying users of their security
  95.         policies and any changes to these policies.
  96.  
  97.    (4)  Vendors and system developers are responsible for providing
  98.         systems which are sound and which embody adequate security
  99.         controls.
  100.  
  101.    (5)  Users, service providers, and hardware and software vendors are
  102.         responsible for cooperating to provide security.
  103.  
  104.    (6)  Technical improvements in Internet security protocols should be
  105.         sought on a continuing basis.  At the same time, personnel
  106.         developing new protocols, hardware or software for the Internet
  107.         are expected to include security considerations as part of the
  108.         design and development process.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Pethia, Crocker, & Fraser                                       [Page 2]
  115.  
  116. RFC 1281          Guidelines for the Secure Operation      November 1991
  117.  
  118.  
  119. Elaboration
  120.  
  121.    (1)  Users are individually responsible for understanding and
  122.         respecting the security policies of the systems (computers and
  123.         networks) they are using.  Users are individually accountable
  124.         for their own behavior.
  125.  
  126.         Users are responsible for their own behavior.  Weaknesses in
  127.         the security of a system are not a license to penetrate or
  128.         abuse a system.  Users are expected to be aware of the security
  129.         policies of computers and networks which they access and to
  130.         adhere to these policies.  One clear consequence of this
  131.         guideline is that unauthorized access to a computer or use of a
  132.         network is explicitly a violation of Internet rules of conduct,
  133.         no matter how weak the protection of those computers or networks.
  134.  
  135.         There is growing international attention to legal prohibition
  136.         against unauthorized access to computer systems, and several
  137.         countries have recently passed legislation that addresses the
  138.         area (e.g., United Kingdom, Australia).  In the United States,
  139.         the Computer Fraud and Abuse Act of 1986, Title 18 U.S.C.
  140.         section 1030 makes it a crime, in certain situations, to access
  141.         a Federal interest computer (federal government computers,
  142.         financial institution computers, and a computer which is one of
  143.         two or more computers used in committing the offense, not all of
  144.         which are located in the same state) without authorization.
  145.         Most of the 50 states in the U.S have similar laws.
  146.  
  147.         Another aspect of this part of the policy is that users are
  148.         individually responsible for all use of resources assigned to
  149.         them, and hence sharing of accounts and access to resources is
  150.         strongly discouraged.  However, since access to resources is
  151.         assigned by individual sites and network operators, the
  152.         specific rules governing sharing of accounts and protection of
  153.         access is necessarily a local matter.
  154.  
  155.    (2)  Users have a responsibility to employ available security
  156.         mechanisms and procedures for protecting their own data.  They
  157.         also have a responsibility for assisting in the protection of
  158.         the systems they use.
  159.  
  160.         Users are expected to handle account privileges in a
  161.         responsible manner and to follow site procedures for the
  162.         security of their data as well as that of the system.  For
  163.         systems which rely upon password protection, users should
  164.         select good passwords and periodically change them.  Proper
  165.         use of file protection mechanisms (e.g., access control lists)
  166.         so as to define and maintain appropriate file access control
  167.  
  168.  
  169.  
  170. Pethia, Crocker, & Fraser                                       [Page 3]
  171.  
  172. RFC 1281          Guidelines for the Secure Operation      November 1991
  173.  
  174.  
  175.         is also part of this responsibility.
  176.  
  177.    (3)  Computer and network service providers are responsible for
  178.         maintaining the security of the systems they operate.  They are
  179.         further responsible for notifying users of their security
  180.         policies and any changes to these policies.
  181.  
  182.         A computer or network service provider may manage resources on
  183.         behalf of users within an organization (e.g., provision of
  184.         network and computer services with a university) or it may
  185.         provide services to a larger, external community (e.g., a
  186.         regional network provider).  These resources may include host
  187.         computers employed by users, routers, terminal servers, personal
  188.         computers or other devices that have access to the Internet.
  189.  
  190.         Because the Internet itself is neither centrally managed nor
  191.         operated, responsibility for security rests with the owners and
  192.         operators of the subscriber components of the Internet.
  193.         Moreover, even if there were a central authority for this
  194.         infrastructure, security necessarily is the responsibility of
  195.         the owners and operators of the systems which are the primary
  196.         data and processing resources of the Internet.
  197.  
  198.         There are tradeoffs between stringent security measures at a
  199.         site and ease of use of systems (e.g., stringent security
  200.         measures may complicate user access to the Internet).  If a site
  201.         elects to operate an unprotected, open system, it may be
  202.         providing a platform for attacks on other Internet hosts while
  203.         concealing the attacker's identity.  Sites which do operate
  204.         open systems are nonetheless responsible for the behavior of
  205.         the systems' users and should be prepared to render assistance
  206.         to other sites when needed.  Whenever possible, sites should
  207.         try to ensure authenticated Internet access.  The readers are
  208.         directed to appendix A for a brief descriptive list of elements
  209.         of good security.
  210.  
  211.         Sites (including network service providers) are encouraged to
  212.         develop security policies.  These policies should be clearly
  213.         communicated to users and subscribers.  The Site Security
  214.         Handbook (FYI 8, RFC 1244) provides useful information and
  215.         guidance on developing good security policies and procedures
  216.         at both the site and network level.
  217.  
  218.    (4)  Vendors and system developers are responsible for providing
  219.         systems which are sound and which embody adequate security
  220.         controls.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Pethia, Crocker, & Fraser                                       [Page 4]
  227.  
  228. RFC 1281          Guidelines for the Secure Operation      November 1991
  229.  
  230.  
  231.         A vendor or system developer should evaluate each system in
  232.         terms of security controls prior to the introduction of the
  233.         system into the Internet community.  Each product (whether
  234.         offered for sale or freely distributed) should describe the
  235.         security features it incorporates.
  236.  
  237.         Vendors and system developers have an obligation to repair
  238.         flaws in the security relevant portions of the systems they
  239.         sell (or freely provide) for use in the Internet.  They are
  240.         expected to cooperate with the Internet community in
  241.         establishing mechanisms for the reporting of security flaws and
  242.         in making security-related fixes available to the community in
  243.         a timely fashion.
  244.  
  245.    (5)  Users, service providers, and hardware and software vendors are
  246.         responsible for cooperating to provide security.
  247.  
  248.         The Internet is a cooperative venture.  The culture and
  249.         practice in the Internet is to render assistance in security
  250.         matters to other sites and networks.  Each site is expected to
  251.         notify other sites if it detects a penetration in progress at
  252.         the other sites, and all sites are expected to help one another
  253.         respond to security violations.  This assistance may include
  254.         tracing connections, tracking violators and assisting law
  255.         enforcement efforts.
  256.  
  257.         There is a growing appreciation within the Internet community
  258.         that security violators should be identified and held
  259.         accountable.  This means that once a violation has been detected,
  260.         sites are encouraged to cooperate in finding the violator and
  261.         assisting in enforcement efforts.  It is recognized that many
  262.         sites will face a trade-off between securing their sites as
  263.         rapidly as possible versus leaving their site open in the hopes
  264.         of identifying the violator.  Sites will also be faced with the
  265.         dilemma of limiting the knowledge of a penetration versus
  266.         exposing the fact that a penetration has occurred.  This policy
  267.         does not dictate that a site must expose either its system or
  268.         its reputation if it decides not to, but sites are encouraged
  269.         to render as much assistance as they can.
  270.  
  271.    (6)  Technical improvements in Internet security protocols should be
  272.         sought on a continuing basis.  At the same time, personnel
  273.         developing new protocols, hardware or software for the Internet
  274.         are expected to include security considerations as part of the
  275.         design and development process.
  276.  
  277.         The points discussed above are all administrative in nature,
  278.         but technical advances are also important.  Existing protocols
  279.  
  280.  
  281.  
  282. Pethia, Crocker, & Fraser                                       [Page 5]
  283.  
  284. RFC 1281          Guidelines for the Secure Operation      November 1991
  285.  
  286.  
  287.         and operating systems do not provide the level of security that
  288.         is desired and feasible today.  Three types of advances are
  289.         encouraged:
  290.  
  291.         (a)  Improvements should be made in the basic security
  292.              mechanisms already in place.  Password security is
  293.              generally poor throughout the Internet and can be
  294.              improved markedly through the use of tools to administer
  295.              password assignment and through the use of better
  296.              authentication technology.  At the same time, the
  297.              Internet user population is expanding to include a
  298.              larger percentage of technically unsophisticated users.
  299.              Security defaults on delivered systems and the controls
  300.              for administering security must be geared to this growing
  301.              population.
  302.  
  303.          (b)  Security extensions to the protocol suite are needed.
  304.               Candidate protocols which should be augmented to improve
  305.               security include network management, routing, file
  306.               transfer, telnet, and mail.
  307.  
  308.          (c)  The design and implementation of operating systems should
  309.               be improved to place more emphasis on security and pay
  310.               more attention to the quality of the implementation of
  311.               security within systems on the Internet.
  312.  
  313. APPENDIX A
  314.  
  315.    Five areas should be addressed in improving local security:
  316.  
  317.    (1)  There must be a clear statement of the local security policy,
  318.         and this policy must be communicated to the users and other
  319.         relevant parties.  The policy should be on file and available
  320.         to users at all times, and should be communicated to users as
  321.         part of providing access to the system.
  322.  
  323.    (2)  Adequate security controls must be implemented.  At a minimum,
  324.         this means controlling access to systems via passwords,
  325.         instituting sound password management, and configuring the
  326.         system to protect itself and the information within it.
  327.  
  328.    (3)  There must be a capability to monitor security compliance and
  329.         respond to incidents involving violation of security.  Logs of
  330.         logins, attempted logins, and other security-relevant events
  331.         are strongly advised, as well as regular audit of these logs.
  332.         Also recommended is a capability to trace connections and other
  333.         events in response to penetrations.  However, it is important
  334.         for service providers to have a well thought out and published
  335.  
  336.  
  337.  
  338. Pethia, Crocker, & Fraser                                       [Page 6]
  339.  
  340. RFC 1281          Guidelines for the Secure Operation      November 1991
  341.  
  342.  
  343.         policy about what information they gather, who has access to it
  344.         and for what purposes.  Maintaining the privacy of network
  345.         users should be kept in mind when developing such a policy.
  346.  
  347.    (4)  There must be an established chain of communication and control
  348.         to handle security matters.  A responsible person should be
  349.         identified as the security contact.  The means for reaching the
  350.         security contact should be made known to all users and should
  351.         be registered in public directories, and it should be easy for
  352.         computer emergency response centers to find contact information
  353.         at any time.
  354.  
  355.         The security contact should be familiar with the technology and
  356.         configuration of all systems at the site or should be able to
  357.         get in touch with those who have this knowledge at any time.
  358.         Likewise, the security contact should be pre-authorized to make
  359.         a best effort to deal with a security incident, or should be
  360.         able to contact those with the authority at any time.
  361.  
  362.    (5)  Sites and networks which are notified of security incidents
  363.         should respond in a timely and effective manner.  In the case
  364.         of penetrations or other violations, sites and networks should
  365.         allocate resources and capabilities to identify the nature of
  366.         the incident and limit the damage.  A site or network cannot be
  367.         considered to have good security if it does not respond to
  368.         incidents in a timely and effective fashion.
  369.  
  370.         If a violator can be identified, appropriate action should be
  371.         taken to ensure that no further violations are caused.  Exactly
  372.         what sanctions should be brought against a violator depend on
  373.         the nature of the incident and the site environment.  For
  374.         example, a university may choose to bring internal disciplinary
  375.         action against a student violator.
  376.  
  377.         Similarly, sites and networks should respond when notified of
  378.         security flaws in their systems.  Sites and networks have the
  379.         responsibility to install fixes in their systems as they become
  380.         available.
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Pethia, Crocker, & Fraser                                       [Page 7]
  395.  
  396. RFC 1281          Guidelines for the Secure Operation      November 1991
  397.  
  398.  
  399. A Bibliography of Computer and Network Security Related Documents
  400.  
  401. United States Public Laws (PL) and Federal Policies
  402.  
  403.    [1] P.L. 100-235, "The Computer Security Act of 1987", (Contained in
  404.        Appendix C of Citation No. 12, Vol II.), Jan. 8, 1988.
  405.  
  406.    [2] P.L. 99-474 (H.R. 4718), "Computer Fraud and Abuse Act of 1986",
  407.        Oct. 16, 1986.
  408.  
  409.    [3] P.L. 99-508 (H.R. 4952), "Electronic Communications Privacy Act
  410.        of 1986", Oct. 21, 1986.
  411.  
  412.    [4] P.L. 99-591, "Paperwork Reduction Reauthorization Act of 1986",
  413.        Oct. 30, 1986.
  414.  
  415.    [5] P.L. 93-579, "Privacy Act of 1984", Dec. 31, 1984.
  416.  
  417.    [6] "National Security Decision Directive 145", (Contained in
  418.        Appendix C of Citation No. 12, Vol II.).
  419.  
  420.    [7] "Security of Federal Automated Information Systems", (Contained
  421.        in Appendix C of Citation No. 12, Vol II.), Appendix III of,
  422.        Management of Federal Information Resources, Office of Management
  423.        and Budget (OMB), Circular A-130.
  424.  
  425.    [8] "Protection of Government Contractor Telecommunications",
  426.        (Contained in Appendix C of Citation No. 12, Vol II.), National
  427.        Communications Security Instruction (NACSI) 6002.
  428.  
  429. Other Documents
  430.  
  431.    [9] Secure Systems Study Committee, "Computers at Risk: Safe
  432.        Computing in the Information Age", Computer Science and
  433.        Technology Board, National Research Council, 2101 Constitution
  434.        Avenue, Washington, DC 20418, December 1990.
  435.  
  436.   [10] Curry, D., "Improving the Security of Your UNIX System", Report
  437.        No. ITSTD-721-FR-90-21, SRI International, 333 Ravenswood Ave.,
  438.        Menlo Park, CA, 94025-3493, April 1990.
  439.  
  440.   [11] Holbrook P., and J. Reynolds, Editors, "Site Security Handbook",
  441.        FYI 8, RFC 1244, CICNet, ISI, July 1991.
  442.  
  443.   [12] "Industry Information Protection, Vols. I,II,III", Industry
  444.        Information Security Task Force, President's National
  445.        Telecommunications Advisory Committee, June 1988.
  446.  
  447.  
  448.  
  449.  
  450. Pethia, Crocker, & Fraser                                       [Page 8]
  451.  
  452. RFC 1281          Guidelines for the Secure Operation      November 1991
  453.  
  454.  
  455.   [13] Jelen, G., "Information Security: An Elusive Goal", Report No.
  456.        P-85-8, Harvard University, Center for Information Policy
  457.        Research, 200 Akin, Cambridge, MA.  02138, June 1985.
  458.  
  459.   [14] "Electronic Record Systems and Individual Privacy", OTA-CIT-296,
  460.        Congress of the United States, Office of Technology Assessment,
  461.        Washington, D.C. 20510, June 1986.
  462.  
  463.   [15] "Defending Secrets, Sharing Data", OTA-CIT-310, Congress of the
  464.        United States, Office of Technology Assessment, Washington, D.C.
  465.        20510, October 1987.
  466.  
  467.   [16] "Summary of General Legislation Relating to Privacy and Computer
  468.        Security", Appendix 1 of, COMPUTERS and PRIVACY: How the
  469.        Government Obtains, Verifies, Uses and Protects Personal Data,
  470.        GAO/IMTEC-90-70BR, United States General Accounting Office,
  471.        Washington, DC 20548, pp.  36-40, August 1990.
  472.  
  473.   [17] Stout, E., "U.S. Geological Survey System Security Plan - FY
  474.        1990", U.S. Geological Survey ISD, MS809, Reston, VA, 22092, May
  475.        1990.
  476.  
  477. Security Considerations
  478.  
  479.    If security considerations had not been so widely ignored in the
  480.    Internet, this memo would not have been possible.
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Pethia, Crocker, & Fraser                                       [Page 9]
  507.  
  508. RFC 1281          Guidelines for the Secure Operation      November 1991
  509.  
  510.  
  511. Authors' Addresses
  512.  
  513.    Richard D. Pethia
  514.    Software Engineering Institute
  515.    Carnegie Mellon University
  516.    Pittsburgh, Pennsylvania 15213-3890
  517.  
  518.    Phone:  (412) 268-7739
  519.    FAX:    (412) 268-6989
  520.  
  521.    EMail:  rdp@cert.sei.cmu.edu
  522.  
  523.  
  524.    Stephen D. Crocker
  525.    Trusted Information Systems, Inc.
  526.    3060 Washington Road
  527.    Glenwood, Maryland 21738
  528.  
  529.    Phone:  (301) 854-6889
  530.    FAX:    (301) 854-5363
  531.  
  532.    EMail:  crocker@tis.com
  533.  
  534.  
  535.    Barbara Y. Fraser
  536.    Software Engineering Institute
  537.    Carnegie Mellon University
  538.    Pittsburgh, Pennsylvania 15213-3890
  539.  
  540.    Phone:  (412) 268-5010
  541.    FAX:    (412) 268-6989
  542.  
  543.    EMail:  byf@cert.sei.cmu.edu
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Pethia, Crocker, & Fraser                                      [Page 10]
  563.