[Internet Security Guidelines I-D FROM: Steve Kent]

[James M Galvin <[e-mail]>]

This message speaks for itself.  Just for your information.

Jim

------- Forwarded Message

Message-ID: <[e-mail]>
From:       Steve Kent <[e-mail]>
To:         [e-mail], [e-mail]
Date:       Mon, 17 Jun 91 17:47:16 -0400
Subject:    Internet Security Guidelines I-D


	Here is my draft revision of this I-D.  As per IAB
instructions I am forwarding it to these lists, even though the next
step in the process lies with the Security AD. Paragraphs which I have
edited are distinguished by being flush left, vs. indented text
throughout the rest of the I-D.  I also have a few bracketed <>,
UPPERCASE comments embedde in the text, still to be resolved.

Steve
- --------------------------------------------

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.  During its history, the
Internet has grown significantly and is now quite diverse.  Its
participants include government institutions and agencies, academic
and research institutions, commercial network and electronic mail
carriers, non-profit research centers and an increasing array of
industrial players who are primarily users of the technology. Despite
this dramatic growth, the system is still operated on a purely
collaborative basis.  Each participating network takes responsibility
for its own operation.  Service providers, private network operators,
users and vendors all cooperate to keep the system functioning.

It is important to recognize that the voluntary nature of the Internet
system is both its strength and, perhaps, its most fragile aspect.
Rules of operation, like the rules of etiquette, are voluntary and,
largely, unenforceable, except where they happen to coincide with
national laws violation of which can lead to prosecution.  A common
set of rules for the successful and increasingly secure operation of
the Internet can, at best, be voluntary, since the laws of various
countries are not uniform regarding data networking.  Indeed, the
guidelines outlined below also can be only voluntary.  However, since
joining the Internet is optional, it is also fair to argue that any
Internet rules of behavior are part of the bargain for joining and
that failure to observe, apart from any legal infrastructure
available, are grounds for sanctions.





INTRODUCTION 

These guidelines address the entire Internet community,
consisting of users, hosts, local, regional, domestic and
international backbone networks, and vendors who supply operating
systems, routers, network management tools, workstations and other
network components.

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 policies of the systems (computers and networks) they
are using.  Users are individually accountable for their own behavior.
 
2) Users have a responsibility to employ available security
mechanisms and procedures for protecting their own data.  They
also have a responsibility for assisting in the protection of the
systems they use.
 
3) Computer 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 which embody 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, personnel developing
new protocols, hardware or software for the Internet are expected to
include security considerations as part of the design and development
process.

 
ELABORATION 
 
1) Users are individually responsible for understanding and respecting
   the security policies of the systems (computers and networks) they
   are using.  Users are individually accountable for their own behavior.
 
   Users are responsible for their own behavior. Weaknesses in the
   security of a system are not a license to penetrate or abuse a
   system.  Users are expected to be aware of the security policies
   of computers and networks which they access and to adhere to these
   policies.  One clear consequence of this guideline is that
   unauthorized access to a computer or use of a network is explicitly a
   violation of Internet rules of conduct, no matter how weak the
   protection of those computers or networks.
 
   There is growing international attention to legal prohibition
   against unauthorized access to computer systems, and several
   countries have recently passed legislation that addresses the area
   (e.g. United Kingdom, Australia).  In the United States, the
   Computer Fraud and Abuse Act of 1986, Title 18 U.S.C. section 1030
   makes it a crime, in certain situations, to access a Federal
   interest computer (federal government computers, financial
   institution computers, and a computer which is one of two or more
   computers used in committing the offense, not all of which are
   located in the same state) without authorization.  Most of the 50
   states in the U.S. have similar laws.
   
   Another aspect of this part of the policy is that users are
individually responsible for all use of resources assigned to them,
and hence sharing of accounts and access to resources is strongly
discouraged.  However, since access to resources is assigned by
individual sites and network operators, the specific rules governing
sharing of accounts and protection of access is necessarily a local
matter.
 
 
2) Users have a responsibility to employ available security
mechanisms and procedures for protecting their own data.  They
also have a responsibility for assisting in the protection of the
systems they use.

	Users are expected to handle account privileges in a
