RFC relevance of computer

As per Relevance of the word computer, we have this rfc below:

Network Working Group N.
Request for Comments: 2350 The University of
BCP: 21 E.
Category: Best Current Practice Sun
June 1998

Expectations for Computer Security Incident

Status of this

This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited

Copyright

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

The purpose of this document is to express the general
community's expectations of Computer Security Incident Response
(CSIRTs). It is not possible to define a set of requirements
would be appropriate for all teams, but it is possible and helpful
list and describe the general set of topics and issues which are
concern and interest to constituent communities

CSIRT constituents have a legitimate need and right to
understand the policies and procedures of 'their' Computer
Incident Response Team. One way to support this understanding is
supply detailed information which users may consider, in the form
a formal template completed by the CSIRT. An outline of such
template and a filled in example are provided

Table of

1 Introduction ....................................................2
2 Scope............................................................4
2.1 Publishing CSIRT Policies and Procedures ....................4
2.2 Relationships between different CSIRTs ......................5
2.3 Establishing Secure Communications ..........................6
3 Information, Policies and Procedures.............................7
3.1 Obtaining the Document.......................................8
3.2 Contact Information .........................................9
3.3 Charter ....................................................10
3.3.1 Mission Statement.....................................10
3.3.2 Constituency..........................................10

Brownlee & Guttman Best Current Practice [Page 1]

RFC 2350 Expectations for Computer Security Incident Response June 1998

3.3.3 Sponsoring Organization / Affiliation.................11
3.3.4 Authority.............................................11
3.4 Policies ...................................................11
3.4.1 Types of Incidents and Level of Support...............11
3.4.2 Co-operation, Interaction and Disclosure
Information...........................................12
3.4.3 Communication and Authentication......................14
3.5 Services ...................................................15
3.5.1 Incident Response ....................................15
3.5.1.1 Incident Triage ..............................15
3.5.1.2 Incident Coordination ........................15
3.5.1.3 Incident Resolution...........................16
3.5.2 Proactive Activities .................................16
3.6 Incident Reporting Forms ...................................16
3.7 Disclaimers ................................................17
Appendix A: Glossary of Terms ....................................18
Appendix B: Related Material .....................................20
Appendix C: Known Computer Security Incident Response Teams ......21
Appendix D: Outline for CSIRT Template ...........................22
Appendix E: Example - 'filled-in' Template for a CSIRT ...........23
4 Acknowlegements ................................................36
5 References .....................................................36
6 Security Considerations ........................................36
7 Authors' Addresses .............................................37
8 Full Copyright Statement .......................................38

1

The GRIP Working Group was formed to create a document that
the community's expectations of computer security incident
teams (CSIRTs). Although the need for such a document originated
the general Internet community, the expectations expressed
also closely match those of more restricted communities

In the past there have been misunderstandings regarding what
expect from CSIRTs. The goal of this document is to provide
framework for presenting the important subjects (related to
response) that are of concern to the community

Before continuing, it is important to clearly understand what
meant by the term "Computer Security Incident Response Team."
the purposes of this document, a CSIRT is a team that performs
coordinates, and supports the response to security incidents
involve sites within a defined constituency (see Appendix A for
more complete definition). Any group calling itself a CSIRT for
specific constituency must therefore react to reported
incidents, and to threats to "their" constituency in ways which
specific community agrees to be in its general interest

Brownlee & Guttman Best Current Practice [Page 2]

RFC 2350 Expectations for Computer Security Incident Response June 1998

Since it is vital that each member of a constituent community be
to understand what is reasonable to expect of their team, a
should make it clear who belongs to their constituency and define
services the team offers to the community. Additionally, each
should publish its policies and operating procedures. Similarly
these same constituents need to know what is expected of them
order for them to receive the services of their team. This
that the team also publish how and where to report incidents

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

It must be emphasized that without active participation from users
the effectiveness of the CSIRT's services can be greatly diminished
This is particularly the case with reporting. At a minimum,
need to know that they should report security incidents, and know
and to where they should report them

Many computer security incidents originate outside local
boundaries and affect inside sites, others originate inside the
community and affect hosts or users on the outside. Often
therefore, the handling of security incidents will involve
sites and potentially multiple CSIRTs. Resolving these
will require cooperation between individual sites and CSIRTs,
between CSIRTs

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

