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

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

                 <draft-ietf-grip-framework-irt-04.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
Internet Accounting
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

This

The purpose of this document is intended to facilitate express the setting of general Internet
community's expectations
regarding the operation of Security Incicident Incident Response Teams (SIRTs). Teams. It describes the various important topics in
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 form general set of a 'template,'
through topics and issues which every SIRT should describe itself
are of concern and its functions. interest to constituent communities.

SIRT clients constituents have a legitimate need and right to fully understand
the policies and procedures of their "their" Security Incident Response Team.  A
SIRT's template supplies details for the various important topics
One way to support this understanding is to supply detailed information
which
clients must consider when selecting 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
provided.

Expectations for Security Incident Response                 26 March 97

Table of Contents

1 Introduction                                                        3
   1.1 Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2                                                       1

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

 2 Description Template:  Security Incident Response Team              7 ............................6

3 Purpose of the Template                                             8 Information, Policies and Procedures...............................7
  3.1 Other Related Material . . . . . . . . . . . . . . . . . . . .  9

 4 The Security Incident Response Team Template                       10
   4.1 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.1Date of last update . . . . . . . . . . . . . . . . . . . . 10
     4.1.2Distribution list for Template Contact Information ...........................................8
  3.2 Document Updates  . . . . . . . . . . 10
   4.2 ..............................................9
  3.3 Charter  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.1Mission Statement . . . . . . . . . . . . . . . . . . . . . 11
     4.2.2Constituency  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.3Sponsoring organization .......................................................9
      3.3.1 Mission Statement.......................................10
      3.3.2 Constituency............................................10
      3.3.3 Sponsoring Organization / affiliation . . . . . . . . . . . 12
     4.2.4Authority . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.3 Affiliation...................10
      3.3.4 Authority...............................................11
  3.4 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.3.1Types .....................................................11
      3.4.1 Types of incidents Incidents and level Level of support . . . . . . . . . . 12
     4.3.2Co-operation Support.................11
      3.4.2 Co-operation and interaction Interaction with other organizations . . . 12
     4.3.3Reporting Organizations...12
      3.4.3 Reporting and Disclosure  . . . . . . . . . . . . . . . . . 13
     4.3.4Communication Disclosure................................13
      3.4.4 Communication and authentication  . . . . . . . . . . . . . 14
   4.4 Authentication........................14
      3.4.5 Point of Customer Contacts..............................14
  3.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.5 .....................................................15
  3.6 Incident reporting Reporting Forms . . . . . . . . . . . . . . . . . . . 15
   4.6 .....................................15
  3.7 Disclaimers  . . . . . . . . . . . . . . . . . . . . . . . . . 15

 5 Secondary Purposes of this Document                                15

 6 ..................................................16

4 Appendix A: Note on procedure definitions                          16

 7 Glossary of Terms                                     17

5 Appendix B: Related Material                                      18

6 Appendix C: Known Security Incident Response Teams                          17                19

7 Appendix D: Outline for SIRT Template                             21

8 Appendix C: Example:  a E: Example - 'filled-in' template                       17 Template for a SIRT             22

9 References                                                        29

10 Security Considerations                                            25

10 Author's Address                                                   25

1 Introduction

The GRIP Working                                          29

11 Authors' Addresses                                               29

Expectations for Security Incident Response                 26 March 97

1 Introduction

The GRIP Working Group was formed to produce guidelines and
recommendations to facilitate create a document that describes
the consistent handling community's expectations of security
incidents in the Internet community. incident response teams
(SIRTs).  Although it is focused on the
Internet, many of the concepts discussed will also be useful need for other
forms of local- and wide-area networks and internets.

Many computer security incidents orginate outside local community
boundaries and affect other 'outside' sites, and others orignate outside such a document originated in the local community and affect hosts or users within it.  Often,
therefore,
general Internet community, the handling of security incidents will involve multiple
Security Incident Response Teams.  Because expectations expressed should also
closely match those of this characteristic it is
important  for every community to have a good security policy, and to
have a Security Incident Response Team (SIRT) in place to manage
communications across community boundaries in a consistent way. more restricted communities.

In the past there have been misunderstandings regarding expectations of
response teams. what to expect
from SIRTs.  The goal of this document is to provide a framework in
which to set expectations.  By defining such a framework for
presenting the community
can express areas and topics important subjects (related to incident response) that need
are of concern to addressed the community.

Before continuing, it is important to clearly understand what is meant
by any SIRT.

'Consistent handling' implies the term "Security Incident Response Team."  For the purposes of
this document, a SIRT is a team that any 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 or incidents, and to threats of them to "their"
constituency in ways which the
Internet specific community agrees to be in its
general interest.  Every

Since it is vital that each member of a constituent community be
able to understand what is reasonable to expect of their team, A SIRT
needs
should make it clear who belongs to their constituency and define clearly the
services they offer and the level at which
they are offered team offers to clients.  Such definitions will be particularly
important 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 contracts and/or agreements which SIRTs make with their
clients.

The "Expectations order for Security Incident Response" is seen as resting on
them to receive the work services of individual SIRTs and their team.  This requires that the cooperation between them.
team also publish how and where incidents should be reported.

This document therefore recommends details a 'template' through template which every SIRT
should describe itself and its functions.  It further recommends that
templates should will be accessible among teams, used by SIRTs to make possible
communicate this information to their constituents.  The constituents
should certainly expect a fully
effective cooperative response framework for incidents or threats across SIRT to provide the entire domain affected by them.

1.1 Definitions

This section defines terms used services they describe in describing security incidents and
response teams.  For
the purpose completed template.

It must be emphasised that without active participation from users, the
effectiveness of the GRIP documents only a limited
list is really needed. SIRT's services can be greatly diminished.  This should help maintain focus on
is particularly the purpose
of case with reporting.  At a minimum, users need to
know that they should report security incidents, and know how and where
they should report them to.

Many computer security incidents originate outside local community
boundaries and affect inside sites, others originate inside the documents, local
community and prevent a duplication of other definitions affect hosts or -
even worse - a proliferation of competing definitions.

Constituency
------------

Implicit in users on the purpose of a outside.  Often, therefore,

Expectations for Security Incident Response Team is                 26 March 97

the
existence handling of a constituency.  This is security incidents will involve the group cooperation of clients, sites,
networks or organizations served by the team.

Security Incident
-----------------

For
multiple sites and potentially multiple SIRTs.  The coordination of
activities across communities and organization requires that the purpose
parties understand who they are dealing with, and what sort of this document:

    'A policies
they have in place.

Many computer security incident is any event which compromises
    some aspect of computer incidents originate outside local community
