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