Internet Engineering Task Force                          Nevil Brownlee
INTERNET-DRAFT                               The University of Auckland
Valid for six months                                       Erik Guttman
                                                       Sun Microsystems
              Expectations for Security Incident Response

                 <draft-ietf-grip-framework-irt-04.txt>

                 <draft-ietf-grip-framework-irt-05.txt>

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.  This Internet Draft is a
   product of the GRIP Working Group of the IETF.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   'working draft' or 'work in progress.'

   To learn the current status of any Internet Draft, please check the
   '1id-abstracts.txt' listing contained in the Internet Drafts shadow
   directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   The purpose of this document is to express the general Internet
   community's expectations of Security Incident Response Teams. Teams (SIRTs).
   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.

   SIRT constituents have a legitimate need and right to fully
   understand the policies and procedures of "their" 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 SIRT.  An outline of such a
   template and a filled in example is are provided.

Expectations for Security Incident Response                 26 March                 28 April 97

Table of Contents

   1 Introduction                                                      1

   2 Scope..............................................................3 Scope.............................................................3
     2.1 Publishing a SIRT Policies and Procedures .....................4 ......................3
     2.2 Relationships between different SIRTs .........................5 ........................4
     2.3 Establishing Secure Communications ............................6 ...........................5

   3 Information, Policies and Procedures...............................7 Procedures..............................6
     3.1 Obtaining the Document........................................7
     3.2 Contact Information ...........................................8
  3.2 Document Updates ..............................................9 ..........................................8
     3.3 Charter .......................................................9 ......................................................9
         3.3.1 Mission Statement.......................................10 Statement.......................................9
         3.3.2 Constituency............................................10 Constituency............................................9
         3.3.3 Sponsoring Organization / Affiliation...................10 Affiliation...................9
         3.3.4 Authority...............................................11 Authority...............................................9
     3.4 Policies .....................................................11 ....................................................10
         3.4.1 Types of Incidents and Level of Support.................11 Support................10
         3.4.2 Co-operation and Co-operation, Interaction with other Organizations...12
      3.4.3 Reporting and Disclosure................................13
      3.4.4 Disclosure of
               Information............................................11
         3.4.3 Communication and Authentication........................14
      3.4.5 Point of Customer Contacts..............................14 Authentication.......................13
     3.5 Services .....................................................15 ....................................................14
     3.6 Incident Reporting Forms .....................................15 ....................................14
     3.7 Disclaimers ..................................................16

4 .................................................15

   Appendix A: Glossary of Terms                                     17

5                                      15

   Appendix B: Related Material                                      18

6                                       17

   Appendix C: Known Security Incident Response Teams                19

7                 18

   Appendix D: Outline for SIRT Template                             21

8                              19

   Appendix E: Example - 'filled-in' Template for a SIRT             22

9              20

   4 Acknowlegments                                                   31

   5 References                                                        29

10                                                       32

   6 Security Considerations                                          29

11                                          32

   7 Authors' Addresses                                               29

Expectations for Security Incident Response                 26 March 97                                               32

1 Introduction

   The GRIP Working Group was formed to create a document that describes
   the community's expectations of security incident response teams
   (SIRTs).  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.

Expectations for Security Incident Response                 15 April 97

   In the past there have been misunderstandings regarding what to
   expect from SIRTs.  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 "Security Incident Response Team."  For the
   purposes of this document, a SIRT 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 SIRT 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.

   Since it is vital that each member of a constituent community be
   able to understand what is reasonable to expect of their team, A a SIRT
   should make it clear who belongs to their constituency and define the
   services the team offers to the community. Additionally, each SIRT
   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 incidents should be reported. to report incidents.

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

   It must be emphasised that without active participation from users,
   the effectiveness of the SIRT'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 to.

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,

Expectations for Security Incident Response                 26 March 97

the handling of security incidents will involve the cooperation of
multiple sites and potentially multiple SIRTs.  The coordination of
activities across communities and organization requires that the
parties understand who they are dealing with, and what sort of policies
they have in place. 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 SIRTs.  Resolving these incidents will
   require cooperation between individual sites and SIRTs, and between
   SIRTs.

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

   The rest of this document describes the set of topics and issues that
   SIRTs 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 it in terms of what that topic means.
   For example, five types of policy statements are listed

Expectations for Security Incident Response                 15 April 97

   (representing those policies of interest to the community), but the
   content of any one of them will necessarily be specific to a given
   team.

   Chapter two provides an overview of three major areas:  The  the
   publishing of information by a response team, the definition of the
   response team's relationship to other response teams 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.
These

   For ease of use by the community, these topics are condensed into an
   outline template for ease of use by
the community, and is found in Appendix D.  This template can be used
   by constituents to elicit information from their SIRT, and it provides
criteria with which to measure their team's performance. SIRT.

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

2 Scope

   The interactions between a constituent community and an incident response team and its
   constituent community response team require first that the community understands
   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

Expectations for Security Incident Response                 26 March 97 other teams.  Finally, many interactions will take
   advantage of existing public infrastructures and infrastructures, so the community needs
   to know how those communications are going to will be protected. Each of these
   subjects will be described in more detail in the following three
   sections.

