CURRENT MEETING REPORT

Reported by Erik Guttman and Barbara Fraser

Minutes of the G and R for Security Incident Processing (GRIP)
 
List is at grip-wg@uu.net 
request at grip-wg-request@uu.net 
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.