INTERNET-DRAFT Guidelines for the Secure Operation of the Internet Richard Pethia Steve Crocker Barbara Fraser March 18, 1991 Status of the Memo This draft document will be submitted to the RFC editor as an informational document. (Editor's comment: This statement may not be completely appropriate for this document. Guidance from the IAB is being sought.) Distribution of this memo is unlimited. Please send comments to spwg@nri.reston.va.us. PREAMBLE The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. Comments by Vinton G. Cerf, Vice President, Corporation for National Research Initiatives, and Chairman, Internet Engineering Task Force, and James Van Bokkelen, President, FTP Software, Inc., have been provided to further illuminate the history and issues involved in this policy. In the early 1970's, the "Internet" was a research project sponsored by the U.S. Defense Advanced Research Projects Agency (DARPA), to explore technology for interlinking packet switching networks. Even in its early phases, the exploration involved international participation, notably University College London and, later, the participants in the Atlantic Satellite Network (SATNET) which included the Norwegian Defense Research Establishment, The Norwegian Telecommunications Administration Research Establishment, the German Air and Space Research Establishment (DFVLR), the Royal Signals and RADAR Establishment (RSRE), and CNUCE, an institute of the Italian Research Council (CNR). In the ensuing fifteen years, the Internet has grown much larger and also more 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 players who are primarily users of the technology. Despite this dramatic growth, the system is still operated on a purely collaborative basis. Participating networks take responsibility for their own operation. Service providers, private network operators, users and vendors all cooperate to keep the system functioning. 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 whose violation 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 recommended guidelines outlined below can also only be voluntary. However, since joining the Internet is optional, it is also fair to argue that the Internet Rules of Behavior are part of the bargain for joining and that failure to observe, apart from any legal infrastructure available, are grounds for sanctions. Vinton G. Cerf October 1990 The following is an excerpt from "The Internet Oral Tradition", published as RFC 1173. Every host and network manager MUST be aware that the Internet as presently constituted is NOT secure. At the protocol level, much more effort has been put into interoperability, reliability and convenience than has been devoted to security, although this is changing. Recent events have made software developers and vendors more sensitive to security, in both configuration and the underlying implementation, but it remains to be demonstrated how much long-term effect this will have. Meanwhile, the existing system survives through the co-operation of all responsible individuals. Security is subjective; one site might view as idle curiosity what another would see as a hostile probe. Since ultimately the existence of the Internet depends on its usefulness to all members of the community, it is important for managers to be willing to accept and act on other sites' security issues, warning or denying access to offending users. The offended site, in turn, must be reasonable in its demands (someone who set off an alarm while idly seeing if the sendmail 'DEBUG' hole was closed on a 'sensitive' host probably should be warned, rather than prosecuted). Because Internet security issues may require that local management people either get in touch with any of their users, or deny an offending individual or group access to other sites, it is necessary that mechanisms exist to allow this. . . .In turn, the 'sensitive' sites MUST be aware that it is impossible in the long term to deny Internet access to crackers, disgruntled former employees, unscrupulous competitors or agents of other countries. Getting an offender flushed is at best a stop-gap, providing a breathing space of a day or an hour while the security holes he was attacking are closed. James Van Bokkelen April 2, 1990 INTRODUCTION These recommended 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. 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. These guidelines encompass six main points. These points are repeated and elaborated in the next section. In addition, an annotated bibliography of computer and network related references has been provided at the end of this document for use by the reader. - ----------------------------------------------------------------------- SECURITY GUIDELINES 1) Users are individually responsible for understanding and respecting the security rules of the systems they are using. Users are individually accountable for their own behavior. 2) Users have responsibility to use available mechanisms and procedures for protecting their own data, and they also have responsibility for assisting in the protection of the systems they use. 3) Site and network service providers are responsible for maintaining the security of the systems they operate. 4) Vendors and system developers are responsible for providing systems which are sound and have adequate security controls. 5) Users, service providers and hardware and software vendors are expected to cooperate in the provision of security. 6) Technical improvements in Internet security protocols should be sought on a continuing basis. At the same time, Internet security implications should be considered by personnel working on new protocols, hardware systems and software systems. ELABORATION 1) Users are individually responsible for understanding and respecting the security rules of the systems they are using. Users are individually accountable for their own behavior. 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 rules and adhere to them. One clear consequence is that breaking into computers is explicitly a violation of Internet rules of conduct, no matter how weak the protection is on those computers. 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 have similar laws. 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 left to them. 2) Users have responsibility to use available mechanisms and procedures for protecting their own data, and they also have responsibility for assisting in the protection of the systems they use. 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. This involves good password selection and maintenance. It also encompasses the proper use of file protections so as to maintain correct file access. 3) Site and network service providers are responsible for maintaining the security of the systems they operate. A 'site' is any organization that owns computers or network related resources. These resources may include host computers that users use, routers, terminal servers, personal computers or other devices that have access to the Internet. A site may be an end user of Internet services or a service provider such as a regional network. Primary responsibility for security necessarily rests with the owners and operators of the components of the Internet, that is, the host operators and network operators. The Internet itself is neither centrally managed nor operated, and hence there is no central authority for implementing or managing the security of the entire Internet. Moreover, even if there were a central authority, security necessarily is the responsibility of the people owning the data and systems involved, so local control is essential. There are tradeoffs between tight security at a site and usability of the systems. Tight security measures may make it more complicated for a user to access the Internet. If a site chooses to have open systems for the ease of use by its constituents, it also has a responsi- bility for the consequences of those open systems when they are exploited by unauthorized individuals. The readers are directed to appendix A for a descriptive list of elements of good security. To facilitate the adoption and implementation of good security practices at the site and network level, the Site Security Policy Handbook Working Group is developing a handbook with guidance on all of these matters. Sites and network operators are encouraged to review this material and use it freely. 4) Vendors and system developers are expected to provide systems which are sound and have adequate security controls. Vendors and system developers should evaluate systems in terms of security controls prior to the introduction of the system into the computing community. Products should be labeled according to security controls that are present. Vendors have a positive obligation to repair flaws in the security relevant portions of the systems they sell for use in the Internet. Vendors are also expected to cooperate with the Internet community as far as making security related fixes available to the entire community in a timely way. 5) Users, sites, networks and vendors are expected to provide mutual security assistance. 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. A site is expected to notify other sites if it sees a penetration in progress at the other sites, and sites are expected to help other sites respond to security violations. This may include tracing connections, tracking violators and assisting law enforcement efforts. 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 and limiting the knowledge of a penetration versus leaving their site open and/or 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. 6) Technical improvements in Internet security protocols should be sought on a continuing basis. At the same time, Internet security implications should be considered by personnel working on new protocols, hardware systems and software systems. The points discussed above are all administrative in nature, but technical advances are also important. The existing protocols and operating systems do not provide the level of security that is desired or that is possible. Three types of advances are encouraged. (i) Improvements 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 password protocols. At the same time, the user population is expanding to include a larger percentage of technically unsophisticated users. The defaults on delivered systems and the controls for administering security must be geared to this large and generally unsophisticated population. (ii) Security extensions to the protocol suite are needed. Candidate protocols which should be augmented to improve security include network management, routing, file transfer, telnet, mail, etc. (iii) Improvements in the design and implementation of operating systems 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: (i) 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. (ii) Adequate security controls must be implemented. At a minimum, this means controlling access to systems via passwords -- and instituting sound password management! -- and configuring the system to protect itself and the information within it. (iii) There must be a capability to monitor security compliance and respond to incidents involving violation of security. Logs of 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 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. (iv) 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. (v) 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. An Annotated Bibliography of Computer and Network Security Related Documents Public Laws (PL) and Federal Policies [1] P.L. 100-235, _T_h_e _C_o_m_p_u_t_e_r _S_e_c_u_r_i_t_y _A_c_t _o_f _1_9_8_7, + Jan. 8, 1988. [2] P.L. 99-474 (H.R. 4718), _C_o_m_p_u_t_e_r _F_r_a_u_d _a_n_d _A_b_u_s_e _A_c_t _o_f _1_9_8_6, Oct. 16, 1986. [3] P.L. 99-508 (H.R. 4952), _E_l_e_c_t_r_o_n_i_c _C_o_m_m_u_n_i_c_a_t_i_o_n_s _P_r_i_v_a_c_y _A_c_t _o_f _1_9_8_6, Oct. 21, 1986. [4] P.L. 99-591, _P_a_p_e_r_w_o_r_k _R_e_d_u_c_t_i_o_n _R_e_a_u_t_h_o_r_i_z_a_t_i_o_n _A_c_t _o_f _1_9_8_6, Oct. 30, 1986. [5] P.L. 93-579, _P_r_i_v_a_c_y _A_c_t _o_f _1_9_8_4, Dec. 31, 1984. [6] _N_a_t_i_o_n_a_l _S_e_c_u_r_i_t_y _D_e_c_i_s_i_o_n _D_i_r_e_c_t_i_v_e _1_4_5. + [7] "Security of Federal Automated Information Systems", + Appendix III of, _M_a_n_a_g_e_m_e_n_t _o_f _F_e_d_e_r_a_l _I_n_f_o_r_m_a_t_i_o_n _R_e_s_o_u_r_c_e_s, Office of Management and Budget (OMB), Cir- cular A-130. [8] _P_r_o_t_e_c_t_i_o_n _o_f _G_o_v_e_r_n_m_e_n_t _C_o_n_t_r_a_c_t_o_r _T_e_l_e_c_o_m_m_u_n_i_c_a_t_i_o_n_s, + National Communications Security Instruction (NACSI) 6002. Miscellaneous Documents [9] "Summary of General Legislation Relating to Privacy and Computer Security", Appendix 1 of, _C_O_M_P_U_T_E_R_S _a_n_d _P_R_I_V_A_C_Y: _H_o_w _t_h_e _G_o_v_e_r_n_m_e_n_t _O_b_t_a_i_n_s, _V_e_r_i_f_i_e_s, _U_s_e_s _a_n_d _P_r_o_t_e_c_t_s _P_e_r_s_o_n_a_l _D_a_t_a, GAO/IMTEC-90-70BR, United States General Accounting Office, Washington, DC 20548, pp. 36-40, Aug. 1990. _________________________ + Contained in Appendix C of Citation No. 13. [10] _D_e_f_e_n_d_i_n_g _S_e_c_r_e_t_s, _S_h_a_r_i_n_g _D_a_t_a, OTA-CIT-310, Congress of the United States, Office of Technology Assessment, Washington, D.C. 20510, Oct. 1987. [11] _E_l_e_c_t_r_o_n_i_c _R_e_c_o_r_d _S_y_s_t_e_m_s _a_n_d _I_n_d_i_v_i_d_u_a_l _P_r_i_v_a_c_y, OTA- CIT-296, Congress of the United States, Office of Tech- nology Assessment, Washington, D.C. 20510, June 1986. [12] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. I, Industry Information Security Task Force, President's National Telecommunications Advisory Committee, June 1988. [13] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. II, Annex C, "IIS Task Force Supporting Documents", (a compendium of documents related to computer security policy), Indus- try Information Security Task Force, President's National Telecommunications Advisory Committee, June 1988. [14] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. III, "Annotated Bibliography", President's National Telecommunications Advisory Committee, Industry Information Security Task Force, June 1988. [15] David A. Curry, _I_m_p_r_o_v_i_n_g _t_h_e _S_e_c_u_r_i_t_y _o_f _Y_o_u_r _U_N_I_X _S_y_s_t_e_m, Report No. ITSTD-721-FR-90-21, SRI Interna- tional, 333 Ravenswood Av., Menlo Park, CA, 94025-3493, April 1990. [16] G. F. Jelen, _I_n_f_o_r_m_a_t_i_o_n _S_e_c_u_r_i_t_y: _A_n _E_l_u_s_i_v_e _G_o_a_l, Report No. P-85-8, Harvard University, Center for Information Policy Research, 200 Akin, Cambridge, MA. 02138, June 1985. [17] Agne Lindberg, _E_l_e_c_t_r_o_n_i_c _D_o_c_u_m_e_n_t_s _a_n_d _E_l_e_c_t_r_o_n_i_c _S_i_g_- _n_a_t_u_r_e_s, (Publisher unknown). [18] Elain Stout, _U._S. _G_e_o_l_o_g_i_c_a_l _S_u_r_v_e_y _S_y_s_t_e_m _S_e_c_u_r_i_t_y _P_l_a_n - _F_Y _1_9_9_0, U.S. Geological Survey ISD, MS809, Res- ton, VA, 22092, May 1990.