Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/grip/grip-minutes-95jul.txt

Text File | 1995-10-18 | 18KB | 479 lines

CURRENT_MEETING_REPORT_


Reported by Barbara Fraser/CERT Coordination Center and
Klaus-Peter Kossakowski/DFN-CERT

Minutes of the Guidelines and Recommendations for Security Incident
Processing Working Group (GRIP)

Due to many new participants which were unfamiliar with the past
activities of this working group, a short overview of the activities of
the working group was provided.  The first meeting was spent reviewing
the outline of the document on incident response teams and proposing
material for the sections.  The second meeting focused on the
development of an outline for the document on vendor requirements.



Incident Response Team Document


Status of the Document


After the discussion during the last IETF meeting there was supposed to
be a draft for this meeting.  Due to the time schedule of the editor he
was unable to fulfill this role.  A volunteer for the position of the
editor was requested.  Nevil Brownlee volunteered for this position
later in the meeting and he is now our new document editor for the
response team document.

There was some discussion regarding the relationship of the template and
the document itself.  It was emphasized that the document serve two
purposes:  to provide guidance to organizations that want to form a
response team so that they will be able to describe themselves in terms
of the template, and to help the reader (or client or potential client)
of a team understand the content of a given team template.

One of the main primary purposes of the document is to help new teams.
During the discussion a split of the IRT document into a document about
forming an IRT and into another document about the team template was
proposed.  No decision was made by the group.  There was discussion as
to whether this document will provide to response teams, minimum
community expectations.  In earlier meetings, this was to be the case.
At this meeting there was a difference of opinion.  This is something
that we will settle on the mailing list or (in the worst case) at the
next meeting.

One of the other purposes of this working group and its documents was
named:  to get other groups to use this template.  This should be
included in the introduction.


Short Review of Team Template

During the review various issues came up.  One of the discussions was
devoted to the availability of the team templates.

A central repository is needed to provide easy access to the templates
of (most) teams.  It was thought that some of the existing archive areas
could include such templates.

It was recommended that digital signatures be used to protect the
provided template against modifications.  (This was also included in the
team template).

Each team will be responsible for ensuring that its own template is
available to its cooperating partners and its constituency.

Another discussion involved the meaning of several terms:
``constituency'', ``sponsor'' and ``authorization''.  Due to many
different situations for the teams it is important to allow a consistent
description.  Therefore, we will provide definitions of these terms
within the context of the document.  They should be included in the
introductory section along with the others that have already been
identified.

After reviewing the already discussed and outlined chapters, the
discussion of the other chapters followed with the the goal to get more
content and keywords which could help the editor of the document.



Discuss Various Topics of the Document

During the last IETF the first chapters of the document
(``Introduction'' and ``Defining a Charter'') were discussed in more
detail.  During this meeting the remaining chapters were handled in
detail.

Policies

The problem of incident reports and requests, and their handling was
discussed in more detail.  It was felt that each team has to choose its
policy, but it should be clearly stated in the team template.  To avoid
the ``black hole'' phenomenon, a team might choose to provide a minimal
feedback even to sites without their constituency.

Due to the impact on the team's constituency (incidents) reports from
outside the constituency must be handled very carefully.  We discussed
that there are several ways that these reports may impact the response
teams constituency:


   o reports from outside effecting inside inside hosts/sites
   o reports from outside that do not effect inside hosts/sites


Interestingly, there is also the possibility that reports from inside
the constituency only effect outside sites.  A team must determine how
they are going to handle these types of reports and make it known.

The item ``reporting requirements'' is confusing due to the relation to
things like ``quarterly reports''.  This item was reworded to ``incident
reporting requirements''.  Similar confusion arose from ``points of
contact''.  It was changed to ``points of customer contacts''.  Standard
bodies were added as possible cooperation partners.

A new, important issue came up related to the team template itself.
Changes of policy must be distributed to the constituency (and other
relevant parties).  Without that, it is clear that misunderstanding and
misconceptions will arise, whenever policies are changed.

It was also felt by the group that vulnerabilities are sometimes not
related to incidents and their handling needs to be addressed.  As at
the last meeting, the group decided to categorize vulnerability response
as an optional service and this topic has to be analyzed in more detail
later.  Vulnerability reports not related to actual incidents might be
addressed to avoid possible incidents (this behavior is sometimes
categorized under ``pro-active measures'').

