draft-ietf-grip-framework-irt-03.txt   draft-ietf-grip-framework-irt-04.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
November 1996 Valid for six months Erik Guttman
Sun Microsystems
Expectations for Security Incident Response Expectations for Security Incident Response
<draft-ietf-grip-framework-irt-03.txt> <draft-ietf-grip-framework-irt-04.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, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. This Internet Draft is a product of the documents as Internet Drafts. This Internet Draft is a product of the
Internet Accounting Working Group of the IETF. 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 months.
Internet Drafts may be updated, replaced, or obsoleted by other Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a 'working draft' or reference material or to cite them other than as a 'working draft' or
'work in progress.' '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
This document is intended to facilitate the setting of expectations The purpose of this document is to express the general Internet
regarding the operation of Security Incicident Response Teams (SIRTs). community's expectations of Security Incident Response Teams. It
It describes the various important topics in the form of a 'template,' is not possible to define a set of requirements that would be
through which every SIRT should describe itself and its functions. appropriate for all teams, but it is possible and helpful to
list and describe the general set of topics and issues which
are of concern and interest to constituent communities.
SIRT clients have a legitimate need and right to fully understand the SIRT constituents have a legitimate need and right to fully understand
policies and procedures of their Security Incident Response Team. A the policies and procedures of "their" Security Incident Response Team.
SIRT's template supplies details for the various important topics which One way to support this understanding is to supply detailed information
clients must consider when selecting a SIRT. which users may consider, in the form of a formal template completed by
the SIRT. An outline of such a template and a filled in example is
provided.
Contents Expectations for Security Incident Response 26 March 97
1 Introduction 3 Table of Contents
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Publishing SIRT Templates . . . . . . . . . . . . . . . . . . 6
1.3 Relationships between SIRTs . . . . . . . . . . . . . . . . . 6
1.4 Establishing Communications between SIRTs . . . . . . . . . . 7
2 Description Template: Security Incident Response Team 7 1 Introduction 1
3 Purpose of the Template 8 2 Scope..............................................................3
3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 9 2.1 Publishing a SIRT Policies and Procedures .....................4
2.2 Relationships between different SIRTs .........................5
2.3 Establishing Secure Communications ............................6
4 The Security Incident Response Team Template 10 3 Information, Policies and Procedures...............................7
4.1 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Contact Information ...........................................8
4.1.1Date of last update . . . . . . . . . . . . . . . . . . . . 10 3.2 Document Updates ..............................................9
4.1.2Distribution list for Template Updates . . . . . . . . . . 10 3.3 Charter .......................................................9
4.2 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1 Mission Statement.......................................10
4.2.1Mission Statement . . . . . . . . . . . . . . . . . . . . . 11 3.3.2 Constituency............................................10
4.2.2Constituency . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.3 Sponsoring Organization / Affiliation...................10
4.2.3Sponsoring organization / affiliation . . . . . . . . . . . 12 3.3.4 Authority...............................................11
4.2.4Authority . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Policies .....................................................11
4.3 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1 Types of Incidents and Level of Support.................11
4.3.1Types of incidents and level of support . . . . . . . . . . 12 3.4.2 Co-operation and Interaction with other Organizations...12
4.3.2Co-operation and interaction with other organizations . . . 12 3.4.3 Reporting and Disclosure................................13
4.3.3Reporting and Disclosure . . . . . . . . . . . . . . . . . 13 3.4.4 Communication and Authentication........................14
4.3.4Communication and authentication . . . . . . . . . . . . . 14 3.4.5 Point of Customer Contacts..............................14
4.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5 Services .....................................................15
4.5 Incident reporting Forms . . . . . . . . . . . . . . . . . . . 15 3.6 Incident Reporting Forms .....................................15
4.6 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.7 Disclaimers ..................................................16
5 Secondary Purposes of this Document 15 4 Appendix A: Glossary of Terms 17
6 Appendix A: Note on procedure definitions 16 5 Appendix B: Related Material 18
7 Appendix B: Known Incident Response Teams 17 6 Appendix C: Known Security Incident Response Teams 19
8 Appendix C: Example: a 'filled-in' template 17 7 Appendix D: Outline for SIRT Template 21
9 Security Considerations 25 8 Appendix E: Example - 'filled-in' Template for a SIRT 22
10 Author's Address 25 9 References 29
1 Introduction 10 Security Considerations 29
The GRIP Working Group was formed to produce guidelines and 11 Authors' Addresses 29
recommendations to facilitate the consistent handling of security
incidents in the Internet community. Although it is focused on the
Internet, many of the concepts discussed will also be useful for other
forms of local- and wide-area networks and internets.
Many computer security incidents orginate outside local community Expectations for Security Incident Response 26 March 97
boundaries and affect other 'outside' sites, and others orignate outside
the local community and affect hosts or users within it. Often,
therefore, the handling of security incidents will involve multiple
Security Incident Response Teams. Because of this characteristic it is
important for every community to have a good security policy, and to
have a Security Incident Response Team (SIRT) in place to manage
communications across community boundaries in a consistent way.
In the past there have been misunderstandings regarding expectations of 1 Introduction
response teams. The goal of this document is to provide a framework in
which to set expectations. By defining such a framework the community
can express areas and topics that need to addressed by any SIRT.
'Consistent handling' implies that any group calling itself a SIRT must The GRIP Working Group was formed to create a document that describes
react to security incidents or to threats of them in ways which the the community's expectations of security incident response teams
Internet community agrees to be in its general interest. Every SIRT (SIRTs). Although the need for such a document originated in the
needs to define clearly the services they offer and the level at which general Internet community, the expectations expressed should also
they are offered to clients. Such definitions will be particularly closely match those of more restricted communities.
important in contracts and/or agreements which SIRTs make with their
clients.
The "Expectations for Security Incident Response" is seen as resting on In the past there have been misunderstandings regarding what to expect
the work of individual SIRTs and the cooperation between them. This from SIRTs. The goal of this document is to provide a framework for
document therefore recommends a 'template' through which every SIRT presenting the important subjects (related to incident response) that
should describe itself and its functions. It further recommends that are of concern to the community.
templates should be accessible among teams, to make possible a fully
effective cooperative response framework for incidents or threats across
the entire domain affected by them.
1.1 Definitions Before continuing, it is important to clearly understand what is meant
by the term "Security Incident Response Team." For the purposes of
this document, a SIRT is a team that performs, coordinates, and supports
the response to security incidents that involve sites within a defined
constituency (see Appendix A for a more complete definition). Any
group calling itself a 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.
This section defines terms used in describing security incidents and Since it is vital that each member of a constituent community be
response teams. For the purpose of the GRIP documents only a limited able to understand what is reasonable to expect of their team, A SIRT
list is really needed. This should help maintain focus on the purpose should make it clear who belongs to their constituency and define the
of the documents, and prevent a duplication of other definitions or - services the team offers to the community. Additionally, each SIRT
even worse - a proliferation of competing definitions. should publish its policies and operating procedures. Similarly, these
same constituents need to know what is expected of them in order for
them to receive the services of their team. This requires that the
team also publish how and where incidents should be reported.
Constituency This document details a template which will be used by SIRTs to
communicate this information to their constituents. The constituents
should certainly expect a SIRT to provide the services they describe in
the completed template.
Implicit in the purpose of a Security Incident Response Team is the It must be emphasised that without active participation from users, the
existence of a constituency. This is the group of clients, sites, effectiveness of the SIRT's services can be greatly diminished. This
networks or organizations served by the team. is particularly the case with reporting. At a minimum, users need to
know that they should report security incidents, and know how and where
they should report them to.
Security Incident 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,
For the purpose of this document: Expectations for Security Incident Response 26 March 97
'A computer security incident is any event which compromises the handling of security incidents will involve the cooperation of
some aspect of computer or network security.' 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.
The definition of an incident may vary between organizations, but at Many computer security incidents originate outside local community
least the following categories are generally applicable: 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
working with other SIRTs and organizations outside their constituency,
and what information will be shared.
* loss of confidentiality, The rest of this document describes the set of topics and issues that
* compromise of integrity, SIRTs need to elaborate for their constituents. However, there is no
* denial of service, attempt to specify the "correct" answer to any one topic area. Rather,
* misuse, each topic is discussed it terms of what that topic means. For example,
* damage. five types of policy statements are listed (representing those policies
of interest to the community), but the content of any one of them will
necessarily be specific to a given team.
These are very general categories. For instance the replacement of a Chapter two provides an overview of three major areas: The publishing
system utility program by a Trojan Horse is an example of 'loss of of information by a response team, the definition of the response
integrity,' and a successful password attack is an example of 'loss of team's relationship to other response teams and the need for secure
confidentiality.' 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.
Within the definition of an incident the word 'compromised' is used. It is the working group's sincere hope that through the clarification
Sometimes an administrator may only 'suspect' an incident. During the of the topics in this document, understanding between the community
handling of a call it must be established whether or not an incident and its SIRTs will be increased.
really occurred.
Security Incident Response Team 2 Scope
Based on two of the definitions given above: The interactions between a constituent community and an incident
response team require first that the community understands the
policies and procedures of the response team. Second, since many
response teams collaborate to handle incidents, the community must
also understand the relationship between their response team and
'A Security Incident Response Team is a group authorized to Expectations for Security Incident Response 26 March 97
manage response to security incidents that involve sites within
its defined constituency.'
In order to be considered a SIRT, a group must: other teams. Finally, many interactions will take advantage of
existing public infrastructures and the community needs to know how
those communications are going to be protected. Each of these subjects
will be described in more detail in the following three sections.
* provide a channel for receiving reports about suspected incidents, 2.1 Publishing a SIRT Policies and Procedures
* provide assistance to members of its constituency in handling these
incidents,
* disseminate incident-related information to its constituency and to
other related parties.
Note that we are not referring here to police or other law enforcement Each user who has access to a Security Incident Response Team should
bodies which may investigate computer-related crime. SIRT members, know as much as possible about services of and interactions with this
indeed, should not need to have any powers beyond those of ordinary team long before he or she actually needs them.
citizens.
Vendor A clear statement of the policies and procedures of a SIRT helps the
constituent understand how best to report incidents and what support to
expect afterwards. Will the SIRT assist in resolving the incident?
Will it provide help in avoiding incidents in the future? Clear
expectations, particularly of the limitations of the services provided
by a SIRT, will make interaction with it more efficient and effective.
A 'vendor' is any entity that produces networking or computing There are different kinds of response teams. Some that have very
technology, and is responsible for the technical content of that broad constituencies (e.g., CERT Coordination Center and the Internet),
technology. Examples of 'technology' include hardware (desktop others that have more bounded constituencies (e.g., DFN-CERT, CIAC),
computers, routers, switches, etc.), and software (operating systems, and still others that have very restricted constituencies (e.g.,
mail forwarding systems, etc.). 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.
Note that the supplier of a technology is not necessarily the 'vendor' As a SIRT provides a service to a this clearly defined constituency,
of that technology. As an example, an Internet Services Provider (ISP) it should communicate all necessary information about its policies
might supply routers to each of its customers, but the 'vendor' is the and services in a suitable form. It is important to understand that
manufacturer, being the entity responsible for the technical content of not all policies and procedures must be publicly available. For
the router, rather than the ISP. 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.
Vulnerability In the past, some teams supplied a kind of Operational Framework,
others provided Frequently Asked Questions (FAQ), while still
others wrote papers for distribution at user conferences or sent
newsletters.
A 'vulnerability' is a characteristic of a piece of technology which can Another efficient way to communicate the relevant information to all
be exploited to perpetrate a security incident. For example, if a concerned, not only constituents but also other teams or organizations,
program unintentionally allowed ordinary users to execute arbitrary would be for each SIRT to publish its guidelines and procedures on its
operating system commands in privileged mode, this "feature" would be a own information server. This would allow constituents to easily access
vulnerability.
1.2 Publishing SIRT Templates Expectations for Security Incident Response 26 March 97
Every SIRT should publish information about its policies and services in it, although this does not address the problem of how a constituent or
the form of a completed template. The simplest way for a SIRT to make will find "his" or "her" team. People within the constituency have to
its template widely available is to publish it on its own information discover that there is a SIRT "at their disposal." It is foreseen that
server so that clients in its constituency can easily find it. completed SIRT templates will soon become searchable by modern search
Templates published as pages in the World Wide Web should include the engines. This will aid in distributing information about the existence
phrase 'SIRT Template' in their title - this will allow Web search of SIRTs and basic information required to approach them.
engines to find them easily.
Whether or not templates are published in a repository, clients - and It would be very useful to have a central repository containing all the
potential clients - of a SIRT will need to be able to authenticate a completed SIRT templates. No such repository presently exists. This
template (verify that it was indeed published by the SIRT) and check might change in the future.
that it has not been modified (for example by verifying a digital
signature for it).
To facilitate interaction between SIRTs, it would be useful to have a Regardless of the source from which the information is retrieved,
central repository for them. The GRIP Working Group believe that some the user of the template must check its authenticity. It is highly
of the existing Internet archive areas could be used for this purpose. recommended that such vital documents be protected by digital
The keeper of each template repository will be responsibly for verifying signatures. These will allow user can verify that the template
the identity of each SIRT lodging a template in the repository. was indeed published by the SIRT and that it has not been modified
thereafter. This document assumes the reader has familiarity with
the proper use of digital signatures to determine whether a document
is authentic.
1.3 Relationships between SIRTs 2.2 Relationships between different SIRTs
In some cases a SIRT may be able to operate effectively on its own. It In some cases a SIRT may be able to operate effectively on its own
is much more likely, however, that a SIRT will need to interact with and in close cooperation with its constituency. But with todays
other SIRTs. Such interactions could include: international networks it is much more likely that most of the
incidents handled by a SIRT will involve parties external to its
constituency. Therefore the team will need to interact with other
SIRTs and sites outside their constituency.
* Responding to requests for advice (e.g. "have you seen this The constituent community should be clear about the nature and
problem before?") extent of this collaboration, as very sensitive information about
* Reporting of problems (for onward referal to other SIRTs, to service individual constituents may be disclosed in the process.
providers or to vendors)
* Working co-operatively to resolve a security incident
Note that there is a difference between a peering agreement, where the Such interactions could include asking other teams for advice,
SIRTs involved agree to work together and share information, and simple disseminating knowledge of problems and working cooperatively
co-operation, where a SIRT (or any other client) simply contacts another to resolve a security incident effecting one or more of the SIRTs'
SIRT and asks for help or advice. Note also that any client wanting constituencies.
direct help in tracking an incident must be prepared to provide
sufficient information about the incident to make tracking possible.
In establishing relationships to support such interactions, SIRTs will In establishing relationships to support such interactions, SIRTs will
need to decide what kinds of agreements can exist between themselves so need to decide what kinds of agreements can exist between them so as to
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.
1.4 Establishing Communications between SIRTs
Once two SIRTs have agreed to work together - as outlined above - they
need to establish secure communications channels. This section outlines
some of the issues involved in this.
When a SIRT (SIRT A) wishes to establish a working relationship with
another SIRT (SIRT B), a responsible person from SIRT A will need to
contact a similarly responsible person at SIRT B. The SIRT B person then
has the problem: "how do I know who I'm talking to?"
It is very easy to send forged e-mail, and not hard to establish a Expectations for Security Incident Response 26 March 97
(false) identity by telephone. PGP and PEM provide effective ways of
securing e-mail, but securing voice communications is much harder. At
present call-back is probably the only simple authentication method.
This may change as technologies such as scrambled telephones, or
PGP-phone on the Internet become available.
PGP relies on a 'web of trust,' built up by having known (and trusted) Note that there is a difference between a peering agreement, where the
people sign PGP keys. This model could also be used for SIRTs. To SIRTs involved agree to work together and share information, and simple
achieve this each SIRT should publish a list of the SIRTs they have co-operation, where a SIRT (or any other organization) simply contacts
peering arrangements (i.e. working relationships) with, including PGP another SIRT and asks for help or advice.
public keys for them and the expiry dates of those keys.
2 Description Template: Security Incident Response Team Although the establishing of such relationships is very important and
affect the ability of a SIRT to support its constituency, it is up to
the teams involved to decide about the details. It is beyond the scope
of this document to make recommendations for this process. But the
same set of information used to set expectations for a user community
regarding sharing of information will help other parties to understand
the objectives and services of a specific SIRT, supporting a first
contact.
The Template is summarized in the section immediately below, and the 2.3 Establishing Secure Communications
remainder of the document describes its components. A 'filled-in'
example of a template is given as Appendix C.
1. Contact Information Once one party has decided to share information with another party, or
1.1 Name of the Team two parties have agreed to share information or work together - as
1.2 Address required for the coordination of Security Incident Response - all
1.3 Time Zone parties involved need secure communications channels. ("Secure" hereby
1.4 Telephone Number relates to the protected transmission of information shared between
1.5 Facsimile Number different parties and not the appropriate use of the information by the
1.6 Other Telecommunication (STU-III, secure facsimile...) parties.)
1.7 Electronic Mail Address
1.8 Public Keys and Other Encryption Information
1.9 Team Members
2. Template Updates The goals of secure communication are:
2.1 Date of Last Update
2.2 Locations where this Template May Be Found
3. Charter - Confidentiality:
3.1 Mission Statement Can somebody else access the content of the communication?
3.2 Constituency
3.3 Sponsors and/or Affiliation
3.4 Authority
4. Policies - Integrity:
4.1 Types of Incidents Can somebody else manipulate the content of the communication?
4.2 Level of Support
4.3 Disclosure of Information
4.4 Cooperation and Interaction with Other Entities
4.5 Communication and Authentication
4.6 Points of Customer Contact
5. Services - Authenticity:
5.1 Incident Response Am I communicating with the "right" person?
5.2 Proactive Activities
6. Incident Reporting Forms 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:
7. Disclaimers Expectations for Security Incident Response 26 March 97
3 Purpose of the Template - Public keys (for techniques like PGP and PEM):
Because they are accessible through the internet, they must be
authenticated before usage. While PGP relies on a
"Web of Trust" - users sign the keys of other users - PEM relies
on a hierarchy - certification authorities sign the keys of users.
The Template which this document proposes is expected to be used by a - Secret keys (for techniques like DES and PGP/conventional
response team to describe what it does, and in the process create encryption): Because they must be known to sender and receiver,
criteria against which its performance can be measured. The Template they must be exchanged before the communication via a secure
does not attempt to specify a "correct" way for the team to operate, but channel.
does recommend on specific policies and functions seen as necessary for
such a team to play a consistent role in the overall security framework.
It also comments on additional roles a team might include in the ambit
of its operations.
The primary purposes of the Template are: Communication is critical for all aspects of incident response. A team
can best support the use of the above-mentioned techniques by gathering
all relevant information, in a consistent way. Specific requirements
(like calling a specific number for checking the authenticity
of keys) should be explained right away. SIRT templates provide a
standardized vehicle for delivering this information.
- to help SIRTs improve the way they operate; It is beyond the scope of this document to address all the technical
and administrative problems of secure communications. The point is
that response teams must support and use a method to secure the
communications between themselves and their constituents (or other
response teams). Whatever the mechanism is, the level of protection
it provides must be acceptable to the constituent community.
- to improve interactions between different SIRTs, and between SIRTs 3 Information, Policies and Procedures
and other organizations such as vendors and law-enforcement
agencies;
- to note necessary interactions with their constituencies in setting In chapter 2, it was mentioned that the policies and procedures of a
expectations and defining policies; response team need to be published to their constituent community.
In this chapter we will list all the types of information that the
community needs to receive from its response team. How this
information is communicated to a community will differ from team to
team, as will the specific information content. The intent here is
to clearly describe the various kinds of information that a
constituent community expects from its response team.
- to help new groups understand what it takes to "be" a SIRT. To make it easier to understand all issues and topics relevant to the
interaction of constituents with "their" SIRT, we suggest that a SIRT
publish all information, policies and procedures addressing their
constituency as a document, following template given in Appendix 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
A Template might appear to provide a marketing tool for comparing Expectations for Security Incident Response 26 March 97
different teams, but this kind of marketing use (or abuse) is strongly
discouraged by the GRIP Working Group.
3.1 Other Related Material that those who interact with the SIRT can obtain and understand it.
This 'Framework for Response Teams' document is the first produced by As always, not every aspect for every environment and/or team can
the GRIP Working Group. A second document will set out guide-lines for be covered. This outline should be seen as a suggestion. Each team
technology vendors to help them handle security incidents. The should feel free to include whatever they think is necessary for
definition of terms given in the next section applies to both documents. supporting their constituency.
Another relevant IETF document is RFC 1244, the Site Security Handbook, 3.1 Contact Information
produced by (and being updated by) the Site Security Handbook Working
Group (SSH). Site requirements and recommendations are covered by the
Handbook, while response team expectations and procedures are addressed
by the GRIP documents.
Other documents of interest for the discussion of incident response Full details of how to contact the SIRT should be listed here, although
teams and their tasks are available by anonymous FTP. A collection can this might be very different for different teams. Some might choose to
be found on: restrict the availability of names of all team members. No further
clarification is given when the meaning of the item can be assumed.
* ftp://ftp.nic.surfnet.nl/surfnet/net-security/ - Name of the SIRT
cert-nl/docs/reports/R-92-01
Some especially interesting documents are: - Mailing Address
* CERT-NL Framework - Time zone This is useful for coordinating
ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt incidents which cross time zones.
* FIRST potential members - Telephone number
ftp://ftp.first.org/pub/first/newmemlt.txt
ftp://ftp.first.org/pub/first/profile.txt
ftp://ftp.first.org/pub/first/op`frame.txt
http://www.first.org/first
* NRL Incident Response Manual - Facsimile number
http://hightop.nrl.navy.mil/news/incident.html
* Bibliography - Other telecommunication Some teams might provide secure
http://www.cert.dfn.de/eng/team/kpk/certbib.html voice communication (e.g. STU III).
- Electronic mail address
4 The Security Incident Response Team Template - Public keys and encryption The use of specific techniques
depends on the ability of the
communication partners to have
access to programs, keys and so on.
Relevant information should be
outlined so users can determine
if and how they can make use of
secure communication while
interacting with the SIRT.
- Team members
This material which follows is addressed to those responsible for - Other information The operating hours and holiday
Security Incident Response Teams. schedule should be provided here.
Is there a 24 hour hotline? Is
there any specific customer contact
info? (See also section 3.4.5).
4.1 Template Updates Expectations for Security Incident Response 26 March 97
Details of a Securty IRT change with time, so the template must indicate 3.2 Document Updates
when it was last changed, who will be informed of future changes, and
(by implication) who will not. Without this, it is inevitable that
misunderstandings and misconceptions will arise over time.
4.1.1 Date of last update 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.
This should be sufficient to allow anyone interested to evaluate the - Date of last update This should be sufficient to allow
anyone interested to evaluate the
currency of the template. currency of the template.
4.1.2 Distribution list for Template Updates - 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.
Persons on this list are notified automatically whenever the template is Digital signatures should be used
changed. The list might normally cover the constituency and any other for update messages sent by a SIRT.
groups the SIRT has frequent interactions with. Readers not on the list
can then recognise that they should check the central repository (above)
for possible updates.
Digital signatures should be used for update messages sent by a SIRT to - Location of the document The location where a current version
those on its distribution list. of the document should be accessible
through a team's online information
services. Constituents can then
easily learn more about the team and
check for recent updates.
4.2 Charter This online version should also be
accompanied by a digital signature,
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 at the authority under which it will do it. The charter should include
least the following: at least the following statements:
* mission statement - Mission statement
* constituency - Constituency
* sponsor / affiliation - Sponsor / affiliation
* authority - Authority
4.2.1 Mission Statement Expectations for Security Incident Response 26 March 97
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 a already stated in the definition of a SIRT. In order to be considered
Security Incident Response Team, the team MUST provide incident a Security Incident Response Team, the team must support the reporting
response, by definition. 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 require
clear, succinct definition. clear, unambiguous definitions.
4.2.2 Constituency 3.3.2 Constituency
A SIRT's constituency (as defined above) can be determined in many ways. A SIRT's constituency can be determined in many ways. For example it
For example it could be a company's employees or its paid subscribers, could be a company's employees or its paid subscribers, or it could be
or it could be defined in terms of a technological focus, such as the defined in terms of a technological focus, such as the users of a
users of a particular operating system. particular operating system.
The definition of constituency should create a perimeter around the The definition of constituency should create a perimeter around the
group to whom the team will provide service. The policy section (below) group to whom the team will provide service. The policy section of
should explain how requests from outside the perimeter will be handled. the document (see below) should explain how requests from outside the
perimeter will be handled.
Constituencies might overlap, as when an ISP supports a SIRT, but If a SIRT decide, not to disclosure their constituency, they should
explain the reasoning behind this decision. For example for-fee
SIRTs will not list their clients but declare that they provide
a service to a large group of customers that are kept confidential
because of the clients' contract.
Constituencies might overlap, as when an ISP provides a SIRT, but
delivers services to customer sites which also have SIRTs. The delivers services to customer sites which also have SIRTs. The
Authority section (below) should make such relationships clear. Authority section of the document (see below) should make such
relationships clear.
People within the constituency have to learn that there is a Security 3.3.3 Sponsoring Organization / Affiliation
IRT for their purposes; the building of a trusted relationship with the
constituency is an on-going process which never ends.
4.2.3 Sponsoring organization / affiliation The sponsoring organization, which authorizes the actions of the SIRT,
should be given next. Knowing this will help the users to understand
the background and setup of the SIRT. It is vital information for
building up trust between a constituent and a SIRT.
The sponsoring organization, which authorises the actions of the SIRT, Expectations for Security Incident Response 26 March 97
should be given next. Defining the affiliation amounts to stating:
"Who is your God?".
4.2.4 Authority 3.3.4 Authority
Based on the relationship between team and constituency this section
will be very different from one team to another. While an
organizational SIRT will be given its authority by the management,
a community SIRT will be supported and chosen by the community,
usually in a advisory role.
SIRTs may not have authority to intervene in the operation of all the SIRTs may not have authority to intervene in the operation of all the
systems within their perimeter. They should identify the scope of their systems within their perimeter. They should identify the scope of
control as distinct from the perimeter of their constituency; if other their control as distinct from the perimeter of their constituency; if
SIRTs operate hierachically within their perimeter, these should be other SIRTs operate hierarchically within their perimeter, these should
identified. be identified and addressed here.
4.3 Policies A disclosure of a team's authority may expose it to claims of
liability. Every team should seek legal advice on these matters.
(See section 3.7 for more on liability.)
4.3.1 Types of incidents and level of support 3.4 Policies
The types of incident which the team is authorised to address and the 3.4.1 Types of Incidents and Level of Support
level of support which the team will contribute when assisting with each
The types of incident which the team is able to address and the
level of support which the team will offer when responding to each
type of incident should be summarized here in list form. The Services type of incident should be summarized here in list form. The Services
section (later) provides opportunity for more detailed definition. section (see below) provides opportunity for more detailed definition
and to address non-incident related topics.
The level of support might change, depending on factors like workload
or completeness of information available. Such factors should be
outlined and their impact should be explained. As a list of known
types of incidents will be incomplete with regard to possible or future
incidents, a SIRT should also give some background on the "default"
support for each reported incident.
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 incidents.
A commitment to act on such information on behalf of its constituency is A commitment to act on such information on behalf of its constituency is
regarded as an optional pro-active service policy rather than a core regarded as an optional pro-active service policy rather than a core
service requirement for a SIRT. service requirement for a SIRT.
4.3.2 Co-operation and interaction with other organizations Expectations for Security Incident Response 26 March 97
This section should make explicit the related groups with which the SIRT 3.4.2 Co-operation and Interaction with other Organizations
routinely interacts. Examples of these are listed below.
Incident Response Teams: A SIRT will often need to interact with This section should make explicit which related groups with which the
other SIRTs. For example a SIRT within a large company may need to SIRT routinely interacts with. Such interactions are not related to
report incidents to a national SIRT, and a national SIRT may need to the Security Incident Response provided, but are used to facilitate
report incidents to national SIRTs in other countries. better cooperation on technical topics or services. By no means should
details about cooperation agreements be given out, the main objective
of this section is to give the constituency a basic understanding
what kind of interactions are established and what their purpose is.
Examples of these are listed below.
Vendors: Larger vendors have their own SIRTs, but smaller vendors Incident Response Teams:
may not. In such cases a SIRT will need to work directly with a vendor. A SIRT will often need to interact with other SIRTs. For example
a SIRT within a large company may need to report incidents to a
national SIRT, and a national SIRT may need to report incidents
to national SIRTs in other countries to deal with all sites
involved in a large-scale attack.
Law-enforcement agencies: These include the police and other Vendors:
investigative agencies. SIRTs and users of the template should be Larger vendors have their own SIRTs, but smaller vendors may not.
sensitive to local laws and regulations, which may vary considerably in In such cases a SIRT will need to work directly with a vendor to
different countries. suggest improvements or modifications, to analyse the technical
problem or to test provided solutions.
Press: A SIRT may be approached by the Press for information and Law-enforcement agencies:
comment from time to time. This is discussed in more detail immediately These include the police and other investigative agencies. SIRTs
and users of the template should be sensitive to local laws and
regulations, which may vary considerably in different countries.
A SIRT might advise on technical details of attacks or seek advice
on the legal implications of an incident. Local laws and
regulations may include specific reporting and confidentiality
requirements.
Press:
A SIRT may be approached by the Press for information and comment
from time to time. This is discussed in more detail immediately
below. below.
4.3.3 Reporting and Disclosure Other:
This might include research activities or the relation to the
sponsoring organization.
Expectations for Security Incident Response 26 March 97
3.4.3 Reporting and Disclosure
The default status of any and all security-related information which a The default status of any and all security-related information which a
team receives can only be 'confidential,' but rigid adherence to this team receives will usually be 'confidential,' but rigid adherence to
makes the team a 'black hole.' Its template should define what this makes the team to appear as a 'black hole.' Its template should
information it will report or disclose, 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 restraints
requiring or limiting disclosure, especially if they work in different requiring or limiting disclosure, especially if they work in different
jurisdictions. Each team's template should specify any such restraints, jurisdictions. In addition, they may have reporting requirements
both to clarify clients' expectations and to inform other teams. imposed by their sponsoring organization. Each team's template should
specify any such restraints, both to clarify users' 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; the present Draft 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.
An explicit policy concerning disclosure to the Press can be helpful, 'Disclosure' includes (but is maybe not limited to):
particularly in clarifying the expectations of a SIRT's constituency.
'Disclosure' includes:
- reporting incidents within the constituency to other teams; - 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 - Handling incidents occurring within the constituency, but
from outside it. reported from outside it.
- reporting observations from within the constituency indicating - Reporting observations from within the constituency indicating
suspected or confirmed incidents outside it; suspected or confirmed incidents outside it.
- acting on reports of incidents occurring outside the constituency; - Acting on reports of incidents occurring outside the constituency.
- passing information about vulnerabilities to vendors, to Partner - Passing information about vulnerabilities to vendors, to Partner
SIRTs or directly to affected sites lying within or outside the SIRTs or directly to affected sites lying within or outside the
constituency; constituency.
- feed-back to parties reporting incidents or vulnerabilities; - Feed-back to parties reporting incidents or vulnerabilities.
- the provision of contact information relating to members of the - The provision of contact information relating to members of the
constituency, members of other constituencies, other SIRTs or constituency, members of other constituencies, other SIRTs or
law-enforcement agencies. 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 The reporting and disclosure policy should make clear who will be the
recipients of a SIRT's reports in each circumstance. It should also recipients of a SIRT's report in each circumstance. It should also
note whether the team will expect to deal through another Security IRT note whether the team will expect to deal through another SIRT
or directly with a member of another constituency over matters directly or directly with a member of another constituency over matters directly
involving that member. involving that member.
A team will normally collect statistics. If they are distributed, the A team will normally collect statistics. If such information are
template's reporting and disclosure policy should say so, and should distributed, the template's reporting and disclosure policy should
list the recipients. say so, and should list methods to obtain such statistics.
4.3.4 Communication and authentication 3.4.4 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 and This is necessary for communication between SIRTs and between a SIRT
its constituents. The template should include public keys or pointers and its constituents. The template should include public keys or
to them, including key fingerprints, together with guidelines on how to pointers to them, including key fingerprints, together with guidelines
use this information to check authenticity. on how to use this information to check authenticity and how to deal
with corrupted information (for example where to report this fact to).
At the moment it is recommended that every SIRT have, as a minimum, a At the moment it is recommended that every SIRT has - if possible - as
PGP key available, since PGP is available world-wide. Teams may also a minimum, a PGP key available. Teams may also make other mechanisms
make other mechanisms available, for example PEM. available (for example PEM, MOSS, S/MIME), according to its needs and
the needs of its constituents. Note however, that SIRTs and users
should be sensitive to local laws and regulations. Some countries do
not allow strong encryption or enforce specific policies on the use of
encryption technology. In addition to encrypting sensitive information
whenever possible, correspondence should include digitally signatures.
(Please note, that in most countries, the protection of authenticity
by using digital signatures is not affected by existing encryption
regulations.)
For communication via telephone or facsimile a 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.
4.4 Services 3.4.5 Point of Customer Contacts
Services should be defined in two sections, as listed below. 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.
* direct incident response Expectations for Security Incident Response 26 March 97
+ verification of incident
+ technical assistance and analysis to understand
the compromise of a system
+ notification of other involved parties
+ eradication
+ recovery
* optional 3.5 Services
+ information provision
- vulnerability archive
- patches and resolutions
+ tools
+ education
+ audit and consulting
+ product evaluation
4.5 Incident reporting Forms Services provided by each SIRT can be differentiated by whether they
relate to the main task, which is incident response, or are provided
in addition (optional in regard to the definition of a SIRT).
Samples of reporting forms used by the SIRT (or pointers to them) should Incident response, which usually includes:
be included at this point in a template.
4.6 Disclaimers - Verification Help with the verification of
incidents, as well as their scope.
Although the template does not constitute a contract, liability might - Technical Assistance This may include analysis of
compromised systems.
- Eradication Elimination of the effects of a
security incident.
- Recovery Aid in restoring affected systems
and services to their status before
the security incident.
- Notification of other involved parties
Additional or optional services, which might include:
- Information provision This might include an archive of
known vulnerabilities, patches or
resolutions of past problems.
- Security Tools
- Education and training
- Product evaluation
- Site security auditing and consulting
3.6 Incident Reporting Forms
The use of reporting forms makes it simplier for both sides, users and
teams, to deal with incidents. The constituent may prepare answers to
various important questions before he or she actually contacts the team
and therefore come well prepared. The team gets all the necessary
information at once with the first report and can proceed efficiently.
Expectations for Security Incident Response 26 March 97
Depending on the objectives and services of a single SIRT, multiple
forms may be used, for example a reporting form for a new vulnerability
will be very different for the form used for reporting incidents.
It is most efficient to provide forms through the online information
services of the team. The exact pointers to them should be given in
the document, together with statements about appropriate use and
guidelines, for when and how to use the forms. If separate e-mail
addresses are supported for form based reporting, they should be
listed here again.
One example for such form is the Incident Reporting Form provided by
the CERT Coordination Center:
- ftp://info.cert.org/incident_reporting_form
3.7 Disclaimers
Although the document does not constitute a contract, liability might
conceivably result from its descriptions of services and purposes. The conceivably result from its descriptions of services and purposes. The
inclusion of a disclaimer at the end of the template is recommended. inclusion of a disclaimer at the end of 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 It should be noted that some forms of reporting or disclosure relating
to specific incidents or vulnerabilities can imply liability, and SIRTs to specific incidents or vulnerabilities can also imply liability, and
should consider the inclusion of disclaimers in such material. SIRTs should consider the inclusion of disclaimers in such material.
In situations where the original version of a template 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 our German template Although we tried to carefully translate the original
into English, we can not be certain that both documents express document from German into English, we can not be certain
the same thoughts in the same level of detail and correctness. that both documents express the same thoughts in the same
In all cases, where there is a difference between both level of detail and correctness. In all cases, where there
versions, the German version is the binding version for our is a difference between both versions, the German version
operation. is the binding version.
5 Secondary Purposes of this Document 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.
The primary audience of this document are the administrators responsible Expectations for Security Incident Response 26 March 97
for communities of users, i.e. 'constituencies.' This section provides
some brief notes on what SIRT clients should expect of their teams.
An incident response team exists primarily to support the clients in its 4 Appendix A: Glossary of Terms
constituency. It is vital that those clients understand what they
should expect of their team. Provided that a SIRT has published its
template, a constituent/client should be able to read the template and
discover what to expect, for example in such areas as privacy and
confidentiality of information, and whether the response team will be This glossary defines terms used in describing security incidents and
contacting downstream sites. Clients should certainly expect a SIRT to Security Incident Response Teams. Only a limited list is included.
provide the services they detail in their template. For more definitions please refer to other sources, for example to the
[RFC 1983].
An important aspect of incident response is the 'follow through' - every Constituency:
incident should be investigated and appropriate actions taken. Clients Implicit in the purpose of a Security Incident Response Team is
should be encouraged by their SIRT to report incidents so that they can the existence of a constituency. This is the group of users,
be acted upon. It must be emphasised that without active participation sites, networks or organizations served by the team. The team
(especially reporting) from clients the effectiveness of the services must be recognized by its constituency to be effective.
they depend on can be greatly diminished. As a minimum, clients need to
know that they should report security incidents, and know how and where
they should report them.
Individual users (i.e. those who are not part of an organisation which Security Incident:
provides a SIRT for its members) who observe a security incident should For the purpose of this document this term is synonym to Computer
ask their Internet Service Provider for details of the most suitable Security Incident: Any adverse event which compromises some aspect
SIRT to report it to. of computer or network security.
Appendix B (below) provides some pointers to SIRTs which were known when The definition of an incident may vary between organizations, but
this document was published. at least the following categories are generally applicable:
6 Appendix A: Note on procedure definitions - Loss of confidentiality of information.
- Compromise of integrity of information.
- Denial of service.
- Misuse of service, systems or information.
- Damage of systems.
Policies and statements of services in the template have to be These are very general categories. For instance the replacement
implemented as procedures, but descriptions of those procedures should of a system utility program by a Trojan Horse is an example of
not be included in the template. 'compromise of integrity,' and a successful password attack is an
example of 'loss of confidentiality.' Attacks, even if they
failed because of proper protection, might be regarded as an
Incident.
The following notes are intended to assist those seeking to form or to Within the definition of an incident the word 'compromised' is
improve their SIRTs. used. Sometimes an administrator may only 'suspect' an incident.
During the response it must be established whether or not an
incident really occurred.
* External Security Incident Response Team:
+ identify other response teams Based on two of the definitions given above, a SIRT is a team
+ define supported clients: that coordinates and supports the response to security incidents
- by domain, through registration system, other means that involve sites within a defined constituency.
+ establish secure communication practices
- use of network, cell-phones, etc
+ define information that a client site must/should provide
- use of reporting forms
* Internal Expectations for Security Incident Response 26 March 97
+ secure the team's infrastructure
+ protect information servers
+ protect sensitive data
+ define expiry of sensitive data
+ define disposal practice for sensitive data
+ establish methods for gathering and keeping statistics
+ establish 'knowledge base' of lessons learned from past incidents
+ create practical implementations of disclosure policies
+ document explicit practices for disclosure to the Press
The Site Security Handbook is a first resource to consult in securing a In order to be considered a SIRT, a team must:
team's infrastructure. SIRT-specific security measures may evolve
later.
7 Appendix B: Known Incident Response Teams - Provide a (secure) channel for receiving reports about
suspected incidents.
- Provide assistance to members of its constituency in
handling these incidents.
- Disseminate incident-related information to its
constituency and to other involved parties.
FIRST is the Forum of Incident Response and Security Teams. Information Note that we are not referring here to police or other law
about FIRST can be found via their World Wide Web home page: enforcement bodies which may investigate computer-related crime.
SIRT members, indeed, should not need to have any powers beyond
those of ordinary citizens.
http://www.first.org/first Vendor:
A 'vendor' is any entity that produces networking or computing
technology, and is responsible for the technical content of that
technology. Examples of 'technology' include hardware (desktop
computers, routers, switches, etc.), and software (operating
systems, mail forwarding systems, etc.).
This page contains pointers to 'Team Contact Information' for SIRTs who Note that the supplier of a technology is not necessarily the
are FIRST members, and to 'Teams with WWW Servers.' 'vendor' of that technology. As an example, an Internet Services
Provider (ISP) might supply routers to each of its customers, but
the 'vendor' is the manufacturer, being the entity responsible for
the technical content of the router, rather than the ISP.
8 Appendix C: Example: a 'filled-in' template Vulnerability:
A 'vulnerability' is a characteristic of a piece of technology
which can be exploited to perpetrate a security incident. For
example, if a program unintentionally allowed ordinary users to
execute arbitrary operating system commands in privileged mode,
this "feature" would be a vulnerability.
<HTML> 5 Appendix B: Related Material
<HEAD>
<TITLE>SIRT Template for XYZ SIRT</TITLE> Important issues in responding to security incidents on a site level
</HEAD> are contained in [RFC 1244], the Site Security Handbook, produced by
the Site Security Handbook Working Group (SSH). This document will
be updated by the SSH working group and will give recommendations for
local policies and procedures, mainly related to the avoidance of
security incidents.
Other documents of interest for the discussion of SIRTs and their
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/
Please refer to file 01-README for further information about
the content of this directory.
Some especially interesting documents in relation to this document are
as follows:
- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/
reports/R-92-01
This report contains the Operational Framework of CERT-NL, the
SIRT of SURFnet (network provider in the Netherlands).
- For readers interested in the operation of FIRST (Forum of
Incident Response and Security Teams) more information is
collected in Appendix C.
- http://hightop.nrl.navy.mil/news/incident.html
This document leads to the NRL Incident Response Manual.
- http://www.cert.dfn.de/eng/team/kpk/certbib.html
This document contains an annotated bibliography of available
material, documents and files about the operation of SIRTs
with links to many of the referenced.
- ftp://info.cert.org/incident_reporting_form
This Incident Reporting Form is provided by the CERT
Coordination Center to gather incident information and to avoid
additional delays by requesting the sites for more detailed
information.
- http://www.cert.org/cert.faqintro.html
A collection of frequently asked questions from the CERT
Coordination Center.
6 Appendix C: Known Security Incident Response Teams
Today, there are many different SIRTs but no single source list every
team. Most of the major and long established teams (the first SIRT was
founded in 1988) are nowadays member of FIRST, the worldwide Forum of
Incident Response and Security Teams. Actually more than 55 teams are
members (1 in Australia, 13 in Europe, all others from America).
Information about FIRST can be found:
- 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 single
teams:
- http://www.first.org/team-info/
For SIRTs which want to become members of this forum (please note, that
a team needs a sponsor - a team already full member of FIRST - to be
introduced), the following files contain more information:
- http://www.first.org/about/op_frame.html
The Operational Framework of FIRST.
- http://www.first.org/docs/newmem.html
Guidelines for teams which want to become member of FIRST.
Many of the European teams, regardless if they are members 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
To learn about existing teams and maybe more suitable teams for one's
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
7 Appendix D: Outline for SIRT Template
This outline summarizes the issues addressed in this document in a logical
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
1.1 Name of the Team
1.2 Address
1.3 Time Zone
1.4 Telephone Number
1.5 Facsimile Number
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
2.1 Date of Last Update
2.2 Distribution List for Notifications
2.3 Locations where this Document May Be Found
3. Charter
3.1 Mission Statement
3.2 Constituency
3.3 Sponsors and/or Affiliation
3.4 Authority
4. Policies
4.1 Types of Incidents and Level of Support
4.2 Cooperation and Interaction with Other Entities
4.3 Disclosure of Information
4.4 Communication and Authentication
4.5 Points of Customer Contacts
5. Services
5.1 Incident Response
5.2 Proactive Activities
6. Incident Reporting Forms
7. Disclaimers
Expectations for Security Incident Response 26 March 97
8 Appendix E: Example - 'filled-in' Template for a SIRT
Below is an example, a filled-in template for a SIRT called XYZ
to avoid any confusion with existing teams. By no means does this
example imply, that a new founded SIRT should reuse this text.
It is for example purposes only.
SIRT Template for XYZ-SIRT
--------------------------
<P>
Note: no digital signature is currently available for this SIRT Note: no digital signature is currently available for this SIRT
Template. We'll put one up as soon as the technology is adopted Template. We'll put one up as soon as the technology is adopted
by XYZ Enterprises. by XYZ Enterprises.
<P>
<XMP>
1. Contact Information 1. Contact Information
1.1 Name of the Team 1.1 Name of the Team
"XYZ-SIRT": the XYZ Computer Emergency Response Team. "XYZ-SIRT": the XYZ Computer Emergency Response Team.
1.2 Address 1.2 Address
XYZ SIRT XYZ SIRT
XYZ Enterprises XYZ Enterprises
Private Bag 12-345
>> Private Bag 12-345 MyTown
>> MyTown MyCountry
>> MyCountry
1.3 Time Zone 1.3 Time Zone
>> MyCountry/Eastern (GMT-0500, and GMT-0400 from April to October) MyCountry/Eastern (GMT-0500, and GMT-0400 from April to October)
1.4 Telephone Number 1.4 Telephone Number
+1 234 567 7890 (ask for the XYZ-SIRT) +1 234 567 7890 (ask for the XYZ-SIRT)
1.5 Facsimile Number 1.5 Facsimile Number
+1 234 567 7654 (this is *not* a secure fax) +1 234 567 7654 (this is *not* a secure fax)
1.6 Other Telecommunication 1.6 Other Telecommunication
None available. None available.
1.7 Electronic Mail Address 1.7 Electronic Mail Address
>> <xyz-sirt@sirt.xyz.org> <xyz-sirt@sirt.xyz.org>
1.8 Public Keys and Other Encryption Information 1.8 Public Keys and Other Encryption Information
Encryption is not currently available, but we plan to install Encryption is not currently available, but we plan to install
PGP as soon as possible. Our PGP public key will appear here PGP as soon as possible. Our PGP public key will appear here
as soon as it is available. as soon as it is available.
Expectations for Security Incident Response 26 March 97
1.9 Team Members 1.9 Team Members
>> Jane Doe of Computing Services is the XYZ-SIRT Jane Doe of Computing Services is the XYZ-SIRT
coordinator. Other team members will be listed here once coordinator. Other team members will be listed here once
their participation is confirmed. their participation is confirmed.
2. Template Updates 2. Document Updates
2.1 Date of Last Update 2.1 Date of Last Update
Please see the bottom of this Web page for this information. Please see the bottom of this Web page for this information.
2.2 Locations where this Template May Be Found 2.2 Distribution List for Notifications
Notifications of updates are submitted to our mailing list
<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
This template is available from the XYZ SIRT WWW This template is available from the XYZ SIRT WWW
site; its URL is site; its URL is
http://www.xyz.org/THIS-INFORMATION-NOT-YET-AVAILABLE http://www.sirt.xyz.org/op_frame.html
>> The template will be signed with the XYZ-SIRT's private PGP The template will be signed with the XYZ-SIRT's PGP
>> key. (WHAT TO DO? Sign just the template? The whole Web key.
>> page? Try ASCII armor? Or have the signature separate?)
There are no plans for the automatic distribution of fresh
copies of this template after updates; please make sure that
you are using the latest version by checking our Web site.
3. Charter 3. Charter
3.1 Mission Statement 3.1 Mission Statement
The purpose of the XYZ-SIRT is, first, to assist members of The purpose of the XYZ-SIRT is, first, to assist members of
XYZ community in implementing proactive measures to reduce XYZ community in implementing proactive measures to reduce
the risks of computer security incidents, and second, to the risks of computer security incidents, and second, to
assist XYZ community in responding to such incidents when assist XYZ community in responding to such incidents when
they occur. they occur.
3.2 Constituency 3.2 Constituency
The XYZ-SIRT's contituency is the XYZ SIRT community, The XYZ-SIRT's constituency is the XYZ SIRT community,
as defined in the context of the "XYZ Policy on Computing as defined in the context of the "XYZ Policy on Computing
Facilities". Facilities".
3.3 Sponsors and/or Affiliation 3.3 Sponsors and/or Affiliation
None. None.
3.4 Authority 3.4 Authority
The XYZ-SIRT operates under the auspices of, and with The XYZ-SIRT operates under the auspices of, and with
authority delegated by, the Department of Computing Services authority delegated by, the Department of Computing Services
of XYZ Enterprises. The Department in turn receives its of XYZ Enterprises. The Department in turn receives its
authority from the formal ruling bodies of XYZ, as authority from the formal ruling bodies of XYZ, as
set out in the "Policy on Computing Facilities". The XYZ-SIRT set out in the "Policy on Computing Facilities". The XYZ-SIRT
Expectations for Security Incident Response 26 March 97
has no direct authority over systems at XYZ Enterprises has no direct authority over systems at XYZ Enterprises
at large. However, it benefits from the direct authority of at large. However, it benefits from the direct authority of
Computing Services with respect to systems managed by this Computing Services with respect to systems managed by this
Department. Also, because Computing Services manages the Department. Also, because Computing Services manages the
XYZ Enterprises Network, and is responsible for connectivity XYZ Enterprises Network, and is responsible for connectivity
to it, the Department has indirect authority over systems to it, the Department has indirect authority over systems
in other departments, inasmuch as the Department can order in other departments, inasmuch as the Department can order
such systems to be disconnected from the network should such systems to be disconnected from the network should
circumstances warrant it. circumstances warrant it.
The XYZ-SIRT expects to work cooperatively with system The XYZ-SIRT expects to work cooperatively with system
administrators and users at XYZ, and, insofar as administrators and users at XYZ, 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-SIRT 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.
4. Policies 4. Policies
4.1 Types of Incidents 4.1 Types of Incidents and Level of Support
The XYZ-SIRT is authorized to address all types of computer The XYZ-SIRT is authorized to address all types of computer
security incidents which occur, or risk occurring, at security incidents which occur, or risk occurring, at
XYZ Enterprises. XYZ Enterprises.
4.2 Level of Support
The level of support given by XYZ-SIRT will vary depending on The level of support given by XYZ-SIRT 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 consituent, the size of the user community affected, and the
XYZ-SIRT's resources at the time. XYZ-SIRT's resources at the time.
No direct support will be given to end users; they are No direct support will be given to end users; they are
expected to contact their system administrator, network expected to contact their system administrator, network
administrator, or department head for assistance. The administrator, or department head for assistance. The
XYZ-SIRT will support the latter people. XYZ-SIRT will support the latter people.
While the XYZ-SIRT understands that there exists great While the XYZ-SIRT understands that there exists great
variation in the level of system administrator expertise at variation in the level of system administrator expertise at
XYZ, and while the XYZ-SIRT will endeavour to present XYZ, and while the XYZ-SIRT will endeavor to present
information and assistance at a level appropriate to information and assistance at a level appropriate to
each person, the XYZ-SIRT cannot train system administrators, each person, the XYZ-SIRT cannot train system administrators,
and it cannot perform system maintenance on their behalf. and it cannot perform system maintenance on their behalf.
In most cases, the XYZ-SIRT will provide pointers to the In most cases, the XYZ-SIRT will provide pointers to the
information needed to implement appropriate measures. information needed to implement appropriate measures.
4.3 Disclosure of Information Expectations for Security Incident Response 26 March 97
>> &&&&&&&&&&&&&&&&&&&&
>> Difficult section; not done yet. Also, it overlaps heavily 4.2 Cooperation and Interaction with Other Entities
>> with the section below; I'm not sure of the best way to
>> separate them. Questions not yet addressed:
- reporting incidents within the constituency to other teams;
- handling incidents occurring within the constituency, but
reported from outside it.
- reporting observations from within the constituency
indicating suspected or confirmed incidents outside it;
- acting on reports of incidents occurring outside the
constituency;
- passing information about vulnerabilities to vendors, to
Partner SIRTs or directly to affected sites lying within
or outside the 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.
Food for thought:
Types of info:
- Contact info for constituents.
- Technical info about a vulnerability.
- Technical info about XYZ facilities.
- Information about incidents:
- Statistical summaries
- Admission of incident of certain type
- Admission of root compromise
- Admission of packet sniffing attack
- Admission that user accounts were compromised
- Description of incident
- Identity of affected systems
- Identity of affected people
- Identity of perpetrator
Recipients of info:
- XYZ management
- Computing Services management
- Affected sysadmin at XYZ
- Affected sysadmin (or SIRT) at another site
- Affected user(s) at XYZ
- All sysadmins potentially concerned (potentially
vulnerable) at XYZ
- All sysadmins at XYZ
- All users potentially concerned at XYZ
(information will leak to general public)
- All users at XYZ (ditto)
- Computer security community
- Peer sysadmins and SIRTs
- Vendors
- Law enforcement
4.4 Cooperation and Interaction with Other Entities
- Other sites: - Other sites:
The XYZ-SIRT will cooperate with other SIRTs (security The XYZ-SIRT will cooperate with other SIRTs (security
incident response teams) and with system administrators at incident response teams) and with system administrators at
other sites, to the extent that their bona fide can be other sites, to the extent that their bona fide can be
verified. Should provincial or national SIRTs be verified. Should provincial or national SIRTs be
constituted, XYZ-SIRT will explore the possibility of peer constituted, XYZ-SIRT will explore the possibility of peer
relationships with them. The possibility of peer relationships with them. The possibility of peer
relationships with close neighbours will also be explored; relationships with close neighbors will also be explored;
unofficial cooperative climates already exist between XYZ unofficial cooperative climates already exist between XYZ
and several nearby universities and large corporations. and several nearby universities and large corporations.
While there are no legal requirements that XYZ-SIRT provide While there are no legal requirements that XYZ-SIRT provide
eny information to any body outside XYZ (aside from any information to any body outside XYZ (aside from
law enforcement agencies), XYZ-SIRT will provide such law enforcement agencies), XYZ-SIRT will provide such
information when the good of the community justifies it. information when the good of the community justifies it.
However, unless identifying information is needed to track However, unless identifying information is needed to track
an incident in progress, such information will be stripped an incident in progress, such information will be stripped
from the report (unless the affected department gives its from the report (unless the affected department gives its
permission that the real information be used). permission that the real information be used).
- Vendors: - Vendors:
The XYZ-SIRT wishes to encourage vendors of all kinds of The XYZ-SIRT wishes to encourage vendors of all kinds of
networking and computer equipment, software, and services networking and computer equipment, software, and services
to improve the security of their products. In aid of to improve the security of their products. In aid of
this, a vulnerability discovered in such a product will be this, a vulnerability discovered in such a product will be
reported to its vendor, along with all technical details reported to its vendor, along with all technical details
needed to identify and fix the problem. Identifying needed to identify and fix the problem. Identifying
details will not be given to the vendor without the details will not be given to the vendor without the
permission of the affected parties. permission of the affected parties.
- Law enforcement: - Law enforcement:
>> XYZ has its own Security Department. ( I NEED TO LOOK UP XYZ has its own Security Department. ( I NEED TO LOOK UP
>> THE RELATIONSHIP BETWEEN COMPUTING SERVICES, XYZ THE RELATIONSHIP BETWEEN COMPUTING SERVICES, XYZ
>> SECURITY, AND OUTSIDE POLICE FORCES. ) Informal working SECURITY, AND OUTSIDE POLICE FORCES. ) Informal working
relationships already exist between some system relationships already exist between some system
administrators at XYZ and the local police; interest administrators at XYZ and the local police; interest
has been expressed by all parties in formalising these has been expressed by all parties in formalizing these
relationships. Any progress relationships. Any progress
made in that area will be reflected in this section. made in that area will be reflected in this section.
In the meantime, authorized and unauthorized users of the In the meantime, authorized and unauthorized users of the
XYZ Computing Facilities should be aware that the XYZ Computing Facilities should be aware that the
XYZ-SIRT will cooperate fully with law enforcement XYZ-SIRT will cooperate fully with law enforcement
agencies in detecting, reporting, documenting, and agencies in detecting, reporting, documenting, and
prosecuting violations of the law; users concerned about prosecuting violations of the law; users concerned about
confidentiality are referred to the XYZ "Policy on confidentiality are referred to the XYZ "Policy on
Computing Facilities". Computing Facilities".
Expectations for Security Incident Response 26 March 97
- The Press: - The Press:
The XYZ-SIRT will not interect directly with the Press. The XYZ-SIRT will not interact directly with the Press.
If necessary, information will be provided to the If necessary, information will be provided to the
XYZ Public Relations Department, and to the XYZ Public Relations Department, and to the
Customer Relations group of the Computing Services Customer Relations group of the Computing Services
Department. All queries will be referred to these two Department. All queries will be referred to these two
bodies. bodies.
- The XYZ SIRT community: - The XYZ SIRT community:
Details of incidents may be released to Computing Services Details of incidents may be released to Computing Services
management, XYZ management, or the Computer management, XYZ management, or the Computer
Resources Committee; these bodies will be charged with Resources Committee; these bodies will be charged with
maintaining the confidentiality of the information. General maintaining the confidentiality of the information. General
skipping to change at page 23, line 12 skipping to change at page 26, line 55
In the paragraphs above, the "affected parties" refers to the In the paragraphs above, the "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 usage of a facility; such intruders may have no
expectation of confidentiality from the XYZ-SIRT. They may or expectation of confidentiality from the XYZ-SIRT. 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.5 Communication and Authentication 4.3 Disclosure of Information
The following types of information will be stored and handled
by XYZ-SIRT:
- Contact info for constituents.
- Technical info about a vulnerability.
- Technical info about XYZ facilities.
- Information about incidents:
- Statistical summaries
- Admission of incident of certain type
- Admission of root compromise
- Admission of packet sniffing attack
- Admission that 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
know - are as follows:
- XYZ management
- Computing Services management
- Affected sysadmin at XYZ
- Affected sysadmin (or SIRT) at another site
Expectations for Security Incident Response 26 March 97
- Affected user(s) at XYZ
- All sysadmins potentially concerned (potentially
vulnerable) at XYZ
- All sysadmins at XYZ
- All users potentially concerned at XYZ
(information will leak to general public)
- All users at XYZ (ditto)
- Computer security community
- Peer sysadmins and SIRTs
- Vendors
- Law enforcement
4.4 Communication and Authentication
In view of the types of information that the XYZ-SIRT will In view of the types of information that the XYZ-SIRT 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.
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-SIRT, 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, and with known
neighbour 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.
4.6 Points of Customer Contact 4.5 Points of Customer Contact
The preferred method for contacting the XYZ-SIRT will be The preferred method for contacting the XYZ-SIRT will be
e-mail. If this is not possible, or not advisable for e-mail. If this is not possible, or not advisable for
security reasons, the XYZ-SIRT can be reached by telephone security reasons, the XYZ-SIRT can be reached by telephone
during regular office hours. during regular office hours.
Expectations for Security Incident Response 26 March 97
5. Services 5. Services
5.1 Incident Response 5.1 Incident Response
>> &&&&&&&&&&&&&&&&&&&&&&&7
>> This section requires a lot of thought. XYZ-SIRT will help users and administrators to handle the
technical and organizational aspects of incidents. By that,
it will provide and facilitate:
- to understand the extend of the incident
- ...
5.2 Proactive Activities 5.2 Proactive Activities
The XYZ-SIRT will coordinate and maintain the following The XYZ-SIRT will coordinate and maintain 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.
- 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.
- 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.
- Repository of security tools for use by sysadmins. - Repository of security tools for use by sysadmins.
skipping to change at page 24, line 12 skipping to change at page 28, line 30
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.
- 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.
- 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.
- Repository of security tools for use by sysadmins. - Repository of security tools for use by sysadmins.
- "Clipping" service for various existing resources, such - "Clipping" service for various existing resources, such
as major mailing lists and newsgroups; important issues as major mailing lists and newsgroups.
of relevance to operating environments in use at the
XYZ will be reported and archived.
- Auditing services - Auditing services
- Central file integrity checking service for Unix - Central file integrity checking service for Unix
machines. machines.
- "Tiger teams".
- Security level assignments; machines at XYZ - Security level assignments; machines at XYZ
will be audited and assigned a security level: not all will be audited and assigned a security level.
machines require or can attain the same level of
security, but it is important to know which ones are
reasonably secure and which are not.
- Archiving services - Archiving services
- Central logging services for Unix machines.
- Records of security incidents handled. - Records of security incidents handled.
6. Incident Reporting Forms 6. Incident Reporting Forms
>> &&&&&&&& Not done yet; I'll probably use an existing There are no own forms developed yet for reporting incidents
>> one from somewhere initially. to XYZ-SIRT. If possible, please make us of the Incident
Reporting Form of the CERT Coordination Center (Pittsburgh, PA).
The actual version is available from:
ftp://info.cert.org/incident_reporting_form
7. Disclaimers 7. Disclaimers
>> -- resp. for technical disclosures (bugtraq) etc.?
>> -- resp. for results for XYZ-SIRT advice?
>> &&&&&&&&&&&&&&&&&&&7
>> WILL NEED XYZ LEGAL COUNSEL ON THIS?
8. Additional Information
The version of this template published in this RFC will undoubtedly be While every precaution will be taken in the preparation of
out of date by the time you see it; it is intended as an example only. information, notifications and alerts, XYZ-SIRT assumes no
Please pick up a fresh copy from our Web site if you actually need responsibility for errors or omissions, or for damages
information about XYZ-SIRT. resulting from the use of the information contained within.
History of this template: Expectations for Security Incident Response 26 March 97
1996/07/29 Jane Doe, version 1.0 9 References
THIS VERSION HAS ABSOLUTELY NO MANAGEMENT APPROVAL!
</XMP> [RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. - July 23,
1991. - 101 pages. - FYI 8.
</BODY> [RFC 1983] G. Malkin / Internet Users' Glossary. - August 16, 1996. -
</HTML> 62 pages. - FYI 18.
9 Security Considerations 10 Security Considerations
This document discusses the operation of Security Incident Response This document discusses issues of the operation of Security Incident
Teams, and is therefore not directly concerned with the security of Response Teams, and the teams interactions with their constituency.
protocols or network systems themselves. 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 Nonetheless, it is vital that SIRTs establish secure communication
channels with other teams, and with members of their constituency. They channels with other teams, and with members of their constituency.
must also secure their own systems and infrastructure. 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.
10 Author's Address 11 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
Sun Microsystems, Inc.
Gaisbergstr. 6
69115 Heidelberg Germany
Phone: +49 6221 601649
E-Mail: eguttman@eng.sun.com
This document expires September 26, 1997.
 End of changes. 214 change blocks. 
600 lines changed or deleted 912 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/