Revised draft Security Policy
J Paul Holbrook <ph@cert.sei.cmu.edu> Wed, 28 November 1990 15:13 UTC
Received: from TAOS.CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa06281; 28 Nov 90 10:13 EST
Received: from localhost by taos.cert.sei.cmu.edu (5.65/2.3) id AA08337; Wed, 28 Nov 90 10:07:03 -0500
Message-Id: <9011281507.AA08337@taos.cert.sei.cmu.edu>
To: spwg@NRI.Reston.VA.US, ssphwg@cert.sei.cmu.edu, psrg-interest@venera.isi.edu, saag@tis.com
Subject: Revised draft Security Policy
Reply-To: crocker@tis.com, rdp@cert.sei.cmu.edu, ph@cert.sei.cmu.edu
Date: Wed, 28 Nov 1990 10:07:01 -0500
From: J Paul Holbrook <ph@cert.sei.cmu.edu>
[I'm sending this message out for Rich Pethia, who is away from the office -- Paul Holbrook] Dear colleagues, Below is a revised working draft of a proposed Internet security policy for your review and comment. This is a revision of the original October 9 draft. Following a series of security policy working group (spwg) working meetings, Steve Crocker and I put together the original draft based on our understanding of the work and inputs of the spwg members. The spwg gets the credit for the work, I'll take any blame for misunderstanding their views. This revision is the result of many useful comments. Thanks to all who took the time to respond. This draft will be discussed at the SPWG meeting at the IETF in Boulder. Please direct your comments, criticisms, or suggestions for change to me, and use the spwg@nri.reston.va.us list as a discussion forum for topics you feel should be widely discussed. Thanks in advance for your interest and comments. Rich Pethia [Note: if you want to compare this to the original draft, you can get it via anonymous FTP from cert.sei.cmu.edu as pub/ssphwg/spwg-policy-6oct.txt. This 28 November draft is also stored there as spwg-policy-28nov.txt. -- ph -------------------- ^L Internet Security Policy Recommendations WORKING DRAFT Richard Pethia Steve Crocker November 28, 1990 PREAMBLE 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 Italian Center for Nuclear Research (CNUCE), and the UK Radar and Signals Research Establishment (RSRE). 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 Internet Security Policy 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 INTRODUCTION This policy recommendation addresses 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. This policy has six main points. These points are repeated and elaborated in the next section. ----------------------------------------------------------------------- THE POLICY 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) Site and network service providers are responsible for maintaining the security of the systems they operate. 3) Vendors and system developers are responsible for providing systems which are sound and have adequate security controls. 4) 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. 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. 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. [Editors note: The following section is in transition. Originally, points 2, 3 and 4 were one composite point. These have been broken into three points, but the material in the original elaboration has not been divvied up. It is included here intact from the prior draft.] 2) Site and network operators are responsible for protecting their systems. 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, viz 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 five elements of good 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. (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, networks and vendors which are notified of security incidents should respond in a timely and effective manner. In the case of penetrations or other violations, sites, networks and vendors should allocate resources and capabilities to identify the nature of the incident, identify the violator, and limit the damage. A site, network or vendor cannot be considered to have good security if it does not respond to incidents in a timely and effective fashion. Similarly, sites, networks and vendors should respond when notified of security flaws in their systems. Vendors, in particular have a positive obligation to repair flaws in the security relevant portions of the systems they sell for use in the Internet. Sites and networks have the parallel responsibility to install fixes in their systems as they become available. 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. 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 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 more emphasis on security and more attention to the quality of the implementation of security within systems on the Internet. GLOSSARY <TBD> REFERENCES <TBD> James VanBokkelen wrote a very good memo on Internet security policy. Many of the points he makes are included above, but his statement is worth reading separately. It is included here for reference. This has been separately issued as RFC 1173. <Original comment was that this should be referenced and removed from this document.> The Internet Oral Tradition James VanBokkelen April 2, 1990 This is a summary of the 'oral tradition' of the Internet as regards the responsibilities of host and network managers, as I understand it. 1. Basic responsibilities: The Internet is a co-operative endeavor, and its usefulness depends on reasonable behavior from every user, host and router in the Internet. It follows that people in charge of the components of the Internet MUST be aware of their responsibilities and attentive to local conditions. Furthermore, they MUST be accessible via both Internet mail and telephone, and responsive to problem reports and diagnostic initiatives from other participants. Even local problems as simple and transient as system crashes or power failures may have widespread effects elsewhere in the net. Problems which require co-operation between two or more responsible individuals to diagnose and correct are relatively common. Likewise, the tools, access and experience needed for efficient analysis may not all exist at a single site. This communal approach to Internet management and maintenance is dictated by the present decentralized organizational structure. The structure, in turn, exists because it is inexpensive and responsive to diverse local needs. Furthermore, for the near term, it is our only choice; I don't see any prospect of either the government or private enterprise building a monolithic, centralized, ubiquitous "Ma Datagram" network provider in this century. 2. Responsibilities of network managers: One or more individuals are responsible for every IP net or subnet which is connected to the Internet. Their names, phone numbers and postal addresses MUST be supplied to the Internet NIC (or to the local or regional transit network's NIC) prior to the network's initial connection to the Internet, and updates and corrections MUST be provided in a timely manner for as long as the net remains connected. In order to adequately deal with problems that may arise, a network manager must have either: A. System management access privileges on every host and router connected to the local network, or: B. The authority and access to either power off, re-boot, physically disconnect or disable IP datagram forwarding to any individual host system that may be misbehaving. For all networks, a network manager capable of exercising this level of control MUST be accessible via telephone 8 hours a day, 5 days a week. For nets carrying transit traffic, a network manager SHOULD be accessible via telephone 24 hours a day. 3. Responsibilities of host system managers: Some individual must be responsible for every host connected to the Internet. This person MUST have the authority, access and tools necessary to configure, operate and control access to the system. For important timesharing hosts, primary domain name servers and mail relays or gateways, responsible individual(s) SHOULD be accessible via telephone 24 hours a day, 7 days a week. For less-important timesharing hosts or single-user PCs or workstations, the responsible individual(s) MUST be prepared for the possibility that their network manager may have to intervene in their absence, should the resolution of an Internet problem require it. 4. Postmaster@foo.bar.baz Every Internet host that handles mail beyond the local network MUST maintain a mailbox named 'postmaster'. In general, this should not simply forward mail elsewhere, but instead be read by a system maintainer logged in to the machine. This mailbox SHOULD be read at least 5 days a week, and arrangements MUST be made to handle incoming mail in the event of the absence of the normal maintainer. A machine's 'postmaster' is the normal point of contact for problems related to mail delivery. Because most traffic on the long-haul segments of the Internet is in the form of mail messages, a local problem can have significant effects elsewhere in the Internet. Some problems may be system-wide, such as disk or file system full, or mailer or domain name server hung, crashed or confused. Others may be specific to a particular user or mailing list (incorrect aliasing or forwarding, quota exceeded, etc.). In either case, the maintainer of a remote machine will normally send mail about delivery problems to 'postmaster'. Also, 'postmaster' is normally specified in the 'reply-to:' field of locally generated mail error messages (unable to deliver due to nonexistent user name, unable to forward, malformed header, etc). If this mailbox isn't read in a timely manner, significant quantities of mail may be lost or returned to its senders. 5. Problems and Resolutions Advances in network management tools may eventually make it possible for a network maintainer to detect and address most problems before they affect users, but for the present, day-to-day users of networking services represent the front line. No responsible individual should allow their 'dumb-question' filter to become too restrictive; reports of the form "I haven't gotten any mumblefrotz mail for a week... " or "I could get there this morning, but not now..." should always get timely attention. There are three basic classes of problems that may have network-wide scope: User-related, host-related and network-related. A. User-related problems can range from bouncing mail or uncivilized behavior on mailing lists to more serious issues like violation of privacy, break-in attempts or vandalism. B. Host-related problems may include mis-configured software, obsolete or buggy software and security holes. C. Network-related problems are most frequently related to routing: incorrect connectivity advertisements, routing loops and black holes can all have major impacts. Mechanisms are usually in place for handling failure of routers or links, but problems short of outright failure can also have severe effects. Each class of problem has its own characteristics. User-related problems can usually be solved by education, but system managers should be aware of applicable federal and state law as well; Privacy violations or 'cracking' attempts have always been grounds for pulling a user's account, but now they can also result in prosecution. Host-related problems are usually resolvable by re-configuration or upgrading the software, but sometimes the manufacturer needs to be made aware of a bug, or jawboned into doing something about it; Bugs that can't be fixed may be serious enough to require partial or total denial of service to the offending system. Similar levels of escalation exist for network-related problems, with the solution of last resort being ostracism of the offending net. 6. The Illusion of Security 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. Accordingly, Internet sites SHOULD NOT have 'general use' accounts, or 'open' (without password) terminal servers that can access the rest of the Internet. 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. 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.
- Revised draft Security Policy J Paul Holbrook