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
  the information by the parties.)

  The goals of secure communication are:

     - Confidentiality:
       Can somebody else access the content of the communication?

     - Integrity:
       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,
  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
  example to the Internet User's Glossary [RFC 1983].

  Constituency:
     Implicit in the purpose of a Computer Security Incident Response
     Team is the existence of a constituency.  This is the group of
     users, sites, networks or organizations served by the team.  The
     team must be recognized by its constituency in order to be
     effective.

  Security Incident:
     For the purpose of this document, this term is a synonym of
     Computer Security Incident: any adverse event which compromises
     some aspect of computer or network security.

     The definition of an incident may vary between organizations, but
     at least the following categories are generally applicable:

     - Loss of confidentiality of information.
     - Compromise of integrity of information.
     - Denial of service.
     - Misuse of service, systems or information.
     - Damage to systems.

     These are very general categories.  For instance the replacement
     of a system utility program by a Trojan Horse is an example of '
     compromise of integrity,' and a successful password attack is an
     example of 'loss of confidentiality.'  Attacks, even if they
     failed because of proper protection, can be regarded as Incidents.

     Within the definition of an incident the word 'compromised' is
     used.  Sometimes an administrator may only 'suspect' an incident.
     During the response it must be established whether or not an
     incident has really occurred.

  Computer Security Incident Response Team:
     Based on two of the definitions given above, a CSIRT is a team
     that coordinates and supports the response to security incidents
     that involve sites within a defined constituency.

     In order to be considered a CSIRT, a team must:

     - Provide a (secure) channel for receiving reports about
       suspected incidents.



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


     - Provide assistance to members of its constituency in
       handling these incidents.
     - Disseminate incident-related information to its
       constituency and to other involved parties.

     Note that we are not referring here to police or other law
     enforcement bodies which may investigate computer-related crime.
     CSIRT members, indeed, need not have any powers beyond those of
     ordinary citizens.

  Vendor:
     A 'vendor' is any entity that produces networking or computing
     technology, and is responsible for the technical content of that
     technology.  Examples of 'technology' include hardware (desktop
     computers, routers, switches, etc.), and software (operating
     systems, mail forwarding systems, etc.).

     Note that the supplier of a technology is not necessarily the '
     vendor' of that technology.  As an example, an Internet Service
     Provider (ISP) might supply routers to each of its customers, but
     the 'vendor' is the manufacturer, since the manufacturer, rather
     than the ISP, is the entity responsible for the technical content
     of the router.

  Vulnerability:
     A 'vulnerability' is a characteristic of a piece of technology
     which can be exploited to perpetrate a security incident.  For
     example, if a program unintentionally allowed ordinary users to
     execute arbitrary operating system commands in privileged mode,
     this "feature" would be a vulnerability.





















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


Appendix B: Related Material

  Important issues in responding to security incidents on a site level
  are contained in [RFC 2196], the Site Security Handbook, produced by
  the Site Security Handbook Working Group (SSH).  This document will
  be updated by the SSH working group and will give recommendations for
  local policies and procedures, mainly related to the avoidance of
  security incidents.

  Other documents of interest for the discussion of CSIRTs and their
  tasks are available by anonymous FTP. A collection can be found on:

  - ftp://ftp.cert.dfn.de/pub/docs/csir/
    Please refer to file 01-README for further information about
    the content of this directory.

  Some especially interesting documents in relation to this document
  are as follows:

  - ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/
    reports/R-92-01
    This report contains the Operational Framework of CERT-NL, the
    CSIRT of SURFnet (network provider in the Netherlands).

  - For readers interested in the operation of FIRST (Forum of
    Incident Response and Security Teams) more information is
    collected in Appendix C.

  - http://hightop.nrl.navy.mil/news/incident.html
    This document leads to the NRL Incident Response Manual.

  - http://www.cert.dfn.de/eng/team/kpk/certbib.html
    This document contains an annotated bibliography of available
    material, documents and files about the operation of CSIRTs
    with links to many of the referenced items.

  - ftp://info.cert.org/incident_reporting_form
    This Incident Reporting Form is provided by the CERT
    Coordination Center to gather incident information and to avoid
    additional delays caused by the need to request more detailed
    information from the reporting site.

  - http://www.cert.org/cert.faqintro.html
    A collection of frequently asked questions from the CERT
    Coordination Center.






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