The rest of this document describes the set of topics and issues
CSIRTs need to elaborate for their constituents. However, there is
attempt to specify the "correct" answer to any one topic area
Rather, each topic is discussed in terms of what that topic means

Chapter two provides an overview of three major areas:
publishing of information by a response team, the definition of
response team's relationship to other response teams, and the
for secure communications. Chapter three describes in detail all
types of information that the community needs to know about
response team

For ease of use by the community, these topics are condensed into
outline template found in Appendix D. This template can be used
constituents to elicit information from their CSIRT

Brownlee & Guttman Best Current Practice [Page 3]

RFC 2350 Expectations for Computer Security Incident Response June 1998

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

2

The interactions between an incident response team and
constituent community response team require first that the
understand the policies and procedures of the response team. Second
since many response teams collaborate to handle incidents,
community must also understand the relationship between
response team and other teams. Finally, many interactions will
advantage of existing public infrastructures, so the community
to know how those communications will be protected. Each of
subjects will be described in more detail in the following
sections

2.1 Publishing CSIRT Policies and

Each user who has access to a Computer Security Incident
Team should know as much as possible about the services of
interactions with this team long before he or she actually
them

A clear statement of the policies and procedures of a CSIRT helps
constituent understand how best to report incidents and what
to expect afterwards. Will the CSIRT assist in resolving
incident? Will it provide help in avoiding incidents in the future
Clear expectations, particularly of the limitations of the
provided by a CSIRT, will make interaction with it more efficient
effective

There are different kinds of response teams: some have very
constituencies (e.g., CERT Coordination Center and the Internet),
others have more bounded constituencies (e.g., DFN-CERT, CIAC),
still others have very restricted constituencies (e.g.,
response teams, corporate response teams). Regardless of the type
response team, the constituency supported by it must be
about the team's policies and procedures. Therefore, it is
that response teams publish such information to their constituency

A CSIRT should communicate all necessary information about
policies and services in a form suitable to the needs of
constituency. It is important to understand that not all
and procedures need be publicly available. For example, it is
necessary to understand the internal operation of a team in order
interact with it, as when reporting an incident or receiving
on how to analyze or secure one's systems

Brownlee & Guttman Best Current Practice [Page 4]

RFC 2350 Expectations for Computer Security Incident Response June 1998

In the past, some teams supplied a kind of Operational Framework
others provided a Frequently Asked Questions list (FAQ), while
others wrote papers for distribution at user conferences or
newsletters

We recommend that each CSIRT publish its guidelines and procedures
its own information server (e.g. a World Wide Web server).
would allow constituents to easily access it, though the
remains of how a constituent can find his or her team; people
the constituency have to discover that there is a CSIRT "at
disposal."

It is foreseen that completed CSIRT templates will soon
searchable by modern search engines, which will aid in
information about the existence of CSIRTs and basic
required to approach them

It would be very useful to have a central repository containing
the completed CSIRT templates. No such repository exists at the
of writing, though this might change in the future

Regardless of the source from which the information is retrieved,
user of the template must check its authenticity. It is
recommended that such vital documents be protected by
signatures. These will allow the user to verify that the
was indeed published by the CSIRT and that it has not been
with. This document assumes the reader is familiar with the
use of digital signatures to determine whether a document
authentic

2.2 Relationships between different

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

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

Inter-CSIRT interactions could include asking other teams for advice
disseminating knowledge of problems, and working cooperatively
resolve a security incident affecting one or more of the CSIRTs
constituencies

Brownlee & Guttman Best Current Practice [Page 5]

RFC 2350 Expectations for Computer Security Incident Response June 1998

In establishing relationships to support such interactions,
must decide what kinds of agreements can exist between them so as
share yet safeguard information, whether this relationship can
disclosed, and if so to whom

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

Although the establishment of such relationships is very
and affects the ability of a CSIRT to support its constituency, it
up to the teams involved to decide about the details. It is
the scope of this document to make recommendations for this process
However, the same set of information used to set expectations for
user community regarding sharing of information will help
parties to understand the objectives and services of a
CSIRT, supporting a first contact

2.3 Establishing Secure

Once one party has decided to share information with another party
or two parties have agreed to share information or work together -
required for the coordination of computer security incident
- all parties involved need secure communications channels. (In
context, "secure" refers to the protected transmission of
shared between different parties, and not to the appropriate use
the information by the parties.)

