Meetings:
30th IETF,
31st IETF,
32nd IETF,
33rd IETF,
34th IETF,
35th IETF,
36th IETF,
38th IETF,
39th IETF,
40th IETF,
41st IETF,
43rd IETF,
44th IETF,
45th IETF
and
46th IETF
The GRIP working group met once during this IETF. The agenda for the meeting was the following:
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:
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:
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."
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.
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 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.
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:
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:
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:
"A second document...vendors to help them with security incidents"
Actually it is much broader than that: should we really have this pointer here?
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 mailing list will be updated to include the new persons who attended these meetings.
Please send questions, comments, and/or suggestions regarding the GRIP working group to the open mailing list grip-wg@uu.net.
All issues regarding these web pages should be directed to klaus-peter@kossakowski.de.
These pages are hosted on http://www.kossakowski.de and are provided on an "AS IS" basis without any explicite or implicite responsibility, liability, etc. (For a more fully understanding please refer to the legal statements within the Impressum, which is only available in German.)