Internet Engineering Task Force                           Nevil Brownlee
INTERNET-DRAFT                                The University of Auckland
                                                           November 1996

              Expectations for Security Incident Response

                <draft-ietf-grip-framework-irt-03.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 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.'

Please

To learn the current status of any Internet Draft, please check the I-D abstract
'1id-abstracts.txt' listing contained in the Internet-drafts
Shadow Directories Internet Drafts shadow
directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com or ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au to learn the current status of this or
any other Internet Draft. (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document is intended to facilitate the setting of expectations
regarding the operation of Security Incicident Response Teams (SIRTs).
It describes the various important topics in the form of a 'template,'
through which every SIRT should describe itself and its functions.

SIRT clients have a legitimate need and right to fully understand the
policies and procedures of their Security Incident Response Team.  A
SIRT's template supplies details for the various important topics which
clients must consider when selecting a SIRT.

Contents

 1 Introduction                                                        2                                                        3
   1.1 Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Publishing SIRT Templates  . . . . . . . . . . . . . . . . . .  5  6
   1.3 Establishing Peering Between Relationships between SIRTs  . . . . . . . . . . . . . . . . .  6
   1.4 Establishing Communications between SIRTs  . . . . . . . . . .  7

 2 Description Template:  Security Incident Response Team              6              7

 3 Purpose of the Template                                             8
   3.1 Other Related Material . . . . . . . . . . . . . . . . . . . .  8  9

 4 The Security Incident Response Team Template                        9                       10
   4.1 Contact Information  . . . . . . . . . . . . . . . . . . . . .  9
   4.2 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.1Date
     4.1.1Date of last update . . . . . . . . . . . . . . . . . . . . 10
     4.2.2Distribution
     4.1.2Distribution list for Template Updates  . . . . . . . . . . 10
   4.3
   4.2 Charter  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.1Mission 11
     4.2.1Mission Statement . . . . . . . . . . . . . . . . . . . . .  10
     4.3.2Constituency 11
     4.2.2Constituency  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.3.3Sponsoring organisation
     4.2.3Sponsoring organization / affiliation . . . . . . . . . . .  11
     4.3.4Authority 12
     4.2.4Authority . . . . . . . . . . . . . . . . . . . . . . . . .  11
   4.4 12
   4.3 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.4.1Types
     4.3.1Types of incidents and level of support . . . . . . . . . . 12
     4.4.2Co-operation
     4.3.2Co-operation and interaction with other organizations . . . 12
     4.4.3Reporting
     4.3.3Reporting and Disclosure  . . . . . . . . . . . . . . . . . 13
     4.4.4Communication
     4.3.4Communication and authentication  . . . . . . . . . . . . . 14
   4.5
   4.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.6
   4.5 Incident reporting Forms . . . . . . . . . . . . . . . . . . . 15
   4.7
   4.6 Disclaimers  . . . . . . . . . . . . . . . . . . . . . . . . . . 15

 5 Secondary Purposes of this Document                                 16                                15

 6 Appendix A: Note on procedure definitions                          16

 7 Appendix B: Known Incident Response Teams                          17

 8 Appendix C: Sample Incident Reporting Form Example:  a 'filled-in' template                       17

 9 Security Considerations                                            25

10 Editor's Author's Address                                                   25

1 Introduction

The GRIP Working Group was formed to produce guidelines and
recommendations to facilitate the consistent handling of security
incidents in the Internet community.  Although it is focused on the
Internet, many of the concepts discussed will also be useful for other
forms of local- and wide-area networks and internets.

Many computer security incidents either originate orginate outside local community
boundaries and affect other 'outside' sites, or originate and others orignate outside
the local community and affect hosts or users within it.  The  Often,
therefore, the handling of security incidents will therefore often involve multiple
Security Incident Response Teams.  Because 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.

In the past there have been misunderstandings regarding expectations of
response teams.  The goal of this document is to provide a framework in
which to set expectations.  By defining such a framework the community
can express areas and topics that need to addressed by any SIRT.

'Consistent handling' implies that any group calling itself a SIRT must
react to security incidents or to threats of them in ways which the
Internet community agrees to be in its general interest.  Every SIRT
needs to define clearly the services they offer and the level at which
they are offered to the client. clients.  Such definitions will be particularly
important in contracts and/or agreements which SIRTs make with their
clients.

The "Expectations for Security Incident Response" document is seen as resting on
the work of individual SIRTs and the cooperation between them.  It  This
document therefore recommends a 'template' through which every SIRT
should describe itself and its functions.  It further recommends that
templates should be accessible among teams, to make possible a fully
effective cooperative response framework for incidents or threats across
the entire domain affected by them.

1.1 Definitions

This section defines terms used in describing security incidents and
response teams.  For the purpose of the GRIP documents only a limited
list is really needed.  This should help maintain focus on the purpose
of the documents, and prevent a duplication of other definitions or -
even worse - a proliferation of competing definitions.

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

Implicit in the purpose of a Security Incident Response Team is the
existence of a constituency.  This is the group of clients, sites,
networks or organizations served by the team.

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

For the purpose of this document:

    'A computer security incident is any 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,
 * compromise of integrity,
 * denial of service,
 * misuse,
 * damage.

These are very general categories.  For instance the forging replacement of a
system utility program by a Trojan Horse is an
electronic mail message example of 'loss of
integrity,' and a successful password attack are two
examples is an example of 'compromise 'loss of integrity.'
confidentiality.'

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

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

Based on two of the definitions given above:

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

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

 * provide a 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 related 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 userss users to execute arbitrary
operating system commands in privileged mode, this "feature" would be a
vulnerability.

1.2 Publishing SIRT Templates

Every SIRT should publish information about its policies and services in
the form of a completed template.  The simplest way for a SIRT to make
its template widely available is to publish it on its own information
server so that clients in its constituency can easily find it.
Templates published as pages in the World Wide Web should include 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 - 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 by verifying a digital
signature for it).