boundaries and affect inside sites, others originate inside the local
community and affect hosts or network security.'

The definition users on the outside.  Often, therefore,
the handling of an incident may vary security incidents will involve multiple sites and
potentially multiple SIRTs.  Resolving these incidents will require
cooperation between organizations, but at
least 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 following categories are generally applicable:

 * loss set of confidentiality,
 * compromise 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 terms of integrity,
 * denial what that topic means. For example,
five types of service,
 * misuse,
 * damage.

These policy statements are very general categories.  For instance the replacement listed (representing those policies
of a
system utility program by a Trojan Horse is an example interest to the community), but the content of 'loss any one of
integrity,' and them will
necessarily be specific to a successful password attack is given team.

Chapter two provides an example overview of 'loss three major areas:  The publishing
of
confidentiality.'

Within information by a response team, the definition of an incident the word 'compromised' is used.
Sometimes an administrator may only 'suspect' an incident.  During response
team's relationship to other response teams and the
handling of a call it must be established whether or not an incident
really occurred.

Security Incident Response Team
-------------------------------

Based on two need for secure
communications.  Chapter three describes in detail all the types of
information that the definitions given above:

    'A Security Incident Response Team is a group authorized community needs to
    manage know about their response to security incidents that involve sites within
    its defined constituency.'

In order to be considered a SIRT, a group must:

 * provide a channel team.
These topics are condensed into an outline template for receiving reports about suspected incidents,
 * provide assistance to members ease of its constituency use by
the community, and is found in handling these
   incidents,
 * disseminate incident-related information Appendix D.  This template can be used
by constituents to its constituency elicit information from their SIRT, and to
   other related parties.

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

Vendor
------

A 'vendor' is any entity that produces networking or computing
technology, and measure their team's performance.

It is responsible for the technical content of working group's sincere hope that
technology.  Examples through the clarification
of 'technology' include hardware (desktop
computers, routers, switches, etc.), the topics in this document, understanding between the community
and software (operating systems,
mail forwarding systems, etc.).

Note its SIRTs will be increased.

2 Scope

The interactions between a constituent community and an incident
response team require first that the supplier of a technology is not necessarily community understands the 'vendor'
policies and procedures of that technology.  As an example, an Internet Services Provider (ISP)
might supply routers the response team.  Second, since many
response teams collaborate to each of its customers, but handle incidents, the 'vendor' is the
manufacturer, being community must
also understand the entity responsible relationship between their response team and

Expectations for the technical content Security Incident Response                 26 March 97

other teams.  Finally, many interactions will take advantage of
existing public infrastructures and the router, rather than the ISP.

Vulnerability
-------------

A 'vulnerability' is a characteristic of a piece of technology which can
be exploited community needs to perpetrate a security incident.  For example, if a
program unintentionally allowed ordinary users know how
those communications are going to execute arbitrary
operating system commands in privileged mode, this "feature" would be a
vulnerability.

1.2 protected. Each of these subjects
will be described in more detail in the following three sections.

2.1 Publishing a SIRT Templates

Every SIRT Policies and Procedures

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

A clear statement of the form policies and procedures of a completed template.  The simplest way for a SIRT helps the
constituent understand how best to make
its template widely available is report incidents and what support to publish
expect afterwards.  Will the SIRT assist in resolving the incident?
Will it on its own information
server so that clients provide help in its constituency can easily find it.
Templates published as pages avoiding incidents in the World Wide Web should include future?  Clear
expectations, particularly of the
phrase 'SIRT Template' in their title - this will allow Web search
engines to find them easily.

Whether or not templates are published in a repository, clients - and
potential clients - limitations of a SIRT will need to be able to authenticate a
template (verify that it was indeed published by the SIRT) and check
that it has not been modified (for example services provided
by verifying a digital
signature for it).

To facilitate SIRT, will make interaction between SIRTs, with it would be useful to more efficient and effective.

There are different kinds of response teams. Some that have a
central repository for them.  The GRIP Working Group believe very
broad constituencies (e.g., CERT Coordination Center and the Internet),
others that some have more bounded constituencies (e.g., DFN-CERT, CIAC),
and still others that have very restricted constituencies (e.g.,
commercial response teams, corporate response teams). Regardless of
the existing Internet archive areas could be used for this purpose.
The keeper type of each template repository will be responsibly for verifying response team, the identity of each SIRT lodging a template in constituency supported by it must be
knowledgeable about the repository.

1.3 Relationships between SIRTs

In some cases team's policies and procedures. Therefore, it
is mandatory that response teams publish such information to their
constituency.

As a SIRT may be able provides a service to operate effectively on a this clearly defined constituency,
it should communicate all necessary information about its own. policies
and services in a suitable form.  It is much more likely, however, important to understand that
not all policies and procedures must be publicly available.  For
example, it is not necessary to understand the internal operation of
a SIRT will need team in order to interact with
other SIRTs.  Such interactions could include:

 * Responding it, as when reporting an incident or
