home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94jul / grip-minutes-94jul.txt < prev    next >
Text File  |  1994-11-01  |  6KB  |  159 lines
  1.  
  2. Guidelines and Recommendations for Incident Processing BOF (GRIP)
  3.  
  4. Reported by Louis Mamakos/UUNET Technologies
  5.  
  6.  
  7. Purpose
  8.  
  9. The GRIP BOF meet to discuss forming a working group which would produce
  10. guidelines and recommendations for use when dealing with security
  11. related incidents.  The scope was to produce recommendations suitable
  12. for use by response teams (RTs), Internet users and vendors of hardware
  13. and software products.
  14.  
  15. The participants decided that the scope of the BOF would address only
  16. security related issues rather than, e.g., legal issues such as use of
  17. the Internet for the commission of crimes and how to interact with law
  18. enforcement agencies.  This should be thought about, and perhaps another
  19. effort can be spun off in a year when the issues in that area are better
  20. understood.
  21.  
  22. We need to define what an ``incident'' is (e.g., break-ins, denial of
  23. service attacks, etc).  If we consider the attributes of integrity,
  24. confidentiality and availability, loss or attack on any one of these
  25. might be considered a ``security incident.''
  26.  
  27. The BOF felt that a working group should address response to incidents
  28. and what response teams (RTs) should do, rather than an education or
  29. prevention effort.  It was felt that the Site Security effort would
  30. address this, and there there was already plenty of response activities
  31. going on.
  32.  
  33.  
  34. Response Teams
  35.  
  36. How is a response team established (for example, an in-house response
  37. team)?  How does one response team interact with others?
  38.  
  39. What sort of information is needed for a response team to respond?
  40.  
  41. How about mandatory auditing and other tools which users can be expected
  42. to have?  Should there be recommendations made in the site security
  43. handbook?
  44.  
  45. Should have response team recommendations vs.  external procedures; that
  46. is, the team itself rather than how one response team interacts with
  47. another response team.
  48.  
  49. Need a single framework for a response team; this could make it easier
  50. for one RT to communicate with another like group since the expectations
  51. and procedures could be similar.
  52.  
  53. Include expectations on RT capabilities, e.g., secure communications.
  54.  
  55. It might be useful to have a government entity maintain a registry of
  56. identified, certified or somehow blessed response teams.  This could
  57. provide liability protection.  ``Launder your liability.''
  58.  
  59. Should a security organization hierarchy be defined or referenced?  This
  60. would include a site security officer, organizational-wide security
  61. people.  Should investigate existing organizations and structures, such
  62. as those in place for the DDN, for further ideas.
  63.  
  64. A response team acts as a proxy for their constituency, and need to have
  65. some authority to do so.  The mandate and authority need to come from
  66. high enough in the organization.
  67.  
  68. ``Vendors'' would include entities such as Internet service providers,
  69. and other things which can have broken security.
  70.  
  71. There are, perhaps, multiple classes of vendors and RTs.
  72.  
  73. Advice to software authors:  how to package software with signatures.
  74.  
  75. Should describe methods for users and vendors interact on security
  76. issues.
  77.  
  78. Should describe methods for response teams and vendors to interact on
  79. security issues.
  80.  
  81. Response teams should have secure communications at their disposal for
  82. communicating with other response teams and their users.
  83.  
  84. How should incidents which are submitted from outside be handled; that
  85. is, how does an incident get handed off to another response team.
  86.  
  87. Need to define constituency of a response team - the users which they
  88. are to address and the technology (hardware, operating systems, etc.)
  89. which they can support.
  90.  
  91. Define a plan of action and procedures for escalation of security
  92. incidents.
  93.  
  94. RTs have to have sufficient resources available to be able to function
  95. effectively.
  96.  
  97. RTs need to somehow establish credibility.
  98.  
  99. Each response team needs to define its authority to operate on behalf of
  100. a constituency, and the responsibility that it has.
  101.  
  102. User's are expected to know their RT contact.
  103.  
  104. Should list some recommended tools for RT use.
  105.  
  106. Need to document RT contact procedures and opportunities (i.e., 9-5 or
  107. complete 24x7 coverage) and what sort of responses are expected.
  108.  
  109.  
  110.  
  111. Vendor Response Guidelines
  112.  
  113. Are ISPs ``vendors''?
  114.  
  115. Define a scale of security incident severity which can be used to label
  116. a particular incident and which can be used to gauge an appropriate
  117. response.
  118.  
  119. What about ``network harm'' issues, where a site has been compromised
  120. and is a source of further attacks.  When do you pull the plug?
  121.  
  122. Need a system to measure vendor response to security incidents at a
  123. particular severity level.
  124.  
  125. Software packages (commercial, freely available) need to have strong
  126. signature verification.  This can be use to detect versions of software
  127. which have been tampered with.  One approach might be to approach FTP
  128. archive sites and other software distribution points and have them
  129. require or attach signatures.
  130.  
  131. Software documentation should include security contact points and
  132. procedures in their documentation.  Should this documentation, where
  133. appropriate, also include RT information and procedures?
  134.  
  135. This should include hardware and software vendors, as well as ``free''
  136. software authors.
  137.  
  138. Need to develop a scale or table for relating RT timing for their
  139. actions vs.  vendor response timing.  That is, once a vendor has been
  140. notified, a sequence of events is might be set into motion which will
  141. occur even if a vendor doesn't respond in time.
  142.  
  143.  
  144. Administrivia
  145.  
  146. The participants of the BOF agreed that there was sufficient interest in
  147. the issues discussed to establish a working group.
  148.  
  149. A mailing list, grip-wg@uunet.uu.net, will be set up.  Requests to be
  150. added or removed should be sent to grip-wg-request@uunet.uu.net.  Any
  151. requests which are sent to the whole mailing list, rather than the
  152. request mailbox, will be cheerfully ignored.  The attendees of this
  153. meeting will be automatically added to the mailing list.
  154.  
  155. The first order of business is to produce a charter for the working
  156. group and a schedule of milestones.  This will be discussed on the
  157. mailing list.
  158.  
  159.