rfc2350.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,565 行 · 第 1/5 页

Network Working Group                                       N. Brownlee
Request for Comments: 2350                   The University of Auckland
BCP: 21                                                      E. Guttman
Category: Best Current Practice                        Sun Microsystems
                                                              June 1998


          Expectations for Computer Security Incident Response

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   The purpose of this document is to express the general Internet
   community's expectations of Computer Security Incident Response Teams
   (CSIRTs). It is not possible to define a set of requirements that
   would be appropriate for all teams, but it is possible and helpful to
   list and describe the general set of topics and issues which are of
   concern and interest to constituent communities.

   CSIRT constituents have a legitimate need and right to fully
   understand the policies and procedures of 'their' Computer Security
   Incident Response Team.  One way to support this understanding is to
   supply detailed information which users may consider, in the form of
   a formal template completed by the CSIRT.  An outline of such a
   template and a filled in example are provided.

Table of Contents

   1 Introduction ....................................................2
   2 Scope............................................................4
     2.1 Publishing CSIRT Policies and Procedures ....................4
     2.2 Relationships between different CSIRTs ......................5
     2.3 Establishing Secure Communications ..........................6
   3 Information, Policies and Procedures.............................7
     3.1 Obtaining the Document.......................................8
     3.2 Contact Information .........................................9
     3.3 Charter ....................................................10
         3.3.1 Mission Statement.....................................10
         3.3.2 Constituency..........................................10



Brownlee & Guttman       Best Current Practice                  [Page 1]

RFC 2350  Expectations for Computer Security Incident Response June 1998


         3.3.3 Sponsoring Organization / Affiliation.................11
         3.3.4 Authority.............................................11
     3.4 Policies ...................................................11
         3.4.1 Types of Incidents and Level of Support...............11
         3.4.2 Co-operation, Interaction and Disclosure of
               Information...........................................12
         3.4.3 Communication and Authentication......................14
     3.5 Services ...................................................15
         3.5.1 Incident Response ....................................15
               3.5.1.1 Incident Triage ..............................15
               3.5.1.2 Incident Coordination ........................15
               3.5.1.3 Incident Resolution...........................16
         3.5.2 Proactive Activities .................................16
     3.6 Incident Reporting Forms ...................................16
     3.7 Disclaimers ................................................17
   Appendix A: Glossary of Terms ....................................18
   Appendix B: Related Material .....................................20
   Appendix C: Known Computer Security Incident Response Teams ......21
   Appendix D: Outline for CSIRT Template ...........................22
   Appendix E: Example - 'filled-in' Template for a CSIRT ...........23
   4 Acknowlegements ................................................36
   5 References .....................................................36
   6 Security Considerations ........................................36
   7 Authors' Addresses .............................................37
   8 Full Copyright Statement .......................................38

1 Introduction

   The GRIP Working Group was formed to create a document that describes
   the community's expectations of computer security incident response
   teams (CSIRTs).  Although the need for such a document originated in
   the general Internet community, the expectations expressed should
   also closely match those of more restricted communities.

   In the past there have been misunderstandings regarding what to
   expect from CSIRTs.  The goal of this document is to provide a
   framework for presenting the important subjects (related to incident
   response) that are of concern to the community.

   Before continuing, it is important to clearly understand what is
   meant by the term "Computer Security Incident Response Team."  For
   the purposes of this document, a CSIRT is a team that performs,
   coordinates, and supports the response to security incidents that
   involve sites within a defined constituency (see Appendix A for a
   more complete definition).  Any group calling itself a CSIRT for a
   specific constituency must therefore react to reported security
   incidents, and to threats to "their" constituency in ways which the
   specific community agrees to be in its general interest.



Brownlee & Guttman       Best Current Practice                  [Page 2]

RFC 2350  Expectations for Computer Security Incident Response June 1998


   Since it is vital that each member of a constituent community be able
   to understand what is reasonable to expect of their team, a CSIRT
   should make it clear who belongs to their constituency and define the
   services the team offers to the community. Additionally, each CSIRT
   should publish its policies and operating procedures. Similarly,
   these same constituents need to know what is expected of them in
   order for them to receive the services of their team.  This requires
   that the team also publish how and where to report incidents.

   This document details a template which will be used by CSIRTs to
   communicate this information to their constituents.  The constituents
   should certainly expect a CSIRT to provide the services they describe
   in the completed template.

   It must be emphasized that without active participation from users,
   the effectiveness of the CSIRT's services can be greatly diminished.
   This is particularly the case with reporting.  At a minimum, users
   need to know that they should report security incidents, and know how
   and to where they should report them.

   Many computer security incidents originate outside local community
   boundaries and affect inside sites, others originate inside the local
   community and affect hosts or users on the outside.  Often,
   therefore, the handling of security incidents will involve multiple
   sites and potentially multiple CSIRTs.  Resolving these incidents
   will require cooperation between individual sites and CSIRTs, and
   between CSIRTs.

   Constituent communities need to know exactly how their CSIRT will be
   working with other CSIRTs and organizations outside their
   constituency, and what information will be shared.

   The rest of this document describes the set of topics and issues that
   CSIRTs need to elaborate for their constituents. However, there is no
   attempt to specify the "correct" answer to any one topic area.
   Rather, each topic is discussed in terms of what that topic means.

   Chapter two provides an overview of three major areas:  the
   publishing of information by a response team, the definition of the
   response team's relationship to other response teams, and the need
   for secure communications.  Chapter three describes in detail all the
   types of information that the community needs to know about their
   response team.

   For ease of use by the community, these topics are condensed into an
   outline template found in Appendix D.  This template can be used by
   constituents to elicit information from their CSIRT.