Appendix C: Known Computer Security Incident Response Teams

  Today, there are many different CSIRTs but no single source lists
  every team. Most of the major and long established teams (the first
  CSIRT was founded in 1988) are nowadays members of FIRST, the
  worldwide Forum of Incident Response and Security Teams.  At the time
  of writing, more than 55 teams are members (1 in Australia, 13 in
  Europe, all others in North America).  Information about FIRST can be
  found:

  - http://www.first.org/

  The current list of members is available also, with the relevant
  contact information and some additional information provided by the
  particular teams:

  - http://www.first.org/team-info/

  For CSIRTs which want to become members of this forum (please note
  that a team needs a sponsor - a team which is already a full member
  of FIRST - to be introduced), the following files contain more
  information:

  - http://www.first.org/about/op_frame.html
    The Operational Framework of FIRST.

  - http://www.first.org/docs/newmem.html
    Guidelines for teams which want to become members of FIRST.

  Many of the European teams, regardless of whether they are members
  of FIRST or not, are listed by countries on a page maintained by
  the German CSIRT:

  - http://www.cert.dfn.de/eng/csir/europe/certs.html

  To learn about existing teams suitable to one's needs it is
  often helpful to ask either known teams or an Internet Service
  Provider for the "right" contact.













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


Appendix D: Outline for CSIRT Template

  This outline summarizes in point form the issues addressed in this
  document, and is the recommended template for a CSIRT description
  document.  Its structure is designed to facilitate the communication
  of a CSIRT's policies, procedures, and other relevant information to
  its constituency and to outside organizations such as other CSIRTs. A
  'filled-in' example of this template is given as Appendix E.

     1.   Document Information
     1.1  Date of Last Update
     1.2  Distribution List for Notifications
     1.3  Locations where this Document May Be Found

     2.   Contact Information
     2.1  Name of the Team
     2.2  Address
     2.3  Time Zone
     2.4  Telephone Number
     2.5  Facsimile Number
     2.6  Other Telecommunication
     2.7  Electronic Mail Address
     2.8  Public Keys and Encryption Information
     2.9  Team Members
     2.10 Other Information
     2.11 Points of Customer Contact

     3.   Charter
     3.1  Mission Statement
     3.2  Constituency
     3.3  Sponsorship and/or Affiliation
     3.4  Authority

     4.   Policies
     4.1  Types of Incidents and Level of Support
     4.2  Co-operation, Interaction and Disclosure of Information
     4.3  Communication and Authentication

     5.   Services
     5.1  Incident Response
          5.1.1. Incident Triage
          5.1.2. Incident Coordination
          5.1.3. Incident Resolution
     5.2  Proactive Activities

     6.   Incident Reporting Forms

     7.   Disclaimers



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


Appendix E: Example - 'filled-in' Template for a CSIRT

  Below is an example of a filled-in template for a fictitious CSIRT
  called XYZ-CSIRT.  This text is for example purposes only, and does
  not constitute endorsement by the working group or the IETF of any
  particular set of procedures or policies.  While CSIRTs are welcome
  to use any or all of this text if they wish, such use is of course
  not mandatory, or even appropriate in most cases.