The goals of secure communication are

- Confidentiality
Can somebody else access the content of the communication

- Integrity
Can somebody else manipulate the content of the communication

- Authenticity
Am I communicating with the "right" person

It is very easy to send forged e-mail, and not hard to establish
(false) identity by telephone. Cryptographic techniques,
example Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM)
provide effective ways of securing e-mail. With the
equipment it is also possible to secure telephone communication.
before using such mechanisms, both parties need the "right
infrastructure, which is to say preparation in advance. The
important preparation is ensuring the authenticity of

Brownlee & Guttman Best Current Practice [Page 6]

RFC 2350 Expectations for Computer Security Incident Response June 1998

cryptographic keys used in secure communication

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

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

Communication is critical to all aspects of incident response.
team can best support the use of the above-mentioned techniques
gathering all relevant information, in a consistent way.
requirements (such as calling a specific number to check
authenticity of keys) should be clear from the start.
templates provide a standardized vehicle for delivering
information

It is beyond the scope of this document to address the technical
administrative problems of secure communications. The point is
response teams must support and use a method to secure
communications between themselves and their constituents (or
response teams). Whatever the mechanism is, the level of
it provides must be acceptable to the constituent community

3 Information, Policies and

In chapter 2 it was mentioned that the policies and procedures of
response team need to be published to their constituent community
In this chapter we will list all the types of information that
community needs to receive from its response team. How
information is communicated to a community will differ from team
team, as will the specific information content. The intent here
to clearly describe the various kinds of information that
constituent community expects from its response team

To make it easier to understand the issues and topics relevant to
interaction of constituents with "their" CSIRT, we suggest that
CSIRT publish all information, policies, and procedures
its constituency as a document, following the template given
Appendix D. The template structure arranges items, making it easy
supply specific information; in Appendix E we provide an example of
filled-out template for the fictitious XYZ University. While
recommendations are made as to what a CSIRT should adopt for
policy or procedures, different possibilities are outlined to

Brownlee & Guttman Best Current Practice [Page 7]

RFC 2350 Expectations for Computer Security Incident Response June 1998

some examples. The most important thing is that a CSIRT have
policy and that those who interact with the CSIRT be able to
and understand it

As always, not every aspect for every environment and/or team can
covered. This outline should be seen as a suggestion. Each
should feel free to include whatever they think is necessary
support its constituency

3.1 Obtaining the

Details of a CSIRT change with time, so the completed template
indicate when it was last changed. Additionally, information
be provided concerning how to find out about future updates.
this, it is inevitable that misunderstandings and misconceptions
arise over time; outdated documents can do more harm than good

- Date of last update This should be sufficient to
anyone interested to evaluate
currency of the template

- Distribution list Mailing lists are a
mechanism to distribute up-to-
information to a large number
users. A team can decide to use
own or an already existing list
notify users whenever the
changes. The list might normally
groups the CSIRT has
interactions with

Digital signatures should be
for update messages sent by a CSIRT

- Location of the document The location where a current
of the document is accessible
a team's online information services
Constituents can then easily
more about the team and check
recent updates. This online
should also be accompanied by
digital signature

Brownlee & Guttman Best Current Practice [Page 8]

RFC 2350 Expectations for Computer Security Incident Response June 1998

3.2 Contact

Full details of how to contact the CSIRT should be listed here
although this might be very different for different teams;
example, some might choose not to publicize the names of their
members. No further clarification is given when the meaning of
item can be assumed

- Name of the

- Mailing

- Time zone This is useful for
incidents which cross time zones

- Telephone

- Facsimile

- Other telecommunication Some teams might provide
voice communication (e.g. STU III).

- Electronic mail

- Public keys and encryption The use of specific
depends on the ability of
communication partners to
access to programs, keys and so on
Relevant information should
given to enable users to
if and how they can make use
encrypted communication
interacting with the CSIRT
- Team

- Operating Hours The operating hours and
schedule should be provided here
Is there a 24 hour hotline

- Additional Contact Info Is there any specific
contact info

More detailed contact information can be provided. This
include different contacts for different services, or might be a
of online information services. If specific procedures for access
some services exist (for example addresses for mailing
requests), these should be explained here

