[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pending minutes for August meeting
39th IETF, Munich, Germany. - August 1997
*****************************************
Guidelines and Recommendations for Incident Processing (GRIP)
=============================================================
Prepared by Barbara Fraser and Klaus-Peter Kossakowski
The GRIP working group met once during the Munich IETF. The following
agenda was used.
Agenda
======
o Discussing recent draft
o Discussing outline of vendor document
o Discussing outline of ISP document
o Schedule and Actions
Expectations for CSIR
=====================
It was suggested by the chairs, that the title and use of SIRT throughout
of the text will 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 is 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.
Discussing the outline for the vendor document
==============================================
Before discussion started, the question for volunteers to edit the document
was raised by the chairs. Barbara will talk to anyone interested in being a
document author.
First question was about the audience for this document and why it was
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 OpenGroup document about Baseline
protection (ABSS) should be read and referenced. URL is xxx
Another issues 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 which 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 packaging can be carried out by other parties (on behalf of the
producer) 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 vendors distributing
an unsecure setup after a bug was 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 need 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).
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.
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.