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

Text File | 1996-06-03 | 14KB | 301 lines

CURRENT MEETING REPORT

Reported by Erik Guttman and Barbara Fraser

Minutes of the G and R for Security Incident Processing (GRIP)

List is at [e-mail]
request at [e-mail]
Archives   ftp.cert.dfn.de

The GRIP working group met once during this IETF.  The agenda for the
meeting was the following:

    Find a volunteer note taker - Erik Guttman was wonderful to
                              volunteer
    Review the current Internet Draft
    Develop outline for the vendor document

The group spent the first 15 minutes or so discussing the audience for
the document.  The goal is to provide a document that accomplishes
several things:
    - sets community expectations for a security incident response team
    - provides a description of what it means to be a response team
    - provide a template to facilitate the definition of any given
      response team.

So, the audience is primarily response teams even though members of the
Internet community will also find it useful.  The descriptions in the
document should help set a constituent's/customer's expectations of the
team.  This document discusses all the many aspects of incident response
that need to be defined. Therefore, a constituent/customer should be
able to read a team's template and discover what to expect, for example,
in such areas as privacy and confidentiality of information, and if the
response team will be contacting downstream sites.

In terms of expectations, the discussion was in terms of "what should
I expect of my own IRT?" and how does this differ from what I expect from
other organizations and groups.  The basic philosophy will have to be
"If you tell us things (in the filled out template), we will expect you
to follow through with what was stated.

Another point that was brought up about follow-through was that users should
be encouraged by their IRT to report incidents so that appropriate actions
can be taken.  Without active participation (ie. reporting) from users, IRTs
can't do much good.  Thus, the users need to know how and when to report.
There was considerable discussion about the definition of an incident.
Another way of stating this is what should users be trained to do?

In a review of Section 4.4 it was asked if we should continue to keep the
document OS neutral. Folks agreed but decided that it would be helpful
to provide examples when needed for clarification.  For example "root
compromise" and  "writable FTP area" when distinguishing between types
of violations.  These examples are rathery UNIX specific.  There was no
clear resolution on this, but we agreed to keep the OS neutrality in mind
whenever possible.

The difference between inappropriate disclosure and unauthorized use got
discussed:  The two categories entail different loss of confidentiality.
Inappropriate disclosure would be to grab stuff and make it more visible
than originally intended.   Text is needed to bring out the differences.
The disclosure issue is further complicated by the fact that disclosure
could be intentional or unintentional.

There was some discussion as to whether the document should discuss what
is out of the scope of an IRT?  It was decided that it is easier to say
things are definitely in the scope/charter of an IRT.

It is important to define what the IRT considers worth their involvement,
or at least to put bounds on what they consider to be an incident.  A
VULNERABILITY is important to know about and an IRT *may* provide analysis
of the vulnerability.  On the other hand it may only do this if the
vulnerability was discovered during a security breach, etc.  It was
reaffirmed that vulnerability analysis isn't required of IRTs but the
analysis of vulnerabilities which do not occur within the framework of
an incident may or may not be a service provided by IRTs.

Examples include pc viruses and malicious programs.  These are not really
an incident on 1 or 2 machines.  But if they are brought in deliberately
they can become full scale incidents.  If merely an accident, generally no.
But, the decision is ultimately with the IRT.

Some IRTs handle all virus cases, etc.  This seemed to be the case in
private IRT set ups (within one corporation.) Others, like the CERT
Coordination Center have traditionally not handled viruses.

There was discussion about nailing down the expectations questions:
- What response level can we expect from the team, what will not be dropped?
- What kind of response can we expect?
- How should one report?  (This is perhaps handled in the SSH user doc)
- Notification (of up/downstream sites, press, government)
- What is the default reporting a constituency can expect, what exceptions
    are there?
- How and when should I, as a member of an IRT's constituency, report an
    incident?

* NOTE:  Corporate network and physical security should be coordinated.  An
IRT may be called when a computer is physically taken/broken into, the
watchmen may be called due to a computer security intrusion.

While we aren't providing an end-user's document we do need to grapple
with the work that an IRT does as well as it's interface to the outside.
One person suggested we could look at it as different management:
managing inward and outward.
 - manage the inward vs. outward sides of incident handling
 - start on the inward side:  Want it to be clear exactly where to go if
   there is a (suspected) incident
 - each topic can be seen from either or both sides.  Ask "Is this an
   inward or outward issue?"

Lots of the discussion focused on the differences between commercial
incident response and incident response defined by a particular entity.
There were member of the working group from both categories and the
discussion was interesting.  For example, if the policy is clear
(as in a corporate case) it should not be necessary to think.  You should
CONTACT SO AND SO as your whole range of choices.  This is harder when it
comes to commercial enterprises like Internet service providers,
value-added service providers, and commercial IRTs.

It seems the outward side comes down to:
 - "As a user you should read this and that policy document.  This will
    make clear what we will provide you with and what you need to deal
    with on your own."

* The document must be clear(er) about what effects the user community
    vs. what is addressed directly to the user community

Upshot to consituents is:  READ YOUR FILLED IN IRT TEMPLATE AND "DO THAT
FIRST".

IRTs *can* set up a policy which says:  If you have ignored my advice, my
future commitment may be limited.

It was also restated that many IRTs have no prosecuting authority to
get people to follow advice when they give it.

* Defining what constituencies are is out of the scope of the RFC, it
    will be done by the IRT or corporate policy in a very individual
    way.

