Meetings:
30th IETF,
31st IETF,
32nd IETF,
33rd IETF,
34th IETF,
35th IETF,
36th IETF,
38th IETF,
39th IETF,
40th IETF,
41st IETF,
43rd IETF,
44th IETF,
45th IETF
and
46th IETF
35th IETF, Los Angeles, Calif. - March 1996
Guidelines and Recommendations for Incident Processing (GRIP)
Session One
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.
Session Two
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 2 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.
Administrivia
The mailing list is:
- grip-wg
- Subscription: grip-wg-request@uu.net
Archives are setup in the US and Europe:
Access to the GRIP charter and minutes is possible via World Wide Web, too.
Please send questions, comments, and/or suggestions regarding the
GRIP working group to the open mailing list
grip-wg@uu.net.
All issues regarding these web pages should be directed to
klaus-peter@kossakowski.de.
These pages are hosted on http://www.kossakowski.de
and are provided on an "AS IS" basis without any explicite or implicite
responsibility, liability, etc. (For a more fully understanding please refer
to the legal statements within the Impressum,
which is only available in German.)