To facilitate interaction between SIRTs, it would be useful to have a
central repository for them.  The GRIP Working Group believe that some
of the existing Internet archive areas could be used for this purpose.
The keeper of each template repository will be responsibly for verifying
the identity of each SIRT lodging a template in the repository.

1.3 Establishing Peering Between Relationships between SIRTs

When

In some cases a SIRT (SIRT A) wishes may be able to establish a working relationship with
another SIRT (SIRT B), operate effectively on its own.  It
is much more likely, however, that a responsible person from SIRT A will need to
contact a similarly responsible person at SIRT B. The SIRT B person then
has the problem:  "how do I know who I'm talking to?"

It is very easy interact with
other SIRTs.  Such interactions could include:

 * Responding to send forged e-mail, and not hard requests for advice (e.g. "have you seen this
   problem before?")
 * Reporting of problems (for onward referal to establish a
(false) identity by telephone.  PGP provides other SIRTs, to service
   providers or to vendors)
 * Working co-operatively to resolve a security incident

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 client) simply contacts another
SIRT and asks for help or advice.  Note also that any client wanting
direct help in tracking an incident must be prepared to provide
sufficient 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 to share yet safeguard information, whether 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 the issues involved in this.

When a SIRT (SIRT A) wishes to establish a working relationship with
another SIRT (SIRT B), a responsible person from SIRT A will need to
contact a similarly responsible person at SIRT B. The SIRT B person then
has the problem:  "how do I know who I'm talking to?"

It is very easy to send forged e-mail, and not hard to establish a
(false) identity by telephone.  PGP and PEM provide effective way ways of
securing e-mail, but securing voice communications is much harder.  At
present call-back is probably the only simple authentication method.
This may change as technologies such as scrambled telephones, or
PGP-phone on 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 of the SIRTs they have
peering arrangements (i.e.  working relationships) with, including PGP
public keys for them.

Note that there them and the expiry dates of those keys.

2 Description Template:  Security Incident Response Team

The Template is a difference between a peering agreement, where summarized in the
SIRTs involved agree to work together and share information, and simple
co-operation, where SIRT B (or any other client) simply contacts SIRT A
and asks for help or advice.  Note also that any client wanting direct
help in tracking an incident must be prepared to provide sufficient
information about the incident to make tracking possible.

2 Description Template:  Security Incident Response Team

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

1. Contact Information
-------------------
 * name
----------------------
 1.1 Name of the team
 * address
 * time zone
 * telephone number
 * facsimile number
 * other telecommunication like STU-III, Team
 1.2 Address
 1.3 Time Zone
 1.4 Telephone Number
 1.5 Facsimile Number
 1.6 Other Telecommunication (STU-III, secure facsimile
 * electronic mail address
 * encryption methods for communication: PGP, PEM, MOSS, ..
 * PGP public key (if PGP used) facsimile...)
 1.7 Electronic Mail Address
 1.8 Public Keys and Other Encryption Information
 1.9 Team Members

2. Template Updates
----------------
 * date
-------------------
 2.1 Date of last update
 * locations Last Update
 2.2 Locations where this template may be found Template May Be Found

3. Charter
-------
 * mission statement
 * constituency
 * sponsor / affiliation
 * authority
----------
 3.1 Mission Statement
 3.2 Constituency
 3.3 Sponsors and/or Affiliation
 3.4 Authority

4. Policies
--------
 * types of incidents
 * level