receiving guidance on how to requests for advice (e.g. "have you seen this
   problem before?")
 * Reporting analyze or secure one's systems.

In the past, some teams supplied a kind of problems (for onward referal to other SIRTs, to service
   providers Operational Framework,
others provided Frequently Asked Questions (FAQ), while still
others wrote papers for distribution at user conferences or sent
newsletters.

Another efficient way to vendors)
 * Working co-operatively to resolve a security incident

Note that there is a difference between a peering agreement, where communicate the
SIRTs involved agree relevant information to work together and share information, and simple
co-operation, where a SIRT (or any all
concerned, not only constituents but also other client) simply contacts another
SIRT and asks for help teams or advice.  Note also that any client wanting
direct help in tracking an incident must organizations,
would be prepared for each SIRT to provide
sufficient publish its guidelines and procedures on its
own information about the incident to make tracking possible.

In establishing relationships to support such interactions, SIRTs will
need to decide what kinds of agreements can exist between themselves so
as server.  This would allow constituents to share yet safeguard information, whether easily access

Expectations for Security Incident Response                 26 March 97

it, although this relationship can be
disclosed, and if so to whom?

1.4 Establishing Communications between SIRTs

Once two SIRTs have agreed to work together - as outlined above - they
need to establish secure communications channels.  This section outlines
some of does not address the issues involved in this.

When a SIRT (SIRT A) wishes to establish a working relationship with
another SIRT (SIRT B), problem of how a responsible person from SIRT A constituent or
will need find "his" or "her" team.  People within the constituency have to
contact
discover that there is a similarly responsible person at SIRT B. The "at their disposal."  It is foreseen that
completed SIRT B person then
has templates will soon become searchable by modern search
engines.  This will aid in distributing information about the problem:  "how do I know who I'm talking to?" existence
of SIRTs and basic information required to approach them.

It is would be very easy to send forged e-mail, and not hard useful to establish have a
(false) identity by telephone.  PGP and PEM provide effective ways of
securing e-mail, but securing voice communications is much harder.  At
present call-back is probably central repository containing all the only simple authentication method.
completed SIRT templates.  No such repository presently exists.  This may
might change as technologies such as scrambled telephones, or
PGP-phone on in the Internet become available.

PGP relies on a 'web of trust,' built up by having known (and trusted)
people sign PGP keys.  This model could also be used for SIRTs.  To
achieve this each SIRT should publish a list future.

Regardless of the SIRTs they have
peering arrangements (i.e.  working relationships) with, including PGP
public keys for them and source from which the expiry dates of those keys.

2 Description Template:  Security Incident Response Team

The Template information is summarized in the section immediately below, and retrieved,
the
remainder user of the document describes its components.  A 'filled-in'
example of a template must check its authenticity.  It is given as Appendix C.

1. Contact Information
----------------------
 1.1 Name of highly
recommended that such vital documents be protected by digital
signatures.  These will allow user can verify that the Team
 1.2 Address
 1.3 Time Zone
 1.4 Telephone Number
 1.5 Facsimile Number
 1.6 Other Telecommunication (STU-III, secure facsimile...)
 1.7 Electronic Mail Address
 1.8 Public Keys and Other Encryption Information
 1.9 Team Members

2. Template Updates
-------------------
 2.1 Date of Last Update
 2.2 Locations where this Template May Be Found

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

4. Policies
-----------
 4.1 Types of Incidents
 4.2 Level of Support
 4.3 Disclosure of Information
 4.4 Cooperation template
was indeed published by the SIRT and Interaction that it has not been modified
thereafter.  This document assumes the reader has familiarity with Other Entities
 4.5 Communication and Authentication
 4.6 Points of Customer Contact

5. Services
-----------
 5.1 Incident Response
 5.2 Proactive Activities

6. Incident Reporting Forms
---------------------------

7. Disclaimers
--------------

3 Purpose of
the Template

The Template which this proper use of digital signatures to determine whether a document proposes
is expected to be used by authentic.

2.2 Relationships between different SIRTs

In some cases a
response team SIRT may be able to describe what it does, operate effectively on its own
and in the process create
criteria against which close cooperation with its performance can be measured.  The Template
does not attempt to specify a "correct" way for constituency.  But with todays
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 operate, but
does recommend on specific policies interact with other
SIRTs and functions seen sites outside their constituency.

The constituent community should be clear about the nature and
extent of this collaboration, as necessary for
such a team to play a consistent role very sensitive information about
individual constituents may be disclosed in the overall security framework.
It also comments on additional roles a team might process.

Such interactions could include in the ambit asking other teams for advice,
disseminating knowledge of its operations.

The primary purposes problems and working cooperatively
to resolve a security incident effecting one or more of the Template are:

  - SIRTs'
constituencies.

In establishing relationships to help support such interactions, SIRTs improve the way they operate;

  - will
need to improve interactions decide what kinds of agreements can exist between different SIRTs, 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 organizations such as vendors organization) simply contacts
another SIRT and law-enforcement
    agencies;

  - to note necessary interactions with their constituencies in setting
    expectations asks for help or advice.

Although the establishing of such relationships is very important and defining policies;

  -
affect the ability of a SIRT to help new groups understand what support its constituency, it takes is up to "be" a SIRT.

A Template might appear
the teams involved to provide a marketing tool decide about the details.  It is beyond the scope
of this document to make recommendations for comparing
different teams, but this kind of marketing use (or abuse) is strongly
discouraged by process.  But the GRIP Working Group.

3.1 Other Related Material

This 'Framework for Response Teams' document is the first produced by
the GRIP Working Group.  A second document will
same set out guide-lines for
technology vendors of information used to help them handle security incidents.  The
definition set expectations for a  user community
regarding sharing of terms given in the next section applies information will help other parties to both documents.

Another relevant IETF document is RFC 1244, the Site Security Handbook,
produced by (and being updated by) the Site Security Handbook Working
Group (SSH). Site requirements and recommendations are covered by understand
the
Handbook, while response team expectations objectives and procedures are addressed
by the GRIP documents.

Other documents services of interest 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 discussion coordination of incident response
teams and their tasks are available by anonymous FTP. A collection can
be found on:

 * ftp://ftp.nic.surfnet.nl/surfnet/net-security/
                                    cert-nl/docs/reports/R-92-01

Some especially interesting documents are:

 * CERT-NL Framework
     ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt

 * FIRST potential members
     ftp://ftp.first.org/pub/first/newmemlt.txt
     ftp://ftp.first.org/pub/first/profile.txt
     ftp://ftp.first.org/pub/first/op`frame.txt
     http://www.first.org/first

 * NRL Incident Response Manual
     http://hightop.nrl.navy.mil/news/incident.html

 * Bibliography
     http://www.cert.dfn.de/eng/team/kpk/certbib.html

4 The Security Incident Response Team Template

This material which follows is addressed - all
parties involved need secure communications channels. ("Secure" hereby
relates to those responsible for
Security Incident Response Teams.

4.1 Template Updates

Details of a Securty IRT change with time, so the template must indicate
when it was last changed, who will be informed protected transmission of future changes, and
(by implication) who will not.  Without this, it is inevitable that
misunderstandings information shared between
different parties and misconceptions will arise over time.

4.1.1 Date of last update

This should be sufficient to allow anyone interested to evaluate not the
currency appropriate use of the template.

4.1.2 Distribution list for Template Updates

Persons on this list are notified automatically whenever information by the template is
changed.
parties.)

The list might normally cover goals of secure communication are:

   - Confidentiality:
     Can somebody else access the constituency and any other
groups content of the SIRT has frequent interactions with.  Readers not on communication?

   - Integrity:
     Can somebody else manipulate the list
can then recognise that they should check content of the central repository (above)
for possible updates.

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

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

It is very easy to
those on its distribution list.

4.2 Charter