CSIRT Description for XYZ-CERT
-----------------------------

  1. About this document

  1.1 Date of Last Update

       This is version 1.01, published 1997/03/31.

  1.2 Distribution List for Notifications

       Notifications of updates are submitted to our mailing list
       <[email protected]>.  Subscription requests for this
       list should be sent to the Majordomo at
       <[email protected]>; the body of the message
       should consist of the word "subscribe".  Send the word "help"
       instead if you don't know how to use a Majordomo list manager.
       This mailing list is moderated.

  1.3 Locations where this Document May Be Found

       The current version of this CSIRT description document is
       available from the XYZ-CERT WWW site; its URL is
         http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.txt
       Une version francaise de ce document est igalement disponible:
         http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.txt
       Please make sure you are using the latest version.

  1.4 Authenticating this Document

       Both the English and French versions of this document have
       been signed with the XYZ-CERT's PGP key.  The signatures are
       also on our Web site, under:
         http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.asc
         http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.asc







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


  2. Contact Information

  2.1 Name of the Team

       "XYZ-CERT": the XYZ University Computer Emergency Response
       Team.

  2.2 Address

       XYZ-CERT
       XYZ University, Computing Services Department
       12345 Rue Principale
       UniversityTown, Quebec
       Canada H0H 0H0

  2.3 Time Zone

       Canada/Eastern (GMT-0500, and GMT-0400 from April to October)

  2.4 Telephone Number

       +1 234 567 7890  (ask for the XYZ-CERT)

  2.5 Facsimile Number

       +1 234 567 7899  (this is *not* a secure fax)

  2.6 Other Telecommunication

       None available.

  2.7 Electronic Mail Address

       <[email protected]>  This is a mail alias that relays mail
       to the human(s) on duty for the XYZ-CERT.

  2.8 Public Keys and Other Encryption Information

       The XYZ-CERT has a PGP key, whose KeyID is 12345678 and
       whose fingerprint is
         11 22 33 44 55 66 77 88  88 77 66 55 44 33 22 11.
       The key and its signatures can be found at the usual large
       public keyservers.

       Because PGP is still a relatively new technology at XYZ
       University, this key still has relatively few signatures;
       efforts are underway to increase the number of links to this
       key in the PGP "web of trust".  In the meantime, since most



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


       fellow universities in Quebec have at least one staff member
       who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has
       signed the XYZ-CERT key, and will be happy to confirm its
       fingerprint and that of her own key to those people who know
       her, by telephone or in person.

  2.9 Team Members

       Zoe Doe of Computing Services is the XYZ-CERT coordinator.
       Backup coordinators and other team members, along with their
       areas of expertise and contact information, are listed in the
       XYZ-CERT web pages, at
         http://www.xyz-univ.ca/xyz-cert/teamlist.html

       Management, liaison and supervision are provided by Steve Tree,
       Assistant Director (Technical Services), Computing Services.

  2.10 Other Information

       General information about the XYZ-CERT, as well as links to
       various recommended security resources, can be found at
         http://www.xyz-univ.ca/xyz-cert/index.html

  2.11 Points of Customer Contact

       The preferred method for contacting the XYZ-CERT is via
       e-mail at <[email protected]>; e-mail sent to this address
       will "biff" the responsible human, or be automatically
       forwarded to the appropriate backup person, immediately.  If
       you require urgent assistance, put "urgent" in your subject
       line.

       If it is not possible (or not advisable for security reasons)
       to use e-mail, the XYZ-CERT can be reached by telephone during
       regular office hours.  Telephone messages are checked less
       often than e-mail.

       The XYZ-CERT's hours of operation are generally restricted to
       regular business hours (09:00-17:00 Monday to Friday except
       holidays).

       If possible, when submitting your report, use the form
       mentioned in section 6.








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


  3. Charter

  3.1 Mission Statement

       The purpose of the XYZ-CERT is, first, to assist members of XYZ
       University community in implementing proactive measures to
       reduce the risks of computer security incidents, and second, to
       assist XYZ community in responding to such incidents when they
       occur.

  3.2 Constituency

       The XYZ-CERT's constituency is the XYZ University community,
       as defined in the context of the "XYZ University Policy on
       Computing Facilities".  This policy is available at
         http://www-compserv.xyz-univ.ca/policies/pcf.html

       However, please note that, notwithtanding the above, XYZ-CERT
       services will be provided for on-site systems only.

  3.3 Sponsorship and/or Affiliation

       The XYZ-CERT is sponsored by the ACME Canadian Research
       Network.  It maintains affiliations with various University
       CSIRTs throughout Canada and the USA on an as needed basis.

  3.4 Authority

       The XYZ-CERT operates under the auspices of, and with authority
       delegated by, the Department of Computing Services of XYZ
       University.  For further information on the mandate and
       authority of the Department of Computing Services, please
       refer to the XYZ University "Policy on Computing Facilities",
       available at
         http://www-compserv.xyz-univ.ca/policies/pcf.html

       The XYZ-CERT expects to work cooperatively with system
       administrators and users at XYZ University, and, insofar as
       possible, to avoid authoritarian relationships.  However,
       should circumstances warrant it, the XYZ-CERT will appeal to
       Computing Services to exert its authority, direct or indirect,
       as necessary.  All members of the XYZ-CERT are members of the
       CCSA (Committee of Computer Systems Administrators), and have
       all of the powers and responsibilities assigned to Systems
       Administrators by the Policy on Computing Facilities, or are
       members of University management.





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


       Members of the XYZ University community who wish to appeal the
       actions of the XYZ-CERT should contact the Assistant Director
       (Technical Services), Computing Services.  If this recourse is
       not satisfactory, the matter may be referred to the Director
       of Computing Services (in the case of perceived
       problems with existing policy), or to the XYZ University
       Office of Rights and Responsibilities (in the case of perceived
       errors in the application of existing policy).

  4. Policies

  4.1 Types of Incidents and Level of Support

       The XYZ-CERT is authorized to address all types of computer
       security incidents which occur, or threaten to occur, at
       XYZ University.

       The level of support given by XYZ-CERT will vary depending on
       the type and severity of the incident or issue, the type of
       constituent, the size of the user community affected, and the
       XYZ-CERT's resources at the time, though in all cases some
       response will be made within one working day.  Resources will
       be assigned according to the following priorities, listed in
       decreasing order:

         - Threats to the physical safety of human beings.
         - Root or system-level attacks on any Management Information
           System, or any part of the backbone network infrastructure.
         - Root or system-level attacks on any large public service
           machine, either multi-user or dedicated-purpose.
         - Compromise of restricted confidential service accounts or
           software installations, in particular those used for MIS
           applications containing confidential data, or those used
           for system administration.
         - Denial of service attacks on any of the above three items.
         - Any of the above at other sites, originating from XYZ
           University.
         - Large-scale attacks of any kind, e.g. sniffing attacks,
           IRC "social engineering" attacks, password cracking
           attacks.
         - Threats, harassment, and other criminal offenses
           involving individual user accounts.
         - Compromise of individual user accounts on multi-user
           systems.
         - Compromise of desktop systems.
         - Forgery and misrepresentation, and other security-related
           violations of local rules and regulations, e.g. netnews
           and e-mail forgery, unauthorized use of IRC bots.



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


         - Denial of service on individual user accounts, e.g.
           mailbombing.

       Types of incidents other than those mentioned above will be
       prioritized according to their apparent severity and extent.

       Note that no direct support will be given to end users; they
       are expected to contact their system administrator, network
       administrator, or department head for assistance.  The XYZ-CERT
       will support the latter people.

       While the XYZ-CERT understands that there exists great
       variation in the level of system administrator expertise at XYZ
       University, and while the XYZ-CERT will endeavor to present
       information and assistance at a level appropriate to each
       person, the XYZ-CERT cannot train system administrators on the
       fly, and it cannot perform system maintenance on their behalf.
       In most cases, the XYZ-CERT will provide pointers to the
       information needed to implement appropriate measures.

       The XYZ-CERT is committed to keeping the XYZ University system
       administration community informed of potential vulnerabilities,
       and where possible, will inform this community of such
       vulnerabilities before they are actively exploited.

  4.2 Co-operation, Interaction and Disclosure of Information

       While there are legal and ethical restrictions on the flow of
       information from XYZ-CERT, many of which are also outlined in
       the XYZ University Policy on Computing Facilities, and all of
       which will be respected, the XYZ-CERT acknowledges its
       indebtedness to, and declares its intention to contribute to,
       the spirit of cooperation that created the Internet.
       Therefore, while appropriate measures will be taken to protect
       the identity of members of our constituency and members of
       neighbouring sites where necessary, the XYZ-CERT will otherwise
       share information freely when this will assist others in
       resolving or preventing security incidents.

       In the paragraphs below, "affected parties" refers to the
       legitimate owners, operators, and users of the relevant
       computing facilities.  It does not refer to unauthorized
       users, including otherwise authorized users making
       unauthorized use of a facility; such intruders may have no
       expectation of confidentiality from the XYZ-CERT.  They may or
       may not have legal rights to confidentiality; such rights will
       of course be respected where they exist.




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


       Information being considered for release will be classified as
       follows:

         - Private user information is information about particular
           users, or in some cases, particular applications, which
           must be considered confidential for legal, contractual,
           and/or ethical reasons.

           Private user information will be not be released in
           identifiable form outside the XYZ-CERT, except as provided
           for below.  If the identity of the user is disguised, then
           the information can be released freely (for example to show
           a sample .cshrc file as modified by an intruder, or to
           demonstrate a particular social engineering attack).

         - Intruder information is similar to private user
           information, but concerns intruders.

           While intruder information, and in particular identifying
           information, will not be released to the public (unless it
           becomes a  matter of public record, for example because
           criminal charges have been laid), it will be exchanged
           freely with system administrators and CSIRTs tracking an
           incident.

         - Private site information is technical information about
           particular systems or sites.

           It will not be released without the permission of the site
           in question, except as provided for below.

         - Vulnerability information is technical information about
           vulnerabilities or attacks, including fixes and
           workarounds.

           Vulnerability information will be released freely, though
           every effort will be made to inform the relevant vendor
           before the general public is informed.

         - Embarrassing information includes the statement that an
           incident has occurred, and information about its extent or
           severity.  Embarrassing information may concern a site or
           a particular user or group of users.

           Embarrassing information will not be released without the
           permission of the site or users in question, except as
           provided for below.




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


         - Statistical information is embarrassing information with
           the identifying information stripped off.

           Statistical information will be released at the discretion
           of the Computing Services Department.

         - Contact information explains how to reach system
           administrators and CSIRTs.

           Contact information will be released freely, except where
           the contact person or entity has requested that this not
           be the case, or where XYZ-CERT has reason to believe that
           the dissemination of this information would not be
           appreciated.

       Potential recipients of information from the XYZ-CERT will be
       classified as follows:

       - Because of the nature of their responsibilities and
         consequent expectations of confidentiality, members of XYZ
         University management are entitled to receive whatever
         information is necessary to facilitate the handling of
         computer security incidents which occur in their
         jurisdictions.

       - Members of the Office of Rights and Responsibilities are
         entitled to receive whatever information they request
         concerning a computer security incident or related matter
         which has been referred to them for resolution.  The same is
         true for the XYZ Security Department, when its assistance in
         an investigation has been enlisted, or when the investigation
         has been instigated at its request.

       - System administrators at XYZ University who are members of
         the CCSA are also, by virtue of their responsibilities,
         trusted with confidential information.  However, unless such
         people are also members of XYZ-CERT, they will be given only
         that confidential information which they must have in order
         to assist with an investigation, or in order to secure their
         own systems.

       - Users at XYZ University are entitled to information which
         pertains to the security of their own computer accounts,
         even if this means revealing "intruder information", or
         "embarrassing information" about another user.  For
         example, if account aaaa is cracked and the intruder attacks
         account bbbb, user bbbb is entitled to know that aaaa was
         cracked, and how the attack on the bbbb account was



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


         executed.  User bbbb is also entitled, if she or he requests
         it, to information about account aaaa which might enable
         bbbb to investigate the attack.  For example, if bbbb was
         attacked by someone remotely connected to aaaa, bbbb should
         be told the provenance of the connections to aaaa, even
         though this information would ordinarily be considered
         private to aaaa.  Users at XYZ University are entitled to be
         notified if their account is believed to have been
         compromised.

       - The XYZ University community will receive no restricted
         information, except where the affected parties have given
         permission for the information to be disseminated.
         Statistical information may be made available to the general
         XYZ community.  There is no obligation on the part of the
         XYZ-CERT to report incidents to the community, though it may
         choose to do so; in particular, it is likely that the
         XYZ-CERT will inform all affected parties of the ways in
         which they were affected, or will encourage the affected site
         to do so.

       - The public at large will receive no restricted information.
         In fact, no particular effort will be made to communicate
         with the public at large, though the XYZ-CERT recognizes
         that, for all intents and purposes, information made
         available to the XYZ University community is in effect made
         available to the community at large, and will tailor the
         information in consequence.

       - The computer security community will be treated the same way
         the general public is treated.  While members of XYZ-CERT may
         participate in discussions within the computer security
         community, such as newsgroups, mailing lists (including the
         full-disclosure list "bugtraq"), and conferences, they will
         treat such forums as though they were the public at large.
         While technical issues (including vulnerabilities) may be
         discussed to any level of detail, any examples taken from
         XYZ-CERT experience will be disguised to avoid identifying
         the affected parties.

       - The press will also be considered as part of the general
         public.  The XYZ-CERT will not interact directly with the
         Press concerning computer security incidents, except to point
         them toward information already released to the general
         public.  If necessary, information will be provided to the
         XYZ University Public Relations Department, and to the
         Customer Relations group of the Computing Services
         Department.  All incident-related queries will be referred to



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


         these two bodies.  The above does not affect the ability of
         members of XYZ-CERT to grant interviews on general computer
         security topics; in fact, they are encouraged to do to, as a
         public service to the community.

       - Other sites and CSIRTs, when they are partners in the
         investigation of a computer security incident, will in some
         cases be trusted with confidential information.  This will
         happen only if the foreign site's bona fide can be verified,
         and the information transmitted will be limited to that which
         is likely to be helpful in resolving the incident.  Such
         information sharing is most likely to happen in the case of
         sites well known to XYZ-CERT (for example, several other
         Quebec universities have informal but well-established
         working relationships with XYZ University in such matters).

         For the purposes of resolving a security incident, otherwise
         semi-private but relatively harmless user information such as
         the provenance of connections to user accounts will not be
         considered highly sensitive, and can be transmitted to a
         foreign site without excessive precautions.  "Intruder
         information" will be transmitted freely to other system
         administrators and CSIRTs.  "Embarrassing information" can be
         transmitted when there is reasonable assurance that it will
         remain confidential, and when it is necessary to resolve an
         incident.

       - Vendors will be considered as foreign CSIRTs for most intents
         and purposes.  The XYZ-CERT wishes to encourage vendors of
         all kinds of networking and computer equipment, software, and
         services to improve the security of their products.  In aid
         of this, a vulnerability discovered in such a product will be
         reported to its vendor, along with all technical details
         needed to identify and fix the problem.  Identifying details
         will not be given to the vendor without the permission of the
         affected parties.

       - Law enforcement officers will receive full cooperation from
         the XYZ-CERT, including any information they require to
         pursue an investigation, in accordance with the Policy on
         Computing Facilities.

  4.3 Communication and Authentication

       In view of the types of information that the XYZ-CERT will
       likely be dealing with, telephones will be considered
       sufficiently secure to be used even unencrypted.  Unencrypted
       e-mail will not be considered particularly secure, but will be



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


       sufficient for the transmission of low-sensitivity data.  If
       it is necessary to send highly sensitive data by e-mail, PGP
       will be used.  Network file transfers will be considered to
       be similar to e-mail for these purposes: sensitive data should
       be encrypted for transmission.

       Where it is necessary to establish trust, for example before
       relying on information given to the XYZ-CERT, or before
       disclosing confidential information, the identity and bona
       fide of the other party will be ascertained to a reasonable
       degree of trust.  Within XYZ University, and with known
       neighbor sites, referrals from known trusted people will
       suffice to identify someone.  Otherwise, appropriate methods
       will be used, such as a search of FIRST members, the use of
       WHOIS and other Internet registration information, etc, along
       with telephone call-back or e-mail mail-back to ensure that
       the party is not an impostor.  Incoming e-mail whose data must
       be trusted will be checked with the originator personally, or
       by means of digital signatures (PGP in particular is
       supported).

  5. Services

  5.1 Incident Response

       XYZ-CERT will assist system administrators in handling the
       technical and organizational aspects of incidents.  In
       particular, it will provide assistance or advice with respect
       to the following aspects of incident management:

  5.1.1 Incident Triage

           - Investigating whether indeed an incident occured.
           - Determining the extent of the incident.

  5.1.2 Incident Coordination

           - Determining the initial cause of the incident
             (vulnerability exploited).
           - Facilitating contact with other sites which may be
             involved.
           - Facilitating contact with XYZ University Security and/or
             appropriate law enforcement officials, if necessary.
           - Making reports to other CSIRTs.
           - Composing announcements to users, if applicable.






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


  5.1.3 Incident Resolution

           - Removing the vulnerability.
           - Securing the system from the effects of the incident.
           - Evaluating whether certain actions are likely to reap
             results in proportion to their cost and risk, in
             particular those actions aimed at an eventual prosecution
             or disciplinary action: collection of evidence after the
             fact, observation of an incident in progress, setting
             traps for intruders, etc.
           - Collecting evidence where criminal prosecution, or
             University disciplinary action, is contemplated.

       In addition, XYZ-CERT will collect statistics concerning
       incidents which occur within or involve the XYZ University
       community, and will notify the community as necessary to
       assist it in protecting against known attacks.

       To make use of XYZ-CERT's incident response services, please
       send e-mail as per section 2.11 above.  Please remember that
       the amount of assistance available will vary according to
       the parameters described in section 4.1.

  5.2 Proactive Activities

       The XYZ-CERT coordinates and maintains the following
       services to the extent possible depending on its resources:
         - Information services
            - List of departmental security contacts, administrative
              and technical.  These lists will be available to the
              general public, via commonly-available channels such as
              the World Wide Web and/or the Domain Name Service.
            - Mailing lists to inform security contacts of new
              information relevant to their computing environments.
              These lists will be available only to XYZ University
              system administrators.
            - Repository of vendor-provided and other security-related
              patches for various operating systems.  This repository
              will be available to the general public wherever
              license restrictions allow it, and will be provided via
              commonly-available channels such as the World Wide Web
              and/or ftp.
            - Repository of security tools and documentation for
              use by sysadmins.  Where possible, precompiled
              ready-to-install versions will be supplied.  These will
              be supplied to the general public via www or ftp as
              above.




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


            - "Clipping" service for various existing resources, such
              as major mailing lists and newsgroups.  The resulting
              clippings will be made available either on the
              restricted mailing list or on the web site, depending
              on their sensitivity and urgency.
         - Training services
            - Members of the XYZ-CERT will give periodic seminars on
              computer security related topics; these seminars will
              be open to XYZ University system administrators.
         - Auditing services
            - Central file integrity checking service for Unix
              machines, and for any other platforms capable of
              running "tripwire".
            - Security level assignments; machines and subnetworks
              at XYZ University will be audited and assigned a
              security level.  This security level information will be
              available to the XYZ University community, to facilitate
              the setting of appropriate access privileges.  However,
              details of the security analyses will be confidential,
              and available only to the concerned parties.
         - Archiving services
            - Central logging service for machines capable of
              Unix-style remote logging.  Incoming log entries will
              be watched by an automated log analysis program, and
              events or trends indicative of a potential security
              problem will be reported to the affected system
              administrators.
            - Records of security incidents handled will be kept.
              While the records will remain confidential, periodic
              statistical reports will be made available to the XYZ
              University community.

       Detailed descriptions of the above services, along with
       instructions for joining mailing lists, downloading
       information, or participating in certain services such as the
       central logging and file integrity checking services, are
       available on the XYZ-CERT web site, as per section 2.10
       above.

  6. Incident Reporting Forms

       There are no local forms developed yet for reporting incidents
       to XYZ-CERT. If possible, please make use of the Incident
       Reporting Form of the CERT Coordination Center (Pittsburgh,
       PA).  The current version is available from:
          ftp://info.cert.org/incident_reporting_form





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


  7. Disclaimers

       While every precaution will be taken in the preparation of
       information, notifications and alerts, XYZ-CERT assumes no
       responsibility for errors or omissions, or for damages
       resulting from the use of the information contained within.