The next major topic addressed in the discussion was ``disclosure''.
The group felt comfortable with the actual items and several others were
added:


   o Vulnerabilities discovered in the process of handling an incident
     and the distribution of relevant information.  There are several
     relationships that have to be addressed here:
         to constituency
         to vendor

   o A team will normally collect statistics.  If they are distributed,
     this should be stated in the policy section under this topic.

   o Because feedback to a reporter will disclose information, this has
     to be handled, too.  It is important to set the right expectations.

   o If conflicts of interests are identified for a single team which
     might interfere with the disclosure of information this must be
     handled here.  The group felt it is unnecessary to address this
     issue within the template explicitly.

   o Legal requirements for disclosure might be different for the
     various teams.  Due to the interference with user expectations,
     these should be outlined.


One specific kind of request is related to contact information for other
teams, organizations or parties.  The distribution of this information
might be important (e.g., contacts to the law enforcement) or it might
be helpful to the reporter if a team will not deal with the request
(because it is outside of the scope or the reporter is outside its
constituency).  Each team can decide to put other contact addresses into
the appendix of its template.  This topic will also fit under
disclosure.

Services

During the first review a little confusion arose surrounding some of the
items within this section.  These were later clarified:


   o ``verification'' was renamed to ``verification of incident''
   o ``optional'' was renamed to ``optional activities''


It was noted that all pro-active services, if offered, are optional.  It
was suggested that the group be very careful in the wording of the
section about optional services to avoid the misconception that such
services are mandatory in order to be perceived as a ``good'' (or
quality) IRT. Even legal conflicts can arise because of such
misunderstanding.

Examples for other optional activities might include but are not limited
to:


   o firewall consulting
   o security tools packages
   o information about security software (e.g., tcp-wrapper)


One of the services during handling an incident is to help the victim to
understand the problem and the extent of the impact and/or damage.  This
fits under ``understanding of activity'' as opposed to under an optional
activity.

The group felt uncomfortable with the topic ``coping''.  This was
changed and divided into ``eradication'' and ``recovery''.  Recovery may
or may not include education.

The closing of an incident as an explicit service (i.e., letting all
involved parties know, that the IRT considers an incident closed) is
important and clearly an instance of the incident handling process.
This also helps the IRT to avoid the black hole phenomenon.

Procedures

This section has no relevance for the team template.  Policies stated in
the template have to be implemented as procedures internally.

Some procedures were discussed in more detail.


   o Keeping statistics was already addressed under disclosure, but a
     team needs a procedure for doing this.

   o Keeping track of lessons learned seems trivial but it is important
     in helping the team handle similar incidents more efficiently the
     next time.

   o It was decided that we should not include too much guidance
     concerning securing a team's infrastructure since we can point them
     to ``The Site Security Handbook'' as a resource.  There might exist
     IRT-specific security demands which are not usually considered for
     other sites and those might be important to handle in this section.

   o Another topic was the use of the network itself as an information
     resource for the teams.  In using it they have to realize that they
     might be vulnerable to faked information which might lead to damage
     if it was used for part of the incident handling process by the
     team (e.g., wrong contact information for contacting involved
     sites).


After reviewing the first document and in lack of more input to the
group, it was decided was to focus on the second document.


Vendor Document

The discussion started with a kind of reality check.  The original
question was what can be achieved through such a document?  The users
need something to point to.  The community has to develop an
understanding of what can be expected from the vendor (technology
producer) side.  Leading the way to best current practise is a good
description for the purpose of this document.

The discussion of experiences of the audience revealed the following
thoughts:


   o Getting an understanding of what the larger community really needs
     is most important.  The needs might be very different for users
     outside the more technical community of the IETF.

   o Users have to deal with a highly hierarchical system of vendor,
     seller and reseller.

   o The users will need a document in simple language, so that
     everybody can understand it and use it.

   o There is a special situation outside the US, where even the vendor,
     seller and reseller have no access to the technical information and
     the detailed knowledge.  For example, it is a wrong assumption that
     every party has access to source code.


Scope of Document

Get an understanding of what users can expect from a vendor when a
product security problem is reported for:


   o software
   o hardware


Clearly this document therefore has to reflect the community's
expectations of how vendors should respond to and handle reports of
security problems in their products.  The producers are the audience,
but users will read it.  This will lead to the use of the document to in
some ways force the technology producer to a specific behavior.