Every SIRT must have send forged e-mail, and not hard to establish a charter which specifies what
(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 do, and secure telephone communication.  But before using such
mechanisms, both parties need the authority under "right" infrastructure, which it will do it. is to
say preparation in advance.  The charter should include at
least most important preparation is ensuring
the following:

 * mission statement
 * constituency
 * sponsor / affiliation
 * authority

4.2.1 Mission Statement

The mission statement should focus on authenticity of the team's core activities,
already stated cryptographic keys used in the definition of a SIRT. In order to be considered a secure communication:

Expectations for Security Incident Response Team, the team MUST provide incident
response, by definition.

The goals                 26 March 97

   - Public keys (for techniques like PGP and purposes of a team PEM):
     Because they are especially important, and require
clear, succinct definition.

4.2.2 Constituency

A SIRT's constituency (as defined above) can be determined in many ways.
For example it could accessible through the internet, they must be
     authenticated before usage.  While PGP relies on a company's employees or its paid subscribers,
or it could be defined in terms
     "Web of a technological focus, such as the Trust" - users sign the keys of other users - PEM relies
     on a particular operating system.

The definition of constituency should create a perimeter around hierarchy - certification authorities sign the
group to whom the team will provide service.  The policy section (below)
should explain how requests from outside the perimeter will keys of users.

   - Secret keys (for techniques like DES and PGP/conventional
     encryption):  Because they must be handled.

Constituencies might overlap, as when an ISP supports a SIRT, but
delivers services known to customer sites which also have SIRTs.  The
Authority section (below) should make such relationships clear.

People within sender and receiver,
     they must be exchanged before the constituency have to learn that there is communication via a Security
IRT secure
     channel.

Communication is critical for their purposes; the building all aspects of a trusted relationship with the
constituency is an on-going process which never ends.

4.2.3 Sponsoring organization / affiliation

The sponsoring organization, which authorises incident response.  A team
can best support the actions use of the SIRT,
should be given next.  Defining the affiliation amounts to stating:
"Who is your God?".

4.2.4 Authority

SIRTs may not have authority to intervene above-mentioned techniques by gathering
all relevant information, in a consistent way.  Specific requirements
(like calling a specific number for checking the operation authenticity
of all the
systems within their perimeter.  They keys) should identify be explained right away.  SIRT templates provide a
standardized vehicle for delivering this information.

It is beyond the scope of their
control as distinct from this document to address all the perimeter of their constituency; if other
SIRTs operate hierachically within their perimeter, these should be
identified.

4.3 Policies

4.3.1 Types of incidents technical
and level administrative problems of support secure communications.  The types of incident which the team point is authorised
that response teams must support and use a method to address secure the
communications between themselves and their constituents (or other
response teams).  Whatever the mechanism is, the level of support which protection
it provides must be acceptable to the team will contribute when assisting with each
type constituent community.

3 Information, Policies and Procedures

In chapter 2, it was mentioned that the policies and procedures of incident should a
response team need to be summarized here in list form.  The Services
section (later) provides opportunity for more detailed definition.

The team should state whether it published to their constituent community.
In this chapter we will act on list all the types of information it receives
about vulnerabilities which create opportunities for future incidents.
A commitment that the
community needs to act on such information on behalf of receive from its constituency response team.  How this
information is
regarded as an optional pro-active service policy rather than a core
service requirement for communicated to a SIRT.

4.3.2 Co-operation and interaction with other organizations

This section should make explicit community will differ from team to
team, as will the related groups with which specific information content.  The intent here is
to clearly describe the SIRT
routinely interacts.  Examples various kinds of these are listed below.

Incident Response Teams:    A SIRT will often need information that a
constituent community expects from its response team.

To make it easier to interact understand all issues and topics relevant to the
interaction of constituents with
other SIRTs.  For example "their" SIRT, we suggest that a SIRT within
publish all information, policies and procedures addressing their
constituency as a large company may need document, following template given in Appendix D.
The template structure arranges items, making it easy to
report incidents supply
specific information, was done for the example in Appendix E.  While
no recommendations are made as to what a national SIRT, and a national SIRT may need to
report incidents to national SIRTs in other countries.

Vendors:    Larger vendors have should adopt for their own SIRTs, but smaller vendors
may not.  In such cases
policy or procedures, different possibilities are outlined to give some
examples. The most important thing is that a SIRT will need to work directly with has a vendor.

Law-enforcement agencies:    These include the police policy and other
investigative agencies.  SIRTs and users of that

Expectations for Security Incident Response                 26 March 97

that those who interact with the template should be
sensitive to local laws and regulations, which may vary considerably in
different countries.

Press:    A SIRT may be approached by the Press for information and
comment from time to time.  This is discussed in more detail immediately
below.

4.3.3 Reporting and Disclosure

The default status of any can obtain and all security-related information which a understand it.

As always, not every aspect for every environment and/or team receives can only
be 'confidential,' but rigid adherence to this
makes the team a 'black hole.'  Its template covered.  This outline should define what
information it will report or disclose, to whom, and when.

Different teams are likely to be subject to different legal restraints
requiring or limiting disclosure, especially if they work in different
jurisdictions. seen as a suggestion.  Each team's template team
should specify any such restraints,
both to clarify clients' expectations and feel free to inform other teams.

Conflicts include whatever they think is necessary for
supporting their constituency.

3.1 Contact Information

Full details of interest, particularly in commercial matters, may also
restrain disclosure by a team; the present Draft does not recommend on how such conflicts to contact the SIRT should be addressed.

An explicit policy concerning disclosure listed here, although
this might be very different for different teams.  Some might choose to
restrict the Press can be helpful,
particularly in clarifying availability of names of all team members. No further
clarification is given when the expectations meaning of a SIRT's constituency.

'Disclosure' includes:

  - reporting incidents within the constituency to other teams; item can be assumed.

   - handling incidents occurring within Name of the constituency, but reported
    from outside it. SIRT

   - reporting observations from within the constituency indicating
    suspected or confirmed incidents outside it; Mailing Address

   - acting on reports of Time zone                     This is useful for coordinating
                                   incidents occurring outside the constituency; which cross time zones.

   - passing information about vulnerabilities to vendors, to Partner
    SIRTs or directly to affected sites lying within or outside the
    constituency; Telephone number

   - feed-back to parties reporting incidents or vulnerabilities; Facsimile number

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

The reporting Other telecommunication       Some teams might provide secure
                                   voice communication (e.g. STU III).
   - Electronic mail address

   - Public keys and disclosure policy should make clear who will be the
recipients encryption    The use of a SIRT's reports in each circumstance.  It should also
note whether specific techniques
                                   depends on the team will expect to deal through another Security IRT
or directly with a member ability of another constituency over matters directly
involving that member.

A team will normally collect statistics.  If they are distributed, the
template's reporting and disclosure policy should say so,
                                   communication partners to have
                                   access to programs, keys and so on.
                                   Relevant information should
list the recipients.

4.3.4 Communication be
                                   outlined so users can determine
                                   if and authentication

Methods how they can make use of
                                   secure and verifiable communication while
                                   interacting with the SIRT.
   - Team members

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

Expectations for communication between SIRTs and between Security Incident Response                 26 March 97

3.2 Document Updates

Details of a SIRT and
its constituents.  The change with time, so the completed template must
indicate when it was last changed.  Additionally, information should include public keys or pointers be
provided to them, including key fingerprints, together with guidelines on learn about how to
use this information to check authenticity.

At the moment find out about future updates.  Without
this, it is recommended inevitable that every SIRT have, as a minimum, a
PGP key available, since PGP is available world-wide.  Teams may also
make other mechanisms available, for example PEM.

For communication via telephone or facsimile a SIRT may keep secret
authentication data for parties with whom they may deal, such as misunderstandings and misconceptions will
arise over time; an
agreed password or phrase.

4.4 Services

Services outdated document will do more harm than good.

   - Date of last update           This should be defined in two sections, as listed below.

 * direct incident response
    + verification of incident
    + technical assistance and analysis sufficient to understand allow
                                   anyone interested to evaluate the compromise
                                   currency of the template.

   - Distribution list             Mailing lists are a system
    + notification of other involved parties
    + eradication
    + recovery

 * optional
    + convenient
                                   mechanism to distribute up-to-date
                                   information provision
       - vulnerability archive
       - patches and resolutions
    + tools
    + education
    + audit and consulting
    + product evaluation

4.5 Incident reporting Forms

Samples to a large number of reporting forms used by
                                   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 (or pointers to them) has frequent
                                   interactions with.

                                   Digital signatures should be included at this point in a template.

4.6 Disclaimers

Although the template does not constitute used
                                   for update messages sent by a contract, liability might
conceivably result from its descriptions SIRT.

   - Location of services and purposes. the document      The
inclusion of location where a disclaimer at the end current version
                                   of the template is recommended.

It document should be noted that some forms of reporting or disclosure relating
to specific incidents or vulnerabilities accessible
                                   through a team's online information
                                   services.  Constituents can imply liability, and SIRTs
should consider the inclusion of disclaimers in such material.

In situations where then
                                   easily learn more about the original team and
                                   check for recent updates.

                                   This online version of a template must be
translated into another language, the translation should carry also be
                                   accompanied by a
disclaimer and digital signature,

3.3 Charter

Every SIRT must have a pointer charter which specifies what it is to do, and
the original.  For example:

    Although we tried to carefully translate our German template
    into English, we can not be certain that both documents express authority under which it will do it.  The charter should include
at least the same thoughts following statements:

   - Mission statement
   - Constituency
   - Sponsor / affiliation
   - Authority

Expectations for Security Incident Response                 26 March 97

3.3.1 Mission Statement

The mission statement should focus on the team's core activities,
already stated in the same level definition of detail and correctness. a SIRT.  In all cases, where there is order to be considered
a difference between both
    versions, Security Incident Response Team, the German version is team must support the binding version for our
    operation.

5 Secondary Purposes reporting
of this Document incidents and support its constituency by dealing with incidents.

The primary audience goals and purposes of this document a team are especially important, and require
clear, unambiguous definitions.

3.3.2 Constituency

A SIRT's constituency can be determined in many 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 administrators responsible
for communities users of users, i.e.  'constituencies.'  This section provides
some brief notes on what SIRT clients should expect a
particular operating system.

The definition of their teams.

An incident response team exists primarily constituency should create a perimeter around the
group to support whom the clients in its
constituency.  It is vital that those clients understand what they
should expect team will provide service.  The policy section of their team.  Provided that a SIRT has published its
template, a constituent/client should be able to read
the template and
discover what to expect, for example in such areas as privacy and

confidentiality of information, and whether document (see below) should explain how requests from outside the response team
perimeter will be
contacting downstream sites.  Clients should certainly expect handled.

If a SIRT decide, not to
provide the services they detail in disclosure their template.

An important aspect of incident response is the 'follow through' - every
incident should be investigated and appropriate actions taken.  Clients constituency, they should be encouraged by
explain the reasoning behind this decision. For example for-fee
SIRTs will not list their SIRT to report incidents so that they can
be acted upon.  It must be emphasised that without active participation
(especially reporting) from clients the effectiveness of the services but declare that they depend on can be greatly diminished.  As provide
a minimum, clients need service to
know a large group of customers that they should report security incidents, and know how and where
they should report them.

Individual users (i.e.  those who are not part kept confidential
because of the clients' contract.

Constituencies might overlap, as when an organisation which ISP provides a SIRT for its members) who observe a security incident should
ask their Internet Service Provider for details of the most suitable
SIRT to report it to.

Appendix B (below) provides some pointers SIRT, but
delivers services to SIRTs customer sites which were known when
this also have SIRTs.  The
Authority section of the document was published.

6 Appendix A: Note on procedure definitions

Policies and statements (see below) should make such
relationships clear.

3.3.3 Sponsoring Organization / Affiliation

The sponsoring organization, which authorizes the actions of services in the template have to SIRT,
should be
implemented as procedures, but descriptions of those procedures should
not be included in given next.   Knowing this will help the template.

The following notes are intended to assist those seeking to form or users to
improve their SIRTs.

 * External
    + identify other response teams
    + define supported clients:
        - by domain, through registration system, other means
    + establish secure communication practices
        - use of network, cell-phones, etc
    + define information that a client site must/should provide
        - use understand
the background and setup of reporting forms

* Internal
  + secure the team's infrastructure
  + protect SIRT.  It is vital information servers
  + protect sensitive data
  + define expiry of sensitive data
  + define disposal practice for sensitive data
  + establish methods
building up trust between a constituent and a SIRT.

Expectations for gathering Security Incident Response                 26 March 97

3.3.4 Authority

Based on the relationship between team and keeping statistics
  + establish 'knowledge base' of lessons learned constituency this section
will be very different from past incidents
  + create practical implementations of disclosure policies
  + document explicit practices for disclosure one team to another. While an
organizational SIRT will be given its authority by the Press

The Site Security Handbook is management,
a first resource to consult community SIRT will be supported and chosen by the community,
usually in securing a
team's infrastructure.  SIRT-specific security measures advisory role.

SIRTs may evolve
later.

7 Appendix B: Known Incident Response Teams

FIRST is not have authority to intervene in the Forum operation of Incident Response and Security Teams.  Information
about FIRST can be found via all the
systems within their World Wide Web home page:

   http://www.first.org/first

This page contains pointers to 'Team Contact Information' for perimeter.  They should identify the scope of
their control as distinct from the perimeter of their constituency; if
other SIRTs who
are FIRST members, operate hierarchically within their perimeter, these should
be identified and to 'Teams with WWW Servers.'

8 Appendix C: Example: addressed here.

A disclosure of a 'filled-in' template

<HTML>
<HEAD>
    <TITLE>SIRT Template team's authority may expose it to claims of
liability.  Every team should seek legal advice on these matters.
(See section 3.7 for XYZ SIRT</TITLE>
</HEAD>

<P>
Note: no digital signature is currently more on liability.)

3.4 Policies

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 opportunity for more detailed definition
and to address non-incident related topics.

The level of support might change, depending on factors like workload
or completeness of 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 each reported incident.

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

Expectations for Security Incident Response                 26 March 97

3.4.2 Co-operation and Interaction with other Organizations

This section should make explicit which related groups with which the
SIRT routinely interacts with.  Such interactions are not related to
the Security Incident Response provided, but are used 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 is to give the constituency a basic understanding
what kind of interactions are established and what their purpose is.
Examples 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 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 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, to analyse the technical
     problem or to test provided solutions.

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

Press:
     A SIRT may be approached by the Press for information and comment
     from time to time.  This is discussed in more detail immediately
     below.

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

Expectations for Security Incident Response                 26 March 97

3.4.3 Reporting and Disclosure

The default status of any and all security-related information which a
team receives will usually be 'confidential,' but rigid adherence to
this makes the team to appear as a 'black hole.'  Its template should
define what information it will report or disclose, to whom, and when.

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

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

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

   - Reporting incidents within the constituency to other teams. By
     this, site related information might become public knowledge,
     accessible for everybody, especially the press.

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

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

   - Acting on reports of incidents occurring outside the constituency.

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

   - Feed-back to parties reporting incidents or vulnerabilities.

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

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

Expectations for Security Incident Response                 26 March 97

towards press contacts.

The reporting and disclosure policy should make clear who will be the
recipients of a SIRT's report in each circumstance.  It should also
note whether the team will expect to deal through another SIRT
or directly with 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, and should list methods 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 a SIRT
and its constituents.  The template should include public keys or
pointers to them, including key fingerprints, together with guidelines
on how to use this information to check authenticity and how to deal
with corrupted information (for example where to report this fact to).

At the moment it is recommended 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 and
the needs of its constituents.    Note however, that SIRTs and users
should be sensitive to local laws and regulations.  Some countries do
not allow strong encryption or enforce specific policies on the use of
encryption technology.  In addition to encrypting sensitive information
whenever possible, correspondence should include digitally 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 as an
agreed password or phrase.

3.4.5 Point of Customer Contacts

More detailed contact information might 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 (like addresses for mailing list requests) these
should be explained here.

Expectations for Security Incident Response                 26 March 97

3.5 Services

Services provided by each SIRT can be differentiated by whether they
relate to the main task, which is incident response, or are provided
in addition (optional in regard to the definition of a SIRT).

Incident response, which usually includes:

   - Verification                  Help with the verification of
                                   incidents, as well as their scope.

   - Technical Assistance          This may include analysis of
                                   compromised systems.

   - Eradication                   Elimination of the effects of a
                                   security incident.

   - Recovery                      Aid 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:

   - Information provision         This might include an archive of
                                   known vulnerabilities, patches or
                                   resolutions 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
and therefore come well prepared.  The team gets all the necessary
information at once with the first report and can proceed efficiently.

Expectations for Security Incident Response                 26 March 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 of the team.  The exact pointers to them should be given in
the document, together with statements about appropriate use and
guidelines, for when and how to use the forms.  If separate e-mail
addresses are supported for form based reporting, they should be
listed here again.

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

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

3.7 Disclaimers

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

It should be noted that some forms of reporting or disclosure relating
to specific incidents or vulnerabilities can also imply liability, and
SIRTs should consider the inclusion of disclaimers in such material.

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

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

The use of and protection by disclaimers is effected by local laws and
regulations.  Therefore each SIRT should be sensitive and if in doubt
should check the disclaimer with a lawyer.

Expectations for Security Incident Response                 26 March 97

4 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 sources, for example to the
[RFC 1983].

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

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

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

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

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

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

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

Expectations for Security Incident Response                 26 March 97

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

       - Provide a (secure) channel for receiving reports about
         suspected incidents.
       - Provide assistance to members of its constituency in
         handling these incidents.
       - Disseminate incident-related information to its
         constituency and to other involved parties.

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

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

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

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

5 Appendix B: Related Material

Important issues in responding to security 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 the avoidance of
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:

Expectations for Security Incident Response                 26 March 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 the Netherlands).

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

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

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

   - ftp://info.cert.org/incident_reporting_form
     This Incident Reporting Form is provided by the CERT
     Coordination Center to gather incident information and to avoid
     additional delays 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 of the major and long established teams (the first SIRT was
founded in 1988) are nowadays member of FIRST, the worldwide Forum of
Incident Response and Security Teams.  Actually more than 55 teams are
members (1 in Australia, 13 in Europe, 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 and some additional information provided by the single
teams:

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

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

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

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

Many of the European teams, regardless if they are members 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 the issues addressed in this document in a logical
structure suitable to communicate the policies and procedures for the
interaction with SIRTs easily to the team's constituency.  A 'filled-in'
example of this template is given as Appendix E.

    1.   Contact Information
    1.1  Name of 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 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

    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 is an example, a filled-in template for a SIRT called XYZ
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 XYZ Enterprises.
<P>

<XMP>

 1. Contact Information
----------------------

 1.1 Name of 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, and GMT-0400 from April to October)

 1.4 Telephone Number
        +1 234 567 7890  (ask for 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 and Other Encryption Information
        Encryption is not currently available, but we plan to install
        PGP as soon as possible.  Our PGP public key will appear here
        as soon as it is available.

Expectations for Security Incident Response                 26 March 97

 1.9 Team Members
>>        Jane Doe of Computing Services is the XYZ-SIRT
        coordinator.  Other team members will be listed here once
        their participation is confirmed.

2. Template Updates
-------------------

 2.1 Date of Last Update
        Please see the bottom of this Web page for this information.

 2.2 Locations where this Template May Be Found
        This template is available from the XYZ SIRT WWW
        site; its URL is
           http://www.xyz.org/THIS-INFORMATION-NOT-YET-AVAILABLE
>>      The template will be signed with the XYZ-SIRT's private PGP
>>      key.  (WHAT TO DO?  Sign just the template?  The whole Web
>>      page?  Try ASCII armor?  Or have the signature separate?)

        There are no plans for the automatic distribution of fresh
        copies of this template after updates; please make sure that
        you are using the latest version by checking our Web site.

3. Charter
----------
 3.1 Mission Statement
        The purpose of the XYZ-SIRT is, first, to assist members of
        XYZ community in implementing proactive measures to reduce
        the risks of computer security incidents, and second, to
        assist XYZ community in responding to such incidents when
        they occur.

 3.2 Constituency
        The XYZ-SIRT's contituency 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
        The XYZ-SIRT operates under the auspices of, and with
        authority delegated by, the Department of Computing Services
        of XYZ Enterprises.  The Department in turn receives its
        authority from the formal ruling bodies of XYZ, as
        set out in the "Policy on Computing Facilities".  The XYZ-SIRT
        has no direct authority over systems at XYZ Enterprises
        at large.  However, it benefits from the direct authority of
        Computing Services with respect to systems managed by this
        Department.  Also, because
        Jane Doe of Computing Services manages the
        XYZ Enterprises Network, 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 to XYZ-SIRT
        coordinator.  Other team members will be disconnected from listed here once
        their participation is confirmed.

 2. Document Updates

 2.1 Date of Last Update
        Please see the network should
        circumstances warrant it.

        The XYZ-SIRT expects to work cooperatively with system
        administrators and users at XYZ, and, insofar as
        possible, bottom of this Web page for this information.

 2.2 Distribution List for Notifications
        Notifications of updates are submitted to avoid authoritarian relationships.  However, our mailing list
        <xyz-sirt-info@sirt.xyz.org>. (Subscription request should circumstances warrant it, the XYZ-SIRT will appeal to
        Computing Services
        go to exert its authority, direct or indirect,
        as necessary.

4. Policies
-----------

 4.1 Types of Incidents
        The XYZ-SIRT <xyz-sirt-info-request@sirt.xyz.org>.)

 2.3 Locations where this Document May Be Found
        This template is authorized to address all types of computer
        security incidents which occur, or risk occurring, at available from the XYZ Enterprises.

 4.2 Level of Support SIRT WWW
        site; its URL is
           http://www.sirt.xyz.org/op_frame.html
        The level of support given by XYZ-SIRT template will vary depending on be signed with the type and severity XYZ-SIRT's PGP
        key.

 3. Charter

 3.1 Mission Statement
        The purpose of the incident or issue, the type XYZ-SIRT is, first, to assist members of
        consituent,
        XYZ community in implementing proactive measures to reduce
        the size risks of the user community affected, computer security incidents, and the
        XYZ-SIRT's resources at the time.

        No direct support will be given second, to end users; they are
        expected
        assist XYZ community in responding to contact their system administrator, network
        administrator, or department head for assistance. such incidents when
        they occur.

 3.2 Constituency
        The
        XYZ-SIRT will support the latter people.

        While XYZ-SIRT's constituency is the XYZ-SIRT understands that there exists great
        variation XYZ SIRT community,
        as defined in the level context of system administrator expertise at
        XYZ, and while the "XYZ Policy on Computing
        Facilities".

 3.3 Sponsors and/or Affiliation
        None.

 3.4 Authority

        The XYZ-SIRT will endeavour to present
        information and assistance at a level appropriate to
        each person, operates under the XYZ-SIRT cannot train system administrators, auspices of, and it cannot perform system maintenance on their behalf.
        In most cases, with
        authority delegated by, the XYZ-SIRT will provide pointers to Department of Computing Services
        of XYZ Enterprises.  The Department in turn receives its
        authority from the
        information needed to implement appropriate measures.

 4.3 Disclosure formal ruling bodies of Information
>>      &&&&&&&&&&&&&&&&&&&&
>>      Difficult section; not done yet.  Also, 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 at XYZ Enterprises
        at large.  However, it overlaps heavily
>>      with benefits from the section below; I'm not sure direct authority of the best way
        Computing Services with respect to
>>      separate them.  Questions not yet addressed:
          - reporting incidents within systems managed by this
        Department.  Also, because Computing Services manages the constituency
        XYZ Enterprises Network, and is responsible for connectivity
        to it, the Department has indirect authority over systems
        in other teams;
          - handling incidents occurring within departments, inasmuch as the constituency, but
            reported from outside it.
          - reporting observations Department can order
        such systems to be disconnected from within the constituency
            indicating suspected or confirmed incidents outside it;
          - acting on reports of incidents occurring outside the
            constituency;
          - passing information about vulnerabilities to vendors, network should
        circumstances warrant it.

        The XYZ-SIRT expects to
            Partner SIRTs or directly work cooperatively with system
        administrators and users at XYZ, and, insofar as
        possible, to affected sites lying within
            or outside avoid authoritarian relationships.  However,
        should circumstances warrant it, the constituency;
          - feed-back XYZ-SIRT will appeal to parties reporting incidents
        Computing Services to exert its authority, direct or vulnerabilities;
          - the provision indirect,
        as necessary.

 4. Policies

 4.1 Types of contact information relating to members Incidents and Level of
            the constituency, members Support

        The XYZ-SIRT is authorized to address all types of other constituencies, other
            SIRTs computer
        security incidents which occur, or law-enforcement agencies.
        Food for thought:
          Types of info:
             - Contact info for constituents.
             - Technical info about a vulnerability.
             - Technical info about risk occurring, at
        XYZ facilities.
             - Information about incidents:
                 - Statistical summaries
                 - Admission of incident Enterprises.

        The level of certain support given by XYZ-SIRT will vary depending on
        the type
                 - Admission of root compromise
                 - Admission of packet sniffing attack
                 - Admission that user accounts were compromised
                 - Description and severity of the incident
                     - Identity of affected systems
                     - Identity of affected people
                     - Identity or issue, the type of perpetrator
          Recipients
        consituent, the size of info:
             - XYZ management
             - Computing Services management
             - Affected sysadmin at XYZ
             - Affected sysadmin (or SIRT) at another site
             - Affected user(s) at XYZ
             - All sysadmins potentially concerned (potentially
               vulnerable) at XYZ
             - All sysadmins the user community affected, and the
        XYZ-SIRT's resources at XYZ
             - All users potentially concerned the time.

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

        While the XYZ-SIRT understands that there exists great
        variation in the level of system administrator expertise at XYZ
               (information
        XYZ, and while the XYZ-SIRT will leak endeavor to general public)
             - All users present
        information and assistance at XYZ (ditto)
             - Computer security community
             - Peer sysadmins a level appropriate to
        each person, the XYZ-SIRT cannot train system administrators,
        and SIRTs
             - Vendors
             - Law enforcement

 4.4 it cannot perform system maintenance on their behalf.
        In most cases, the XYZ-SIRT will provide pointers to the
        information needed to implement appropriate measures.

Expectations for Security Incident Response                 26 March 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 or national SIRTs be
            constituted, XYZ-SIRT will explore the possibility of peer
            relationships with them.  The possibility of peer
            relationships with close neighbours neighbors will also be explored;
            unofficial cooperative climates already exist between XYZ
            and several nearby universities and large corporations.
            While there are no legal requirements that XYZ-SIRT provide
            eny
            any information to any body outside XYZ (aside from
            law enforcement agencies), XYZ-SIRT will provide such
            information when the good of the community justifies it.
            However, unless identifying information is needed to track
            an incident in progress, such information will be stripped
            from the report (unless the affected department gives its
            permission that the real information be used).
        - Vendors:
            The XYZ-SIRT wishes to encourage vendors of all kinds of
            networking and computer equipment, software, and services
            to improve the security of their products.  In aid of
            this, a vulnerability discovered in such a product will be
            reported to its vendor, along with all technical details
            needed to identify and fix the problem.  Identifying
            details will not be given to the vendor without the
            permission of the affected parties.
        - Law enforcement:
>>
            XYZ has its 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 at XYZ and the local police; interest
            has been expressed by all parties in formalising formalizing these
            relationships.  Any progress
            made in that area will be reflected in this section.
            In the meantime, authorized and unauthorized users of the
            XYZ Computing Facilities should be aware that the
            XYZ-SIRT will cooperate fully with law enforcement
            agencies in detecting, reporting, documenting, and
            prosecuting violations of the law; users concerned about
            confidentiality are referred to the XYZ "Policy on
            Computing Facilities".

Expectations for Security Incident Response                 26 March 97

        - The Press:
            The XYZ-SIRT will not interect interact directly with the Press.
            If necessary, information will be provided to the
            XYZ Public Relations Department, and to the
            Customer Relations group of the Computing Services
            Department.  All queries will be referred to these two
            bodies.
        - The XYZ SIRT community:
            Details of incidents may be released to Computing Services
            management, XYZ management, or the Computer
            Resources Committee; these bodies will be charged with
            maintaining the confidentiality of the information.  General
            report of incidents, summaries of multiple incidents, and
            statistics may be made available to the general XYZ
            community, with identifying information stripped (except
            where permission has been obtained from the affected
            parties).  There is no obligation on the part of the
            XYZ-SIRT to report incidents to the community, though it
            may choose to do so; in particular, it is likely that the
            XYZ-SIRT will inform all affected parties of the ways in
            which they were affected.
        - The public at large:
            In general, no particular efforts will be made to
            communicate with the public at large, though the XYZ-SIRT
            recognizes that, for all intents and purposes, information
            made available to the XYZ community is in effect
            made available to the community at large, and will tailor
            the information in consequence.
        - The computer security community:
            While members of XYZ-SIRT 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
            experience will be disguised to avoid identifying the
            affected parties.

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

 4.5

 4.3 Disclosure of Information

        The following types of information will be stored and handled
        by XYZ-SIRT:
             - Contact info for constituents.
             - Technical info about 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 that user accounts were compromised
                 - Description of incident
                     - Identity of affected systems
                     - Identity of affected people
                     - Identity of perpetrator

          Recipients 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 will leak to general public)
             - All users at XYZ (ditto)
             - Computer security community
             - Peer sysadmins and SIRTs
             - Vendors
             - Law enforcement

 4.4 Communication and Authentication

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

        Where it is necessary to establish trust, for example before
        relying on information given to the XYZ-SIRT, 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, and with known
        neighbour
        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.6

 4.5 Points of Customer Contact

        The preferred method for contacting the XYZ-SIRT will be
        e-mail.  If this 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

 5. Services