4 Acknowlegdements

  The editors gratefully acknowledge the contributed material and
  editorial scrutiny of Anne Bennett.   Thanks also to Don Stikvoort
  for assistance reworking the description of Incident Response Team
  services.

5 References

  [RFC 2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
  September 1997.

  [RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
  August 1996.

6 Security Considerations

  This document discusses the operation of Computer Security Incident
  Response Teams, and the teams' interactions with their constituencies
  and with other organizations.  It is, therefore, not directly
  concerned with the security of protocols, applications, or network
  systems themselves.  It is not even concerned with particular
  responses and reactions to security incidents, but only with the
  appropriate description of the responses provided by CSIRTs.

  Nonetheless, it is vital that the CSIRTs themselves operate securely,
  which means that they must establish secure communication channels
  with other teams, and with members of their constituency.  They must
  also secure their own systems and infrastructure, to protect the
  interests of their constituency and to maintain the confidentiality
  of the identity of victims and reporters of security incidents.













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


7 Authors' Addresses

  Nevil Brownlee
  ITSS Technology Development
  The University of Auckland

  Phone: +64 9 373 7599 x8941
  EMail: [email protected]


  Erik Guttman
  Sun Microsystems, Inc.
  Bahnstr. 2
  74915 Waibstadt Germany

  Phone: +49 7263 911484
  EMail: [email protected]


































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


8 Full Copyright Statement

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

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.






















Brownlee & Guttman       Best Current Practice                 [Page 38]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.