Network Working Group N. Brownlee
Request for Comments: 2350 The University of Auckland
BCP: 21 E. Guttman
Category: Best Current Practice Sun Microsystems
June 1998
Expectations for Computer Security Incident Response
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
The purpose of this document is to express the general Internet
community's expectations of Computer Security Incident Response Teams
(CSIRTs). It is not possible to define a set of requirements that
would be appropriate for all teams, but it is possible and helpful to
list and describe the general set of topics and issues which are of
concern and interest to constituent communities.
CSIRT constituents have a legitimate need and right to fully
understand the policies and procedures of 'their' Computer Security
Incident Response Team. One way to support this understanding is to
supply detailed information which users may consider, in the form of
a formal template completed by the CSIRT. An outline of such a
template and a filled in example are provided.
Table of Contents
1 Introduction ....................................................2
2 Scope............................................................4
2.1 Publishing CSIRT Policies and Procedures ....................4
2.2 Relationships between different CSIRTs ......................5
2.3 Establishing Secure Communications ..........................6
3 Information, Policies and Procedures.............................7
3.1 Obtaining the Document.......................................8
3.2 Contact Information .........................................9
3.3 Charter ....................................................10
3.3.1 Mission Statement.....................................10
3.3.2 Constituency..........................................10
Brownlee & Guttman Best Current Practice [Page 1]
RFC 2350 Expectations for Computer Security Incident Response June 1998
3.3.3 Sponsoring Organization / Affiliation.................11
3.3.4 Authority.............................................11
3.4 Policies ...................................................11
3.4.1 Types of Incidents and Level of Support...............11
3.4.2 Co-operation, Interaction and Disclosure of
Information...........................................12
3.4.3 Communication and Authentication......................14
3.5 Services ...................................................15
3.5.1 Incident Response ....................................15
3.5.1.1 Incident Triage ..............................15
3.5.1.2 Incident Coordination ........................15
3.5.1.3 Incident Resolution...........................16
3.5.2 Proactive Activities .................................16
3.6 Incident Reporting Forms ...................................16
3.7 Disclaimers ................................................17
Appendix A: Glossary of Terms ....................................18
Appendix B: Related Material .....................................20
Appendix C: Known Computer Security Incident Response Teams ......21
Appendix D: Outline for CSIRT Template ...........................22
Appendix E: Example - 'filled-in' Template for a CSIRT ...........23
4 Acknowlegements ................................................36
5 References .....................................................36
6 Security Considerations ........................................36
7 Authors' Addresses .............................................37
8 Full Copyright Statement .......................................38
1 Introduction
The GRIP Working Group was formed to create a document that describes
the community's expectations of computer security incident response
teams (CSIRTs). Although the need for such a document originated in
the general Internet community, the expectations expressed should
also closely match those of more restricted communities.
In the past there have been misunderstandings regarding what to
expect from CSIRTs. The goal of this document is to provide a
framework for presenting the important subjects (related to incident
response) that are of concern to the community.
Before continuing, it is important to clearly understand what is
meant by the term "Computer Security Incident Response Team." For
the purposes of this document, a CSIRT is a team that performs,
coordinates, and supports the response to security incidents that
involve sites within a defined constituency (see Appendix A for a
more complete definition). Any group calling itself a CSIRT for a
specific constituency must therefore react to reported security
incidents, and to threats to "their" constituency in ways which the
specific community agrees to be in its general interest.
Brownlee & Guttman Best Current Practice [Page 2]
RFC 2350 Expectations for Computer Security Incident Response June 1998
Since it is vital that each member of a constituent community be able
to understand what is reasonable to expect of their team, a CSIRT
should make it clear who belongs to their constituency and define the
services the team offers to the community. Additionally, each CSIRT
should publish its policies and operating procedures. Similarly,
these same constituents need to know what is expected of them in
order for them to receive the services of their team. This requires
that the team also publish how and where to report incidents.
This document details a template which will be used by CSIRTs to
communicate this information to their constituents. The constituents
should certainly expect a CSIRT to provide the services they describe
in the completed template.
It must be emphasized that without active participation from users,
the effectiveness of the CSIRT's services can be greatly diminished.
This is particularly the case with reporting. At a minimum, users
need to know that they should report security incidents, and know how
and to where they should report them.
Many computer security incidents originate outside local community
boundaries and affect inside sites, others originate inside the local
community and affect hosts or users on the outside. Often,
therefore, the handling of security incidents will involve multiple
sites and potentially multiple CSIRTs. Resolving these incidents
will require cooperation between individual sites and CSIRTs, and
between CSIRTs.
Constituent communities need to know exactly how their CSIRT will be
working with other CSIRTs and organizations outside their
constituency, and what information will be shared.
The rest of this document describes the set of topics and issues that
CSIRTs need to elaborate for their constituents. However, there is no
attempt to specify the "correct" answer to any one topic area.
Rather, each topic is discussed in terms of what that topic means.
Chapter two provides an overview of three major areas: the
publishing of information by a response team, the definition of the
response team's relationship to other response teams, and the need
for secure communications. Chapter three describes in detail all the
types of information that the community needs to know about their
response team.
For ease of use by the community, these topics are condensed into an
outline template found in Appendix D. This template can be used by
constituents to elicit information from their CSIRT.
Brownlee & Guttman Best Current Practice [Page 3]
RFC 2350 Expectations for Computer Security Incident Response June 1998
It is the working group's sincere hope that through clarification of
the topics in this document, understanding between the community and
its CSIRTs will be increased.
2 Scope
The interactions between an incident response team and its
constituent community response team require first that the community
understand the policies and procedures of the response team. Second,
since many response teams collaborate to handle incidents, the
community must also understand the relationship between their
response team and other teams. Finally, many interactions will take
advantage of existing public infrastructures, so the community needs
to know how those communications will be protected. Each of these
subjects will be described in more detail in the following three
sections.
2.1 Publishing CSIRT Policies and Procedures
Each user who has access to a Computer Security Incident Response
Team should know as much as possible about the services of and
interactions with this team long before he or she actually needs
them.
A clear statement of the policies and procedures of a CSIRT helps the
constituent understand how best to report incidents and what support
to expect afterwards. Will the CSIRT assist in resolving the
incident? Will it provide help in avoiding incidents in the future?
Clear expectations, particularly of the limitations of the services
provided by a CSIRT, will make interaction with it more efficient and
effective.
There are different kinds of response teams: some have very broad
constituencies (e.g., CERT Coordination Center and the Internet),
others have more bounded constituencies (e.g., DFN-CERT, CIAC), and
still others have very restricted constituencies (e.g., commercial
response teams, corporate response teams). Regardless of the type of
response team, the constituency supported by it must be knowledgeable
about the team's policies and procedures. Therefore, it is mandatory
that response teams publish such information to their constituency.
A CSIRT should communicate all necessary information about its
policies and services in a form suitable to the needs of its
constituency. It is important to understand that not all policies
and procedures need be publicly available. For example, it is not
necessary to understand the internal operation of a team in order to
interact with it, as when reporting an incident or receiving guidance
on how to analyze or secure one's systems.
Brownlee & Guttman Best Current Practice [Page 4]
RFC 2350 Expectations for Computer Security Incident Response June 1998
In the past, some teams supplied a kind of Operational Framework,
others provided a Frequently Asked Questions list (FAQ), while still
others wrote papers for distribution at user conferences or sent
newsletters.
We recommend that each CSIRT publish its guidelines and procedures on
its own information server (e.g. a World Wide Web server). This
would allow constituents to easily access it, though the problem
remains of how a constituent can find his or her team; people within
the constituency have to discover that there is a CSIRT "at their
disposal."
It is foreseen that completed CSIRT templates will soon become
searchable by modern search engines, which will aid in distributing
information about the existence of CSIRTs and basic information
required to approach them.
It would be very useful to have a central repository containing all
the completed CSIRT templates. No such repository exists at the time
of writing, though this might change in the future.
Regardless of the source from which the information is retrieved, the
user of the template must check its authenticity. It is highly
recommended that such vital documents be protected by digital
signatures. These will allow the user to verify that the template
was indeed published by the CSIRT and that it has not been tampered
with. This document assumes the reader is familiar with the proper
use of digital signatures to determine whether a document is
authentic.
2.2 Relationships between different CSIRTs
In some cases a CSIRT may be able to operate effectively on its own
and in close cooperation with its constituency. But with today's
international networks it is much more likely that most of the
incidents handled by a CSIRT will involve parties external to its
constituency. Therefore the team will need to interact with other
CSIRTs and sites outside its constituency.
The constituent community should understand the nature and extent of
this collaboration, as very sensitive information about individual
constituents may be disclosed in the process.
Inter-CSIRT interactions could include asking other teams for advice,
disseminating knowledge of problems, and working cooperatively to
resolve a security incident affecting one or more of the CSIRTs'
constituencies.
Brownlee & Guttman Best Current Practice [Page 5]
RFC 2350 Expectations for Computer Security Incident Response June 1998
In establishing relationships to support such interactions, CSIRTs
must decide what kinds of agreements can exist between them so as to
share yet safeguard information, whether this relationship can be
disclosed, and if so to whom.
Note that there is a difference between a peering agreement, where
the CSIRTs involved agree to work together and share information, and
simple co-operation, where a CSIRT (or any other organization) simply
contacts another CSIRT and asks for help or advice.
Although the establishment of such relationships is very important
and affects the ability of a CSIRT to support its constituency, it is
up to the teams involved to decide about the details. It is beyond
the scope of this document to make recommendations for this process.
However, the same set of information used to set expectations for a
user community regarding sharing of information will help other
parties to understand the objectives and services of a specific
CSIRT, supporting a first contact.
2.3 Establishing Secure Communications
Once one party has decided to share information with another party,
or two parties have agreed to share information or work together - as
required for the coordination of computer security incident response
- all parties involved need secure communications channels. (In this
context, "secure" refers to the protected transmission of information
shared between different parties, and not to the appropriate use of
the information by the parties.)
The goals of secure communication are:
- Confidentiality:
Can somebody else access the content of the communication?
- Integrity:
Can somebody else manipulate the content of the communication?
- Authenticity:
Am I communicating with the "right" person?
It is very easy to send forged e-mail, and not hard to establish a
(false) identity by telephone. Cryptographic techniques, for
example Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM) can
provide effective ways of securing e-mail. With the correct
equipment it is also possible to secure telephone communication. But
before using such mechanisms, both parties need the "right"
infrastructure, which is to say preparation in advance. The most
important preparation is ensuring the authenticity of the
Brownlee & Guttman Best Current Practice [Page 6]
RFC 2350 Expectations for Computer Security Incident Response June 1998
cryptographic keys used in secure communication:
- Public keys (for techniques like PGP and PEM):
Because they are accessible through the Internet, public keys must
be authenticated before use. While PGP relies on a "Web of Trust"
(where users sign the keys of other users), PEM relies on a
hierarchy (where certification authorities sign the keys of users).
- Secret keys (for techniques like DES and PGP/conventional
encryption): Because these must be known to both sender and
receiver, secret keys must be exchanged before the communication
via a secure channel.
Communication is critical to all aspects of incident response. A
team can best support the use of the above-mentioned techniques by
gathering all relevant information, in a consistent way. Specific
requirements (such as calling a specific number to check the
authenticity of keys) should be clear from the start. CSIRT
templates provide a standardized vehicle for delivering this
information.
It is beyond the scope of this document to address the technical and
administrative problems of secure communications. The point is that
response teams must support and use a method to secure the
communications between themselves and their constituents (or other
response teams). Whatever the mechanism is, the level of protection
it provides must be acceptable to the constituent community.
3 Information, Policies and Procedures
In chapter 2 it was mentioned that the policies and procedures of a
response team need to be published to their constituent community.
In this chapter we will list all the types of information that the
community needs to receive from its response team. How this
information is communicated to a community will differ from team to
team, as will the specific information content. The intent here is
to clearly describe the various kinds of information that a
constituent community expects from its response team.
To make it easier to understand the issues and topics relevant to the
interaction of constituents with "their" CSIRT, we suggest that a
CSIRT publish all information, policies, and procedures addressing
its constituency as a document, following the template given in
Appendix D. The template structure arranges items, making it easy to
supply specific information; in Appendix E we provide an example of a
filled-out template for the fictitious XYZ University. While no
recommendations are made as to what a CSIRT should adopt for its
policy or procedures, different possibilities are outlined to give
Brownlee & Guttman Best Current Practice [Page 7]
RFC 2350 Expectations for Computer Security Incident Response June 1998
some examples. The most important thing is that a CSIRT have a
policy and that those who interact with the CSIRT be able to obtain
and understand it.
As always, not every aspect for every environment and/or team can be
covered. This outline should be seen as a suggestion. Each team
should feel free to include whatever they think is necessary to
support its constituency.
3.1 Obtaining the Document
Details of a CSIRT change with time, so the completed template must
indicate when it was last changed. Additionally, information should
be provided concerning how to find out about future updates. Without
this, it is inevitable that misunderstandings and misconceptions will
arise over time; outdated documents can do more harm than good.
- Date of last update This should be sufficient to allow
anyone interested to evaluate the
currency of the template.
- Distribution list Mailing lists are a convenient
mechanism to distribute up-to-date
information to a large number of
users. A team can decide to use its
own or an already existing list to
notify users whenever the document
changes. The list might normally be
groups the CSIRT has frequent
interactions with.
Digital signatures should be used
for update messages sent by a CSIRT.
- Location of the document The location where a current version
of the document is accessible through
a team's online information services.
Constituents can then easily learn
more about the team and check for
recent updates. This online version
should also be accompanied by a
digital signature.
Brownlee & Guttman Best Current Practice [Page 8]
RFC 2350 Expectations for Computer Security Incident Response June 1998
3.2 Contact Information
Full details of how to contact the CSIRT should be listed here,
although this might be very different for different teams; for
example, some might choose not to publicize the names of their team
members. No further clarification is given when the meaning of the
item can be assumed.
- Name of the CSIRT
- Mailing Address
- Time zone This is useful for coordinating
incidents which cross time zones.
- Telephone number
- Facsimile number
- Other telecommunication Some teams might provide secure
voice communication (e.g. STU III).
- Electronic mail address
- Public keys and encryption The use of specific techniques
depends on the ability of the
communication partners to have
access to programs, keys and so on.
Relevant information should be
given to enable users to determine
if and how they can make use of
encrypted communication while
interacting with the CSIRT.
- Team members
- Operating Hours The operating hours and holiday
schedule should be provided here.
Is there a 24 hour hotline?
- Additional Contact Info Is there any specific customer
contact info?
More detailed contact information can be provided. This might
include different contacts for different services, or might be a list
of online information services. If specific procedures for access to
some services exist (for example addresses for mailing list
requests), these should be explained here.
Brownlee & Guttman Best Current Practice [Page 9]
RFC 2350 Expectations for Computer Security Incident Response June 1998
3.3 Charter
Every CSIRT must have a charter which specifies what it is to do, and
the authority under which it will do it. The charter should include
at least the following items:
- Mission statement
- Constituency
- Sponsorship / affiliation
- Authority
3.3.1 Mission Statement
The mission statement should focus on the team's core activities,
already stated in the definition of a CSIRT. In order to be
considered a Computer Security Incident Response Team, the team must
support the reporting of incidents and support its constituency by
dealing with incidents.
The goals and purposes of a team are especially important, and
require clear, unambiguous definition.
3.3.2 Constituency
A CSIRT's constituency can be determined in any of several ways. For
example it could be a company's employees or its paid subscribers, or
it could be defined in terms of a technological focus, such as the
users of a particular operating system.
The definition of the constituency should create a perimeter around
the group to whom the team will provide service. The policy section
of the document (see below) should explain how requests from outside
this perimeter will be handled.
If a CSIRT decides not to disclose its constituency, it should
explain the reasoning behind this decision. For example, for-fee
CSIRTs will not list their clients but will declare that they provide
a service to a large group of customers that are kept confidential
because of the clients' contracts.
Constituencies might overlap, as when an ISP provides a CSIRT which
delivers services to customer sites that also have CSIRTs. The
Authority section of the CSIRT's description (see below) should make
such relationships clear.
Brownlee & Guttman Best Current Practice [Page 10]
RFC 2350 Expectations for Computer Security Incident Response June 1998
3.3.3 Sponsoring Organization / Affiliation
The sponsoring organization, which authorizes the actions of the
CSIRT, should be given next. Knowing this will help the users to
understand the background and set-up of the CSIRT, and it is vital
information for building trust between a constituent and a CSIRT.
3.3.4 Authority
This section will vary greatly from one CSIRT to another, based on
the relationship between the team and its constituency. While an
organizational CSIRT will be given its authority by the management of
the organization, a community CSIRT will be supported and chosen by
the community, usually in a advisory role.
A CSIRT may or may not have the authority to intervene in the
operation of all of the systems within its perimeter. It should
identify the scope of its control as distinct from the perimeter of
its constituency. If other CSIRTs operate hierarchically within its
perimeter, this should be mentioned here, and the related CSIRTs
identified.
Disclosure of a team's authority may expose it to claims of
liability. Every team should seek legal advice on these matters.
(See section 3.7 for more on liability.)
3.4 Policies
It is critical that Incident Response Teams define their policies.
The following sections discuss communication of these policies to the
constituent community.
3.4.1 Types of Incidents and Level of Support
The types of incident which the team is able to address, and the
level of support which the team will offer when responding to each
type of incident, should be summarized here in list form. The
Services section (see below) provides the opportunity to give more
detailed descriptions, and to address non-incident-related topics.
The level of support may change depending on factors such as the
team's workload and the completeness of the information available.
Such factors should be outlined and their impact should be explained.
As a list of known types of incidents will be incomplete with regard
to possible or future incidents, a CSIRT should also give some
background on the "default" support for incident types not otherwise
mentioned.
Brownlee & Guttman Best Current Practice [Page 11]
RFC 2350 Expectations for Computer Security Incident Response June 1998
The team should state whether it will act on information it receives
about vulnerabilities which create opportunities for future
incidents. A commitment to act on such information on behalf of its
constituency is regarded as an optional proactive service policy
rather than a core service requirement for a CSIRT.
3.4.2 Co-operation, Interaction and Disclosure of Information
This section should make explicit which related groups the CSIRT
routinely interacts with. Such interactions are not necessarily
related to the computer security incident response provided, but are
used to facilitate better cooperation on technical topics or
services. By no means need details about cooperation agreements be
given out; the main objective of this section is to give the
constituency a basic understanding of what kind of interactions are
established and what their purpose is.
Cooperation between CSIRTs can be facilitated by the use of unique
ticket number assignment combined with explicit handoff procedures.
This reduces the chance of misunderstandings, duplications of effort,
assists in incident tracking and prevents 'loops' in communication.
The reporting and disclosure policy should make clear who will be the
recipients of a CSIRT's report in each circumstance. It should also
note whether the team will expect to operate through another CSIRT or
directly with a member of another constituency over matters
specifically concerning that member.
Related groups a CSIRT will interact with are listed below:
Incident Response Teams:
A CSIRT will often need to interact with other CSIRTs. For
example a CSIRT within a large company may need to report
incidents to a national CSIRT, and a national CSIRT may need to
report incidents to national CSIRTs in other countries to deal
with all sites involved in a large-scale attack.
Collaboration between CSIRTs may lead to disclosure of
information. The following are examples of such disclosure, but
are not intended to be an exhaustive list:
- Reporting incidents within the constituency to other teams.
If this is done, site-related information may become public
knowledge, accessible to everyone, in particular the press.
- Handling incidents occurring within the constituency, but
reported from outside it (which implies that some information
has already been disclosed off-site).
Brownlee & Guttman Best Current Practice [Page 12]
RFC 2350 Expectations for Computer Security Incident Response June 1998
- Reporting observations from within the constituency indicating
suspected or confirmed incidents outside it.
- Acting on reports of incidents from outside the constituency.
- Passing information about vulnerabilities to vendors, to
partner CSIRTs or directly to affected sites lying within or
outside the constituency.
- Feedback to parties reporting incidents or vulnerabilities.
- The provision of contact information relating to members of
the constituency, members of other constituencies, other
CSIRTs, or law-enforcement agencies.
Vendors:
Some vendors have their own CSIRTs, but some vendors may not. In
such cases a CSIRT will need to work directly with a vendor to
suggest improvements or modifications, to analyze the technical
problem or to test provided solutions. Vendors play a special
role in handling an incident if their products' vulnerabilities
are involved in the incident.
Law-enforcement agencies:
These include the police and other investigative agencies. CSIRTs
and users of the template should be sensitive to local laws and
regulations, which may vary considerably in different countries.
A CSIRT might advise on technical details of attacks or seek
advice on the legal implications of an incident. Local laws and
regulations may include specific reporting and confidentiality
requirements.
Press:
A CSIRT may be approached by the press for information and comment
from time to time.
An explicit policy concerning disclosure to the press can be
helpful, particularly in clarifying the expectations of a CSIRT's
constituency. The press policy will have to clarify the same
topics as above more specifically, as the constituency will
usually be very sensitive to press contacts.
Other:
This might include research activities or the relation to the
sponsoring organization.
Brownlee & Guttman Best Current Practice [Page 13]
RFC 2350 Expectations for Computer Security Incident Response June 1998
The default status of any and all security-related information which
a team receives will usually be 'confidential,' but rigid adherence
to this makes the team to appear to be an informational 'black hole,'
which may reduce the likelihood of the team's obtaining cooperation
from clients and from other organizations. The CSIRT's template
should define what information it will report or disclose, to whom,
and when.
Different teams are likely to be subject to different legal
restraints requiring or limiting disclosure, especially if they work
in different jurisdictions. In addition, they may have reporting
requirements imposed by their sponsoring organization. Each team's
template should specify any such constraints, both to clarify users'
expectations and to inform other teams.
Conflicts of interest, particularly in commercial matters, may also
restrain disclosure by a team; this document does not recommend on
how such conflicts should be addressed.
A team will normally collect statistics. If statistical information
is distributed, the template's reporting and disclosure policy should
say so, and should describe how to obtain such statistics.
3.4.3 Communication and Authentication
You must have a policy which describes methods of secure and
verifiable communication that you will use. This is necessary for
communication between CSIRTs and between a CSIRT and its
constituents. The template should include public keys or pointers to
them, including key fingerprints, together with guidelines on how to
use this information to check authenticity and how to deal with
corrupted information (for example where to report this fact).
At the moment it is recommended that as a minimum every CSIRT have
(if possible), a PGP key available. A team may also make other
mechanisms available (for example PEM, MOSS, S/MIME), according to
its needs and the needs of its constituents. Note however, that
CSIRTs and users should be sensitive to local laws and regulations.
Some countries do not allow strong encryption, or enforce specific
policies on the use of encryption technology. In addition to
encrypting sensitive information whenever possible, correspondence
should include digital signatures. (Please note that in most
countries, the protection of authenticity by using digital signatures
is not affected by existing encryption regulations.)
For communication via telephone or facsimile a CSIRT may keep secret
authentication data for parties with whom they may deal, such as an
agreed password or phrase. Obviously, such secret keys must not be
Brownlee & Guttman Best Current Practice [Page 14]
RFC 2350 Expectations for Computer Security Incident Response June 1998
published, though their existence may be.
3.5 Services
Services provided by a CSIRT can be roughly divided into two
categories: real-time activities directly related to the main task of
incident response, and non-real-time proactive activities, supportive
of the incident response task. The second category and part of the
first category consist of services which are optional in the sense
that not all CSIRTs will offer them.
3.5.1 Incident Response
Incident response usually includes assessing incoming reports about
incidents ("Incident Triage") and following up on these with other
CSIRTs, ISPs and sites ("Incident Coordination"). A third range of
services, helping a local site to recover from an incident ("Incident
Resolution"), is comprised of typically optional services, which not
all CSIRTs will offer.
3.5.1.1 Incident Triage
Incident triage usually includes:
- Report assessment Interpretion of incoming incident
reports, prioritizing them, and
relating them to ongoing incidents
and trends.
- Verification Help in determining whether an
incident has really occurred, and
its scope.
3.5.1.2 Incident Coordination
Incident Coordination normally includes:
- Information categorization Categorization of the incident related
information (logfiles, contact
information, etc.) with respect to
the information disclosure policy.
- Coordination Notification of other involved
parties on a need-to-know basis, as
per the information disclosure
policy.
Brownlee & Guttman Best Current Practice [Page 15]
RFC 2350 Expectations for Computer Security Incident Response June 1998
3.5.1.3 Incident Resolution
Usually additional or optional, incident resolution services
include:
- Technical Assistance This may include analysis of
compromised systems.
- Eradication Elimination of the cause of a
security incident (the vulnerability
exploited), and its effects (for
example, continuing access to the
system by an intruder).
- Recovery Aid in restoring affected systems
and services to their status before
the security incident.
3.5.2. Proactive Activities
Usually additional or optional, proactive services might include:
- Information provision This might include an archive of
known vulnerabilities, patches or
resolutions of past problems, or
advisory mailing lists.
- Security Tools This may include tools for auditing
a Site's security.
- Education and training
- Product evaluation
- Site security auditing and consulting
3.6 Incident Reporting Forms
The use of reporting forms makes it simpler for both users and teams
to deal with incidents. The constituent can prepare answers to
various important questions before he or she actually contacts the
team, and can therefore come well prepared. The team gets all the
necessary information at once with the first report and can proceed
efficiently.
Depending on the objectives and services of a particular CSIRT,
multiple forms may be used, for example a reporting form for a new
vulnerability may be very different from the form used for reporting
Brownlee & Guttman Best Current Practice [Page 16]
RFC 2350 Expectations for Computer Security Incident Response June 1998
incidents.
It is most efficient to provide forms through the online information
services of the team. The exact pointers to them should be given in
the CSIRT description document, together with statements about
appropriate use, and guidelines for when and how to use the forms. If
separate e-mail addresses are supported for form-based reporting,
they should be listed here again.
One example of such a form is the Incident Reporting Form provided by
the CERT Coordination Center:
- ftp://info.cert.org/incident_reporting_form
3.7 Disclaimers
Although the CSIRT description document does not constitute a
contract, liability may conceivably result from its descriptions of
services and purposes. The inclusion of a disclaimer at the end of
the template is therefore recommended and should warn the user about
possible limitations.
In situations where the original version of a document must be
translated into another language, the translation should carry a
disclaimer and a pointer to the original. For example:
Although we tried to carefully translate the original document
from German into English, we can not be certain that both
documents express the same thoughts in the same level of detail
and correctness. In all cases, where there is a difference
between both versions, the German version will prevail.
The use of and protection by disclaimers is affected by local laws
and regulations, of which each CSIRT should be aware. If in doubt the
CSIRT should check the disclaimer with a lawyer.
Brownlee & Guttman Best Current Practice [Page 17]
RFC 2350 Expectations for Computer Security Incident Response June 1998
Appendix A: Glossary of Terms
This glossary defines terms used in describing security incidents and
Computer Security Incident Response Teams. Only a limited list is
included. For more definitions please refer to other sources, for
example to the Internet User's Glossary [RFC 1983].
Constituency:
Implicit in the purpose of a Computer Security Incident Response
Team is the existence of a constituency. This is the group of
users, sites, networks or organizations served by the team. The
team must be recognized by its constituency in order to be
effective.
Security Incident:
For the purpose of this document, this term is a synonym of
Computer Security Incident: any adverse event which compromises
some aspect of computer or network security.
The definition of an incident may vary between organizations, but
at least the following categories are generally applicable:
- Loss of confidentiality of information.
- Compromise of integrity of information.
- Denial of service.
- Misuse of service, systems or information.
- Damage to systems.
These are very general categories. For instance the replacement
of a system utility program by a Trojan Horse is an example of '
compromise of integrity,' and a successful password attack is an
example of 'loss of confidentiality.' Attacks, even if they
failed because of proper protection, can be regarded as Incidents.
Within the definition of an incident the word 'compromised' is
used. Sometimes an administrator may only 'suspect' an incident.
During the response it must be established whether or not an
incident has really occurred.
Computer Security Incident Response Team:
Based on two of the definitions given above, a CSIRT is a team
that coordinates and supports the response to security incidents
that involve sites within a defined constituency.
In order to be considered a CSIRT, a team must:
- Provide a (secure) channel for receiving reports about
suspected incidents.
Brownlee & Guttman Best Current Practice [Page 18]
RFC 2350 Expectations for Computer Security Incident Response June 1998
- Provide assistance to members of its constituency in
handling these incidents.
- Disseminate incident-related information to its
constituency and to other involved parties.
Note that we are not referring here to police or other law
enforcement bodies which may investigate computer-related crime.
CSIRT members, indeed, need not have any powers beyond those of
ordinary citizens.
Vendor:
A 'vendor' is any entity that produces networking or computing
technology, and is responsible for the technical content of that
technology. Examples of 'technology' include hardware (desktop
computers, routers, switches, etc.), and software (operating
systems, mail forwarding systems, etc.).
Note that the supplier of a technology is not necessarily the '
vendor' of that technology. As an example, an Internet Service
Provider (ISP) might supply routers to each of its customers, but
the 'vendor' is the manufacturer, since the manufacturer, rather
than the ISP, is the entity responsible for the technical content
of the router.
Vulnerability:
A 'vulnerability' is a characteristic of a piece of technology
which can be exploited to perpetrate a security incident. For
example, if a program unintentionally allowed ordinary users to
execute arbitrary operating system commands in privileged mode,
this "feature" would be a vulnerability.
Brownlee & Guttman Best Current Practice [Page 19]
RFC 2350 Expectations for Computer Security Incident Response June 1998
Appendix B: Related Material
Important issues in responding to security incidents on a site level
are contained in [RFC 2196], the Site Security Handbook, produced by
the Site Security Handbook Working Group (SSH). This document will
be updated by the SSH working group and will give recommendations for
local policies and procedures, mainly related to the avoidance of
security incidents.
Other documents of interest for the discussion of CSIRTs and their
tasks are available by anonymous FTP. A collection can be found on:
- ftp://ftp.cert.dfn.de/pub/docs/csir/
Please refer to file 01-README for further information about
the content of this directory.
Some especially interesting documents in relation to this document
are as follows:
- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/
reports/R-92-01
This report contains the Operational Framework of CERT-NL, the
CSIRT of SURFnet (network provider in the Netherlands).
- For readers interested in the operation of FIRST (Forum of
Incident Response and Security Teams) more information is
collected in Appendix C.
- http://hightop.nrl.navy.mil/news/incident.html
This document leads to the NRL Incident Response Manual.
- http://www.cert.dfn.de/eng/team/kpk/certbib.html
This document contains an annotated bibliography of available
material, documents and files about the operation of CSIRTs
with links to many of the referenced items.
- ftp://info.cert.org/incident_reporting_form
This Incident Reporting Form is provided by the CERT
Coordination Center to gather incident information and to avoid
additional delays caused by the need to request more detailed
information from the reporting site.
- http://www.cert.org/cert.faqintro.html
A collection of frequently asked questions from the CERT
Coordination Center.
Brownlee & Guttman Best Current Practice [Page 20]
RFC 2350 Expectations for Computer Security Incident Response June 1998
Appendix C: Known Computer Security Incident Response Teams
Today, there are many different CSIRTs but no single source lists
every team. Most of the major and long established teams (the first
CSIRT was founded in 1988) are nowadays members of FIRST, the
worldwide Forum of Incident Response and Security Teams. At the time
of writing, more than 55 teams are members (1 in Australia, 13 in
Europe, all others in North America). Information about FIRST can be
found:
- http://www.first.org/
The current list of members is available also, with the relevant
contact information and some additional information provided by the
particular teams:
- http://www.first.org/team-info/
For CSIRTs which want to become members of this forum (please note
that a team needs a sponsor - a team which is already a full member
of FIRST - to be introduced), the following files contain more
information:
- http://www.first.org/about/op_frame.html
The Operational Framework of FIRST.
- http://www.first.org/docs/newmem.html
Guidelines for teams which want to become members of FIRST.
Many of the European teams, regardless of whether they are members
of FIRST or not, are listed by countries on a page maintained by
the German CSIRT:
- http://www.cert.dfn.de/eng/csir/europe/certs.html
To learn about existing teams suitable to one's needs it is
often helpful to ask either known teams or an Internet Service
Provider for the "right" contact.
Brownlee & Guttman Best Current Practice [Page 21]
RFC 2350 Expectations for Computer Security Incident Response June 1998
Appendix D: Outline for CSIRT Template
This outline summarizes in point form the issues addressed in this
document, and is the recommended template for a CSIRT description
document. Its structure is designed to facilitate the communication
of a CSIRT's policies, procedures, and other relevant information to
its constituency and to outside organizations such as other CSIRTs. A
'filled-in' example of this template is given as Appendix E.
1. Document Information
1.1 Date of Last Update
1.2 Distribution List for Notifications
1.3 Locations where this Document May Be Found
2. Contact Information
2.1 Name of the Team
2.2 Address
2.3 Time Zone
2.4 Telephone Number
2.5 Facsimile Number
2.6 Other Telecommunication
2.7 Electronic Mail Address
2.8 Public Keys and Encryption Information
2.9 Team Members
2.10 Other Information
2.11 Points of Customer Contact
3. Charter
3.1 Mission Statement
3.2 Constituency
3.3 Sponsorship and/or Affiliation
3.4 Authority
4. Policies
4.1 Types of Incidents and Level of Support
4.2 Co-operation, Interaction and Disclosure of Information
4.3 Communication and Authentication
5. Services
5.1 Incident Response
5.1.1. Incident Triage
5.1.2. Incident Coordination
5.1.3. Incident Resolution
5.2 Proactive Activities
6. Incident Reporting Forms
7. Disclaimers
Brownlee & Guttman Best Current Practice [Page 22]
RFC 2350 Expectations for Computer Security Incident Response June 1998
Appendix E: Example - 'filled-in' Template for a CSIRT
Below is an example of a filled-in template for a fictitious CSIRT
called XYZ-CSIRT. This text is for example purposes only, and does
not constitute endorsement by the working group or the IETF of any
particular set of procedures or policies. While CSIRTs are welcome
to use any or all of this text if they wish, such use is of course
not mandatory, or even appropriate in most cases.
CSIRT Description for XYZ-CERT
-----------------------------
1. About this document
1.1 Date of Last Update
This is version 1.01, published 1997/03/31.
1.2 Distribution List for Notifications
Notifications of updates are submitted to our mailing list