draft-ietf-grip-framework-irt-04.txt   draft-ietf-grip-framework-irt-05.txt 
Internet Engineering Task Force Nevil Brownlee Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland INTERNET-DRAFT The University of Auckland
Valid for six months Erik Guttman Valid for six months Erik Guttman
Sun Microsystems Sun Microsystems
Expectations for Security Incident Response Expectations for Security Incident Response
<draft-ietf-grip-framework-irt-04.txt> <draft-ietf-grip-framework-irt-05.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas,
its Working Groups. Note that other groups may also distribute working and its Working Groups. Note that other groups may also distribute
documents as Internet Drafts. This Internet Draft is a product of the working documents as Internet Drafts. This Internet Draft is a
GRIP Working Group of the IETF. product of the GRIP Working Group of the IETF.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six
Internet Drafts may be updated, replaced, or obsoleted by other months. Internet Drafts may be updated, replaced, or obsoleted by
documents at any time. It is not appropriate to use Internet Drafts as other documents at any time. It is not appropriate to use Internet
reference material or to cite them other than as a 'working draft' or Drafts as reference material or to cite them other than as a
'work in progress.' 'working draft' or 'work in progress.'
To learn the current status of any Internet Draft, please check the To learn the current status of any Internet Draft, please check the
'1id-abstracts.txt' listing contained in the Internet Drafts shadow '1id-abstracts.txt' listing contained in the Internet Drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
The purpose of this document is to express the general Internet The purpose of this document is to express the general Internet
community's expectations of Security Incident Response Teams. It community's expectations of Security Incident Response Teams (SIRTs).
is not possible to define a set of requirements that would be It is not possible to define a set of requirements that would be
appropriate for all teams, but it is possible and helpful to appropriate for all teams, but it is possible and helpful to list
list and describe the general set of topics and issues which and describe the general set of topics and issues which are of
are of concern and interest to constituent communities. concern and interest to constituent communities.
SIRT constituents have a legitimate need and right to fully understand SIRT constituents have a legitimate need and right to fully
the policies and procedures of "their" Security Incident Response Team. understand the policies and procedures of "their" Security Incident
One way to support this understanding is to supply detailed information Response Team. One way to support this understanding is to supply
which users may consider, in the form of a formal template completed by detailed information which users may consider, in the form of a
the SIRT. An outline of such a template and a filled in example is formal template completed by the SIRT. An outline of such a
provided. template and a filled in example are provided.
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 28 April 97
Table of Contents Table of Contents
1 Introduction 1 1 Introduction 1
2 Scope..............................................................3 2 Scope.............................................................3
2.1 Publishing a SIRT Policies and Procedures .....................4 2.1 Publishing SIRT Policies and Procedures ......................3
2.2 Relationships between different SIRTs .........................5 2.2 Relationships between different SIRTs ........................4
2.3 Establishing Secure Communications ............................6 2.3 Establishing Secure Communications ...........................5
3 Information, Policies and Procedures...............................7 3 Information, Policies and Procedures..............................6
3.1 Contact Information ...........................................8 3.1 Obtaining the Document........................................7
3.2 Document Updates ..............................................9 3.2 Contact Information ..........................................8
3.3 Charter .......................................................9 3.3 Charter ......................................................9
3.3.1 Mission Statement.......................................10 3.3.1 Mission Statement.......................................9
3.3.2 Constituency............................................10 3.3.2 Constituency............................................9
3.3.3 Sponsoring Organization / Affiliation...................10 3.3.3 Sponsoring Organization / Affiliation...................9
3.3.4 Authority...............................................11 3.3.4 Authority...............................................9
3.4 Policies .....................................................11 3.4 Policies ....................................................10
3.4.1 Types of Incidents and Level of Support.................11 3.4.1 Types of Incidents and Level of Support................10
3.4.2 Co-operation and Interaction with other Organizations...12 3.4.2 Co-operation, Interaction and Disclosure of
3.4.3 Reporting and Disclosure................................13 Information............................................11
3.4.4 Communication and Authentication........................14 3.4.3 Communication and Authentication.......................13
3.4.5 Point of Customer Contacts..............................14 3.5 Services ....................................................14
3.5 Services .....................................................15 3.6 Incident Reporting Forms ....................................14
3.6 Incident Reporting Forms .....................................15 3.7 Disclaimers .................................................15
3.7 Disclaimers ..................................................16
4 Appendix A: Glossary of Terms 17 Appendix A: Glossary of Terms 15
5 Appendix B: Related Material 18 Appendix B: Related Material 17
6 Appendix C: Known Security Incident Response Teams 19 Appendix C: Known Security Incident Response Teams 18
7 Appendix D: Outline for SIRT Template 21 Appendix D: Outline for SIRT Template 19
8 Appendix E: Example - 'filled-in' Template for a SIRT 22 Appendix E: Example - 'filled-in' Template for a SIRT 20
9 References 29 4 Acknowlegments 31
10 Security Considerations 29 5 References 32
11 Authors' Addresses 29 6 Security Considerations 32
Expectations for Security Incident Response 26 March 97 7 Authors' Addresses 32
1 Introduction 1 Introduction
The GRIP Working Group was formed to create a document that describes The GRIP Working Group was formed to create a document that describes
the community's expectations of security incident response teams the community's expectations of security incident response teams
(SIRTs). Although the need for such a document originated in the (SIRTs). Although the need for such a document originated in the
general Internet community, the expectations expressed should also general Internet community, the expectations expressed should also
closely match those of more restricted communities. closely match those of more restricted communities.
In the past there have been misunderstandings regarding what to expect Expectations for Security Incident Response 15 April 97
from SIRTs. 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 In the past there have been misunderstandings regarding what to
by the term "Security Incident Response Team." For the purposes of expect from SIRTs. The goal of this document is to provide a
this document, a SIRT is a team that performs, coordinates, and supports framework for presenting the important subjects (related to incident
the response to security incidents that involve sites within a defined response) that are of concern to the community.
constituency (see Appendix A for a more complete definition). Any
group calling itself a SIRT for a specific constituency must therefore Before continuing, it is important to clearly understand what is
react to reported security incidents, and to threats to "their" meant by the term "Security Incident Response Team." For the
constituency in ways which the specific community agrees to be in its purposes of this document, a SIRT is a team that performs,
general interest. coordinates, and supports the response to security incidents that
involve sites within a defined constituency (see Appendix A for a
more complete definition). Any group calling itself a SIRT for a
specific constituency must therefore react to reported security
incidents, and to threats to "their" constituency in ways which the
specific community agrees to be in its general interest.
Since it is vital that each member of a constituent community be Since it is vital that each member of a constituent community be
able to understand what is reasonable to expect of their team, A SIRT able to understand what is reasonable to expect of their team, a SIRT
should make it clear who belongs to their constituency and define the should make it clear who belongs to their constituency and define the
services the team offers to the community. Additionally, each SIRT services the team offers to the community. Additionally, each SIRT
should publish its policies and operating procedures. Similarly, these should publish its policies and operating procedures. Similarly,
same constituents need to know what is expected of them in order for these same constituents need to know what is expected of them in
them to receive the services of their team. This requires that the order for them to receive the services of their team. This requires
team also publish how and where incidents should be reported. that the team also publish how and where to report incidents.
This document details a template which will be used by SIRTs to This document details a template which will be used by SIRTs to
communicate this information to their constituents. The constituents communicate this information to their constituents. The constituents
should certainly expect a SIRT to provide the services they describe in should certainly expect a SIRT to provide the services they describe
the completed template. in the completed template.
It must be emphasised that without active participation from users, the It must be emphasised that without active participation from users,
effectiveness of the SIRT's services can be greatly diminished. This the effectiveness of the SIRT's services can be greatly diminished.
is particularly the case with reporting. At a minimum, users need to This is particularly the case with reporting. At a minimum, users
know that they should report security incidents, and know how and where need to know that they should report security incidents, and know how
they should report them to. and to where they should report them.
Many computer security incidents originate outside local community Many computer security incidents originate outside local community
boundaries and affect inside sites, others originate inside the local boundaries and affect inside sites, others originate inside the local
community and affect hosts or users on the outside. Often, therefore, community and affect hosts or users on the outside. Often,
therefore, the handling of security incidents will involve multiple
Expectations for Security Incident Response 26 March 97 sites and potentially multiple SIRTs. Resolving these incidents will
require cooperation between individual sites and SIRTs, and between
the handling of security incidents will involve the cooperation of SIRTs.
multiple sites and potentially multiple SIRTs. The coordination of
activities across communities and organization requires that the
parties understand who they are dealing with, and what sort of policies
they have in place.
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 SIRTs. Resolving these incidents will require
cooperation between individual sites and SIRTs, and between SIRTs.
Constituent communities need to know exactly how their SIRT will be Constituent communities need to know exactly how their SIRT will be
working with other SIRTs and organizations outside their constituency, working with other SIRTs and organizations outside their
and what information will be shared. constituency, and what information will be shared.
The rest of this document describes the set of topics and issues that The rest of this document describes the set of topics and issues that
SIRTs need to elaborate for their constituents. However, there is no SIRTs need to elaborate for their constituents. However, there is no
attempt to specify the "correct" answer to any one topic area. Rather, attempt to specify the "correct" answer to any one topic area.
each topic is discussed it terms of what that topic means. For example, Rather, each topic is discussed in terms of what that topic means.
five types of policy statements are listed (representing those policies For example, five types of policy statements are listed
of interest to the community), but the content of any one of them will
necessarily be specific to a given team.
Chapter two provides an overview of three major areas: The publishing Expectations for Security Incident Response 15 April 97
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.
These topics are condensed into an outline template for ease of use by
the community, and is found in Appendix D. This template can be used
by constituents to elicit information from their SIRT, and it provides
criteria with which to measure their team's performance.
It is the working group's sincere hope that through the clarification (representing those policies of interest to the community), but the
content of any one of them will necessarily be specific to a given
team.
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 SIRT.
It is the working group's sincere hope that through clarification
of the topics in this document, understanding between the community of the topics in this document, understanding between the community
and its SIRTs will be increased. and its SIRTs will be increased.
2 Scope 2 Scope
The interactions between a constituent community and an incident The interactions between an incident response team and its
response team require first that the community understands the constituent community response team require first that the community
policies and procedures of the response team. Second, since many understand the policies and procedures of the response team. Second,
response teams collaborate to handle incidents, the community must since many response teams collaborate to handle incidents, the
also understand the relationship between their response team and community must also understand the relationship between their
response team and other teams. Finally, many interactions will take
Expectations for Security Incident Response 26 March 97 advantage of existing public infrastructures, so the community needs
to know how those communications will be protected. Each of these
other teams. Finally, many interactions will take advantage of subjects will be described in more detail in the following three
existing public infrastructures and the community needs to know how sections.
those communications are going to be protected. Each of these subjects
will be described in more detail in the following three sections.
2.1 Publishing a SIRT Policies and Procedures 2.1 Publishing SIRT Policies and Procedures
Each user who has access to a Security Incident Response Team should Each user who has access to a Security Incident Response Team should
know as much as possible about services of and interactions with this know as much as possible about the services of and interactions with
team long before he or she actually needs them. this team long before he or she actually needs them.
A clear statement of the policies and procedures of a SIRT helps the A clear statement of the policies and procedures of a SIRT helps the
constituent understand how best to report incidents and what support to constituent understand how best to report incidents and what support
expect afterwards. Will the SIRT assist in resolving the incident? to expect afterwards. Will the SIRT assist in resolving the
Will it provide help in avoiding incidents in the future? Clear incident? Will it provide help in avoiding incidents in the
expectations, particularly of the limitations of the services provided future? Clear expectations, particularly of the limitations of the
by a SIRT, will make interaction with it more efficient and effective. services provided by a SIRT, will make interaction with it more
efficient and effective.
There are different kinds of response teams. Some that have very There are different kinds of response teams: some have very broad
broad constituencies (e.g., CERT Coordination Center and the Internet), constituencies (e.g., CERT Coordination Center and the Internet),
others that have more bounded constituencies (e.g., DFN-CERT, CIAC), others have more bounded constituencies (e.g., DFN-CERT, CIAC),
and still others that have very restricted constituencies (e.g., 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.
As a SIRT provides a service to a this clearly defined constituency, Expectations for Security Incident Response 15 April 97
it should communicate all necessary information about its policies
and services in a suitable form. It is important to understand that commercial response teams, corporate response teams). Regardless
not all policies and procedures must be publicly available. For of the type of response team, the constituency supported by it
example, it is not necessary to understand the internal operation of must be knowledgeable about the team's policies and procedures.
a team in order to interact with it, as when reporting an incident or Therefore, it is mandatory that response teams publish such
receiving guidance on how to analyze or secure one's systems. information to their constituency.
A SIRT 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.
In the past, some teams supplied a kind of Operational Framework, In the past, some teams supplied a kind of Operational Framework,
others provided Frequently Asked Questions (FAQ), while still others provided a Frequently Asked Questions list (FAQ), while still
others wrote papers for distribution at user conferences or sent others wrote papers for distribution at user conferences or sent
newsletters. newsletters.
Another efficient way to communicate the relevant information to all We recommend that each SIRT publish its guidelines and procedures on
concerned, not only constituents but also other teams or organizations, its own information server (e.g. a World Wide Web server). This
would be for each SIRT to publish its guidelines and procedures on its would allow constituents to easily access it, though the problem
own information server. This would allow constituents to easily access remains of how a constituent can find "his" or "her" team; people
within the constituency have to discover that there is a SIRT "at
Expectations for Security Incident Response 26 March 97 their disposal."
it, although this does not address the problem of how a constituent or It is foreseen that completed SIRT templates will soon become
will find "his" or "her" team. People within the constituency have to searchable by modern search engines, which will aid in distributing
discover that there is a SIRT "at their disposal." It is foreseen that information about the existence of SIRTs and basic information
completed SIRT templates will soon become searchable by modern search required to approach them.
engines. This will aid in distributing information about the existence
of SIRTs and basic information required to approach them.
It would be very useful to have a central repository containing all the It would be very useful to have a central repository containing all
completed SIRT templates. No such repository presently exists. This the completed SIRT templates. No such repository exists at the time
might change in the future. of writing, though this might change in the future.
Regardless of the source from which the information is retrieved, Regardless of the source from which the information is retrieved,
the user of the template must check its authenticity. It is highly the user of the template must check its authenticity. It is highly
recommended that such vital documents be protected by digital recommended that such vital documents be protected by digital
signatures. These will allow user can verify that the template signatures. These will allow the user to verify that the template
was indeed published by the SIRT and that it has not been modified was indeed published by the SIRT and that it has not been tampered
thereafter. This document assumes the reader has familiarity with with. This document assumes the reader is familiar with the proper
the proper use of digital signatures to determine whether a document use of digital signatures to determine whether a document is
is authentic. authentic.
2.2 Relationships between different SIRTs 2.2 Relationships between different SIRTs
In some cases a SIRT may be able to operate effectively on its own In some cases a SIRT may be able to operate effectively on its own
and in close cooperation with its constituency. But with todays and in close cooperation with its constituency. But with today's
international networks it is much more likely that most of the international networks it is much more likely that most of the
incidents handled by a SIRT will involve parties external to its incidents handled by a SIRT will involve parties external to its
constituency. Therefore the team will need to interact with other constituency. Therefore the team will need to interact with other
SIRTs and sites outside their constituency.
The constituent community should be clear about the nature and Expectations for Security Incident Response 15 April 97
extent of this collaboration, as very sensitive information about
individual constituents may be disclosed in the process.
Such interactions could include asking other teams for advice, SIRTs and sites outside its constituency.
disseminating knowledge of problems and working cooperatively
to resolve a security incident effecting one or more of the SIRTs' 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-SIRT 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 SIRTs'
constituencies. constituencies.
In establishing relationships to support such interactions, SIRTs will In establishing relationships to support such interactions, SIRTs
need to decide what kinds of agreements can exist between them so as to must decide what kinds of agreements can exist between them so as to
share yet safeguard information, whether this relationship can be share yet safeguard information, whether this relationship can be
disclosed, and if so to whom. disclosed, and if so to whom.
Expectations for Security Incident Response 26 March 97 Note that there is a difference between a peering agreement, where
the SIRTs involved agree to work together and share information, and
Note that there is a difference between a peering agreement, where the simple co-operation, where a SIRT (or any other organization) simply
SIRTs involved agree to work together and share information, and simple contacts another SIRT and asks for help or advice.
co-operation, where a SIRT (or any other organization) simply contacts
another SIRT and asks for help or advice.
Although the establishing of such relationships is very important and Although the establishment of such relationships is very important
affect the ability of a SIRT to support its constituency, it is up to and affects the ability of a SIRT to support its constituency, it is
the teams involved to decide about the details. It is beyond the scope up to the teams involved to decide about the details. It is beyond
of this document to make recommendations for this process. But the the scope of this document to make recommendations for this process.
same set of information used to set expectations for a user community However, the same set of information used to set expectations for a
regarding sharing of information will help other parties to understand user community regarding sharing of information will help other
the objectives and services of a specific SIRT, supporting a first parties to understand the objectives and services of a specific
contact. SIRT, supporting a first contact.
2.3 Establishing Secure Communications 2.3 Establishing Secure Communications
Once one party has decided to share information with another party, or Once one party has decided to share information with another party,
two parties have agreed to share information or work together - as or two parties have agreed to share information or work together - as
required for the coordination of Security Incident Response - all required for the coordination of security incident response - all
parties involved need secure communications channels. ("Secure" hereby parties involved need secure communications channels. (In this
relates to the protected transmission of information shared between context, "secure" refers to the protected transmission of information
different parties and not the appropriate use of the information by the shared between different parties, and not to the appropriate use of
parties.) the information by the parties.)
The goals of secure communication are: The goals of secure communication are:
- Confidentiality: - Confidentiality:
Can somebody else access the content of the communication? Can somebody else access the content of the communication?
- Integrity: - Integrity:
Can somebody else manipulate the content of the communication? Can somebody else manipulate the content of the communication?
- Authenticity: - Authenticity:
Am I communicating with the "right" person? Am I communicating with the "right" person?
It is very easy to send forged e-mail, and not hard to establish a Expectations for Security Incident Response 15 April 97
(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 cryptographic keys used in secure communication:
Expectations for Security Incident Response 26 March 97 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
cryptographic keys used in secure communication:
- Public keys (for techniques like PGP and PEM): - Public keys (for techniques like PGP and PEM):
Because they are accessible through the internet, they must be Because they are accessible through the Internet, public keys must
authenticated before usage. While PGP relies on a be authenticated before use. While PGP relies on a "Web of Trust"
"Web of Trust" - users sign the keys of other users - PEM relies (where users sign the keys of other users), PEM relies on a
on a hierarchy - certification authorities sign the keys of users. hierarchy (where certification authorities sign the keys of users).
- Secret keys (for techniques like DES and PGP/conventional - Secret keys (for techniques like DES and PGP/conventional
encryption): Because they must be known to sender and receiver, encryption): Because these must be known to both sender and
they must be exchanged before the communication via a secure receiver, secret keys must be exchanged before the communication
channel. via a secure channel.
Communication is critical for all aspects of incident response. A team Communication is critical to all aspects of incident response. A
can best support the use of the above-mentioned techniques by gathering team can best support the use of the above-mentioned techniques by
all relevant information, in a consistent way. Specific requirements gathering all relevant information, in a consistent way. Specific
(like calling a specific number for checking the authenticity requirements (such as calling a specific number to check the
of keys) should be explained right away. SIRT templates provide a authenticity of keys) should be clear from the start. SIRT templates
standardized vehicle for delivering this information. provide a standardized vehicle for delivering this information.
It is beyond the scope of this document to address all the technical It is beyond the scope of this document to address the technical
and administrative problems of secure communications. The point is and administrative problems of secure communications. The point is
that response teams must support and use a method to secure the that response teams must support and use a method to secure the
communications between themselves and their constituents (or other communications between themselves and their constituents (or other
response teams). Whatever the mechanism is, the level of protection response teams). Whatever the mechanism is, the level of protection
it provides must be acceptable to the constituent community. it provides must be acceptable to the constituent community.
3 Information, Policies and Procedures 3 Information, Policies and Procedures
In chapter 2, it was mentioned that the policies and procedures of a In chapter 2 it was mentioned that the policies and procedures of a
response team need to be published to their constituent community. response team need to be published to their constituent community.
In this chapter we will list all the types of information that the In this chapter we will list all the types of information that the
community needs to receive from its response team. How this community needs to receive from its response team. How this
information is communicated to a community will differ from team to information is communicated to a community will differ from team to
team, as will the specific information content. The intent here is team, as will the specific information content. The intent here is
to clearly describe the various kinds of information that a to clearly describe the various kinds of information that a
constituent community expects from its response team. constituent community expects from its response team.
To make it easier to understand all issues and topics relevant to the To make it easier to understand the issues and topics relevant to the
interaction of constituents with "their" SIRT, we suggest that a SIRT interaction of constituents with "their" SIRT, we suggest that a SIRT
publish all information, policies and procedures addressing their publish all information, policies, and procedures addressing its
constituency as a document, following template given in Appendix D. constituency as a document, following the template given in Appendix
The template structure arranges items, making it easy to supply D. The template structure arranges items, making it easy to supply
specific information, was done for the example in Appendix E. While
no recommendations are made as to what a SIRT should adopt for their
policy or procedures, different possibilities are outlined to give some
examples. The most important thing is that a SIRT has a policy and that
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 15 April 97
that those who interact with the SIRT can obtain and understand it. 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 SIRT should adopt for its
policy or procedures, different possibilities are outlined to give
some examples. The most important thing is that a SIRT have a policy
and that that those who interact with the SIRT be able to obtain and
understand it.
As always, not every aspect for every environment and/or team can As always, not every aspect for every environment and/or team can
be covered. This outline should be seen as a suggestion. Each team be covered. This outline should be seen as a suggestion. Each team
should feel free to include whatever they think is necessary for should feel free to include whatever they think is necessary to
supporting their constituency. support its constituency.
3.1 Contact Information 3.1 Obtaining the Document
Full details of how to contact the SIRT should be listed here, although Details of a SIRT change with time, so the completed template must
this might be very different for different teams. Some might choose to indicate when it was last changed. Additionally, information should
restrict the availability of names of all team members. No further be provided concerning how to find out about future updates. Without
clarification is given when the meaning of the item can be assumed. this, it is inevitable that misunderstandings and misconceptions will
arise over time; an outdated document 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
cover the constituency and any other
groups the SIRT has frequent
interactions with.
Digital signatures should be used
for update messages sent by a SIRT.
- 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.
Expectations for Security Incident Response 15 April 97
3.2 Contact Information
Full details of how to contact the SIRT 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 SIRT - Name of the SIRT
- Mailing Address - Mailing Address
- Time zone This is useful for coordinating - Time zone This is useful for coordinating
incidents which cross time zones. incidents which cross time zones.
- Telephone number - Telephone number
skipping to change at page 8, line 41 skipping to change at page 8, line 35
- Other telecommunication Some teams might provide secure - Other telecommunication Some teams might provide secure
voice communication (e.g. STU III). voice communication (e.g. STU III).
- Electronic mail address - Electronic mail address
- Public keys and encryption The use of specific techniques - Public keys and encryption The use of specific techniques
depends on the ability of the depends on the ability of the
communication partners to have communication partners to have
access to programs, keys and so on. access to programs, keys and so on.
Relevant information should be Relevant information should be
outlined so users can determine given to enable users to determine
if and how they can make use of if and how they can make use of
secure communication while encrypted communication while
interacting with the SIRT. interacting with the SIRT.
- Team members - Team members
- Other information The operating hours and holiday - Operating Hours The operating hours and holiday
schedule should be provided here. schedule should be provided here.
Is there a 24 hour hotline? Is Is there a 24 hour hotline?
there any specific customer contact
info? (See also section 3.4.5).
Expectations for Security Incident Response 26 March 97
3.2 Document Updates
Details of a SIRT change with time, so the completed template must
indicate when it was last changed. Additionally, information should be
provided to learn about how to find out about future updates. Without
this, it is inevitable that misunderstandings and misconceptions will
arise over time; an outdated document will 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
cover the constituency and any other
groups the SIRT has frequent
interactions with.
Digital signatures should be used - Additional Contact Info Is there any specific customer
for update messages sent by a SIRT. contact info?
- Location of the document The location where a current version More detailed contact information can be provided. This might
of the document should be accessible include different contacts for different services, or might be a
through a team's online information list of online information services. If specific procedures for
services. Constituents can then access to some services exist (for example addresses for mailing
easily learn more about the team and list requests), these should be explained here.
check for recent updates.
This online version should also be Expectations for Security Incident Response 28 April 97
accompanied by a digital signature,
3.3 Charter 3.3 Charter
Every SIRT must have a charter which specifies what it is to do, and Every SIRT must have a charter which specifies what it is to do, and
the authority under which it will do it. The charter should include the authority under which it will do it. The charter should include
at least the following statements: at least the following items:
- Mission statement - Mission statement
- Constituency - Constituency
- Sponsor / affiliation - Sponsorship / affiliation
- Authority - Authority
Expectations for Security Incident Response 26 March 97
3.3.1 Mission Statement 3.3.1 Mission Statement
The mission statement should focus on the team's core activities, The mission statement should focus on the team's core activities,
already stated in the definition of a SIRT. In order to be considered already stated in the definition of a SIRT. In order to be
a Security Incident Response Team, the team must support the reporting considered a Security Incident Response Team, the team must support
of incidents and support its constituency by dealing with incidents. the reporting of incidents and support its constituency by dealing
with incidents.
The goals and purposes of a team are especially important, and require The goals and purposes of a team are especially important, and
clear, unambiguous definitions. require clear, unambiguous definition.
3.3.2 Constituency 3.3.2 Constituency
A SIRT's constituency can be determined in many ways. For example it A SIRT's constituency can be determined in any of several ways. For
could be a company's employees or its paid subscribers, or it could be example it could be a company's employees or its paid subscribers,
defined in terms of a technological focus, such as the users of a or it could be defined in terms of a technological focus, such as
particular operating system. the users of a particular operating system.
The definition of constituency should create a perimeter around the The definition of the constituency should create a perimeter around
group to whom the team will provide service. The policy section of the group to whom the team will provide service. The policy section
the document (see below) should explain how requests from outside the of the document (see below) should explain how requests from outside
perimeter will be handled. this perimeter will be handled.
If a SIRT decide, not to disclosure their constituency, they should If a SIRT decides not to disclose its constituency, it should
explain the reasoning behind this decision. For example for-fee explain the reasoning behind this decision. For example, for-fee
SIRTs will not list their clients but declare that they provide SIRTs will not list their clients but will declare that they provide
a service to a large group of customers that are kept confidential a service to a large group of customers that are kept confidential
because of the clients' contract. because of the clients' contracts.
Constituencies might overlap, as when an ISP provides a SIRT, but Constituencies might overlap, as when an ISP provides a SIRT which
delivers services to customer sites which also have SIRTs. The delivers services to customer sites that also have SIRTs. The
Authority section of the document (see below) should make such Authority section of the SIRT's description (see below) should
relationships clear. make such relationships clear.
3.3.3 Sponsoring Organization / Affiliation 3.3.3 Sponsoring Organization / Affiliation
The sponsoring organization, which authorizes the actions of the SIRT, The sponsoring organization, which authorizes the actions of the
should be given next. Knowing this will help the users to understand SIRT, should be given next. Knowing this will help the users to
the background and setup of the SIRT. It is vital information for
building up trust between a constituent and a SIRT.
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 28 April 97
understand the background and set-up of the SIRT, and it is vital
information for building trust between a constituent and a SIRT.
3.3.4 Authority 3.3.4 Authority
Based on the relationship between team and constituency this section This section will vary greatly from one SIRT to another, based on
will be very different from one team to another. While an the relationship between the team and its constituency. While an
organizational SIRT will be given its authority by the management, organizational SIRT will be given its authority by the management
a community SIRT will be supported and chosen by the community, of the organization, a community SIRT will be supported and chosen
usually in a advisory role. by the community, usually in a advisory role.
SIRTs may not have authority to intervene in the operation of all the A SIRT may or may not have the authority to intervene in the
systems within their perimeter. They should identify the scope of operation of all of the systems within its perimeter. It should
their control as distinct from the perimeter of their constituency; if identify the scope of its control as distinct from the perimeter of
other SIRTs operate hierarchically within their perimeter, these should its constituency. If other SIRTs operate hierarchically within its
be identified and addressed here. perimeter, this should be mentioned here, and the related SIRTs
identified.
A disclosure of a team's authority may expose it to claims of Disclosure of a team's authority may expose it to claims of
liability. Every team should seek legal advice on these matters. liability. Every team should seek legal advice on these matters.
(See section 3.7 for more on liability.) (See section 3.7 for more on liability.)
3.4 Policies 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 3.4.1 Types of Incidents and Level of Support
The types of incident which the team is able to address and the 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 level of support which the team will offer when responding to each
type of incident should be summarized here in list form. The Services type of incident, should be summarized here in list form. The
section (see below) provides opportunity for more detailed definition Services section (see below) provides the opportunity to give more
and to address non-incident related topics. detailed descriptions, and to address non-incident-related topics.
The level of support might change, depending on factors like workload The level of support may change depending on factors such as the
or completeness of information available. Such factors should be team's workload and the completeness of the information available.
outlined and their impact should be explained. As a list of known Such factors should be outlined and their impact should be
types of incidents will be incomplete with regard to possible or future explained. As a list of known types of incidents will be incomplete
incidents, a SIRT should also give some background on the "default" with regard to possible or future incidents, a SIRT should also give
support for each reported incident. some background on the "default" support for incident types not
otherwise mentioned.
The team should state whether it will act on information it receives The team should state whether it will act on information it receives
about vulnerabilities which create opportunities for future incidents. about vulnerabilities which create opportunities for future
A commitment to act on such information on behalf of its constituency is incidents. A commitment to act on such information on behalf of its
regarded as an optional pro-active service policy rather than a core constituency is regarded as an optional proactive service policy
service requirement for a SIRT. rather than a core service requirement for a SIRT.
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 15 April 97
3.4.2 Co-operation and Interaction with other Organizations 3.4.2 Co-operation, Interaction and Disclosure of Information
This section should make explicit which related groups with which the This section should make explicit which related groups the SIRT
SIRT routinely interacts with. Such interactions are not related to routinely interacts with. Such interactions are not necessarily
the Security Incident Response provided, but are used to facilitate related to the security incident response provided, but are used to
better cooperation on technical topics or services. By no means should facilitate better cooperation on technical topics or services. By
details about cooperation agreements be given out, the main objective no means need details about cooperation agreements be given out; the
of this section is to give the constituency a basic understanding main objective of this section is to give the constituency a basic
what kind of interactions are established and what their purpose is. understanding of what kind of interactions are established and what
Examples of these are listed below. their purpose is.
The reporting and disclosure policy should make clear who will be
the recipients of a SIRT's report in each circumstance. It should
also note whether the team will expect to operate through another
SIRT or directly with a member of another constituency over matters
specifically concerning that member.
Important examples of related groups a SIRT will interact with are
listed below.
Incident Response Teams: Incident Response Teams:
A SIRT will often need to interact with other SIRTs. For example A SIRT will often need to interact with other SIRTs. For example
a SIRT within a large company may need to report incidents to a a SIRT within a large company may need to report incidents to a
national SIRT, and a national SIRT may need to report incidents national SIRT, and a national SIRT may need to report incidents
to national SIRTs in other countries to deal with all sites to national SIRTs in other countries to deal with all sites
involved in a large-scale attack. involved in a large-scale attack.
Collaboration between SIRTs 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).
- Reporting observations from within the constituency indicating
suspected or confirmed incidents outside it.
- Acting on reports of incidents occurring outside the
constituency.
- Passing information about vulnerabilities to vendors, to
partner SIRTs or directly to affected sites lying within or
outside the constituency.
- Feedback to parties reporting incidents or vulnerabilities.
- The provision of contact information relating to members of
Expectations for Security Incident Response 15 April 97
the constituency, members of other constituencies, other
SIRTs, or law-enforcement agencies.
Vendors: Vendors:
Larger vendors have their own SIRTs, but smaller vendors may not. Larger vendors have their own SIRTs, but smaller vendors may not.
In such cases a SIRT will need to work directly with a vendor to In such cases a SIRT will need to work directly with a vendor to
suggest improvements or modifications, to analyse the technical suggest improvements or modifications, to analyse the technical
problem or to test provided solutions. problem or to test provided solutions.
Law-enforcement agencies: Law-enforcement agencies:
These include the police and other investigative agencies. SIRTs These include the police and other investigative agencies. SIRTs
and users of the template should be sensitive to local laws and and users of the template should be sensitive to local laws and
regulations, which may vary considerably in different countries. regulations, which may vary considerably in different countries.
A SIRT might advise on technical details of attacks or seek advice A SIRT might advise on technical details of attacks or seek
on the legal implications of an incident. Local laws and advice on the legal implications of an incident. Local laws and
regulations may include specific reporting and confidentiality regulations may include specific reporting and confidentiality
requirements. requirements.
Press: Press:
A SIRT may be approached by the Press for information and comment A SIRT may be approached by the press for information and comment
from time to time. This is discussed in more detail immediately from time to time.
below.
An explicit policy concerning disclosure to the press can be
helpful, particularly in clarifying the expectations of a SIRT's
constituency. The press policy will have to clarify the same
topics as above more specifically, as the constituency will
usually be very sensitive to press contacts.
Other: Other:
This might include research activities or the relation to the This might include research activities or the relation to the
sponsoring organization. sponsoring organization.
Expectations for Security Incident Response 26 March 97 The default status of any and all security-related information which
a team receives will usually be 'confidential,' but rigid adherence
3.4.3 Reporting and Disclosure to this makes the team to appear to be an informational 'black
hole,' which may reduce the likelihood of the team's obtaining
The default status of any and all security-related information which a cooperation from clients and from other organizations. The SIRT's
team receives will usually be 'confidential,' but rigid adherence to template should define what information it will report or disclose,
this makes the team to appear as a 'black hole.' Its template should to whom, and when.
define what information it will report or disclose, to whom, and when.
Different teams are likely to be subject to different legal restraints Different teams are likely to be subject to different legal
requiring or limiting disclosure, especially if they work in different restraints requiring or limiting disclosure, especially if they work
jurisdictions. In addition, they may have reporting requirements in different jurisdictions. In addition, they may have reporting
imposed by their sponsoring organization. Each team's template should requirements imposed by their sponsoring organization. Each team's
specify any such restraints, both to clarify users' expectations and to template should specify any such constraints, both to clarify users'
inform other teams. expectations and to inform other teams.
Conflicts of interest, particularly in commercial matters, may also Conflicts of interest, particularly in commercial matters, may also
restrain disclosure by a team; this document does not recommend on restrain disclosure by a team; this document does not recommend on
how such conflicts should be addressed. how such conflicts should be addressed.
'Disclosure' includes (but is maybe not limited to): A team will normally collect statistics. If statistical information
- Reporting incidents within the constituency to other teams. By
this, site related information might become public knowledge,
accessible for everybody, especially the press.
- Handling incidents occurring within the constituency, but
reported from outside it.
- Reporting observations from within the constituency indicating
suspected or confirmed incidents outside it.
- Acting on reports of incidents occurring outside the constituency.
- Passing information about vulnerabilities to vendors, to Partner
SIRTs or directly to affected sites lying within or outside the
constituency.
- Feed-back to parties reporting incidents or vulnerabilities.
- The provision of contact information relating to members of the
constituency, members of other constituencies, other SIRTs or
law-enforcement agencies.
An explicit policy concerning disclosure to the Press can be helpful,
particularly in clarifying the expectations of a SIRT's constituency.
The press policy will have to clarify the same topics as above more
specifically, as the constituency will usually be very sensitive
Expectations for Security Incident Response 26 March 97
towards press contacts.
The reporting and disclosure policy should make clear who will be the Expectations for Security Incident Response 28 April 97
recipients of a SIRT's report in each circumstance. It should also
note whether the team will expect to deal through another SIRT
or directly with a member of another constituency over matters directly
involving that member.
A team will normally collect statistics. If such information are is distributed, the template's reporting and disclosure policy
distributed, the template's reporting and disclosure policy should should say so, and should describe how to obtain such statistics.
say so, and should list methods to obtain such statistics.
3.4.4 Communication and Authentication 3.4.3 Communication and Authentication
Methods of secure and verifiable communication should be established. Methods of secure and verifiable communication should be established.
This is necessary for communication between SIRTs and between a SIRT This is necessary for communication between SIRTs and between a SIRT
and its constituents. The template should include public keys or and its constituents. The template should include public keys or
pointers to them, including key fingerprints, together with guidelines pointers to them, including key fingerprints, together with
on how to use this information to check authenticity and how to deal guidelines on how to use this information to check authenticity and
with corrupted information (for example where to report this fact to). how to deal with corrupted information (for example where to report
this fact).
At the moment it is recommended that every SIRT has - if possible - as At the moment it is recommended that as a minimum every SIRT have
a minimum, a PGP key available. Teams may also make other mechanisms (if possible), a PGP key available. A team may also
available (for example PEM, MOSS, S/MIME), according to its needs and make other mechanisms available (for example PEM, MOSS, S/MIME),
the needs of its constituents. Note however, that SIRTs and users according to its needs and the needs of its constituents. Note
should be sensitive to local laws and regulations. Some countries do however, that SIRTs and users should be sensitive to local laws and
not allow strong encryption or enforce specific policies on the use of regulations. Some countries do not allow strong encryption, or
encryption technology. In addition to encrypting sensitive information enforce specific policies on the use of encryption technology. In
whenever possible, correspondence should include digitally signatures. addition to encrypting sensitive information whenever possible,
(Please note, that in most countries, the protection of authenticity correspondence should include digital signatures. (Please note that
by using digital signatures is not affected by existing encryption in most countries, the protection of authenticity by using digital
regulations.) signatures is not affected by existing encryption regulations.)
For communication via telephone or facsimile a SIRT may keep secret For communication via telephone or facsimile a SIRT may keep secret
authentication data for parties with whom they may deal, such as an authentication data for parties with whom they may deal, such as an
agreed password or phrase. agreed password or phrase. Obviously, such secret keys must not be
published, though their existence may be.
3.4.5 Point of Customer Contacts
More detailed contact information might be provided. This might
include different contacts for different services or might be a list
of online information services. If specific procedures for access to
some services exist (like addresses for mailing list requests) these
should be explained here.
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 15 April 97
3.5 Services 3.5 Services
Services provided by each SIRT can be differentiated by whether they Services provided by a SIRT can be differentiated according to
relate to the main task, which is incident response, or are provided whether they relate to the main task, which is incident response, or
in addition (optional in regard to the definition of a SIRT). are provided in addition to it, i.e. are optional in regard to the
definition of a SIRT.
Incident response, which usually includes: Incident response usually includes:
- Verification Help with the verification of - Verification Help in determining whether an
incidents, as well as their scope. incident has really occurred, and
its scope.
- Technical Assistance This may include analysis of - Technical Assistance This may include analysis of
compromised systems. compromised systems.
- Eradication Elimination of the effects of a - Eradication Elimination of the cause of a
security incident. security incident (the vulnerability
exploited), and its effects (for
example, continuing access to the
system by an intruder).
- Recovery Aid in restoring affected systems - Recovery Aid in restoring affected systems
and services to their status before and services to their status before
the security incident. the security incident.
- Notification of other involved parties - Coordination Notification of other involved
parties.
Additional or optional services, which might include: Additional or optional services might include:
- Information provision This might include an archive of - Information provision This might include an archive of
known vulnerabilities, patches or known vulnerabilities, patches or
resolutions of past problems. resolutions of past problems, or
- Security Tools advisory mailing lists.
- Security Tools This may include tools for auditing
a Site's security.
- Education and training - Education and training
- Product evaluation - Product evaluation
- Site security auditing and consulting - Site security auditing and consulting
3.6 Incident Reporting Forms 3.6 Incident Reporting Forms
The use of reporting forms makes it simplier for both sides, users and The use of reporting forms makes it simpler for both users and
teams, to deal with incidents. The constituent may prepare answers to teams to deal with incidents. The constituent can prepare answers to
various important questions before he or she actually contacts the team various important questions before he or she actually contacts the
and therefore come well prepared. The team gets all the necessary team, and can therefore come well prepared. The team gets all the
information at once with the first report and can proceed efficiently.
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 15 April 97
Depending on the objectives and services of a single SIRT, multiple necessary information at once with the first report and can proceed
forms may be used, for example a reporting form for a new vulnerability efficiently.
will be very different for the form used for reporting incidents.
Depending on the objectives and services of a particular SIRT,
multiple forms may be used, for example a reporting form for a new
vulnerability may be very different from the form used for reporting
incidents.
It is most efficient to provide forms through the online information It is most efficient to provide forms through the online information
services of the team. The exact pointers to them should be given in services of the team. The exact pointers to them should be given in
the document, together with statements about appropriate use and the SIRT description document, together with statements about
guidelines, for when and how to use the forms. If separate e-mail appropriate use, and guidelines for when and how to use the forms.
addresses are supported for form based reporting, they should be If separate e-mail addresses are supported for form-based reporting,
listed here again. they should be listed here again.
One example for such form is the Incident Reporting Form provided by One example of such a form is the Incident Reporting Form provided by
the CERT Coordination Center: the CERT Coordination Center:
- ftp://info.cert.org/incident_reporting_form - ftp://info.cert.org/incident_reporting_form
3.7 Disclaimers 3.7 Disclaimers
Although the document does not constitute a contract, liability might Although the SIRT description document does not constitute a
conceivably result from its descriptions of services and purposes. The contract, liability may conceivably result from its descriptions of
inclusion of a disclaimer at the end of the template is therefore services and purposes. The inclusion of a disclaimer at the end of
recommended and should warn the user about possible limitations. the template is therefore recommended and should warn the user about
possible limitations.
It should be noted that some forms of reporting or disclosure relating
to specific incidents or vulnerabilities can also imply liability, and
SIRTs should consider the inclusion of disclaimers in such material.
In situations where the original version of a document must be In situations where the original version of a document must be
translated into another language, the translation should carry a translated into another language, the translation should carry a
disclaimer and a pointer to the original. For example: disclaimer and a pointer to the original. For example:
Although we tried to carefully translate the original Although we tried to carefully translate the original
document from German into English, we can not be certain document from German into English, we can not be certain
that both documents express the same thoughts in the same that both documents express the same thoughts in the same
level of detail and correctness. In all cases, where there level of detail and correctness. In all cases, where there
is a difference between both versions, the German version is a difference between both versions, the German version
is the binding version. will prevail.
The use of and protection by disclaimers is effected by local laws and
regulations. Therefore each SIRT should be sensitive and if in doubt
should check the disclaimer with a lawyer.
Expectations for Security Incident Response 26 March 97 The use of and protection by disclaimers is affected by local laws
and regulations, of which each SIRT should be aware. If in doubt
the SIRT should check the disclaimer with a lawyer.
4 Appendix A: Glossary of Terms Appendix A: Glossary of Terms
This glossary defines terms used in describing security incidents and This glossary defines terms used in describing security incidents and
Security Incident Response Teams. Only a limited list is included. Security Incident Response Teams. Only a limited list is included.
For more definitions please refer to other sources, for example to the For more definitions please refer to other sources, for example to
[RFC 1983]. the Internet User's Glossary [RFC 1983].
Expectations for Security Incident Response 28 April 97
Constituency: Constituency:
Implicit in the purpose of a Security Incident Response Team is Implicit in the purpose of a Security Incident Response Team is
the existence of a constituency. This is the group of users, the existence of a constituency. This is the group of users,
sites, networks or organizations served by the team. The team sites, networks or organizations served by the team. The team
must be recognized by its constituency to be effective. must be recognized by its constituency in order to be effective.
Security Incident: Security Incident:
For the purpose of this document this term is synonym to Computer For the purpose of this document, this term is a synonym of
Security Incident: Any adverse event which compromises some aspect Computer Security Incident: any adverse event which compromises
of computer or network security. some aspect of computer or network security.
The definition of an incident may vary between organizations, but The definition of an incident may vary between organizations, but
at least the following categories are generally applicable: at least the following categories are generally applicable:
- Loss of confidentiality of information. - Loss of confidentiality of information.
- Compromise of integrity of information. - Compromise of integrity of information.
- Denial of service. - Denial of service.
- Misuse of service, systems or information. - Misuse of service, systems or information.
- Damage of systems. - Damage to systems.
These are very general categories. For instance the replacement These are very general categories. For instance the replacement
of a system utility program by a Trojan Horse is an example of of a system utility program by a Trojan Horse is an example of
'compromise of integrity,' and a successful password attack is an 'compromise of integrity,' and a successful password attack is an
example of 'loss of confidentiality.' Attacks, even if they example of 'loss of confidentiality.' Attacks, even if they
failed because of proper protection, might be regarded as an failed because of proper protection, can be regarded as
Incident. Incidents.
Within the definition of an incident the word 'compromised' is Within the definition of an incident the word 'compromised' is
used. Sometimes an administrator may only 'suspect' an incident. used. Sometimes an administrator may only 'suspect' an incident.
During the response it must be established whether or not an During the response it must be established whether or not an
incident really occurred. incident has really occurred.
Security Incident Response Team: Security Incident Response Team:
Based on two of the definitions given above, a SIRT is a team Based on two of the definitions given above, a SIRT is a team
that coordinates and supports the response to security incidents that coordinates and supports the response to security incidents
that involve sites within a defined constituency. that involve sites within a defined constituency.
Expectations for Security Incident Response 26 March 97
In order to be considered a SIRT, a team must: In order to be considered a SIRT, a team must:
- Provide a (secure) channel for receiving reports about - Provide a (secure) channel for receiving reports about
suspected incidents. suspected incidents.
- Provide assistance to members of its constituency in - Provide assistance to members of its constituency in
handling these incidents. handling these incidents.
- Disseminate incident-related information to its - Disseminate incident-related information to its
constituency and to other involved parties. constituency and to other involved parties.
Note that we are not referring here to police or other law Note that we are not referring here to police or other law
enforcement bodies which may investigate computer-related crime. enforcement bodies which may investigate computer-related crime.
SIRT members, indeed, should not need to have any powers beyond SIRT members, indeed, need not have any powers beyond
those of ordinary citizens. those of ordinary citizens.
Expectations for Security Incident Response 28 April 97
Vendor: Vendor:
A 'vendor' is any entity that produces networking or computing A 'vendor' is any entity that produces networking or computing
technology, and is responsible for the technical content of that technology, and is responsible for the technical content of that
technology. Examples of 'technology' include hardware (desktop technology. Examples of 'technology' include hardware (desktop
computers, routers, switches, etc.), and software (operating computers, routers, switches, etc.), and software (operating
systems, mail forwarding systems, etc.). systems, mail forwarding systems, etc.).
Note that the supplier of a technology is not necessarily the Note that the supplier of a technology is not necessarily the
'vendor' of that technology. As an example, an Internet Services 'vendor' of that technology. As an example, an Internet Service
Provider (ISP) might supply routers to each of its customers, but Provider (ISP) might supply routers to each of its customers, but
the 'vendor' is the manufacturer, being the entity responsible for the 'vendor' is the manufacturer, since the manufacturer, rather
the technical content of the router, rather than the ISP. than the ISP, is the entity responsible for the technical content
of the router.
Vulnerability: Vulnerability:
A 'vulnerability' is a characteristic of a piece of technology A 'vulnerability' is a characteristic of a piece of technology
which can be exploited to perpetrate a security incident. For which can be exploited to perpetrate a security incident. For
example, if a program unintentionally allowed ordinary users to example, if a program unintentionally allowed ordinary users to
execute arbitrary operating system commands in privileged mode, execute arbitrary operating system commands in privileged mode,
this "feature" would be a vulnerability. this "feature" would be a vulnerability.
5 Appendix B: Related Material Appendix B: Related Material
Important issues in responding to security incidents on a site level Important issues in responding to security incidents on a site level
are contained in [RFC 1244], the Site Security Handbook, produced by are contained in [RFC 1244], the Site Security Handbook, produced by
the Site Security Handbook Working Group (SSH). This document will the Site Security Handbook Working Group (SSH). This document will
be updated by the SSH working group and will give recommendations for be updated by the SSH working group and will give recommendations
local policies and procedures, mainly related to the avoidance of for local policies and procedures, mainly related to the avoidance
security incidents. of security incidents.
Other documents of interest for the discussion of SIRTs and their Other documents of interest for the discussion of SIRTs and their
tasks are available by anonymous FTP. A collection can be found on: tasks are available by anonymous FTP. A collection can be found on:
Expectations for Security Incident Response 26 March 97
- ftp://ftp.cert.dfn.de/pub/docs/csir/ - ftp://ftp.cert.dfn.de/pub/docs/csir/
Please refer to file 01-README for further information about Please refer to file 01-README for further information about
the content of this directory. the content of this directory.
Some especially interesting documents in relation to this document are Some especially interesting documents in relation to this document
as follows: are as follows:
- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/ - ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/
reports/R-92-01 reports/R-92-01
This report contains the Operational Framework of CERT-NL, the This report contains the Operational Framework of CERT-NL, the
SIRT of SURFnet (network provider in the Netherlands). SIRT of SURFnet (network provider in the Netherlands).
- For readers interested in the operation of FIRST (Forum of - For readers interested in the operation of FIRST (Forum of
Incident Response and Security Teams) more information is Incident Response and Security Teams) more information is
collected in Appendix C. collected in Appendix C.
- http://hightop.nrl.navy.mil/news/incident.html - http://hightop.nrl.navy.mil/news/incident.html
This document leads to the NRL Incident Response Manual. This document leads to the NRL Incident Response Manual.
Expectations for Security Incident Response 28 April 97
- http://www.cert.dfn.de/eng/team/kpk/certbib.html - http://www.cert.dfn.de/eng/team/kpk/certbib.html
This document contains an annotated bibliography of available This document contains an annotated bibliography of available
material, documents and files about the operation of SIRTs material, documents and files about the operation of SIRTs
with links to many of the referenced. with links to many of the referenced items.
- ftp://info.cert.org/incident_reporting_form - ftp://info.cert.org/incident_reporting_form
This Incident Reporting Form is provided by the CERT This Incident Reporting Form is provided by the CERT
Coordination Center to gather incident information and to avoid Coordination Center to gather incident information and to avoid
additional delays by requesting the sites for more detailed additional delays caused by the need to request more detailed
information. information from the reporting site.
- http://www.cert.org/cert.faqintro.html - http://www.cert.org/cert.faqintro.html
A collection of frequently asked questions from the CERT A collection of frequently asked questions from the CERT
Coordination Center. Coordination Center.
6 Appendix C: Known Security Incident Response Teams Appendix C: Known Security Incident Response Teams
Today, there are many different SIRTs but no single source list every Today, there are many different SIRTs but no single source lists
team. Most of the major and long established teams (the first SIRT was every team. Most of the major and long established teams (the first
founded in 1988) are nowadays member of FIRST, the worldwide Forum of SIRT was founded in 1988) are nowadays members of FIRST, the
Incident Response and Security Teams. Actually more than 55 teams are worldwide Forum of Incident Response and Security Teams. At the
members (1 in Australia, 13 in Europe, all others from America). time of writing, more than 55 teams are members (1 in Australia, 13
Information about FIRST can be found: in Europe, all others in North America). Information about FIRST
can be found:
- http://www.first.org/ - http://www.first.org/
Expectations for Security Incident Response 26 March 97 The actual list of members is available also, with the relevant
contact information and some additional information provided by the
The actual list of members is available also, with the relevant contact particular teams:
information and some additional information provided by the single
teams:
- http://www.first.org/team-info/ - http://www.first.org/team-info/
For SIRTs which want to become members of this forum (please note, that For SIRTs which want to become members of this forum (please note
a team needs a sponsor - a team already full member of FIRST - to be that a team needs a sponsor - a team which is already a full member
introduced), the following files contain more information: of FIRST - to be introduced), the following files contain more
information:
- http://www.first.org/about/op_frame.html - http://www.first.org/about/op_frame.html
The Operational Framework of FIRST. The Operational Framework of FIRST.
- http://www.first.org/docs/newmem.html - http://www.first.org/docs/newmem.html
Guidelines for teams which want to become member of FIRST. Guidelines for teams which want to become members of FIRST.
Many of the European teams, regardless if they are members of FIRST or Many of the European teams, regardless of whether they are members
not, are listed by countries on a page maintained by the German SIRT: of FIRST or not, are listed by countries on a page maintained by
the German SIRT:
- http://www.cert.dfn.de/eng/csir/europe/certs.html - http://www.cert.dfn.de/eng/csir/europe/certs.html
To learn about existing teams and maybe more suitable teams for one's To learn about existing teams suitable to one's needs it is
need it is always a good approach, to ask either existing teams or an
Internet Service Provider for the "right" contact.
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 28 April 97
7 Appendix D: Outline for SIRT Template often helpful to ask either known teams or an Internet Service
Provider for the "right" contact.
This outline summarizes the issues addressed in this document in a logical Appendix D: Outline for SIRT Template
structure suitable to communicate the policies and procedures for the
interaction with SIRTs easily to the team's constituency. A 'filled-in'
example of this template is given as Appendix E.
1. Contact Information This outline summarizes in point form the issues addressed in this
1.1 Name of the Team document, and is the recommended template for a SIRT description
1.2 Address document. Its structure is designed to facilitate the communication
1.3 Time Zone of a SIRT's policies, procedures, and other relevant information to
1.4 Telephone Number its constituency and to outside organizations such as other SIRTs.
1.5 Facsimile Number A 'filled-in' example of this template is given as Appendix E.
1.6 Other Telecommunication
1.7 Electronic Mail Address
1.8 Public Keys and Encryption Information
1.9 Team Members
1.10 Other Information
2. Document Updates 1. Document Information
2.1 Date of Last Update 1.1 Date of Last Update
2.2 Distribution List for Notifications 1.2 Distribution List for Notifications
2.3 Locations where this Document May Be Found 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. Charter
3.1 Mission Statement 3.1 Mission Statement
3.2 Constituency 3.2 Constituency
3.3 Sponsors and/or Affiliation 3.3 Sponsorship and/or Affiliation
3.4 Authority 3.4 Authority
4. Policies 4. Policies
4.1 Types of Incidents and Level of Support 4.1 Types of Incidents and Level of Support
4.2 Cooperation and Interaction with Other Entities 4.2 Co-operation, Interaction and Disclosure of Information
4.3 Disclosure of Information 4.3 Communication and Authentication
4.4 Communication and Authentication
4.5 Points of Customer Contacts
5. Services 5. Services
5.1 Incident Response 5.1 Incident Response
5.2 Proactive Activities 5.2 Proactive Activities
6. Incident Reporting Forms 6. Incident Reporting Forms
7. Disclaimers 7. Disclaimers
Expectations for Security Incident Response 26 March 97 Expectations for Security Incident Response 28 April 97
8 Appendix E: Example - 'filled-in' Template for a SIRT Appendix E: Example - 'filled-in' Template for a SIRT
Below is an example, a filled-in template for a SIRT called XYZ Below is an example of a filled-in template for a fictitious SIRT
to avoid any confusion with existing teams. By no means does this called XYZ-SIRT. This text is for example purposes only, and does
example imply, that a new founded SIRT should reuse this text. not constitute endorsement by the working group or the IETF of any
It is for example purposes only. particular set of procedures or policies. While SIRTs 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.
SIRT Template for XYZ-SIRT SIRT Description for XYZ-CERT
-------------------------- -----------------------------
Note: no digital signature is currently available for this SIRT 1. About this document
Template. We'll put one up as soon as the technology is adopted
by XYZ Enterprises.
1. Contact Information 1.1 Date of Last Update
1.1 Name of the Team This is version 1.01, published 1997/03/31.
"XYZ-SIRT": the XYZ Computer Emergency Response Team.
1.2 Address 1.2 Distribution List for Notifications
XYZ SIRT
XYZ Enterprises
Private Bag 12-345
MyTown
MyCountry
1.3 Time Zone Notifications of updates are submitted to our mailing list
MyCountry/Eastern (GMT-0500, and GMT-0400 from April to October) <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.4 Telephone Number 1.3 Locations where this Document May Be Found
+1 234 567 7890 (ask for the XYZ-SIRT)
1.5 Facsimile Number The current version of this SIRT description document is
+1 234 567 7654 (this is *not* a secure fax) available from the XYZ-CERT WWW site; its URL is
http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.txt
Une version francaise de ce document est igalement disponible:
http://www.xyz-univ.ca/xyz-cert/francais/sirt-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/sirt-descr.asc
http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.asc
2. Contact Information
2.1 Name of the Team
"XYZ-CERT": the XYZ University Computer Emergency Response
Team.
Expectations for Security Incident Response 28 April 97
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
1.6 Other Telecommunication
None available. None available.
1.7 Electronic Mail Address 2.7 Electronic Mail Address
<xyz-sirt@sirt.xyz.org>
1.8 Public Keys and Other Encryption Information <xyz-cert@xyz-univ.ca> This is a mail alias that relays mail
Encryption is not currently available, but we plan to install to the human(s) on duty for the XYZ-CERT.
PGP as soon as possible. Our PGP public key will appear here
as soon as it is available.
Expectations for Security Incident Response 26 March 97 2.8 Public Keys and Other Encryption Information
1.9 Team Members The XYZ-CERT has a PGP key, whose KeyID is 12345678 and
Jane Doe of Computing Services is the XYZ-SIRT whose fingerprint is
coordinator. Other team members will be listed here once 11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11.
their participation is confirmed. The key and its signatures can be found at the usual large
public keyservers.
2. Document Updates 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
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.1 Date of Last Update 2.9 Team Members
Please see the bottom of this Web page for this information.
2.2 Distribution List for Notifications Zoe Doe of Computing Services is the XYZ-CERT coordinator.
Notifications of updates are submitted to our mailing list Backup coordinators and other team members, along with their
<xyz-sirt-info@sirt.xyz.org>. (Subscription request should
go to <xyz-sirt-info-request@sirt.xyz.org>.)
2.3 Locations where this Document May Be Found Expectations for Security Incident Response 28 April 97
This template is available from the XYZ SIRT WWW
site; its URL is areas of expertise and contact information, are listed in the
http://www.sirt.xyz.org/op_frame.html XYZ-CERT web pages, at
The template will be signed with the XYZ-SIRT's PGP http://www.xyz-univ.ca/xyz-cert/teamlist.html
key.
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.
3. Charter 3. Charter
3.1 Mission Statement 3.1 Mission Statement
The purpose of the XYZ-SIRT is, first, to assist members of
XYZ community in implementing proactive measures to reduce The purpose of the XYZ-CERT is, first, to assist members of XYZ
the risks of computer security incidents, and second, to University community in implementing proactive measures to
assist XYZ community in responding to such incidents when reduce the risks of computer security incidents, and second, to
they occur. assist XYZ community in responding to such incidents when they
occur.
3.2 Constituency 3.2 Constituency
The XYZ-SIRT's constituency is the XYZ SIRT community,
as defined in the context of the "XYZ Policy on Computing
Facilities".
3.3 Sponsors and/or Affiliation The XYZ-CERT's constituency is the XYZ University community,
None. 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
3.4 Authority However, please note that, notwithtanding the above, XYZ-CERT
services will be provided for on-site systems only.
The XYZ-SIRT operates under the auspices of, and with Expectations for Security Incident Response 28 April 97
authority delegated by, the Department of Computing Services
of XYZ Enterprises. The Department in turn receives its
authority from the formal ruling bodies of XYZ, as
set out in the "Policy on Computing Facilities". The XYZ-SIRT
Expectations for Security Incident Response 26 March 97 3.3 Sponsorship and/or Affiliation
has no direct authority over systems at XYZ Enterprises The XYZ-CERT is currently completing the application process
at large. However, it benefits from the direct authority of for membership in FIRST, the Forum of Incident Response and
Computing Services with respect to systems managed by this Security Teams. More information about FIRST is available
Department. Also, because Computing Services manages the from
XYZ Enterprises Network, and is responsible for connectivity http://www.first.org/
to it, the Department has indirect authority over systems
in other departments, inasmuch as the Department can order
such systems to be disconnected from the network should
circumstances warrant it.
The XYZ-SIRT expects to work cooperatively with system 3.4 Authority
administrators and users at XYZ, and, insofar as
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, possible, to avoid authoritarian relationships. However,
should circumstances warrant it, the XYZ-SIRT will appeal to should circumstances warrant it, the XYZ-CERT will appeal to
Computing Services to exert its authority, direct or indirect, Computing Services to exert its authority, direct or indirect,
as necessary. 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.
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 the XYZ University
Office of Rights and Responsibilities (in the case of perceived
errors in the application of existing policy).
4. Policies 4. Policies
4.1 Types of Incidents and Level of Support 4.1 Types of Incidents and Level of Support
The XYZ-SIRT is authorized to address all types of computer The XYZ-CERT is authorized to address all types of computer
security incidents which occur, or risk occurring, at security incidents which occur, or threaten to occur, at
XYZ Enterprises. XYZ University.
The level of support given by XYZ-SIRT will vary depending on The level of support given by XYZ-CERT will vary depending on
the type and severity of the incident or issue, the type of the type and severity of the incident or issue, the type of
consituent, the size of the user community affected, and the constituent, the size of the user community affected, and the
XYZ-SIRT's resources at the time. XYZ-CERT's resources at the time, though in all cases some
response will be made within one working day. Resources will
No direct support will be given to end users; they are Expectations for Security Incident Response 28 April 97
expected to contact their system administrator, network
administrator, or department head for assistance. The
XYZ-SIRT will support the latter people.
While the XYZ-SIRT understands that there exists great be assigned according to the following priorities, listed in
variation in the level of system administrator expertise at decreasing order:
XYZ, and while the XYZ-SIRT will endeavor to present
information and assistance at a level appropriate to
each person, the XYZ-SIRT cannot train system administrators,
and it cannot perform system maintenance on their behalf.
In most cases, the XYZ-SIRT will provide pointers to the
information needed to implement appropriate measures.
Expectations for Security Incident Response 26 March 97 - 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, harrassment, 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.
- Denial of service on individual user accounts, e.g.
mailbombing.
4.2 Cooperation and Interaction with Other Entities Types of incidents other than those mentioned above will be
prioritized according to their apparent severity and extent.
- Other sites: Note that no direct support will be given to end users; they
The XYZ-SIRT will cooperate with other SIRTs (security are expected to contact their system administrator, network
incident response teams) and with system administrators at administrator, or department head for assistance. The XYZ-CERT
other sites, to the extent that their bona fide can be will support the latter people.
verified. Should provincial or national SIRTs be
constituted, XYZ-SIRT will explore the possibility of peer
relationships with them. The possibility of peer
relationships with close neighbors will also be explored;
unofficial cooperative climates already exist between XYZ
and several nearby universities and large corporations.
While there are no legal requirements that XYZ-SIRT provide
any information to any body outside XYZ (aside from
law enforcement agencies), XYZ-SIRT will provide such
information when the good of the community justifies it.
However, unless identifying information is needed to track
an incident in progress, such information will be stripped
from the report (unless the affected department gives its
permission that the real information be used).
- Vendors:
The XYZ-SIRT wishes to encourage vendors of all kinds of
networking and computer equipment, software, and services
to improve the security of their products. In aid of
this, a vulnerability discovered in such a product will be
reported to its vendor, along with all technical details
needed to identify and fix the problem. Identifying
details will not be given to the vendor without the
permission of the affected parties.
- Law enforcement:
XYZ has its own Security Department. ( I NEED TO LOOK UP
THE RELATIONSHIP BETWEEN COMPUTING SERVICES, XYZ
SECURITY, AND OUTSIDE POLICE FORCES. ) Informal working
relationships already exist between some system
administrators at XYZ and the local police; interest
has been expressed by all parties in formalizing these
relationships. Any progress
made in that area will be reflected in this section.
In the meantime, authorized and unauthorized users of the
XYZ Computing Facilities should be aware that the
XYZ-SIRT will cooperate fully with law enforcement
agencies in detecting, reporting, documenting, and
prosecuting violations of the law; users concerned about
confidentiality are referred to the XYZ "Policy on
Computing Facilities".
Expectations for Security Incident Response 26 March 97 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 Press: The XYZ-CERT is committed to keeping the XYZ University system
The XYZ-SIRT will not interact directly with the Press. administration community informed of potential
If necessary, information will be provided to the vulnerabilities, and where possible, will inform this
XYZ Public Relations Department, and to the community of such vulnerabilities before they are actively
Customer Relations group of the Computing Services exploited.
Department. All queries will be referred to these two
bodies.
- The XYZ SIRT community:
Details of incidents may be released to Computing Services
management, XYZ management, or the Computer
Resources Committee; these bodies will be charged with
maintaining the confidentiality of the information. General
report of incidents, summaries of multiple incidents, and
statistics may be made available to the general XYZ
community, with identifying information stripped (except
where permission has been obtained from the affected
parties). There is no obligation on the part of the
XYZ-SIRT to report incidents to the community, though it
may choose to do so; in particular, it is likely that the
XYZ-SIRT will inform all affected parties of the ways in
which they were affected.
- The public at large:
In general, no particular efforts will be made to
communicate with the public at large, though the XYZ-SIRT
recognizes that, for all intents and purposes, information
made available to the XYZ community is in effect
made available to the community at large, and will tailor
the information in consequence.
- The computer security community:
While members of XYZ-SIRT may participate in discussions
within the computer security community, such as newsgroups,
mailing lists (including the full-disclosure list
"bugtraq"), and conferences, they will treat such forums
as though they were the public at large. While technical
issues (including vulnerabilities) may be discussed to any
level of detail, any examples taken from XYZ-SIRT
experience will be disguised to avoid identifying the
affected parties.
In the paragraphs above, the "affected parties" refers to the Expectations for Security Incident Response 28 April 97
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 legitimate owners, operators, and users of the relevant
computing facilities. It does not refer to unauthorized computing facilities. It does not refer to unauthorized
users, including otherwise authorized users making users, including otherwise authorized users making
unauthorized usage of a facility; such intruders may have no unauthorized use of a facility; such intruders may have no
expectation of confidentiality from the XYZ-SIRT. They may or expectation of confidentiality from the XYZ-CERT. They may or
may not have legal rights to confidentiality; such rights will may not have legal rights to confidentiality; such rights will
of course be respected where they exist. of course be respected where they exist.
4.3 Disclosure of Information Information being considered for release will be classified as
follows:
The following types of information will be stored and handled - Private user information is information about particular
by XYZ-SIRT: users, or in some cases, particular applications, which
- Contact info for constituents. must be considered confidential for legal, contractual,
- Technical info about a vulnerability. and/or ethical reasons.
- Technical info about XYZ facilities.
- Information about incidents:
- Statistical summaries
- Admission of incident of certain type
- Admission of root compromise
- Admission of packet sniffing attack
- Admission that user accounts were compromised
- Description of incident
- Identity of affected systems
- Identity of affected people
- Identity of perpetrator
Recipients of information are - depending on the need to Private user information will be not be released in
know - are as follows: identifiable form outside the XYZ-CERT, except as provided
- XYZ management for below. If the identity of the user is disguised, then
- Computing Services management the information can be released freely (for example to show
- Affected sysadmin at XYZ a sample .cshrc file as modified by an intruder, or to
- Affected sysadmin (or SIRT) at another site demonstrate a particular social engineering attack).
Expectations for Security Incident Response 26 March 97 - Intruder information is similar to private user
information, but concerns intruders.
- Affected user(s) at XYZ While intruder information, and in particular identifying
- All sysadmins potentially concerned (potentially information, will not be released to the public (unless it
vulnerable) at XYZ becomes a matter of public record, for example because
- All sysadmins at XYZ criminal charges have been laid), it will be exchanged
- All users potentially concerned at XYZ freely with system administrators and SIRTs tracking an
(information will leak to general public) incident.
- All users at XYZ (ditto)
- Computer security community
- Peer sysadmins and SIRTs
- Vendors
- Law enforcement
4.4 Communication and Authentication - Private site information is technical information about
particular systems or sites.
In view of the types of information that the XYZ-SIRT will It will not be released without the permission of the site
in question, except as provided for below.
Expectations for Security Incident Response 28 April 97
- 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.
- 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 SIRTs.
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,
Expectations for Security Incident Response 28 April 97
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
"embarrasssing 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
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.
Expectations for Security Incident Response 28 April 97
- 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
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 SIRTs, 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 mattters).
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 SIRTs. "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 SIRTs 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.
Expectations for Security Incident Response 28 April 97
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 likely be dealing with, telephones will be considered
sufficiently secure to be used even unencrypted. Unencrypted sufficiently secure to be used even unencrypted. Unencrypted
e-mail will not be considered particularly secure, but will be e-mail will not be considered particularly secure, but will be
sufficient for the transmission of low-sensitivity data. If sufficient for the transmission of low-sensitivity data. If
it is necessary to send highly sensitive data by e-mail, PGP it is necessary to send highly sensitive data by e-mail, PGP
will be used. Network file transfers will be considered to will be used. Network file transfers will be considered to
be similar to e-mail for these purposes. 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 Where it is necessary to establish trust, for example before
relying on information given to the XYZ-SIRT, or before relying on information given to the XYZ-CERT, or before
disclosing confidential information, the identity and bona disclosing confidential information, the identity and bona
fide of the other party will be ascertained to a reasonable fide of the other party will be ascertained to a reasonable
degree of trust. Within XYZ, and with known degree of trust. Within XYZ University, and with known
neighbor sites, referrals from known trusted people will neighbor sites, referrals from known trusted people will
suffice to identify someone. Otherwise, appropriate methods suffice to identify someone. Otherwise, appropriate methods
will be used, such as a search of FIRST members, the use of will be used, such as a search of FIRST members, the use of
WHOIS and other Internet registration information, etc, along WHOIS and other Internet registration information, etc, along
with telephone call-back or e-mail mail-back to ensure that with telephone call-back or e-mail mail-back to ensure that
the party is not an impostor. Incoming e-mail whose data must the party is not an impostor. Incoming e-mail whose data must
be trusted will be checked with the originator personally, or be trusted will be checked with the originator personally, or
by means of digital signatures. by means of digital signatures (PGP in particular is
supported).
4.5 Points of Customer Contact 5. Services
The preferred method for contacting the XYZ-SIRT will be 5.1 Incident Response
e-mail. If this is not possible, or not advisable for
security reasons, the XYZ-SIRT can be reached by telephone
during regular office hours.
Expectations for Security Incident Response 26 March 97 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:
- Determining the extent of the incident.
- Determining the initial cause of the incident
(vulnerability exploited).
- Facilitating contact with other sites which may be
involved.
- 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.
5. Services Expectations for Security Incident Response 28 April 97
5.1 Incident Response - Facilitating contact with XYZ University Security and/or
appropriate law enforcement officials, if necessary.
- Making reports to other SIRTs.
- Composing announcements to users, if applicable.
XYZ-SIRT will help users and administrators to handle the In addition, XYZ-CERT will collect statistics concerning
technical and organizational aspects of incidents. By that, incidents which occur within or involve the XYZ University
it will provide and facilitate: community, and will notify the community as necessary to
- to understand the extend of the incident 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 5.2 Proactive Activities
The XYZ-SIRT will coordinate and maintain the following The XYZ-CERT coordinates and maintains the following
services to the extent possible depending on its resources: services to the extent possible depending on its resources:
- Information services - Information services
- List of departmental security contacts, administrative - List of departmental security contacts, administrative
and technical. 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 - Mailing lists to inform security contacts of new
information relevant to their computing environments. 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 - Repository of vendor-provided and other security-related
patches for various operating systems. patches for various operating systems. This repository
- Repository of security tools for use by sysadmins. 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.
- "Clipping" service for various existing resources, such - "Clipping" service for various existing resources, such
as major mailing lists and newsgroups. 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 - Auditing services
- Central file integrity checking service for Unix - Central file integrity checking service for Unix
machines. machines, and for any other platforms capable of
- Security level assignments; machines at XYZ running "tripwire".
will be audited and assigned a security level.
Expectations for Security Incident Response 28 April 97
- 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 - Archiving services
- Records of security incidents handled. - 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 6. Incident Reporting Forms
There are no own forms developed yet for reporting incidents There are no local forms developed yet for reporting incidents
to XYZ-SIRT. If possible, please make us of the Incident to XYZ-CERT. If possible, please make use of the Incident
Reporting Form of the CERT Coordination Center (Pittsburgh, PA). Reporting Form of the CERT Coordination Center (Pittsburgh,
The actual version is available from: PA). The actual version is available from:
ftp://info.cert.org/incident_reporting_form ftp://info.cert.org/incident_reporting_form
7. Disclaimers 7. Disclaimers
While every precaution will be taken in the preparation of While every precaution will be taken in the preparation of
information, notifications and alerts, XYZ-SIRT assumes no information, notifications and alerts, XYZ-CERT assumes no
responsibility for errors or omissions, or for damages responsibility for errors or omissions, or for damages
resulting from the use of the information contained within. resulting from the use of the information contained within.
Expectations for Security Incident Response 26 March 97 4 Acknowlegements
9 References The editors gratefully acknowledge the contributed material and
editorial scrutiny of Anne Bennett.
[RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. - July 23, Expectations for Security Incident Response 28 April 97
1991. - 101 pages. - FYI 8.
[RFC 1983] G. Malkin / Internet Users' Glossary. - August 16, 1996. - 5 References
62 pages. - FYI 18.
10 Security Considerations [RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. -
July 23, 1991. - 101 pages. - FYI 8.
This document discusses issues of the operation of Security Incident [RFC 1983] G. Malkin / Internet Users' Glossary. -
Response Teams, and the teams interactions with their constituency. August 16, 1996. - 62 pages. - FYI 18.
It is therefore not directly concerned with the security of protocols,
applications or network systems themselves. It is not even concerned
about the response and reaction to security incidents.
Nonetheless, it is vital that SIRTs establish secure communication 6 Security Considerations
channels with other teams, and with members of their constituency.
They must also secure their own systems and infrastructure, to protect This document discusses the operation of Security Incident Response
the interests of their constituency and to maintain the confidentiality 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 SIRTs.
Nonetheless, it is vital that the SIRTs 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. of the identity of victims and reporters of security incidents.
11 Authors' Addresses 7 Authors' Addresses
Nevil Brownlee Nevil Brownlee
ITSS Technology Development ITSS Technology Development
The University of Auckland The University of Auckland
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz E-mail: n.brownlee@auckland.ac.nz
Erik Guttman Erik Guttman
Sun Microsystems, Inc. Sun Microsystems, Inc.
Gaisbergstr. 6 Gaisbergstr. 6
69115 Heidelberg Germany 69115 Heidelberg Germany
Phone: +49 6221 601649 Phone: +49 6221 601649
E-Mail: eguttman@eng.sun.com E-Mail: eguttman@eng.sun.com
This document expires September 26, 1997. This document expires October 28, 1997.
 End of changes. 230 change blocks. 
813 lines changed or deleted 1132 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/