-----------
 4.1 Types of support
 * disclosure
    - Incidents
 4.2 Level of compromised site's information
    - the compromise Support
 4.3 Disclosure of SIRT site to constituency
    - incident reporting requirements
 * cooperation & interaction Information
 4.4 Cooperation and Interaction with
    - incident response teams
    - vendors
    - investigative agencies
    - involved sites
    - press
 * communication & authentication
 * point Other Entities
 4.5 Communication and Authentication
 4.6 Points of customer contacts Customer Contact

5. Services
--------
 * incident response
    - verification
    - understanding
    - coping
    - notification
 * proactive activities
-----------
 5.1 Incident Response
 5.2 Proactive Activities

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

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

3 Purpose of the Template

The Template which this document proposes is expected to be used by a
response team to describe what it does, and in the process create
criteria against which its performance can be measured.  The Template
does not attempt to specify a "correct" way for the team to operate, but
does recommend on specific policies and functions seen as necessary for
such a team to play a consistent role with other SIRTs throughout in the
networking community. overall security framework.
It also comments on additional roles a team might include in the ambit
of its operations.

The primary purposes of the Template are:

  - to help SIRTs improve the way they operate;

  - to improve interactions between different SIRTs, and between SIRTs
    and other organizations such as vendors and law-enforcement
    agencies;

  - to note necessary interactions with their constituencies in setting
    expectations and defining policies;

  - to help new groups understand what it takes to "be" a SIRT.

A Template might appear to provide a marketing tool for comparing
different teams, but this kind of marketing use (or abuse) is strongly
discouraged by 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 set out guide-lines for
technology vendors to help them handle security incidents.  The
definition of terms given in the next section applies 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 the
Handbook, while response team expectations and procedures are addressed
by the GRIP documents.

Other documents of interest for the discussion 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 to those responsible for
Security Incident Response Teams.

4.1 Contact Information

Full details of how to contact the SIRT should be listed here.

4.2 Template Updates

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

4.2.1

4.1.1 Date of last update

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

4.2.2

4.1.2 Distribution list for Template Updates

Persons on this list are notified automatically whenever the template is
changed.  The list might normally cover the constituency and any other
groups the SIRT has frequent interactions with.  Readers not on the list
can then recognise that they should check the central repository (above)
for possible updates.

Digital signatures should be used for update messages sent by a SIRT to
those on its distribution list.

4.3

4.2 Charter

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

 * mission statement
 * constituency
 * sponsor / affiliation
 * authority

4.3.1

4.2.1 Mission Statement

The mission statement should focus on the team's core activities,
already stated in the definition of a SIRT. In order to be considered a
Security Incident Response Team, the team MUST provide incident
response, as defined in section 1.1. by definition.

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

4.3.2

4.2.2 Constituency

A SIRT's constituency (as defined above) 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
users of a particular operating system.

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

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

People within the constituency have to learn that there is a Security
IRT for their purposes; the building of a trusted relationship with the
constituency is an on-going process which never ends.

4.3.3

4.2.3 Sponsoring organisation organization / affiliation

Any

The sponsoring organisations or affiliations, if they exist, must be
disclosed to constituents.  For example, organization, which authorises the CERT Coordination Centre's
sponsoring organisation is the Software Engineering Institute, Carnegie
Mellon University; actions of the sponsoring organisation for a SIRT within a large
coprporation would SIRT,
should be given next.  Defining the corporation itself.  SIRTs within smaller
organisations may have no sponsoring organisation, in which case they
should specify 'none.'

4.3.4 affiliation amounts to stating:
"Who is your God?".

4.2.4 Authority

SIRTs may not have authority to intervene in the operation of all the
systems within their perimeters.  Each perimeter.  They should identify the scope of its their
control as distinct from the perimeter of its their constituency; if other
SIRTs operate hierachically within this their perimeter, they these should be
identified.

For example, a corporate SIRT may have authority to force the
installation of software patches as the result of an incident.  Other
SIRTs, such as a national SIRT, may only be able to advise that such
patches should be installed.

4.4

4.3 Policies

4.4.1

4.3.1 Types of incidents and level of support

The types of incident which the team is authorised to address and the
level of support which the team will contribute in when assisting with each
type of incident should be summarized here in list form.  The Services
section (later) provides opportunity for more detailed definition.

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.

4.4.2

4.3.2 Co-operation and interaction with other organizations

This section should make explicit the related groups with which the SIRT
routinely interacts.  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.

Vendors:    The interaction here is in reporting vulnerabilities
discovered during an incident.  If your SIRT has relationships with
product vendors, these should be described here.    Larger vendors have their own SIRTs, but smaller vendors
may not.  In such cases a SIRT will need to work directly with a vendor.

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.

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

4.4.3 immediately
below.

4.3.3 Reporting and Disclosure

