rfc2350.txt

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

   assists in incident tracking and prevents 'loops' in communication.

   The reporting and disclosure policy should make clear who will be the
   recipients of a CSIRT's report in each circumstance.  It should also
   note whether the team will expect to operate through another CSIRT or
   directly with a member of another constituency over matters
   specifically concerning that member.

   Related groups a CSIRT will interact with are listed below:

   Incident Response Teams:
      A CSIRT will often need to interact with other CSIRTs.  For
      example a CSIRT within a large company may need to report
      incidents to a national CSIRT, and a national CSIRT may need to
      report incidents to national CSIRTs in other countries to deal
      with all sites involved in a large-scale attack.

      Collaboration between CSIRTs may lead to disclosure of
      information.  The following are examples of such disclosure, but
      are not intended to be an exhaustive list:

       - Reporting incidents within the constituency to other teams.
         If this is done, site-related information may become public
         knowledge, accessible to everyone, in particular the press.

       - Handling incidents occurring within the constituency, but
         reported from outside it (which implies that some information
         has already been disclosed off-site).



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


       - Reporting observations from within the constituency indicating
         suspected or confirmed incidents outside it.

       - Acting on reports of incidents from outside the constituency.

       - Passing information about vulnerabilities to vendors, to
         partner CSIRTs or directly to affected sites lying within or
         outside the constituency.

       - Feedback to parties reporting incidents or vulnerabilities.

       - The provision of contact information relating to members of
         the constituency, members of other constituencies, other
         CSIRTs, or law-enforcement agencies.

   Vendors:
      Some vendors have their own CSIRTs, but some vendors may not.  In
      such cases a CSIRT will need to work directly with a vendor to
      suggest improvements or modifications, to analyze the technical
      problem or to test provided solutions.  Vendors play a special
      role in handling an incident if their products' vulnerabilities
      are involved in the incident.

   Law-enforcement agencies:
      These include the police and other investigative agencies.  CSIRTs
      and users of the template should be sensitive to local laws and
      regulations, which may vary considerably in different countries.
      A CSIRT might advise on technical details of attacks or seek
      advice on the legal implications of an incident. Local laws and
      regulations may include specific reporting and confidentiality
      requirements.

   Press:
      A CSIRT may be approached by the press for information and comment
      from time to time.

      An explicit policy concerning disclosure to the press can be
      helpful, particularly in clarifying the expectations of a CSIRT's
      constituency.  The press policy will have to clarify the same
      topics as above more specifically, as the constituency will
      usually be very sensitive to press contacts.

   Other:
      This might include research activities or the relation to the
      sponsoring organization.






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


   The default status of any and all security-related information which
   a team receives will usually be 'confidential,' but rigid adherence
   to this makes the team to appear to be an informational 'black hole,'
   which may reduce the likelihood of the team's obtaining cooperation
   from clients and from other organizations.  The CSIRT's template
   should define what information it will report or disclose, to whom,
   and when.

   Different teams are likely to be subject to different legal
   restraints requiring or limiting disclosure, especially if they work
   in different jurisdictions.  In addition, they may have reporting
   requirements imposed by their sponsoring organization.  Each team's
   template should specify any such constraints, both to clarify users'
   expectations and to inform other teams.

   Conflicts of interest, particularly in commercial matters, may also
   restrain disclosure by a team; this document does not recommend on
   how such conflicts should be addressed.

   A team will normally collect statistics.  If statistical information
   is distributed, the template's reporting and disclosure policy should
   say so, and should describe how to obtain such statistics.

3.4.3 Communication and Authentication

   You must have a policy which describes methods of secure and
   verifiable communication that you will use.  This is necessary for
   communication between CSIRTs and between a CSIRT and its
   constituents.  The template should include public keys or pointers to
   them, including key fingerprints, together with guidelines on how to
   use this information to check authenticity and how to deal with
   corrupted information (for example where to report this fact).

   At the moment it is recommended that as a minimum every CSIRT have
   (if possible), a PGP key available.  A team may also make other
   mechanisms available (for example PEM, MOSS, S/MIME), according to
   its needs and the needs of its constituents.   Note however, that
   CSIRTs and users should be sensitive to local laws and regulations.
   Some countries do not allow strong encryption, or enforce specific
   policies on the use of encryption technology.  In addition to
   encrypting sensitive information whenever possible, correspondence
   should include digital signatures.  (Please note that in most
   countries, the protection of authenticity by using digital signatures
   is not affected by existing encryption regulations.)

   For communication via telephone or facsimile a CSIRT may keep secret
   authentication data for parties with whom they may deal, such as an
   agreed password or phrase.  Obviously, such secret keys must not be



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


   published, though their existence may be.