responsible manner and to follow site procedures for the security of
their data as well as that of the system.  For systems which rely
upon password protection, users should select good change passwords
and and periodically change them.  Proper use of file protection
mechanisms (e.g., access control lists) so as to define and maintain
appropriate file access control is also part of this responsibility.


3) Computer and network service providers are responsible for
maintaining the security of the systems they operate.

   A computer or network service provider may manage resources on
behalf of users within an organization e.g., provision of network and
computer services with a university, or it may provide services to a
larger, external community, e.g., a regional network provider.  These
resources may include host computers employed by users, routers,
terminal servers, personal computers or other devices that have
access to the Internet.

	Primary responsibility for security necessarily rests with
the owners and operators of the subscriber components of the
Internet, that is, host and local network administratrors.  Even the
Internet infrastructure itself, e.g., regional and national level
networks, is neither centrally managed nor operated, and hence there
is no central authority for implementing or managing the security of
the Internet.  Moreover, even if there were a central authority for
this infrastructure, security necessarily is the responsibility of
the owners and operators of the systems which are the primary data
storage and processing resources of the Internet, so local control is
essential.

	There are tradeoffs between stringent security measures at a
site and ease of use of systems, e.g., stringent security measures
may complicate user to access the Internet.  However, if a site
elects to operate an unprotected system to facillitate ease of use by
its constituents, it may expose other Internet subscribers to
increased risk of unauthorized access, by providing a platform from
which attacks may be launched while an attacker's identity is
concealed.  Readers are directed to appendix A for a brief,
descriptive list of elements of good security. <REFER TO SITE
SECURITY HANDBOOK INSTEAD, THIS LIST IS PRETTY BRIEF?>

   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. 

<SHOULD THIS RFC WAIT FOR THE SSPHWG RFC?>

4) Vendors and system developers are responsible for providing systems
   which are sound and which embody adequate security controls.

   A vendor or system developer should evaluate each system in terms
of security controls prior to the introduction of the system into the
Internet community.  Each product (whether offered for sale or freely
distributed) should describe the security features it incorporates.
Over time, vendors should submit products for evaluation of security
functionality and assurance, as government or independent commercial
security evaluation facilities come into existance [ISF?].

	Vendors and system developers have an obligation to repair
flaws in the security relevant portions of the systems they sell for
use in the Internet.  They are expected to cooperate with the
Internet community in establishing mechanisms for the reporting of
security flaws and in making security-related fixes available to the
community in a timely fashion.


5) Users, service providers and hardware and software vendors are
expected to cooperate in the provision of security.
 
	The Internet is a cooperative venture.  The culture and
practice in the Internet is to render assistance in security matters
to other sites and networks.  Each site is expected to notify other
sites if it detects a penetration in progress at the other sites, and
all sites are expected to help one another respond to security
violations.  This assistance may include tracing connections,
tracking violators and assisting law enforcement efforts.
 
	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 identifying the violator and assisting in
law enforcement efforts.  It is recognized that each site must
independently address the trade-off between securing the site 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.  <ISN'T TRADEOFF BETWEEN CLOSING A HOLE,
INDEPENDENT OF KEEPING QUIET, VS. KEEPING HOLE OPEN TO HELP TRACK
PENETRATOR WHILE KEEPING QUIET?  THIS IS NOT A GOOD WAY TO EXPRESS
THAT CONCETP> This policy does not require that a site must expose
either its system or its reputation, 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, personnel developing
new protocols, hardware or software for the Internet are expected to
include security considerations as part of the design and development
process.

	The points discussed above are all administrative in nature,
but technical advances are also important.   Existing protocols
and operating systems do not provide the level of security that is
desired and feasible today.  Three types of advances are encouraged:
 
 (i) Improvements should be made in the basic security mechanisms
already in place.  Password security is generally poor throughout the
Internet and can be improved markedly through the use of tools to
administer password assignment and through the use of better
authentication technology.  At the same time, the Internet user
population is expanding to include a larger percentage of technically
unsophisticated users.  Security defaults on delivered systems and
the controls for administering security must be geared to this
growing population.
 
 (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) The design and implementation of operating systems should be
improved to place more emphasis on security and pay more attention to
the quality of the implementation of security within systems on the
Internet.


 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
   						<IN NICs?>
       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,
       <LOGIN ATTEMPTS?>
       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
	      <A HYPHEN OR TWO HERE?>
       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
       			<ANOTHER NIC PLUG?>
       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

