Received: from cunyvm.cuny.edu by NRI.NRI.Reston.VA.US id aa00975; 21 Feb 90 11:24 EST Received: from Sdsc.BITnet by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8769; Wed, 21 Feb 90 11:25:00 EST Date: Wed, 21 Feb 90 16:14:41 GMT From: loveep%SDSC.BITNET@CUNYVM.CUNY.EDU (E. Paul Love 619 534-5043) Message-Id: <900221161441.24801e65@Sds.Sdsc.Edu> Subject: Addition to the list To: spwg-request@nri.reston.va.us X-ST-Vmsmail-To: ST%"spwg-request@nri.reston.va.us" Status: O Please add Gerard Newman to the sec. mailing list. His address is: gkn@sds.sdsc.edu Thanks, Paul Love SDSC   Received: from psi.com by NRI.NRI.Reston.VA.US id aa01925; 21 Feb 90 12:07 EST Date: Wed, 21 Feb 90 11:18:12 -0500 From: schoff@psi.com (Marty Schoffstall) Received: by psi.com (5.61/2.1-Performance Systems International) id AA16533; Wed, 21 Feb 90 11:18:12 -0500 Message-Id: <9002211618.AA16533@psi.com> To: spwg-request@nri.reston.va.us Subject: please add Status: O schoff@psi.com thanks, marty   Received: from [128.127.25.100] by NRI.NRI.Reston.VA.US id aa02761; 21 Feb 90 13:10 EST Received: by vax.ftp.com id AA04553; Wed, 21 Feb 90 13:11:39 EST Date: Wed, 21 Feb 90 13:11:39 EST From: jbvb@vax.ftp.com (James Van Bokkelen) Message-Id: <9002211811.AA04553@vax.ftp.com> To: spwg-request@nri.reston.va.us Subject: Please add me to the list Status: O jbvb@ftp.com James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901   Received: from [128.127.25.100] by NRI.NRI.Reston.VA.US id aa02776; 21 Feb 90 13:12 EST Received: by vax.ftp.com id AA04566; Wed, 21 Feb 90 13:13:00 EST Message-Id: <9002211813.AA04566@vax.ftp.com> Date: Wed 21 Feb 90 13:13:31 From: jbvb@plug.ftp.com (James B. VanBokkelen) Reply-To: jbvb@vax.ftp.com To: spwg@nri.reston.va.us Subject: The 'responsibility' write up I promised I would do after IETF Status: O This is my 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-opeative endeavor, and its usefulness depends on reasonable behaviour from every user, host and router in the Internet. As such, 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 a co-operative endeavor to diagnose and correct are relatively common [[ Need to discuss types of problems: user-related, like vandalism, break-in attempts, uncivilized behaviour on mailing lists, etc; host-related, like security holes, mis-configured software, obsolete or buggy software; and network-related, like media problems, routing problems, etc.]] 2. Responsibilities of network managers: One or more individuals are responsible for every IP net or subnet which is conected 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 netowrk, or: B. The authority and access to either power off, re-boot, physically disconnect or disable routing to any individual host system that may be misbehaving. For stub 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 SHUOLD 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 accessable 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 possiblity 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 receives mail 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 of the traffic on 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'. If this isn't read in a timely manner, significant quantities of mail may be lost or returned to its senders. 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). jbvb 16-Feb-90   Received: from psi.com by NRI.NRI.Reston.VA.US id aa03092; 21 Feb 90 13:35 EST Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA17346; Wed, 21 Feb 90 12:46:25 -0500 Message-Id: <9002211746.AA17346@psi.com> To: jbvb@vax.ftp.com Cc: spwg@NRI.Reston.VA.US Subject: Re: The 'responsibility' write up I promised I would do after IETF In-Reply-To: Your message of Wed, 21 Feb 90 13:13:31 -0500. <9002211813.AA04566@vax.ftp.com> Date: Wed, 21 Feb 90 12:46:25 -0500 From: "Martin Lee Schoffstall" Status: O I think your on the right track. I suggest you add an additional section TerminalServers: DialupTerminalServers which provided generalized access to the Internet should MINIMALLY include a user authentication mechanism for users who have the right/need to use the Internet for appropriate purposes. This authentication mechanism should periodically be updated with revised passwords, etc. DialupTerminalServers without any mechanism should be restricted to "local" network(s). Marty   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa02391; 21 Feb 90 23:32 EST To: jbvb@vax.ftp.com cc: spwg@nri.reston.va.us, vcerf Subject: Re: The 'responsibility' write up I promised I would do after IETF In-reply-to: Your message of Wed, 21 Feb 90 13:13:31 -0500. <9002211813.AA04566@vax.ftp.com> Date: Wed, 21 Feb 90 23:31:03 -0500 From: vcerf@nri Message-ID: <9002212332.aa02391@NRI.NRI.Reston.VA.US> Status: O James, thanks for a very helpful and thought-provoking write-up. I take it you will massage a bit more in section one. This will make a handsome addition to host requirements and gateway requirements! Vint   Received: from [128.127.25.100] by NRI.NRI.Reston.VA.US id aa07227; 27 Feb 90 12:51 EST Received: by vax.ftp.com id AA25871; Tue, 27 Feb 90 12:18:04 EST Date: Tue, 27 Feb 90 12:18:04 EST From: jbvb@vax.ftp.com (James Van Bokkelen) Message-Id: <9002271718.AA25871@vax.ftp.com> To: schoff@psi.com Cc: spwg@NRI.Reston.VA.US In-Reply-To: "Martin Lee Schoffstall"'s message of Wed, 21 Feb 90 12:46:25 -0500 <9002211746.AA17346@psi.com> Subject: The 'responsibility' write up I promised I would do after IETF Status: O TerminalServers: DialupTerminalServers which provided generalized access to the Internet should MINIMALLY include a user authentication mechanism for users who have the right/need to use the Internet for appropriate purposes. This authentication mechanism should periodically be updated with revised passwords, etc. DialupTerminalServers without any mechanism should be restricted to "local" network(s). Marty Out of respect for my Internet "origins", I can't get behind a statement like that. Once, I was a turist, totally dependent on open terminal servers and the like for access to hosts where I could read frivolous mailing lists. FTP wouldn't exist in its present form if it weren't for turists (both founders and those hired later), and I know of at least one other vendor with similar ancestry. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901   Received: from mbunix.mitre.org by NRI.NRI.Reston.VA.US id aa09221; 27 Feb 90 15:56 EST Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Received: from localhost by ulana.mitre.org (4.0/SMI-4.0) id AA00640; Tue, 27 Feb 90 15:59:40 EST Message-Id: <9002272059.AA00640@ulana.mitre.org> To: James Van Bokkelen Cc: sra@mbunix.mitre.org, spwg@nri.reston.va.us Subject: Re: The 'responsibility' write up I promised I would do after IETF In-Reply-To: Your message of Tue, 27 Feb 90 12:18:04 -0500. <9002271718.AA25871@vax.ftp.com> Date: Tue, 27 Feb 90 15:59:39 -0500 From: sra@ulana.mitre.org Status: O Although I agree totally for the needs of turists I think the internet would be well served by creating an access control scheme such that legitimate users could be turists while persons having no predetermined need would be restricted to "local" networks. Stan Ames (gads does that mean that I agree with marty)   Received: from psi.com by NRI.NRI.Reston.VA.US id aa04815; 28 Feb 90 9:12 EST Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA10598; Wed, 28 Feb 90 08:08:41 -0500 Message-Id: <9002281308.AA10598@psi.com> To: jbvb@vax.ftp.com (James Van Bokkelen) Cc: schoff@psi.com, spwg@NRI.Reston.VA.US Subject: Re: The 'responsibility' write up I promised I would do after IETF In-Reply-To: Your message of Tue, 27 Feb 90 12:18:04 -0500. <9002271718.AA25871@vax.ftp.com> Date: Wed, 28 Feb 90 08:08:41 -0500 From: "Martin Lee Schoffstall" Status: O The world has changed, the original Internet used H316's then C/30's, the original Internet had static routing between lsi11 gateways, the original Internet only used hosts.txt. I don't want to return to those days. Marty --------- TerminalServers: DialupTerminalServers which provided generalized access to the Inter net should MINIMALLY include a user authentication mechanism for users who have the right/need to use the Internet for appropriate purposes . This authentication mechanism should periodically be updated with revised passwords, etc. DialupTerminalServers without any mechanism should be restricted to "local" network(s). Marty Out of respect for my Internet "origins", I can't get behind a statement like that. Once, I was a turist, totally dependent on open terminal servers and the like for access to hosts where I could read frivolous mailing lists. FTP wouldn't exist in its present form if it weren't for turists (both founders and those hired later), and I know of at least one other vendor with similar ancestry. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa05693; 2 Mar 90 6:27 EST To: sra@ulana.mitre.org cc: James Van Bokkelen , sra@mbunix.mitre.org, spwg@nri.reston.va.us, vcerf Subject: Re: The 'responsibility' write up I promised I would do after IETF In-reply-to: Your message of Tue, 27 Feb 90 15:59:39 -0500. <9002272059.AA00640@ulana.mitre.org> Date: Fri, 02 Mar 90 06:26:05 -0500 From: vcerf@nri Message-ID: <9003020627.aa05693@NRI.NRI.Reston.VA.US> Status: O I would much rather deliberately sanction tourists by explicit agreement with them than leave the system completely oblivious to visitors. Didn't MIT institute a policy like that on MIT-MC years ago? Vint PS. By "like that" I mean that you applied to MIT to explain what you had in mind to do on MC and MIT gave you an account if it agreed the proposed work made sense.   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa06424; 2 Mar 90 7:25 EST To: spwg@nri.reston.va.us Subject: Security and Network Management Workshop Date: Fri, 02 Mar 90 07:25:48 -0500 From: vcerf@nri Message-ID: <9003020725.aa06424@NRI.NRI.Reston.VA.US> Status: O ------- Forwarded Message Return-Path: Received: from csa1.lbl.gov by NRI.NRI.Reston.VA.US id aa00486; 1 Mar 90 16:37 EST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 1 Mar 90 13:34:39 PST Received: from venera.isi.edu by lbl.gov (4.1/1.39) id AA01501; Thu, 1 Mar 90 13:36:29 PST Posted-Date: Thu, 01 Mar 90 13:37:32 -0800 Received: from icarus.riacs.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 1 Mar 90 13:32:20 -0800 Received: from phun.riacs.edu by icarus.riacs.edu (5.59/2.1G) id AA03392; Thu, 1 Mar 90 13:33:43 PST Received: from localhost by phun.riacs.edu (5.59/2.0N) id AA03864; Thu, 1 Mar 90 13:37:34 PST Message-Id: <9003012137.AA03864@phun.riacs.edu> To: jif@venera.isi.edu To: nsd@riacs.edu Subject: Call for papers. IFIP WG6.6 International Workshop on Network Security and Management. September 26-28, 1990. Zurich, Switzerland Date: Thu, 01 Mar 90 13:37:32 -0800 From: leiner@riacs.edu FYI ________________________- Subject: The integration and interplay of security and management in computer networks, internetworks, and distributed systems. Network security functions and mechanisms are needed to protect network users from one another, from potential intruders or from the network itself, as well as to protect the network from abuse by legitimate or illegitimate users. Both network users and administrators need convenient and effective management mechanisms to control the use of these security functions and enforce desired security policies. In addition, the same security mechanisms and procedures are needed to protect the various functions and resources involved in the management of the network itself. Finally, network security and management schemes must provide basic support for the requirements of diverse distributed applications to allow their smooth inter-operation in an integrated system. The workshop will not address cryptographic algorithms, their implementation, and operating systems security issues, except as these subjects may relate to essential system aspects of specific network security management schemes. Schedule: Paper or position statement due: April 15, 1990 Information to participants mailed: June 1, 1990 Deadline for complete papers and final registration July 31, 1990 Tentative program mailed: August 15, 1990 For more information contact: Phil Janson Liba Svobodova pj@ibm.com svo@ibm.com IBM Research Division Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon, Switzerland ------- End of Forwarded Message   Received: from [128.127.25.100] by NRI.NRI.Reston.VA.US id aa08029; 2 Mar 90 10:09 EST Received: by vax.ftp.com id AA24463; Fri, 2 Mar 90 10:11:20 EST Date: Fri, 2 Mar 90 10:11:20 EST From: jbvb@vax.ftp.com (James Van Bokkelen) Message-Id: <9003021511.AA24463@vax.ftp.com> To: vcerf@NRI.Reston.VA.US Cc: spwg@NRI.Reston.VA.US In-Reply-To: vcerf@NRI.Reston.VA.US's message of Fri, 02 Mar 90 06:26:05 -0500 <9003020627.aa05693@NRI.NRI.Reston.VA.US> Subject: Re: The 'responsibility' write up I promised I would do after IETF Status: O My point is that I had no "proposed work". I wasn't a CS major, I wasn't a student, I wasn't an employee, I wasn't familiar with any language that had a working compiler on most of the machines I had accounts on. I had been given accounts by people I had never met face to face, mostly because I knew people who knew people. My original account on AI had come from a roommate, and it persisted throught various phases of access control and no access control (the new AI started out without it). The problem was how to get to the net via phone, and there I was using all sorts of means (but not TACs, I didn't know the right people). I was reading 'bandykin' and small quantities of personal mail. If it hadn't been possible for me and several other people now employed at FTP to get net access without any legitimate reason, as a total waste of resources, the company would not exist in its present form today. IMHO, it was an investment made by the then-current "Internet community" that paid off. Flame on: I would feel somewhat less strongly about this if I had any significant number of resumes coming in with useful TCP/IP experience. I don't. I have to get them somewhere, and random turists and hackers from all over the place have filled the bill, so far. They at least know how to use the utilities, and how to do e-mail (as opposed to many CS undergrads I see, who seem to mostly know how to write 2/3 of a complier for some dummy language their prof consed up, and average 2 comments per program file). Flame off. Also, I get the hackers and turists cheap by throwing in "legitimate" net access as part of the job... If everyone else really wants something like Marty's paragraph in the write-up, add it to my final draft (which should come around next week). The tolerance of unrestricted 'local-only' access is something I can accept, albeit without enthusiasm. jbvb   Received: from psi.com by NRI.NRI.Reston.VA.US id aa08577; 2 Mar 90 11:12 EST Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA22375; Fri, 2 Mar 90 10:00:23 -0500 Message-Id: <9003021500.AA22375@psi.com> To: vcerf@NRI.Reston.VA.US Cc: sra@ulana.mitre.org, James Van Bokkelen , sra@mbunix.mitre.org, spwg@NRI.Reston.VA.US, wls@psi.com, pullen@darpa.mil Subject: Re: The 'responsibility' write up I promised I would do after IETF In-Reply-To: Your message of Fri, 02 Mar 90 06:26:05 -0500. <9003020627.aa05693@NRI.NRI.Reston.VA.US> Date: Fri, 02 Mar 90 10:00:22 -0500 From: "Martin Lee Schoffstall" Status: O Vint, Those were the good old days. What we've seen is that academic institutions are getting tighter and tighter on giving user accounts on machines due to liability issues. A defense that Cornell might have mounted against a rather large group of organization in the Internet sueing them over Robert Morris was that as a student Robert had a legitimate purpose as a student. That defense would fold in many courts for a complete outsider, and this has been discussed and is discussed in many circles. Of course the commercial world as a whole never does this for the same libaility reasons and a few others. To reiterate my past posting, if you want tourists then you keep them inside your yard (network), don't let them roam around the entire neighborhood peeking in the windows. Marty --------- I would much rather deliberately sanction tourists by explicit agreement with them than leave the system completely oblivious to visitors. Didn't MIT institute a policy like that on MIT-MC years ago? Vint PS. By "like that" I mean that you applied to MIT to explain what you had in mind to do on MC and MIT gave you an account if it agreed the proposed work made sense.   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa11550; 2 Mar 90 16:05 EST To: jbvb@vax.ftp.com (James Van Bokkelen) cc: vcerf@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, vcerf Subject: Re: The 'responsibility' write up I promised I would do after IETF In-reply-to: Your message of Fri, 02 Mar 90 10:11:20 -0500. <9003021511.AA24463@vax.ftp.com> Date: Fri, 02 Mar 90 16:05:08 -0500 From: vcerf@nri Message-ID: <9003021605.aa11550@NRI.NRI.Reston.VA.US> Status: O jbvb I understand your feeling - and I even empathize with it. The problem is that the folks that foot the bill may not feel quite so generous as the system moves towards commercial mode of operation, especially if the costs become usage sensitive. You raise an important kind of infrastructural point, though, which ought not be lost. Can you work in something somewhere about the benefit of allowing tourism in the system? Vint   Received: from fl.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa11143; 20 Mar 90 11:42 EST Received: from localhost by fl.sei.cmu.edu (5.61/2.5) id AA10889; Tue, 20 Mar 90 11:44:14 -0500 Message-Id: <9003201644.AA10889@fl.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Cc: dkb@ecf.ncsl.nist.gov, mills@frog.ncsl.nist.gov Subject: Security Policy Working Group Date: Tue, 20 Mar 90 11:44:10 EST From: Richard Pethia Status: O To: SPWG list Below is a copy of the charter for the security policy working group. It contains a description of what I think we're trying to do, a set of objectives, and an outline of how we might go about meeting the objectives. Please review the charter and use this list to communicate your thoughts, critique, etc. Also, if you have ideas on issues you feel should be addressed in a security policy or have ideas on developing a policy framework, please share them with the group. I am calling a meeting for April 4th so as many of us as can attend have an opportunity to brainstorm the issues and work towards a policy framework. The meeting will be held somewhere near Washington DC, probably at NIST facilities in Gaithersberg MD. Please consider this note as an invitation to the meeting. If you are interested in attending, please let me know. I'll send details (exact place) on the meeting as soon as I have them (in a day or two). Hope to hear from you soon, Rich Pethia __________________________________________________________________________ Security Policy Working Group (spwg) Chairman: Rich Pethia rdp@sei.cmu.edu Mailing lists: spwg@nri.reston.va.us spwg-request@nri.reston.va.us Description of Working Group: The Security Policy Working Group is chartered to create a proposed Internet Security Policy for review, possible modification, and possible adoption by the Internet Activities Board. The SPWG will focus on both technical and adminstrative issues related to security, including integrity, authentication and confidentiality controls, and administration of hosts and networks. Objectives and Milestones: Among the issues to be considered in this working group are: o Responsibilities and obligations of users, data base administrators, host operators, and network managers. o Technical controls which provide protection from disruption of service, unauthorized modification of data, unauthorized disclosure of information and unauthorized use of facilities. o Organizational requirements for host, local network, regional network and backbone network operators. o Incident handling procedures for various Interenet components. Specific steps that will be taken are: 1) First Meeting: review and approve the charter making any necessary changes. Begin work on a policy framework. Assign work on detailing issues for each level of the hierarchy with first draft outline to be reviewed at the May IETF. 2) May IETF Meeting: revise and approve framework documents. Begin work on detailing areas of concern, technical issues, legal issues, and recommendations for each level of the hierarchy. 3) In the July 1990 timeframe, prepare first draft policy recommendation for working group review and modification. 4) In the early September 1990 timeframe, finalize draft policy and initiate review following standard RFC procedure.   Received: from mcsun.eu.net by NRI.NRI.Reston.VA.US id aa08371; 23 Mar 90 8:47 EST Received: by mcsun.EU.net with SMTP; Fri, 23 Mar 90 14:49:21 +0100 (MET) Received: from fganffm by unido.informatik.uni-dortmund.de with UUCP (UNIDO-2.0.1.e) via EUnet for mcsun.eu.net id AO13859; Fri, 23 Mar 90 14:46:25 +0100 From: Christian Riechmann Date: Fri, 23 Mar 90 13:30:44 +0100 Message-Id: <9003231230.AA04887@rufvax.ffm.fgan.de> Received: by rufvax.ffm.fgan.de; Fri, 23 Mar 90 13:30:44 +0100 To: spwg-request@NRI.Reston.VA.US Subject: Mailing-list Cc: bel@unido.informatik.uni-dortmund.de Status: O Would you please add my address (rie@rufvax.ffm.fgan.de) to the spwg-mailing list. Thanks Christian Riechmann   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa08713; 23 Mar 90 9:06 EST To: Christian Riechmann cc: spwg-request@NRI.Reston.VA.US Subject: Re: Mailing-list In-reply-to: Your message of Fri, 23 Mar 90 13:30:44 +0100. <9003231230.AA04887@rufvax.ffm.fgan.de> Date: Fri, 23 Mar 90 09:05:57 -0500 From: gvaudre@NRI.Reston.VA.US Message-ID: <9003230906.aa08713@NRI.NRI.Reston.VA.US> Status: O Christian, I have added you to the Security policy working group mailing list. spwg@nri.reston.va.us Greg Vaudreuil   Received: from tis.com by NRI.NRI.Reston.VA.US id aa13769; 26 Mar 90 12:40 EST Received: from RABBIT.TIS.COM by TIS.COM (5.61/1.34) id AA19341; Mon, 26 Mar 90 11:59:02 -0500 Message-Id: <9003261659.AA19341@TIS.COM> To: IETF@isi.edu, us-wg@nnsc.nsf.net, tcp-ip@nic.ddn.mil, spwg@NRI.Reston.VA.US, privacy-tf@venera.isi.edu Cc: iesg@NRI.Reston.VA.US, iab@NRI.Reston.VA.US, rdp@sei.cmu.edu, jkrey@isi.edu, ph@sei.cmu.edu, crocker@tis.com, Craig Partridge Subject: Announcing Site Security Policy Handbook Working Group (SSPHWG) Date: Mon, 26 Mar 90 11:58:52 -0500 From: crocker@tis.com Status: O A new working group has just been formed and will be meeting at the next IETF Meeting in Pittsburgh: Site Security Policy Handbook Working Group (SSPHWG) Co-Chairs: Paul Holbrook/CERT ph@SEI.CMU.EDU Joyce K. Reynolds/USC-ISI jkrey@ISI.EDU Mailing lists: General discussion: ssphwg@cert.sei.cmu.edu To subscribe: ssphwg-request@cert.sei.cmu.edu Description of Working Group: The Site Security Policy Handbook Working Group is chartered to create a handbook that will help sites develop their own site-specific policies and procedures to deal with computer security problems and their prevention. Objectives: Among the issues to be considered in this group are: 1) Establishing official site policy on computer security. 2) Establishing procedures to prevent security problems. 3) Establishing procedures to use when unauthorized activity occurs. 4) Establishing post-incident procedures. A specific schedule of activities will be worked out in the near future. This group will meet at the next IETF meeting, in Pittsburgh. The formation of this group provided an excellent opportunity for cooperation between areas within the new IESG structure. The User Services director (Craig Partridge) and the Security Area director (Steve Crocker) joined together to support the formation of this working group. After some discussion, it was agreed to place administrative responsibility for this group within the security area, but the work will be reported to and reviewed by both areas in parallel.   Received: from venera.isi.edu by NRI.NRI.Reston.VA.US id aa16428; 26 Mar 90 15:34 EST Received: by venera.isi.edu (5.61/5.61+local) id ; Mon, 26 Mar 90 09:41:21 -0800 Posted-Date: Mon, 26 Mar 90 11:58:52 -0500 Received-Date: Mon, 26 Mar 90 09:41:02 -0800 Received: from TIS.COM by venera.isi.edu (5.61/5.61+local) id ; Mon, 26 Mar 90 09:41:02 -0800 Received: from RABBIT.TIS.COM by TIS.COM (5.61/1.34) id AA19341; Mon, 26 Mar 90 11:59:02 -0500 Message-Id: <9003261659.AA19341@TIS.COM> To: IETF@venera.isi.edu, us-wg@nnsc.nsf.net, tcp-ip@nic.ddn.mil, spwg@NRI.Reston.VA.US, privacy-tf@venera.isi.edu Cc: iesg@NRI.Reston.VA.US, iab@NRI.Reston.VA.US, rdp@sei.cmu.edu, jkrey@venera.isi.edu, ph@sei.cmu.edu, crocker@tis.com, Craig Partridge Subject: Announcing Site Security Policy Handbook Working Group (SSPHWG) Date: Mon, 26 Mar 90 11:58:52 -0500 From: crocker@tis.com Status: O A new working group has just been formed and will be meeting at the next IETF Meeting in Pittsburgh: Site Security Policy Handbook Working Group (SSPHWG) Co-Chairs: Paul Holbrook/CERT ph@SEI.CMU.EDU Joyce K. Reynolds/USC-ISI jkrey@ISI.EDU Mailing lists: General discussion: ssphwg@cert.sei.cmu.edu To subscribe: ssphwg-request@cert.sei.cmu.edu Description of Working Group: The Site Security Policy Handbook Working Group is chartered to create a handbook that will help sites develop their own site-specific policies and procedures to deal with computer security problems and their prevention. Objectives: Among the issues to be considered in this group are: 1) Establishing official site policy on computer security. 2) Establishing procedures to prevent security problems. 3) Establishing procedures to use when unauthorized activity occurs. 4) Establishing post-incident procedures. A specific schedule of activities will be worked out in the near future. This group will meet at the next IETF meeting, in Pittsburgh. The formation of this group provided an excellent opportunity for cooperation between areas within the new IESG structure. The User Services director (Craig Partridge) and the Security Area director (Steve Crocker) joined together to support the formation of this working group. After some discussion, it was agreed to place administrative responsibility for this group within the security area, but the work will be reported to and reviewed by both areas in parallel.   Received: from [128.237.3.22] by NRI.NRI.Reston.VA.US id aa07007; 27 Mar 90 8:51 EST Received: from localhost by fl.sei.cmu.edu (5.61/2.5) id AA22370; Tue, 27 Mar 90 08:53:52 -0500 Message-Id: <9003271353.AA22370@fl.sei.cmu.edu> To: spwg-request@NRI.Reston.VA.US Subject: [tsudik%kamalot.usc.edu%oberon.usc.edu@usc.edu (Gene Tsudik): SPWG] Date: Tue, 27 Mar 90 08:53:50 EST From: Richard Pethia Status: O ------- Forwarded Message Received: from SEI.CMU.EDU by fl.sei.cmu.edu (5.61/2.5) id AA18418; Sat, 24 Mar 90 17:35:25 -0500 Received: from usc.edu by sei.cmu.edu (5.61/2.3) id AA09139; Sat, 24 Mar 90 17:35:17 -0500 Received: from kamalot.usc.edu by usc.edu (5.59/SMI-3.0DEV3) id AA24424; Sat, 24 Mar 90 14:35:15 PST Received: by kamalot.usc.edu (4.0/SMI-3.0DEV3) id AA00801; Sat, 24 Mar 90 14:35:13 PST Date: Sat, 24 Mar 90 14:35:13 PST From: tsudik%kamalot.usc.edu%oberon.usc.edu@usc.edu (Gene Tsudik) Message-Id: <9003242235.AA00801@kamalot.usc.edu> To: rdp@sei.cmu.edu Subject: SPWG Hi, I'd like to join the SPWG and get on the associated mailing list if possible. Thanks a lot, Gene Tsudik Computer Networks and Distributed Systems Lab USC LA CA ------- End of Forwarded Message   Received: from [128.237.3.22] by NRI.NRI.Reston.VA.US id aa07069; 27 Mar 90 8:58 EST Received: from localhost by fl.sei.cmu.edu (5.61/2.5) id AA22410; Tue, 27 Mar 90 09:00:49 -0500 Message-Id: <9003271400.AA22410@fl.sei.cmu.edu> To: spwg-request@NRI.Reston.VA.US Subject: [ellis@laura.psc.edu (James Ellis): Re: security groups] Date: Tue, 27 Mar 90 09:00:46 EST From: Richard Pethia Status: O Greg, I don't remember seeing Jim's name on the spwg list. It looks like he wants it there. ------- Forwarded Message Received: from SEI.CMU.EDU by fl.sei.cmu.edu (5.61/2.5) id AA21281; Mon, 26 Mar 90 17:03:47 -0500 Received: from laura.psc.edu by sei.cmu.edu (5.61/2.3) id AA14576; Mon, 26 Mar 90 17:03:41 -0500 Received: by laura.psc.edu (5.57/Ultrix2.4-C) id AA26744; Mon, 26 Mar 90 17:04:17 EST Date: Mon, 26 Mar 90 17:04:17 EST From: ellis@laura.psc.edu (James Ellis) Message-Id: <9003262204.AA26744@laura.psc.edu> To: rdp@sei.cmu.edu Subject: Re: security groups Thanks for the clarification. I am on the spwg list already I believe. That meeting sounds the most interesting although since the next IETF will be here in Pgh it might be good to try to go to the ssphwg meeting as well. I would appreciate being added to that mailing list. Thanks. Glad to hear the spwg meeting is a one-day affair. I would be interested in going down in the morning and coming back in the evening. Does the agenda start late enough to allow for this? How many folks to you expect to have there? ------- End of Forwarded Message   Received: from [128.237.3.22] by NRI.NRI.Reston.VA.US id aa07353; 27 Mar 90 9:18 EST Received: from localhost by fl.sei.cmu.edu (5.61/2.5) id AA22443; Tue, 27 Mar 90 09:19:18 -0500 Message-Id: <9003271419.AA22443@fl.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Cc: dkb@ecf.ncsl.nist.gov, shirey@gateway.mitre.org, mills@frog.ncsl.nist.gov, ellis@laura.psc.edu Subject: spwg meeting Date: Tue, 27 Mar 90 09:19:13 EST From: Richard Pethia Status: OR To: SPWG list Due to a large number of schedule conflicts, I am rescheduling the spwg meeting I had originally scheduled for April 4th. The first meeting of the spwg working group will be held on April 17th at the NRI facilities in Reston Va. The meeting will start at 9:30 AM and will probably continue until about 4:00 PM. As I said in my original message, the purpose of the meeting is to have as many of us as can attend brainstorm the issues and work towards a policy framework. The framework will be presented to a larger group at the May IETF meeting in Pittsburgh. A copy of the spwg charter and directions to NRI are appended to this note. Please let me know if you plan to attend the meeting. An accurate count of attendees will help us prepare for the meeting. Hope to hear from you soon, Rich Pethia __________________________________________________________________________ Security Policy Working Group (spwg) Chairman: Rich Pethia rdp@sei.cmu.edu Mailing lists: spwg@nri.reston.va.us spwg-request@nri.reston.va.us Description of Working Group: The Security Policy Working Group is chartered to create a proposed Internet Security Policy for review, possible modification, and possible adoption by the Internet Activities Board. The SPWG will focus on both technical and adminstrative issues related to security, including integrity, authentication and confidentiality controls, and administration of hosts and networks. Objectives and Milestones: Among the issues to be considered in this working group are: o Responsibilities and obligations of users, data base administrators, host operators, and network managers. o Technical controls which provide protection from disruption of service, unauthorized modification of data, unauthorized disclosure of information and unauthorized use of facilities. o Organizational requirements for host, local network, regional network and backbone network operators. o Incident handling procedures for various Interenet components. Specific steps that will be taken are: 1) First Meeting: review and approve the charter making any necessary changes. Begin work on a policy framework. Assign work on detailing issues for each level of the hierarchy with first draft outline to be reviewed at the May IETF. 2) May IETF Meeting: revise and approve framework documents. Begin work on detailing areas of concern, technical issues, legal issues, and recommendations for each level of the hierarchy. 3) In the July 1990 timeframe, prepare first draft policy recommendation for working group review and modification. 4) In the early September 1990 timeframe, finalize draft policy and initiate review following standard RFC procedure. ---------------------------------------------------------------------- The following is a list of hotels that are relatively close to NRI. Dulles airport is approximately 8 miles from NRI (the toll road is the only road to and from the airport). Sheraton International (approximately 1 mile to NRI) Sunrise Valley Drive (703) 620-9000 ($99.00/night corporate rate) >From Dulles to Hotel: Take Dulles toll road to Wiehle Avenue exit. Turn right onto Wiehle Avenue. Take 1st right onto Sunrise Valley Drive. The Sheraton is about 1 mile on the right. >From Hotel to NRI: Turn left onto Sunrise Valley Drive from hotel driveway. At the third light take a left onto Preston White Drive. Turn left at the drive marked 1895 Preston White Drive, NRI is located at the base of the drive. Parking is available on the side with access to NRI (Suite 100) through the front of the building. Courtyard By Marriott 533 Herndon Parkway (703) 478-9400 ($72.00/night corporate rate) >From Dulles to Hotel: Take Dulles toll road to the Herndon/Chantilly exit (exit 2), turn left at the end of the exit ramp. Turn right at the 3rd light onto Herndon Parkway. Hotel is one mile on the right. >From Hotel to NRI: Turn right out of Hotel. Turn right at 1st light onto Spring Street. Go through 1st light, take a right at the second light onto Wiehle Avenue, at the third light take a left onto Sunrise Valley Drive. Turn left at the first light onto Preston White Drive. Turn left at the drive marked 1895 Preston White Drive, NRI is located at the base of the drive. Parking is available on the side with access to NRI (Suite 100) through the front of the building. Days Inn 2200 Centerville Road (703) 471-6700 ($65.00/night corporate rate) Dulles to Hotel: Take Dulles toll road to the Herndon/Chantilly exit (exit 2), take a left at the end of the ramp. The hotel is just after the first light on your left. Hotel to NRI: Take a right out of the hotel. Go under the toll road. Take a left at the first light onto the toll road. Take the Wiehle Avenue exit and take a right at the end of the ramp. Turn left at the first light onto Sunrise Valley Drive and then take a left at the first light onto Preston White Drive. Turn left at the drive marked 1895 Preston White Drive, NRI is located at the base of the drive. Parking is available on the side with access to NRI (Suite 100) through the front of the building. ********** Directions to NRI if you are not staying at the above hotels: >From Washington Via Route 66: Take Route 66 west to the exit for the Dulles Access Road and the Route 267 Toll Road (50 cent toll). Follow Toll Road to Exit 5 at Hunter Mill Road (25 cent toll). At the bottom of the ramp turn left onto Hunter Mill Road. At the second stop light (T-intersection), turn right onto Sunrise Valley Drive and go eight-tenths of a mile to Preston White Drive. Turn right at the office park sign marked The Branches, then turn right at the drive marked 1895 Preston White Drive. Note: From 4 to 6:30 p.m., use of Route 66 is limited to cars carrying three or more people. >From National Airport: Upon exiting from the airport, follow signs to George Washington Parkway north, and take the Parkway north either to Route 495 or to Route 66 and follow directions given above. >From Dulles Airport: Take Dulles Access Road onto toll road toward Washington to the second Reston exit (Wiehle Avenue). Exit right onto Wiehle, then take next left at T-intersection stop light onto Sunrise Valley Drive. Go seven- tenths of a mile, through one stop light, and turn left at the office park sign marked The Branches, then turn right at the drive marked 1895 Preston White Drive.   Received: from nic.ddn.mil by NRI.NRI.Reston.VA.US id aa05551; 29 Mar 90 5:11 EST Received: from TIS.COM by NIC.DDN.MIL with TCP; Mon, 26 Mar 90 09:01:50 PST Received: from RABBIT.TIS.COM by TIS.COM (5.61/1.34) id AA19341; Mon, 26 Mar 90 11:59:02 -0500 Message-Id: <9003261659.AA19341@TIS.COM> To: IETF@isi.edu, us-wg@nnsc.nsf.net, tcp-ip@nic.ddn.mil, spwg@NRI.Reston.VA.US, privacy-tf@venera.isi.edu Cc: iesg@NRI.Reston.VA.US, iab@NRI.Reston.VA.US, rdp@sei.cmu.edu, jkrey@isi.edu, ph@sei.cmu.edu, crocker@tis.com, Craig Partridge Subject: Announcing Site Security Policy Handbook Working Group (SSPHWG) Date: Mon, 26 Mar 90 11:58:52 -0500 From: crocker@tis.com Status: O A new working group has just been formed and will be meeting at the next IETF Meeting in Pittsburgh: Site Security Policy Handbook Working Group (SSPHWG) Co-Chairs: Paul Holbrook/CERT ph@SEI.CMU.EDU Joyce K. Reynolds/USC-ISI jkrey@ISI.EDU Mailing lists: General discussion: ssphwg@cert.sei.cmu.edu To subscribe: ssphwg-request@cert.sei.cmu.edu Description of Working Group: The Site Security Policy Handbook Working Group is chartered to create a handbook that will help sites develop their own site-specific policies and procedures to deal with computer security problems and their prevention. Objectives: Among the issues to be considered in this group are: 1) Establishing official site policy on computer security. 2) Establishing procedures to prevent security problems. 3) Establishing procedures to use when unauthorized activity occurs. 4) Establishing post-incident procedures. A specific schedule of activities will be worked out in the near future. This group will meet at the next IETF meeting, in Pittsburgh. The formation of this group provided an excellent opportunity for cooperation between areas within the new IESG structure. The User Services director (Craig Partridge) and the Security Area director (Steve Crocker) joined together to support the formation of this working group. After some discussion, it was agreed to place administrative responsibility for this group within the security area, but the work will be reported to and reviewed by both areas in parallel.   Received: from tis.com by NRI.NRI.Reston.VA.US id aa06778; 30 Mar 90 8:47 EST Received: from RABBIT.TIS.COM by TIS.COM (5.61/1.34) id AA09252; Fri, 30 Mar 90 08:48:51 -0500 Message-Id: <9003301348.AA09252@TIS.COM> To: MHart@NRI.Reston.VA.US Cc: iesg@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, ssphwg@cert.sei.cmu.edu, privacy-tf@venera.isi.edu, jis@bitsy.mit.edu Return-Receipt-To: crocker@TIS.COM Subject: Security area monthly report Date: Fri, 30 Mar 90 08:48:36 -0500 From: crocker@tis.com Status: OR [Note to cc recipients: This is my portion of the IESG's input to the Internet monthly report. The cc list includes the security area working groups and the PSRG. Send me desires for adds or deletes.] Security Area Monthly Report ---------------------------- A new working group was formed to formulate a handbook for site security. This is the Site Security Policy Handbook Working Group (SSPHWG) co-chaired by Joyce Reynolds (ISI) and Paul Holbrook (CERT/SEI). Paul Holbrook/CERT ph@SEI.CMU.EDU Joyce K. Reynolds/USC-ISI jkrey@ISI.EDU General discussion: ssphwg@cert.sei.cmu.edu To subscribe: ssphwg-request@cert.sei.cmu.edu This group will hold its first meeting at the Pittsburgh IETF meeting in May. The Security Policy WG, chaired by Rich Pethia, plans to hold a one day meeting at the NRI in Reston, VA on April 17. It will also meet at the Pittsburgh IETF meeting. Implementations of Privacy Enhanced Mail based on RFCs 1113, 1114, and 1115, which came from the IRTF's Privacy and Security Research Group, are advancing. There will be a presentation and perhaps even a demo at the Pittsburgh IETF meeting.   Received: from [128.127.25.100] by NRI.NRI.Reston.VA.US id aa00427; 9 Apr 90 17:19 EDT Received: by vax.ftp.com id AA13154; Mon, 9 Apr 90 17:20:45 EDT Message-Id: <9004092120.AA13154@vax.ftp.com> Date: Mon 09 Apr 90 16:20:55 From: "James B. VanBokkelen" Reply-To: jbvb@vax.ftp.com To: spwg@NRI.Reston.VA.US Subject: A revised draft of the 'responsibility' write up Status: OR 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 behaviour 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 possiblity 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 behaviour 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. jbvb 02-Apr-90   Received: from mbunix.mitre.org by NRI.NRI.Reston.VA.US id aa14388; 13 Apr 90 15:28 EDT Message-Id: <9004131930.AA23103@mbunix.mitre.org> Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org To: Richard Pethia Cc: spwg@NRI.Reston.VA.US, dkb@bogus.ncsl.nist.gov, shirey@gateway.mitre.org, mills@frog.ncsl.nist.gov, ellis@laura.psc.edu, jdj@mbunix.mitre.org Subject: Re: spwg meeting In-Reply-To: Your message of Tue, 27 Mar 90 09:19:13 -0500. <9003271419.AA22443@fl.sei.cmu.edu> Date: Fri, 13 Apr 90 15:30:55 EDT From: "Joel D. Jacobs" Status: OR I intend to be there on the 17th. Have there been any changes to the agenda or other info? Joel D. Jacobs   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa05611; 18 Apr 90 9:01 EDT To: Brad Tipler cc: spwg-request@NRI.Reston.VA.US Subject: Re: Addition to distribution list In-reply-to: Your message of Wed, 18 Apr 90 08:12:37 -0400. <9004181212.AA06078@crc.skl.dnd.ca> Date: Wed, 18 Apr 90 09:01:07 -0400 From: gvaudre@NRI.Reston.VA.US Message-ID: <9004180901.aa05611@NRI.NRI.Reston.VA.US> Status: O You have been added to the spwg@nri.reston.va.us mailing list. Greg V.   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa05803; 19 Apr 90 9:08 EDT To: lance hoffman cc: spwg-request@NRI.Reston.VA.US, gvaudre@NRI.Reston.VA.US Subject: Re: Please put me on sec policy working group In-reply-to: Your message of Wed, 18 Apr 90 22:59:09 -0400. <9004190259.AA09260@seas.gwu.edu> Date: Thu, 19 Apr 90 09:08:43 -0400 From: gvaudre@NRI.Reston.VA.US Message-ID: <9004190908.aa05803@NRI.NRI.Reston.VA.US> Status: O You have been added to the spwg mailing list. Greg Vaudreuil   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa05820; 19 Apr 90 9:09 EDT To: Farokh Deboo cc: spwg-request@NRI.Reston.VA.US, gvaudre@NRI.Reston.VA.US Subject: Re: Addition Request In-reply-to: Your message of Wed, 18 Apr 90 19:46:12 -0700. <9004190246.AA24854@interlink.com> Date: Thu, 19 Apr 90 09:09:43 -0400 From: gvaudre@NRI.Reston.VA.US Message-ID: <9004190909.aa05820@NRI.NRI.Reston.VA.US> Status: O "spwg-request@interlink.com" has been added as an exploder to the spwg@NRI.reston.va.us mailing list. Greg Vaudreuil   Received: from tis.com by NRI.NRI.Reston.VA.US id aa12177; 27 Apr 90 15:41 EDT Received: from HAPPY.TIS.COM by TIS.COM (5.61/1.34) id AA15990; Fri, 27 Apr 90 14:58:17 -0400 Message-Id: <9004271858.AA15990@TIS.COM> To: MHart@NRI.Reston.VA.US Cc: iesg@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, ssphwg@cert.sei.cmu.edu, privacy-interest@venera.isi.edu, awg@bitsy.mit.edu Subject: Security area monthly report -- April 1990 Date: Fri, 27 Apr 90 14:56:29 -0400 From: crocker@tis.com Status: O [Note to cc recipients: This is my portion of the IESG's input to the Internet monthly report. The cc list includes the security area working groups and the PSRG. Send me desires for adds or deletes.] Security Area Monthly Report ---------------------------- The security area has working groups in authentication, security policy and site security policy handbook. The Authentication Working Group covers both IP authentication and SNMP authentication. The security area also coordinates security matters with other IETF areas and with the IRTF Privacy and Security Research Group. Authentication (IP and SNMP): Jeff Schiller, Chuck Davin, Jim Galvin, and Keith McCloghrie The SNMP documents have been reviewed by the PSRG and informal comments have been submitted to the authors. All three documents will be available at the Pittsburgh meeting for review during the SNMP Authentication Working Group Meeting. Security Policy: Rich Pethia The SPWG met on April 17 at NRI facilities. The meeting was attended by 13 IETF members who focused on developing an: Internet Security Policy Development Framework. The purpose of the framework is to give the working group a focal point to use when identifying policy issues and deciding policy content. The framework contains the following major sections: -Introduction: definitions, scope of policy, applicability, authority, focus and emphasis. -Inventory of existing policies: existing policies, directives, laws that may impact Internet security policy. -Needed Policy: what policies are needed and how should they be produced. -Security Services: what specific Internet services should be covered and what is the policy in each area. -Certification and Accreditation: who are the "authorities", what process is used to certify individual network components, how is a collection of components accreditated. -Security administration and responsibilities: how is the security policy communicated, administered. This framework will be presented to the SPWG working group at the May IETF meeting and assignments to work specific areas will be made at that time. Site Security Policy Handbook: Joyce Reynolds and Paul Holbrook The SSPHWG will be meeting May 2nd at the Pittsburgh IETF. The agenda will include: 1) Discussion on current security policy and relationship to the Security Policy Working Group (SPWG). 2) Goals and directions of the SSPHWG (strawman proposal by J. Paul Holbrook). 3) Structure and organization of handbook. 4) Timeframe for writing and submission for publication of the handbook. 5) Review of plans/action items for next round of meetings. a) Next meeting in Los Angeles, Tuesday, June 12th at USC/Information Sciences Institute. b) Next IETF meeting in August at University of British Columbia. Privacy Enhanced Mail: Steve Kent and Ken Rossen Privacy enhanced mail will be presented at the IETF meeting in Pittsburgh. Details are being worked out for the release of the software to the PSRG and later to the Internet community as a whole.   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa12607; 27 Apr 90 16:20 EDT Received: from TIS.COM by cert.sei.cmu.edu (5.61/2.2) id AA06516; Fri, 27 Apr 90 15:44:33 -0400 Received: from HAPPY.TIS.COM by TIS.COM (5.61/1.34) id AA15990; Fri, 27 Apr 90 14:58:17 -0400 Message-Id: <9004271858.AA15990@TIS.COM> To: MHart@NRI.Reston.VA.US Cc: iesg@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, ssphwg@cert.sei.cmu.edu, privacy-interest@venera.isi.edu, awg@bitsy.mit.edu Subject: Security area monthly report -- April 1990 Date: Fri, 27 Apr 90 14:56:29 -0400 From: crocker@tis.com Status: O [Note to cc recipients: This is my portion of the IESG's input to the Internet monthly report. The cc list includes the security area working groups and the PSRG. Send me desires for adds or deletes.] Security Area Monthly Report ---------------------------- The security area has working groups in authentication, security policy and site security policy handbook. The Authentication Working Group covers both IP authentication and SNMP authentication. The security area also coordinates security matters with other IETF areas and with the IRTF Privacy and Security Research Group. Authentication (IP and SNMP): Jeff Schiller, Chuck Davin, Jim Galvin, and Keith McCloghrie The SNMP documents have been reviewed by the PSRG and informal comments have been submitted to the authors. All three documents will be available at the Pittsburgh meeting for review during the SNMP Authentication Working Group Meeting. Security Policy: Rich Pethia The SPWG met on April 17 at NRI facilities. The meeting was attended by 13 IETF members who focused on developing an: Internet Security Policy Development Framework. The purpose of the framework is to give the working group a focal point to use when identifying policy issues and deciding policy content. The framework contains the following major sections: -Introduction: definitions, scope of policy, applicability, authority, focus and emphasis. -Inventory of existing policies: existing policies, directives, laws that may impact Internet security policy. -Needed Policy: what policies are needed and how should they be produced. -Security Services: what specific Internet services should be covered and what is the policy in each area. -Certification and Accreditation: who are the "authorities", what process is used to certify individual network components, how is a collection of components accreditated. -Security administration and responsibilities: how is the security policy communicated, administered. This framework will be presented to the SPWG working group at the May IETF meeting and assignments to work specific areas will be made at that time. Site Security Policy Handbook: Joyce Reynolds and Paul Holbrook The SSPHWG will be meeting May 2nd at the Pittsburgh IETF. The agenda will include: 1) Discussion on current security policy and relationship to the Security Policy Working Group (SPWG). 2) Goals and directions of the SSPHWG (strawman proposal by J. Paul Holbrook). 3) Structure and organization of handbook. 4) Timeframe for writing and submission for publication of the handbook. 5) Review of plans/action items for next round of meetings. a) Next meeting in Los Angeles, Tuesday, June 12th at USC/Information Sciences Institute. b) Next IETF meeting in August at University of British Columbia. Privacy Enhanced Mail: Steve Kent and Ken Rossen Privacy enhanced mail will be presented at the IETF meeting in Pittsburgh. Details are being worked out for the release of the software to the PSRG and later to the Internet community as a whole.   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa03511; 7 May 90 15:53 EDT To: Richard Pethia cc: spwg-request@NRI.Reston.VA.US, gvaudre@NRI.Reston.VA.US Subject: Re: ["Jeffrey J. Carpenter": Please add me to ISP] In-reply-to: Your message of Mon, 07 May 90 15:37:43 -0400. <9005071937.AA12751@poohbah.cert.sei.cmu.edu> Date: Mon, 07 May 90 15:53:09 -0400 From: gvaudre@NRI.Reston.VA.US Message-ID: <9005071553.aa03511@NRI.NRI.Reston.VA.US> Status: O Rich, I plan to add the names of the attendees to the mailing list... This may take some time however. I'm temporarily swamped. For now I am just adding direct requests. Greg V.   From: Greg Vaudreuil Date: Thu, 17 May 90 15:25:58 EDT Org: Corp. for National Research Initiatives Phone: (703) 620-8990 ; Fax: (703) 620-0913 X-Mailer: Mail User's Shell (6.5 4/17/89) To: rdp@sei.cmu.edu Subject: Attendee list of SPWG at PSC Cc: spwg@NRI.Reston.VA.US Message-ID: <9005171526.aa15495@NRI.NRI.Reston.VA.US> Status: O Those attendees not already on the mailing list have been added. Greg V. Stan Ames sra@mbunix.mitre.org Tom Bajzek twb@andrew.cmu.edu Alison Brown alison@maverick.osc.edu Jeffrey S. Carpenter jjc@unix.cis.pitt.edu Vinton Cerf vcerf@NRI.Reston.VA.US Richard Colella colella@osi3.ncsl.nist.gov Steve Crocker crocker@tis.com James Davin jrd@ptt.lcs.mit.edu Hunaid Engineer hunaid@opus.cray.com James Galvin galvin@tis.com Ella Gardner epg@gateway.mitre.org Tony Hain hain@nmfecc.arpa Robert Hoffman hoffman@cs.pitt.edu Paul Holbrook ph@SEI.CMU.EDU Greg Hollingsworth gregh@mailer.jhuapl.edu Phil Karn Karn@Thumper.Bellcore.Com Tracy Laquey tracy@emx.utexas.edu Keith McCloghrie sytek!kzm@hplabs.hp.com Gerald K Newman gkn@sds.sdsc.edu Lee Oattes oattes@utcs.utoronto.ca David Perkins dave_perkins@3com.com Marsha Perrott mlpt@andrew.emu.edu Richard Pethia rdp@sei.cmu.edu Ted Pike tgp@sei.cmu.edu Paul Pomes paul_pomes@uiuc.edu Joyce Reynolds jkrey@venera.isi.edu Robert J. Reschly Jr. reschly@brl.mil Milt Roselinsky cmcvax!milt@hub.vcsb.edu Jonathan Saperia saperia%tcpjon@decwrl.dec.com Robert W. Shirey shirey@mitre.org Tim Seaver tas@mcnc.org Michael StJohns stjohns@umd5.umd.edu Cal Thixton cthixton@next.com C. Philip Wood cpw@lanl.gov Sze-Ying Wuu wuu@nisc.junc.net 1   From: Greg Vaudreuil Date: Thu, 17 May 90 15:25:58 EDT Org: Corp. for National Research Initiatives Phone: (703) 620-8990 ; Fax: (703) 620-0913 X-Mailer: Mail User's Shell (6.5 4/17/89) To: rdp@sei.cmu.edu Subject: Attendee list of SPWG at PSC Cc: spwg@NRI.Reston.VA.US Message-ID: <9005171526.aa15495@NRI.NRI.Reston.VA.US> Status: O Those attendees not already on the mailing list have been added. Greg V. Stan Ames sra@mbunix.mitre.org Tom Bajzek twb@andrew.cmu.edu Alison Brown alison@maverick.osc.edu Jeffrey S. Carpenter jjc@unix.cis.pitt.edu Vinton Cerf vcerf@NRI.Reston.VA.US Richard Colella colella@osi3.ncsl.nist.gov Steve Crocker crocker@tis.com James Davin jrd@ptt.lcs.mit.edu Hunaid Engineer hunaid@opus.cray.com James Galvin galvin@tis.com Ella Gardner epg@gateway.mitre.org Tony Hain hain@nmfecc.arpa Robert Hoffman hoffman@cs.pitt.edu Paul Holbrook ph@SEI.CMU.EDU Greg Hollingsworth gregh@mailer.jhuapl.edu Phil Karn Karn@Thumper.Bellcore.Com Tracy Laquey tracy@emx.utexas.edu Keith McCloghrie sytek!kzm@hplabs.hp.com Gerald K Newman gkn@sds.sdsc.edu Lee Oattes oattes@utcs.utoronto.ca David Perkins dave_perkins@3com.com Marsha Perrott mlpt@andrew.emu.edu Richard Pethia rdp@sei.cmu.edu Ted Pike tgp@sei.cmu.edu Paul Pomes paul_pomes@uiuc.edu Joyce Reynolds jkrey@venera.isi.edu Robert J. Reschly Jr. reschly@brl.mil Milt Roselinsky cmcvax!milt@hub.vcsb.edu Jonathan Saperia saperia%tcpjon@decwrl.dec.com Robert W. Shirey shirey@mitre.org Tim Seaver tas@mcnc.org Michael StJohns stjohns@umd5.umd.edu Cal Thixton cthixton@next.com C. Philip Wood cpw@lanl.gov Sze-Ying Wuu wuu@nisc.junc.net 1   Received: from vax.ftp.com by NRI.NRI.Reston.VA.US id aa13818; 24 May 90 16:15 EDT Received: by vax.ftp.com id AA06770; Thu, 24 May 90 16:13:23 EDT Date: Thu, 24 May 90 16:13:23 EDT From: James Van Bokkelen Message-Id: <9005242013.AA06770@vax.ftp.com> To: spwg@NRI.Reston.VA.US Subject: Re: The 'responsibility' write up I promised I would do after IETF Status: O I posted it a second time, more or less finished, and got no comment. Is the consensus that it belongs here, or in user-doc? jbvb   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa16274; 24 May 90 19:34 EDT To: James Van Bokkelen cc: spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: The 'responsibility' write up I promised I would do after IETF In-reply-to: Your message of Thu, 24 May 90 16:13:23 -0400. <9005242013.AA06770@vax.ftp.com> Date: Thu, 24 May 90 19:33:24 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9005241934.aa16274@NRI.NRI.Reston.VA.US> Status: O jbvb, I would put it into a separate RFC for all to read and reference it! Vint   Received: from tis.com by NRI.NRI.Reston.VA.US id aa01533; 24 May 90 23:31 EDT Received: from SOL.TIS.COM by TIS.COM (5.61/1.34) id AA29356; Thu, 24 May 90 23:30:26 -0400 Message-Id: <9005250330.AA29356@TIS.COM> To: vcerf@NRI.Reston.VA.US Cc: James Van Bokkelen , spwg@NRI.Reston.VA.US, jkrey@isi.edu, ph@sei.cmu.edu Subject: Re: The 'responsibility' write up I promised I would do after IETF In-Reply-To: Your message of Thu, 24 May 90 19:33:24 -0400. <9005241934.aa16274@NRI.NRI.Reston.VA.US> Date: Thu, 24 May 90 23:30:04 -0400 From: crocker@tis.com Status: O jbvb, I agree with Vint's suggestion. It is well written and well worth reading. With respect to the overall Internet security policy, my picture of things is that a framework is emerging which addresses a variety of issues, including user behavior. Since network administration is split among many groups, it seems likely that each group will have to adopt its own security policy. The SPWG output will probably serve two roles. It will set forth some requirements and standards for each network's adoption of a security policy, and it will provide an example for what a typical security policy is. I think your note fits squarely into this framework and addresses the important issues. I take the lack of comment to represent probable consensus, and attention is now focused on other aspects. Given the hierarchical nature of network administration, I suspect your note is equally valuable in the SSPHWG effort. (I hope Joyce or Paul is listening.) Steve   Received: from taos.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa04346; 29 May 90 14:16 EDT Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA01059; Tue, 29 May 90 14:15:37 -0400 Message-Id: <9005291815.AA01059@taos.cert.sei.cmu.edu> To: crocker@tis.com Cc: vcerf@NRI.Reston.VA.US, James Van Bokkelen , spwg@NRI.Reston.VA.US, jkrey@isi.edu Subject: Re: The 'responsibility' write up I promised I would do after IETF In-Reply-To: Your message of "Thu, 24 May 90 23:30:04 EDT." <9005250330.AA29356@TIS.COM> Date: Tue, 29 May 90 14:15:36 EDT From: J Paul Holbrook Status: O Steve Crocker writes: ' Given the hierarchical nature of network administration, I suspect your note is equally valuable in the SSPHWG effort. (I hope Joyce or Paul is listening.)' I agree that James Van Bokkelen's contribution is useful to the SSPHWG effort. For that matter, almost anything you could talk about in the context of an Internet security policy applies to the policy handbook. Another way of looking at the split between the two groups: the SPWG will recommend an Internet security policy, and the SSPHWG will produce a guide for how sites can implement that security policy (as well as dealing with other site security issues that are outside the scope of the Internet security policy.) J. Paul Holbrook ssphwg co-chair Internet: (412) 268-7720   Received: from taos.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07138; 1 Jun 90 10:35 EDT Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA05927; Fri, 1 Jun 90 10:34:08 -0400 Message-Id: <9006011434.AA05927@taos.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Subject: Scope of the Internet Security Policy Date: Fri, 01 Jun 90 10:34:06 EDT From: J Paul Holbrook Status: O At the SPWG meeting in Pittsburgh several people agreed to write on some position statements on some of the important issues that the Internet Security Policy will have to address. We agreed to write these up by 5/31. This one is a short proposal for the scope of of the Internet Security Policy. These are sent out to encourage discussion on this issue. Please disagree, critique, and have at it. Please copy the spwg list on any replies. I'll sent out another note shortly on a different topic. J. Paul Holbrook ssphwg co-chair Internet: (412) 268-7720 SCOPE OF THE INTERNET SECURITY POLICY J. Paul Holbrook 6/1/90 The Internet security policy should not mandate security policies for sites beyond what is necessary for maintaining the security of the Internet. The policy should not mandate the form of a site's internal response to security problems. However, it should require that a site have policies in place which meet a minimum set of requirements to allow effective prevention of and response to Internet security problems. Helping a site develop a more complete set of security policies and procedures is the goal of the the Site Security Policy Handbook. The goal of the policy is to ensure that each site responsibly protects and audits access to the Internet, and maintains a point of contact so that each site can get information about security problems and also assist others in dealing with security problems that involve their site. The policy covers all "network-capable" devices that may affect the Internet. Thus, in additional to hosts, terminal servers, routers, and other network management devices are covered. Other machines that may indirectly allow unaudited access to the Internet are also covered. For example, if a host that has access to the Internet also trusts other hosts on a site's local network, the policy covers those other machines as well. As an example, if an Internet host trusts a local PC, a user might be able to use the PC to gain access to the Internet without proper auditing. In this case, the PC is covered under the policy. (If the Internet host does not trust the PC, the PC does not come under the policy.)   Received: from poohbah.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07461; 1 Jun 90 11:12 EDT Received: from localhost by poohbah.cert.sei.cmu.edu (5.61/2.3) id AA29986; Fri, 1 Jun 90 11:12:17 -0400 Message-Id: <9006011512.AA29986@poohbah.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Subject: spwg meeting minutes Date: Fri, 01 Jun 90 11:12:16 EDT From: Richard Pethia Status: O Dear working group members, Below are the spwg working group minutes for both the April 17th and May 1st meetings. I apologize for the late distribution of the minutes, but day to day fires have necessarily taken precedence. I appreciate the time and effort you have all taken to attend the meetings, to share your thoughts, and to begin working on a proposed policy. As we here at the CERT/CC continue to help Internet sites deal with computer security problems and their prevention, I'm more convinced than ever that the development of security policy, procedures, and techniques, along with the identification and elimination of vulnerabilities, are critical activities. For those of you who have volunteered to produce short statements on particular issues, please distribute them to the spwg list as they are completed. The resulting discussion is sure to help us sharpen our thinking and work towards concensus. -------- Reported by Richard Pethia: CERT/CC Mintues of the SPWG Meeting of April 17, 1990 The purpose of the April 17 meeting was to review the spwg chater, making any necessary changes, and to begin the activity of producing a policy framework. The initial discussion at the April 17 meeting focused on the utility of producing a security policy for the Internet, an internetwork of many networks sharing common name and address spaces. Since the ``Internet'' has no single controlling entity, and since its components are owned, operated, and administered by a variety of organizations, there was a concern that it would not be possible to enforce an Internet Security Policy in any useful way. Despite the concerns, the attendees at this meeting decided that a formal written policy, issued by the IAB as a recommendation in the form of an RFC, could act as a vehicle to build concensus among the organizations that own and operate components of the Internet. While it was concluded that uniform policy enforcement was probably not possible, the effort of producing and promoting a security policy would benefit the Internet community by focusing attention on Internet security issues and by encouraging the component owners to take steps to improve the security of those components. In addition, the recommended policy could act as a vehicle to establish expectations of community behavior and could act as an enabling document for the development and implementation of local policy. The group then decided that the policy should address various audiences: Internet users, host operators, network operators (including local networks, regional networks, national backbones, and international backbones), host vendors, and network vendors. For each of these audiences, the policy should speak to legal issues, technical issues, and administrative issues. Finally, the policy should, for each of the audiences, deal with the following issues: unauthorized access to data, destruction of data, modification of data, unauthorized use of service, and denial of service. Attention then turned to the distinction between a policy and a framework to be used in developing a policy. It was generally felt that the final result of the spwg effort should be a short, succinct document that address the issues listed above. The activity of developing the policy, however, should proceed using some sort of framework that would support the policy developers' efforts. This ``Internet Security Policy Development Framework'' should be structured to insure all key issues are addressed and act as a working document that is elaborated over time and serves to capture the work of the policy developers. The initial outline of the document is: 1. Introduction (a) Definitions and references (terms used in the balance of the document) (b) Internet definition (c) Scope of policy (d) Applicability (e) Authority (f) Focus and emphasis 2. Inventory of existing policies. A survey of existing policies, directives and laws that would influence an Internet security policy. 3. Needed policy and architecture A description of the audiences and issues an Internet Security policy should address. 4. Security Services Covers such areas as: Service classes, information classes, subscribers and users, current architectural approaches, availability, etc. 5. Certification and Accreditation Covers possible certification and accreditation activities including: who are the authorities, certification of components, accreditation of facilities. 6. Security Administration and Responsibilities Discusses issues as: overall security policy coordination, facility administration, component security administration, risk management, security training and awareness. Minutes of the SPWG meeting of May 1, 1990 The purpose of the May 1st meeting was to discuss the policy development framework created at the April meeting and to begin work documenting areas of concern and key issues. The framework was presented and there was general agreement that it could be used as a vehicle to develop a proposed Internet security policy. Discusson focused on section 4 (Security Services) of the outline and it was decided that the following three dimensions of the problem should be considered o Security Threats/Services - Confidentiality (theft of data) - Integrity (destruction) - Authentication (masquerade) - Assured Service (denial of service) o Domains of Implementation - Administrative - Technical - Legal o Who's Responsible - Users - Host Operators - Router/Network operators - Host Vendors - Router vendors Finally, attendees brainstormed to produce the key issues listed below. Several attendees (named on individual items below) agreed to draft brief position statements on specific items in the early June time frame. o Internet infrastructure assured service (Mike StJohns) o User Identification - including authentication, email, remote login, ftp (Vint Cerf) o Plugging Holes - individual responsibility (Tracy Laquey) o Incident Handling rules (Tracy Laquey) o Identification of resources (Tony Hain) o Lines of responsibility o User/Host/Network responsibilities (Paul Holbrook) o Proper usage; network ethics (James Van Bokkelen) o Configuration control o Audit trail o Confidentiality o Bad Press o User Identification - restricted access o Denial of Service - network service o Unauthorized access o Adequate response when being challenged about being a source of attacks (especially when cooperating with an investigation) o Known chain of responsibile authorities o Export restrictions - limitations enforcement Attendees of the April Meeting Branstad, Dennis dkb@ecf.ncsl.nist.gov Crocker, Steve crocker@tis.com Elliott, Oma oelliott@ddn1.dca.mil Ellis, James ellis@psc.edu Gross, Phill pgross@nri.reston.va.us Holbrook, Paul ph@cert.sei.cmu.edu Hollingsworth, Greg gregh@mailer.jhuapl.edu Jacobs, Joel jdj@mitre.org Mills, Kevin mills@osi3.ncsl.nist.gov Pethia, Rich rdp@cert.sei.cmu.edu Shirey, Rob shirey@mitre.org Tabacchi, Len Vaudreuil, Greg Gvaudre@nri.reston.va.us Attendees of the May meeting Stan Ames sra@mbunix.mitre.org Tom Bajzek twb@andrew.cmu.edu Alison Brown alison@maverick.osc.edu Jeffrey S. Carpenter jjc@unix.cis.pitt.edu Vinton Cerf vcerf@NRI.Reston.VA.US Richard Colella colella@osi3.ncsl.nist.gov Steve Crocker crocker@tis.com James Davin jrd@ptt.lcs.mit.edu Hunaid Engineer hunaid@opus.cray.com James Galvin galvin@tis.com Ella Gardner epg@gateway.mitre.org Tony Hain hain@nmfecc.arpa Robert Hoffman hoffman@cs.pitt.edu Paul Holbrook ph@SEI.CMU.EDU Greg Hollingsworth gregh@mailer.jhuapl.edu Phil Karn Karn@Thumper.Bellcore.Com Tracy Laquey tracy@emx.utexas.edu Keith McCloghrie sytek!kzm@hplabs.hp.com Gerald K Newman gkn@sds.sdsc.edu Lee Oattes oattes@utcs.utoronto.ca David Perkins dave_perkins@3com.com Marsha Perrott mlpt@andrew.emu.edu Richard Pethia rdp@sei.cmu.edu Ted Pike tgp@sei.cmu.edu Paul Pomes paul_pomes@uiuc.edu Joyce Reynolds jkrey@venera.isi.edu Robert J. Reschly Jr. reschly@brl.mil Milt Roselinsky cmcvax!milt@hub.vcsb.edu Jonathan Saperia saperia%tcpjon@decwrl.dec.com Robert W. Shirey shirey@mitre.org Tim Seaver tas@mcnc.org Michael StJohns stjohns@umd5.umd.edu Cal Thixton cthixton@next.com C. Philip Wood cpw@lanl.gov Sze-Ying Wuu wuu@nisc.junc.net   Received: from taos.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07858; 1 Jun 90 11:48 EDT Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA06056; Fri, 1 Jun 90 11:48:21 -0400 Message-Id: <9006011548.AA06056@taos.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Subject: Site security contacts proposal Date: Fri, 01 Jun 90 11:48:19 EDT From: J Paul Holbrook Status: O Here's another position statement for the Internet Security Policy effort. This one addresses the topic of who has authority and responsibility at a site to deal with security problems and how does someone outside that site get in touch with them. Again, this is just a first cut: fire away, and copy the group. J. Paul Holbrook ssphwg co-chair Internet: (412) 268-7720 SITE SECURITY CONTACTS DRAFT Position Statement J. Paul Holbrook 6/1/90 In this proposal, I use the term `site' to mean every resource-owning organization, including regional networks and other entities. I've used the terms 'MUST' and 'SHOULD' in capitals to help point out suggested policy directions. [Comments in brackets are notes to help explain the reasoning behind some of the statements. These comments would not appear as part of a policy, though they might appear as a commentary that goes along with the policy.] Site Security Contact Every site MUST have a site security contact. This may or may not be the same as the normal site contact or network manager. A site security contact can be an individual or an organization. The site security contact SHOULD be familiar with the technology and security of all systems at that site. If that is not possible, the security contact MUST be able to get in touch with the people that have this knowledge 24 hours a day. [At the CERT we've been got in touch with sites only to find out that they have no idea who is responsible for security or how to get in touch with them.] [A point of terminology: in his `responsibility' writeup, James VanBokkelen refers to `network managers' and `host managers'. The site security contact is a peer to the network manager; it might even be the same person. Others in the Internet community have used the term `site contact', which I've used because it helps to emphasize that a site security contact may have to deal with both network and host issues. Certainly a regional network or other network provider can (and should) have a `site security contact.' However, the terminology is certainly open to change.] Security Contact Availability The site security contact MUST provide other designated organizations in the Internet with a 24 hour point of contact. At a minimum, this should be a phone number which is answered during `business hours' 5 days a week, and equipped with an answering machine that is checked at least once every day (including weekends) to cover off hours. Sites SHOULD consider providing `real time' response: e.g., home phone numbers, pager numbers, or other means of contacting people. However, being able to get directly in touch with the security contact at any time is not required. [This is a compromise statement; it's hard to require a site to provide around-the-clock response without proof that it would be worth the cost. At the CERT we've found almost all problems can be dealt with by having a contact who is available during business hours. However, large sites or sites that care about the availability and security of their systems will probably want to provide 24 hour access to their security contact.] Sites MUST ensure that some backup security contact can be reached if the primary security contact is unavailable. This can take the form of a secondary contact person or organization. If outside organizations must use some different procedure to get to the backup security contact, sites MUST ensure that these procedures are communicated to the outside organizations. The `designated' or `outside' organizations have this contact information might be a local Network Control Center or Network Information Center, or might be security response centers such as CERT. Since security organizations might need access to this information anytime, organizations that keep this information MUST make it available 24 hours a day. [ The User Connectivity Problem (UCP) working group is working on the problem of how to get site contact information propagated around so that network problems can be dealt with. We should consider using whatever means they come up with for distributing this kind of information. In any case, the specifics of how this works are an operational matter that doesn't belong in a policy. ] Security Policy Issues Although the initial response to a security incident is often a technical one, policy issues also need to be dealt with. Should an intruder be shut out or watched? Should law enforcement be involved? Should a site disconnect itself from the network to avoid a worm or intruders? These decisions are not strictly technical; they may affect many people. Sites MUST ensure that people with the authority to decide these kinds of issues are available in the event of a serious security problem. If the site security contact does not have the authority to make these kinds of decisions, sites are encouraged to have a 24 hour administrative contact. (This administrative contact does not need to be visible to people outside the site.) Sites SHOULD also have policies that state who has the authority to make decisions and take actions in response to security problems, and under what circumstances administrators or decision makers should be brought in on an active security incident. The goal should be that a site security contact can quickly (i.e., in a few hours) take action to deal with a security problem, if necessary getting in touch with someone who can authorize their actions. At some sites, policy makers could give advance authorization to the site security contact and other system managers. For example, the site may give their technical people the authority and license to make their best efforts to deal with security problems. In this case, the policy also protects the technical people from `retribution' from policy makers after the fact. [The motivation here is that policy makers should be involved early on if a serious security incident is underway. Policy makers may have little to do with the day-to-day operation of systems, but they will be concerned if a serious security incident has serious impact on a site and it's operation. Among other things, if decision makers are not involved and understand the nature of security problems, they might impose policies after the fact to `deal with the security problem.' For example, the CERT has heard of sites where the local policy maker's response to a security incident was to advocate permanently disconnecting from the Internet. However, since this issue is mostly a matter of site internal policies, the Internet Security Policy should not mandate an administrative contact. The Site Security Policy Handbook will help flesh out this area by going into detail about how site policy makers should be involved in setting security policy and procedures.]   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa06994; 2 Jun 90 11:53 EDT To: J Paul Holbrook cc: spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Fri, 01 Jun 90 10:34:06 -0400. <9006011434.AA05927@taos.cert.sei.cmu.edu> Date: Sat, 02 Jun 90 11:51:21 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006021153.aa06994@NRI.NRI.Reston.VA.US> Status: O The notion of "trust" may need more careful elaboration in your otherwise clear and helpful summary. Should I be thinking "rlogin" when I read your paragraph on hosts trusting PCs? vint   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa07018; 2 Jun 90 11:54 EDT To: J Paul Holbrook cc: spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Fri, 01 Jun 90 10:34:06 -0400. <9006011434.AA05927@taos.cert.sei.cmu.edu> Date: Sat, 02 Jun 90 11:53:36 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006021154.aa07018@NRI.NRI.Reston.VA.US> Status: O The notion of "trust" may need more careful elaboration in your otherwise clear and helpful summary. Should I be thinking "rlogin" when I read your paragraph on hosts trusting PCs? vint   Received: from taos.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa02927; 4 Jun 90 17:10 EDT Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA09583; Mon, 4 Jun 90 17:08:22 -0400 Message-Id: <9006042108.AA09583@taos.cert.sei.cmu.edu> To: vcerf@NRI.Reston.VA.US Cc: spwg@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-Reply-To: Your message of "Sat, 02 Jun 90 11:53:36 EDT." <9006021154.aa07018@NRI.NRI.Reston.VA.US> Date: Mon, 04 Jun 90 17:08:20 EDT From: J Paul Holbrook Status: O The notion of "trust" may need more careful elaboration in your otherwise clear and helpful summary. Should I be thinking "rlogin" when I read your paragraph on hosts trusting PCs? I was thinking of rlogin when I wrote that part of the proposal. However, there may be other mechanisms that an Internet host uses to trust other machines -- special accounts, special network services, and so forth. Anytime an Internet host gives unauthenticated access to another machine, we have to be concerned about the machine it is trusting. Note that rlogin causes some sticky issues: individual users sometimes use the .rhosts mechanism to trust a machine outside their local site. Does this mean that a site's local policies apply to those external trusted machines? This sounds unworkable, but it's a valid security concern: you can't say your site is secure if you give others trusted access to your system without knowing something about their security. I didn't want be over specific about technology in the policy. When I wrote these proposals, I was thinking about the output of this group as being divided into the The Policy along with a commentary or guide to interpretation. The Policy should be succinct and adaptable to future techologies. Is this a reasonable model? Paul Holbrook CERT/SEI/CMU   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa00653; 8 Jun 90 4:24 EDT To: J Paul Holbrook cc: vcerf@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Mon, 04 Jun 90 17:08:20 -0400. <9006042108.AA09583@taos.cert.sei.cmu.edu> Date: Fri, 08 Jun 90 04:23:03 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006080424.aa00653@NRI.NRI.Reston.VA.US> Status: O Paul, "The Policy" needs to be succinct. I have the gut feeling, though, that there needs to be some kind of architectural model underlying the policy or it won;t be reasonable to try to interpret it rationally. This may require us to articulate the range of architectures for which the Policy is intended to work. hmm at this hour I may just be babbling, but I think at the moment that we may need to step back and ask what kind of architectural model we are implicitly using as we craft the policy. Vint   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa00667; 8 Jun 90 4:24 EDT To: J Paul Holbrook cc: vcerf@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Mon, 04 Jun 90 17:08:20 -0400. <9006042108.AA09583@taos.cert.sei.cmu.edu> Date: Fri, 08 Jun 90 04:24:30 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006080424.aa00667@NRI.NRI.Reston.VA.US> Status: O Paul, "The Policy" needs to be succinct. I have the gut feeling, though, that there needs to be some kind of architectural model underlying the policy or it won;t be reasonable to try to interpret it rationally. This may require us to articulate the range of architectures for which the Policy is intended to work. hmm at this hour I may just be babbling, but I think at the moment that we may need to step back and ask what kind of architectural model we are implicitly using as we craft the policy. Vint   Received: from taos.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa04579; 8 Jun 90 9:36 EDT Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA13391; Fri, 8 Jun 90 09:36:11 -0400 Message-Id: <9006081336.AA13391@taos.cert.sei.cmu.edu> To: vcerf@NRI.Reston.VA.US Cc: J Paul Holbrook , spwg@NRI.Reston.VA.US Subject: am I seeing double? In-Reply-To: Your message of "Fri, 08 Jun 90 04:23:03 EDT." <9006080424.aa00653@NRI.NRI.Reston.VA.US> Date: Fri, 08 Jun 90 09:36:10 EDT From: J Paul Holbrook Status: OR I think this is just coincidence, but .. The last two messages that you sent to me in reply to my SPWG messages have each been sent twice. In both cases, you sent a message, and then I got another copy of the message dated 1-2 minutes later. I'm guessing that since I haven't seen other messages of yours repeated, it was just a slip that ended up with two copies going out. And given the time that both messages were sent (late at night and early in the morning), I'm not surprised! The thing that makes it so noticable is that since the message is sent to me and cc'd to the SPWG, I already get two copies. But since the message itself was sent twice, I end up with four copies in my inbox. I certainly do pay close heed to your comments, but two copies would probably be enough :-). Just FYI, here's the header portions of the four messages as the SPWG archives on NRI captured them. Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa06994; 2 Jun 90 11:53 EDT To: J Paul Holbrook cc: spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Fri, 01 Jun 90 10:34:06 -0400. <9006011434.AA05927@taos.cert.sei.cmu.edu> Date: Sat, 02 Jun 90 11:51:21 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006021153.aa06994@NRI.NRI.Reston.VA.US> ------------- Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa07018; 2 Jun 90 11:54 EDT To: J Paul Holbrook cc: spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Fri, 01 Jun 90 10:34:06 -0400. <9006011434.AA05927@taos.cert.sei.cmu.edu> Date: Sat, 02 Jun 90 11:53:36 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006021154.aa07018@NRI.NRI.Reston.VA.US> ------------- Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa00653; 8 Jun 90 4:24 EDT To: J Paul Holbrook cc: vcerf@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Mon, 04 Jun 90 17:08:20 -0400. <9006042108.AA09583@taos.cert.sei.cmu.edu> Date: Fri, 08 Jun 90 04:23:03 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006080424.aa00653@NRI.NRI.Reston.VA.US> -------------- Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa00667; 8 Jun 90 4:24 EDT To: J Paul Holbrook cc: vcerf@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: Scope of the Internet Security Policy In-reply-to: Your message of Mon, 04 Jun 90 17:08:20 -0400. <9006042108.AA09583@taos.cert.sei.cmu.edu> Date: Fri, 08 Jun 90 04:24:30 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006080424.aa00667@NRI.NRI.Reston.VA.US>   Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa16392; 10 Jun 90 10:19 EDT To: J Paul Holbrook cc: vcerf@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US, vcerf@NRI.Reston.VA.US Subject: Re: am I seeing double? In-reply-to: Your message of Fri, 08 Jun 90 09:36:10 -0400. <9006081336.AA13391@taos.cert.sei.cmu.edu> Date: Sun, 10 Jun 90 10:17:14 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9006101019.aa16392@NRI.NRI.Reston.VA.US> Status: O Paul, I don't see why you got four copies. Two I could understand, too. I will check the SPWG on the chance you are on that list twce??? Vint   Received: from [128.237.253.35] by NRI.NRI.Reston.VA.US id aa12151; 13 Aug 90 13:36 EDT Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA12437; Mon, 13 Aug 90 13:35:40 -0400 Message-Id: <9008131735.AA12437@taos.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Subject: VCerf: Need for unforgeable user identification Reply-To: vcerf@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US Date: Mon, 13 Aug 90 13:35:38 EDT From: J Paul Holbrook Status: O Security Policy WG folks: The following memo was written by Vint Cerf to address one of policy topics we talked about at the Pittsburgh IETF in May. I transcribed this from Vint's hand-written draft; please blame any typos and the formatting on me. Forwarded with permission from Vint. Paul Holbrook ----------------------------------------- Vint Cerf CNRI July 31, 1990 The Need for Unforgeable User Identification FIRST DRAFT Summary ------- This brief memorandum motivates the need for Internet mechanisms and facilities for authenticating user identification and for assuring that such identification cannot be forged. Introduction ------------ The Internet has reached a point in its evolution where some of the services accessible require compensation from the using parties (or an entity which accepts responsibility for paying for services rendered). At the application level, such compensation is required for use of information services such as bibliographic databases (National Library of Medicine MEDLARS; Research Libraries Information Network, etc.) Commercial electronic messaging providers (e.g. MCI Mail, Compuserve, ATT Mail, Sprint Mail, BT Dialcom, QUIK-COMM, etc.) normally charge for their services. Some, such as Compuserve and MCI Mail provide access to commercial information services (e.g. Dow Jones News & Retrieval). Under the present terms and conditions, commercial email services do not charge Internet users for delivering email sent from Internet sites to commercial email boxes. Even if this provision remains in place, there are other services such as fax and hardcopy delivery, bulletin boards and information services which, at present, are not accessible to Internet users because there is no secure way to identify a billable account to which to charge these special services. Passwords carried in plaintext form across the Internet, whether in a Telnet session or via email, are not sufficiently protected to make the risk of compromise acceptable. Moreover, there is no currently standardized means of authenticating whether the use of a particular billable account is legitimate (once a password is compromised, it can be used at will, for simple, password-based account identification methods.) Example Requirements --------------------- At least two applications need reliable, secure account authentication capability: (1) remote login (2) email store and forward services In the first instance, it is required that the user/account identification provided to the server be protected from capture and re-use by hostile third parties and that the serving site can verify that the identification has not been forged. In the second case, it is required that at an email relay, an arriving message to be passed into the next email system can be reliably and authentically associated with an account in the next email system, if necessary, for purposes of accounting and validation that the message originator is authorized to use the services requested. For example, it should be possible for an Internet user to send email to fax recipients by way of ATT Mail and for ATT Mail to correctly account and bill for this usage. This means that the originator must supply information associated with a message which identifies ---------- account information needed to complete processing of the message at the Internet/commercial email interface. The provision of this account identifying information needs protection from compromise and validation that its use is legitimate. Questions --------- 1. Can the same techniques work for remote login and store-and-forward services? 2. Even if a "password" can be encrypted for confidentiality and signed for authenticity, how can the recipient be sure that the encrypted and signed object has not been hijacked by an abusing third party? (i.e. "stealing and reuse") 3. Given that there must be some kind of authenticated exchange between user and server just to set up an account, can we take advantage of this to carry out any additional exchanges needed to support the confidentiality and authenticity required for these account validation applications?   Received: from poohbah.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa06202; 23 Aug 90 11:51 EDT Received: from localhost by poohbah.cert.sei.cmu.edu (5.61/2.3) id AA13544; Thu, 23 Aug 90 11:49:59 -0400 Message-Id: <9008231549.AA13544@poohbah.cert.sei.cmu.edu> To: gvaudre@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US Subject: spwg minutes Date: Thu, 23 Aug 90 11:49:57 EDT From: Richard Pethia Status: O Security Policy Working Group Chairperson: Richard Pethia, rdp@sei.cmu.edu MINUTES FOR August 1 Meeting at UBC IETF ---------------------------------------- Minutes submitted by Paul Holbrook. Richard Pethia was not able to attend this meeting, so the meeting was co-chaired by Steve Crocker and Paul Holbrook. The initial part of the meeting focused on history of the group and the efforts thus far. We noted that the group had not made the progress it had hoped for; at the previous meeting in Pittsburgh, seven people had agreed to produce position statements on various issues, but only three of those statements had shown up. (Two of the statements are included in these minutes; the other one from James Van Bokkelen has been released as RFC 1173.) After a general discussion of the scope of the group and it's relationship to the work of the Site Security Policy Handbook WG (SSPHWG), Steve Crocker came up with some 'strawman' statements that might be in an Internet security policy. Steve stressed that these were statements that he didn't necessarily agree with, but were intended to be worded 'strongly' to provoke discussion. The group agreed the Steve had certainly provoked them. After a discussion of these statements (which we could not retrieve for these minutes), Steve proposed that everyone spend a few minutes writing up their own statements that they would include in an Internet security policy. This exercise worked very well, and the responses from the group showed a surprising amount of agreement. Joel Jacobs from Mitre took the task of trying to synthesize the writings of the group into a single strawman security policy. A summary (and interpretation) of some of the thoughts of the group is included at the end of these minutes. The goal of the group is to have some solid draft of an Internet security policy by the December IETF at the University of Colorado. To that end, a small group of people may gather in September to hammer out a solid draft of the security policy for other to critique. - ------------------------- J. Paul Holbrook Computer Emergency Response Team, SEI/CMU August 22, 1990 Security Policy Themes from the UBC Security Policy WG Meeting What follows are some of the themes the group seems to agree upon coupled with explanatory paragraphs in which I try to interpret the thinking of the group. A caveat: the information in this document has been filtered several times. Steve Crocker provided the original bullets, and thus provided his own view of what the group said. The paragraph after each bullet is my interpretation of what the group was thinking about. In particular, where the explanation says people 'should' do something, that does not mean that everyone agreed to propose this, just that this is one interpretation of where the group was going. The result is that the people who were at the meeting may not agree with what follows. * Internet, regionals/backbones, sites, hosts -- all should have security policies. Security policies and procedures are needed at all levels of the Internet. The policies will be different for different groups, and the general level of security expected may be different. For example, the policy may encourage regional networks to protect the network infrastructure such as the routers and other network equipment, but may put the burden of privacy on hosts. Thus, a regional would make it's best effort to protect the network, but would not provide a guarantee of privacy for the hosts that use it. * Emphasis on user responsibility, identification, and accountability. The policy should state clearly that users are responsible for their own actions regardless of the level of security a site maintains. By analogy, even if you leave your front door unlocked, that doesn't give someone else permission to enter your house. Sites should also have policies that support identifying and (if necessary) accounting for individual users. If your site is used to break into another site, that other site may ask for your help in tracking down the problem. It should be possible for you to figure out what user's account at your site was used. This requires that all users be individually identified, and that enough accounting records be kept to identify when users were on systems. (On Unix systems, the normal login accounting may well be sufficient for what we're after here.) This last requirement is likely to be controversial. There are sites that keep guest or group accounts for their own convenience, terminal servers that allow access out to the Internet without logging into a local system, and so forth. There was some irony in this proposal, since we all enjoyed this kind of open access out to the Internet at UBC, yet this was the very kind of access we were proposing limiting. * Emphasis on mutual assistance - Preference for investigation - Concern for privacy Where possible, sites should assist each other in investigating security incidents. Sites should provide contact points to help facilitate communication about security problems. When a security incident occurs, a site has two main choices: a) try to watch or trace the intruder(s) in an effort to see how widespread the problem is and hopefully identify who is responsible; b) identify the vulnerabilities or lapses that led to the incident, clean up the systems and lock the intruder(s) Some people leaned towards encouraging sites to investigate problems. In many cases, locking an intruder out will force them to find another site to use, but will not stop them from breaking into systems. The decision about what to do about an intrusion will always be up to the site, but the community standard should be to try to solve the problem. This does not necessarily advocate prosecution or law enforcement involvement. Once an intruder is identified, there are many possible courses of action. * Encouragement to use good security controls Policies and procedures are not a substitute for putting good security controls in place and making sure systems are securely configured. The policy should encourage sites to put useful security controls in place. - ------------------------ Vint Cerf CNRI July 31, 1990 The Need for Unforgeable User Identification FIRST DRAFT Summary ------- This brief memorandum motivates the need for Internet mechanisms and facilities for authenticating user identification and for assuring that such identification cannot be forged. Introduction ------------ The Internet has reached a point in its evolution where some of the services accessible require compensation from the using parties (or an entity which accepts responsibility for paying for services rendered). At the application level, such compensation is required for use of information services such as bibliographic databases (National Library of Medicine MEDLARS; Research Libraries Information Network, etc.) Commercial electronic messaging providers (e.g. MCI Mail, Compuserve, ATT Mail, Sprint Mail, BT Dialcom, QUIK-COMM, etc.) normally charge for their services. Some, such as Compuserve and MCI Mail provide access to commercial information services (e.g. Dow Jones News & Retrieval). Under the present terms and conditions, commercial email services do not charge Internet users for delivering email sent from Internet sites to commercial email boxes. Even if this provision remains in place, there are other services such as fax and hardcopy delivery, bulletin boards and information services which, at present, are not accessible to Internet users because there is no secure way to identify a billable account to which to charge these special services. Passwords carried in plaintext form across the Internet, whether in a Telnet session or via email, are not sufficiently protected to make the risk of compromise acceptable. Moreover, there is no currently standardized means of authenticating whether the use of a particular billable account is legitimate (once a password is compromised, it can be used at will, for simple, password-based account identification methods.) Example Requirements --------------------- At least two applications need reliable, secure account authentication capability: (1) remote login (2) email store and forward services In the first instance, it is required that the user/account identification provided to the server be protected from capture and re-use by hostile third parties and that the serving site can verify that the identification has not been forged. In the second case, it is required that at an email relay, an arriving message to be passed into the next email system can be reliably and authentically associated with an account in the next email system, if necessary, for purposes of accounting and validation that the message originator is authorized to use the services requested. For example, it should be possible for an Internet user to send email to fax recipients by way of ATT Mail and for ATT Mail to correctly account and bill for this usage. This means that the originator must supply information associated with a message which identifies ---------- account information needed to complete processing of the message at the Internet/commercial email interface. The provision of this account identifying information needs protection from compromise and validation that its use is legitimate. Questions --------- 1. Can the same techniques work for remote login and store-and-forward services? 2. Even if a "password" can be encrypted for confidentiality and signed for authenticity, how can the recipient be sure that the encrypted and signed object has not been hijacked by an abusing third party? (i.e. "stealing and reuse") 3. Given that there must be some kind of authenticated exchange between user and server just to set up an account, can we take advantage of this to carry out any additional exchanges needed to support the confidentiality and authenticity required for these account validation applications? --------------------------------------- J. Paul Holbrook Computer Emergency Response Team, SEI/CMU June 1, 1990 Scope of the Internet Security Policy This proposal deals with two areas that the Internet Security Policy is concerned with: the scope of the Internet Policy, and lines of authority or responsibility at a site. These are separate issues, so I'll treat them that way. SCOPE OF THE POLICY The Internet Security Policy should not mandate security policies for sites beyond what is necessary for maintaining the security of the Internet. The policy should not mandate the form of a site's internal response to security problems. However, it should require that a site have policies in place which meet a minimum set of requirements to allow effective prevention of and response to Internet security problems. Helping a site develop a more complete set of security policies and procedures is the goal of the the Site Security Policy Handbook. The goal of the policy is to ensure that each site responsibly protects and audits access to the Internet, and maintains a point of contact so that each site can get information about security problems and also assist others in dealing with security problems that involve their site. The policy covers all "network-capable" devices that may affect the Internet. Thus, in addition to hosts, terminal servers, routers, and other network management devices are covered. Other machines that may indirectly allow unaudited access to the Internet are also covered. For example, if a host that has access to the Internet also trusts other hosts on a site's local network, the policy covers those other machines as well. As an example, if an Internet host trusts a local PC via some mechanism such as rlogin or special trusted accounts, a user might be able to use the PC to gain access to the Internet without proper auditing. In this case, the PC is covered under the policy. (If the Internet host does not trust the PC, the PC does not come under the policy.) SITE AUTHORITY In this proposal, I use the term `site' to mean every resource-owning organization, including regional networks and other entities. I've used the terms 'MUST' and 'SHOULD' in capitals to help point out suggested policy directions. [Comments in brackets are notes to help explain the reasoning behind some of the statements. These comments would not appear as part of a policy, though they might appear as a commentary that goes along with the policy.] Site Security Contact Every site MUST have a site security contact. This may or may not be the same as the normal site contact or network manager. A site security contact can be an individual or an organization. The site security contact SHOULD be familiar with the technology and security of all systems at that site. If that is not possible, the security contact MUST be able to get in touch with the people that have this knowledge 24 hours a day. [At the CERT we've got in touch with sites only to find out that they have no idea who is responsible for security or how to get in touch with them.] [A point of terminology: in his `responsibility' writeup, James VanBokkelen refers to `network managers' and `host managers'. The site security contact is a peer to the network manager; it might even be the same person. Others in the Internet community have used the term `site contact', which I've used because it helps to emphasize that a site security contact may have to deal with both network and host issues. Certainly a regional network or other network provider can (and should) have a `site security contact.' However, the terminology is certainly open to change.] Security Contact Availability The site security contact MUST provide other designated organizations in the Internet with a 24 hour point of contact. At a minimum, this should be a phone number which is answered during `business hours' 5 days a week, and equipped with an answering machine that is checked at least once every day (including weekends) to cover off hours. Sites SHOULD consider providing `real time' response: e.g., home phone numbers, pager numbers, or other means of contacting people. However, being able to get directly in touch with the security contact at any time is not required. [This is a compromise statement; it's hard to require a site to provide around-the-clock response without proof that it would be worth the cost. At the CERT we've found almost all problems can be dealt with by having a contact who is available during business hours. However, large sites or sites that care about the availability and security of their systems will probably want to provide 24 hour access to their security contact.] Sites MUST ensure that some backup security contact can be reached if the primary security contact is unavailable. This can take the form of a secondary contact person or organization. If outside organizations must use some different procedure to get to the backup security contact, sites MUST ensure that these procedures are communicated to the outside organizations. The `designated' or `outside' organizations have this contact information might be a local Network Control Center or Network Information Center, or might be security response centers such as CERT. Since security organizations might need access to this information anytime, organizations that keep this information MUST make it available 24 hours a day. [ The User Connectivity Problem (UCP) working group is working on the problem of how to get site contact information propagated around so that network problems can be dealt with. We should consider using whatever means they come up with for distributing this kind of information. In any case, the specifics of how this works are an operational matter that doesn't belong in a policy. ] Security Policy Issues Although the initial response to a security incident is often a technical one, policy issues also need to be dealt with. Should an intruder be shut out or watched? Should law enforcement be involved? Should a site disconnect itself from the network to avoid a worm or intruders? These decisions are not strictly technical; they may affect many people. Sites MUST ensure that people with the authority to decide these kinds of issues are available in the event of a serious security problem. If the site security contact does not have the authority to make these kinds of decisions, sites are encouraged to have a 24 hour administrative contact. (This administrative contact does not need to be visible to people outside the site.) Sites SHOULD also have policies that state who has the authority to make decisions and take actions in response to security problems, and under what circumstances administrators or decision makers should be brought in on an active security incident. The goal should be that a site security contact can quickly (i.e., in a few hours) take action to deal with a security problem, if necessary getting in touch with someone who can authorize their actions. At some sites, policy makers could give advance authorization to the site security contact and other system managers. For example, the site may give their technical people the authority and license to make their best efforts to deal with security problems. In this case, the policy also protects the technical people from `retribution' from policy makers after the fact. [The motivation here is that policy makers should be involved early on if a serious security incident is underway. Policy makers may have little to do with the day-to-day operation of systems, but they will be concerned if a serious security incident has serious impact on a site and it's operation. Among other things, if decision makers are not involved and understand the nature of security problems, they might impose policies after the fact to `deal with the security problem.' For example, the CERT has heard of sites where the local policy maker's response to a security incident was to advocate permanently disconnecting from the Internet. However, since this issue is mostly a matter of site internal policies, the Internet Security Policy should not mandate an administrative contact. The Site Security Policy Handbook will help flesh out this area by going into detail about how site policy makers should be involved in setting security policy and procedures.]   Received: from babyoil.ftp.com by NRI.NRI.Reston.VA.US id aa14241; 23 Aug 90 17:54 EDT Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA11368; Thu, 23 Aug 90 13:24:01 -0500 Date: Thu, 23 Aug 90 13:24:01 -0500 Message-Id: <9008231824.AA11368@ftp.com> To: Richard Pethia Subject: Re: spwg minutes From: "James B. Van Bokkelen" Reply-To: jbvb@ftp.com Cc: gvaudre@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com Status: O A correction: I wasn't at Pittsburgh, I made my promise in Tallahassee (sp?). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901   Received: from mcsun.eu.net by NRI.NRI.Reston.VA.US id aa01342; 25 Aug 90 5:10 EDT Received: by mcsun.EU.net via EUnet; Sat, 25 Aug 90 11:08:49 +0200 (MET) Received: by ub4b (5.61/ub4b_01) id AA07564; Sat, 25 Aug 90 11:02:13 +0200 Date: 25 Aug 90 8:11 From: Suchun Wu To: spwg@NRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at NRI.NRI.Reston.VA.US Message-Id: <309:wu@ts.info.fundp.rtt.be> Subject: ask for joining distribution list Status: O Please add me to your distribution list with the following address: wu@ts.info.fundp.rtt.be Regards.   Received: from poohbah.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07548; 17 Oct 90 12:23 EDT Received: from localhost by poohbah.cert.sei.cmu.edu (5.61/2.3) id AA25933; Wed, 17 Oct 90 12:23:08 -0400 Message-Id: <9010171623.AA25933@poohbah.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US, ssphwg@NRI.Reston.VA.US, psrg-interest@venera.isi.edu, saag@tis.com Subject: Draft Security Policy Date: Wed, 17 Oct 90 12:23:06 EDT From: Richard Pethia Status: O Dear colleagues, Below is a working draft of a proposed Internet security policy for your review and comment. Following a series of security policy working group (spwg) working meetings, Steve Crocker and I put together this 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. Please direct your comments, criticisms, or suggestions for change to me, and use the spwg list as a discussion forum for topics you feel should be widely discussed. Thanks in advance for your interest and comments. Rich Pethia -------------------- Internet Security Policy WORKING DRAFT Richard Pethia Steve Crocker October 9, 1990 INTRODUCTION This policy 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 or use. ["access" covers unauthorized database lookup, for example; "use" covers unauthorized logging in to a system.] This policy has four 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. Vendors are responsible for providing systems which are sound and have adequate security controls. Users are responsible for protecting their own data and for assisting in the protection of the systems they use. 3) Users, service providers and hardware and software vendors are expected to cooperate in the provision of security. 4) 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 prohibited, no matter how weak the protection is on those computers. 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. 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) Site and network operators are responsible for protecting their systems. Vendors are responsible for providing systems which are sound and have adequate security controls. Users are responsible for protecting their own data and for assisting in the protection of the systems they use. 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. (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 are developing a handbook with guidance on all of these matters. Sites and network operators are encouraged to review this material and use it freely. 3) 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. 4) 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 REFERENCES 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. The intent is to make it a separate RFC and reference it. 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.   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa10790; 17 Oct 90 15:23 EDT Received: from NRI.RESTON.VA.US by cert.sei.cmu.edu (5.61/2.2) id AA29928; Wed, 17 Oct 90 14:11:18 -0400 Received: from poohbah.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07548; 17 Oct 90 12:23 EDT Received: from localhost by poohbah.cert.sei.cmu.edu (5.61/2.3) id AA25933; Wed, 17 Oct 90 12:23:08 -0400 Message-Id: <9010171623.AA25933@poohbah.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US, ssphwg@NRI.Reston.VA.US, psrg-interest@venera.isi.edu, saag@tis.com Subject: Draft Security Policy Date: Wed, 17 Oct 90 12:23:06 EDT From: Richard Pethia Status: O Dear colleagues, Below is a working draft of a proposed Internet security policy for your review and comment. Following a series of security policy working group (spwg) working meetings, Steve Crocker and I put together this 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. Please direct your comments, criticisms, or suggestions for change to me, and use the spwg list as a discussion forum for topics you feel should be widely discussed. Thanks in advance for your interest and comments. Rich Pethia -------------------- Internet Security Policy WORKING DRAFT Richard Pethia Steve Crocker October 9, 1990 INTRODUCTION This policy 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 or use. ["access" covers unauthorized database lookup, for example; "use" covers unauthorized logging in to a system.] This policy has four 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. Vendors are responsible for providing systems which are sound and have adequate security controls. Users are responsible for protecting their own data and for assisting in the protection of the systems they use. 3) Users, service providers and hardware and software vendors are expected to cooperate in the provision of security. 4) 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 prohibited, no matter how weak the protection is on those computers. 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. 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) Site and network operators are responsible for protecting their systems. Vendors are responsible for providing systems which are sound and have adequate security controls. Users are responsible for protecting their own data and for assisting in the protection of the systems they use. 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. (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 are developing a handbook with guidance on all of these matters. Sites and network operators are encouraged to review this material and use it freely. 3) 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. 4) 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 REFERENCES 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. The intent is to make it a separate RFC and reference it. 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.   Received: from venera.isi.edu by NRI.NRI.Reston.VA.US id aa16423; 17 Oct 90 23:00 EDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 17 Oct 90 19:59:15 -0700 Date: Wed, 17 Oct 90 16:15:11 PDT From: postel@venera.isi.edu Posted-Date: Wed, 17 Oct 90 16:15:11 PDT Message-Id: <9010172315.AA10859@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Wed, 17 Oct 90 16:15:11 PDT To: psrg-interest@venera.isi.edu, rdp@cert.sei.cmu.edu, saag@tis.com, spwg@NRI.Reston.VA.US, ssphwg@NRI.Reston.VA.US Subject: Re: Draft Security Policy Status: O Rich: Hi. I see no evidience that the following comments were processed. I really am perplexed by the paragraph: 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 or use. ["access" covers unauthorized database lookup, for example; "use" covers unauthorized logging in to a system.] I don't see where this "access" vs "use" distinction is made use of later, and i don't see any difference in the supposed definitions. --jon. Date: Tue, 9 Oct 90 15:08:00 PDT From: postel@ISI.EDU To: rdp@sei.cmu.edu Subject: re: revised security policy draft Cc: crocker@tis.com, iab@ISI.EDU, iesg@ISI.EDU Richard: 1) i dont quite understand "['access' covers unauthorized database lookup, for example; 'use' covers unauthorized logging into a system.]". Is a "database lookup" like (case 1) DNS query or a 'whois' query, or is it like (case 2) searching for citations in a bibliographic data base or looking up flights in the OAG ? I can't imagine how case 1 like queries could be unauthorized, and i think all case 2 queries are really examples of "use". 2) The appendix by James Van Bokkelen has already been published as RFC-1173. --jon.   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa02202; 18 Oct 90 6:43 EDT Received: from NRI.RESTON.VA.US by cert.sei.cmu.edu (5.61/2.2) id AA00767; Thu, 18 Oct 90 05:48:11 -0400 Received: from venera.isi.edu by NRI.NRI.Reston.VA.US id aa16423; 17 Oct 90 23:00 EDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 17 Oct 90 19:59:15 -0700 Date: Wed, 17 Oct 90 16:15:11 PDT From: postel@venera.isi.edu Posted-Date: Wed, 17 Oct 90 16:15:11 PDT Message-Id: <9010172315.AA10859@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Wed, 17 Oct 90 16:15:11 PDT To: psrg-interest@venera.isi.edu, rdp@cert.sei.cmu.edu, saag@tis.com, spwg@NRI.Reston.VA.US, ssphwg@NRI.Reston.VA.US Subject: Re: Draft Security Policy Status: O Rich: Hi. I see no evidience that the following comments were processed. I really am perplexed by the paragraph: 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 or use. ["access" covers unauthorized database lookup, for example; "use" covers unauthorized logging in to a system.] I don't see where this "access" vs "use" distinction is made use of later, and i don't see any difference in the supposed definitions. --jon. Date: Tue, 9 Oct 90 15:08:00 PDT From: postel@ISI.EDU To: rdp@sei.cmu.edu Subject: re: revised security policy draft Cc: crocker@tis.com, iab@ISI.EDU, iesg@ISI.EDU Richard: 1) i dont quite understand "['access' covers unauthorized database lookup, for example; 'use' covers unauthorized logging into a system.]". Is a "database lookup" like (case 1) DNS query or a 'whois' query, or is it like (case 2) searching for citations in a bibliographic data base or looking up flights in the OAG ? I can't imagine how case 1 like queries could be unauthorized, and i think all case 2 queries are really examples of "use". 2) The appendix by James Van Bokkelen has already been published as RFC-1173. --jon.   Received: from [134.177.32.17] by NRI.NRI.Reston.VA.US id aa03578; 18 Oct 90 8:58 EDT Received: from excalibur.synoptics.com by mvis1.synoptics.com (5.61/2.1G) id AA03046; Thu, 18 Oct 90 05:56:22 -0700 Received: by excalibur.synoptics.com (4.0/2.0N) id AA29330; Thu, 18 Oct 90 05:56:19 PDT Message-Id: <9010181256.AA29330@excalibur.synoptics.com> Date: Thu, 18 Oct 90 05:56:19 PDT From: Steven Blair Quote-Week: Die Yuppie Scum II...the next paycheck.. To: postel@venera.isi.edu, ssphwg@NRI.Reston.VA.US Subject: Re: Draft Security Policy Cc: psrg-interest@venera.isi.edu, spwg@NRI.Reston.VA.US Status: O I can not understand why this paragraph was even included. It seems to be totally unrelated to the overall document, and would be interested to see if everyone feesl it should potentially deleted: >> 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 or use. ["access" >> covers unauthorized database lookup, for example; "use" covers >> unauthorized logging in to a system.] Let's take this one statement at a time: >> Security is understood to include protection of the privacy of >> information OK, that's fairly clear, and by the "computer" terminology is redundant to the mission of the document. >>protection of information against unauthorized modification OK, that should be better defined, as to not leave ambiguities in that statement. >> protection of systems against denial of service HUH?? >> and protection of systems against unauthorized access or use That's the only realistic statement in the entire paragraph, to me. Mabye a better wording would be: Security includes the protection of private materials and their unauthorized use, modification, and/or access by unauthorized indviduals. Security also includes the system<->system interactions which could impair, or deny services to selected systems. steve blair sblair@synoptics.com hostmaster@synoptics.com   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa04495; 18 Oct 90 10:07 EDT Received: from NRI.RESTON.VA.US by cert.sei.cmu.edu (5.61/2.2) id AA01345; Thu, 18 Oct 90 09:24:11 -0400 Received: from [134.177.32.17] by NRI.NRI.Reston.VA.US id aa03578; 18 Oct 90 8:58 EDT Received: from excalibur.synoptics.com by mvis1.synoptics.com (5.61/2.1G) id AA03046; Thu, 18 Oct 90 05:56:22 -0700 Received: by excalibur.synoptics.com (4.0/2.0N) id AA29330; Thu, 18 Oct 90 05:56:19 PDT Message-Id: <9010181256.AA29330@excalibur.synoptics.com> Date: Thu, 18 Oct 90 05:56:19 PDT From: Steven Blair Quote-Week: Die Yuppie Scum II...the next paycheck.. To: postel@venera.isi.edu, ssphwg@NRI.Reston.VA.US Subject: Re: Draft Security Policy Cc: psrg-interest@venera.isi.edu, spwg@NRI.Reston.VA.US Status: O I can not understand why this paragraph was even included. It seems to be totally unrelated to the overall document, and would be interested to see if everyone feesl it should potentially deleted: >> 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 or use. ["access" >> covers unauthorized database lookup, for example; "use" covers >> unauthorized logging in to a system.] Let's take this one statement at a time: >> Security is understood to include protection of the privacy of >> information OK, that's fairly clear, and by the "computer" terminology is redundant to the mission of the document. >>protection of information against unauthorized modification OK, that should be better defined, as to not leave ambiguities in that statement. >> protection of systems against denial of service HUH?? >> and protection of systems against unauthorized access or use That's the only realistic statement in the entire paragraph, to me. Mabye a better wording would be: Security includes the protection of private materials and their unauthorized use, modification, and/or access by unauthorized indviduals. Security also includes the system<->system interactions which could impair, or deny services to selected systems. steve blair sblair@synoptics.com hostmaster@synoptics.com   Received: from taos.cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07398; 18 Oct 90 13:28 EDT Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA02135; Thu, 18 Oct 90 13:23:48 -0400 Message-Id: <9010181723.AA02135@taos.cert.sei.cmu.edu> To: Steven Blair Cc: ssphwg@cert.sei.cmu.edu, psrg-interest@venera.isi.edu, spwg@NRI.Reston.VA.US Subject: Re: Draft Security Policy In-Reply-To: Your message of "Thu, 18 Oct 90 05:56:19 PDT." <9010181256.AA29330@excalibur.synoptics.com> Date: Thu, 18 Oct 90 13:23:45 EDT From: J Paul Holbrook Status: O Steve Blair questions why the paragraph talking about security as protection of unauthorized information and so forth was included in the draft. My reading is that this paragraph defines what the term 'security' means in the context of this policy. This policy is essentially the 'security constitution' for the Internet. As such, it has to define the scope and direction for more specific security policies and procedures that will be created by organizations that own resources on the Internet. This part of the document is meant to point out that any comprehensive security policy should address ALL the areas mentioned in this paragraph. I disagree with Steve Blair about the statement as a whole. I think that the statement is succinct, clear, and that all the parts are useful. It is couched in "security-speak", but that's not inappropriate; the terms used have well-defined meaning in computer security circles. The people defining organization-specific policies based on the Internet policy will need to have some understanding of computer security issues in order to write a good policy. (Incidentally, part of the function of the Site Security Policy Handbook being produced by the SSPHWG is to serve as a guide to computer security issues for organizations trying to write security policies. So there is a place where these kinds of terms can be better explained.) I have some questions and comments on Steve's comments. >> Security is understood to include protection of the privacy of >> information OK, that's fairly clear, and by the "computer" terminology is redundant to the mission of the document. Steve, I don't understand your comment here. What is redundant? Privacy of information on computer systems is a concern distinct from other security concerns. Robert Van Cleef has already commented on denial service, so I'll leave that one. Steve proposes the rewording Security includes the protection of private materials and their unauthorized use, modification, and/or access by unauthorized individuals. Security also includes the system<->system interactions which could impair, or deny services to selected systems. The term 'private materials' doesn't seem to be right. It seems too broad, and although I think Steve is trying to make sure this covers all the bases, it doesn't seem to come off right. The paragraph in the draft focuses on two things: protection of information, and protection of systems. This seems to capture all of what 'private material' covers, and covers it in a more general fashion. I like the focus on 'information' because that makes it independent of where the information is: whether it's information going over the network, sitting on a router, or on a system, it's all potentially vulnerable and may need to be protected. In this context, "protecting information against unauthorized modification", as it says in the draft, seems to make clear sense: security concerns about information apply any place the information may exist: on hosts, in transit over nets, passing through routers, or any other place. Steve's term "system<->system" also misses part of the problem, because it misses the human part of the problem. Problems come from both systems and people. Though the Internet worm was programmed threat, here at the CERT we've seen far more examples of people on the other end of an attack. J. Paul Holbrook / ssphwg co-chair CERT/CMU ph@cert.sei.cmu.edu   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07562; 18 Oct 90 13:39 EDT Received: from NRI.RESTON.VA.US by cert.sei.cmu.edu (5.61/2.2) id AA02228; Thu, 18 Oct 90 12:51:11 -0400 Received: from mvis1.synoptics.com by NRI.NRI.Reston.VA.US id aa05624; 18 Oct 90 11:28 EDT Received: from excalibur.synoptics.com by mvis1.synoptics.com (5.61/2.1G) id AA00773; Thu, 18 Oct 90 08:28:53 -0700 Received: by excalibur.synoptics.com (4.0/2.0N) id AA01847; Thu, 18 Oct 90 08:28:51 PDT Message-Id: <9010181528.AA01847@excalibur.synoptics.com> Date: Thu, 18 Oct 90 08:28:51 PDT From: Steven Blair Quote-Week: Die Yuppie Scum II...the next paycheck.. To: postel@venera.isi.edu, ssphwg@NRI.Reston.VA.US, vancleef@prandtl.nas.nasa.gov Subject: Re: Draft Security Policy Cc: psrg-interest@venera.isi.edu, spwg@NRI.Reston.VA.USd Status: O OK, I now understand the wording issues that many have been so kind to email me this morning. I agree that accidental, Morris et. al. is relative. But the other wordings are what I have more issues with, which is why I suggested a re-wording Comments?? scb   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa07576; 18 Oct 90 13:40 EDT Received: from NRI.RESTON.VA.US by cert.sei.cmu.edu (5.61/2.2) id AA02207; Thu, 18 Oct 90 12:47:31 -0400 Received: from prandtl.nas.nasa.gov by NRI.NRI.Reston.VA.US id aa05589; 18 Oct 90 11:24 EDT Received: Thu, 18 Oct 90 08:25:19 -0700 by prandtl.nas.nasa.gov (5.61/1.2) Date: Thu, 18 Oct 90 08:25:19 -0700 From: "Robert E. Van Cleef" Message-Id: <9010181525.AA04531@prandtl.nas.nasa.gov> To: postel@venera.isi.edu, sblair@synoptics.com, ssphwg@NRI.Reston.VA.US Subject: Re: Draft Security Policy Cc: psrg-interest@venera.isi.edu, spwg@NRI.Reston.VA.USd Status: OR Steve; Protection against denial of service, both intentional and accidental, is my major justification for implementing computer security in a research environment. For example, most of the damage caused by the Morris Worm could be classified damage caused by a "denial of service" attack. The other reason I use is insurance of data integrity. Intentional or accidental corruption of data must be avoided. The use of the term "accidental" is important. In my experience, there are more instances of denial of service or corruption of data problems caused by the actions of authorized users or system administrators than by outside intruders. In a "research" environment, privacy is not the primary concern of system security. The primary concerns are system availability and data integrity, privacy is a secondary concern. Bob ::Message-Id: <9010181256.AA29330@excalibur.synoptics.com> ::Date: Thu, 18 Oct 90 05:56:19 PDT ::From: Steven Blair ::Subject: Re: Draft Security Policy :: ::>> protection of systems against denial of service :: ::HUH??   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa08139; 18 Oct 90 14:13 EDT Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.61/2.2) id AA02358; Thu, 18 Oct 90 13:24:03 -0400 Received: from localhost by taos.cert.sei.cmu.edu (5.61/2.3) id AA02135; Thu, 18 Oct 90 13:23:48 -0400 Message-Id: <9010181723.AA02135@taos.cert.sei.cmu.edu> To: Steven Blair Cc: ssphwg@cert.sei.cmu.edu, psrg-interest@venera.isi.edu, spwg@NRI.Reston.VA.US Subject: Re: Draft Security Policy In-Reply-To: Your message of "Thu, 18 Oct 90 05:56:19 PDT." <9010181256.AA29330@excalibur.synoptics.com> Date: Thu, 18 Oct 90 13:23:45 EDT From: J Paul Holbrook Status: O Steve Blair questions why the paragraph talking about security as protection of unauthorized information and so forth was included in the draft. My reading is that this paragraph defines what the term 'security' means in the context of this policy. This policy is essentially the 'security constitution' for the Internet. As such, it has to define the scope and direction for more specific security policies and procedures that will be created by organizations that own resources on the Internet. This part of the document is meant to point out that any comprehensive security policy should address ALL the areas mentioned in this paragraph. I disagree with Steve Blair about the statement as a whole. I think that the statement is succinct, clear, and that all the parts are useful. It is couched in "security-speak", but that's not inappropriate; the terms used have well-defined meaning in computer security circles. The people defining organization-specific policies based on the Internet policy will need to have some understanding of computer security issues in order to write a good policy. (Incidentally, part of the function of the Site Security Policy Handbook being produced by the SSPHWG is to serve as a guide to computer security issues for organizations trying to write security policies. So there is a place where these kinds of terms can be better explained.) I have some questions and comments on Steve's comments. >> Security is understood to include protection of the privacy of >> information OK, that's fairly clear, and by the "computer" terminology is redundant to the mission of the document. Steve, I don't understand your comment here. What is redundant? Privacy of information on computer systems is a concern distinct from other security concerns. Robert Van Cleef has already commented on denial service, so I'll leave that one. Steve proposes the rewording Security includes the protection of private materials and their unauthorized use, modification, and/or access by unauthorized individuals. Security also includes the system<->system interactions which could impair, or deny services to selected systems. The term 'private materials' doesn't seem to be right. It seems too broad, and although I think Steve is trying to make sure this covers all the bases, it doesn't seem to come off right. The paragraph in the draft focuses on two things: protection of information, and protection of systems. This seems to capture all of what 'private material' covers, and covers it in a more general fashion. I like the focus on 'information' because that makes it independent of where the information is: whether it's information going over the network, sitting on a router, or on a system, it's all potentially vulnerable and may need to be protected. In this context, "protecting information against unauthorized modification", as it says in the draft, seems to make clear sense: security concerns about information apply any place the information may exist: on hosts, in transit over nets, passing through routers, or any other place. Steve's term "system<->system" also misses part of the problem, because it misses the human part of the problem. Problems come from both systems and people. Though the Internet worm was programmed threat, here at the CERT we've seen far more examples of people on the other end of an attack. J. Paul Holbrook / ssphwg co-chair CERT/CMU ph@cert.sei.cmu.edu   Received: from mwunix.mitre.org by NRI.NRI.Reston.VA.US id aa10233; 18 Oct 90 15:35 EDT Return-Path: Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA06212; Thu, 18 Oct 90 15:33:38 -0400 Received: by smiley.mitre.org (4.1/SMI-4.0) id AA15757; Thu, 18 Oct 90 15:33:36 EDT Date: Thu, 18 Oct 90 15:33:36 EDT From: Robert Shirey Message-Id: <9010181933.AA15757@smiley.mitre.org> To: spwg@NRI.Reston.VA.US Subject: Policy Terminology Status: O At a minimum, Internet security policy and other security-related documents shoul use the internationally standardized terminology of ISO International Standard 7498/2, the OSI security architecture. For example, say "data confidentiality" instead of "data privacy". There is enough work to do without having to define terms. The draft policy reads much more like a voluntary code of ethics than a policy. Definition from 7498/2: "security policy: The set of criteria for the provision of security services".   Received: from psi.com by NRI.NRI.Reston.VA.US id aa16284; 18 Oct 90 21:26 EDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA18878; Thu, 18 Oct 90 21:10:03 -0400 Message-Id: <9010190110.AA18878@psi.com> To: Robert Shirey Cc: spwg@NRI.Reston.VA.US Subject: Re: Policy Terminology In-Reply-To: Your message of Thu, 18 Oct 90 15:33:36 -0400. <9010181933.AA15757@smiley.mitre.org> Date: Thu, 18 Oct 90 21:10:02 -0400 From: Martin Lee Schoffstall Status: O While this is an interesting suggestion, it is a tad parochial, we may want to temper some of the definitive nature of ISO with 20 years of experiences in the ARPANET/Internet. Marty -------- At a minimum, Internet security policy and other security-related documents shoul use the internationally standardized terminology of ISO International Standard 7498/2, the OSI security architecture. For example, say "data confidentiality" instead of "data privacy". There is enough work to do without having to define terms. The draft policy reads much more like a voluntary code of ethics than a policy . Definition from 7498/2: "security policy: The set of criteria for the provision of security services".   Received: from tis.com by NRI.NRI.Reston.VA.US id aa10809; 19 Oct 90 15:29 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA04003; Fri, 19 Oct 90 15:28:46 EDT Message-Id: <9010191928.AA04003@TIS.COM> To: spwg@NRI.Reston.VA.US Subject: [Paul Clark: Re: Draft Internet Security Policy ] Date: Fri, 19 Oct 90 15:28:44 -0400 From: Stephen D Crocker Status: O ------- Forwarded Message Replied: Thu, 18 Oct 90 23:34:44 -0400 Replied: "Paul Clark " Return-Path: paul@TIS.COM Return-Path: Received: from SNOW.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA15822; Thu, 18 Oct 90 10:41:16 EDT Message-Id: <9010181441.AA15822@TIS.COM> To: Stephen D Crocker Cc: techies@TIS.COM, paul@TIS.COM Subject: Re: Draft Internet Security Policy In-Reply-To: Your message of Wed, 17 Oct 90 17:07:23 -0400. <9010172107.AA23577@TIS.COM> Date: Thu, 18 Oct 90 10:41:41 -0400 From: Paul Clark In reviewing Rich Pethia's document there appeared to be a few omissions. Whether these were deliberate or not I do not know. - Policy Section 1 part 2: It seems unclear who (users, administrators, etc.) is responsible in the event resources are used in an unauthorized fashion during an account breakin. - A more general question related to the preceding is: "To what extent, and under what circumstances, are operators, vendors, and users to be held accountable for breaches in security?" - There is no mention of penalties or enforcement mechanisms within the document. As such a policy statement carries very little weight. Perhaps outline of current legal remedies or other potential actions would be helpful. In general, I found the document to be properly succinct and well organized. I would welcome responses to my criticism. Paul Clark ------- End of Forwarded Message   Received: from nri by NRI.NRI.Reston.VA.US id aa10844; 23 Oct 90 15:37 EDT To: spwg@NRI.Reston.VA.US cc: mdavies@NRI.Reston.VA.US Subject: My abject apology Date: Tue, 23 Oct 90 15:34:05 -0400 From: mdavies@NRI.Reston.VA.US Message-ID: <9010231537.aa10844@NRI.NRI.Reston.VA.US> Status: O Folks, I'm awfully sorry for inundating you with so much extra (useless) mail. I'm still something of a novice at this, though mistakes like this inspire one to mature! Those of you who have emailed me directly have been very gracious. THANK YOU!! I have learned my lesson. Megan I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN. I WILL NEVER CC THE SPWG MAILING LIST ON AN ACKNOWLEDGEMENT AGAIN........ ......................   Received: from psi.com by NRI.NRI.Reston.VA.US id aa14001; 23 Oct 90 18:50 EDT Date: Tue, 23 Oct 90 18:42:40 -0400 From: Marty Schoffstall Received: by psi.com (5.61/2.1-Performance Systems International) id AA12120; Tue, 23 Oct 90 18:42:40 -0400 Message-Id: <9010232242.AA12120@psi.com> To: spwg@NRI.Reston.VA.US Subject: Comments on the Draft Cc: schoff@psi.com It has been my belief that the IAB has no authority to set standards, hence we have the RFC document series and the continued grey state of what the IAB stands on (other than itself and some form of consensus). Obviously standards are set by NIST and obviously the IAB side stepped this long ago. The old FRICC, now renamed, set POLICY for federal networking, but did not encroach on private internetworking (including the mid-levels) in any documentable manner. Historically the IAB has never set policy and even within this past year I have heard the chair state the same. This document on "Internet Security Policy" breaks both a tradition and possibly some legal constructs eventually. I strongly encourage you all to remove the word policy and in general tone down this document to recommendations. Let's look at some details: - Under Elaboration (1), "Users are individually accountable for their own behaviour". This is not my understanding of the restrictions to R&E for backbones, nor what DARPA historically enforced, nor would it stand a legal challenge. More importantly I do not think that this is reasonable. Under this language, any organization who showed wanton disregard for whatever norms, laws, agreements, etc in providing access etc would have no liability since it was the individuals who were the problem. - Under Elaboration (3), the whole concept of providing mutual security assistance is pretty interesting. What are the edges of the envelope here? For instance mere law as to privacy of email, etc.. Strict readings of certain statuatory constraints both Federal and at the state level would have me render assistance to law enforcement agencies but I'd be in deep yogurt if I did it with the part time network manager of foo.edu or foo.com. Most very large corporations and universities actually have telecom policy that says the reverse, that they won't help you. Of less importance, is that I think Jame's section should be reissued as an historical RFC and not encumbered with all of this. Such are my comments on this document. Marty   Received: from nri by NRI.NRI.Reston.VA.US id ab15355; 24 Oct 90 19:51 EDT To: Marty Schoffstall cc: spwg@NRI.Reston.VA.US Subject: Re: Comments on the Draft In-reply-to: Your message of Tue, 23 Oct 90 18:42:40 -0400. <9010232242.AA12120@psi.com> Date: Wed, 24 Oct 90 19:45:39 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9010241951.ab15355@NRI.NRI.Reston.VA.US> Marty, I suppose we could label this Internet Security Practice. I think it is correct that users are or ought to be accountable for their behavior - but I think this is just a general statement about personal responsibility. I do not agree with your conclusion that such a statement allows organizations to escape culpability. If we said that ONLY individual users were responsible, then your observation would make more sense to me, but we didn't say that. Maybe we should also say something about the responsibility of organizations since, later in the text, I think the notion of organizational responsibility shows up. I did not follow your comment about being in deep yogurt if you cooperated with enforcement agencies using a prt time network manager - the status of the manager as part time seems to be irrelevant? As to corporations and universities that have policy not to assist - this could use some back up - can you provide some examples? Most of the telephone companies actually have a policy of working together in security matters, including informing each other of what they find on public bulletin boards as to account numbers, passwords and the like. Vint   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 90 10:07:01 EST From: J Paul Holbrook [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 REFERENCES 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. 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.   Received: from [128.237.253.35] by NRI.NRI.Reston.VA.US id aa06513; 28 Nov 90 10:15 EST Received: from localhost by taos.cert.sei.cmu.edu (5.65/2.3) id AA08344; Wed, 28 Nov 90 10:14:06 -0500 Message-Id: <9011281514.AA08344@taos.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Cc: mdavies@NRI.Reston.VA.US Subject: Agenda and recommended reading for IETF Reply-To: rdp@cert.sei.cmu.edu, ph@cert.sei.cmu.edu Date: Wed, 28 Nov 90 10:14:05 EST From: J Paul Holbrook The Security Policy Working Group will meet on Wednesday, December 5 from 1:30 to 3:30 pm at the IETF meeting in Boulder. The recommended reading for the meeting is the November 28 revised draft of the recommended Internet Security Policy. This draft was just sent out to the spwg, and can also be retrieved via anoymous ftp from cert.sei.cmu.edu in /pub/ssphwg/spwg-policy-28nov.txt. If you want to compare this to the original draft, that draft is available in the same directory as spwg-policy-9oct.txt. Rich Pethia will come to Boulder with the complete list of comments received on the October 9 draft. Here is the proposed agenda for that meeting: -Step through the new draft and reach consensus of the participants (making changes as necessary.) -Define action plan for building consensus across the Internet community. -Assign action items for each element of the plan. [I'm sending this out on behalf of Rich Pethia, who is out of the office -- Paul Holbrook].   Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa07858; 28 Nov 90 11:14 EST Received: from TAOS.CERT.SEI.CMU.EDU by cert.sei.cmu.edu (5.65/2.2) id AA27658; Wed, 28 Nov 90 10:14:03 -0500 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 90 10:07:01 EST From: J Paul Holbrook [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 REFERENCES 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. 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.   Received: from NRI by NRI.NRI.Reston.VA.US id aa15915; 20 Dec 90 18:19 EST To: spwg@NRI.Reston.VA.US cc: rdp@cert.sei.cmu.edu, mdavies@NRI.Reston.VA.US Subject: Updated mailing list Date: Thu, 20 Dec 90 18:16:54 -0500 From: Megan Davies Message-ID: <9012201819.aa15915@NRI.NRI.Reston.VA.US> Hi, I am enclosing a copy of the current spwg mailing list. It has recently been updated to include those individuals who attended the spwg session in Boulder (and who were not previously on the list). Please let me know of any needed adjustments by sending same to: spwg-request@nri.reston.va.us. Thank you and have the happiest of holidays. Megan "" "0.U-Pittsburgh" "0.interlink-redist" "0.saic" "Agrawala, Ashok" "Aiken, Bob" "Ames, Stan" "Badve, Suhas" "Bagnall, Douglas" "Bajzek, Tom" "Baran, Fuat" "Baum, Michael" "Bellovin, Steve" "Boardman, Spider" "Bradner, Scott" "Brown, Alison" "Brown, Vickie" "Brunell, Mats" "Byrum, Frank" "Carpenter, Jeff" "Carrol, Eric" "Cerf, Vinton" "Chiappa, Noel" "Colella, Richard" "Crocker, Steve" "Curry, Dave" "Davin, James R." "Dray, James" "Ellis, James" "Engineer, Hunaid" "Fernandez, Louis" "Finseth, Craig" "Ford, Peter" "Galvin, James M." "Gardner, Ella" "Hahn, Jack" "Hain, Tony" "Haller, Neil" "Hamilton, Debbie" "Henize, Dewey" "Hertzer, Joerg" "Hobby, Russ" "Hoffman, Lance" "Hoffman, Robert" "Holbrook, Paul" "Hollingsworth, Greg" "Housley, Russ" "Irish, Dudley" "Jacobs, Joel" "Johnson, Dale" "Karn, Phil" "Kedlaya, Ram" "Kinley, Darren" "Kirstein, Peter" "Koro, Mark" "Kutz, William" "Lauck, Tony" "Lauer, Greg" "Lazear, Walter" "Liebreich, Dave" "Linn, John" "Long, Daniel" "Love, Paul" "Mills, Kevin" "Morris, Dennis" "Murphy, Dave" "Newman, Gerard" "Noble, Chuck" "Oattes, Lee" "Ostapik, fred" "Perkins, David" "Perrott, Marsha" "Pethia, Rich" "Pike, Ted" "Piper, Ian" "Pomes, Paul" "Reschly, Robert Jr." "Reynolds, Joyce" "Riechmann, Christian" "Robey, Frank J." "Ronzone, Phill" "Rosenstein, Mark" "Rossen, Ken" "Russel, Dennis" "Saperia, Jon" "Schiller, Jeffrey" "Schoffstall, Marty" "Seaver, Tim" "Sheridan, Jim" "Shirey, Robert W." "Shue, Chi" "Smith, Art" "Solensky, Frank" "St. Johns, Mike" "Strickland, Vance" "Thixton, Cal" "Tipler, Brad" "Tsudik, Gene" "Van Wyk, Ken" "Van Cleef, Bob" "VanBokkelen, James" "Varadhan, Kannan" "Vaudreuil, Greg" "Waldbusser, Steve" "Wood, C. Philip" "Wu, Suchun" "Yasaki, Brian"   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa15055; 6 Mar 91 16:08 EST Received: from SPARKY.CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa14930; 6 Mar 91 16:02 EST Received: from localhost by sparky.cert.sei.cmu.edu (5.65/2.3) id AA04515; Wed, 6 Mar 91 16:03:31 -0500 Message-Id: <9103062103.AA04515@sparky.cert.sei.cmu.edu> To: spwg@NRI.Reston.VA.US Subject: Latest Draft Date: Wed, 06 Mar 91 16:03:30 EST From: Barbara Fraser 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 byf@cert.sei.cmu.edu ====================================== 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.   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa24441; 7 Mar 91 22:20 EST Received: from ATHENA.MIT.EDU by NRI.NRI.Reston.VA.US id aa24279; 7 Mar 91 22:12 EST Received: from BIG-SCREW.MIT.EDU by ATHENA.MIT.EDU with SMTP id AA00453; Thu, 7 Mar 91 22:13:58 EST Received: by BIG-SCREW (5.57/4.7) id AA24369; Thu, 7 Mar 91 22:13:55 EST Date: Thu, 7 Mar 91 22:13:55 EST Message-Id: <9103080313.AA24369@BIG-SCREW> From: "Jeffrey I. Schiller" Sender: jis@athena.mit.edu To: spwg@NRI.Reston.VA.US Subject: Re: Latest Draft This message is in response to my previous comments. Basically in my last set of comments I pointed out some issues which I thought should be addressed in the policy. In this message I propose concrete changes in an attempt to address my own concerns. Under the Elaboration section, change Point (3) Subparagraph (iii) from: (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. To (All Uppercase represents my changes): (iii) There SHOULD 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. I also recommend changing subpoint (v) from: (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 (no uppercase used here, changes should be obvious): (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. -Jeff   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa06708; 8 Mar 91 10:34 EST Received: from ftp.com by NRI.NRI.Reston.VA.US id aa06619; 8 Mar 91 10:29 EST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA26418; Fri, 8 Mar 91 10:31:35 -0500 Date: Fri, 8 Mar 91 10:31:35 -0500 Message-Id: <9103081531.AA26418@ftp.com> To: spwg@NRI.Reston.VA.US Subject: Re: Latest Draft From: "James B. Van Bokkelen" Reply-To: jbvb@ftp.com Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com I second Jeff's concerns. His changes look good. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901   Received: from SPARKY.CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa14523; 22 Mar 91 11:55 EST Received: from localhost by sparky.cert.sei.cmu.edu (5.65/2.3) id AA13056; Fri, 22 Mar 91 11:56:42 -0500 Message-Id: <9103221656.AA13056@sparky.cert.sei.cmu.edu> To: cerf@NRI.Reston.VA.US, crocker@tis.com, pgross@NRI.Reston.VA.US, gvaudre@NRI.Reston.VA.US Cc: saag@tis.com, spwg@NRI.Reston.VA.US Subject: Final Document Date: Fri, 22 Mar 91 11:56:41 EST From: Barbara Fraser Here's the final document as submitted to internet-drafts@nri.reston.va.us. 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 spwg@nri.reston.va.us. PREAMBLE The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. Comments by Vinton G. Cerf, Vice President, Corporation for National Research Initiatives, and Chairman, Internet Engineering Task Force, and James Van Bokkelen, President, FTP Software, Inc., have been provided to further illuminate the history and issues involved in this policy. In the early 1970's, the "Internet" was a research project sponsored by the U.S. Defense Advanced Research Projects Agency (DARPA), to explore technology for interlinking packet switching networks. Even in its early phases, the exploration involved international participation, notably University College London and, later, the participants in the Atlantic Satellite Network (SATNET) which included the Norwegian Defense Research Establishment, The Norwegian Telecommunications Administration Research Establishment, the German Air and Space Research Establishment (DFVLR), the Royal Signals and RADAR Establishment (RSRE), and CNUCE, an institute of the Italian Research Council (CNR). In the ensuing fifteen years, the Internet has grown much larger and also more diverse. Its participants include government institutions and agencies, academic and research institutions, commercial network and electronic mail carriers, non-profit research centers and an increasing array of industrial players who are primarily users of the technology. Despite this dramatic growth, the system is still operated on a purely collaborative basis. Participating networks take responsibility for their own operation. Service providers, private network operators, users and vendors all cooperate to keep the system functioning. It is important to recognize that the voluntary nature of the Internet system is both its strength and, perhaps, its most fragile aspect. Rules of operation, like the rules of etiquette, are voluntary and, largely, unenforceable, except where they happen to coincide with national laws whose violation can lead to prosecution. A common set of rules for the successful and increasingly secure operation of the Internet can, at best, be voluntary, since the laws of various countries are not uniform regarding data networking. Indeed, the recommended guidelines outlined below can also only be voluntary. However, since joining the Internet is optional, it is also fair to argue that the Internet Rules of Behavior are part of the bargain for joining and that failure to observe, apart from any legal infrastructure available, are grounds for sanctions. Vinton G. Cerf October 1990 The following is an excerpt from "The Internet Oral Tradition", published as RFC 1173. Every host and network manager MUST be aware that the Internet as presently constituted is NOT secure. At the protocol level, much more effort has been put into interoperability, reliability and convenience than has been devoted to security, although this is changing. Recent events have made software developers and vendors more sensitive to security, in both configuration and the underlying implementation, but it remains to be demonstrated how much long-term effect this will have. Meanwhile, the existing system survives through the co-operation of all responsible individuals. Security is subjective; one site might view as idle curiosity what another would see as a hostile probe. Since ultimately the existence of the Internet depends on its usefulness to all members of the community, it is important for managers to be willing to accept and act on other sites' security issues, warning or denying access to offending users. The offended site, in turn, must be reasonable in its demands (someone who set off an alarm while idly seeing if the sendmail 'DEBUG' hole was closed on a 'sensitive' host probably should be warned, rather than prosecuted). Because Internet security issues may require that local management people either get in touch with any of their users, or deny an offending individual or group access to other sites, it is necessary that mechanisms exist to allow this. . . .In turn, the 'sensitive' sites MUST be aware that it is impossible in the long term to deny Internet access to crackers, disgruntled former employees, unscrupulous competitors or agents of other countries. Getting an offender flushed is at best a stop-gap, providing a breathing space of a day or an hour while the security holes he was attacking are closed. James Van Bokkelen April 2, 1990 INTRODUCTION These recommended guidelines address the entire Internet community, consisting of users, hosts, local, regional, domestic and international backbone networks, and vendors who supply operating systems, routers, network management tools, workstations and other network components. Security is understood to include protection of the privacy of information, protection of information against unauthorized modification, protection of systems against denial of service, and protection of systems against unauthorized access. These guidelines encompass six main points. These points are repeated and elaborated in the next section. In addition, an annotated bibliography of computer and network related references has been provided at the end of this document for use by the reader. ----------------------------------------------------------------------- SECURITY GUIDELINES 1) Users are individually responsible for understanding and respecting the security rules of the systems they are using. Users are individually accountable for their own behavior. 2) Users have responsibility to use available mechanisms and procedures for protecting their own data, and they also have responsibility for assisting in the protection of the systems they use. 3) Site and network service providers are responsible for maintaining the security of the systems they operate. 4) Vendors and system developers are responsible for providing systems which are sound and have adequate security controls. 5) Users, service providers and hardware and software vendors are expected to cooperate in the provision of security. 6) Technical improvements in Internet security protocols should be sought on a continuing basis. At the same time, Internet security implications should be considered by personnel working on new protocols, hardware systems and software systems. ELABORATION 1) Users are individually responsible for understanding and respecting the security rules of the systems they are using. Users are individually accountable for their own behavior. Users are responsible for their own behavior. Weaknesses in the security of a system are not a license to penetrate or abuse a system. Users are expected to be aware of the rules and adhere to them. One clear consequence is that breaking into computers is explicitly a violation of Internet rules of conduct, no matter how weak the protection is on those computers. There is growing international attention to legal prohibition against unauthorized access to computer systems, and several countries have recently passed legislation that addresses the area (e.g. United Kingdom, Australia). In the United States, the Computer Fraud and Abuse Act of 1986, Title 18 U.S.C. section 1030 makes it a crime, in certain situations, to access a Federal interest computer (federal government computers, financial institution computers, and a computer which is one of two or more computers used in committing the offense, not all of which are located in the same state) without authorization. Most of the 50 states have similar laws. Another aspect of this part of the policy is that users are individually responsible for all use of resources assigned to them, and hence sharing of accounts and access to resources is strongly discouraged. However, since access to resources is assigned by individual sites and network operators, the specific rules governing sharing of accounts and protection of access is necessarily left to them. 2) Users have responsibility to use available mechanisms and procedures for protecting their own data, and they also have responsibility for assisting in the protection of the systems they use. Users are expected to handle account privileges in a responsible manner and to follow site procedures for the security of their data as well as that of the system. This involves good password selection and maintenance. It also encompasses the proper use of file protections so as to maintain correct file access. 3) Site and network service providers are responsible for maintaining the security of the systems they operate. A 'site' is any organization that owns computers or network related resources. These resources may include host computers that users use, routers, terminal servers, personal computers or other devices that have access to the Internet. A site may be an end user of Internet services or a service provider such as a regional network. Primary responsibility for security necessarily rests with the owners and operators of the components of the Internet, that is, the host operators and network operators. The Internet itself is neither centrally managed nor operated, and hence there is no central authority for implementing or managing the security of the entire Internet. Moreover, even if there were a central authority, security necessarily is the responsibility of the people owning the data and systems involved, so local control is essential. There are tradeoffs between tight security at a site and usability of the systems. Tight security measures may make it more complicated for a user to access the Internet. If a site chooses to have open systems for the ease of use by its constituents, it also has a responsi- bility for the consequences of those open systems when they are exploited by unauthorized individuals. The readers are directed to appendix A for a descriptive list of elements of good security. To facilitate the adoption and implementation of good security practices at the site and network level, the Site Security Policy Handbook Working Group is developing a handbook with guidance on all of these matters. Sites and network operators are encouraged to review this material and use it freely. 4) Vendors and system developers are expected to provide systems which are sound and have adequate security controls. Vendors and system developers should evaluate systems in terms of security controls prior to the introduction of the system into the computing community. Products should be labeled according to security controls that are present. Vendors have a positive obligation to repair flaws in the security relevant portions of the systems they sell for use in the Internet. Vendors are also expected to cooperate with the Internet community as far as making security related fixes available to the entire community in a timely way. 5) Users, sites, networks and vendors are expected to provide mutual security assistance. The Internet is a cooperative venture. The culture and practice in the Internet is to render assistance in security matters to other sites and networks. A site is expected to notify other sites if it sees a penetration in progress at the other sites, and sites are expected to help other sites respond to security violations. This may include tracing connections, tracking violators and assisting law enforcement efforts. There is a growing appreciation within the Internet community that security violators should be identified and held accountable. This means that once a violation has been detected, sites are encouraged to cooperate in finding the violator and assisting in enforcement efforts. It is recognized that many sites will face a trade-off between securing their sites as rapidly as possible and limiting the knowledge of a penetration versus leaving their site open and/or exposing the fact that a penetration has occurred. This policy does not dictate that a site must expose either its system or its reputation if it decides not to, but sites are encouraged to render as much assistance as they can. 6) Technical improvements in Internet security protocols should be sought on a continuing basis. At the same time, Internet security implications should be considered by personnel working on new protocols, hardware systems and software systems. The points discussed above are all administrative in nature, but technical advances are also important. The existing protocols and operating systems do not provide the level of security that is desired or that is possible. Three types of advances are encouraged. (i) Improvements in the basic security mechanisms already in place. Password security is generally poor throughout the Internet and can be improved markedly through the use of tools to administer password assignment and through the use of better password protocols. At the same time, the user population is expanding to include a larger percentage of technically unsophisticated users. The defaults on delivered systems and the controls for administering security must be geared to this large and generally unsophisticated population. (ii) Security extensions to the protocol suite are needed. Candidate protocols which should be augmented to improve security include network management, routing, file transfer, telnet, mail, etc. (iii) Improvements in the design and implementation of operating systems to place more emphasis on security and pay more attention to the quality of the implementation of security within systems on the Internet. APPENDIX A Five areas should be addressed in improving local security: (i) There must be a clear statement of the local security policy, and this policy must be communicated to the users and other relevant parties. The policy should be on file and available to users at all times, and should be communicated to users as part of providing access to the system. (ii) Adequate security controls must be implemented. At a minimum, this means controlling access to systems via passwords -- and instituting sound password management! -- and configuring the system to protect itself and the information within it. (iii) There must be a capability to monitor security compliance and respond to incidents involving violation of security. Logs of logins and other security-relevant events are strongly advised, as well as regular audit of these logs. Also recommended is a capability to trace connections and other events in response to penetrations. However, it is important for service providers to have a well thought out and published policy about what information they gather, who has access to it and for what purposes. Maintaining the privacy of network users should be kept in mind when developing such a policy. (iv) There must be an established chain of communication and control to handle security matters. A responsible person should be identified as the security contact. The means for reaching the security contact should be made known to all users and should be registered in public directories, and it should be easy for computer emergency response centers to find contact information at any time. The security contact should be familiar with the technology and configuration of all systems at the site or should be able to get in touch with those who have this knowledge at any time. Likewise, the security contact should be pre-authorized to make a best effort to deal with a security incident, or should be able to contact those with the authority at any time. (v) Sites and networks which are notified of security incidents should respond in a timely and effective manner. In the case of penetrations or other violations, sites and networks should allocate resources and capabilities to identify the nature of the incident and limit the damage. A site or network cannot be considered to have good security if it does not respond to incidents in a timely and effective fashion. If a violator can be identified, appropriate action should be taken to ensure that no further violations are caused. Exactly what sanctions should be brought against a violator depend on the nature of the incident and the site environment. For example, a university may choose to bring internal disciplinary action against a student violator. Similarly, sites and networks should respond when notified of security flaws in their systems. Sites and networks have the responsibility to install fixes in their systems as they become available. An Annotated Bibliography of Computer and Network Security Related Documents Public Laws (PL) and Federal Policies [1] P.L. 100-235, _T_h_e _C_o_m_p_u_t_e_r _S_e_c_u_r_i_t_y _A_c_t _o_f _1_9_8_7, + Jan. 8, 1988. [2] P.L. 99-474 (H.R. 4718), _C_o_m_p_u_t_e_r _F_r_a_u_d _a_n_d _A_b_u_s_e _A_c_t _o_f _1_9_8_6, Oct. 16, 1986. [3] P.L. 99-508 (H.R. 4952), _E_l_e_c_t_r_o_n_i_c _C_o_m_m_u_n_i_c_a_t_i_o_n_s _P_r_i_v_a_c_y _A_c_t _o_f _1_9_8_6, Oct. 21, 1986. [4] P.L. 99-591, _P_a_p_e_r_w_o_r_k _R_e_d_u_c_t_i_o_n _R_e_a_u_t_h_o_r_i_z_a_t_i_o_n _A_c_t _o_f _1_9_8_6, Oct. 30, 1986. [5] P.L. 93-579, _P_r_i_v_a_c_y _A_c_t _o_f _1_9_8_4, Dec. 31, 1984. [6] _N_a_t_i_o_n_a_l _S_e_c_u_r_i_t_y _D_e_c_i_s_i_o_n _D_i_r_e_c_t_i_v_e _1_4_5. + [7] "Security of Federal Automated Information Systems", + Appendix III of, _M_a_n_a_g_e_m_e_n_t _o_f _F_e_d_e_r_a_l _I_n_f_o_r_m_a_t_i_o_n _R_e_s_o_u_r_c_e_s, Office of Management and Budget (OMB), Cir- cular A-130. [8] _P_r_o_t_e_c_t_i_o_n _o_f _G_o_v_e_r_n_m_e_n_t _C_o_n_t_r_a_c_t_o_r _T_e_l_e_c_o_m_m_u_n_i_c_a_t_i_o_n_s, + National Communications Security Instruction (NACSI) 6002. Miscellaneous Documents [9] "Summary of General Legislation Relating to Privacy and Computer Security", Appendix 1 of, _C_O_M_P_U_T_E_R_S _a_n_d _P_R_I_V_A_C_Y: _H_o_w _t_h_e _G_o_v_e_r_n_m_e_n_t _O_b_t_a_i_n_s, _V_e_r_i_f_i_e_s, _U_s_e_s _a_n_d _P_r_o_t_e_c_t_s _P_e_r_s_o_n_a_l _D_a_t_a, GAO/IMTEC-90-70BR, United States General Accounting Office, Washington, DC 20548, pp. 36-40, Aug. 1990. _________________________ + Contained in Appendix C of Citation No. 13. [10] _D_e_f_e_n_d_i_n_g _S_e_c_r_e_t_s, _S_h_a_r_i_n_g _D_a_t_a, OTA-CIT-310, Congress of the United States, Office of Technology Assessment, Washington, D.C. 20510, Oct. 1987. [11] _E_l_e_c_t_r_o_n_i_c _R_e_c_o_r_d _S_y_s_t_e_m_s _a_n_d _I_n_d_i_v_i_d_u_a_l _P_r_i_v_a_c_y, OTA- CIT-296, Congress of the United States, Office of Tech- nology Assessment, Washington, D.C. 20510, June 1986. [12] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. I, Industry Information Security Task Force, President's National Telecommunications Advisory Committee, June 1988. [13] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. II, Annex C, "IIS Task Force Supporting Documents", (a compendium of documents related to computer security policy), Indus- try Information Security Task Force, President's National Telecommunications Advisory Committee, June 1988. [14] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. III, "Annotated Bibliography", President's National Telecommunications Advisory Committee, Industry Information Security Task Force, June 1988. [15] David A. Curry, _I_m_p_r_o_v_i_n_g _t_h_e _S_e_c_u_r_i_t_y _o_f _Y_o_u_r _U_N_I_X _S_y_s_t_e_m, Report No. ITSTD-721-FR-90-21, SRI Interna- tional, 333 Ravenswood Av., Menlo Park, CA, 94025-3493, April 1990. [16] G. F. Jelen, _I_n_f_o_r_m_a_t_i_o_n _S_e_c_u_r_i_t_y: _A_n _E_l_u_s_i_v_e _G_o_a_l, Report No. P-85-8, Harvard University, Center for Information Policy Research, 200 Akin, Cambridge, MA. 02138, June 1985. [17] Agne Lindberg, _E_l_e_c_t_r_o_n_i_c _D_o_c_u_m_e_n_t_s _a_n_d _E_l_e_c_t_r_o_n_i_c _S_i_g_- _n_a_t_u_r_e_s, (Publisher unknown). [18] Elain Stout, _U._S. _G_e_o_l_o_g_i_c_a_l _S_u_r_v_e_y _S_y_s_t_e_m _S_e_c_u_r_i_t_y _P_l_a_n - _F_Y _1_9_9_0, U.S. Geological Survey ISD, MS809, Res- ton, VA, 22092, May 1990.   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa15007; 22 Mar 91 12:01 EST Received: from SPARKY.CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa14523; 22 Mar 91 11:55 EST Received: from localhost by sparky.cert.sei.cmu.edu (5.65/2.3) id AA13056; Fri, 22 Mar 91 11:56:42 -0500 Message-Id: <9103221656.AA13056@sparky.cert.sei.cmu.edu> To: cerf@NRI.Reston.VA.US, crocker@tis.com, pgross@NRI.Reston.VA.US, gvaudre@NRI.Reston.VA.US Cc: saag@tis.com, spwg@NRI.Reston.VA.US Subject: Final Document Date: Fri, 22 Mar 91 11:56:41 EST From: Barbara Fraser Here's the final document as submitted to internet-drafts@nri.reston.va.us. 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 spwg@nri.reston.va.us. PREAMBLE The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. Comments by Vinton G. Cerf, Vice President, Corporation for National Research Initiatives, and Chairman, Internet Engineering Task Force, and James Van Bokkelen, President, FTP Software, Inc., have been provided to further illuminate the history and issues involved in this policy. In the early 1970's, the "Internet" was a research project sponsored by the U.S. Defense Advanced Research Projects Agency (DARPA), to explore technology for interlinking packet switching networks. Even in its early phases, the exploration involved international participation, notably University College London and, later, the participants in the Atlantic Satellite Network (SATNET) which included the Norwegian Defense Research Establishment, The Norwegian Telecommunications Administration Research Establishment, the German Air and Space Research Establishment (DFVLR), the Royal Signals and RADAR Establishment (RSRE), and CNUCE, an institute of the Italian Research Council (CNR). In the ensuing fifteen years, the Internet has grown much larger and also more diverse. Its participants include government institutions and agencies, academic and research institutions, commercial network and electronic mail carriers, non-profit research centers and an increasing array of industrial players who are primarily users of the technology. Despite this dramatic growth, the system is still operated on a purely collaborative basis. Participating networks take responsibility for their own operation. Service providers, private network operators, users and vendors all cooperate to keep the system functioning. It is important to recognize that the voluntary nature of the Internet system is both its strength and, perhaps, its most fragile aspect. Rules of operation, like the rules of etiquette, are voluntary and, largely, unenforceable, except where they happen to coincide with national laws whose violation can lead to prosecution. A common set of rules for the successful and increasingly secure operation of the Internet can, at best, be voluntary, since the laws of various countries are not uniform regarding data networking. Indeed, the recommended guidelines outlined below can also only be voluntary. However, since joining the Internet is optional, it is also fair to argue that the Internet Rules of Behavior are part of the bargain for joining and that failure to observe, apart from any legal infrastructure available, are grounds for sanctions. Vinton G. Cerf October 1990 The following is an excerpt from "The Internet Oral Tradition", published as RFC 1173. Every host and network manager MUST be aware that the Internet as presently constituted is NOT secure. At the protocol level, much more effort has been put into interoperability, reliability and convenience than has been devoted to security, although this is changing. Recent events have made software developers and vendors more sensitive to security, in both configuration and the underlying implementation, but it remains to be demonstrated how much long-term effect this will have. Meanwhile, the existing system survives through the co-operation of all responsible individuals. Security is subjective; one site might view as idle curiosity what another would see as a hostile probe. Since ultimately the existence of the Internet depends on its usefulness to all members of the community, it is important for managers to be willing to accept and act on other sites' security issues, warning or denying access to offending users. The offended site, in turn, must be reasonable in its demands (someone who set off an alarm while idly seeing if the sendmail 'DEBUG' hole was closed on a 'sensitive' host probably should be warned, rather than prosecuted). Because Internet security issues may require that local management people either get in touch with any of their users, or deny an offending individual or group access to other sites, it is necessary that mechanisms exist to allow this. . . .In turn, the 'sensitive' sites MUST be aware that it is impossible in the long term to deny Internet access to crackers, disgruntled former employees, unscrupulous competitors or agents of other countries. Getting an offender flushed is at best a stop-gap, providing a breathing space of a day or an hour while the security holes he was attacking are closed. James Van Bokkelen April 2, 1990 INTRODUCTION These recommended guidelines address the entire Internet community, consisting of users, hosts, local, regional, domestic and international backbone networks, and vendors who supply operating systems, routers, network management tools, workstations and other network components. Security is understood to include protection of the privacy of information, protection of information against unauthorized modification, protection of systems against denial of service, and protection of systems against unauthorized access. These guidelines encompass six main points. These points are repeated and elaborated in the next section. In addition, an annotated bibliography of computer and network related references has been provided at the end of this document for use by the reader. ----------------------------------------------------------------------- SECURITY GUIDELINES 1) Users are individually responsible for understanding and respecting the security rules of the systems they are using. Users are individually accountable for their own behavior. 2) Users have responsibility to use available mechanisms and procedures for protecting their own data, and they also have responsibility for assisting in the protection of the systems they use. 3) Site and network service providers are responsible for maintaining the security of the systems they operate. 4) Vendors and system developers are responsible for providing systems which are sound and have adequate security controls. 5) Users, service providers and hardware and software vendors are expected to cooperate in the provision of security. 6) Technical improvements in Internet security protocols should be sought on a continuing basis. At the same time, Internet security implications should be considered by personnel working on new protocols, hardware systems and software systems. ELABORATION 1) Users are individually responsible for understanding and respecting the security rules of the systems they are using. Users are individually accountable for their own behavior. Users are responsible for their own behavior. Weaknesses in the security of a system are not a license to penetrate or abuse a system. Users are expected to be aware of the rules and adhere to them. One clear consequence is that breaking into computers is explicitly a violation of Internet rules of conduct, no matter how weak the protection is on those computers. There is growing international attention to legal prohibition against unauthorized access to computer systems, and several countries have recently passed legislation that addresses the area (e.g. United Kingdom, Australia). In the United States, the Computer Fraud and Abuse Act of 1986, Title 18 U.S.C. section 1030 makes it a crime, in certain situations, to access a Federal interest computer (federal government computers, financial institution computers, and a computer which is one of two or more computers used in committing the offense, not all of which are located in the same state) without authorization. Most of the 50 states have similar laws. Another aspect of this part of the policy is that users are individually responsible for all use of resources assigned to them, and hence sharing of accounts and access to resources is strongly discouraged. However, since access to resources is assigned by individual sites and network operators, the specific rules governing sharing of accounts and protection of access is necessarily left to them. 2) Users have responsibility to use available mechanisms and procedures for protecting their own data, and they also have responsibility for assisting in the protection of the systems they use. Users are expected to handle account privileges in a responsible manner and to follow site procedures for the security of their data as well as that of the system. This involves good password selection and maintenance. It also encompasses the proper use of file protections so as to maintain correct file access. 3) Site and network service providers are responsible for maintaining the security of the systems they operate. A 'site' is any organization that owns computers or network related resources. These resources may include host computers that users use, routers, terminal servers, personal computers or other devices that have access to the Internet. A site may be an end user of Internet services or a service provider such as a regional network. Primary responsibility for security necessarily rests with the owners and operators of the components of the Internet, that is, the host operators and network operators. The Internet itself is neither centrally managed nor operated, and hence there is no central authority for implementing or managing the security of the entire Internet. Moreover, even if there were a central authority, security necessarily is the responsibility of the people owning the data and systems involved, so local control is essential. There are tradeoffs between tight security at a site and usability of the systems. Tight security measures may make it more complicated for a user to access the Internet. If a site chooses to have open systems for the ease of use by its constituents, it also has a responsi- bility for the consequences of those open systems when they are exploited by unauthorized individuals. The readers are directed to appendix A for a descriptive list of elements of good security. To facilitate the adoption and implementation of good security practices at the site and network level, the Site Security Policy Handbook Working Group is developing a handbook with guidance on all of these matters. Sites and network operators are encouraged to review this material and use it freely. 4) Vendors and system developers are expected to provide systems which are sound and have adequate security controls. Vendors and system developers should evaluate systems in terms of security controls prior to the introduction of the system into the computing community. Products should be labeled according to security controls that are present. Vendors have a positive obligation to repair flaws in the security relevant portions of the systems they sell for use in the Internet. Vendors are also expected to cooperate with the Internet community as far as making security related fixes available to the entire community in a timely way. 5) Users, sites, networks and vendors are expected to provide mutual security assistance. The Internet is a cooperative venture. The culture and practice in the Internet is to render assistance in security matters to other sites and networks. A site is expected to notify other sites if it sees a penetration in progress at the other sites, and sites are expected to help other sites respond to security violations. This may include tracing connections, tracking violators and assisting law enforcement efforts. There is a growing appreciation within the Internet community that security violators should be identified and held accountable. This means that once a violation has been detected, sites are encouraged to cooperate in finding the violator and assisting in enforcement efforts. It is recognized that many sites will face a trade-off between securing their sites as rapidly as possible and limiting the knowledge of a penetration versus leaving their site open and/or exposing the fact that a penetration has occurred. This policy does not dictate that a site must expose either its system or its reputation if it decides not to, but sites are encouraged to render as much assistance as they can. 6) Technical improvements in Internet security protocols should be sought on a continuing basis. At the same time, Internet security implications should be considered by personnel working on new protocols, hardware systems and software systems. The points discussed above are all administrative in nature, but technical advances are also important. The existing protocols and operating systems do not provide the level of security that is desired or that is possible. Three types of advances are encouraged. (i) Improvements in the basic security mechanisms already in place. Password security is generally poor throughout the Internet and can be improved markedly through the use of tools to administer password assignment and through the use of better password protocols. At the same time, the user population is expanding to include a larger percentage of technically unsophisticated users. The defaults on delivered systems and the controls for administering security must be geared to this large and generally unsophisticated population. (ii) Security extensions to the protocol suite are needed. Candidate protocols which should be augmented to improve security include network management, routing, file transfer, telnet, mail, etc. (iii) Improvements in the design and implementation of operating systems to place more emphasis on security and pay more attention to the quality of the implementation of security within systems on the Internet. APPENDIX A Five areas should be addressed in improving local security: (i) There must be a clear statement of the local security policy, and this policy must be communicated to the users and other relevant parties. The policy should be on file and available to users at all times, and should be communicated to users as part of providing access to the system. (ii) Adequate security controls must be implemented. At a minimum, this means controlling access to systems via passwords -- and instituting sound password management! -- and configuring the system to protect itself and the information within it. (iii) There must be a capability to monitor security compliance and respond to incidents involving violation of security. Logs of logins and other security-relevant events are strongly advised, as well as regular audit of these logs. Also recommended is a capability to trace connections and other events in response to penetrations. However, it is important for service providers to have a well thought out and published policy about what information they gather, who has access to it and for what purposes. Maintaining the privacy of network users should be kept in mind when developing such a policy. (iv) There must be an established chain of communication and control to handle security matters. A responsible person should be identified as the security contact. The means for reaching the security contact should be made known to all users and should be registered in public directories, and it should be easy for computer emergency response centers to find contact information at any time. The security contact should be familiar with the technology and configuration of all systems at the site or should be able to get in touch with those who have this knowledge at any time. Likewise, the security contact should be pre-authorized to make a best effort to deal with a security incident, or should be able to contact those with the authority at any time. (v) Sites and networks which are notified of security incidents should respond in a timely and effective manner. In the case of penetrations or other violations, sites and networks should allocate resources and capabilities to identify the nature of the incident and limit the damage. A site or network cannot be considered to have good security if it does not respond to incidents in a timely and effective fashion. If a violator can be identified, appropriate action should be taken to ensure that no further violations are caused. Exactly what sanctions should be brought against a violator depend on the nature of the incident and the site environment. For example, a university may choose to bring internal disciplinary action against a student violator. Similarly, sites and networks should respond when notified of security flaws in their systems. Sites and networks have the responsibility to install fixes in their systems as they become available. An Annotated Bibliography of Computer and Network Security Related Documents Public Laws (PL) and Federal Policies [1] P.L. 100-235, _T_h_e _C_o_m_p_u_t_e_r _S_e_c_u_r_i_t_y _A_c_t _o_f _1_9_8_7, + Jan. 8, 1988. [2] P.L. 99-474 (H.R. 4718), _C_o_m_p_u_t_e_r _F_r_a_u_d _a_n_d _A_b_u_s_e _A_c_t _o_f _1_9_8_6, Oct. 16, 1986. [3] P.L. 99-508 (H.R. 4952), _E_l_e_c_t_r_o_n_i_c _C_o_m_m_u_n_i_c_a_t_i_o_n_s _P_r_i_v_a_c_y _A_c_t _o_f _1_9_8_6, Oct. 21, 1986. [4] P.L. 99-591, _P_a_p_e_r_w_o_r_k _R_e_d_u_c_t_i_o_n _R_e_a_u_t_h_o_r_i_z_a_t_i_o_n _A_c_t _o_f _1_9_8_6, Oct. 30, 1986. [5] P.L. 93-579, _P_r_i_v_a_c_y _A_c_t _o_f _1_9_8_4, Dec. 31, 1984. [6] _N_a_t_i_o_n_a_l _S_e_c_u_r_i_t_y _D_e_c_i_s_i_o_n _D_i_r_e_c_t_i_v_e _1_4_5. + [7] "Security of Federal Automated Information Systems", + Appendix III of, _M_a_n_a_g_e_m_e_n_t _o_f _F_e_d_e_r_a_l _I_n_f_o_r_m_a_t_i_o_n _R_e_s_o_u_r_c_e_s, Office of Management and Budget (OMB), Cir- cular A-130. [8] _P_r_o_t_e_c_t_i_o_n _o_f _G_o_v_e_r_n_m_e_n_t _C_o_n_t_r_a_c_t_o_r _T_e_l_e_c_o_m_m_u_n_i_c_a_t_i_o_n_s, + National Communications Security Instruction (NACSI) 6002. Miscellaneous Documents [9] "Summary of General Legislation Relating to Privacy and Computer Security", Appendix 1 of, _C_O_M_P_U_T_E_R_S _a_n_d _P_R_I_V_A_C_Y: _H_o_w _t_h_e _G_o_v_e_r_n_m_e_n_t _O_b_t_a_i_n_s, _V_e_r_i_f_i_e_s, _U_s_e_s _a_n_d _P_r_o_t_e_c_t_s _P_e_r_s_o_n_a_l _D_a_t_a, GAO/IMTEC-90-70BR, United States General Accounting Office, Washington, DC 20548, pp. 36-40, Aug. 1990. _________________________ + Contained in Appendix C of Citation No. 13. [10] _D_e_f_e_n_d_i_n_g _S_e_c_r_e_t_s, _S_h_a_r_i_n_g _D_a_t_a, OTA-CIT-310, Congress of the United States, Office of Technology Assessment, Washington, D.C. 20510, Oct. 1987. [11] _E_l_e_c_t_r_o_n_i_c _R_e_c_o_r_d _S_y_s_t_e_m_s _a_n_d _I_n_d_i_v_i_d_u_a_l _P_r_i_v_a_c_y, OTA- CIT-296, Congress of the United States, Office of Tech- nology Assessment, Washington, D.C. 20510, June 1986. [12] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. I, Industry Information Security Task Force, President's National Telecommunications Advisory Committee, June 1988. [13] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. II, Annex C, "IIS Task Force Supporting Documents", (a compendium of documents related to computer security policy), Indus- try Information Security Task Force, President's National Telecommunications Advisory Committee, June 1988. [14] _I_n_d_u_s_t_r_y _I_n_f_o_r_m_a_t_i_o_n _P_r_o_t_e_c_t_i_o_n, Vol. III, "Annotated Bibliography", President's National Telecommunications Advisory Committee, Industry Information Security Task Force, June 1988. [15] David A. Curry, _I_m_p_r_o_v_i_n_g _t_h_e _S_e_c_u_r_i_t_y _o_f _Y_o_u_r _U_N_I_X _S_y_s_t_e_m, Report No. ITSTD-721-FR-90-21, SRI Interna- tional, 333 Ravenswood Av., Menlo Park, CA, 94025-3493, April 1990. [16] G. F. Jelen, _I_n_f_o_r_m_a_t_i_o_n _S_e_c_u_r_i_t_y: _A_n _E_l_u_s_i_v_e _G_o_a_l, Report No. P-85-8, Harvard University, Center for Information Policy Research, 200 Akin, Cambridge, MA. 02138, June 1985. [17] Agne Lindberg, _E_l_e_c_t_r_o_n_i_c _D_o_c_u_m_e_n_t_s _a_n_d _E_l_e_c_t_r_o_n_i_c _S_i_g_- _n_a_t_u_r_e_s, (Publisher unknown). [18] Elain Stout, _U._S. _G_e_o_l_o_g_i_c_a_l _S_u_r_v_e_y _S_y_s_t_e_m _S_e_c_u_r_i_t_y _P_l_a_n - _F_Y _1_9_9_0, U.S. Geological Survey ISD, MS809, Res- ton, VA, 22092, May 1990.   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa03291; 17 May 91 8:20 EDT Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa03115; 17 May 91 8:11 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06705; Fri, 17 May 91 08:09:13 EDT Message-Id: <9105171209.AA06705@TIS.COM> To: spwg@NRI.Reston.VA.US, saag@tis.com Subject: [Michael I Bushnell: Proposed RFC `Guidelines for the Secure Operation of the Internet'] Date: Fri, 17 May 91 08:09:12 -0400 From: Stephen D Crocker In case you didn't already see this, these are interesting comments. Rich, Barbara or others: We should attempt to explicate or respond. Steve ------- Forwarded Message Date: Fri, 17 May 91 01:36:30 -0400 From: Michael I Bushnell To: postel@isi.edu, iab@isi.edu Cc: iesg@NRI.Reston.VA.US, ietf@isi.edu Subject: Proposed RFC `Guidelines for the Secure Operation of the Internet' This document suffers from a serious flaw, which causes it to be very difficult to use. It fails to describe which local security features are advice to participants in the internet for their own good, and which features are things all good net-citizens should do. For example, it says: (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. Does this mean that a site which chooses not to exercise strict password management, and is willing to assume the risk that it might be damaged, is being a bad citizen, or is it simply an indication that such a site needs to be aware of the risk it is undertaking? If this is merely advice to system administrators, then that is well and good, and, in fact, it is good advice. But a better wording would be "Without adequate security controls, systems are can be highly vulnerable. Minimal security necessary to prevent severe vulnerability includes passwords (with sound password management) and proper system configuration." Such a wording would leave open the possibility that a site is willing to be vulnerable, and accepts the risk itself. Another example: 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. Does this section mean that I, as an OS developer, am obligated to provide and maintain security features, or is it an indication that a "good" OS developer does so, or is it simply helpful advice to people selling and writing software? My software is not sold. Does this change the positive obligation at all? Here's another: 5) Users, sites, networks and vendors are expected to provide mutual security assistance. This doesn't even happen from CERT! CERT consistently refuses to explain the nature of security flaws in vendors' software, despite full knowledge of the nature of the flaw. For example, the recent telnetd bug had fixes posted for SunOS, but there was no description of the nature of the bug. My email queries went unanswered. I had to find out the nature of the bug, so I could check our software for it, from the grapevine and people who read comp.unix.wizards. If CERT can't be expected to provide security assistance, who can? If CERT is to be the standard for this kind of assistance, then some kind of distinction needs to be made between helping people deal with existing attacks (which CERT does well) and helping people avoid future attacks (which CERT does spottily, at best). I don't expect an immediate answer to these questions. I'm trying to point out what I see as a serious flaw in the document. I'd like to see the IESG revise it, and make it much clearer which things are mandatory, which are part of good net citizenship, and which are simply helpful advice. I hope it isn't too late for this to happen. I'd hate to see policies get enshrined without an understanding of the various security requirements the diverse systems on the internet have, especially including open systems. Something else to consider: At some point, theoretically, the internet will be accessed through commercial service providers. If systems are going to be required to have some particular security level, that become useless when anyone gets on the net. A good analogy comes from usenet. In the "early days", system administrators were all "good people", and you could implicitly trust them. Many, many sites honored all `rmgroup' messages without question. Now that usenet has branched out, and become wildly successful, one can no longer expect other system administrators to secure one's own news system. Almost nobody honors all `rmgroup' messages anymore. When the internet becomes this spread out, will we still be relying on other systems to provide security for our own, or will we realize that other systems fundamentally cannot be expected to secure themselves merely for our own sake? -mib ------- End of Forwarded Message   Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa17763; 3 Jun 91 17:35 EDT Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2) id AA05492; Mon, 3 Jun 91 16:55:36 -0400 Received: by nic.cic.net (4.1/SMI-4.1) id AA04803; Mon, 3 Jun 91 17:07:52 EDT Message-Id: <9106032107.AA04803@nic.cic.net> To: ssphwg@cert.sei.cmu.edu, spwg@cert.sei.cmu.edu Cc: saag@tis.com, tech-interest@cic.net Subject: Site Security Policy Handbook Draft Reply-To: holbrook@cic.net Date: Mon, 03 Jun 91 17:07:49 -0400 From: J Paul Holbrook The Site Security Policy Handbook is now available as an Internet Draft. This version is an extensive rewrite of the draft of November, 1990. This document is open for comments for the month of June. We'll take all comments we get in July, and assuming they don't mandate a major rewrite, we'll fold them in and submit this document as an RFC in July. Many thanks to all who commented and worked on this draft; special thanks to Barbara Fraser of CERT for reworking Chapter 2. This document is also available in the ssphwg archive directory (cert.sei.cmu.edu:/pub/ssphwg). (I apologize to those of you on the IETF list who have seen this.) SSPHWG co-chairs J. Paul Holbrook CICNet holbrook@cic.net Joyce K. Reynolds ISI/USC jkrey@isi.edu ------- Forwarded Message To: ietf@isi.edu Cc: internet-drafts@nri.reston.va.us Subject: ID ACTION:draft-ietf-ssph-handbook-00.txt Date: Mon, 03 Jun 91 09:51:22 -0400 From: Candice Moshos Message-Id: <9106030951.aa06144@NRI.NRI.Reston.VA.US> A New Internet Draft is available from the on-line Internet-Drafts directories. Title : Security Policy Handbook Author(s) : Paul Holbrook, Joyce Reynolds Filename : draft-ietf-ssph-handbook-00.txt This handbook is the product of the Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF). This RFC provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, type "cd internet-drafts". Type "get draft-ietf-ssph-handbook-00.txt". Internet-Drafts directories are located at: o NSF Network Service Center (East Coast) Address: nnsc.nsf.net (192.31.103.6) o Defense Data Network NIC (West Coast) Address: nic.ddn.mil (192.67.67.20) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Nordunet NIC (Europe) Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: SERVICE@nic.ddn.mil Subject line: SEND INTERNET-DRAFTS:draft-ietf-ssph-handbook-00.txt For questions, please mail to internet-drafts@nri.reston.va.us. ------- End of Forwarded Message   Received: from CERT.SEI.CMU.EDU by NRI.NRI.Reston.VA.US id aa19328; 3 Jun 91 19:16 EDT Received: from frisby.CS.ORST.EDU by cert.sei.cmu.edu (5.65/2.2) id AA06590; Mon, 3 Jun 91 18:42:42 -0400 Received: from frisby.CS.ORST.EDU by frisby.CS.ORST.EDU (4.1/1.30) id AA27317; Mon, 3 Jun 91 15:50:40 PDT Message-Id: <9106032250.AA27317@frisby.CS.ORST.EDU> To: holbrook@cic.net Cc: ssphwg@cert.sei.cmu.edu, spwg@cert.sei.cmu.edu Subject: Re: Site Security Policy Handbook Draft In-Reply-To: Your message of Mon, 03 Jun 91 17:07:49 EDT. <9106032107.AA04803@nic.cic.net> Date: Mon, 03 Jun 91 15:50:31 PDT From: sechrest@frisby.cs.orst.edu MMDF-Warning: Parse error in original version of preceding line at NRI.NRI.Reston.VA.US -------- I would like to use the SSPH as a piece of workshop on security tuning of Unix systems. Does anyone see a problem with doing this? I will be giving the workshop on 8/7 and 8/8. ----- John Sechrest . Internet: sechrest@cs.orst.edu Lab Coordinator . UUCP: hplabs!hp-pcd!orstcs!sechrest Computer Science Dept . Oregon State University . Corvallis,Oregon 97331 . (503) 737-3273 .   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa05334; 4 Jun 91 9:22 EDT Received: from nic.cic.net by NRI.NRI.Reston.VA.US id aa05206; 4 Jun 91 9:16 EDT Received: by nic.cic.net (4.1/SMI-4.1) id AA05303; Tue, 4 Jun 91 09:22:35 EDT Message-Id: <9106041322.AA05303@nic.cic.net> To: spwg@NRI.Reston.VA.US Subject: Site Security Handbook Draft Date: Tue, 04 Jun 91 09:22:33 -0400 From: J Paul Holbrook I mistyped the address for this group .. again, my apologies to those (most?) of you who have seen this already, but I did want to make sure everyone had a chance to see it. Paul Holbrook holbrook@cic.net SSPHWG co-chair ------- Forwarded Message Message-Id: <9106032107.AA04803@nic.cic.net> To: ssphwg@cert.sei.cmu.edu, spwg@cert.sei.cmu.edu Cc: saag@tis.com, tech-interest@cic.net Subject: Site Security Policy Handbook Draft Reply-To: holbrook@cic.net Date: Mon, 03 Jun 91 17:07:49 -0400 From: J Paul Holbrook The Site Security Policy Handbook is now available as an Internet Draft. This version is an extensive rewrite of the draft of November, 1990. This document is open for comments for the month of June. We'll take all comments we get in July, and assuming they don't mandate a major rewrite, we'll fold them in and submit this document as an RFC in July. Many thanks to all who commented and worked on this draft; special thanks to Barbara Fraser of CERT for reworking Chapter 2. This document is also available in the ssphwg archive directory (cert.sei.cmu.edu:/pub/ssphwg). (I apologize to those of you on the IETF list who have seen this.) SSPHWG co-chairs J. Paul Holbrook CICNet holbrook@cic.net Joyce K. Reynolds ISI/USC jkrey@isi.edu - ------- Forwarded Message To: ietf@isi.edu Cc: internet-drafts@nri.reston.va.us Subject: ID ACTION:draft-ietf-ssph-handbook-00.txt Date: Mon, 03 Jun 91 09:51:22 -0400 From: Candice Moshos Message-Id: <9106030951.aa06144@NRI.NRI.Reston.VA.US> A New Internet Draft is available from the on-line Internet-Drafts directories. Title : Security Policy Handbook Author(s) : Paul Holbrook, Joyce Reynolds Filename : draft-ietf-ssph-handbook-00.txt This handbook is the product of the Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF). This RFC provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, type "cd internet-drafts". Type "get draft-ietf-ssph-handbook-00.txt". Internet-Drafts directories are located at: o NSF Network Service Center (East Coast) Address: nnsc.nsf.net (192.31.103.6) o Defense Data Network NIC (West Coast) Address: nic.ddn.mil (192.67.67.20) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Nordunet NIC (Europe) Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: SERVICE@nic.ddn.mil Subject line: SEND INTERNET-DRAFTS:draft-ietf-ssph-handbook-00.txt For questions, please mail to internet-drafts@nri.reston.va.us. - ------- End of Forwarded Message ------- End of Forwarded Message   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa21447; 10 Jun 91 15:56 EDT Received: from vmcms.csuohio.edu by NRI.NRI.Reston.VA.US id aa21287; 10 Jun 91 15:48 EDT Received: from VMCMS.CSUOHIO.EDU by VMCMS.CSUOHIO.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1331; Mon, 10 Jun 91 15:49:02 EST Date: Mon, 10 Jun 91 15:48:57 EST From: "John P. Nolan" To: spwg@NRI.Reston.VA.US Message-ID: <9106101548.aa21287@NRI.NRI.Reston.VA.US> In November 90 I recieved a draft of "Internet Security Recommendations" This is a topic of high interest to me, as I'm trying to research this topic for our regional network (OARNet). Could you let me know if there have been any developments in this area. Has this document been updated (please send the revision over the net)? Has the document gone forward & recieved more approvals or is it ready to be adopted, or is it a defacto standard pending the formal completion? Any help would be appreciated. I will be discussing this on Wed 6/12, with our regional network group. John Nolan Manager of Technical Support Cleveland State University Phone: 216-687-2150 Bitnet: S0001@CSUOHIO InterNet: S0001@VMCMS.CSUOHIO.EDU   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa10815; 18 Jun 91 12:36 EDT Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa10634; 18 Jun 91 12:28 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA15022; Tue, 18 Jun 91 11:21:49 EDT Message-Id: <9106181521.AA15022@TIS.COM> Reply-To: James M Galvin To: saag@tis.com Cc: Security Policy Working Group Subject: [Internet Security Guidelines I-D FROM: Steve Kent] Date: Tue, 18 Jun 91 11:21:48 -0400 From: James M Galvin This message speaks for itself. Just for your information. Jim ------- Forwarded Message Message-ID: <9106172157.AA09118@venera.isi.edu> From: Steve Kent To: iab@ISI.EDU, ietf@ISI.EDU 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 spwg@nri.reston.va.us. PREAMBLE The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. 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. 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 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. 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 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, 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. [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. [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   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa16357; 18 Jun 91 16:37 EDT Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa16136; 18 Jun 91 16:27 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA23300; Tue, 18 Jun 91 16:28:00 EDT Message-Id: <9106182028.AA23300@TIS.COM> Reply-To: James M Galvin To: saag@tis.com Cc: Security Policy Working Group Subject: [re: Internet Security Guidelines I-D FROM: Craig Partridge] Date: Tue, 18 Jun 91 16:27:59 -0400 From: James M Galvin Comments from Craig Partridge. Jim ------- Forwarded Message Message-ID: <9106180724.AA14000@garuda.sics.se> Sender: craig@sics.se From: Craig Partridge To: Steve Kent cc: iab@ISI.EDU, ietf@ISI.EDU Date: Tue, 18 Jun 91 09:24:09 +0200 Subject: re: Internet Security Guidelines I-D Steve: I've got a comment. I'm deeply distressed by the guidelines which place responsibilities on the users without placing any responsibilities on providers to notify users. In my experience, some level of "abuse" is by users who aren't told what's correct. So I'd change item (3) from > 3) Computer and network service providers are responsible > for maintaining the security of the systems they operate. to + 3) Computer and network service providers are responsible + for maintaining the security of the systems they operate + and for notifying users of their security policies + and any changes to their security policies. Yes I know about the old saw "ignorance of the law is not a defense" however, we have mechanisms in society at large to make people aware of the laws they are living under (e.g. driver's tests, civics laws, newspapers, etc.) -- we should make sure that a similar information mechanism is available on networks. (I note that Appendix A(i) mentions this need, but I believe it must be stated more forcefully as an integral part of the system). Craig ------- End of Forwarded Message   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa06964; 19 Jun 91 9:31 EDT Received: from mwunix.mitre.org by NRI.NRI.Reston.VA.US id aa06379; 19 Jun 91 9:17 EDT Return-Path: Received: from chance.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA13048; Wed, 19 Jun 91 09:17:07 -0400 Received: from loghost.mitre.org by chance.mitre.org (4.0/SMI-4.0) id AA01208; Wed, 19 Jun 91 09:20:00 EDT Message-Id: <9106191320.AA01208@chance.mitre.org> To: spwg@NRI.Reston.VA.US Subject: Re: Internet Security Guidelines I-D Date: Wed, 19 Jun 91 09:19:58 -0400 From: "H. Craig McKee" >[6] National Security >Decision Directive 145. + NSDD 145 was superseded by NSD 42, which is classified Secret, suggest delete. The recent draft SSPHWG RFC has an annotated bibliography that includes some good tutorial manuals done the National Computer Security Center. Regards - Craig   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa06582; 21 Jun 91 9:13 EDT Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa06525; 21 Jun 91 9:09 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA03932; Fri, 21 Jun 91 09:11:07 EDT Message-Id: <9106211311.AA03932@TIS.COM> Reply-To: James M Galvin To: Security Policy Working Group Cc: saag@tis.com Subject: [Re: Internet Security Guidelines I-D FROM: Steve Kent] Date: Fri, 21 Jun 91 09:11:05 -0400 From: James M Galvin For completeness. Jim ------- Forwarded Message Message-ID: <9106202242.AA23633@venera.isi.edu> From: Steve Kent To: Craig Partridge cc: iab@ISI.EDU, ietf@ISI.EDU Date: Thu, 20 Jun 91 18:33:25 -0400 Subject: Re: Internet Security Guidelines I-D Craig, First, let me observe that the part of the policy guidelines that caught your attention is one which I did not significantly change, i.e., your objection was equally valid with regard to the text approved by the IESG and sent to the IAB. So, your comment should be viewed as indicative of an oversight in the course of the prior IESG review, not a comment about a revision as sent to the IESG by the IAB. Second, I agree with your concern, but note that the first item in the Appendix of the document explicitly mentions site responsibility for making local security policy known, I quote from the original ID: "(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." So, the question may be whether this warrents inclusion in one of the top level guidelines as you suggest, or whether the discussion in the Appendix suffices. I have no objection to making this consideration more prominent, but I'll leave it to the original authors to perform the next round of edits. Steve ------- End of Forwarded Message   Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa10803; 24 Jun 91 10:46 EDT Received: from JUPITER.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA26220; Mon, 24 Jun 91 10:48:02 EDT Message-Id: <9106241448.AA26220@TIS.COM> To: Craig Partridge , iab@isi.edu, iesg@NRI.Reston.VA.US Cc: spwg@NRI.Reston.VA.US Subject: Point of order re: Internet Security Guidelines I-D In-Reply-To: Your message of Mon, 24 Jun 91 08:41:46 +0200. <9106240641.AA24672@garuda.sics.se> Date: Mon, 24 Jun 91 10:47:32 -0400 From: Stephen D Crocker Let's move further discussion of the merits and specifics of the Internet Security Guidelines I-D back to the SPWG mailing list (spwg@nri.reston.va.us). It's evident that the IAB has not accepted the document in its current form and that additional work is needed. The authors will make the necessary changes as soon as possible and it will be resubmitted as an I-D. Thanks, Steve   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa10993; 24 Jun 91 10:54 EDT Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa10803; 24 Jun 91 10:46 EDT Received: from JUPITER.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA26220; Mon, 24 Jun 91 10:48:02 EDT Message-Id: <9106241448.AA26220@TIS.COM> To: Craig Partridge , iab@isi.edu, iesg@NRI.Reston.VA.US Cc: spwg@NRI.Reston.VA.US Subject: Point of order re: Internet Security Guidelines I-D In-Reply-To: Your message of Mon, 24 Jun 91 08:41:46 +0200. <9106240641.AA24672@garuda.sics.se> Date: Mon, 24 Jun 91 10:47:32 -0400 From: Stephen D Crocker Let's move further discussion of the merits and specifics of the Internet Security Guidelines I-D back to the SPWG mailing list (spwg@nri.reston.va.us). It's evident that the IAB has not accepted the document in its current form and that additional work is needed. The authors will make the necessary changes as soon as possible and it will be resubmitted as an I-D. Thanks, Steve   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa01814; 25 Jun 91 4:45 EDT Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa01781; 25 Jun 91 4:37 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA04944; Tue, 25 Jun 91 02:54:55 EDT Message-Id: <9106250654.AA04944@TIS.COM> To: Craig Partridge Cc: spwg@NRI.Reston.VA.US Subject: Re: Point of order re: Internet Security Guidelines I-D In-Reply-To: Your message of Tue, 25 Jun 91 08:25:40 +0200. <9106250625.AA26851@garuda.sics.se> Date: Tue, 25 Jun 91 02:54:53 -0400 From: Stephen D Crocker Craig, Your point is well made and I agree. It's inappropriate to require conformance if there isn't a legitimate job of informing the users. Now the trick is to craft the wording the right way. This is intended to be an enabling document. It's supposed to stimulate network and host administrators into writing policies which are consistent with these guidelines. Thanks, Steve   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa07195; 25 Jun 91 9:15 EDT Received: from mcsun.EU.net by NRI.NRI.Reston.VA.US id aa07169; 25 Jun 91 9:14 EDT Received: by mcsun.EU.net via EUnet; id AA14447 (5.65a/CWI-2.95); Tue, 25 Jun 91 15:16:13 +0200 Received: from sics.se by sunic.sunet.se (5.61+IDA/KTH/LTH/1.196) id AAsunic14482; Tue, 25 Jun 91 08:32:25 +0200 Received: from garuda.sics.se by sics.se (5.61-bind 1.5+ida/SiteCap-3.0) id AA10734; Tue, 25 Jun 91 08:25:44 +0200 Received: from localhost by garuda.sics.se (5.61-bind 1.4+ida/SiteCap-3.0) id AA26851; Tue, 25 Jun 91 08:25:42 +0200 Message-Id: <9106250625.AA26851@garuda.sics.se> To: Stephen D Crocker Cc: spwg@NRI.Reston.VA.US Subject: re: Point of order re: Internet Security Guidelines I-D From: Craig Partridge Date: Tue, 25 Jun 91 08:25:40 +0200 Sender: craig@sics.se Steve: OK - here's my two cents for spwg. (Note that I don't have time to actively get involved in spwg, and thus have not joined the mailing list. I'm asking that folks keep me on the cc: list for any follow up on this particular topic). Following up on my note to Steve and his reply. I believe that any guidelines that expect individuals to conform to a set of policies should also contain explicit requirements that the policies be conveyed to the the individuals. And I don't think putting the requirement that organizations circulate their policies in a Appendix, while placing the requirement on users in the main text is appropriate. It suggests that notification is less important than conformance -- I don't believe conformance can be achieved without proper notification. I also believe that requiring conformance without giving notification is fundamentally unfair. Thanks! Craig   Received: from mcsun.EU.net by NRI.NRI.Reston.VA.US id aa16019; 25 Jun 91 13:46 EDT Received: by mcsun.EU.net via EUnet; id AA09735 (5.65a/CWI-2.95); Tue, 25 Jun 91 17:48:16 +0200 Received: from sics.se by sunic.sunet.se (5.61+IDA/KTH/LTH/1.196) id AAsunic04331; Tue, 25 Jun 91 14:44:54 +0200 Received: from asia.sics.se by sics.se (5.61-bind 1.5+ida/SiteCap-3.0) id AA21048; Tue, 25 Jun 91 14:44:45 +0200 Received: from localhost by asia.sics.se (5.61-bind 1.4+ida/SiteCap-3.0) id AA08670; Tue, 25 Jun 91 14:44:43 +0200 Message-Id: <9106251244.AA08670@asia.sics.se> To: Stephen D Crocker Cc: Craig Partridge , iab@isi.edu, iesg@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US Subject: Re: Point of order re: Internet Security Guidelines I-D In-Reply-To: Your message of Mon, 24 Jun 91 10:47:32 -0400. <9106241448.AA26220@TIS.COM> Date: Tue, 25 Jun 91 14:44:37 +0200 From: matsb@sics.se Steve Crocker wrote: Let's move further discussion of the merits and specifics of the Internet Security Guidelines I-D back to the SPWG mailing list (spwg@nri.reston.va.us). It's evident that the IAB has not accepted the document in its current form and that additional work is needed. The authors will make the necessary changes as soon as possible and it will be resubmitted as an I-D. I have only printed the extensive document so far and taken a very quick glance at it. I have a feeling that the missing part to it, is a cover explaining what "one" should do with it. Some suggestions: - Promote Security Knowledge trough seminars and lectures for users in general, special cources for sysadms and security resp persons, and industry! - Recommend each networked organsation to establish a security policy with a minimi recommended checklist on what it should contain - Suggest to implement a security service description to be part of a contract between a service provider and a customer. Preferably with a checklist on what such a contract could contain (responsibilities for each party, contact info for key personell, rules when an organisation may be cut off from the WAN (e g repeated cracking attempts from users at site) and rules to establish connectivity again (need for customer site to document what actions they have taken...) --mats   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa16236; 25 Jun 91 13:56 EDT Received: from mcsun.EU.net by NRI.NRI.Reston.VA.US id aa16019; 25 Jun 91 13:46 EDT Received: by mcsun.EU.net via EUnet; id AA09735 (5.65a/CWI-2.95); Tue, 25 Jun 91 17:48:16 +0200 Received: from sics.se by sunic.sunet.se (5.61+IDA/KTH/LTH/1.196) id AAsunic04331; Tue, 25 Jun 91 14:44:54 +0200 Received: from asia.sics.se by sics.se (5.61-bind 1.5+ida/SiteCap-3.0) id AA21048; Tue, 25 Jun 91 14:44:45 +0200 Received: from localhost by asia.sics.se (5.61-bind 1.4+ida/SiteCap-3.0) id AA08670; Tue, 25 Jun 91 14:44:43 +0200 Message-Id: <9106251244.AA08670@asia.sics.se> To: Stephen D Crocker Cc: Craig Partridge , iab@isi.edu, iesg@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US Subject: Re: Point of order re: Internet Security Guidelines I-D In-Reply-To: Your message of Mon, 24 Jun 91 10:47:32 -0400. <9106241448.AA26220@TIS.COM> Date: Tue, 25 Jun 91 14:44:37 +0200 From: matsb@sics.se Steve Crocker wrote: Let's move further discussion of the merits and specifics of the Internet Security Guidelines I-D back to the SPWG mailing list (spwg@nri.reston.va.us). It's evident that the IAB has not accepted the document in its current form and that additional work is needed. The authors will make the necessary changes as soon as possible and it will be resubmitted as an I-D. I have only printed the extensive document so far and taken a very quick glance at it. I have a feeling that the missing part to it, is a cover explaining what "one" should do with it. Some suggestions: - Promote Security Knowledge trough seminars and lectures for users in general, special cources for sysadms and security resp persons, and industry! - Recommend each networked organsation to establish a security policy with a minimi recommended checklist on what it should contain - Suggest to implement a security service description to be part of a contract between a service provider and a customer. Preferably with a checklist on what such a contract could contain (responsibilities for each party, contact info for key personell, rules when an organisation may be cut off from the WAN (e g repeated cracking attempts from users at site) and rules to establish connectivity again (need for customer site to document what actions they have taken...) --mats   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa08292; 28 Jun 91 10:26 EDT Received: from mwunix.mitre.org by NRI.NRI.Reston.VA.US id aa08230; 28 Jun 91 10:22 EDT Return-Path: Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2) id AA25662; Fri, 28 Jun 91 10:21:39 -0400 Received: from loghost.mitre.org by smiley.mitre.org (4.1/SMI-4.0) id AA18299; Fri, 28 Jun 91 10:24:49 EDT Message-Id: <9106281424.AA18299@smiley.mitre.org> To: spwg@NRI.Reston.VA.US Subject: spwg nits Date: Fri, 28 Jun 91 10:24:49 -0400 From: "H. Craig McKee" What follows might reasonably be considered a bunch of nit picks. But I read the paper carefully and had difficulty. >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. This is part of section 2 concerning user responsibilities. It seems to me the primary responsibility for file access control lies with the system administrator, not the user. For example, the administrator may set the UNIX default permissions at -rw-r----- and instruct users that any other setting requires his permission. ======================================== >3) Computer and network service providers are responsible for >maintaining the security of the systems they operate. ======================================= > Primary responsibility for security necessarily rests with >the owners and operators of the subscriber components of the >Internet, that is, host and local network administrators. ======================================== > Sites and network operators are encouraged to > review this material and use it freely. ========================================== > 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. ========================================== >5) Users, service providers and hardware and software vendors are >expected to cooperate in the provision of security. I offer a plea for consistent terminology. Your paper names a bunch of entities, and (except for "user"), I'm not sure I know who they all are. computer and network service providers owners and operators ... that is, host and local network administrators site and network operators vendor and system developer service providers and hardware and software vendors   Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa09472; 29 Jun 91 12:24 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA16545; Sat, 29 Jun 91 12:26:00 EDT Message-Id: <9106291626.AA16545@TIS.COM> To: matsb@sics.se Cc: Craig Partridge , iab@isi.edu, iesg@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US Subject: Re: Point of order re: Internet Security Guidelines I-D In-Reply-To: Your message of Tue, 25 Jun 91 14:44:37 +0200. <9106251244.AA08670@asia.sics.se> Date: Sat, 29 Jun 91 12:25:56 -0400 From: Stephen D Crocker Mats, Thanks for your comment. There are two documents emerging. One is the Internet Security Guidelines, and the other is a Site Security Handbook. (The titles of both of these are slightly in flux.) The guidelines document is short; the handbook is *long*. Although your comment could apply to either document, I suspect you're really talking about the 100 page handbook. This is the product of the Site Security Policy Handbook Working Group (ssphwg) chaired by Joyce Reynolds and Paul Holbrook. Joyce is on the IESG, and I'll depend on her to pass your comments on to her working group. With respect to the guidelines document, there is some tension between making it short and compact versus including lots of motivation and explanation. Barbara Fraser and I are wrestling with this now, and we'll try to crank out a new version within a couple of weeks. Steve Steve   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa09630; 29 Jun 91 12:30 EDT Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa09472; 29 Jun 91 12:24 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA16545; Sat, 29 Jun 91 12:26:00 EDT Message-Id: <9106291626.AA16545@TIS.COM> To: matsb@sics.se Cc: Craig Partridge , iab@isi.edu, iesg@NRI.Reston.VA.US, spwg@NRI.Reston.VA.US Subject: Re: Point of order re: Internet Security Guidelines I-D In-Reply-To: Your message of Tue, 25 Jun 91 14:44:37 +0200. <9106251244.AA08670@asia.sics.se> Date: Sat, 29 Jun 91 12:25:56 -0400 From: Stephen D Crocker Mats, Thanks for your comment. There are two documents emerging. One is the Internet Security Guidelines, and the other is a Site Security Handbook. (The titles of both of these are slightly in flux.) The guidelines document is short; the handbook is *long*. Although your comment could apply to either document, I suspect you're really talking about the 100 page handbook. This is the product of the Site Security Policy Handbook Working Group (ssphwg) chaired by Joyce Reynolds and Paul Holbrook. Joyce is on the IESG, and I'll depend on her to pass your comments on to her working group. With respect to the guidelines document, there is some tension between making it short and compact versus including lots of motivation and explanation. Barbara Fraser and I are wrestling with this now, and we'll try to crank out a new version within a couple of weeks. Steve Steve   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa09406; 24 Jul 91 10:18 EDT Received: from nic.cic.net by NRI.NRI.Reston.VA.US id aa09262; 24 Jul 91 10:07 EDT Received: by nic.cic.net (4.1/SMI-4.1) id AA25821; Wed, 24 Jul 91 10:12:01 EDT Message-Id: <9107241412.AA25821@nic.cic.net> To: ssphwg@cert.sei.cmu.edu, spwg@NRI.Reston.VA.US Subject: Site Security Handbook RFC released Date: Wed, 24 Jul 91 10:12:00 -0400 From: J Paul Holbrook Many, many thanks to all who worked on these documents and gave us comments. I'm glad to see this document finally out; I hope it will make some impact on the security of the Internet. As a side note, I'll be presenting this work during on Tuesday, July 30th plenary session at the IETF. J. Paul Holbrook ssphwg co-chair CICNet Technical Services Manager holbrook@cic.net (313) 998-7680 ------- Forwarded Message Date: Tue, 23 Jul 91 15:49:52 PDT From: jkrey@isi.edu Posted-Date: Tue, 23 Jul 91 15:49:52 PDT Message-Id: <9107232249.AA11028@akamai.isi.edu> Received: by akamai.isi.edu (4.0/4.0.3-4) id ; Tue, 23 Jul 91 15:49:52 PDT To: kevin@longs.lance.colostate.edu Subject: Re: Site Security Policy Handbook Cc: holbrook@cic.net, jkrey@isi.edu To: Request-for-Comments-List:; Subject: FYI8, RFC1244 on Site Security Handbook Cc: jkrey@ISI.EDU Reply-To: jkrey@ISI.EDU Date: Tue, 23 Jul 91 12:50:39 PDT From: "Joyce K. Reynolds" A new For Your Information (FYI) Request for Comments is now available from the DDN Network Information Center in the online library at FTP.NISC.SRI.COM. FYI: 8: RFC: 1244: Title: Site Security Handbook Author: P. Holbrook & J. Reynolds Mailbox: holbrook@cic.net, jkrey@isi.edu Pages: 101 Characters: 253,471 Obsoletes/Updates: none pathname: rfc/fyi8.txt rfc/rfc1244.txt This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This handbook is meant to be a starting place for further research and should be viewed as a useful resource, but not the final authority. This handbook is the product of the Site Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF). This FYI RFC provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET, or NISC.JVNC.NET. FYI RFCs can be obtained from via FTP from FTP.NISC.SRI.COM, with the pathname rfc/fyimm.txt, or rfc/rfcnnnn.TXT (where "mm" refers to the number of the FYI and "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "guest". SRI also provides an automatic mail service for those sites which cannot use FTP. Address the request to MAIL-SERVER@NISC.SRI.COM and in the subject field of the message indicate the FYI or RFC to be sent: "send fyimm", or "send rfcnnnn". Multiple requests may be included in the same message. ------- End of Forwarded Message   Received: from cert.sei.cmu.edu by NRI.NRI.Reston.VA.US id aa09595; 24 Jul 91 10:26 EDT Received: from nic.cic.net by cert.sei.cmu.edu (5.65/2.2) id AA05038; Wed, 24 Jul 91 10:08:49 -0400 Received: by nic.cic.net (4.1/SMI-4.1) id AA25821; Wed, 24 Jul 91 10:12:01 EDT Message-Id: <9107241412.AA25821@nic.cic.net> To: ssphwg@cert.sei.cmu.edu, spwg@NRI.Reston.VA.US Subject: Site Security Handbook RFC released Date: Wed, 24 Jul 91 10:12:00 -0400 From: J Paul Holbrook Many, many thanks to all who worked on these documents and gave us comments. I'm glad to see this document finally out; I hope it will make some impact on the security of the Internet. As a side note, I'll be presenting this work during on Tuesday, July 30th plenary session at the IETF. J. Paul Holbrook ssphwg co-chair CICNet Technical Services Manager holbrook@cic.net (313) 998-7680 ------- Forwarded Message Date: Tue, 23 Jul 91 15:49:52 PDT From: jkrey@isi.edu Posted-Date: Tue, 23 Jul 91 15:49:52 PDT Message-Id: <9107232249.AA11028@akamai.isi.edu> Received: by akamai.isi.edu (4.0/4.0.3-4) id ; Tue, 23 Jul 91 15:49:52 PDT To: kevin@longs.lance.colostate.edu Subject: Re: Site Security Policy Handbook Cc: holbrook@cic.net, jkrey@isi.edu To: Request-for-Comments-List:; Subject: FYI8, RFC1244 on Site Security Handbook Cc: jkrey@ISI.EDU Reply-To: jkrey@ISI.EDU Date: Tue, 23 Jul 91 12:50:39 PDT From: "Joyce K. Reynolds" A new For Your Information (FYI) Request for Comments is now available from the DDN Network Information Center in the online library at FTP.NISC.SRI.COM. FYI: 8: RFC: 1244: Title: Site Security Handbook Author: P. Holbrook & J. Reynolds Mailbox: holbrook@cic.net, jkrey@isi.edu Pages: 101 Characters: 253,471 Obsoletes/Updates: none pathname: rfc/fyi8.txt rfc/rfc1244.txt This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This handbook is meant to be a starting place for further research and should be viewed as a useful resource, but not the final authority. This handbook is the product of the Site Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF). This FYI RFC provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET, or NISC.JVNC.NET. FYI RFCs can be obtained from via FTP from FTP.NISC.SRI.COM, with the pathname rfc/fyimm.txt, or rfc/rfcnnnn.TXT (where "mm" refers to the number of the FYI and "nnnn" refers to the number of the RFC). Login with FTP username "anonymous" and password "guest". SRI also provides an automatic mail service for those sites which cannot use FTP. Address the request to MAIL-SERVER@NISC.SRI.COM and in the subject field of the message indicate the FYI or RFC to be sent: "send fyimm", or "send rfcnnnn". Multiple requests may be included in the same message. ------- End of Forwarded Message   Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa02033; 21 Aug 91 4:28 EDT Received: from mvb.saic.com by NRI.NRI.Reston.VA.US id aa01932; 21 Aug 91 4:18 EDT Received: from proto.SAIC.COM ([139.121.22.8]) by MVB.SAIC.COM (CHCS-MailMan V7.2) with SMTP id 3409535; Wed, 21 Aug 1991 01:20:22 PDT Received: by Proto.SAIC.Com (4.1/SMI-4.1/kfp1) id AA16162; Wed, 21 Aug 91 01:20:11 PDT Message-Id: <9108210820.AA16162@Proto.SAIC.Com> To: spwg@NRI.Reston.VA.US Subject: address change Date: Wed, 21 Aug 91 01:20:10 -0700 From: pilotti@proto.saic.com Please make the following change. Note that the OLD address may have already been deleted as the machine sol has been offline for some weeks. OLD: esosun!sol!{keith,proto1!keith} (maybe @ucsd.edu) NEW: spwg@jupiter.saic.com Thanks... +Keith -- O Keith F. Pilotti --O | Science Applications International Corporation (619)552-5641 (Voice) | | 10770 Wateridge Circle, San Diego, CA 92121 (619)452-9680 (FAX) | | | | Pilotti@Jupiter.SAIC.COM {:-) SAIC ESG Prototyping Laboratory | O----------------------------------------------------------------------------O