A question was raised if the document will address the areas of secure:


   o packaging
   o distribution
   o installation
   o default configuration


Is the development of the software within the scope or not?  The field
of software engineering clearly does not fit into this document.  But
perhaps a document about ``best current practise'' for software
developers is needed.  This topic will probably not be included in this
document and the decision to write yet another document will be decided
after we have these two completed (or at least well underway).  The
distribution of software (especially in the public domain area) often
leads to flaws and therefore advice in this area would be worthwhile.

The normal answer on a security hole is the suggestion to use an
update/revised version of the product.  However, internal technology
constraints may make this impossible to use or not advisable.  Some
vendors stop supporting patches for software products and the change to
a new major version would force the victim organization to change the
whole setup.  Therefore the sites need updates (especially in complex
system setups) not a new version.  The question of how long a specific
system is supported is important.  Especially in the case of large
organizations the amount of work for ``regular'' updates is immense.
Folks are interested in the length of time as measured in calendar time
as opposed to versions.  So, for example, some vendors state that they
support the current versions and the two preceding ones.  The problem is
that the buyer does not know how long a period of time this might cover.

From a strategic and financial planning point of view it would be very
helpful to know, rather, how long in real time an organization can count
on support for the product.  What about products that are sold but are
no longer supported or dropped from the list of supported products
shortly after purchase.  What are the implications for security patches
in these cases?

The feeling was also that security problems have to be addressed, even
without a service agreement.  Security patches are expected to be free.
However, this will not hold forever since vendors must be able to stop
support on old products at some point in time.  The point is that they
need to clearly state what their support policy is so that a buyer can
make informed decisions.

The distribution of security information has to be addressed, too.  This
is a sensitive subject but the group came up with a starting point for
further discussions in this area.  In general, enough information has to
be shared so that it is possible to find out if a site is vulnerable.

This may be especially important if no patch is available and the
knowledge about a security bug can be serious to a site.  If informed, a
site would perhaps decide to disconnect from the net.

It was brought up that there may be liability involved with the
disclosure of such information and what is the responsibility for side
effects of patches (like it is done on prescription medications).

The distribution of more detailed security related information to
(major) customers was approached by at least one major vendor.  Due to
the transfer of the liability for misuse of this information to the
customers, no one was eager to sign the contract.  One solution was
proposed:


   o If no exploitation, company provides fix, but does not disclose
     before fix is available.

   o If being exploited, disclose the information.


It was quickly noted that we are not attorneys, and we cannot possibly
set policy.  However the discussion was good because it pointed out the
areas where vendors need to their policies.

Resellers are problematic, too.  They might be responsible for security
flaws the end user will contact the vendor of single components.

Network providers may claim to be technology providers (aka vendors),
but they are not.  Even if they are responsible for things like router
configurations, this has to be separated from the hardware and software
component.



Purpose Statement

Primary Purposes

Reflect the community's expectations of what consumers can expect from a
vendor to address the security issues related to their products during
the product's lifetime (excluding the software development process).  To
include:


   o distribution

   o default configuration

   o optional components (e.g., debugging)

   o installation

   o normal use

   o response to security problems (known by the vendor and reported by
     customers)

   o support for old versions, duration of support

   o documentation


Secondary Purposes

Raise the awareness both on vendor and consumer sides that addressing
security issues is worthwhile.


Outline of Draft Document

Suggestion for the title of the document:


     ``Internet Technology Producers Guide to Good Security
     Practice''


   o Introduction

      -  purpose

      -  statement of intended audience

      -  basic definitions
          * vendor
          * security bug

      -  relationship to other documents
          * site security handbook (SSH)
          * vendor document (GRIP)

   o Distribution

   o Default configuration

   o Optional components

   o Installation

   o Normal use

   o Response to security problems
         known by the vendor
         reported by customers

   o Duration of support

   o Documentation


Discuss Various Topics of the Document

The following definitions were discussed:


   o Vendor -- Entities that produce technology and are responsible for
     the technical content.

   o Security Bug -- No definition was given during the 33rd IETF. If it
     is felt that there would be the need for such (maybe under a
     different term) we will get a definition later.


Administrivia

Incident Response Teams Document


     September 1995    -- First draft
     November 1995     -- Internet-Draft
     December 1995     -- 34th IETF, review of draft
     January 20, 1996  -- Final draft
     Mid-February 1996 -- Final call


Internet Technology Provider Document


     September 1995 -- Draft outline