Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/grip/grip-minutes-97aug.txt

Text File | 1997-10-10 | 8KB | 183 lines

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 ([e-mail]).

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.