home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1281.txt < prev    next >
Text File  |  1996-05-07  |  23KB  |  280 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Pethia Request for Comments: 1281                Software Engineering Institute                                                               S. Crocker                                        Trusted Information Systems, Inc.                                                                B. Fraser                                           Software Engineering Institute                                                            November 1991 
  8.  
  9.            Guidelines for the Secure Operation of the Internet 
  10.  
  11. Status of this Memo 
  12.  
  13.    This memo provides information for the Internet community.  It does    not specify an Internet standard.  Distribution of this memo is    unlimited. 
  14.  
  15. Preamble 
  16.  
  17.    The purpose of this document is to provide a set of guidelines to aid    in the secure operation of the Internet.  During its history, the    Internet has grown significantly and is now quite diverse.  Its    participants include government institutions and agencies, academic    and research institutions, commercial network and electronic mail    carriers, non-profit research centers and an increasing array of    industrial organizations who are primarily users of the technology.    Despite this dramatic growth, the system is still operated on a    purely collaborative basis.  Each participating network takes    responsibility for its own operation.  Service providers, private    network operators, users and vendors all cooperate to keep the system    functioning. 
  18.  
  19.    It is important to recognize that the voluntary nature of the    Internet system is both its strength and, perhaps, its most fragile    aspect.  Rules of operation, like the rules of etiquette, are    voluntary and, largely, unenforceable, except where they happen to    coincide with national laws, violation of which can lead to    prosecution.  A common set of rules for the successful and    increasingly secure operation of the Internet can, at best, be    voluntary, since the laws of various countries are not uniform    regarding data networking.  Indeed, the guidelines outlined below    also can be only voluntary.  However, since joining the Internet is    optional, it is also fair to argue that any Internet rules of    behavior are part of the bargain for joining and that failure to    observe them, apart from any legal infrastructure available, are    grounds for sanctions. 
  20.  
  21.  
  22.  
  23.  
  24.  
  25. Pethia, Crocker, & Fraser                                       [Page 1] 
  26.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  27.  
  28.  Introduction 
  29.  
  30.    These guidelines address the entire Internet community, consisting of    users, hosts, local, regional, domestic and international backbone    networks, and vendors who supply operating systems, routers, network    management tools, workstations and other network components. 
  31.  
  32.    Security is understood to include protection of the privacy of    information, protection of information against unauthorized    modification, protection of systems against denial of service, and    protection of systems against unauthorized access. 
  33.  
  34.    These guidelines encompass six main points.  These points are    repeated and elaborated in the next section.  In addition, a    bibliography of computer and network related references has been    provided at the end of this document for use by the reader. 
  35.  
  36.  Security Guidelines 
  37.  
  38.    (1)  Users are individually responsible for understanding and         respecting the security policies of the systems (computers and         networks) they are using.  Users are individually accountable         for their own behavior. 
  39.  
  40.    (2)  Users have a responsibility to employ available security         mechanisms and procedures for protecting their own data.  They         also have a responsibility for assisting in the protection of         the systems they use. 
  41.  
  42.    (3)  Computer and network service providers are responsible for         maintaining the security of the systems they operate.  They are         further responsible for notifying users of their security         policies and any changes to these policies. 
  43.  
  44.    (4)  Vendors and system developers are responsible for providing         systems which are sound and which embody adequate security         controls. 
  45.  
  46.    (5)  Users, service providers, and hardware and software vendors are         responsible for cooperating to provide security. 
  47.  
  48.    (6)  Technical improvements in Internet security protocols should be         sought on a continuing basis.  At the same time, personnel         developing new protocols, hardware or software for the Internet         are expected to include security considerations as part of the         design and development process. 
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Pethia, Crocker, & Fraser                                       [Page 2] 
  55.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  56.  
  57.  Elaboration 
  58.  
  59.    (1)  Users are individually responsible for understanding and         respecting the security policies of the systems (computers and         networks) they are using.  Users are individually accountable         for their own behavior. 
  60.  
  61.         Users are responsible for their own behavior.  Weaknesses in         the security of a system are not a license to penetrate or         abuse a system.  Users are expected to be aware of the security         policies of computers and networks which they access and to         adhere to these policies.  One clear consequence of this         guideline is that unauthorized access to a computer or use of a         network is explicitly a violation of Internet rules of conduct,         no matter how weak the protection of those computers or networks. 
  62.  
  63.         There is growing international attention to legal prohibition         against unauthorized access to computer systems, and several         countries have recently passed legislation that addresses the         area (e.g., United Kingdom, Australia).  In the United States,         the Computer Fraud and Abuse Act of 1986, Title 18 U.S.C.         section 1030 makes it a crime, in certain situations, to access         a Federal interest computer (federal government computers,         financial institution computers, and a computer which is one of         two or more computers used in committing the offense, not all of         which are located in the same state) without authorization.         Most of the 50 states in the U.S have similar laws. 
  64.  
  65.         Another aspect of this part of the policy is that users are         individually responsible for all use of resources assigned to         them, and hence sharing of accounts and access to resources is         strongly discouraged.  However, since access to resources is         assigned by individual sites and network operators, the         specific rules governing sharing of accounts and protection of         access is necessarily a local matter. 
  66.  
  67.    (2)  Users have a responsibility to employ available security         mechanisms and procedures for protecting their own data.  They         also have a responsibility for assisting in the protection of         the systems they use. 
  68.  
  69.         Users are expected to handle account privileges in a         responsible manner and to follow site procedures for the         security of their data as well as that of the system.  For         systems which rely upon password protection, users should         select good passwords and periodically change them.  Proper         use of file protection mechanisms (e.g., access control lists)         so as to define and maintain appropriate file access control 
  70.  
  71.  
  72.  
  73. Pethia, Crocker, & Fraser                                       [Page 3] 
  74.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  75.  
  76.          is also part of this responsibility. 
  77.  
  78.    (3)  Computer and network service providers are responsible for         maintaining the security of the systems they operate.  They are         further responsible for notifying users of their security         policies and any changes to these policies. 
  79.  
  80.         A computer or network service provider may manage resources on         behalf of users within an organization (e.g., provision of         network and computer services with a university) or it may         provide services to a larger, external community (e.g., a         regional network provider).  These resources may include host         computers employed by users, routers, terminal servers, personal         computers or other devices that have access to the Internet. 
  81.  
  82.         Because the Internet itself is neither centrally managed nor         operated, responsibility for security rests with the owners and         operators of the subscriber components of the Internet.         Moreover, even if there were a central authority for this         infrastructure, security necessarily is the responsibility of         the owners and operators of the systems which are the primary         data and processing resources of the Internet. 
  83.  
  84.         There are tradeoffs between stringent security measures at a         site and ease of use of systems (e.g., stringent security         measures may complicate user access to the Internet).  If a site         elects to operate an unprotected, open system, it may be         providing a platform for attacks on other Internet hosts while         concealing the attacker's identity.  Sites which do operate         open systems are nonetheless responsible for the behavior of         the systems' users and should be prepared to render assistance         to other sites when needed.  Whenever possible, sites should         try to ensure authenticated Internet access.  The readers are         directed to appendix A for a brief descriptive list of elements         of good security. 
  85.  
  86.         Sites (including network service providers) are encouraged to         develop security policies.  These policies should be clearly         communicated to users and subscribers.  The Site Security         Handbook (FYI 8, RFC 1244) provides useful information and         guidance on developing good security policies and procedures         at both the site and network level. 
  87.  
  88.    (4)  Vendors and system developers are responsible for providing         systems which are sound and which embody adequate security         controls. 
  89.  
  90.  
  91.  
  92.  
  93.  
  94. Pethia, Crocker, & Fraser                                       [Page 4] 
  95.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  96.  
  97.          A vendor or system developer should evaluate each system in         terms of security controls prior to the introduction of the         system into the Internet community.  Each product (whether         offered for sale or freely distributed) should describe the         security features it incorporates. 
  98.  
  99.         Vendors and system developers have an obligation to repair         flaws in the security relevant portions of the systems they         sell (or freely provide) for use in the Internet.  They are         expected to cooperate with the Internet community in         establishing mechanisms for the reporting of security flaws and         in making security-related fixes available to the community in         a timely fashion. 
  100.  
  101.    (5)  Users, service providers, and hardware and software vendors are         responsible for cooperating to provide security. 
  102.  
  103.         The Internet is a cooperative venture.  The culture and         practice in the Internet is to render assistance in security         matters to other sites and networks.  Each site is expected to         notify other sites if it detects a penetration in progress at         the other sites, and all sites are expected to help one another         respond to security violations.  This assistance may include         tracing connections, tracking violators and assisting law         enforcement efforts. 
  104.  
  105.         There is a growing appreciation within the Internet community         that security violators should be identified and held         accountable.  This means that once a violation has been detected,         sites are encouraged to cooperate in finding the violator and         assisting in enforcement efforts.  It is recognized that many         sites will face a trade-off between securing their sites as         rapidly as possible versus leaving their site open in the hopes         of identifying the violator.  Sites will also be faced with the         dilemma of limiting the knowledge of a penetration versus         exposing the fact that a penetration has occurred.  This policy         does not dictate that a site must expose either its system or         its reputation if it decides not to, but sites are encouraged         to render as much assistance as they can. 
  106.  
  107.    (6)  Technical improvements in Internet security protocols should be         sought on a continuing basis.  At the same time, personnel         developing new protocols, hardware or software for the Internet         are expected to include security considerations as part of the         design and development process. 
  108.  
  109.         The points discussed above are all administrative in nature,         but technical advances are also important.  Existing protocols 
  110.  
  111.  
  112.  
  113. Pethia, Crocker, & Fraser                                       [Page 5] 
  114.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  115.  
  116.          and operating systems do not provide the level of security that         is desired and feasible today.  Three types of advances are         encouraged: 
  117.  
  118.         (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. 
  119.  
  120.          (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. 
  121.  
  122.          (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. 
  123.  
  124. APPENDIX A 
  125.  
  126.    Five areas should be addressed in improving local security: 
  127.  
  128.    (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. 
  129.  
  130.    (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. 
  131.  
  132.    (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 
  133.  
  134.  
  135.  
  136. Pethia, Crocker, & Fraser                                       [Page 6] 
  137.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  138.  
  139.          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. 
  140.  
  141.    (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. 
  142.  
  143.         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. 
  144.  
  145.    (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. 
  146.  
  147.         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. 
  148.  
  149.         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. 
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163. Pethia, Crocker, & Fraser                                       [Page 7] 
  164.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  165.  
  166.  A Bibliography of Computer and Network Security Related Documents 
  167.  
  168. United States Public Laws (PL) and Federal Policies 
  169.  
  170.    [1] P.L. 100-235, "The Computer Security Act of 1987", (Contained in        Appendix C of Citation No. 12, Vol II.), Jan. 8, 1988. 
  171.  
  172.    [2] P.L. 99-474 (H.R. 4718), "Computer Fraud and Abuse Act of 1986",        Oct. 16, 1986. 
  173.  
  174.    [3] P.L. 99-508 (H.R. 4952), "Electronic Communications Privacy Act        of 1986", Oct. 21, 1986. 
  175.  
  176.    [4] P.L. 99-591, "Paperwork Reduction Reauthorization Act of 1986",        Oct. 30, 1986. 
  177.  
  178.    [5] P.L. 93-579, "Privacy Act of 1984", Dec. 31, 1984. 
  179.  
  180.    [6] "National Security Decision Directive 145", (Contained in        Appendix C of Citation No. 12, Vol II.). 
  181.  
  182.    [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. 
  183.  
  184.    [8] "Protection of Government Contractor Telecommunications",        (Contained in Appendix C of Citation No. 12, Vol II.), National        Communications Security Instruction (NACSI) 6002. 
  185.  
  186. Other Documents 
  187.  
  188.    [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. 
  189.  
  190.   [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. 
  191.  
  192.   [11] Holbrook P., and J. Reynolds, Editors, "Site Security Handbook",        FYI 8, RFC 1244, CICNet, ISI, July 1991. 
  193.  
  194.   [12] "Industry Information Protection, Vols. I,II,III", Industry        Information Security Task Force, President's National        Telecommunications Advisory Committee, June 1988. 
  195.  
  196.  
  197.  
  198.  Pethia, Crocker, & Fraser                                       [Page 8] 
  199.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  200.  
  201.    [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. 
  202.  
  203.   [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. 
  204.  
  205.   [15] "Defending Secrets, Sharing Data", OTA-CIT-310, Congress of the        United States, Office of Technology Assessment, Washington, D.C.        20510, October 1987. 
  206.  
  207.   [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. 
  208.  
  209.   [17] Stout, E., "U.S. Geological Survey System Security Plan - FY        1990", U.S. Geological Survey ISD, MS809, Reston, VA, 22092, May        1990. 
  210.  
  211. Security Considerations 
  212.  
  213.    If security considerations had not been so widely ignored in the    Internet, this memo would not have been possible. 
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239. Pethia, Crocker, & Fraser                                       [Page 9] 
  240.  RFC 1281          Guidelines for the Secure Operation      November 1991 
  241.  
  242.  Authors' Addresses 
  243.  
  244.    Richard D. Pethia    Software Engineering Institute    Carnegie Mellon University    Pittsburgh, Pennsylvania 15213-3890 
  245.  
  246.    Phone:  (412) 268-7739    FAX:    (412) 268-6989 
  247.  
  248.    EMail:  rdp@cert.sei.cmu.edu 
  249.  
  250.     Stephen D. Crocker    Trusted Information Systems, Inc.    3060 Washington Road    Glenwood, Maryland 21738 
  251.  
  252.    Phone:  (301) 854-6889    FAX:    (301) 854-5363 
  253.  
  254.    EMail:  crocker@tis.com 
  255.  
  256.     Barbara Y. Fraser    Software Engineering Institute    Carnegie Mellon University    Pittsburgh, Pennsylvania 15213-3890 
  257.  
  258.    Phone:  (412) 268-5010    FAX:    (412) 268-6989 
  259.  
  260.    EMail:  byf@cert.sei.cmu.edu 
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  Pethia, Crocker, & Fraser                                      [Page 10] 
  279.  
  280.