<THIS "ANNOTATED" BIBLIOGRAPHY CONTAINS NO ANNOTATION.  I SUGGEST
THAT WHOEVER CONTRIBUTED EACH ENTRY SHOULD PROVIDE 1-2 SENTENCES
DESCRIBING THE RELEVANCE OF THE ENTRY TO THIS DOCUMENT.>

           Public Laws (PL) and Federal Policies



[1]  P.L. 100-235, The Computer
Security Act of 1987, + Jan.
     8, 1988.


[2]  P.L. 99-474 (H.R. 4718), Computer Fraud
and  Abuse  Act
     of 1986, Oct. 16, 1986.


[3]  P.L.  99-508  (H.R.  4952),  Electronic 
Communications
     Privacy Act of 1986, Oct. 21, 1986.


[4]  P.L. 99-591, Paperwork
Reduction
Reauthorization Act of
     1986, Oct. 30, 1986.


[5]  P.L. 93-579, Privacy Act of 1984,
Dec. 31, 1984.


[6]  National Security
Decision Directive 145.  +


[7]  "Security of Federal Automated Information Systems",  +
     Appendix  III  of,  Management  of 
Federal Information
     Resources, Office of Management and Budget (OMB),  Cir-
     cular A-130.


[8]  Protection of
Government Contractor
Telecommunications,
     +  National Communications Security Instruction (NACSI)
     6002.


                     Miscellaneous Documents



[9]  "Summary of General Legislation Relating to Privacy and
     Computer   Security",  Appendix  1  of,  COMPUTERS  and
     PRIVACY: How the
Government Obtains,
Verifies, Uses and
     Protects   Personal  
Data,  GAO/IMTEC-90-70BR,  United
     States General Accounting Office, Washington, DC 20548,
     pp. 36-40,  Aug. 1990.
_________________________
+  Contained in Appendix C of Citation No. 13.













[10] Defending Secrets,
Sharing Data, OTA-CIT-310,  Congress
     of  the United States, Office of Technology Assessment,
     Washington, D.C. 20510, Oct. 1987.


[11] Electronic Record
Systems and Individual
Privacy,  OTA-
     CIT-296, Congress of the United States, Office of Tech-
     nology Assessment, Washington, D.C. 20510, June 1986.


[12] Industry  Information 
Protection,  Vol.  I,   Industry
     Information  Security  Task Force, President's National
     Telecommunications Advisory Committee, June 1988.


[13] Industry Information
Protection, 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] Industry Information
Protection, Vol.  III,  "Annotated
     Bibliography",  President's National Telecommunications
     Advisory Committee, Industry Information Security  Task
     Force, June 1988.


[15] David A. Curry, Improving the 
Security  of  Your  UNIX
     System,  Report  No.  ITSTD-721-FR-90-21,  SRI Interna-
     tional, 333 Ravenswood Av., Menlo Park, CA, 94025-3493,
     April 1990.


[16] G. F. Jelen, Information 
Security:  An  Elusive  Goal,
     Report  No.  P-85-8,  Harvard  University,  Center  for
     Information Policy Research, 200 Akin,  Cambridge,  MA.
     02138, June 1985.

<KILL THIS ONE IF YOU CAN'T GET A BETTER CITATION>
[17] Agne Lindberg, Electronic
Documents and Electronic Sig-
     natures, (Publisher unknown).


[18] Elain Stout, U.S.  Geological 
Survey  System  Security
     Plan - FY 1990, U.S. Geological Survey ISD, MS809, Res-
     ton, VA, 22092, May 1990.

<PROPOSED NEW ENTRY AND EXAMPLE ANNOTATION>

[19] Secure Systems Study Committee, Computers at Risk: Safe Computing
in the Information Age, Computer Science and Technology Board,
National Research Council, 2101 Constitution Avenue, Washington, DC
20418, December 1990.  This report highlights computer and network
security concerns and urges the development of a set of generally
accepcted system security practices.  It calls for the establishment
of a non-profit Information Security Foundation to perform evaluation
of computer and network security facilities of commercial products and
conduct research into security technology.



------- End of Forwarded Message