Brownlee & Guttman Best Current Practice [Page 9]

RFC 2350 Expectations for Computer Security Incident Response June 1998

3.3

Every CSIRT must have a charter which specifies what it is to do,
the authority under which it will do it. The charter should
at least the following items

- Mission
-
- Sponsorship /
-

3.3.1 Mission

The mission statement should focus on the team's core activities
already stated in the definition of a CSIRT. In order to
considered a Computer Security Incident Response Team, the team
support the reporting of incidents and support its constituency
dealing with incidents

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

3.3.2

A CSIRT's constituency can be determined in any of several ways.
example it could be a company's employees or its paid subscribers,
it could be defined in terms of a technological focus, such as
users of a particular operating system

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

If a CSIRT decides not to disclose its constituency, it
explain the reasoning behind this decision. For example, for-
CSIRTs will not list their clients but will declare that they
a service to a large group of customers that are kept
because of the clients' contracts

Constituencies might overlap, as when an ISP provides a CSIRT
delivers services to customer sites that also have CSIRTs.
Authority section of the CSIRT's description (see below) should
such relationships clear

Brownlee & Guttman Best Current Practice [Page 10]

RFC 2350 Expectations for Computer Security Incident Response June 1998

3.3.3 Sponsoring Organization /

The sponsoring organization, which authorizes the actions of
CSIRT, should be given next. Knowing this will help the users
understand the background and set-up of the CSIRT, and it is
information for building trust between a constituent and a CSIRT

3.3.4

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

A CSIRT may or may not have the authority to intervene in
operation of all of the systems within its perimeter. It
identify the scope of its control as distinct from the perimeter
its constituency. If other CSIRTs operate hierarchically within
perimeter, this should be mentioned here, and the related
identified

Disclosure of a team's authority may expose it to claims
liability. Every team should seek legal advice on these matters
(See section 3.7 for more on liability.)

3.4

It is critical that Incident Response Teams define their policies
The following sections discuss communication of these policies to
constituent community

3.4.1 Types of Incidents and Level of

The types of incident which the team is able to address, and
level of support which the team will offer when responding to
type of incident, should be summarized here in list form.
Services section (see below) provides the opportunity to give
detailed descriptions, and to address non-incident-related topics

The level of support may change depending on factors such as
team's workload and the completeness of the information available
Such factors should be outlined and their impact should be explained
As a list of known types of incidents will be incomplete with
to possible or future incidents, a CSIRT should also give
background on the "default" support for incident types not
mentioned

Brownlee & Guttman Best Current Practice [Page 11]

RFC 2350 Expectations for Computer Security Incident Response June 1998

The team should state whether it will act on information it
about vulnerabilities which create opportunities for
incidents. A commitment to act on such information on behalf of
constituency is regarded as an optional proactive service
rather than a core service requirement for a CSIRT

3.4.2 Co-operation, Interaction and Disclosure of

This section should make explicit which related groups the
routinely interacts with. Such interactions are not
related to the computer security incident response provided, but
used to facilitate better cooperation on technical topics
services. By no means need details about cooperation agreements
given out; the main objective of this section is to give
constituency a basic understanding of what kind of interactions
established and what their purpose is

Cooperation between CSIRTs can be facilitated by the use of
ticket number assignment combined with explicit handoff procedures
This reduces the chance of misunderstandings, duplications of effort
assists in incident tracking and prevents 'loops' in communication

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

Related groups a CSIRT will interact with are listed below

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

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

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

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

Brownlee & Guttman Best Current Practice [Page 12]

RFC 2350 Expectations for Computer Security Incident Response June 1998

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

- Acting on reports of incidents from outside the constituency

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

- Feedback to parties reporting incidents or vulnerabilities

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

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

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

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

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

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

Brownlee & Guttman Best Current Practice [Page 13]

RFC 2350 Expectations for Computer Security Incident Response June 1998

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

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

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

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

3.4.3 Communication and

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

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

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

Brownlee & Guttman Best Current Practice [Page 14]

RFC 2350 Expectations for Computer Security Incident Response June 1998

published, though their existence may be

3.5

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

3.5.1 Incident

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

3.5.1.1 Incident

Incident triage usually includes

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

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

3.5.1.2 Incident

Incident Coordination normally includes

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

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

