2131 lines
80 KiB
Text
Executable file
2131 lines
80 KiB
Text
Executable file
HyperRFC: file rfc2350.txt cached
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
<xyz-cert-info@xyz-univ.ca>. Subscription requests for this
|
|
list should be sent to the Majordomo at
|
|
<xyz-cert-info-request@xyz-univ.ca>; the body of the message
|
|
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 Found
|
|
|
|
The current version of this CSIRT description document is
|
|
available from the XYZ-CERT WWW site; its URL is
|
|
http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.txt
|
|
Une version francaise de ce document est igalement disponible:
|
|
http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.txt
|
|
Please make sure you are using the latest version.
|
|
|
|
1.4 Authenticating this Document
|
|
|
|
Both the English and French versions of this document have
|
|
been signed with the XYZ-CERT's PGP key. The signatures are
|
|
also on our Web site, under:
|
|
http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.asc
|
|
http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.asc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 23]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
2. Contact Information
|
|
|
|
2.1 Name of the Team
|
|
|
|
"XYZ-CERT": the XYZ University Computer Emergency Response
|
|
Team.
|
|
|
|
2.2 Address
|
|
|
|
XYZ-CERT
|
|
XYZ University, Computing Services Department
|
|
12345 Rue Principale
|
|
UniversityTown, Quebec
|
|
Canada H0H 0H0
|
|
|
|
2.3 Time Zone
|
|
|
|
Canada/Eastern (GMT-0500, and GMT-0400 from April to October)
|
|
|
|
2.4 Telephone Number
|
|
|
|
+1 234 567 7890 (ask for the XYZ-CERT)
|
|
|
|
2.5 Facsimile Number
|
|
|
|
+1 234 567 7899 (this is *not* a secure fax)
|
|
|
|
2.6 Other Telecommunication
|
|
|
|
None available.
|
|
|
|
2.7 Electronic Mail Address
|
|
|
|
<xyz-cert@xyz-univ.ca> This is a mail alias that relays mail
|
|
to the human(s) on duty for the XYZ-CERT.
|
|
|
|
2.8 Public Keys and Other Encryption Information
|
|
|
|
The XYZ-CERT has a PGP key, whose KeyID is 12345678 and
|
|
whose fingerprint is
|
|
11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11.
|
|
The key and its signatures can be found at the usual large
|
|
public keyservers.
|
|
|
|
Because PGP is still a relatively new technology at XYZ
|
|
University, this key still has relatively few signatures;
|
|
efforts are underway to increase the number of links to this
|
|
key in the PGP "web of trust". In the meantime, since most
|
|
|
|
|
|
|
|
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 member
|
|
who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has
|
|
signed the XYZ-CERT key, and will be happy to confirm its
|
|
fingerprint and that of her own key to those people who know
|
|
her, by telephone or in person.
|
|
|
|
2.9 Team Members
|
|
|
|
Zoe Doe of Computing Services is the XYZ-CERT coordinator.
|
|
Backup coordinators and other team members, along with their
|
|
areas of expertise and contact information, are listed in the
|
|
XYZ-CERT web pages, at
|
|
http://www.xyz-univ.ca/xyz-cert/teamlist.html
|
|
|
|
Management, liaison and supervision are provided by Steve Tree,
|
|
Assistant Director (Technical Services), Computing Services.
|
|
|
|
2.10 Other Information
|
|
|
|
General information about the XYZ-CERT, as well as links to
|
|
various recommended security resources, can be found at
|
|
http://www.xyz-univ.ca/xyz-cert/index.html
|
|
|
|
2.11 Points of Customer Contact
|
|
|
|
The preferred method for contacting the XYZ-CERT is via
|
|
e-mail at <xyz-cert@xyz-univ.ca>; e-mail sent to this address
|
|
will "biff" the responsible human, or be automatically
|
|
forwarded to the appropriate backup person, immediately. If
|
|
you require urgent assistance, put "urgent" in your subject
|
|
line.
|
|
|
|
If it is not possible (or not advisable for security reasons)
|
|
to use e-mail, the XYZ-CERT can be reached by telephone during
|
|
regular office hours. Telephone messages are checked less
|
|
often than e-mail.
|
|
|
|
The XYZ-CERT's hours of operation are generally restricted to
|
|
regular business hours (09:00-17:00 Monday to Friday except
|
|
holidays).
|
|
|
|
If possible, when submitting your report, use the form
|
|
mentioned in section 6.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 25]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
3. Charter
|
|
|
|
3.1 Mission Statement
|
|
|
|
The purpose of the XYZ-CERT is, first, to assist members of XYZ
|
|
University community in implementing proactive measures to
|
|
reduce the risks of computer security incidents, and second, to
|
|
assist XYZ community in responding to such incidents when they
|
|
occur.
|
|
|
|
3.2 Constituency
|
|
|
|
The XYZ-CERT's constituency is the XYZ University community,
|
|
as defined in the context of the "XYZ University Policy on
|
|
Computing Facilities". This policy is available at
|
|
http://www-compserv.xyz-univ.ca/policies/pcf.html
|
|
|
|
However, please note that, notwithtanding the above, XYZ-CERT
|
|
services will be provided for on-site systems only.
|
|
|
|
3.3 Sponsorship and/or Affiliation
|
|
|
|
The XYZ-CERT is sponsored by the ACME Canadian Research
|
|
Network. It maintains affiliations with various University
|
|
CSIRTs throughout Canada and the USA on an as needed basis.
|
|
|
|
3.4 Authority
|
|
|
|
The XYZ-CERT operates under the auspices of, and with authority
|
|
delegated by, the Department of Computing Services of XYZ
|
|
University. For further information on the mandate and
|
|
authority of the Department of Computing Services, please
|
|
refer to the XYZ University "Policy on Computing Facilities",
|
|
available at
|
|
http://www-compserv.xyz-univ.ca/policies/pcf.html
|
|
|
|
The XYZ-CERT expects to work cooperatively with system
|
|
administrators and users at XYZ University, and, insofar as
|
|
possible, to avoid authoritarian relationships. However,
|
|
should circumstances warrant it, the XYZ-CERT will appeal to
|
|
Computing Services to exert its authority, direct or indirect,
|
|
as necessary. All members of the XYZ-CERT are members of the
|
|
CCSA (Committee of Computer Systems Administrators), and have
|
|
all of the powers and responsibilities assigned to Systems
|
|
Administrators by the Policy on Computing Facilities, or are
|
|
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 the
|
|
actions of the XYZ-CERT should contact the Assistant Director
|
|
(Technical Services), Computing Services. If this recourse is
|
|
not satisfactory, the matter may be referred to the Director
|
|
of Computing Services (in the case of perceived
|
|
problems with existing policy), or to the XYZ University
|
|
Office of Rights and Responsibilities (in the case of perceived
|
|
errors in the application of existing policy).
|
|
|
|
4. Policies
|
|
|
|
4.1 Types of Incidents and Level of Support
|
|
|
|
The XYZ-CERT is authorized to address all types of computer
|
|
security incidents which occur, or threaten to occur, at
|
|
XYZ University.
|
|
|
|
The level of support given by XYZ-CERT will vary depending on
|
|
the type and severity of the incident or issue, the type of
|
|
constituent, the size of the user community affected, and the
|
|
XYZ-CERT's resources at the time, though in all cases some
|
|
response will be made within one working day. Resources will
|
|
be assigned according to the following priorities, listed in
|
|
decreasing order:
|
|
|
|
- Threats to the physical safety of human beings.
|
|
- Root or system-level attacks on any Management Information
|
|
System, or any part of the backbone network infrastructure.
|
|
- Root or system-level attacks on any large public service
|
|
machine, either multi-user or dedicated-purpose.
|
|
- Compromise of restricted confidential service accounts or
|
|
software installations, in particular those used for MIS
|
|
applications containing confidential data, or those used
|
|
for system administration.
|
|
- Denial of service attacks on any of the above three items.
|
|
- Any of the above at other sites, originating from XYZ
|
|
University.
|
|
- Large-scale attacks of any kind, e.g. sniffing attacks,
|
|
IRC "social engineering" attacks, password cracking
|
|
attacks.
|
|
- Threats, harassment, and other criminal offenses
|
|
involving individual user accounts.
|
|
- Compromise of individual user accounts on multi-user
|
|
systems.
|
|
- Compromise of desktop systems.
|
|
- Forgery and misrepresentation, and other security-related
|
|
violations of local rules and regulations, e.g. netnews
|
|
and e-mail forgery, unauthorized use of IRC bots.
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 27]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
- Denial of service on individual user accounts, e.g.
|
|
mailbombing.
|
|
|
|
Types of incidents other than those mentioned above will be
|
|
prioritized according to their apparent severity and extent.
|
|
|
|
Note that no direct support will be given to end users; they
|
|
are expected to contact their system administrator, network
|
|
administrator, or department head for assistance. The XYZ-CERT
|
|
will support the latter people.
|
|
|
|
While the XYZ-CERT understands that there exists great
|
|
variation in the level of system administrator expertise at XYZ
|
|
University, and while the XYZ-CERT will endeavor to present
|
|
information and assistance at a level appropriate to each
|
|
person, the XYZ-CERT cannot train system administrators on the
|
|
fly, and it cannot perform system maintenance on their behalf.
|
|
In most cases, the XYZ-CERT will provide pointers to the
|
|
information needed to implement appropriate measures.
|
|
|
|
The XYZ-CERT is committed to keeping the XYZ University system
|
|
administration community informed of potential vulnerabilities,
|
|
and where possible, will inform this community of such
|
|
vulnerabilities before they are actively exploited.
|
|
|
|
4.2 Co-operation, Interaction and Disclosure of Information
|
|
|
|
While there are legal and ethical restrictions on the flow of
|
|
information from XYZ-CERT, many of which are also outlined in
|
|
the XYZ University Policy on Computing Facilities, and all of
|
|
which will be respected, the XYZ-CERT acknowledges its
|
|
indebtedness to, and declares its intention to contribute to,
|
|
the spirit of cooperation that created the Internet.
|
|
Therefore, while appropriate measures will be taken to protect
|
|
the identity of members of our constituency and members of
|
|
neighbouring sites where necessary, the XYZ-CERT will otherwise
|
|
share information freely when this will assist others in
|
|
resolving or preventing security incidents.
|
|
|
|
In the paragraphs below, "affected parties" refers to the
|
|
legitimate owners, operators, and users of the relevant
|
|
computing facilities. It does not refer to unauthorized
|
|
users, including otherwise authorized users making
|
|
unauthorized use of a facility; such intruders may have no
|
|
expectation of confidentiality from the XYZ-CERT. They may or
|
|
may not have legal rights to confidentiality; such rights will
|
|
of course be respected where they exist.
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 28]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
Information being considered for release will be classified as
|
|
follows:
|
|
|
|
- Private user information is information about particular
|
|
users, or in some cases, particular applications, which
|
|
must be considered confidential for legal, contractual,
|
|
and/or ethical reasons.
|
|
|
|
Private user information will be not be released in
|
|
identifiable form outside the XYZ-CERT, except as provided
|
|
for below. If the identity of the user is disguised, then
|
|
the information can be released freely (for example to show
|
|
a sample .cshrc file as modified by an intruder, or to
|
|
demonstrate a particular social engineering attack).
|
|
|
|
- Intruder information is similar to private user
|
|
information, but concerns intruders.
|
|
|
|
While intruder information, and in particular identifying
|
|
information, will not be released to the public (unless it
|
|
becomes a matter of public record, for example because
|
|
criminal charges have been laid), it will be exchanged
|
|
freely with system administrators and CSIRTs tracking an
|
|
incident.
|
|
|
|
- Private site information is technical information about
|
|
particular systems or sites.
|
|
|
|
It will not be released without the permission of the site
|
|
in question, except as provided for below.
|
|
|
|
- Vulnerability information is technical information about
|
|
vulnerabilities or attacks, including fixes and
|
|
workarounds.
|
|
|
|
Vulnerability information will be released freely, though
|
|
every effort will be made to inform the relevant vendor
|
|
before the general public is informed.
|
|
|
|
- Embarrassing information includes the statement that an
|
|
incident has occurred, and information about its extent or
|
|
severity. Embarrassing information may concern a site or
|
|
a particular user or group of users.
|
|
|
|
Embarrassing information will not be released without the
|
|
permission of the site or users in question, except as
|
|
provided for below.
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 29]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
- Statistical information is embarrassing information with
|
|
the identifying information stripped off.
|
|
|
|
Statistical information will be released at the discretion
|
|
of the Computing Services Department.
|
|
|
|
- Contact information explains how to reach system
|
|
administrators and CSIRTs.
|
|
|
|
Contact information will be released freely, except where
|
|
the contact person or entity has requested that this not
|
|
be the case, or where XYZ-CERT has reason to believe that
|
|
the dissemination of this information would not be
|
|
appreciated.
|
|
|
|
Potential recipients of information from the XYZ-CERT will be
|
|
classified as follows:
|
|
|
|
- Because of the nature of their responsibilities and
|
|
consequent expectations of confidentiality, members of XYZ
|
|
University management are entitled to receive whatever
|
|
information is necessary to facilitate the handling of
|
|
computer security incidents which occur in their
|
|
jurisdictions.
|
|
|
|
- Members of the Office of Rights and Responsibilities are
|
|
entitled to receive whatever information they request
|
|
concerning a computer security incident or related matter
|
|
which has been referred to them for resolution. The same is
|
|
true for the XYZ Security Department, when its assistance in
|
|
an investigation has been enlisted, or when the investigation
|
|
has been instigated at its request.
|
|
|
|
- System administrators at XYZ University who are members of
|
|
the CCSA are also, by virtue of their responsibilities,
|
|
trusted with confidential information. However, unless such
|
|
people are also members of XYZ-CERT, they will be given only
|
|
that confidential information which they must have in order
|
|
to assist with an investigation, or in order to secure their
|
|
own systems.
|
|
|
|
- Users at XYZ University are entitled to information which
|
|
pertains to the security of their own computer accounts,
|
|
even if this means revealing "intruder information", or
|
|
"embarrassing information" about another user. For
|
|
example, if account aaaa is cracked and the intruder attacks
|
|
account bbbb, user bbbb is entitled to know that aaaa was
|
|
cracked, and how the attack on the bbbb account was
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 30]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
executed. User bbbb is also entitled, if she or he requests
|
|
it, to information about account aaaa which might enable
|
|
bbbb to investigate the attack. For example, if bbbb was
|
|
attacked by someone remotely connected to aaaa, bbbb should
|
|
be told the provenance of the connections to aaaa, even
|
|
though this information would ordinarily be considered
|
|
private to aaaa. Users at XYZ University are entitled to be
|
|
notified if their account is believed to have been
|
|
compromised.
|
|
|
|
- The XYZ University community will receive no restricted
|
|
information, except where the affected parties have given
|
|
permission for the information to be disseminated.
|
|
Statistical information may be made available to the general
|
|
XYZ community. There is no obligation on the part of the
|
|
XYZ-CERT to report incidents to the community, though it may
|
|
choose to do so; in particular, it is likely that the
|
|
XYZ-CERT will inform all affected parties of the ways in
|
|
which they were affected, or will encourage the affected site
|
|
to do so.
|
|
|
|
- The public at large will receive no restricted information.
|
|
In fact, no particular effort will be made to communicate
|
|
with the public at large, though the XYZ-CERT recognizes
|
|
that, for all intents and purposes, information made
|
|
available to the XYZ University community is in effect made
|
|
available to the community at large, and will tailor the
|
|
information in consequence.
|
|
|
|
- The computer security community will be treated the same way
|
|
the general public is treated. While members of XYZ-CERT may
|
|
participate in discussions within the computer security
|
|
community, such as newsgroups, mailing lists (including the
|
|
full-disclosure list "bugtraq"), and conferences, they will
|
|
treat such forums as though they were the public at large.
|
|
While technical issues (including vulnerabilities) may be
|
|
discussed to any level of detail, any examples taken from
|
|
XYZ-CERT experience will be disguised to avoid identifying
|
|
the affected parties.
|
|
|
|
- The press will also be considered as part of the general
|
|
public. The XYZ-CERT will not interact directly with the
|
|
Press concerning computer security incidents, except to point
|
|
them toward information already released to the general
|
|
public. If necessary, information will be provided to the
|
|
XYZ University Public Relations Department, and to the
|
|
Customer Relations group of the Computing Services
|
|
Department. All incident-related queries will be referred to
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 31]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
these two bodies. The above does not affect the ability of
|
|
members of XYZ-CERT to grant interviews on general computer
|
|
security topics; in fact, they are encouraged to do to, as a
|
|
public service to the community.
|
|
|
|
- Other sites and CSIRTs, when they are partners in the
|
|
investigation of a computer security incident, will in some
|
|
cases be trusted with confidential information. This will
|
|
happen only if the foreign site's bona fide can be verified,
|
|
and the information transmitted will be limited to that which
|
|
is likely to be helpful in resolving the incident. Such
|
|
information sharing is most likely to happen in the case of
|
|
sites well known to XYZ-CERT (for example, several other
|
|
Quebec universities have informal but well-established
|
|
working relationships with XYZ University in such matters).
|
|
|
|
For the purposes of resolving a security incident, otherwise
|
|
semi-private but relatively harmless user information such as
|
|
the provenance of connections to user accounts will not be
|
|
considered highly sensitive, and can be transmitted to a
|
|
foreign site without excessive precautions. "Intruder
|
|
information" will be transmitted freely to other system
|
|
administrators and CSIRTs. "Embarrassing information" can be
|
|
transmitted when there is reasonable assurance that it will
|
|
remain confidential, and when it is necessary to resolve an
|
|
incident.
|
|
|
|
- Vendors will be considered as foreign CSIRTs for most intents
|
|
and purposes. The XYZ-CERT wishes to encourage vendors of
|
|
all kinds of networking and computer equipment, software, and
|
|
services to improve the security of their products. In aid
|
|
of this, a vulnerability discovered in such a product will be
|
|
reported to its vendor, along with all technical details
|
|
needed to identify and fix the problem. Identifying details
|
|
will not be given to the vendor without the permission of the
|
|
affected parties.
|
|
|
|
- Law enforcement officers will receive full cooperation from
|
|
the XYZ-CERT, including any information they require to
|
|
pursue an investigation, in accordance with the Policy on
|
|
Computing Facilities.
|
|
|
|
4.3 Communication and Authentication
|
|
|
|
In view of the types of information that the XYZ-CERT will
|
|
likely be dealing with, telephones will be considered
|
|
sufficiently secure to be used even unencrypted. Unencrypted
|
|
e-mail will not be considered particularly secure, but will be
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 32]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
sufficient for the transmission of low-sensitivity data. If
|
|
it is necessary to send highly sensitive data by e-mail, PGP
|
|
will be used. Network file transfers will be considered to
|
|
be similar to e-mail for these purposes: sensitive data should
|
|
be encrypted for transmission.
|
|
|
|
Where it is necessary to establish trust, for example before
|
|
relying on information given to the XYZ-CERT, or before
|
|
disclosing confidential information, the identity and bona
|
|
fide of the other party will be ascertained to a reasonable
|
|
degree of trust. Within XYZ University, and with known
|
|
neighbor sites, referrals from known trusted people will
|
|
suffice to identify someone. Otherwise, appropriate methods
|
|
will be used, such as a search of FIRST members, the use of
|
|
WHOIS and other Internet registration information, etc, along
|
|
with telephone call-back or e-mail mail-back to ensure that
|
|
the party is not an impostor. Incoming e-mail whose data must
|
|
be trusted will be checked with the originator personally, or
|
|
by means of digital signatures (PGP in particular is
|
|
supported).
|
|
|
|
5. Services
|
|
|
|
5.1 Incident Response
|
|
|
|
XYZ-CERT will assist system administrators in handling the
|
|
technical and organizational aspects of incidents. In
|
|
particular, it will provide assistance or advice with respect
|
|
to the following aspects of incident management:
|
|
|
|
5.1.1 Incident Triage
|
|
|
|
- Investigating whether indeed an incident occured.
|
|
- Determining the extent of the incident.
|
|
|
|
5.1.2 Incident Coordination
|
|
|
|
- Determining the initial cause of the incident
|
|
(vulnerability exploited).
|
|
- Facilitating contact with other sites which may be
|
|
involved.
|
|
- Facilitating contact with XYZ University Security and/or
|
|
appropriate law enforcement officials, if necessary.
|
|
- Making reports to other CSIRTs.
|
|
- Composing announcements to users, if applicable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 33]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
5.1.3 Incident Resolution
|
|
|
|
- Removing the vulnerability.
|
|
- Securing the system from the effects of the incident.
|
|
- Evaluating whether certain actions are likely to reap
|
|
results in proportion to their cost and risk, in
|
|
particular those actions aimed at an eventual prosecution
|
|
or disciplinary action: collection of evidence after the
|
|
fact, observation of an incident in progress, setting
|
|
traps for intruders, etc.
|
|
- Collecting evidence where criminal prosecution, or
|
|
University disciplinary action, is contemplated.
|
|
|
|
In addition, XYZ-CERT will collect statistics concerning
|
|
incidents which occur within or involve the XYZ University
|
|
community, and will notify the community as necessary to
|
|
assist it in protecting against known attacks.
|
|
|
|
To make use of XYZ-CERT's incident response services, please
|
|
send e-mail as per section 2.11 above. Please remember that
|
|
the amount of assistance available will vary according to
|
|
the parameters described in section 4.1.
|
|
|
|
5.2 Proactive Activities
|
|
|
|
The XYZ-CERT coordinates and maintains the following
|
|
services to the extent possible depending on its resources:
|
|
- Information services
|
|
- List of departmental security contacts, administrative
|
|
and technical. These lists will be available to the
|
|
general public, via commonly-available channels such as
|
|
the World Wide Web and/or the Domain Name Service.
|
|
- Mailing lists to inform security contacts of new
|
|
information relevant to their computing environments.
|
|
These lists will be available only to XYZ University
|
|
system administrators.
|
|
- Repository of vendor-provided and other security-related
|
|
patches for various operating systems. This repository
|
|
will be available to the general public wherever
|
|
license restrictions allow it, and will be provided via
|
|
commonly-available channels such as the World Wide Web
|
|
and/or ftp.
|
|
- Repository of security tools and documentation for
|
|
use by sysadmins. Where possible, precompiled
|
|
ready-to-install versions will be supplied. These will
|
|
be supplied to the general public via www or ftp as
|
|
above.
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 34]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
- "Clipping" service for various existing resources, such
|
|
as major mailing lists and newsgroups. The resulting
|
|
clippings will be made available either on the
|
|
restricted mailing list or on the web site, depending
|
|
on their sensitivity and urgency.
|
|
- Training services
|
|
- Members of the XYZ-CERT will give periodic seminars on
|
|
computer security related topics; these seminars will
|
|
be open to XYZ University system administrators.
|
|
- Auditing services
|
|
- Central file integrity checking service for Unix
|
|
machines, and for any other platforms capable of
|
|
running "tripwire".
|
|
- Security level assignments; machines and subnetworks
|
|
at XYZ University will be audited and assigned a
|
|
security level. This security level information will be
|
|
available to the XYZ University community, to facilitate
|
|
the setting of appropriate access privileges. However,
|
|
details of the security analyses will be confidential,
|
|
and available only to the concerned parties.
|
|
- Archiving services
|
|
- Central logging service for machines capable of
|
|
Unix-style remote logging. Incoming log entries will
|
|
be watched by an automated log analysis program, and
|
|
events or trends indicative of a potential security
|
|
problem will be reported to the affected system
|
|
administrators.
|
|
- Records of security incidents handled will be kept.
|
|
While the records will remain confidential, periodic
|
|
statistical reports will be made available to the XYZ
|
|
University community.
|
|
|
|
Detailed descriptions of the above services, along with
|
|
instructions for joining mailing lists, downloading
|
|
information, or participating in certain services such as the
|
|
central logging and file integrity checking services, are
|
|
available on the XYZ-CERT web site, as per section 2.10
|
|
above.
|
|
|
|
6. Incident Reporting Forms
|
|
|
|
There are no local forms developed yet for reporting incidents
|
|
to XYZ-CERT. If possible, please make use of the Incident
|
|
Reporting Form of the CERT Coordination Center (Pittsburgh,
|
|
PA). The current version is available from:
|
|
ftp://info.cert.org/incident_reporting_form
|
|
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 35]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
7. Disclaimers
|
|
|
|
While every precaution will be taken in the preparation of
|
|
information, notifications and alerts, XYZ-CERT assumes no
|
|
responsibility for errors or omissions, or for damages
|
|
resulting from the use of the information contained within.
|
|
|
|
4 Acknowlegdements
|
|
|
|
The editors gratefully acknowledge the contributed material and
|
|
editorial scrutiny of Anne Bennett. Thanks also to Don Stikvoort
|
|
for assistance reworking the description of Incident Response Team
|
|
services.
|
|
|
|
5 References
|
|
|
|
[RFC 2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
|
|
September 1997.
|
|
|
|
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
|
|
August 1996.
|
|
|
|
6 Security Considerations
|
|
|
|
This document discusses the operation of Computer Security Incident
|
|
Response Teams, and the teams' interactions with their constituencies
|
|
and with other organizations. It is, therefore, not directly
|
|
concerned with the security of protocols, applications, or network
|
|
systems themselves. It is not even concerned with particular
|
|
responses and reactions to security incidents, but only with the
|
|
appropriate description of the responses provided by CSIRTs.
|
|
|
|
Nonetheless, it is vital that the CSIRTs themselves operate securely,
|
|
which means that they must establish secure communication channels
|
|
with other teams, and with members of their constituency. They must
|
|
also secure their own systems and infrastructure, to protect the
|
|
interests of their constituency and to maintain the confidentiality
|
|
of the identity of victims and reporters of security incidents.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 36]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
7 Authors' Addresses
|
|
|
|
Nevil Brownlee
|
|
ITSS Technology Development
|
|
The University of Auckland
|
|
|
|
Phone: +64 9 373 7599 x8941
|
|
EMail: n.brownlee@auckland.ac.nz
|
|
|
|
|
|
Erik Guttman
|
|
Sun Microsystems, Inc.
|
|
Bahnstr. 2
|
|
74915 Waibstadt Germany
|
|
|
|
Phone: +49 7263 911484
|
|
EMail: Erik.Guttman@sun.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 37]
|
|
|
|
RFC 2350 Expectations for Computer Security Incident Response June 1998
|
|
|
|
|
|
8 Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
|
|
|
This document and translations of it may be copied and furnished to
|
|
others, and derivative works that comment on or otherwise explain it
|
|
or assist in its implementation may be prepared, copied, published
|
|
and distributed, in whole or in part, without restriction of any
|
|
kind, provided that the above copyright notice and this paragraph are
|
|
included on all such copies and derivative works. However, this
|
|
document itself may not be modified in any way, such as by removing
|
|
the copyright notice or references to the Internet Society or other
|
|
Internet organizations, except as needed for the purpose of
|
|
developing Internet standards in which case the procedures for
|
|
copyrights defined in the Internet Standards process must be
|
|
followed, or as required to translate it into languages other than
|
|
English.
|
|
|
|
The limited permissions granted above are perpetual and will not be
|
|
revoked by the Internet Society or its successors or assigns.
|
|
|
|
This document and the information contained herein is provided on an
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Brownlee & Guttman Best Current Practice [Page 38]
|
|
|
|
|
|
|