2.1 Publishing a SIRT Policies and Procedures

   Each user who has access to a 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 SIRT helps the
   constituent understand how best to report incidents and what support
   to expect afterwards.  Will the SIRT 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 SIRT, will make interaction with it more
   efficient and effective.

   There are different kinds of response teams. Some that teams: some have very broad
   constituencies (e.g., CERT Coordination Center and the Internet),
   others that have more bounded constituencies (e.g., DFN-CERT, CIAC),
   and still others that have very restricted constituencies (e.g.,

Expectations for Security Incident Response                 15 April 97

   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.

As a

   A SIRT provides a service to a this clearly defined constituency,
it should communicate all necessary information about its
   policies and services in a form suitable form. to the needs of its
   constituency.  It is important to understand that not all policies
   and procedures must 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.

   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.

Another efficient way to communicate the relevant information to all
concerned, not only constituents but also other teams or organizations,
would be for

   We recommend that each SIRT to publish its guidelines and procedures on
   its own information server. server (e.g. a World Wide Web server).  This
   would allow constituents to easily access

Expectations for Security Incident Response                 26 March 97 it, although this does not address though the problem
   remains of how a constituent or
will can find "his" or "her" team.  People team; people
   within the constituency have to discover that there is a SIRT "at
   their disposal."

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

   It would be very useful to have a central repository containing all
   the completed SIRT templates.  No such repository presently exists.  This 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 can to verify that the template
   was indeed published by the SIRT and that it has not been modified
thereafter. tampered
   with. This document assumes the reader has familiarity is familiar with the proper
   use of digital signatures to determine whether a document is
   authentic.

2.2 Relationships between different SIRTs

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

Expectations for Security Incident Response                 15 April 97

   SIRTs and sites outside their its constituency.

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

Such

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

   In establishing relationships to support such interactions, SIRTs will
need to
   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.

Expectations for Security Incident Response                 26 March 97

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

   Although the establishing establishment of such relationships is very important
   and
affect affects the ability of a SIRT 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.  But
   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
   SIRT, 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 Security Incident Response security incident response - all
   parties involved need secure communications channels. ("Secure" hereby
relates (In this
   context, "secure" refers to the protected transmission of information
   shared between different parties 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?

Expectations for Security Incident Response                 15 April 97

   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
   cryptographic keys used in secure communication:

Expectations for Security Incident Response                 26 March 97

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

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

   Communication is critical for 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
(like (such as calling a specific number for checking to check the
   authenticity of keys) should be explained right away. clear from the start.  SIRT templates
   provide a standardized vehicle for delivering this information.

   It is beyond the scope of this document to address all 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, 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 all the issues and topics relevant to the
   interaction of constituents with "their" SIRT, we suggest that a SIRT
   publish all information, policies policies, and procedures addressing their its
   constituency as a document, following the template given in Appendix
   D.  The template structure arranges items, making it easy to supply
specific information, was done

Expectations for the example Security Incident Response                 15 April 97

   specific information; in Appendix E. E we provide an example of a
   filled-out template for the fictitious XYZ University.  While
   no recommendations are made as to what a SIRT should adopt for their its
   policy or procedures, different possibilities are outlined to give
   some examples.  The most important thing is that a SIRT has have a policy
   and that

Expectations for Security Incident Response                 26 March 97 that those who interact with the SIRT can 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 for
supporting their to
   support its constituency.

3.1 Contact Information

Full details of how to contact Obtaining the Document

   Details of a SIRT change with time, so the completed template must
   indicate when it was last changed.  Additionally, information should
   be listed here, although
this might be very different for different teams.  Some might choose provided concerning how to
restrict the availability of names of all team members. No further
clarification is given when the meaning of the item can be assumed.

   - Name of the SIRT

   - 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
                                   outlined so users can determine
                                   if and how they can make use of
                                   secure communication while
                                   interacting with the SIRT.
   - Team members

   - Other information             The operating hours and holiday
                                   schedule should be provided here.
                                   Is there a 24 hour hotline?  Is
                                   there any specific customer contact
                                   info?  (See also section 3.4.5).

Expectations for Security Incident Response                 26 March 97

3.2 Document Updates

Details of a SIRT change with time, so the completed template must
indicate when it was last changed.  Additionally, information should be
provided to learn about how to find out about future updates.  Without
this, it find out about future updates.  Without
   this, it is inevitable that misunderstandings and misconceptions will
   arise over time; an outdated document will 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
                                   cover the constituency and any other
                                   groups the SIRT has frequent
                                   interactions with.

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

   - Location of the document      The location where a current version
                                   of the document should be 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,

3.3 Charter

Every SIRT 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 statements:

   - Mission statement
   - Constituency
   - Sponsor / affiliation
   - Authority signature.

Expectations for Security Incident Response                 26 March                 15 April 97

3.3.1 Mission Statement

The mission statement should focus on the team's core activities,
already stated in the definition

3.2 Contact Information

   Full details of a SIRT.  In order how to be considered
a Security Incident Response Team, the team must support contact the reporting
of SIRT 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 SIRT

   - 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 SIRT.
   - 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.

Expectations for Security Incident Response                 28 April 97

3.3 Charter

   Every SIRT 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 SIRT.  In order to be
   considered a 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 SIRT'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 SIRT decides not to disclose its constituency, it should
   explain the reasoning behind this decision. For example, for-fee
   SIRTs 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 SIRT which
   delivers services to customer sites that also have SIRTs.  The
   Authority section of the SIRT's description (see below) should
   make such relationships clear.

3.3.3 Sponsoring Organization / Affiliation

   The sponsoring organization, which authorizes the actions of the
   SIRT, should be given next.   Knowing this will help the users to

Expectations for Security Incident Response                 28 April 97

   understand the background and set-up of the SIRT, and it is vital
   information for building trust between a constituent and a SIRT.

3.3.4 Authority

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

   A SIRT 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 SIRTs operate hierarchically within its
   perimeter, this should be mentioned here, and the related SIRTs
   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 SIRT should also give
   some background on the "default" support for incident types not
   otherwise mentioned.

   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 by dealing with incidents.

The goals is regarded as an optional proactive service policy
   rather than a core service requirement for a SIRT.

Expectations for Security Incident Response                 15 April 97

3.4.2 Co-operation, Interaction and purposes Disclosure of Information

   This section should make explicit which related groups the SIRT
   routinely interacts with.  Such interactions are not necessarily
   related to the 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 team basic
   understanding of what kind of interactions are especially important, established and require
clear, unambiguous definitions.

3.3.2 Constituency

A SIRT's constituency can what
   their purpose is.

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

   Important examples of related groups a SIRT will interact with are
   listed below.

   Incident Response Teams:
      A SIRT will often need to interact with other SIRTs. For example it
could be
      a company's employees or its paid subscribers, or it could be
defined SIRT within a large company may need to report incidents to a
      national SIRT, and a national SIRT may need to report incidents
      to national SIRTs in other countries to deal with all sites
      involved in terms of a technological focus, such as the users large-scale attack.

      Collaboration between SIRTs may lead to disclosure of a
particular operating system.
      information.  The definition following are examples of constituency should create a perimeter around such disclosure,
      but are not intended to be an exhaustive list:

       - Reporting incidents within the
group constituency to whom other teams.
         If this is done, site-related information may become public
         knowledge, accessible to everyone, in particular the team will provide service.  The policy section of press.

       - Handling incidents occurring within the document (see below) should explain how requests constituency, but
         reported from outside it (which implies that some information
         has already been disclosed off-site).

       - Reporting observations from within the
perimeter will be handled.

If a SIRT decide, not to disclosure their constituency, they should
explain constituency indicating
         suspected or confirmed incidents outside it.

       - Acting on reports of incidents occurring outside the reasoning behind this decision. For example for-fee
         constituency.

       - Passing information about vulnerabilities to vendors, to
         partner SIRTs will not list 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

Expectations for Security Incident Response                 15 April 97

         the constituency, members of other constituencies, other
         SIRTs, or law-enforcement agencies.

   Vendors:
      Larger vendors have their clients own SIRTs, but declare that they provide smaller vendors may not.
      In such cases a service SIRT will need to work directly with a large group of customers that are kept confidential
because of vendor to
      suggest improvements or modifications, to analyse the clients' contract.

Constituencies might overlap, as when an ISP provides a SIRT, but
delivers services technical
      problem or to customer sites which also have SIRTs.  The
Authority section test provided solutions.

   Law-enforcement agencies:
      These include the police and other investigative agencies.  SIRTs
      and users of the document (see below) template should make such
relationships clear.

3.3.3 Sponsoring Organization / Affiliation

The sponsoring organization, be sensitive to local laws and
      regulations, which authorizes may vary considerably in different countries.
      A SIRT might advise on technical details of attacks or seek
      advice on the actions legal implications of an incident. Local laws and
      regulations may include specific reporting and confidentiality
      requirements.

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

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

   Other:
      This might include research activities or the background and setup of relation to the SIRT.  It is vital information for
building up trust between a constituent
      sponsoring organization.

   The default status of any and all security-related information which
   a SIRT.

Expectations for Security Incident Response                 26 March 97

3.3.4 Authority

Based on the relationship between team and constituency this section receives will usually be very different from one 'confidential,' but rigid adherence
   to this makes the team to another. While an
organizational SIRT will appear to be given its authority by an informational 'black
   hole,' which may reduce the management,
a community SIRT likelihood of the team's obtaining
   cooperation from clients and from other organizations.  The SIRT's
   template should define what information it will be supported report or disclose,
   to whom, and chosen by the community,
usually when.

   Different teams are likely to be subject to different legal
   restraints requiring or limiting disclosure, especially if they work
   in a advisory role.

SIRTs different jurisdictions.  In addition, they may not have authority to intervene in the operation of all the
systems within reporting
   requirements imposed by their perimeter.  They sponsoring organization.  Each team's
   template should identify the scope of
their control as distinct from the perimeter of their constituency; if specify any such constraints, both to clarify users'
   expectations and to inform other SIRTs operate hierarchically within their perimeter, these 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 identified and addressed here. addressed.

   A 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 will normally collect statistics.  If statistical information

Expectations for more on liability.)

3.4 Policies

3.4.1 Types of Incidents and Level of Support

The types of incident which the team Security Incident Response                 28 April 97

   is able to address and the
level of support which distributed, the team will offer when responding template's reporting and disclosure policy
   should say so, and should describe how to each
type obtain such statistics.

3.4.3 Communication and Authentication

   Methods of incident secure and verifiable communication should be summarized here in list form.  The Services
section (see below) provides opportunity established.
   This is necessary for more detailed definition communication between SIRTs and to address non-incident related topics. between a SIRT
   and its constituents.  The level of support might change, depending on factors like workload template should include public keys or completeness of
   pointers to them, including key fingerprints, together with
   guidelines on how to use this information available.    Such factors should be
outlined to check authenticity and their impact should be explained.  As a list of known
types of incidents will be incomplete
   how to deal with regard corrupted information (for example where to possible or future
incidents, report
   this fact).

   At the moment it is recommended that as a minimum every SIRT should have
   (if possible), a PGP key available.  A team may also give some background on
   make other mechanisms available (for example PEM, MOSS, S/MIME),
   according to its needs and the "default"
support for each reported incident.

The team needs of its constituents.   Note
   however, that SIRTs and users should state whether it will act on information it receives
about vulnerabilities which create opportunities for future incidents.
A commitment be sensitive to act 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 SIRT may keep secret
   authentication data for parties with whom they may deal, such information on behalf of its constituency is
regarded as an optional pro-active service policy rather than a core
service requirement for a SIRT.
   agreed password or phrase.  Obviously, such secret keys must not be
   published, though their existence may be.

Expectations for Security Incident Response                 26 March                 15 April 97

3.4.2 Co-operation and Interaction with other Organizations

This section should make explicit which related groups with which the

3.5 Services

   Services provided by a SIRT routinely interacts with.  Such interactions are not related can be differentiated according to
the Security Incident Response provided, but are used
   whether they relate to facilitate
better cooperation on technical topics or services.  By no means should
details about cooperation agreements be given out, the main objective
of this section task, which is incident response, or
   are provided in addition to it, i.e. are optional in regard to give the constituency
   definition of a basic understanding
what kind SIRT.

   Incident response usually includes:

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

   - Technical Assistance          This may include analysis of interactions are established
                                   compromised systems.

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

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

   - Coordination                  Notification of these are listed below.

Incident Response Teams:
     A SIRT will often need to interact with other SIRTs. For example
     a SIRT within a large company involved
                                   parties.

   Additional or optional 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 need to report incidents to include tools for auditing
                                   a
     national SIRT, Site's security.

   - Education and a national SIRT may need to report incidents
     to national SIRTs in other countries 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 all sites
     involved in a large-scale attack.

Vendors:
     Larger vendors have their own SIRTs, but smaller vendors may not.
     In such cases a SIRT will need to work directly with a vendor to
     suggest improvements or modifications, incidents.  The constituent can prepare answers to analyse the technical
     problem
   various important questions before he or to test provided solutions.

Law-enforcement agencies:
     These include she actually contacts the police and other investigative agencies.  SIRTs
   team, and users of can therefore come well prepared.  The team gets all the template should be sensitive to local laws

Expectations for Security Incident Response                 15 April 97

   necessary information at once with the first report and
     regulations, which may vary considerably in different countries.
     A SIRT might advise on technical details of attacks or seek advice can proceed
   efficiently.

   Depending on the legal implications of an incident. Local laws objectives and
     regulations services of a particular SIRT,
   multiple forms may include specific be used, for example a reporting and confidentiality
     requirements.

Press:
     A SIRT form for a new
   vulnerability may be approached by very different from the Press form used for reporting
   incidents.

   It is most efficient to provide forms through the online information and comment
     from time
   services of the team.  The exact pointers to time.  This is discussed them should be given in more detail immediately
     below.

Other:
     This might include research activities or
   the relation SIRT description document, together with statements about
   appropriate use, and guidelines for when and how to use the
     sponsoring organization.

Expectations forms.
   If separate e-mail addresses are supported for Security form-based reporting,
   they should be listed here again.

   One example of such a form is the Incident Response                 26 March 97

3.4.3 Reporting Form provided by
   the CERT Coordination Center:

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

3.7 Disclaimers

   Although the SIRT description document does not constitute a
   contract, liability may conceivably result from its descriptions of
   services and Disclosure purposes.  The default status inclusion of any a disclaimer at the end of
   the template is therefore recommended and all security-related information which should warn the user about
   possible limitations.

   In situations where the original version of a
team receives will usually document must be 'confidential,' but rigid adherence to
this makes
   translated into another language, the team to appear as a 'black hole.'  Its template translation should
define what information it will report or disclose, to whom, carry a
   disclaimer and when.

Different teams are likely a pointer to be subject the original.  For example:

      Although we tried to different legal restraints
requiring or limiting disclosure, especially if they work carefully translate the original
      document from German into English, we can not be certain
      that both documents express the same thoughts in different
jurisdictions. the same
      level of detail and correctness.  In addition, they may have reporting requirements
imposed by their sponsoring organization.  Each team's template should
specify any such restraints, all cases, where there
      is a difference between both to clarify users' expectations and to
inform other teams.

Conflicts versions, the German version
      will prevail.

   The use of interest, particularly in commercial matters, may also
restrain disclosure and protection by a team; this document does not recommend on
how such conflicts disclaimers is affected by local laws
   and regulations, of which each SIRT should be addressed.

'Disclosure' includes (but is maybe not limited to):

   - Reporting incidents within aware. If in doubt
   the constituency SIRT should check the disclaimer with a lawyer.

Appendix A: Glossary of Terms

   This glossary defines terms used in describing security incidents and
   Security Incident Response Teams.  Only a limited list is included.
   For more definitions please refer to other teams. By
     this, site related information might become public knowledge,
     accessible sources, for everybody, especially the press.

   - Handling incidents occurring within example to
   the constituency, but
     reported from outside it.

   - Reporting observations from within Internet User's Glossary [RFC 1983].

Expectations for Security Incident Response                 28 April 97

   Constituency:
      Implicit in the constituency indicating
     suspected or confirmed incidents outside it.

   - Acting on reports purpose of incidents occurring outside a Security Incident Response Team is
      the existence of a constituency.

   - Passing information about vulnerabilities to vendors, to Partner
     SIRTs  This is the group of users,
      sites, networks or directly organizations served by the team.  The team
      must be recognized by its constituency in order to affected sites lying within 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 outside network security.

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

       - Feed-back to parties reporting incidents or vulnerabilities. Loss of confidentiality of information.
       - The provision Compromise of contact information relating to members integrity of the
     constituency, members information.
       - Denial of other constituencies, other SIRTs service.
       - Misuse of service, systems or
     law-enforcement agencies.

An explicit policy concerning disclosure information.
       - Damage to systems.

      These are very general categories.  For instance the Press 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 helpful,
particularly in clarifying regarded as
      Incidents.

      Within the expectations definition of a SIRT's constituency.
The press policy will have to clarify an incident the same topics as above more
specifically, as word 'compromised' is
      used.  Sometimes an administrator may only 'suspect' an incident.
      During the constituency will usually response it must be very sensitive

Expectations for established whether or not an
      incident has really occurred.

   Security Incident Response                 26 March 97

towards press contacts.

The reporting and disclosure policy should make clear who will be the
recipients Team:
      Based on two of a SIRT's report in each circumstance.  It should also
note whether the team will expect to deal through another definitions given above, a SIRT
or directly with is a member of another constituency over matters directly
involving that member.

A team will normally collect statistics.  If such information are
distributed, the template's reporting and disclosure policy should
say so,
      that coordinates and should list methods supports the response to obtain such statistics.

3.4.4 Communication and Authentication

Methods of secure and verifiable communication should be established.
This is necessary for communication between SIRTs and between security incidents
      that involve sites within a SIRT
and its constituents.  The template should include public keys or
pointers defined constituency.

      In order to them, including key fingerprints, together with guidelines
on how be considered a SIRT, a team must:

       - Provide a (secure) channel for receiving reports about
         suspected incidents.
       - Provide assistance to use this members of its constituency in
         handling these incidents.
       - Disseminate incident-related information to check authenticity its
         constituency and how to deal
with corrupted information (for example where other involved parties.

      Note that we are not referring here to report this fact to).

At the moment it police or other law
      enforcement bodies which may investigate computer-related crime.
      SIRT members, indeed, need not have any powers beyond
      those of ordinary citizens.

Expectations for Security Incident Response                 28 April 97

   Vendor:
      A 'vendor' is recommended any entity that every SIRT has - if possible - as
a minimum, a PGP key available.  Teams may also make other mechanisms
available (for example PEM, MOSS, S/MIME), according to its needs produces networking or computing
      technology, and is responsible for the needs technical content of its constituents.    Note however, that SIRTs and users
should be sensitive to local laws
      technology.  Examples of 'technology' include hardware (desktop
      computers, routers, switches, etc.), and regulations.  Some countries do software (operating
      systems, mail forwarding systems, etc.).

      Note that the supplier of a technology is not allow strong encryption or enforce specific policies on necessarily the use
      'vendor' of
encryption that technology.  In addition  As an example, an Internet Service
      Provider (ISP) might supply routers to encrypting sensitive information
whenever possible, correspondence should include digitally signatures.
(Please note, that in most countries, each of its customers, but
      the 'vendor' is the protection manufacturer, since the manufacturer, rather
      than the ISP, is the entity responsible for the technical content
      of authenticity
by using digital signatures the router.

   Vulnerability:
      A 'vulnerability' is not affected by existing encryption
regulations.)

For communication via telephone or facsimile a SIRT may keep secret
authentication data for parties with whom they may deal, such as an
agreed password or phrase.

3.4.5 Point characteristic of Customer Contacts

More detailed contact information might be provided.  This might
include different contacts for different services or might be a list piece of online information services.  If specific procedures for access technology
      which can be exploited to
some services exist (like addresses for mailing list requests) these
should 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 explained here.

Expectations for a vulnerability.

Appendix B: Related Material

   Important issues in responding to security incidents on a site level
   are contained in [RFC 1244], the Site Security Incident Response                 26 March 97

3.5 Services

Services provided Handbook, produced by each SIRT can
   the Site Security Handbook Working Group (SSH).  This document will
   be differentiated updated by whether they
relate to the main task, which is incident response, or are provided
in addition (optional in regard SSH working group and will give recommendations
   for local policies and procedures, mainly related to the definition avoidance
   of a SIRT).

Incident response, which usually includes: security incidents.

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

   - Verification                  Help with ftp://ftp.cert.dfn.de/pub/docs/csir/
     Please refer to file 01-README for further information about
     the verification content of
                                   incidents, as well this directory.

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

   - Technical Assistance ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/
     reports/R-92-01
     This may include analysis of
                                   compromised systems.

   - Eradication                   Elimination report contains the Operational Framework of CERT-NL, the effects
     SIRT of a
                                   security incident.

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

   - Notification of other involved parties

Additional or optional services, which might include: Netherlands).

   - Information provision         This might include an archive For readers interested in the operation of
                                   known vulnerabilities, patches or
                                   resolutions FIRST (Forum of past problems.
   - Security Tools

   - Education and training

   - Product evaluation

   - Site security auditing and consulting

3.6
     Incident Reporting Forms

The use of reporting forms makes it simplier for both sides, users and
teams, to deal with incidents.  The constituent may prepare answers to
various important questions before he or she actually contacts the team Response and therefore come well prepared.  The team gets all the necessary Security Teams) more information at once with is
     collected in Appendix C.

   - http://hightop.nrl.navy.mil/news/incident.html
     This document leads to the first report and can proceed efficiently. NRL Incident Response Manual.

Expectations for Security Incident Response                 26 March                 28 April 97

Depending on the objectives and services of a single SIRT, multiple
forms may be used, for example a reporting form for a new vulnerability
will be very different for the form used for reporting incidents.

It is most efficient to provide forms through the online information
services

   - http://www.cert.dfn.de/eng/team/kpk/certbib.html
     This document contains an annotated bibliography of available
     material, documents and files about the team.  The exact pointers to them should be given in
the document, together operation of SIRTs
     with statements about appropriate use and
guidelines, for when and how links to use the forms.  If separate e-mail
addresses are supported for form based reporting, they should be
listed here again.

One example for such form is many of the referenced items.

   - ftp://info.cert.org/incident_reporting_form
     This Incident Reporting Form is provided by the CERT
     Coordination Center:

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

3.7 Disclaimers

Although Center to gather incident information and to avoid
     additional delays caused by the document does not constitute a contract, liability might
conceivably result need to request more detailed
     information from its descriptions the reporting site.

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

Appendix C: Known Security Incident Response Teams

   Today, there are many different SIRTs but no single source lists
   every team. Most of a disclaimer at the end major and long established teams (the first
   SIRT was founded in 1988) are nowadays members of FIRST, the template is therefore
recommended
   worldwide Forum of Incident Response and should warn Security Teams.  At the user
   time of writing, more than 55 teams are members (1 in Australia, 13
   in Europe, all others in North America).  Information about possible limitations.

It should FIRST
   can be noted that some forms found:

   - http://www.first.org/

   The actual list of reporting or disclosure relating
to specific incidents or vulnerabilities can also imply liability, 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 SIRTs should consider 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 inclusion 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 disclaimers in such material.

In situations where the original version European teams, regardless of whether they are members
   of FIRST or not, are listed by countries on a document must be
translated into another language, page maintained by
   the translation should carry a
disclaimer and a pointer German SIRT:

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

   To learn about existing teams suitable to the original.  For example:

     Although we tried one's needs it is

Expectations for Security Incident Response                 28 April 97

   often helpful to carefully translate the original
     document from German into English, we can not be certain
     that both documents express ask either known teams or an Internet Service
   Provider for the same thoughts "right" contact.

Appendix D: Outline for SIRT Template

   This outline summarizes in point form the same
     level of detail issues addressed in this
   document, and correctness.  In all cases, where there is the recommended template for a difference between both versions, SIRT description
   document.  Its structure is designed to facilitate the German version communication
   of a SIRT's policies, procedures, and other relevant information to
   its constituency and to outside organizations such as other SIRTs.
   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 binding version.

The use 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 protection by disclaimers is effected by local laws Level of Support
      4.2  Co-operation, Interaction and
regulations.  Therefore each SIRT should be sensitive Disclosure of Information
      4.3  Communication and if in doubt
should check the disclaimer with a lawyer. Authentication

      5.   Services
      5.1  Incident Response
      5.2  Proactive Activities

      6.   Incident Reporting Forms

      7.   Disclaimers

Expectations for Security Incident Response                 26 March                 28 April 97

4

Appendix A: Glossary of Terms

This glossary defines terms used in describing security incidents and
Security Incident Response Teams.  Only E: Example - 'filled-in' Template for a limited list SIRT

   Below is included.
For more definitions please refer to other sources, for an example to the
[RFC 1983].

Constituency:
     Implicit in the purpose of a Security Incident Response Team is
     the existence of filled-in template for a constituency. fictitious SIRT
   called XYZ-SIRT.  This text is for example purposes only, and does
   not constitute endorsement by the working group of users,
     sites, networks or organizations served by the team.  The team
     must be recognized by its constituency IETF of any
   particular set of procedures or policies.  While SIRTs are welcome
   to be effective.

Security Incident:
     For the purpose use any or all of this document this term text if they wish, such use is synonym to Computer
     Security Incident: Any adverse event which compromises some aspect of computer course
   not mandatory, or network security.

     The definition even appropriate in most cases.

SIRT Description for XYZ-CERT
-----------------------------

   1. About this document

   1.1 Date of an incident may vary between organizations, but 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
        <xyz-cert-info@xyz-univ.ca>.  Subscription requests for this
        list should be sent to the Majordomo at least
        <xyz-cert-info-request@xyz-univ.ca>; 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 body of systems.

     These are very general categories.  For instance the replacement message
        should consist of the word "subscribe".  Send the word "help"
        instead if you don't know how to use a system utility program by a Trojan Horse Majordomo list manager.
        This mailing list is an example of
     'compromise moderated.

   1.3 Locations where this Document May Be Found

        The current version of integrity,' and a successful password attack this SIRT description document is an
     example of 'loss of confidentiality.'  Attacks, even if they
     failed because
        available from the XYZ-CERT WWW site; its URL is
          http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.txt
        Une version francaise de ce document est igalement disponible:
          http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.txt
        Please make sure you are using the latest version.

   1.4 Authenticating this Document

        Both the English and French versions of proper protection, might be regarded as an
     Incident.

     Within this document have
        been signed with the definition XYZ-CERT's PGP key.  The signatures are
        also on our Web site, under:
          http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.asc
          http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.asc

   2. Contact Information

   2.1 Name of an incident the word 'compromised' is
     used.  Sometimes an administrator may only 'suspect' an incident.
     During Team

        "XYZ-CERT": the response it must be established whether or not an
     incident really occurred. XYZ University Computer Emergency Response
        Team.

Expectations for Security Incident Response Team:
     Based                 28 April 97

   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

        <xyz-cert@xyz-univ.ca>  This is a mail alias that relays mail
        to the human(s) on two of duty for the definitions given above, XYZ-CERT.

   2.8 Public Keys and Other Encryption Information

        The XYZ-CERT has a SIRT PGP key, whose KeyID is a team
     that coordinates 12345678 and supports
        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 response to security incidents
     that involve sites within usual large
        public keyservers.

	Because PGP is still a defined constituency.

Expectations for Security Incident Response                 26 March 97

     In order relatively new technology at XYZ
	University, this key still has relatively few signatures;
	efforts are underway to be considered a SIRT, a team must:

       - Provide a (secure) channel for receiving reports about
         suspected incidents.
       - Provide assistance increase the number of links to members this
	key in the PGP "web of its constituency trust".  In the meantime, since most
	fellow universities in
         handling these incidents.
       - Disseminate incident-related information 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
         constituency
	fingerprint 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.
     SIRT members, indeed, should not need of her own key to have any powers beyond those people who know
	her, by telephone or in person.

   2.9 Team Members

        Zoe Doe of ordinary citizens.

Vendor:
     A 'vendor' Computing Services is any entity that produces networking or computing
     technology, the XYZ-CERT coordinator.
        Backup coordinators and is responsible other team members, along with their

Expectations for the technical content of that
     technology.  Examples Security Incident Response                 28 April 97

        areas of 'technology' include hardware (desktop
     computers, routers, switches, etc.), expertise and software (operating
     systems, mail forwarding systems, etc.).

     Note that the supplier of a technology is not necessarily contact information, are listed in the
     'vendor' of that technology.  As an example, an Internet Services
     Provider (ISP) might supply routers
        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 each
	various recommended security resources, can be found at
	  http://www.xyz-univ.ca/xyz-cert/index.html

   2.11 Points of its customers, but Customer Contact

        The preferred method for contacting the 'vendor' XYZ-CERT is via
        e-mail at <xyz-cert@xyz-univ.ca>; e-mail sent to this address
        will "biff" the manufacturer, being the entity responsible for human, or be automatically
        forwarded to the technical content of 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 router, rather 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 ISP.

Vulnerability:
     A 'vulnerability' is a characteristic form
        mentioned in section 6.

   3. Charter

   3.1 Mission Statement

        The purpose of a piece the XYZ-CERT is, first, to assist members of technology
     which can be exploited XYZ
        University community in implementing proactive measures to perpetrate a
        reduce the risks of computer security incident.  For
     example, if a program unintentionally allowed ordinary users incidents, and second, to
     execute arbitrary operating system commands in privileged mode,
     this "feature" would be a vulnerability.

5 Appendix B: Related Material

Important issues
        assist XYZ community in responding to security such incidents on a site level
are contained in [RFC 1244], 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 when they
        occur.

   3.2 Constituency

        The XYZ-CERT's constituency is the avoidance of
security incidents.

Other documents of interest for XYZ University community,
        as defined in the discussion of SIRTs and their
tasks are context of the "XYZ University Policy on
        Computing Facilities".  This policy is available by anonymous FTP. A collection can at
          http://www-compserv.xyz-univ.ca/policies/pcf.html

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

Expectations for Security Incident Response                 26 March                 28 April 97

   - 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
     SIRT of SURFnet (network provider in

   3.3 Sponsorship and/or Affiliation

        The XYZ-CERT is currently completing the Netherlands).

   - For readers interested application process
        for membership in FIRST, the operation of FIRST (Forum Forum of Incident Response and
        Security Teams) more Teams.  More information about FIRST 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
        from
          http://www.first.org/

   3.4 Authority

	The XYZ-CERT operates under the auspices of, and files about with authority
	delegated by, the operation Department of SIRTs
     with links to many Computing Services of XYZ
	University.  For further information on the referenced.

   - ftp://info.cert.org/incident_reporting_form
     This Incident Reporting Form is provided by mandate and
        authority of the CERT
     Coordination Center Department of Computing Services, please
        refer to gather incident information 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
     additional delays by requesting the sites for more detailed
     information.

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

6 Appendix C: Known Security Incident Response Teams

Today, there are many different SIRTs but no single source list every
team. Most 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 major and long established teams (the first SIRT was
founded in 1988) XYZ-CERT are nowadays member members of FIRST, the worldwide Forum
        CCSA (Committee of
Incident Response Computer Systems Administrators), and Security Teams.  Actually more than 55 teams are
members (1 in Australia, 13 in Europe, have
        all others from America).
Information about FIRST can be found:

   - http://www.first.org/

Expectations for Security Incident Response                 26 March 97

The actual list of members is available also, with the relevant contact
information powers and some additional information provided responsibilities assigned to Systems
        Administrators by the single
teams:

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

For SIRTs which want to become Policy on Computing Facilities, or are
        members of this forum (please note, that
a team needs a sponsor - a team already full member University management.

        Members 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 XYZ University community who wish to become member of FIRST.

Many of appeal the European teams, regardless if they are members
        actions of FIRST or
not, are listed by countries on a page maintained by the German SIRT:

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

To learn about existing teams and maybe more suitable teams for one's
need it is always a good approach, to ask either existing teams or an
Internet Service Provider for the "right" contact.

Expectations for Security Incident Response                 26 March 97

7 Appendix D: Outline for SIRT Template

This outline summarizes XYZ-CERT should contact the issues addressed in Assistant Director
        (Technical Services), Computing Services.  If this document in a logical
structure suitable recourse is
        not satisfactory, the matter may be referred to communicate the policies and procedures for Director
        of Computing Services (in the
interaction case of perceived
        problems with SIRTs easily existing policy), or to the team's constituency.  A 'filled-in'
example the XYZ University
        Office of this template is given as Appendix E.

    1.   Contact Information
    1.1  Name Rights and Responsibilities (in the case of perceived
        errors in the Team
    1.2  Address
    1.3  Time Zone
    1.4  Telephone Number
    1.5  Facsimile Number
    1.6  Other Telecommunication
    1.7  Electronic Mail Address
    1.8  Public Keys and Encryption Information
    1.9  Team Members
    1.10 Other Information

    2.   Document Updates
    2.1  Date application of Last Update
    2.2  Distribution List for Notifications
    2.3  Locations where this Document May Be Found

    3.   Charter
    3.1  Mission Statement
    3.2  Constituency
    3.3  Sponsors and/or Affiliation
    3.4  Authority existing policy).

   4. Policies

   4.1 Types of Incidents and Level of Support
    4.2  Cooperation and Interaction with Other Entities
    4.3  Disclosure of Information
    4.4  Communication and Authentication
    4.5  Points of Customer Contacts

    5.   Services
    5.1  Incident Response
    5.2  Proactive Activities

    6.   Incident Reporting Forms

    7.   Disclaimers

Expectations for Security Incident Response                 26 March 97

8 Appendix E: Example - 'filled-in' Template for a SIRT

Below

        The XYZ-CERT is an example, a filled-in template for a SIRT called XYZ authorized to avoid any confusion with existing teams. By no means does this
example imply, that a new founded SIRT should reuse this text.
It is for example purposes only.

 SIRT Template for XYZ-SIRT
 --------------------------

 Note: no digital signature is currently available for this SIRT
 Template.  We'll put one up as soon as the technology is adopted
 by address all types of computer
        security incidents which occur, or threaten to occur, at
        XYZ Enterprises.

 1. Contact Information

 1.1 Name University.

        The level of support given by XYZ-CERT will vary depending on
        the Team
        "XYZ-SIRT": the XYZ Computer Emergency Response Team.

 1.2 Address
        XYZ SIRT
        XYZ Enterprises
        Private Bag 12-345
        MyTown
        MyCountry

 1.3 Time Zone
        MyCountry/Eastern (GMT-0500, type and GMT-0400 from April to October)

 1.4 Telephone Number
        +1 234 567 7890  (ask for severity of the incident or issue, the type of
        constituent, the size of the XYZ-SIRT)

 1.5 Facsimile Number
        +1 234 567 7654  (this is *not* a secure fax)

 1.6 Other Telecommunication
        None available.

 1.7 Electronic Mail Address
        <xyz-sirt@sirt.xyz.org>

 1.8 Public Keys user community affected, and Other Encryption Information
        Encryption is not currently available, but we plan to install
        PGP as soon as possible.  Our PGP public key the
        XYZ-CERT's resources at the time, though in all cases some
        response will be made within one working day.  Resources will appear here
        as soon as it is available.

Expectations for Security Incident Response                 26 March                 28 April 97

 1.9 Team Members
        Jane Doe of Computing Services is the XYZ-SIRT
        coordinator.  Other team members will

        be assigned according to the following priorities, listed here once
        their participation is confirmed.

 2. Document Updates

 2.1 Date 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 Last Update
        Please see the bottom backbone network infrastructure.
          - Root or system-level attacks on any large public service
            machine, either multi-user or dedicated-purpose.
          - Compromise of this Web page restricted confidential service accounts or
            software installations, in particular those used for this information.

 2.2 Distribution List MIS
            applications containing confidential data, or those used
            for Notifications
        Notifications system administration.
          - Denial of service attacks on any of updates are submitted to our mailing list
        <xyz-sirt-info@sirt.xyz.org>. (Subscription request should
        go to <xyz-sirt-info-request@sirt.xyz.org>.)

 2.3 Locations where this Document May Be Found
        This template is available from the XYZ SIRT WWW
        site; its URL is
           http://www.sirt.xyz.org/op_frame.html
        The template will be signed with above three items.
          - Any of the XYZ-SIRT's PGP
        key.

 3. Charter

 3.1 Mission Statement
        The purpose 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, harrassment, 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.
          - Denial of the XYZ-SIRT is, first, to assist members service on individual user accounts, e.g.
            mailbombing.

        Types of
        XYZ community in implementing proactive measures incidents other than those mentioned above will be
        prioritized according to reduce
        the risks of computer security incidents, their apparent severity and second, to
        assist XYZ community in responding extent.

	Note that no direct support will be given to such incidents when end users; they occur.

 3.2 Constituency
        The XYZ-SIRT's constituency is the XYZ SIRT community,
        as defined in the context of the "XYZ Policy on Computing
        Facilities".

 3.3 Sponsors and/or Affiliation
        None.

 3.4 Authority
	are expected to contact their system administrator, network
	administrator, or department head for assistance.  The XYZ-SIRT operates under XYZ-CERT
	will support the auspices of, and with
        authority delegated by, latter people.

	While the Department of Computing Services
        of XYZ Enterprises.  The Department XYZ-CERT understands that there exists great
	variation in turn receives its
        authority from the formal ruling bodies level of XYZ, as
        set out in the "Policy on Computing Facilities".  The XYZ-SIRT

Expectations for Security Incident Response                 26 March 97

        has no direct authority over systems system administrator expertise at XYZ Enterprises
        at large.  However, it benefits from
	University, and while the direct authority of
        Computing Services with respect XYZ-CERT will endeavor to systems managed by this
        Department.  Also, because Computing Services manages the
        XYZ Enterprises Network, present
	information and is responsible for connectivity
        to it, the Department has indirect authority over systems
        in other departments, inasmuch as the Department can order
        such systems assistance at a level appropriate to be disconnected from each
	person, the network should
        circumstances warrant it.

        The XYZ-SIRT expects to work cooperatively with XYZ-CERT cannot train system administrators on the
	fly, and users at XYZ, and, insofar as
        possible, it cannot perform system maintenance on their behalf.
	In most cases, the XYZ-CERT will provide pointers to avoid authoritarian relationships.  However,
        should circumstances warrant it, the XYZ-SIRT will appeal
	information needed to
        Computing Services implement appropriate measures.

        The XYZ-CERT is committed to exert its authority, direct or indirect,
        as necessary.

 4. Policies

 4.1 Types keeping the XYZ University system
        administration community informed of Incidents potential
        vulnerabilities, and Level where possible, will inform this
        community of Support

        The XYZ-SIRT is authorized to address all types such vulnerabilities before they are actively
        exploited.

Expectations for Security Incident Response                 28 April 97

   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 computer
        security incidents which occur, or risk occurring, at are also outlined in
	the XYZ Enterprises.

        The level University Policy on Computing Facilities, and all of support given by XYZ-SIRT
	which will vary depending on be respected, the type XYZ-CERT acknowledges its
	indebtedness to, and severity declares its intention to contribute to,
	the spirit of cooperation that created the incident or issue, Internet.
	Therefore, while appropriate measures will be taken to protect
	the type identity of
        consituent, the size members of our constituency and members of
	neighbouring sites where necessary, the user community affected, 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
        XYZ-SIRT's resources at 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 time.

        No direct support XYZ-CERT.  They may or
        may not have legal rights to confidentiality; such rights will
        of course be given to end users; respected where they are
        expected to contact their system administrator, network
        administrator, exist.

        Information being considered for release will be classified as
        follows:

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

	    Private user information will support the latter people.

        While the XYZ-SIRT understands that there exists great
        variation be not be released in
	    identifiable form outside the level XYZ-CERT, except as provided
	    for below.  If the identity of system administrator expertise at
        XYZ, and while the XYZ-SIRT will endeavor user is disguised, then
	    the information can be released freely (for example to present 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 assistance at a level appropriate in particular identifying
            information, will not be released to
        each person, the XYZ-SIRT cannot train system administrators,
        and public (unless it cannot perform
            becomes a  matter of public record, for example because
            criminal charges have been laid), it will be exchanged
            freely with system maintenance on their behalf.
        In most cases, the XYZ-SIRT administrators and SIRTs tracking an
            incident.

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

            It will provide pointers to not be released without the
        information needed to implement appropriate measures. permission of the site
            in question, except as provided for below.

Expectations for Security Incident Response                 26 March                 28 April 97

 4.2 Cooperation and Interaction with Other Entities

          - Other sites:
            The XYZ-SIRT will cooperate with other SIRTs (security
            incident response teams) and with system administrators at
            other sites, to the extent that their bona fide can be
            verified.  Should provincial Vulnerability information is technical information about
            vulnerabilities or national SIRTs be
            constituted, XYZ-SIRT attacks, including fixes and
            workarounds.

            Vulnerability information will explore the possibility of peer
            relationships with them.  The possibility of peer
            relationships with close neighbors be released freely, though
            every effort will also be explored;
            unofficial cooperative climates already exist between XYZ
            and several nearby universities and large corporations.
            While there are no legal requirements made to inform the relevant vendor
            before the general public is informed.

          - Embarrassing information includes the statement that XYZ-SIRT provide
            any 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 to any body outside XYZ (aside from
            law enforcement agencies), XYZ-SIRT will provide such
            information when not be released without the good
            permission of the community justifies it.
            However, unless identifying site or users in question, except as
            provided for below.

          - Statistical information is needed 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 track
            an incident in progress, such reach system
            administrators and SIRTs.

            Contact information will be stripped
            from released freely, except where
            the report (unless contact person or entity has requested that this not
            be the affected department gives its
            permission case, or where XYZ-CERT has reason to believe that
            the real dissemination of this information would not be
            appreciated.

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

	- Vendors:
            The XYZ-SIRT wishes to encourage vendors Because of all kinds the nature of
            networking and computer equipment, software, their responsibilities and services
	  consequent expectations of confidentiality, members of XYZ
	  University management are entitled to improve receive whatever
	  information is necessary to facilitate the security handling of
	  computer security incidents which occur in their products.  In aid
	  jurisdictions.

	- Members of
            this, a vulnerability discovered in such the Office of Rights and Responsibilities are
	  entitled to receive whatever information they request
	  concerning a product will be
            reported 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 vendor, along with all technical details
            needed to identify and fix assistance in
	  an investigation has been enlisted, or when the problem.  Identifying
            details 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,

Expectations for Security Incident Response                 28 April 97

          trusted with confidential information.  However, unless such
          people are also members of XYZ-CERT, they will not be given only
          that confidential information which they must have in order
          to the vendor without the
            permission of the affected parties.
        - Law enforcement:
            XYZ has its assist with an investigation, or in order to secure their
          own Security Department.  ( I NEED TO LOOK UP
            THE RELATIONSHIP BETWEEN COMPUTING SERVICES, XYZ
            SECURITY, AND OUTSIDE POLICE FORCES. )  Informal working
            relationships already exist between some system
            administrators systems.

        - Users at XYZ and University are entitled to information which
          pertains to the local police; interest
            has been expressed by all parties in formalizing these
            relationships.  Any progress
            made in that area will be reflected in security of their own computer accounts,
          even if this section.
            In the meantime, authorized means revealing "intruder information", or
          "embarrasssing information" about another user.  For
          example, if account aaaa is cracked and unauthorized users of the
            XYZ Computing Facilities should be aware intruder attacks
          account bbbb, user bbbb is entitled to know that the
            XYZ-SIRT will cooperate fully with law enforcement
            agencies in detecting, reporting, documenting, aaaa was
          cracked, and
            prosecuting violations of the law; users concerned about
            confidentiality are referred to how the XYZ "Policy attack on
            Computing Facilities".

Expectations for Security Incident Response                 26 March 97

        - The Press:
            The XYZ-SIRT will not interact directly with the Press.
            If necessary, bbbb account was
          executed.  User bbbb is also entitled, if she or he requests
          it, to information will be provided about account aaaa which might enable
          bbbb to investigate the
            XYZ Public Relations Department, and attack.  For example, if bbbb was
          attacked by someone remotely connected to aaaa, bbbb should
          be told the
            Customer Relations group provenance of the Computing Services
            Department.  All queries will connections to aaaa, even
          though this information would ordinarily be referred considered
          private to these two
            bodies.
        - The aaaa.  Users at XYZ SIRT community:
            Details of incidents may University are entitled to be released
          notified if their account is believed to Computing Services
            management, have been
          compromised.

	- The XYZ management, or the Computer
            Resources Committee; these bodies University community will be charged with
            maintaining receive no restricted
	  information, except where the confidentiality of affected parties have given
	  permission for the information.  General
            report of incidents, summaries of multiple incidents, and
            statistics information to be disseminated.
	  Statistical information may be made available to the general
	  XYZ
            community, with identifying information stripped (except
            where permission has been obtained from the affected
            parties). community.  There is no obligation on the part of the
            XYZ-SIRT
	  XYZ-CERT to report incidents to the community, though it may
	  choose to do so; in particular, it is likely that the
            XYZ-SIRT
	  XYZ-CERT will inform all affected parties of the ways in
	  which they were affected. affected, or will encourage the affected site
	  to do so.

	- The public at large: large will receive no restricted information.
	  In general, fact, no particular efforts effort will be made to communicate
	  with the public at large, though the XYZ-SIRT 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: community will be treated the same way
	  the general public is treated.  While members of XYZ-SIRT 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-SIRT
	  XYZ-CERT experience will be disguised to avoid identifying
	  the affected parties.

        In

Expectations for Security Incident Response                 28 April 97

	- The press will also be considered as part of the paragraphs above, general
	  public.  The XYZ-CERT will not interact directly with the "affected parties" refers
	  Press concerning computer security incidents, except to point
	  them toward information already released to the
        legitimate owners, operators, general
	  public.  If necessary, information will be provided to the
	  XYZ University Public Relations Department, and users to the
	  Customer Relations group of the relevant
        computing facilities.  It Computing Services
	  Department.  All incident-related queries will be referred to
	  these two bodies.  The above does not refer to unauthorized
        users, including otherwise authorized users making
        unauthorized usage 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 facility; such intruders may have no
        expectation
	  public service to the community.

	- Other sites and SIRTs, when they are partners in the
	  investigation of confidentiality from a computer security incident, will in some
	  cases be trusted with confidential information.  This will
	  happen only if the XYZ-SIRT.  They may or
        may not have legal rights to confidentiality; such rights foreign site's bona fide can be verified,
	  and the information transmitted will
        of course be respected where they exist.

 4.3 Disclosure 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 Information

        The following types
	  sites well known to XYZ-CERT (for example, several other
	  Quebec universities have informal but well-established
	  working relationships with XYZ University in such mattters).

	  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 stored
	  considered highly sensitive, and handled
        by XYZ-SIRT:
             - Contact info for constituents.
             - Technical info about can be transmitted to a vulnerability.
             - Technical info about XYZ facilities.
             - Information about incidents:
                 - Statistical summaries
                 - Admission of incident of certain type
                 - Admission of root compromise
                 - Admission of packet sniffing attack
                 - Admission
	  foreign site without excessive precautions.  "Intruder
          information" will be transmitted freely to other system
          administrators and SIRTs.  "Embarrassing information" can be
          transmitted when there is reasonable assurance that user accounts were compromised
                 - Description of incident it will
          remain confidential, and when it is necessary to resolve an
          incident.

	- Identity Vendors will be considered as foreign SIRTs for most intents
	  and purposes.  The XYZ-CERT wishes to encourage vendors of affected systems
                     - Identity
	  all kinds of affected people
                     - Identity networking and computer equipment, software, and
	  services to improve the security of perpetrator

          Recipients their products.  In aid
	  of information are - depending on the need to
          know - are as follows:
             - XYZ management
             - Computing Services management
             - Affected sysadmin at XYZ
             - Affected sysadmin (or SIRT) at another site

Expectations for Security Incident Response                 26 March 97

             - Affected user(s) at XYZ
             - All sysadmins potentially concerned (potentially
               vulnerable) at XYZ
             - All sysadmins at XYZ
             - All users potentially concerned at XYZ
               (information this, a vulnerability discovered in such a product will leak be
	  reported to general public)
             - All users at XYZ (ditto)
             - Computer security community
             - Peer sysadmins its vendor, along with all technical details
	  needed to identify and SIRTs
             - Vendors fix the problem.  Identifying details
	  will not be given to the vendor without the permission of the
	  affected parties.

        - Law enforcement

 4.4 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.

Expectations for Security Incident Response                 28 April 97

   4.3 Communication and Authentication

        In view of the types of information that the XYZ-SIRT 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
        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. 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-SIRT, 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, 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.

 4.5 Points of Customer Contact

        The preferred method for contacting the XYZ-SIRT will be
        e-mail.  If this signatures (PGP in particular is not possible, or not advisable for
        security reasons, the XYZ-SIRT can be reached by telephone
        during regular office hours.

Expectations for Security Incident Response                 26 March 97
        supported).

   5. Services

   5.1 Incident Response

        XYZ-SIRT

        XYZ-CERT will help users and assist system administrators to handle in handling the
        technical and organizational aspects of incidents. By that,  In
        particular, it will provide and facilitate:
             - assistance or advice with respect
        to understand the extend following aspects of incident management:
            - Determining the extent of the incident.
            - Determining the initial cause of the incident
              (vulnerability exploited).
            - Facilitating contact with other sites which may be
              involved.
            - 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.

Expectations for Security Incident Response                 28 April 97

            - Facilitating contact with XYZ University Security and/or
              appropriate law enforcement officials, if necessary.
            - ... Making reports to other SIRTs.
            - Composing announcements to users, if applicable.

        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-SIRT will coordinate XYZ-CERT coordinates and maintain 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. 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.
             - "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.
               machines, and for any other platforms capable of
               running "tripwire".

Expectations for Security Incident Response                 28 April 97

             - 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. 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 own local forms developed yet for reporting incidents
        to XYZ-SIRT. XYZ-CERT. If possible, please make us use of the Incident
        Reporting Form of the CERT Coordination Center (Pittsburgh,
        PA).  The actual version is available from:
           ftp://info.cert.org/incident_reporting_form

   7. Disclaimers

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

4 Acknowlegements

   The editors gratefully acknowledge the contributed material and
   editorial scrutiny of Anne Bennett.

Expectations for Security Incident Response                 26 March                 28 April 97

9

5 References

   [RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. -
      July 23, 1991. - 101 pages. - FYI 8.

   [RFC 1983] G. Malkin / Internet Users' Glossary. -
      August 16, 1996. - 62 pages. - FYI 18.

10

6 Security Considerations

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

   Nonetheless, it is vital that the SIRTs 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.

11

7 Authors' Addresses

    Nevil Brownlee
    ITSS Technology Development
    The University of Auckland

    Phone: +64 9 373 7599 x8941
    E-mail: n.brownlee@auckland.ac.nz

    Erik Guttman
    Sun Microsystems, Inc.
    Gaisbergstr. 6
    69115 Heidelberg Germany

    Phone: +49 6221 601649
    E-Mail: eguttman@eng.sun.com

This document expires September 26, October 28, 1997.