Brownlee & Guttman       Best Current Practice                  [Page 3]

RFC 2350  Expectations for Computer Security Incident Response June 1998


   It is the working group's sincere hope that through clarification of
   the topics in this document, understanding between the community and
   its CSIRTs will be increased.

2 Scope

   The interactions between an incident response team and its
   constituent community response team require first that the community
   understand the policies and procedures of the response team. Second,
   since many response teams collaborate to handle incidents, the
   community must also understand the relationship between their
   response team and other teams.  Finally, many interactions will take
   advantage of existing public infrastructures, so the community needs
   to know how those communications will be protected. Each of these
   subjects will be described in more detail in the following three
   sections.

2.1 Publishing CSIRT Policies and Procedures

   Each user who has access to a Computer Security Incident Response
   Team should know as much as possible about the services of and
   interactions with this team long before he or she actually needs
   them.

   A clear statement of the policies and procedures of a CSIRT helps the
   constituent understand how best to report incidents and what support
   to expect afterwards.  Will the CSIRT assist in resolving the
   incident?   Will it provide help in avoiding incidents in the future?
   Clear expectations, particularly of the limitations of the services
   provided by a CSIRT, will make interaction with it more efficient and
   effective.

   There are different kinds of response teams: some have very broad
   constituencies (e.g., CERT Coordination Center and the Internet),
   others have more bounded constituencies (e.g., DFN-CERT, CIAC), and
   still others have very restricted constituencies (e.g., commercial
   response teams, corporate response teams).  Regardless of the type of
   response team, the constituency supported by it must be knowledgeable
   about the team's policies and procedures. Therefore, it is mandatory
   that response teams publish such information to their constituency.

   A CSIRT should communicate all necessary information about its
   policies and services in a form suitable to the needs of its
   constituency.  It is important to understand that not all policies
   and procedures need be publicly available.  For example, it is not
   necessary to understand the internal operation of a team in order to
   interact with it, as when reporting an incident or receiving guidance
   on how to analyze or secure one's systems.



Brownlee & Guttman       Best Current Practice                  [Page 4]

RFC 2350  Expectations for Computer Security Incident Response June 1998


   In the past, some teams supplied a kind of Operational Framework,
   others provided a Frequently Asked Questions list (FAQ), while still
   others wrote papers for distribution at user conferences or sent
   newsletters.

   We recommend that each CSIRT publish its guidelines and procedures on
   its own information server (e.g. a World Wide Web server).  This
   would allow constituents to easily access it, though the problem
   remains of how a constituent can find his or her team; people within
   the constituency have to discover that there is a CSIRT "at their
   disposal."

   It is foreseen that completed CSIRT templates will soon become
   searchable by modern search engines,  which will aid in distributing
   information about the existence of CSIRTs and basic information
   required to approach them.

   It would be very useful to have a central repository containing all
   the completed CSIRT templates.  No such repository exists at the time
   of writing, though this might change in the future.

   Regardless of the source from which the information is retrieved, the
   user of the template must check its authenticity.  It is highly
   recommended that such vital documents be protected by digital
   signatures.  These will allow the user to verify that the template
   was indeed published by the CSIRT and that it has not been tampered
   with. This document assumes the reader is familiar with the proper
   use of digital signatures to determine whether a document is
   authentic.

2.2 Relationships between different CSIRTs

   In some cases a CSIRT may be able to operate effectively on its own
   and in close cooperation with its constituency.  But with today's
   international networks it is much more likely that most of the
   incidents handled by a CSIRT will involve parties external to its
   constituency.  Therefore the team will need to interact with other
   CSIRTs and sites outside its constituency.

   The constituent community should understand the nature and extent of
   this collaboration, as very sensitive information about individual
   constituents may be disclosed in the process.

   Inter-CSIRT interactions could include asking other teams for advice,
   disseminating knowledge of problems, and working cooperatively to
   resolve a security incident affecting one or more of the CSIRTs'
   constituencies.




Brownlee & Guttman       Best Current Practice                  [Page 5]

RFC 2350  Expectations for Computer Security Incident Response June 1998


   In establishing relationships to support such interactions, CSIRTs
   must decide what kinds of agreements can exist between them so as to
   share yet safeguard information, whether this relationship can be
   disclosed, and if so to whom.

   Note that there is a difference between a peering agreement, where
   the CSIRTs involved agree to work together and share information, and
   simple co-operation, where a CSIRT (or any other organization) simply
   contacts another CSIRT and asks for help or advice.

   Although the establishment of such relationships is very important
   and affects the ability of a CSIRT to support its constituency, it is
   up to the teams involved to decide about the details.  It is beyond
   the scope of this document to make recommendations for this process.
   However, the same set of information used to set expectations for a
   user community regarding sharing of information will help other
   parties to understand the objectives and services of a specific
   CSIRT, supporting a first contact.

2.3 Establishing Secure Communications

   Once one party has decided to share information with another party,
   or two parties have agreed to share information or work together - as
   required for the coordination of computer security incident response
   - all parties involved need secure communications channels. (In this
   context, "secure" refers to the protected transmission of information
   shared between different parties, and not to the appropriate use of