Latest Draft

[Barbara Fraser <[e-mail]>]

Enclosed is a copy of the latest draft for the Internet Security
Policy Recommendations.  It and earlier versions are available
via anonymous ftp from cert.sei.cmu.edu (128.237.253.5).  They
are located in ~ftp/pub/ssphwg/spwg-policy*.

In addition, I have included some comments I received from Jeff
Schiller.  They bring out some points we should discuss at the
working group meeting.

Barbara Fraser
CERT/CC
[e-mail]
======================================
Comments from Jeff:
 
Subject: Some Comments On:  draft Security Policy


   ELABORATION 
   ...

   3) Site and network service providers are responsible for maintaining
      the security of the systems they operate.
   ...
      There are five elements of good local security:
   ...
    (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.

This is a very time-sharing oriented view. In many corners of the Internet
the majority use is moving away from time-sharing and toward single user
workstations. Some of these workstations are sufficiently inexpensive that
we are beginning to see them move into living spaces (ie. people's homes,
and college student's dormitory rooms). In this workstation environment it
is important to consider the privacy issues that go along with security logs.
For example the audit log in MIT's Kerberos authentication system allows you
to keep tabs on where certain students are physically located on campus.
For this reason we carefully protect these logs, and may limit how long
they are kept around.

    ...
    (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, identify the violator, 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.

	  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.

I have become aware of a trend where people are not willing to cooperate
because they feel that by cooperating they may help send a relatively
innocent (and typically young) person to jail. Not so long ago individual
sites had a large amount of discretion over the form of punishment that a
violator at their site would receive. For example if I was notified of a
security incident involving one of our students, I could exercise my
judgment (or more accurately MIT could exercise judgment through the Office
of the Dean for Student Affairs) about the level of punishment that the
student would receive. Today however if I cooperate with the FBI, then
punishment is out of our hands. I (and others I am aware of) are concerned
that what we may consider an innocent "probe" may be interpreted by certain
federal agencies as a "serious" crime. This is particularly true today when
most law enforcement is basically clueless about the Internet and react to
the level of pressure and emotion that they receive from the "victim" of
the security incident. Many time these victims have only seen an invalid
login attempt.

Already today I receive messages from government sites that demand that I
identify the culprit of a security incident. These messages often cite
section and verse explaining what a serious crime they are reporting.
Included is a log from a UNIX system showing invalid login attempts, but no
success. I really don't want the Internet Security Policy to be used as yet
another document cited in such messages.

			-Jeff

======================


 
	       Internet Security Policy Recommendations
 
                            WORKING DRAFT 

			   Richard Pethia
			    Steve Crocker
			   Barbara Fraser
			  February 26, 1991


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 Italian Center for
   Nuclear Research (CNUCE), and the Royal Signals and RADAR 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


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.  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.

   James Van Bokkelen
   April 2, 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.  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.

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

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) 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, 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 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, identify the violator, 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.
   
       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.

   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 more emphasis on security and more attention to the
       quality of the implementation of security within systems on the
       Internet.






                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.