rfc2350.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

        Can somebody else manipulate the content of the communication?

      - Authenticity:
        Am I communicating with the "right" person?

   It is very easy to send forged e-mail, and not hard to establish a
   (false) identity by telephone.    Cryptographic techniques, for
   example Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM) can
   provide effective ways of securing e-mail.  With the correct
   equipment it is also possible to secure telephone communication. But
   before using such mechanisms, both parties need the "right"
   infrastructure, which is to say preparation in advance.  The most
   important preparation is ensuring the authenticity of the



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


   cryptographic keys used in secure communication:

   - Public keys (for techniques like PGP and PEM):
     Because they are accessible through the Internet, public keys must
     be authenticated before use.  While PGP relies on a "Web of Trust"
     (where users sign the keys of other users), PEM relies on a
     hierarchy (where certification authorities sign the keys of users).

   - Secret keys (for techniques like DES and PGP/conventional
     encryption):  Because these must be known to both sender and
     receiver, secret keys must be exchanged before the communication
     via a secure channel.

   Communication is critical to all aspects of incident response.  A
   team can best support the use of the above-mentioned techniques by
   gathering all relevant information, in a consistent way.  Specific
   requirements (such as calling a specific number to check the
   authenticity of keys) should be clear from the start.  CSIRT
   templates provide a standardized vehicle for delivering this
   information.

   It is beyond the scope of this document to address the technical and
   administrative problems of secure communications.  The point is that
   response teams must support and use a method to secure the
   communications between themselves and their constituents (or other
   response teams).  Whatever the mechanism is, the level of protection
   it provides must be acceptable to the constituent community.

3 Information, Policies and Procedures

   In chapter 2 it was mentioned that the policies and procedures of a
   response team need to be published to their constituent community.
   In this chapter we will list all the types of information that the
   community needs to receive from its response team.  How this
   information is communicated to a community will differ from team to
   team, as will the specific information content.  The intent here is
   to clearly describe the various kinds of information that a
   constituent community expects from its response team.

   To make it easier to understand the issues and topics relevant to the
   interaction of constituents with "their" CSIRT, we suggest that a
   CSIRT publish all information, policies, and procedures addressing
   its constituency as a document, following the template given in
   Appendix D.  The template structure arranges items, making it easy to
   supply specific information; in Appendix E we provide an example of a
   filled-out template for the fictitious XYZ University.  While no
   recommendations are made as to what a CSIRT should adopt for its
   policy or procedures, different possibilities are outlined to give



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


   some examples.  The most important thing is that a CSIRT have a
   policy and that those who interact with the CSIRT be able to obtain
   and understand it.

   As always, not every aspect for every environment and/or team can be
   covered.  This outline should be seen as a suggestion.  Each team
   should feel free to include whatever they think is necessary to
   support its constituency.

3.1 Obtaining the Document

   Details of a CSIRT change with time, so the completed template must
   indicate when it was last changed.  Additionally, information should
   be provided concerning how to find out about future updates. Without
   this, it is inevitable that misunderstandings and misconceptions will
   arise over time; outdated documents can do more harm than good.

   - Date of last update         This should be sufficient to allow
                                 anyone interested to evaluate the
                                 currency of the template.

   - Distribution list           Mailing lists are a convenient
                                 mechanism to distribute up-to-date
                                 information to a large number of
                                 users.  A team can decide to use its
                                 own or an already existing list to
                                 notify users whenever the document
                                 changes.  The list might normally be
                                 groups the CSIRT has frequent
                                 interactions with.

                                 Digital signatures should be used
                                 for update messages sent by a CSIRT.

   - Location of the document    The location where a current version
                                 of the document is accessible through
                                 a team's online information services.
                                 Constituents can then easily learn
                                 more about the team and check for
                                 recent updates.  This online version
                                 should also be accompanied by a
                                 digital signature.









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


3.2 Contact Information

   Full details of how to contact the CSIRT should be listed here,
   although this might be very different for different teams; for
   example, some might choose not to publicize the names of their team
   members. No further clarification is given when the meaning of the
   item can be assumed.

   - Name of the CSIRT

   - Mailing Address

   - Time zone                   This is useful for coordinating
                                 incidents which cross time zones.

   - Telephone number

   - Facsimile number

   - Other telecommunication     Some teams might provide secure
                                 voice communication (e.g. STU III).

   - Electronic mail address

   - Public keys and encryption  The use of specific techniques
                                 depends on the ability of the
                                 communication partners to have
                                 access to programs, keys and so on.
                                 Relevant information should be
                                 given to enable users to determine
                                 if and how they can make use of
                                 encrypted communication while
                                 interacting with the CSIRT.
   - Team members

   - Operating Hours             The operating hours and holiday
                                 schedule should be provided here.
                                 Is there a 24 hour hotline?

   - Additional Contact Info     Is there any specific customer
                                 contact info?

   More detailed contact information can be provided.  This might
   include different contacts for different services, or might be a list
   of online information services.  If specific procedures for access to
   some services exist (for example addresses for mailing list
   requests), these should be explained here.




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