-----------

 5.1 Incident Response
>>      &&&&&&&&&&&&&&&&&&&&&&&7
>>      This section requires a lot

        XYZ-SIRT will help users and administrators to handle the
        technical and organizational aspects of incidents. By that,
        it will provide and facilitate:
             - to understand the extend of thought. the incident
             - ...

 5.2 Proactive Activities

        The XYZ-SIRT will coordinate and maintain the following
        services to the extent possible depending on its resources:
           - Information services
              - List of departmental security contacts, administrative
                and technical.
              - Mailing lists to inform security contacts of new
                information relevant to their computing environments.
              - Repository of vendor-provided and other security-related
                patches for various operating systems.
              - Repository of security tools for use by sysadmins.
              - "Clipping" service for various existing resources, such
                as major mailing lists and newsgroups; important issues
                of relevance to operating environments in use at the
                XYZ will be reported and archived. newsgroups.
           - Auditing services
              - Central file integrity checking service for Unix
                machines.
              - "Tiger teams".
              - Security level assignments; machines at XYZ
                will be audited and assigned a security level: not all
                machines require or can attain the same level of
                security, but it is important to know which ones are
                reasonably secure and which are not. level.
           - Archiving services
              - Central logging services for Unix machines.
              - Records of security incidents handled.

 6. Incident Reporting Forms