3.5 Services

   Services provided by a CSIRT can be roughly divided into two
   categories: real-time activities directly related to the main task of
   incident response, and non-real-time proactive activities, supportive
   of the incident response task. The second category and part of the
   first category consist of services which are optional in the sense
   that not all CSIRTs will offer them.

3.5.1 Incident Response

   Incident response usually includes assessing incoming reports about
   incidents ("Incident Triage") and following up on these with other
   CSIRTs, ISPs and sites ("Incident Coordination"). A third range of
   services, helping a local site to recover from an incident ("Incident
   Resolution"), is comprised of typically optional services, which not
   all CSIRTs will offer.

3.5.1.1 Incident Triage

   Incident triage usually includes:

   - Report assessment           Interpretion of incoming incident
                                 reports, prioritizing them, and
                                 relating them to ongoing incidents
                                 and trends.

   - Verification                Help in determining whether an
                                 incident has really occurred, and
                                 its scope.

3.5.1.2 Incident Coordination

   Incident Coordination normally includes:

   - Information categorization  Categorization of the incident related
                                 information (logfiles, contact
                                 information, etc.) with respect to
                                 the information disclosure policy.

   - Coordination                Notification of other involved
                                 parties on a need-to-know basis, as
                                 per the information disclosure
                                 policy.





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


3.5.1.3 Incident Resolution

   Usually additional or optional, incident resolution services
   include:

   - Technical Assistance        This may include analysis of
                                 compromised systems.

   - Eradication                 Elimination of the cause of a
                                 security incident (the vulnerability
                                 exploited), and its effects (for
                                 example, continuing access to the
                                 system by an intruder).

   - Recovery                    Aid in restoring affected systems
                                 and services to their status before
                                 the security incident.

3.5.2. Proactive Activities

   Usually additional or optional, proactive services might include:

   - Information provision       This might include an archive of
                                 known vulnerabilities, patches or
                                 resolutions of past problems, or
                                 advisory mailing lists.

   - Security Tools              This may include tools for auditing
                                 a Site's security.

   - Education and training

   - Product evaluation

   - Site security auditing and consulting

3.6 Incident Reporting Forms

   The use of reporting forms makes it simpler for both users and teams
   to deal with incidents.  The constituent can prepare answers to
   various important questions before he or she actually contacts the
   team, and can therefore come well prepared.  The team gets all the
   necessary information at once with the first report and can proceed
   efficiently.

   Depending on the objectives and services of a particular CSIRT,
   multiple forms may be used, for example a reporting form for a new
   vulnerability may be very different from the form used for reporting



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


   incidents.

   It is most efficient to provide forms through the online information
   services of the team.  The exact pointers to them should be given in
   the CSIRT description document, together with statements about
   appropriate use, and guidelines for when and how to use the forms. If
   separate e-mail addresses are supported for form-based reporting,
   they should be listed here again.

   One example of such a form is the Incident Reporting Form provided by
   the CERT Coordination Center:

   - ftp://info.cert.org/incident_reporting_form

3.7 Disclaimers

   Although the CSIRT description document does not constitute a
   contract, liability may conceivably result from its descriptions of
   services and purposes.  The inclusion of a disclaimer at the end of
   the template is therefore recommended and should warn the user about
   possible limitations.

   In situations where the original version of a document must be
   translated into another language, the translation should carry a
   disclaimer and a pointer to the original.  For example:

      Although we tried to carefully translate the original document
      from German into English, we can not be certain that both
      documents express the same thoughts in the same level of detail
      and correctness.  In all cases, where there is a difference
      between both versions, the German version will prevail.

   The use of and protection by disclaimers is affected by local laws
   and regulations, of which each CSIRT should be aware. If in doubt the
   CSIRT should check the disclaimer with a lawyer.
















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


Appendix A: Glossary of Terms

   This glossary defines terms used in describing security incidents and
   Computer Security Incident Response Teams.  Only a limited list is
   included.  For more definitions please refer to other sources, for