Then there was discussion about what we should include concerning the
question:   How do you find your IRT?
- ask your ISP
- ask an IT security officer [? I don't know what this means]
- put hints into the User SSH

Note: IRTs have a responsibility to advertise themselves to users/IRTs
Dissemination of info about IRTs:  First my constituents then outward.
Since there is a trust issue (is this really an IRT?) it makes sense
to send information out in a 'tree' like manner, using trust along the
way of the direct source of info.  It was mentioned that the trust
model for IRTs is the same as that for PGP, a web of trust. The most
challeging piece is to fine the first entity that you truly trust.

The info about IRTs and IR techniques needs to be in the hands of tech
support, as they will be faced with incidents on the front lines.

Most important is that IRTs publish to their constituencies.  This is
really according to a "push model," as they will not be in a position
to really ask until it is too late.

There was discussion about a central repository, but the bottom line is
that the IRT in question needs to make it's information available.
First, it should publish its template on its own information server.
Everyone also acknowledged that the FIRST repository is a good thing,
but that there may be teams that aren't members of FIRST so we can't
count on that 100%.  We might point folks to the FIRST archives, their
Internet service provider, and other known response centers.  One of the
primary jobs an IRT must succeed in is making upstream sites aware of
how to contact them.

International audience:  The IRTs and users of the template should/must
work sensitively to local laws and regulations.

* It is probably important to clarify any local regulations which will
effect the primary operation of the IRT to those who may have
very different expectations in different countries, etc.

* It is very possible that a team will want to have internal and
external versions of their policy.  One may be for corporate use only
on the one hand, and the other for general consumption/cooperation guidelines
on the other.

Getting back to knowing who the response teams are brought out some
further discussion.  We decided that we would provide a list of the
current IRTs in the document as a starting point, along with a pointer
to first.org.

In general the idea of a central repository presents some challenges.
The repository may be  very difficult to keep current and to keep filled
with accurate information.  (Bad guys can create 'IRT' facades, etc.)

Who will 'vet' the response teams/classify them officially?  Note this is
a very sticky area that will have liability issues associated with it, as
business will claim to be able to do this.  Who will have the right or
claim to have the right to deny them?   There was even discussion as to
whether someone could go to an investigative agency in their country to
see if a particular team was legitimate.  May be valuable to enlist the
aid of a national (law enforcement) agency to maintain a list of contacts
and act as a clearing house. Right now, the list of members in FIRST is
a good start, but some mentioned that there will inevitably
be IRTs that are really just an individual who has contracted with some
organizations to provide incident response services. So, we need to be
sensitive to future needs.

There was some discussion concerning categories of vulnerabilities, and
one member of the group suggested there are 3 general kinds:
- vendor/os vulnerability
- those used from a local host targeted at another site 1:1 or thereabouts
- those used internally, internal matter in an organization.

The first may or may not be an incident.  It will be if it was exploited.
Otherwise it falls into the category of a vulnerability.  If it is wide-
spread in consequences it should be dealt with.

If it is a 1:1 or 1:many incident you deal with them and or their IRT, as
well as local law enforcement since there may be a concern for liabilities
if you don't and the downstream sites find out later.

If it is an internal compromise, it should be dealt with internal security
mechanisms in place.

Commercial response teams will broaden the field of who should be tracked.

The quality of sources may not be all good or bad, there is a gray area.

Teams have the template to
- give to constituencies (private part)
- give to public (public part)

* Idea: use a 'keytag' to classify the document so that yahoo/infoseek/etc
info directory scans will make them available to the network community.
The search engines out there will help the incident sufferer.  Alternatively
the list at FIRST should be on the web...

* There was some discussion as to whether to change the title to
"Expectations for Internet Security Incident Response" . We'll decide
on the list.

The following were some specific edits:
- intro: add "dealing with internet but concepts apply to closed nets."
         add "formulate expectations"
- S 1.1: rename Template Repository to Central Repository
- pg 4 : "distribution of template updates" tell you where to get new
     templates
- S 3, pg 5:
         primary purpose:  set expectations of constituents & customers

         "A second document...vendors to help them with security incidents"
         Actually it is much broader than that: should we really have this
         pointer here?
- S 4.2, pg 6:
         "Partner Team" what is this?  Omit it.
- S 4.3: Goes away
- S 4.4: Incident should be Incident Response

---------------------------------------------------------------------------

At this point in time, the time alotted to the working group session was
about over and we didn't have time to do any real work on the second
document.  The following are some comments on the outline.

- The outline can be thought of as the consumers life cycle of relationship
    with a vendor vis-a-vis possible security issues.

- OPTIONAL COMPONENTS section comments
    - features like NIS and NIS+ which you may use, make it very clear
      what known security problems will be taken on if they are turned
      on.

- INSTALLATION section comments
    - make it very clear what you have to do right away before the
      system is really usable (change certain passwords for example)
    - eliminate guest/no password accounts
    [isn't this section really DEFAULT CONFIGURATION by another name?]

- Most of the discussion was on the DEFAULT CONFIGURATION
    - security features need a lot of attention
    - x is a 'good idea', y is a 'bad idea' notes are useful
    - be clear this is not unix based nor is it a 'security engineering
      handbook'
    - [the fellow from TI's IRT asked] should group passwords even be
      turned on?
    - how to disable promiscuous internet connections and make it hard
      for users to get access to such facilities.
    - do not use cleartext passwords on the wire if at all possible
    - no trust should be the default
    - GET MORE IDEAS FROM THE MAILING LIST

Next Steps:

1. Nevil will create a new draft by mid-January for everyone to review
before the March meeting.  We hope to have a stable document by then so
that only small editorial changes will be needed before we can advance it.

2. We'll discuss the vendor document on the list. We are working on
selecting the document editor(s) for that document.

3. We are planning two sessions in Los Angeles, 1 to complete the IRT document,
and a second one to work on the vendor document.