3.3 Charter

   Every CSIRT must have a charter which specifies what it is to do, and
   the authority under which it will do it.  The charter should include
   at least the following items:

   - Mission statement
   - Constituency
   - Sponsorship / affiliation
   - Authority

3.3.1 Mission Statement

   The mission statement should focus on the team's core activities,
   already stated in the definition of a CSIRT.  In order to be
   considered a Computer Security Incident Response Team, the team must
   support the reporting of incidents and support its constituency by
   dealing with incidents.

   The goals and purposes of a team are especially important, and
   require clear, unambiguous definition.

3.3.2 Constituency

   A CSIRT's constituency can be determined in any of several ways. For
   example it could be a company's employees or its paid subscribers, or
   it could be defined in terms of a technological focus, such as the
   users of a particular operating system.

   The definition of the constituency should create a perimeter around
   the group to whom the team will provide service.  The policy section
   of the document (see below) should explain how requests from outside
   this perimeter will be handled.

   If a CSIRT decides not to disclose its constituency, it should
   explain the reasoning behind this decision. For example, for-fee
   CSIRTs will not list their clients but will declare that they provide
   a service to a large group of customers that are kept confidential
   because of the clients' contracts.

   Constituencies might overlap, as when an ISP provides a CSIRT which
   delivers services to customer sites that also have CSIRTs.  The
   Authority section of the CSIRT's description (see below) should make
   such relationships clear.







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


3.3.3 Sponsoring Organization / Affiliation

   The sponsoring organization, which authorizes the actions of the
   CSIRT, should be given next.   Knowing this will help the users to
   understand the background and set-up of the CSIRT, and it is vital
   information for building trust between a constituent and a CSIRT.

3.3.4 Authority

   This section will vary greatly from one CSIRT to another, based on
   the relationship between the team and its constituency.   While an
   organizational CSIRT will be given its authority by the management of
   the organization, a community CSIRT will be supported and chosen by
   the community, usually in a advisory role.

   A CSIRT may or may not have the authority to intervene in the
   operation of all of the systems within its perimeter.  It should
   identify the scope of its control as distinct from the perimeter of
   its constituency.  If other CSIRTs operate hierarchically within its
   perimeter, this should be mentioned here, and the related CSIRTs
   identified.

   Disclosure of a team's authority may expose it to claims of
   liability.  Every team should seek legal advice on these matters.
   (See section 3.7 for more on liability.)

3.4 Policies

   It is critical that Incident Response Teams define their policies.
   The following sections discuss communication of these policies to the
   constituent community.

3.4.1 Types of Incidents and Level of Support

   The types of incident which the team is able to address, and the
   level of support which the team will offer when responding to each
   type of incident, should be summarized here in list form.  The
   Services section (see below) provides the opportunity to give more
   detailed descriptions, and to address non-incident-related topics.

   The level of support may change depending on factors such as the
   team's workload and the completeness of the information available.
   Such factors should be outlined and their impact should be explained.
   As a list of known types of incidents will be incomplete with regard
   to possible or future incidents, a CSIRT should also give some
   background on the "default" support for incident types not otherwise
   mentioned.




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


   The team should state whether it will act on information it receives
   about vulnerabilities which create opportunities for future
   incidents.  A commitment to act on such information on behalf of its
   constituency is regarded as an optional proactive service policy
   rather than a core service requirement for a CSIRT.

3.4.2 Co-operation, Interaction and Disclosure of Information

   This section should make explicit which related groups the CSIRT
   routinely interacts with.  Such interactions are not necessarily
   related to the computer security incident response provided, but are
   used to facilitate better cooperation on technical topics or
   services.  By no means need details about cooperation agreements be
   given out; the main objective of this section is to give the
   constituency a basic understanding of what kind of interactions are
   established and what their purpose is.

   Cooperation between CSIRTs can be facilitated by the use of unique
   ticket number assignment combined with explicit handoff procedures.
   This reduces the chance of misunderstandings, duplications of effort,