CURRENT MEETING REPORT

Reported by Barbara Fraser, CERT Coordination Center

Minutes of the G and R Security Incident Processing Working Group (grip)

The GRIP Working Group met twice during this IETF. The first session was spent reviewing the current draft of the guidelines for incident response document, and the second session was spent discussing the outline for the vendor document.

We re-affirmed that the audience was incident response teams, and that we would write it such that it provides community expectations for such teams. The group went through the document section by section and provided input to Nevil who will make the necessary changes in the next draft.

We also discussed the ordering of sections in the document and several changes were suggested. Again, Nevil will handle the requests. The group discussed the topic of liason and peering between response teams, and how that type of information can be conveyed to the community. Jeff Schiller agreed to write a paragraph on the subject and send it to the list.

The second session was devoted to discussing the next document, Guidelines for Internet Technology Producers. The title has not been fully discussed, but this one will be used as a working title. This session was held on Friday morning and because of that the attendance was low. The group did decide to collect some of their thoughts. The use of the words "must" and "should" haven't been set so their use below is simply representative of the language that the attendee used. This is something we will have to consider at some point in time. Below is the set of topics/suggestions that were captured during the session. This will need a lot of work.

A. Packaging and Distribution

• digital signatures/checksums must be available for every product - must have out of band verification mechanism for the signatures - demonstration software shouldn't require system privileges to run or there should be strong warnings to the site to test on a test network.

There was some discussion as to whether we should specify a minimum algorithm for this use, but there was no decision.

B. Default Configurations

• want products "secure by default" (e.g., no trust by default) - devices (e.g., ttys, ptys) should not be set as secure by default - no open accounts
• good directory an file permission settings - good umask
• minimum network services on by default - writable/default community strings a problem - locking screen savers
• concern about default configurations of servers (e.g., ftpd open to guest)
• concern about exported file system defaults in file sharing setups
  

C. Installation

• don't rely on default paths
  

D. Normal Use

• "no further changes" mode after installation is complete - need to address levels of access (e.g., normal use should not provide full access to all resources)
  

E. Response to Security Problems

• make security patches available to anyone for lifetime of the product (as defined by the vendor of the product) - describe procedures for handling security problem reports - acknowledgement of publicly discussed problems
  

F. Support for old versions and duration of support

• describe the lifetime of a product at the time a site is considering purchasing it. (e.g., x number of years, or "this rev. supported until two major revisions are subsequently released").
  

G. Documentation

• documentation separate from installation media (sometimes you can't get to the documentation until the system has been installed!) - provide one-stop shopping for security information including overview and checklists.
  

H. Other things

• trust models for files vs. trust model for net - network services should require authentication - documents with executable content should not be on - don't want surprises.