home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94dec / grip-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  8KB  |  227 lines
  1.  
  2. Guidelines and Recommendations for Incident Processing BOF (GRIP)
  3.  
  4. Reported by Louis Mamakos/UUNET Technologies
  5.  
  6. The GRIP BOF met for two sessions on 6 December.
  7.  
  8.  
  9. Agenda
  10.  
  11.    o GRIP charter
  12.    o Milestones
  13.    o Vendor recommendations document
  14.    o Response team recommendations document
  15.    o Begin document outline, if time permits
  16.  
  17.  
  18. Charter
  19.  
  20. A charter for the GRIP working group was proposed, discussed and
  21. modified.  A revised charter was produced and agreed upon.  The problem
  22. statement for the group was:
  23.  
  24.  
  25.  
  26.      The purpose of the Security Incident Response Working Group is
  27.      to provide guidelines and recommendations to facilitate the
  28.      consistent handling of security incidents in the Internet
  29.      community.  Guidelines will address technology vendors, network
  30.      service providers, and response teams in their roles assisting
  31.      organizations in resolving security incidents.  These
  32.      relationships are functional and can exist within and across
  33.      organizational boundaries.
  34.  
  35.  
  36.  
  37. The working group will produce two standards-track quality documents:
  38.  
  39.  
  40.    o Guidelines for security incident response teams.
  41.    o Guidelines for vendors (this will include both technology producers
  42.      and network service providers).
  43.  
  44.  
  45. Milestones
  46.  
  47. A set of milestones was agreed upon to measure the progress of the
  48. working group.  Since the output of the working group will be two
  49. documents, most of the milestones refer to measuring the progress of the
  50. two documents to be produced.  The milestones are:
  51.  
  52.  
  53.    o February 1, 1995 - Draft describing problem statement and document
  54.      taxonomy/vocabulary.  Also cite the Site Security Handbook
  55.      documents to make clear the relationship and scope between the two
  56.      working groups and documents.
  57.  
  58.    o February 15, 1995 - Draft outline for remainder of Response Team
  59.      document.
  60.  
  61.    o April 3, 1995 [April IETF] - Review of complete Internet-Draft of
  62.      Response Team document at first working group meeting.  The second
  63.      working group meeting will be used to develop the outline for the
  64.      second document.
  65.  
  66.    o June 1, 1995 - Reviewed, final version of Response Team document
  67.      ready for Last Call.
  68.  
  69.    o June 30, 1995 - Second document Internet-Draft complete
  70.  
  71.    o July 17, 1995 [July IETF] - Review second and comment second
  72.      Internet-Draft document.
  73.  
  74.    o September 1, 1995 - Reviewed, final version of Vendor document
  75.      ready for Last Call.
  76.  
  77.  
  78. Document Discussion
  79.  
  80. The group decided to begin with the response team document, since it
  81. will likely describe all of the terms which will likely be used in the
  82. other document as well.  Both documents will have a very similar
  83. introduction or prologue to explain where the document fits within a
  84. related set of documents including the two produced by the GRIP Working
  85. Group as well as the Site Security Handbook produced by another IETF
  86. working group.
  87.  
  88. The group discussed how the documents would be treated once released,
  89. and what the flavor of the documents would be.  There was a discussion
  90. and observation that documents produced, even if not a standard, will
  91. likely be cited in a legal context.  The document will be something to
  92. measure and describe how a response team, for instance, operates rather
  93. than offering advice on the ``correct'' way to operate a response team.
  94. The documents would act as an aid to describe the specific policies and
  95. functions of entities acting as response teams and in other roles.
  96.  
  97. There was discussion about the partitioning of the ``problem'' between
  98. the GRIP group work, and what happens in the SSH Working Group.  That
  99. is, site requirements and recommendations should be cited in the SSH
  100. group, while response team expectations and procedures be in the GRIP
  101. documents.
  102.  
  103. There was an observation that there is a recursive property when
  104. describing the roles that particular entities take.  For example, a
  105. ``Site'' is a recursive sort of entity, where it may have a response
  106. team component ``inside,'' but potentially looks like ``victim'' from
  107. the outside.
  108.  
  109. There was agreement that the group does need to address causes of
  110. outages; only address what happens when it is diagnosed as a security
  111. incident.  That is, there will not be specific recommendations on
  112. preventing incidents (which will be in the scope of the Site Security
  113. Handbook work), but to focus on incident handling related issues.
  114.  
  115. Peter Berger graciously volunteered to be the editor of the first
  116. document.
  117.  
  118.  
  119. Document Outline
  120.  
  121. At the second meeting of the GRIP BOF later in the day, there was a
  122. brief recap of the work which occurred in the first session.  The bulk
  123. of the time was spent working on an outline of the first document.  It
  124. was felt that there should be a set of terms which should be defined in
  125. the document (which could then be re-used in the second document).  It
  126. was pretty clear that many of the terms which are used in talking about
  127. these issues are somewhat ambiguous.
  128.  
  129. The following list of terms was proposed.  Specific definitions can be
  130. filled in later:
  131.  
  132.  
  133.    o Incidents
  134.    o Response teams
  135.    o Sites
  136.    o Users [Define these as roles]
  137.    o Vendors - product/technology producers [Would be good to have a
  138.      term less loaded than ``vendor'']
  139.    o Shell accounts
  140.    o Security
  141.    o Secure communications
  142.    o Vulnerability
  143.    o Network service provider Internet Shell account
  144.    o Information service provider
  145.  
  146.  
  147. The members of the group then began to flesh out an outline of the
  148. topics to be covered in the ``response team'' document.  There were a
  149. few major areas, with topics which fit under each:
  150.  
  151.  
  152.    o Functions
  153.       -  validate problem
  154.       -  technical assistance analysis to understand compromise
  155.       -  authenticate source?
  156.       -  notification of other involved entities
  157.       -  assistance
  158.       -  information provider
  159.           * vulnerability archive
  160.           * patches and resolutions
  161.           * tools
  162.       -  education
  163.       -  audit and consulting
  164.       -  product evaluation
  165.  
  166.    o Policies
  167.       -  disclosure - the response team should have a policy of
  168.          disclosure; how much to disclose, to whom and when.  Does a
  169.          response team contact another affected party, or the party's
  170.          response team?
  171.       -  cooperation and interaction policies with other response teams
  172.       -  define kinds of incidents handled
  173.       -  define levels of support for various types of incidents
  174.       -  vul.  handling
  175.           * searching for them
  176.           * handling reported ones
  177.  
  178.    o Response team interactions
  179.       -  with other response teams
  180.       -  with those reporting incidents
  181.       -  with other involved users/sites
  182.       -  with law enforcement
  183.       -  with public/press
  184.       -  with vendors (that is technology producer or service providers)
  185.       -  with perpetrator or perpetrator's organization
  186.  
  187.    o Procedures
  188.       -  Internal security
  189.       -  secure communications
  190.       -  authenticated information distribution
  191.       -  incident reporting
  192.       -  dealing with public relations
  193.  
  194.    o Forming a response team
  195.       -  defining constituency
  196.       -  define scope of authority/perimeter
  197.       -  identify other response teams
  198.       -  (how about an FYI to enumerate response teams)
  199.       -  operating procedures
  200.  
  201.  
  202. There was considerable discussion during the building of this list, and
  203. some issues came to light regarding the scope of the response team
  204. activities, the degrees of assistance they could provide, etc.
  205.  
  206. As a part of handling an incident, you are removing the immediate cause
  207. incident from a system (or decide not to).
  208.  
  209. Part of responding is being able to deal with other response teams.
  210.  
  211. Response teams may have limitations due to span of control.  Response
  212. teams must establish their scope of control before incidents occur.
  213.  
  214. The group should produce a standard template or form which describes the
  215. way that response teams operate to facilitate communications between
  216. response teams.  Information in the template would be the points
  217. described in the document, a ``template for a framework.''
  218.  
  219. This concluded the work done by the group at the second BOF meeting.
  220. The editor offered that a first draft of the introduction to the first
  221. document could be available before the end of the year.
  222.  
  223. Further work on the remainder of the document will occur on the mailing
  224. list, with an Internet-Draft to be produced before the next IETF meeting
  225. where it will be commented on and modified.
  226.  
  227.