NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Chair(s):
Louis Mamakos <louie@uu.net>
Barbara Fraser <byf@sei.cmu.edu>
K.P. Kossakowski <kpk@cert.dfn.de>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O''Dell <mo@uu.net>
Operations and Management Area Advisor:
Michael O''Dell <mo@uu.net>
Mailing Lists:
General Discussion: grip-wg@uu.net
To Subscribe: grip-wg-request@uu.net
Archive:
Description of Working Group:
The full name of this working group is Guidelines and Recommendations for Security Incident Processing.
This working group is co-chartered by the Security Area.
The purpose of the GRIP Working Group is to provide guidelines and recommendations to facilitate the consistent handling of security incidents in the Internet community. Guidelines will address technology vendors, network service providers, response teams in their roles assisting organizations in resolving security incidents. These relationships are functional and can exist within and across organizational boundaries.
The working group will produce two quality documents:
1) Guidelines for security incident response teams.
2) Guidelines for vendors (this will include both technology producers and network service providers).
Goals and Milestones:
Feb 95 |
|
Produce document describing problem statement and document taxonomy/vocabulary. Also cite the Site Security Handbook documents to make clear the relationship and scope between the two working groups and documents. |
Feb 95 |
|
Produce draft outline for remainder of Response Team Document. |
Done |
|
Meet at Danvers IETF to review full Internet-Draft of Response Team Document. |
Jun 95 |
|
Produce Internet-Draft on Guidelines for vendors. |
Jun 95 |
|
Produce final version of Response Team Internet-Draft. |
Done |
|
Meet at Stockholm IETF. Review vendor Guideline Internet-Draft. |
Sep 95 |
|
Produce final version of Vendor Guideline Internet-Draft. Submit to IESG for review. |
Internet-Drafts:
· Expectations for Computer Security Incident Response
No Request For Comments
Minutes of the Guidelines and Recommendations for Incident Processing (GRIP) Working Group
Reported by Barbara Fraser and Klaus-Peter Kossakowski
The GRIP working group met once during the Munich IETF. The following agenda was used.
I. Agenda
I. Discussing recent draft
II. Discussing outline of vendor document
III. Discussing outline of ISP document
IV. Schedule and Actions
II. Expectations for CSIR
The chairs suggested that the title and use of SIRT throughout the text would be changed. Within the last year, Computer Security Incident Response Team (CSIRT) is becoming the standard. The group agreed.
One person (from a vendor organization) pointed out that there is no text expressing the expectations the vendor community has with regards to CSIRTs. Suggestion was that it doesn't fit into the document with the scope on the broad user community. It can be handled within the upcoming vendor document.
In section 1 (page 3, 3rd paragraph) the last sentence misleads the reader into expecting that he will find lists of many examples within the document. We will remove the sentence.
The heading of section 2 is now "Scope" but this is not the objective of this section any longer as it gives an overview about three different areas. The group decided to ask for ideas on the list and tasked the editors to fix it.
When discussing 2.2, the notion of tracking numbers came up. Bill Woodcock agreed to send some text to the list that might fit under the Triage function where more technical details are handled.
In 3.3.2, more examples for defining the constituency should be given. Bill will send some text.
In 3.4.2, the text about vendors (page 13) needs some clarifications. Not only does the text suggest that only vendors with an IRT are "large," but the interaction between other IRTs and vendors is not clear. It also jumps to vulnerability handling instead of covering the actions necessary to assist in the response to an incident.
The section 3.4.3 isn't strong enough to address the need for secure communication and authenticity. The "should" in the first sentence will be changed to "must." Additionally, it will be included that appropriate policies must be established too. (Erik suggested one sentence to address both problems and will fix it.)
In 3.5.1,its subsections, and Appendix D the word "cure" should be changed to "resolution."
It was pointed out that the living example in Appendix E wasn't adjusted to the new outline of Incident Response Services (Triage, Coordination, Resolution). This will be fixed.
In Appendix E, the example included an erroneous statement for 3.3 Affiliation and Sponsorship, since FIRST membership is interesting but not what we meant. Text from 3.4 could be used, but there should be some reporting requirements also included.
Barbara will check on the appropriate use of the CERT Incident Reporting Form to see if it is okay - even for a commercial IRT - to point towards it. If not, it should be mentioned within the document.
III. Discussing the outline for the vendor document
Before discussion started, the chairs raised the question for volunteers to edit the document. Barbara will talk to anyone interested in being a document author.
First question was about the audience for this document and why it is bounded to the vendor community. Barbara explained the relation to the Site Security Handbook work and answered the question.
Some other folk pointed out that the Open Group document about Baseline protection (ABSS) should be read and referenced. URL is xxx
Another issue brought up was the scope of the product. As products might be developed for a specific environment, and the product might be used within a different environment, the security might be very different. Boundaries should be given and the documentation should explain what ports are used or what files are accessed. The security level by default should be documented. This whole topic will fit into section G Documentation. Andreas Siegert will send some text about it.
Within the scope/purpose section, it must be defined what kind of products we are addressing (do we want to handle cables?). To help the reader, it would be easier to address classes of products that share the same characteristics.
Computer virus checking should be added to the section A. Discussion was about the "must" for the out of band verification mechanism for the signatures. There might be total different kind of mechanisms used for the protection of the customer, so different classes might come in handy here again.
As other parties (on behalf of the producer) can carry out packaging, different responsibilities might arise. This should be addressed somehow. Even worse, their actions might impact the authenticity and security of the product and might change the provided checksums.
Going on to section B, a question was asked as to how to address the security quality of default configurations. What about a vendor distributing an unsecured setup after a bug is published on the net? Security Engineering is beyond this document and there is an effort under way to address such issues.
New input was added to advise vendors to give version numbers within the documentation about products used. As the vendor is not responsible for the content of additional third party programs he is providing, it is even more important to know which programs are not covered by the vendor. It would be even beneficial to the vendor, as the reporting of problems would be more specific. This should be covered within section C.
Whenever there are choices between security and insecurity, the security version should be used by default. However, it has to be a decision of the user. There was no resolution during the meeting; the group needs some examples to list.
Customer must be made aware about the problem of default configurations systems. This was supported since users tend not to read documentation and would therefore be provided with guidance up front as to how to change default settings to improve security. Ideally, this will encourage the vendor to avoid such weak default configurations in the first place.
There has also been a problem with knowing the exact release version for products. Sometimes the vendor will make security changes but not increment the release version. The group felt that vendors should be required to provide unique version numbers for any changes.
For section D, people would like to see a frozen configuration to avoid future problems later on.
In section E, a question was asked if we expect the security fixes to be free. It was clear that it is a contractual agreement. Media cost should be reasonable, and it is expected that only the owner of the product (not anyone) will receive the patches/fixes.
Section H actually deals mostly with security engineering and hence much of it may be removed or modified.
All in attendance felt the document should be written and volunteers were encouraged to contact Barbara directly (byf@cert.org).
IV. Discussing of ISP Document
Only two or three of the participants have read the outline sent around by Nevil Brownlee on the list. Barbara briefly explained the history of the document. The outline will be made available on the GRIP WWW pages by the 15th of August as: http://www.cert.dfn.de/eng/resource/ietf/grip/isp-out.txt
Tom Killalea will submit a first draft in October.
V. Schedule and Actions
31. August 1997: New draft of IRT document
16. September 1997: Last call to working group ends, thereafter submit to IESG thereafter
15. October 1997: First draft of ISP document
25. November 1997: First draft of Vendor document
Barbara will take an action item to update the mailing list with the new participants.
None Received