Brownlee & Guttman Best Current Practice [Page 15]

RFC 2350 Expectations for Computer Security Incident Response June 1998

3.5.1.3 Incident

Usually additional or optional, incident resolution
include

- Technical Assistance This may include analysis
compromised systems

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

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

3.5.2. Proactive

Usually additional or optional, proactive services might include

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

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

- Education and

- Product

- Site security auditing and

3.6 Incident Reporting

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

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

Brownlee & Guttman Best Current Practice [Page 16]

RFC 2350 Expectations for Computer Security Incident Response June 1998

incidents

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

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

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

3.7

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

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

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

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

Brownlee & Guttman Best Current Practice [Page 17]

RFC 2350 Expectations for Computer Security Incident Response June 1998

Appendix A: Glossary of

This glossary defines terms used in describing security incidents
Computer Security Incident Response Teams. Only a limited list
included. For more definitions please refer to other sources,
example to the Internet User's Glossary [RFC 1983].

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

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

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

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

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

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

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

In order to be considered a CSIRT, a team must

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

Brownlee & Guttman Best Current Practice [Page 18]

RFC 2350 Expectations for Computer Security Incident Response June 1998

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

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

Vendor
A 'vendor' is any entity that produces networking or
technology, and is responsible for the technical content of
technology. Examples of 'technology' include hardware (
computers, routers, switches, etc.), and software (
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
Provider (ISP) might supply routers to each of its customers,
the 'vendor' is the manufacturer, since the manufacturer,
than the ISP, is the entity responsible for the technical
of the router

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

Brownlee & Guttman Best Current Practice [Page 19]

RFC 2350 Expectations for Computer Security Incident Response June 1998

Appendix B: Related

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

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

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

Some especially interesting documents in relation to this
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,
CSIRT of SURFnet (network provider in the Netherlands).

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

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

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

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

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

Brownlee & Guttman Best Current Practice [Page 20]

RFC 2350 Expectations for Computer Security Incident Response June 1998

Appendix C: Known Computer Security Incident Response

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

- http://www.first.org

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

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

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

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

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

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

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

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

Brownlee & Guttman Best Current Practice [Page 21]

RFC 2350 Expectations for Computer Security Incident Response June 1998

Appendix D: Outline for CSIRT

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

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

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

3.
3.1 Mission
3.2
3.3 Sponsorship and/or
3.4

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

5.
5.1 Incident
5.1.1. Incident
5.1.2. Incident
5.1.3. Incident
5.2 Proactive

6. Incident Reporting

7.

Brownlee & Guttman Best Current Practice [Page 22]

RFC 2350 Expectations for Computer Security Incident Response June 1998

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

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

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

1. About this

1.1 Date of Last

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

1.2 Distribution List for

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

1.3 Locations where this Document May Be

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

1.4 Authenticating this

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

Brownlee & Guttman Best Current Practice [Page 23]

RFC 2350 Expectations for Computer Security Incident Response June 1998

2. Contact

2.1 Name of the

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

2.2

XYZ-
XYZ University, Computing Services
12345 Rue
UniversityTown,
Canada H0H 0H

2.3 Time

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

2.4 Telephone

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

2.5 Facsimile

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

2.6 Other

None available

2.7 Electronic Mail

This is a mail alias that relays
to the human(s) on duty for the XYZ-CERT

2.8 Public Keys and Other Encryption

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

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

Brownlee & Guttman Best Current Practice [Page 24]

RFC 2350 Expectations for Computer Security Incident Response June 1998

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

2.9 Team

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

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

2.10 Other

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

2.11 Points of Customer

The preferred method for contacting the XYZ-CERT is
e-mail at ; e-mail sent to this
will "biff" the responsible human, or be
forwarded to the appropriate backup person, immediately.
you require urgent assistance, put "urgent" in your
line

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

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

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

Brownlee & Guttman Best Current Practice [Page 25]

RFC 2350 Expectations for Computer Security Incident Response June 1998

3.

3.1 Mission

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

3.2

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

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

3.3 Sponsorship and/or

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

3.4

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

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

Brownlee & Guttman Best Current Practice [Page 26]

RFC 2350 Expectations for Computer Security Incident Response June 1998

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

4.

4.1 Types of Incidents and Level of

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

The level of support given by XYZ-CERT will vary depending
the type and severity of the