CURRENT_MEETING_REPORT_ Reported by Richard Pethia/ CERT 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 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 2 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 3 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 4