draft-ietf-grip-framework-irt-00.txt   draft-ietf-grip-framework-irt-01.txt 
Internet Engineering Task Force Nevil Brownlee Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT John White INTERNET-DRAFT The University of Auckland
The University of Auckland Expires in six months
September 1995
Framework for Security Incident Response Expectations for Security Incident Response
<draft-ietf-grip-framework-irt-00.txt> <draft-ietf-grip-framework-irt-01.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. Internet Accounting 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.
skipping to change at page 2, line ? skipping to change at page 2, line ?
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.'
Please check the I-D abstract listing contained in the Internet-drafts Please check the I-D abstract listing contained in the Internet-drafts
Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or
any other Internet Draft. any other Internet Draft.
Abstract Abstract
This document provides guidelines for Internet Security Incident This document explains what is expected of Incident Response Teams
Response Teams (IRTs), and recommends a "template" through which every (IRTs), provides guidelines for IRTs, and recommends a "template"
IRT should describe itself and its functions. It was produced by the through which every IRT should describe itself and its functions. It
GRIP Working Group of the IETF. was produced by the GRIP Working Group of the IETF.
Contents Contents
1 Introduction 2 1 Introduction 2
1.1 Template Repository . . . . . . . . . . . . . . . . . . . . . . 3 1.1 User Expectations . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Publishing IRT Templates . . . . . . . . . . . . . . . . . . . 3
2 Description Template: Security Incident Response Team 3 2 Description Template: Security Incident Response Team 4
3 Purpose of the Template 5 3 Purpose of the Template 5
3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 5 3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 6
4 Definitions 6
4.1 Constituency . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Partner Teams . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Definitions 7
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5 Security Incident Response Team . . . . . . . . . . . . . . . . 7
4.6 Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7 Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 The Security Incident Response Team Template 8 5 The Security Incident Response Team Template 9
5.1 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1 Date of last update . . . . . . . . . . . . . . . . . . . 8 5.1.1 Date of last update . . . . . . . . . . . . . . . . . . . . 9
5.1.2 Distribution List for Template Updates . . . . . . . . . . 9 5.1.2 Distribution list for Template Updates . . . . . . . . . . 9
5.2 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1 Mission Statement . . . . . . . . . . . . . . . . . . . . . 9 5.2.1 Mission Statement . . . . . . . . . . . . . . . . . . . . . 10
5.2.2 Constituency . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.2 Constituency . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3 Sponsoring organization / affiliation . . . . . . . . . . . 10 5.2.3 Sponsoring organization / affiliation . . . . . . . . . . . 10
5.2.4 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.4 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1 Types of incidents and level of support . . . . . . . . . . 10 5.3.1 Types of incidents and level of support . . . . . . . . . . 11
5.3.2 Co-operation and interaction with other organizations . . . 10 5.3.2 Co-operation and interaction with other organizations . . . 11
5.3.3 Reporting and Disclosure . . . . . . . . . . . . . . . . . 11 5.3.3 Reporting and Disclosure . . . . . . . . . . . . . . . . . 12
5.3.4 Communication and authentication . . . . . . . . . . . . . 12 5.3.4 Communication and authentication . . . . . . . . . . . . . 13
5.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5 Incident reporting Forms . . . . . . . . . . . . . . . . . . . 14
5.6 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6 Appendix: Note on procedure definitions 13 6 Appendix A: Note on procedure definitions 14
7 Security Considerations 14 7 Appendix B: Known Incident Response Teams 15
8 Author's Addresses 14 8 Security Considerations 15
9 Author's Address 16
1 Introduction 1 Introduction
The Working Group group was formed to provide guidelines and The Working Group was formed to provide guidelines and recommendations
recommendations to facilitate the consistent handling of security to facilitate the consistent handling of security incidents in the
incidents in the Internet community. 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.
Security incidents and potential threats of them usually extend beyond Security incidents and potential threats of them usually extend beyond
institutional or local community boundaries. "Consistent handling" institutional or local community boundaries. "Consistent handling"
implies that any group calling itself an Incident Response Team (IRT) implies that any group calling itself an Incident Response Team (IRT)
must react to security incidents or to threats of them in ways which the must react to security incidents or to threats of them in ways which the
general Internet community agrees to be in its general interest. general Internet community agrees to be in its general interest.
The "Framework for Security Incident Response" is seen as resting on the The "Expectations for Security Incident Response" is seen as resting on
the work of individual IRTs and the cooperation between them.
work of individual IRTs and the cooperation between them.
This document therefore recommends a "template" through which every IRT This document therefore recommends a "template" through which every IRT
should describe itself and its functions. It further recommends that should describe itself and its functions. It further recommends that
templates should be accessible among teams, to make possible a fully templates should be accessible among teams, to make possible a fully
effective cooperative response framework for incidents or threats across effective cooperative response framework for incidents or threats across
the entire domain affected by them. the entire domain affected by them.
1.1 Template Repository 1.1 User Expectations
This document provides a detailed discussion of all aspects of incident
response. It is also intended to provide a common understanding of what
is involved in, and implied by, each section of an IRT's template.
An incident response team exists primarily to support the users in its
constituency. It is vital that those users understand what they should
expect of their team. Provided that an IRT has published its template,
a constituent/customer 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 contacting
downstream sites. Users should certainly expect an IRT to provide the
services they detail in their IRT.
An important aspect of incident response is the 'follow through' - every
incident should be investigated and appropriate actions taken. Users
should be encouraged by their IRT to report incidents so they can be
acted upon. It must be emphasised that without active participation
(especially reporting) from users the effectiveness of the services they
depend on can be greatly diminished. As a minimum, users need to know
that they should report security incidents, and know how and where they
should report them.
1.2 Publishing IRT Templates
If templates are to be accessible between IRTs, a central repository If templates are to be accessible between IRTs, a central repository
will be needed for them. The GRIP Working Group believe that some of will be needed for them. The GRIP Working Group believe that some of
the existing Internet archive areas could be used for this purpose. the existing Internet archive areas could be used for this purpose.
Digital signatures should be used to protect the completed templates
against modifications. The keeper of each template repository will be
responsibly for verifying the identity of each IRT lodging a template in
the repository.
Each team should be responsible for ensuring that its own template is Each team should be responsible for ensuring that its own template is
available to at least its constituency and its co-operating partner available to at least its own constituency and to any other groups it
teams. Digital signatures should be used to protect the completed needs to interact with frequently. These groups will include any
templates against modifications. The keeper of each template repository 'up-stream' sites and/or IRTs which the team needs to report to.
will be responsibly for verifying the identity of each IRT loding a
template in the repository.
concerning the sharing of Template information) --- Whether or not an IRT lodges a copy of its template in a repository, it
should publish one on its own information server so that users in its
constituency can easily find it. Templates published as pages in the
World Wide Web should include the phrase 'IRT Template' in their title;
this will allow Web search engines to find them easily.
The Template is summarized in the section immediately below, and the Individual users who observe a security incident should ask their
remainder of the document describes its components. Internet Service Provider for details of the most suitable IRT to report
it to.
Appendix B (below) provides some pointers to IRTs which were known when
this document was published.
2 Description Template: Security Incident Response Team 2 Description Template: Security Incident Response Team
The Template is summarized in the section immediately below, and the
remainder of the document describes its components.
Contact Information Contact Information
------------------- -------------------
* name of the team * name of the team
* address * address
* telephone * telephone
* telefax * facsimile
* other telecommunication like STU-III * other telecommunication like STU-III
* electronic mail * electronic mail
* encryption methods for communication: PGP, PEM, MOSS, .. * encryption methods for communication: PGP, PEM, MOSS, ..
* actual list of members on demand (optional) * actual list of members on demand (optional)
Template Updates Template Updates
---------------- ----------------
* Date of last update * Date of last update
* Distribution of template updates * Distribution list for template updates
Charter Charter
------- -------
* mission statement * mission statement
* constituency * constituency
* sponsor / affiliation * sponsor / affiliation
* authority * authority
Policies Policies
-------- --------
skipping to change at page 6, line 19 skipping to change at page 6, line 46
Some especially interesting documents are: Some especially interesting documents are:
* CERT-NL Framework * CERT-NL Framework
ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt ftp://ftp.cert.dfn.de/pub/csir/docs/cert-nl.opframe.txt
* FIRST potential members * FIRST potential members
ftp://ftp.first.org/pub/first/newmemlt.txt ftp://ftp.first.org/pub/first/newmemlt.txt
ftp://ftp.first.org/pub/first/profile.txt ftp://ftp.first.org/pub/first/profile.txt
ftp://ftp.first.org/pub/first/op`frame.txt ftp://ftp.first.org/pub/first/op`frame.txt
http://www.first.org/first
* NRL Incident Response Manual
http://hightop.nrl.navy.mil/news/incident.html
* Bibliography * Bibliography
http://www.cert.dfn.de/eng/team/kpk/certbib.html http://www.cert.dfn.de/eng/team/kpk/certbib.html
4 Definitions 4 Definitions
This section defines terms used in describing security incidents and This section defines terms used in describing security incidents and
response teams. For the purpose of the GRIP documents only a limited response teams. For the purpose of the GRIP documents only a limited
list is really needed. This should help maintain focus on the purpose list is really needed. This should help maintain focus on the purpose
of the documents, and prevent a duplication of other definitions or - of the documents, and prevent a duplication of other definitions or -
even worse - a proliferation of competing definitions. even worse - a proliferation of competing definitions.
4.1 Constituency Constituency
------------
Implicit in the purpose of a Security Incident Response Team is the Implicit in the purpose of a Security Incident Response Team is the
existence of a constituency. This is the group of users, sites, existence of a constituency. This is the group of users, sites,
networks or organizations served by the team. networks or organizations served by the team.
4.2 Partner Teams Security Incident
-----------------
Implicit in the purpose of the Template proposed here is the existence
of Partner Teams which are its primary audience, and which share in the
responsibility for addressing security incidents or threats common to
their separate constituencies.
4.3 Security
After considerable discussion, the Working Group decided not to attempt
a definition of "security", but instead to rely on intuition, or on
definitions in other documents such as the Site Security Handbook.
4.4 Incident
For the purpose of this document: For the purpose of this document:
'A computer security incident is any event which compromises 'A computer security incident is any event which compromises
some aspect of computer or network security.' some aspect of computer or network security.'
The definition of an incident may vary between organizations, but at The definition of an incident may vary between organizations, but at
least the following categories are generally applicable: least the following categories are generally applicable:
* loss of confidentiality, * loss of confidentiality,
skipping to change at page 7, line 36 skipping to change at page 8, line 14
These are very general categories. For instance the forging of an These are very general categories. For instance the forging of an
electronic mail message and a successful password attack are two electronic mail message and a successful password attack are two
examples of 'compromise of integrity.' examples of 'compromise of integrity.'
Within the definition of an incident the word 'compromised' is used. Within the definition of an incident the word 'compromised' is used.
Sometimes an administrator may only 'suspect' an incident. During the Sometimes an administrator may only 'suspect' an incident. During the
handling of a call it must be established whether or not an incident handling of a call it must be established whether or not an incident
really occurred. really occurred.
4.5 Security Incident Response Team Security Incident Response Team
-------------------------------
Based on two of the definitions given above: Based on two of the definitions given above:
'A Security Incident Response Team is a group authorized to deal 'A Security Incident Response Team is a group authorized to deal
with security incidents that occur within its defined constituency.' with security incidents that occur within its defined constituency.'
It should provide a channel for receiving reports about suspected It should provide a channel for receiving reports about suspected
incidents and for disseminating incident-related information to its incidents and for disseminating incident-related information to its
constituency and to other related parties; it should also provide constituency and to other related parties; it should also provide
assistance to members of its constituency in handling these incidents. assistance to members of its constituency in handling these incidents.
4.6 Vendor Vendor
------
A 'vendor' is any entity that produces networking or computing A 'vendor' is any entity that produces networking or computing
technology, and is responsible for the technical content of that technology, and is responsible for the technical content of that
technology. Examples of 'technology' include hardware (routers, technology. Examples of 'technology' include hardware (routers,
switches, etc), and software (operating systems, mail forwarding switches, etc.), and software (operating systems, mail forwarding
systems, etc). systems, etc.).
Note that the supplier of a technology is not necessarily the 'vendor' Note that the supplier of a technology is not necessarily the 'vendor'
of that technology. As an example, an Internet Services Provider (ISP) of that technology. As an example, an Internet Services Provider (ISP)
might supply routers to each of its customers, but the 'vendor' is the might supply routers to each of its customers, but the 'vendor' is the
manufacturer, being the entity responsible for the technical content of manufacturer, being the entity responsible for the technical content of
the router, rather than the ISP. the router, rather than the ISP.
4.7 Vulnerability Vulnerability
-------------
A 'vulnerability' is a characteristic of a piece of technology which can A 'vulnerability' is a characteristic of a piece of technology which can
be exploited to perpetrate a security incident. For example, if a be exploited to perpetrate a security incident. For example, if a
program allowed ordinary users to execute operating system commands in program allowed ordinary users to execute operating system commands in
privileged mode, this "feature" would be a vulnerability. privileged mode, this "feature" would be a vulnerability.
5 The Security Incident Response Team Template 5 The Security Incident Response Team Template
This material which follows is addressed to those responsible for This material which follows is addressed to those responsible for
Security Incident Response Teams. Security Incident Response Teams.
5.1 Template Updates 5.1 Template Updates
skipping to change at page 9, line 10 skipping to change at page 9, line 25
Details of an IRT change with time, so the template must indicate when Details of an IRT change with time, so the template must indicate when
it was last changed, who will be informed of future changes, and (by it was last changed, who will be informed of future changes, and (by
implication) who will not. Without this, it is inevitable that implication) who will not. Without this, it is inevitable that
misunderstandings and misconceptions will arise over time. misunderstandings and misconceptions will arise over time.
5.1.1 Date of last update 5.1.1 Date of last update
This should be sufficient to allow anyone interested to evaluate the This should be sufficient to allow anyone interested to evaluate the
currency of the template. currency of the template.
5.1.2 Distribution of Template Updates 5.1.2 Distribution list for Template Updates
Persons on this list are notified automatically whenever the template is Persons on this list are notified automatically whenever the template is
changed. The list might normally cover the constituency and immediate changed. The list might normally cover the constituency and any other
Partner IRTs. Readers not on the list can then recognise that they groups the IRT has frequent interactions with. Readers not on the list
should check the central repository (above) for possible updates. can then recognise that they should check the central repository (above)
for possible updates.
Digital signatures should be used for update messages sent by an IRT to Digital signatures should be used for update messages sent by an IRT to
those on its distribution list. those on its distribution list.
5.2 Charter 5.2 Charter
Every IRT must have a charter which specifying what it is to do, and the Every IRT must have a charter which specifying what it is to do, and the
authority under which it will do it. The charter should include at authority under which it will do it. The charter should include at
least the following: least the following:
skipping to change at page 10, line 34 skipping to change at page 11, line 13
"Who is your God?". "Who is your God?".
5.2.4 Authority 5.2.4 Authority
IRTs may not have authority to intervene in the operation of all the IRTs 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 their
control as distinct from the perimeter of their constituency; if other control as distinct from the perimeter of their constituency; if other
IRTs operate hierachically within their perimeter, these should be IRTs operate hierachically within their perimeter, these should be
identified. identified.
5.3 Policies 5.3 Policies
5.3.1 Types of incidents and level of support 5.3.1 Types of incidents and level of support
The types of incident which the team is authorised to address and the The types of incident which the team is authorised to address and the
level of support the team will contribute in assisting with each type of level of support the team will contribute in assisting with each type of
incident should be summarized here in list form. The Services section incident should be summarized here in list form. The Services section
(later) provides opportunity for more detailed definition. (later) provides opportunity for more detailed definition.
The team should state whether it will act on information it receives The team should state whether it will act on information it receives
skipping to change at page 11, line 4 skipping to change at page 11, line 24
5.3.1 Types of incidents and level of support 5.3.1 Types of incidents and level of support
The types of incident which the team is authorised to address and the The types of incident which the team is authorised to address and the
level of support the team will contribute in assisting with each type of level of support the team will contribute in assisting with each type of
incident should be summarized here in list form. The Services section incident should be summarized here in list form. The Services section
(later) provides opportunity for more detailed definition. (later) provides opportunity for more detailed definition.
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 an IRT. service requirement for an IRT.
5.3.2 Co-operation and interaction with other organizations 5.3.2 Co-operation and interaction with other organizations
This section should make explicit the related groups with which the IRT This section should make explicit the related groups with which the IRT
interacts: routinely interacts. Examples of these are listed below.
* incident response teams Incident Response Teams: An IRT will often need to interact with
* vendors other IRTs. For example an IRT within a large company may need to
* law-enforcement agencies report incidents to a national IRT, and a national IRT may need to
* press report incidents to national IRTs in other countries.
Vendors: Larger vendors have their own IRTs, but smaller vendors may
not. In such cases an IRT will need to work directly with a vendor.
Law-enforcement agencies: These include the police and other
investigative agencies. IRTs and users of the template should be
sensitive to local laws and regulations, which may vary considerably in
different countries.
Press: An IRT may be approached by the Press for information and
comment from time to time. This is discussed in more detail below
(Reporting and Disclosure).
5.3.3 Reporting and Disclosure 5.3.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 can only be 'confidential,' but rigid adherence to this
makes the team a 'black hole.' Its template should define what makes the team a 'black hole.' Its template should define what
information it will report or disclose, to whom, and when. 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
skipping to change at page 12, line 36 skipping to change at page 13, line 21
Methods of secure and verifiable communication should be established. Methods of secure and verifiable communication should be established.
This is necessary for communication between IRTs and between an IRT and This is necessary for communication between IRTs and between an IRT and
its constituents. The template should include public keys or pointers its constituents. The template should include public keys or pointers
to them, including key fingerprints, together with guidelines on how to to them, including key fingerprints, together with guidelines on how to
use this information to check authenticity. use this information to check authenticity.
At the moment it is recommended that every IRT have, as a minimum, a PGP At the moment it is recommended that every IRT have, as a minimum, a PGP
key available, since PGP is available world-wide. Teams may also make key available, since PGP is available world-wide. Teams may also make
other mechanisms available, for example PEM. other mechanisms available, for example PEM.
For comunication via telephone or facsimile an IRT may keep secret For communication via telephone or facsimile an IRT 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.
5.4 Services 5.4 Services
Services should be defined in two sections, as listed below. Services should be defined in two sections, as listed below.
* direct incident response * direct incident response
+ verification of incident + verification of incident
+ technical assistance analysis to understand compromise + technical assistance analysis to understand compromise
+ notification of other involved parties + notification of other involved parties
+ eradication + eradication
+ recovery + recovery
* optional * optional
+ information provision + information provision
- vunerablility archive - vulnerability archive
- patches and resolutions - patches and resolutions
+ tools + tools
+ education + education
+ audit and consulting + audit and consulting
+ product evaluation + product evaluation
5.5 Incident reporting Forms 5.5 Incident reporting Forms
Samples of reporting forms used by the IRT (or pointers to them) should Samples of reporting forms used by the IRT (or pointers to them) should
be included at this point in a template. be included at this point in a template.
skipping to change at page 14, line 5 skipping to change at page 14, line 31
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 our German template
into English, we can not be certain that both documents express into English, we can not be certain that both documents express
the same thoughts in the same level of detail and correctness. the same thoughts in the same level of detail and correctness.
In all cases, where there is a difference between both In all cases, where there is a difference between both
versions, the German version is the binding version for our versions, the German version is the binding version for our
operation. operation.
6 Appendix: Note on procedure definitions 6 Appendix A: Note on procedure definitions
Policies and statements of services in the template have to be Policies and statements of services in the template have to be
implemented as procedures, but descriptions of those procedures should implemented as procedures, but descriptions of those procedures should
not be included in the template. not be included in the template.
The following notes are intended to assist those seeking to form or to The following notes are intended to assist those seeking to form or to
improve their IRTs. improve their IRTs.
* External * External
+ identify other response teams + identify other response teams
skipping to change at page 14, line 37 skipping to change at page 15, line 19
+ define expiry of sensitive data + define expiry of sensitive data
+ define disposal practice for sensitive data + define disposal practice for sensitive data
+ establish methods for gathering and keeping statistics + establish methods for gathering and keeping statistics
+ establish 'knowledge base' of lessons learned from past incidents + establish 'knowledge base' of lessons learned from past incidents
+ create practical implementations of disclosure policies + create practical implementations of disclosure policies
+ document explicit practices for disclosure to the Press + document explicit practices for disclosure to the Press
The Site Security Handbook is a first resource to consult in securing a The Site Security Handbook is a first resource to consult in securing a
team's infrastructure. IRT-specific security measures may evolve later. team's infrastructure. IRT-specific security measures may evolve later.
7 Security Considerations 7 Appendix B: Known Incident Response Teams
FIRST is the Forum of Incident Response and Security Teams. Information
about FIRST can be found via their World Wide Web home page:
http://www.first.org/first
This page contains pointers to 'Team Contact Information' for IRTs who
are FIRST members, and to 'Teams with WWW Servers.'
8 Security Considerations
This document discusses the operation of Security Incident Response This document discusses the operation of Security Incident Response
Teams, and is therefore not directly concerned with the security of Teams, and is therefore not directly concerned with the security of
protocols or network systems themselves. protocols or network systems themselves.
Nonetheless, it is vital that IRTs establish secure communication Nonetheless, it is vital that IRTs 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.
8 Author's Addresses 9 Author's Address
Nevil Brownlee Nevil Brownlee
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
John White
The University of Auckland
Phone: +64 9 373 7599 x8946
E-mail: j.white@auckland.ac.nz
 End of changes. 45 change blocks. 
94 lines changed or deleted 144 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/