The default status of any and all security-related information which a
team receives can only be 'confidential,' but rigid adherence to this
makes the team a 'black hole.'  Its template should define what
information it will report or disclose, to whom, and under what
circumstances. 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 mave have reporting requirements
imposed by their sponsoring organisation, or they may be required by law
to report certain kinds of security incident.  Each team's template should specify any such restraints and requirements, restraints,
both to clarify clients' expectations and to inform other teams.  As an example of such
restraints, the Dutch equivalent of the U.S. Federal Bureau of
Investigation (FBI) has some kinds of documents which may NOT be
recorded electronically.

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

An explicit policy concerning disclosure to the Press can be helpful,
particularly in clarifying the expectations of a SIRT's constituency.

'Disclosure' includes:

  - reporting incidents within the constituency to other teams;

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

The reporting and disclosure policy should make clear who will be the
recipients of a SIRT's reports in each circumstance.  It should also
note whether the team will expect to deal through another Security IRT
or directly with a member 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, and should
list the recipients.

4.4.4

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

At the moment it is recommended 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 an
agreed password or phrase.

4.5

4.4 Services

Services should be defined in two sections, as listed below.

 * direct incident response
    + verification of the incident, i.e. help in determining whether
        the problem really is caused by a security compromise incident
    + technical analysis assistance and analysis to understand
      the nature of the compromise of a system
    + notification of other involved parties
    + guidance with eradication of the incident, i.e. steps
        to eliminate the compromise and prevent it recurring
    + guidance in recovery from the incident

 * optional
    + vulnerability analysis outside of direct incident activity
    + information provision
       - maintaining a vulnerability archive
       - developing and supplying patches and resolutions
    + tool development and distribution tools
    + education
    + audit and consulting
    + product evaluation

Security Incident response Teams may provide different kinds of services
to different sub-constituencies; this needs to be spelled out.  For
example, 'we are willing to provide direct incident response to other
communities as follows ..'

4.6

4.5 Incident reporting Forms

Samples of reporting forms used by the SIRT (or pointers to them) should
be included at this point in a template.  As an example, the CERT
Coordination Centre's incident reporting form is attached as Appendix C.

4.7 Disclaimers

Although

4.6 Disclaimers

Although the template 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 recommended.

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

In situations where the original version of a template 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 our German template
    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 for our
    operation.

5 Secondary Purposes of this Document

The primary audience of this document are the administrators responsible
for communities of users, i.e.  'constituencies.'  This section provides
some brief notes on what SIRT clients should expect of their teams.

An incident response team exists primarily to support the clients in its
constituency.  It is vital that those clients understand what they
should expect 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 the response team will be
contacting downstream sites.  Clients should certainly expect a SIRT to
provide the services they detail in their template.

An important aspect of incident response is the 'follow through' - every
incident should be investigated and appropriate actions taken.  Clients
should be encouraged by 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
they depend on can be greatly diminished.  As a minimum, clients need to
know that they should report security incidents, and know how and where
they should report them.

