Final Document

[Barbara Fraser <[e-mail]>]

Here's the final document as submitted to [e-mail].
A 'Status of the Memo' section has been added.  

Barbara

---------------------------------------------------------------------

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 [e-mail].



   
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.