---------------------------

>>      &&&&&&&& Not done yet; I'll probably use an existing
>>      one from somewhere initially.

7. Disclaimers
--------------

>>  -- resp. for technical disclosures (bugtraq) etc.?
>>  -- resp. for results

        There are no own forms developed yet for XYZ-SIRT advice?
>>  &&&&&&&&&&&&&&&&&&&7
>>  WILL NEED XYZ LEGAL COUNSEL ON THIS?

8. Additional Information
------------------------- reporting incidents
        to XYZ-SIRT. If possible, please make us of the Incident
        Reporting Form of the CERT Coordination Center (Pittsburgh, PA).
        The actual version of this template published in this RFC is available from:
            ftp://info.cert.org/incident_reporting_form

 7. Disclaimers

        While every precaution will undoubtedly be
out of date by taken in the time you see it; it is intended as an example only.
Please pick up a fresh copy preparation of
        information, notifications and alerts, XYZ-SIRT assumes no
        responsibility for errors or omissions, or for damages
        resulting from our Web site if you actually need
information about XYZ-SIRT.

History the use of this template:

   1996/07/29  Jane Doe, version 1.0
      THIS VERSION HAS ABSOLUTELY NO MANAGEMENT APPROVAL!

</XMP>

</BODY>
</HTML> the information contained within.

Expectations for Security Incident Response                 26 March 97

9 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 Security Considerations

This document discusses issues of the operation of Security Incident
Response Teams, and the teams interactions with their constituency.
It is therefore not directly concerned with the security of
protocols protocols,
applications or network systems themselves.  It is not even concerned
about the response and reaction to security incidents.

Nonetheless, it is vital that SIRTs establish secure communication
channels with other teams, and with members of their constituency.
They must also secure their own systems and infrastructure.

10 Author's Address infrastructure, to protect
the interests of their constituency and to maintain the confidentiality
of the identity of victims and reporters of security incidents.

11 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, 1997.