Individual users (i.e.  those who are not part of an organisation which
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 to SIRTs which were known when
this document was published.

6 Appendix A: Note on procedure definitions

Policies and statements of services in the template have to be
implemented as procedures, but descriptions of those procedures should
not be included in the template.

The following notes are intended to assist those seeking to form or 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 of reporting forms

* Internal
  + secure the team's infrastructure
  + protect information servers
  + protect sensitive data
  + define expiry of sensitive data
  + define disposal practice for sensitive data
  + establish methods for gathering and keeping statistics
  + establish 'knowledge base' of lessons learned from past incidents
  + create practical implementations of disclosure policies
  + document explicit practices for disclosure to the Press

The Site Security Handbook is a first resource to consult in securing a
team's infrastructure.  SIRT-specific security measures may evolve
later.

7 Appendix B: Known Incident Response Teams

FIRST is the Forum of Incident Response and Security Teams.  Information
about FIRST can be found via their World Wide Web home page:

   http://www.first.org/first

This page contains pointers to 'Team Contact Information' for SIRTs who
are FIRST members, and to 'Teams with WWW Servers.'

8 Appendix C: Sample Incident Reporting Form

The following Example:  a 'filled-in' template

<HTML>
<HEAD>
    <TITLE>SIRT Template for XYZ SIRT</TITLE>
</HEAD>

<P>
Note: no digital signature is currently available for this SIRT
Template.  We'll put one up as soon as the form which clients should use to report incidents
to technology is adopted
by XYZ Enterprises.
<P>

<XMP>

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

 1.1 Name of the CERT Co-ordination Centre:

version 3.0
February 28, 1996

                   CERT(sm) Coordination Center
                     Incident Reporting Form

The CERT Coordination Center (CERT/CC) has developed Team
        "XYZ-SIRT": the following
form in an effort 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 gather incident information.  We would appreciate
your completing October)

 1.4 Telephone Number
        +1 234 567 7890  (ask for the form below in 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 much detail soon as possible.  The
information  Our PGP public key will appear here
        as soon as it is available.

 1.9 Team Members
>>        Jane Doe of Computing Services is optional, but from our experience we have found that
having the answers to all 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 questions enables us to provide bottom of this Web page for this information.

 2.2 Locations where this Template May Be Found
        This template is available from the best
assistance.  Completing XYZ SIRT WWW
        site; its URL is
           http://www.xyz.org/THIS-INFORMATION-NOT-YET-AVAILABLE
>>      The template will be signed with the form also helps avoid delays while we get
back to you requesting XYZ-SIRT's private PGP
>>      key.  (WHAT TO DO?  Sign just the information we need in order to help you.
Sites template?  The whole Web
>>      page?  Try ASCII armor?  Or have told us, as well, that filling out the form has helped them
work through signature separate?)

        There are no plans for the incident.

Note automatic distribution of fresh
        copies of this template after updates; please make sure that
        you are using the latest version by checking our policy is Web site.

3. Charter
----------
 3.1 Mission Statement
        The purpose of the XYZ-SIRT is, first, to keep any information specific assist members of
        XYZ community in implementing proactive measures to your site
confidential unless we receive your permission reduce
        the risks of computer security incidents, and second, to release that
information.

Please feel free
        assist XYZ community in responding to duplicate any section as required.  Please return
this form to cert@cert.org.  If you are unable to email this form,
please send 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 FAX. this
        Department.  Also, because 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 be disconnected from the network should
        circumstances warrant it.

        The XYZ-SIRT expects to work cooperatively with system
        administrators and users at XYZ, and, insofar as
        possible, to avoid authoritarian relationships.  However,
        should circumstances warrant it, the XYZ-SIRT will appeal to
        Computing Services to exert its authority, direct or indirect,
        as necessary.

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

 4.1 Types of Incidents
        The CERT/CC FAX number XYZ-SIRT is

 +1 412 268 6989

Thank you authorized to address all types of computer
        security incidents which occur, or risk occurring, at
        XYZ Enterprises.

 4.2 Level of Support
        The level of support given by XYZ-SIRT will vary depending on
        the type and severity of the incident or issue, the type of
        consituent, the size of the user community affected, and the
        XYZ-SIRT's resources at 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 your cooperation 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, and help.
............................................................................

1.0. General while the XYZ-SIRT will endeavour to present
        information and assistance at a level appropriate to
        each person, the XYZ-SIRT cannot train system administrators,
        and 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.

 4.3 Disclosure of Information

     1.1. Incident number (to be assigned by
>>      &&&&&&&&&&&&&&&&&&&&
>>      Difficult section; not done yet.  Also, it overlaps heavily
>>      with the section below; I'm not sure of the best way to
>>      separate them.  Questions not yet addressed:
          - reporting incidents within the constituency to other teams;
          - 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 CERT/CC):  CERT#

     1.2. Reporting site information

          1.2.1.  Name (e.g., CERT Coordination Center):
          1.2.2.  Domain Name (e.g., cert.org):
          1.2.3.  Brief description of constituency;
          - feed-back to parties reporting incidents or vulnerabilities;
          - the organization:
          1.2.4.  Is your site an Internet Service Provider (Yes/No):

2.0. Contact Information

     2.1. Your provision of contact information

           2.1.1.  Name:
           2.1.2.  Email address:
           2.1.3.  Telephone number:
           2.1.4.  FAX number:
           2.1.5.  Pager number:
           2.1.6.  Home telephone number (for CERT/CC internal use
                    only):
           2.1.7.  Secure communication channel (e.g., PGP, PEM, DES,
                    secure telephone/FAX) [NOTE -- we will call relating to
                    obtain members of
            the secure communication channel
                    information] (Yes/No):

     2.2. Additional contact information (if available)

           2.2.1.  Name:
           2.2.2.  Email address:
           2.2.3.  Telephone number:
           2.2.4.  FAX number:
           2.2.5.  Pager number:
           2.2.6.  Home telephone number (for CERT/CC internal use
                    only):
           2.2.7.  Secure communication channel (Yes/No):

     2.3. Site security contact information (if applicable)

           2.3.1.  Name:
           2.3.2.  Email address:
           2.3.3.  Telephone number:
           2.3.4.  FAX number:
           2.3.5.  Pager number:
           2.3.6.  Home telephone number (for our internal use only):
           2.3.7.  Secure communication channel (Yes/No):

     2.4. Contact information for constituency, members of other site(s) involved in this
           incident (if available)

           2.4.1.  Site name:
           2.4.2.  Contact person name:
           2.4.3.  Email address:
           2.4.4.  Telephone number:
           2.4.5.  FAX number:
           2.4.6.  Pager number:
           2.4.7.  Home telephone number (for CERT/CC internal use
                    only):
           2.4.8.  Secure communication channel (Yes/No):

     2.5. Contact information for any constituencies, other incident response team(s)
           (IRTs) that has/have been notified (if available)

           2.5.1.  IRT name:
           2.5.2.  Constituency domain:
           2.5.3.  Contact person name:
           2.5.4.  Email address:
           2.5.5.  Telephone number:
           2.5.6.  FAX number:
           2.5.7.  Pager number:
           2.5.8.  Home telephone number (for CERT/CC internal use
                    only):
           2.5.9.  Secure communication channel (Yes/No):
           2.5.10. IRT reference number:

     2.6.
            SIRTs or law-enforcement agencies.
        Food for thought:
          Types of info:
             - Contact information info for any law enforcement agency(ies) 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
          has/have been notified (if available)

          2.6.1.  Law enforcement agency name:
          2.6.2.  Contact person name:
          2.6.3.  Email address:
          2.6.4.  Telephone number:
          2.6.5.  FAX number:
          2.6.6.  Pager number:
          2.6.7.  Home telephone number (for CERT/CC internal use
                   only):
          2.6.8.  Secure communication channel (Yes/No):
          2.6.9. user accounts were compromised
                 - Description of incident
                     - Identity of affected systems
                     - Identity of affected people
                     - Identity of perpetrator
          Recipients 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 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 agency reference number:

3.0. Contacting Sites Involved

     3.1. We ask that reporting sites contact

 4.4 Cooperation and Interaction with Other Entities
        - Other sites:
            The XYZ-SIRT will cooperate with other sites involved in SIRTs (security
            incident activity.  Please let us know if you need assistance
  in obtaining contact information for the site(s) involved.

          When contacting the response teams) and with system administrators at
            other sites, we would very much
  appreciate a cc to the "cert@cert.org" alias.  This helps
  us identify connections between incidents and understand extent that their bona fide can be
            verified.  Should provincial or national SIRTs be
            constituted, XYZ-SIRT will explore the scope possibility of intruder activity.  We would also appreciate
  your including our incident number in the subject line peer
            relationships with them.  The possibility of
  any correspondence relating to this incident if one
  has been assigned (see item 1.1.).

          If you are unable to contact the involved sites, please get
          in touch peer
            relationships with us close neighbours 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 information to discuss how we can assist you.

     3.2. Disclosure any body outside XYZ (aside from
            law enforcement agencies), XYZ-SIRT will provide such
            information -- may we give when the following types good of the community justifies it.
            However, unless identifying information is needed to

          3.2.1. the sites involved in this track
            an incident

                  3.2.1.1. your domain (Yes/No):
                  3.2.1.2. your host(s) involved (Yes/No):
                  3.2.1.3. your contact in progress, such information (Yes/No):

          3.2.2. incident response teams, for sites 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
                 constituencies involved products.  In aid of
            this, a vulnerability discovered in this incident

                  3.2.2.1. your domain (Yes/No):
                  3.2.2.2. your host(s) involved (Yes/No):
                  3.2.2.3. your contact information (Yes/No):

          3.2.3. law enforcement agency(ies) if there is such a legal
                 investigation
                  3.2.3.1. your domain (Yes/No):
                  3.2.3.2. your host(s) involved (Yes/No):
                  3.2.3.3. your contact information (Yes/No):

4.0. Host Information

     4.1. Host(s) involved 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 your site.  Please provide information
          on XYZ and the local police; interest
            has been expressed by all host(s) involved parties in formalising these
            relationships.  Any progress
            made in that area will be reflected in this incident at section.
            In the meantime, authorized and unauthorized users of the
            XYZ Computing Facilities should be aware that the time
            XYZ-SIRT will cooperate fully with law enforcement
            agencies in detecting, reporting, documenting, and
            prosecuting violations of the
          incident (one entry per host please)

          4.1.1.  Hostname:
          4.1.2.  IP address(es):
          4.1.3.  Vendor hardware, OS, and version:
          4.1.4.  Security patches applied/installed as currently
                   recommended by law; users concerned about
            confidentiality are referred to the vendor XYZ "Policy on
            Computing Facilities".
        - The Press:
            The XYZ-SIRT will not interect directly with the Press.
            If necessary, information will be provided to the
            XYZ Public Relations Department, and to the CERT/CC
                   (Yes/No/Unknown):
          4.1.5.  Function(s)
            Customer Relations group of the involved host

                  4.1.5.1. Router (Yes/No):
                  4.1.5.2. Terminal server (Yes/No):
                  4.1.5.3. Other (e.g. mail hub, information server,
                           DNS [external or internal], etc.):

          4.1.6.  Where on 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 network is Computer
            Resources Committee; these bodies will be charged with
            maintaining the involved host (e.g.
                   backbone, subnet):
          4.1.7.  Nature 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 at risk stripped (except
            where permission has been obtained from the affected
            parties).  There is no obligation on the involved
                   host (e.g. router configuration, proprietary,
                   personnel, financial, etc.):
          4.1.8.  Timezone part of the involved host (relative
            XYZ-SIRT to report incidents to GMT):
          4.1.9.  In the attack, was community, though it
            may choose to do so; in particular, it is likely that the host
            XYZ-SIRT will inform all affected parties of the source, ways in
            which they were affected.
        - The public at large:
            In general, no particular efforts will be made to
            communicate with the victim,
                   or both:
          4.1.10. Was this host compromised as a result of this attack
                   (Yes/No):

     4.2. Host(s) involved public at other other sites (one entry per host
          please)

          4.2.1. Hostname:
          4.2.2. IP address(es):
          4.2.3. Vendor hardware, OS, large, though the XYZ-SIRT
            recognizes that, for all intents and version:
          4.2.4. Has purposes, information
            made available to the site been notified (Yes/No):
          4.2.5. In XYZ community is in effect
            made available to the attack, was community at large, and will tailor
            the host information in consequence.
        - The computer security community:
            While members of XYZ-SIRT may participate in discussions
            within the source, computer security community, such as newsgroups,
            mailing lists (including the victim, or
                  both:
          4.2.6. Was this host compromised full-disclosure list
            "bugtraq"), and conferences, they will treat such forums
            as a result though they were the public at large.  While technical
            issues (including vulnerabilities) may be discussed to any
            level of this attack
                  (Yes/No):

5.0. Incident Categories

     5.1. Please mark as many categories as are appropriate detail, any examples taken from XYZ-SIRT
            experience will be disguised to
          this incident

          5.1.1.  Probe(s):
          5.1.2.  Scan(s):
          5.1.3.  Prank:
          5.1.4.  Scam:
          5.1.5.  Email Spoofing:
          5.1.6.  Email bombardment:

                  5.1.6.1. was this denial-of-service attack successful
                           (Yes/No):

          5.1.7.  Sendmail attack:

                  5.1.7.1. did this attack result in a compromise
                           (Yes/No):

          5.1.8.  Break-in

                  5.1.8.1. Intruder gained root access (Yes/No):
                  5.1.8.2. Intruder installed Trojan horse program(s)
                           (Yes/No):
                  5.1.8.3. Intruder installed packet sniffer (Yes/No):

                           5.1.8.3.1. What was avoid identifying the full pathname(s) of
            affected parties.

        In the sniffer output file(s):
                           5.1.8.3.2. How many sessions did paragraphs above, the sniffer
                                      log (use "grep -c 'DATA'
                                      <filename>" "affected parties" refers to obtain this
                                      information):

                  5.1.8.4.  NIS (yellow pages) attack (Yes/No):
                  5.1.8.5.  NFS attack (Yes/No):
                  5.1.8.6.  TFTP attack (Yes/No):
                  5.1.8.7.  FTP attack (Yes/No):
                  5.1.8.8.  Telnet attack (Yes/No):
                  5.1.8.9.  Rlogin or rsh attack (Yes/No):
                  5.1.8.10. Cracked password (Yes/No):
                  5.1.8.11. Easily-guessable password (Yes/No):

          5.1.9.  Anonymous FTP abuse (Yes/No):
          5.1.10. IP spoofing (Yes/No):
          5.1.11. Product vulnerability (Yes/No):

                  5.1.11.1. Vulnerability exploited:

          5.1.12. Configuration error (Yes/No):

                  5.1.12.1. Type of configuration error:

          5.1.13. Misuse of host(s) resources (Yes/No):

          5.1.14. Worm (Yes/No):
          5.1.15. Virus (Yes/No):
          5.1.16. Other (please specify):

6.0. Security Tools

     6.1. At the time
        legitimate owners, operators, and users of the incident, were you any using the following
          security tools (Yes/No; How often)

          Network Monitoring tools
             6.1.1.  Argus:
             6.1.2.  netlog (part relevant
        computing facilities.  It does not refer to unauthorized
        users, including otherwise authorized users making
        unauthorized usage of the TAMU Security Package):

          Authentication/Password tools
             6.1.3.  Crack:
             6.1.4.  One-time passwords:
             6.1.5.  Proactive password checkers:
             6.1.6.  Shadow passwords:
             6.1.7.  Kerberos:

          Service filtering tools
             6.1.8.  Host access control via modified daemons or
                     wrappers:
             6.1.9.  Drawbridge (part a facility; such intruders may have no
        expectation of confidentiality from the TAMU Security Package):
             6.1.10. Firewall (what product):
             6.1.11. TCP access control using packet filtering:

          Tools XYZ-SIRT.  They may or
        may not have legal rights to scan hosts for known vulnerabilities
             6.1.12. ISS:
             6.1.13. SATAN:

          Multi-purpose tools
             6.1.14. C2 security:
             6.1.15. COPS:
             6.1.16. Tiger (part confidentiality; such rights will
        of the TAMU Security Package):

          File Integrity Checking tools
             6.1.17. MD5:
             6.1.18. Tripwire:

          Other tools
             6.1.19. lsof:
             6.1.20. cpm:
             6.1.21. smrsh:
             6.1.22. append-only file systems:

          Additional tools (please specify):

     6.2. At the time course be respected where they exist.

 4.5 Communication and Authentication
        In view of the incident, which types of information that the following logs were
          you using, if any (Yes/No)
          6.2.1. syslog:
          6.2.2. utmp:
          6.2.3. wtmp:
          6.2.4. TCP wrapper:
          6.2.5. process accounting:

     6.3. What do you believe 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 reliability and integrity 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 logs (e.g., are purposes.

        Where it is necessary to establish trust, for example before
        relying on information given to the logs stored offline XYZ-SIRT, or on a
          different host):

7.0. Detailed description of before
        disclosing confidential information, the incident

     7.1. Please complete in as much detail as possible

          7.1.1.  Date identity and duration bona
        fide of incident:
          7.1.2.  How you discovered the incident:
          7.1.3.  Method used other party will be ascertained to gain access a reasonable
        degree of trust.  Within XYZ, and with known
        neighbour 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 affected host(s):
          7.1.4.  Details use of vulnerabilities exploited
        WHOIS and other Internet registration information, etc, along
        with telephone call-back or e-mail mail-back to ensure that are
        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 Points of Customer Contact
        The preferred method for contacting the XYZ-SIRT will be
        e-mail.  If this is not addressed in previous sections:
          7.1.5.  Other aspects of possible, or not advisable for
        security reasons, the "attack":
          7.1.6.  Hidden files/directories:
          7.1.7.  The source XYZ-SIRT can be reached by telephone
        during regular office hours.

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

 5.1 Incident Response
>>      &&&&&&&&&&&&&&&&&&&&&&&7
>>      This section requires a lot of thought.

 5.2 Proactive Activities
        The XYZ-SIRT will coordinate and maintain the attack (if known):
          7.1.8.  Steps taken to address the incident (e.g., binaries
                   reinstalled, patches applied):
          7.1.9.  Planned steps following
        services to address the incident (if any):
          7.1.10. Do you plan to start using any extent possible depending on its resources:
           - Information services
              - List of the tools listed
                   above in question 6.0 (please list tools expected
                   to use):
          7.1.11. Other:

     7.2. Please append any log information or directory listings departmental security contacts, administrative
                and
           timezone technical.
              - Mailing lists to inform security contacts of new
                information (relative relevant to GMT).

     7.3. Please indicate if any their computing environments.
              - Repository of the following were left on your
           system by the intruder (Yes/No):

          7.3.1. intruder tool output (such as packet sniffer output
                  logs):
          7.3.2. tools/scripts to exploit vulnerabilities:
          7.3.3. source code programs (such as Trojan horse programs,
                  sniffer programs):
          7.3.4. binary code programs (such as Trojan horse programs,
                  sniffer programs):
          7.3.5. vendor-provided and other files:

          If you answered yes to any security-related
                patches for various operating systems.
              - Repository of the last 5 questions, please
          call the CERT/CC hotline (+1 412 268 7090) security tools for instructions
          on uploading files to us use by FTP.  Thanks.

     7.4. What assistance would you like from 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 CERT/CC?

Copyright 1996 Carnegie Mellon University.
This form may
                XYZ will be reproduced reported and distributed without permission
provided it is used archived.
           - Auditing services
              - Central file integrity checking service for noncommercial purposes 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 CERT
Coordination Center same level of
                security, but it is acknowledged.

CERT important to know which ones are
                reasonably secure and which are not.
           - 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 for XYZ-SIRT advice?
>>  &&&&&&&&&&&&&&&&&&&7
>>  WILL NEED XYZ LEGAL COUNSEL ON THIS?

8. Additional Information
-------------------------

The version of this template published in this RFC will undoubtedly be
out of date by the time you see it; it is intended as an example only.
Please pick up a service mark fresh copy from our Web site if you actually need
information about XYZ-SIRT.

History of Carnegie Mellon University. this template:

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

</XMP>

</BODY>
</HTML>

9 Security Considerations

This document discusses the operation of Security Incident Response
Teams, and is therefore not directly concerned with the security of
protocols or network systems themselves.

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 Editor's Author's Address

    Nevil Brownlee
    ITSS Technology Developmenta Development
    The University of Auckland

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