Guidelines and Recommendations for Incident Processing BOF (GRIP) Reported by Louis Mamakos/UUNET Technologies The GRIP BOF met for two sessions on 6 December. Agenda o GRIP charter o Milestones o Vendor recommendations document o Response team recommendations document o Begin document outline, if time permits Charter A charter for the GRIP working group was proposed, discussed and modified. A revised charter was produced and agreed upon. The problem statement for the group was: The purpose of the Security Incident Response Working Group is to provide guidelines and recommendations to facilitate the consistent handling of security incidents in the Internet community. Guidelines will address technology vendors, network service providers, and response teams in their roles assisting organizations in resolving security incidents. These relationships are functional and can exist within and across organizational boundaries. The working group will produce two standards-track quality documents: o Guidelines for security incident response teams. o Guidelines for vendors (this will include both technology producers and network service providers). Milestones A set of milestones was agreed upon to measure the progress of the working group. Since the output of the working group will be two documents, most of the milestones refer to measuring the progress of the two documents to be produced. The milestones are: o February 1, 1995 - Draft describing problem statement and document taxonomy/vocabulary. Also cite the Site Security Handbook documents to make clear the relationship and scope between the two working groups and documents. o February 15, 1995 - Draft outline for remainder of Response Team document. o April 3, 1995 [April IETF] - Review of complete Internet-Draft of Response Team document at first working group meeting. The second working group meeting will be used to develop the outline for the second document. o June 1, 1995 - Reviewed, final version of Response Team document ready for Last Call. o June 30, 1995 - Second document Internet-Draft complete o July 17, 1995 [July IETF] - Review second and comment second Internet-Draft document. o September 1, 1995 - Reviewed, final version of Vendor document ready for Last Call. Document Discussion The group decided to begin with the response team document, since it will likely describe all of the terms which will likely be used in the other document as well. Both documents will have a very similar introduction or prologue to explain where the document fits within a related set of documents including the two produced by the GRIP Working Group as well as the Site Security Handbook produced by another IETF working group. The group discussed how the documents would be treated once released, and what the flavor of the documents would be. There was a discussion and observation that documents produced, even if not a standard, will likely be cited in a legal context. The document will be something to measure and describe how a response team, for instance, operates rather than offering advice on the ``correct'' way to operate a response team. The documents would act as an aid to describe the specific policies and functions of entities acting as response teams and in other roles. There was discussion about the partitioning of the ``problem'' between the GRIP group work, and what happens in the SSH Working Group. That is, site requirements and recommendations should be cited in the SSH group, while response team expectations and procedures be in the GRIP documents. There was an observation that there is a recursive property when describing the roles that particular entities take. For example, a ``Site'' is a recursive sort of entity, where it may have a response team component ``inside,'' but potentially looks like ``victim'' from the outside. There was agreement that the group does need to address causes of outages; only address what happens when it is diagnosed as a security incident. That is, there will not be specific recommendations on preventing incidents (which will be in the scope of the Site Security Handbook work), but to focus on incident handling related issues. Peter Berger graciously volunteered to be the editor of the first document. Document Outline At the second meeting of the GRIP BOF later in the day, there was a brief recap of the work which occurred in the first session. The bulk of the time was spent working on an outline of the first document. It was felt that there should be a set of terms which should be defined in the document (which could then be re-used in the second document). It was pretty clear that many of the terms which are used in talking about these issues are somewhat ambiguous. The following list of terms was proposed. Specific definitions can be filled in later: o Incidents o Response teams o Sites o Users [Define these as roles] o Vendors - product/technology producers [Would be good to have a term less loaded than ``vendor''] o Shell accounts o Security o Secure communications o Vulnerability o Network service provider Internet Shell account o Information service provider The members of the group then began to flesh out an outline of the topics to be covered in the ``response team'' document. There were a few major areas, with topics which fit under each: o Functions - validate problem - technical assistance analysis to understand compromise - authenticate source? - notification of other involved entities - assistance - information provider * vulnerability archive * patches and resolutions * tools - education - audit and consulting - product evaluation o Policies - disclosure - the response team should have a policy of disclosure; how much to disclose, to whom and when. Does a response team contact another affected party, or the party's response team? - cooperation and interaction policies with other response teams - define kinds of incidents handled - define levels of support for various types of incidents - vul. handling * searching for them * handling reported ones o Response team interactions - with other response teams - with those reporting incidents - with other involved users/sites - with law enforcement - with public/press - with vendors (that is technology producer or service providers) - with perpetrator or perpetrator's organization o Procedures - Internal security - secure communications - authenticated information distribution - incident reporting - dealing with public relations o Forming a response team - defining constituency - define scope of authority/perimeter - identify other response teams - (how about an FYI to enumerate response teams) - operating procedures There was considerable discussion during the building of this list, and some issues came to light regarding the scope of the response team activities, the degrees of assistance they could provide, etc. As a part of handling an incident, you are removing the immediate cause incident from a system (or decide not to). Part of responding is being able to deal with other response teams. Response teams may have limitations due to span of control. Response teams must establish their scope of control before incidents occur. The group should produce a standard template or form which describes the way that response teams operate to facilitate communications between response teams. Information in the template would be the points described in the document, a ``template for a framework.'' This concluded the work done by the group at the second BOF meeting. The editor offered that a first draft of the introduction to the first document could be available before the end of the year. Further work on the remainder of the document will occur on the mailing list, with an Internet-Draft to be produced before the next IETF meeting where it will be commented on and modified.