draft-ietf-grip-framework-irt-02.txt   draft-ietf-grip-framework-irt-03.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
Expectations for Security Incident Response Expectations for Security Incident Response
<draft-ietf-grip-framework-irt-03.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.
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.'
Please check the I-D abstract listing contained in the Internet-drafts To learn the current status of any Internet Draft, please check the
Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, '1id-abstracts.txt' listing contained in the Internet Drafts shadow
ftp.nisc.sri.com or munnari.oz.au to learn the current status of this or directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
any other Internet Draft. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract Abstract
This document is intended to facilitate the setting of expectations This document is intended to facilitate the setting of expectations
regarding the operation of Security Incicident Response Teams (SIRTs). regarding the operation of Security Incicident Response Teams (SIRTs).
It describes the various important topics in the form of a 'template,' It describes the various important topics in the form of a 'template,'
through which every SIRT should describe itself and its functions. through which every SIRT should describe itself and its functions.
SIRT clients have a legitimate need and right to fully understand the SIRT clients have a legitimate need and right to fully understand the
policies and procedures of their Security Incident Response Team. A policies and procedures of their Security Incident Response Team. A
SIRT's template supplies details for the various important topics which SIRT's template supplies details for the various important topics which
clients must consider when selecting a SIRT. clients must consider when selecting a SIRT.
Contents Contents
1 Introduction 2 1 Introduction 3
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Publishing SIRT Templates . . . . . . . . . . . . . . . . . . 5 1.2 Publishing SIRT Templates . . . . . . . . . . . . . . . . . . 6
1.3 Establishing Peering Between SIRTs . . . . . . . . . . . . . . 6 1.3 Relationships between SIRTs . . . . . . . . . . . . . . . . . 6
2 Description Template: Security Incident Response Team 6 1.4 Establishing Communications between SIRTs . . . . . . . . . . 7
2 Description Template: Security Incident Response Team 7
3 Purpose of the Template 8 3 Purpose of the Template 8
3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 8 3.1 Other Related Material . . . . . . . . . . . . . . . . . . . . 9
4 The Security Incident Response Team Template 9 4 The Security Incident Response Team Template 10
4.1 Contact Information . . . . . . . . . . . . . . . . . . . . . 9 4.1 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Template Updates . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1Date of last update . . . . . . . . . . . . . . . . . . . . 10
4.2.1Date of last update . . . . . . . . . . . . . . . . . . . . 10 4.1.2Distribution list for Template Updates . . . . . . . . . . 10
4.2.2Distribution list for Template Updates . . . . . . . . . . 10 4.2 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1Mission Statement . . . . . . . . . . . . . . . . . . . . . 11
4.3.1Mission Statement . . . . . . . . . . . . . . . . . . . . . 10 4.2.2Constituency . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2Constituency . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.3Sponsoring organization / affiliation . . . . . . . . . . . 12
4.3.3Sponsoring organisation / affiliation . . . . . . . . . . . 11 4.2.4Authority . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.4Authority . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.1Types of incidents and level of support . . . . . . . . . . 12
4.4.1Types of incidents and level of support . . . . . . . . . . 12 4.3.2Co-operation and interaction with other organizations . . . 12
4.4.2Co-operation and interaction with other organizations . . . 12 4.3.3Reporting and Disclosure . . . . . . . . . . . . . . . . . 13
4.4.3Reporting and Disclosure . . . . . . . . . . . . . . . . . 13 4.3.4Communication and authentication . . . . . . . . . . . . . 14
4.4.4Communication and authentication . . . . . . . . . . . . . 14 4.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5 Incident reporting Forms . . . . . . . . . . . . . . . . . . . 15
4.6 Incident reporting Forms . . . . . . . . . . . . . . . . . . . 15 4.6 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7 Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Secondary Purposes of this Document 16 5 Secondary Purposes of this Document 15
6 Appendix A: Note on procedure definitions 16 6 Appendix A: Note on procedure definitions 16
7 Appendix B: Known Incident Response Teams 17 7 Appendix B: Known Incident Response Teams 17
8 Appendix C: Sample Incident Reporting Form 17 8 Appendix C: Example: a 'filled-in' template 17
9 Security Considerations 25 9 Security Considerations 25
10 Editor's Address 25 10 Author's Address 25
1 Introduction 1 Introduction
The GRIP Working Group was formed to produce guidelines and The GRIP Working Group was formed to produce guidelines and
recommendations to facilitate the consistent handling of security recommendations to facilitate the consistent handling of security
incidents in the Internet community. Although it is focused on the incidents in the Internet community. Although it is focused on the
Internet, many of the concepts discussed will also be useful for other Internet, many of the concepts discussed will also be useful for other
forms of local- and wide-area networks and internets. forms of local- and wide-area networks and internets.
Many computer security incidents either originate outside local Many computer security incidents orginate outside local community
community boundaries and affect other 'outside' sites, or originate boundaries and affect other 'outside' sites, and others orignate outside
outside the local community and affect hosts or users within it. The the local community and affect hosts or users within it. Often,
handling of security incidents will therefore often involve multiple therefore, the handling of security incidents will involve multiple
Security Incident Response Teams. Because of this characteristic it is Security Incident Response Teams. Because of this characteristic it is
important for every community to have a good security policy, and to important for every community to have a good security policy, and to
have a Security Incident Response Team (SIRT) in place to manage have a Security Incident Response Team (SIRT) in place to manage
communications across community boundaries in a consistent way. communications across community boundaries in a consistent way.
In the past there have been misunderstandings regarding expectations of In the past there have been misunderstandings regarding expectations of
response teams. The goal of this document is to provide a framework in response teams. The goal of this document is to provide a framework in
which to set expectations. By defining such a framework the community which to set expectations. By defining such a framework the community
can express areas and topics that need to addressed by any SIRT. can express areas and topics that need to addressed by any SIRT.
'Consistent handling' implies that any group calling itself a SIRT must 'Consistent handling' implies that any group calling itself a SIRT must
react to security incidents or to threats of them in ways which the react to security incidents or to threats of them in ways which the
Internet community agrees to be in its general interest. Every SIRT Internet community agrees to be in its general interest. Every SIRT
needs to define clearly the services they offer and the level at which needs to define clearly the services they offer and the level at which
they are offered to the client. Such definitions will be particularly they are offered to clients. Such definitions will be particularly
important in contracts and/or agreements which SIRTs make with their important in contracts and/or agreements which SIRTs make with their
clients. clients.
The "Expectations for Security Incident Response" document is seen as The "Expectations for Security Incident Response" is seen as resting on
resting on the work of individual SIRTs and the cooperation between the work of individual SIRTs and the cooperation between them. This
them. It recommends a 'template' through which every SIRT should document therefore recommends a 'template' through which every SIRT
describe itself and its functions. It further recommends that templates should describe itself and its functions. It further recommends that
should be accessible among teams, to make possible a fully effective templates should be accessible among teams, to make possible a fully
cooperative response framework for incidents or threats across the effective cooperative response framework for incidents or threats across
entire domain affected by them. the entire domain affected by them.
1.1 Definitions 1.1 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.
Constituency Constituency
skipping to change at page 4, line 22 skipping to change at page 4, line 29
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,
* compromise of integrity, * compromise of integrity,
* denial of service, * denial of service,
* misuse, * misuse,
* damage. * damage.
These are very general categories. For instance the forging of an These are very general categories. For instance the replacement of a
electronic mail message and a successful password attack are two system utility program by a Trojan Horse is an example of 'loss of
examples of 'compromise of integrity.' integrity,' and a successful password attack is an example of 'loss of
confidentiality.'
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.
Security Incident Response Team Security Incident Response Team
------------------------------- -------------------------------
Based on two of the definitions given above: Based on two of the definitions given above:
skipping to change at page 5, line 7 skipping to change at page 5, line 19
its defined constituency.' its defined constituency.'
In order to be considered a SIRT, a group must: In order to be considered a SIRT, a group must:
* provide a channel for receiving reports about suspected incidents, * provide a channel for receiving reports about suspected incidents,
* provide assistance to members of its constituency in handling these * provide assistance to members of its constituency in handling these
incidents, incidents,
* disseminate incident-related information to its constituency and to * disseminate incident-related information to its constituency and to
other related parties. other related parties.
Note that we are not referring here to police or other law enforcement
bodies which may investigate computer-related crime. SIRT members,
indeed, should not need to have any powers beyond those of ordinary
citizens.
Vendor Vendor
------ ------
A 'vendor' is any entity that produces networking or computing A 'vendor' is any entity that produces networking or computing
technology, and is responsible for the technical content of that technology, and is responsible for the technical content of that
technology. Examples of 'technology' include hardware (desktop technology. Examples of 'technology' include hardware (desktop
computers, routers, switches, etc.), and software (operating systems, computers, routers, switches, etc.), and software (operating systems,
mail forwarding systems, etc.). mail forwarding 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.
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 userss to execute operating system commands in program unintentionally allowed ordinary users to execute arbitrary
privileged mode, this "feature" would be a vulnerability. operating system commands in privileged mode, this "feature" would be a
vulnerability.
1.2 Publishing SIRT Templates 1.2 Publishing SIRT Templates
Every SIRT should publish information about its policies and services in Every SIRT should publish information about its policies and services in
the form of a completed template. The simplest way for a SIRT to make the form of a completed template. The simplest way for a SIRT to make
its template widely available is to publish it on its own information its template widely available is to publish it on its own information
server so that clients in its constituency can easily find it. server so that clients in its constituency can easily find it.
Templates published as pages in the World Wide Web should include the Templates published as pages in the World Wide Web should include the
phrase 'SIRT Template' in their title - this will allow Web search phrase 'SIRT Template' in their title - this will allow Web search
engines to find them easily. engines to find them easily.
skipping to change at page 6, line 11 skipping to change at page 6, line 27
template (verify that it was indeed published by the SIRT) and check template (verify that it was indeed published by the SIRT) and check
that it has not been modified (for example by verifying a digital that it has not been modified (for example by verifying a digital
signature for it). signature for it).
To facilitate interaction between SIRTs, it would be useful to have a To facilitate interaction between SIRTs, it would be useful to have a
central repository for them. The GRIP Working Group believe that some central repository for them. The GRIP Working Group believe that some
of the existing Internet archive areas could be used for this purpose. of the existing Internet archive areas could be used for this purpose.
The keeper of each template repository will be responsibly for verifying The keeper of each template repository will be responsibly for verifying
the identity of each SIRT lodging a template in the repository. the identity of each SIRT lodging a template in the repository.
1.3 Establishing Peering Between SIRTs 1.3 Relationships between SIRTs
In some cases a SIRT may be able to operate effectively on its own. It
is much more likely, however, that a SIRT will need to interact with
other SIRTs. Such interactions could include:
* Responding to requests for advice (e.g. "have you seen this
problem before?")
* Reporting of problems (for onward referal to other SIRTs, to service
providers or to vendors)
* Working co-operatively to resolve a security incident
Note that there is a difference between a peering agreement, where the
SIRTs involved agree to work together and share information, and simple
co-operation, where a SIRT (or any other client) simply contacts another
SIRT and asks for help or advice. Note also that any client wanting
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
need to decide what kinds of agreements can exist between themselves so
as to share yet safeguard information, whether this relationship can be
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 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 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 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?" 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 It is very easy to send forged e-mail, and not hard to establish a
(false) identity by telephone. PGP provides an effective way of (false) identity by telephone. PGP and PEM provide effective ways of
securing e-mail, but securing voice communications is much harder. At securing e-mail, but securing voice communications is much harder. At
present call-back is probably the only simple authentication method. present call-back is probably the only simple authentication method.
This may change as technologies such as scrambled telephones, or This may change as technologies such as scrambled telephones, or
PGP-phone on the Internet become available. PGP-phone on the Internet become available.
PGP relies on a 'web of trust,' built up by having known (and trusted) PGP relies on a 'web of trust,' built up by having known (and trusted)
people sign PGP keys. This model could also be used for SIRTs. To people sign PGP keys. This model could also be used for SIRTs. To
achieve this each SIRT should publish a list of the SIRTs they have achieve this each SIRT should publish a list of the SIRTs they have
peering arrangements (i.e. working relationships) with, including PGP peering arrangements (i.e. working relationships) with, including PGP
public keys for them. public keys for them and the expiry dates of those keys.
Note that there is a difference between a peering agreement, where the
SIRTs involved agree to work together and share information, and simple
co-operation, where SIRT B (or any other client) simply contacts SIRT A
and asks for help or advice. Note also that any client wanting direct
help in tracking an incident must be prepared to provide sufficient
information about the incident to make tracking possible.
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 The Template is summarized in the section immediately below, and the
remainder of the document describes its components. remainder of the document describes its components. A 'filled-in'
example of a template is given as Appendix C.
Contact Information 1. Contact Information
* name of the team ----------------------
* address 1.1 Name of the Team
* time zone 1.2 Address
* telephone number 1.3 Time Zone
* facsimile number 1.4 Telephone Number
* other telecommunication like STU-III, secure facsimile 1.5 Facsimile Number
* electronic mail address 1.6 Other Telecommunication (STU-III, secure facsimile...)
* encryption methods for communication: PGP, PEM, MOSS, .. 1.7 Electronic Mail Address
* PGP public key (if PGP used) 1.8 Public Keys and Other Encryption Information
1.9 Team Members
Template Updates 2. Template Updates
* date of last update -------------------
* locations where this template may be found 2.1 Date of Last Update
2.2 Locations where this Template May Be Found
Charter 3. Charter
* mission statement ----------
* constituency 3.1 Mission Statement
* sponsor / affiliation 3.2 Constituency
* authority 3.3 Sponsors and/or Affiliation
3.4 Authority
Policies 4. Policies
* types of incidents -----------
* level of support 4.1 Types of Incidents
* disclosure 4.2 Level of Support
- of compromised site's information 4.3 Disclosure of Information
- the compromise of SIRT site to constituency 4.4 Cooperation and Interaction with Other Entities
- incident reporting requirements 4.5 Communication and Authentication
* cooperation & interaction with 4.6 Points of Customer Contact
- incident response teams
- vendors
- investigative agencies
- involved sites
- press
* communication & authentication
* point of customer contacts
Services 5. Services
* incident response -----------
- verification 5.1 Incident Response
- understanding 5.2 Proactive Activities
- coping
- notification
* proactive activities
Incident Reporting Forms 6. Incident Reporting Forms
---------------------------
Disclaimers 7. Disclaimers
--------------
3 Purpose of the Template 3 Purpose of the Template
The Template which this document proposes is expected to be used by a The Template which this document proposes is expected to be used by a
response team to describe what it does, and in the process create response team to describe what it does, and in the process create
criteria against which its performance can be measured. The Template criteria against which its performance can be measured. The Template
does not attempt to specify a "correct" way for the team to operate, but does not attempt to specify a "correct" way for the team to operate, but
does recommend on specific policies and functions seen as necessary for does recommend on specific policies and functions seen as necessary for
such a team to play a consistent role with other SIRTs throughout the such a team to play a consistent role in the overall security framework.
networking community. It also comments on additional roles a team might It also comments on additional roles a team might include in the ambit
include in the ambit of its operations. of its operations.
The primary purposes of the Template are: The primary purposes of the Template are:
- to help SIRTs improve the way they operate; - to help SIRTs improve the way they operate;
- to improve interactions between different SIRTs, and between SIRTs - to improve interactions between different SIRTs, and between SIRTs
and other organizations such as vendors and law-enforcement and other organizations such as vendors and law-enforcement
agencies; agencies;
- to note necessary interactions with their constituencies in setting - to note necessary interactions with their constituencies in setting
skipping to change at page 9, line 38 skipping to change at page 10, line 17
http://hightop.nrl.navy.mil/news/incident.html 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 The Security Incident Response Team Template 4 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.
4.1 Contact Information 4.1 Template Updates
Full details of how to contact the SIRT should be listed here.
4.2 Template Updates
Details of a Security IRT change with time, so the template must Details of a Securty IRT change with time, so the template must indicate
indicate when it was last changed, who will be informed of future when it was last changed, who will be informed of future changes, and
changes, and (by implication) who will not. Without this, it is (by implication) who will not. Without this, it is inevitable that
inevitable that misunderstandings and misconceptions will arise over misunderstandings and misconceptions will arise over time.
time.
4.2.1 Date of last update 4.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.
4.2.2 Distribution list for Template Updates 4.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 any other changed. The list might normally cover the constituency and any other
groups the SIRT has frequent interactions with. Readers not on the list groups the SIRT has frequent interactions with. Readers not on the list
can then recognise that they should check the central repository (above) can then recognise that they should check the central repository (above)
for possible updates. for possible updates.
Digital signatures should be used for update messages sent by a SIRT to Digital signatures should be used for update messages sent by a SIRT to
those on its distribution list. those on its distribution list.
4.3 Charter 4.2 Charter
Every SIRT must have a charter which specifying 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 at
least the following: least the following:
* mission statement * mission statement
* constituency * constituency
* sponsor / affiliation * sponsor / affiliation
* authority * authority
4.3.1 Mission Statement 4.2.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 a
Security Incident Response Team, the team MUST provide incident Security Incident Response Team, the team MUST provide incident
response, as defined in section 1.1. response, by definition.
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, succinct definition.
4.3.2 Constituency 4.2.2 Constituency
A SIRT's constituency (as defined above) can be determined in many ways. A SIRT's constituency (as defined above) can be determined in many ways.
For example it could be a company's employees or its paid subscribers, For example it could be a company's employees or its paid subscribers,
or it could be defined in terms of a technological focus, such as the or it could be defined in terms of a technological focus, such as the
users of a particular operating system. users of a 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 (below)
should explain how requests from outside the perimeter will be handled. should explain how requests from outside the perimeter will be handled.
Constituencies might overlap, as when an ISP supports a SIRT, but Constituencies might overlap, as when an ISP supports 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 (below) should make such relationships clear.
People within the constituency have to learn that there is a Security People within the constituency have to learn that there is a Security
IRT for their purposes; the building of a trusted relationship with the IRT for their purposes; the building of a trusted relationship with the
constituency is an on-going process which never ends. constituency is an on-going process which never ends.
4.3.3 Sponsoring organisation / affiliation 4.2.3 Sponsoring organization / affiliation
Any sponsoring organisations or affiliations, if they exist, must be The sponsoring organization, which authorises the actions of the SIRT,
disclosed to constituents. For example, the CERT Coordination Centre's should be given next. Defining the affiliation amounts to stating:
sponsoring organisation is the Software Engineering Institute, Carnegie "Who is your God?".
Mellon University; the sponsoring organisation for a SIRT within a large
coprporation would be the corporation itself. SIRTs within smaller
organisations may have no sponsoring organisation, in which case they
should specify 'none.'
4.3.4 Authority 4.2.4 Authority
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 perimeters. Each should identify the scope of its systems within their perimeter. They should identify the scope of their
control as distinct from the perimeter of its constituency; if other control as distinct from the perimeter of their constituency; if other
SIRTs operate hierachically within this perimeter, they should be SIRTs operate hierachically within their perimeter, these should be
identified. identified.
For example, a corporate SIRT may have authority to force the 4.3 Policies
installation of software patches as the result of an incident. Other
SIRTs, such as a national SIRT, may only be able to advise that such
patches should be installed.
4.4 Policies
4.4.1 Types of incidents and level of support 4.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 which the team will contribute when assisting with each
incident should be summarized here in list form. The Services section type of incident should be summarized here in list form. The Services
(later) provides opportunity for more detailed definition. section (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 a SIRT. service requirement for a SIRT.
4.4.2 Co-operation and interaction with other organizations 4.3.2 Co-operation and interaction with other organizations
This section should make explicit the related groups with which the SIRT This section should make explicit the related groups with which the SIRT
routinely interacts. Examples of these are listed below. routinely interacts. Examples of these are listed below.
Incident Response Teams: A SIRT will often need to interact with Incident Response Teams: A SIRT will often need to interact with
other SIRTs. For example a SIRT within a large company may need to 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 a national SIRT, and a national SIRT may need to
report incidents to national SIRTs in other countries. report incidents to national SIRTs in other countries.
Vendors: The interaction here is in reporting vulnerabilities Vendors: Larger vendors have their own SIRTs, but smaller vendors
discovered during an incident. If your SIRT has relationships with may not. In such cases a SIRT will need to work directly with a vendor.
product vendors, these should be described here. Larger vendors have
their own SIRTs, but smaller vendors may not. In such cases a SIRT will
need to work directly with a vendor.
Law-enforcement agencies: These include the police and other Law-enforcement agencies: These include the police and other
investigative agencies. SIRTs and users of the template should be investigative agencies. SIRTs and users of the template should be
sensitive to local laws and regulations, which may vary considerably in sensitive to local laws and regulations, which may vary considerably in
different countries. different countries.
Press: A SIRT may be approached by the Press for information and Press: A SIRT may be approached by the Press for information and
comment from time to time. This is discussed in more detail below comment from time to time. This is discussed in more detail immediately
(Reporting and Disclosure). below.
4.4.3 Reporting and Disclosure 4.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 under what information it will report or disclose, to whom, and when.
circumstances.
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. In addition, they mave have reporting requirements jurisdictions. Each team's template should specify any such restraints,
imposed by their sponsoring organisation, or they may be required by law both to clarify clients' expectations and to inform other teams.
to report certain kinds of security incident. Each team's template
should specify any such restraints and requirements, both to clarify
clients' expectations and to inform other teams. As an example of such
restraints, the Dutch equivalent of the U.S. Federal Bureau of
Investigation (FBI) has some kinds of documents which may NOT be
recorded electronically.
Conflicts of interest, particularly in commercial matters, may also Conflicts of interest, particularly in commercial matters, may also
restrain disclosure by a team; this document does not recommend on how restrain disclosure by a team; the present Draft does not recommend on
such conflicts should be addressed. how such conflicts should be addressed.
An explicit policy concerning disclosure to the Press can be helpful, An explicit policy concerning disclosure to the Press can be helpful,
particularly in clarifying the expectations of a SIRT's constituency. particularly in clarifying the expectations of a SIRT's constituency.
'Disclosure' includes: 'Disclosure' includes:
- reporting incidents within the constituency to other teams; - reporting incidents within the constituency to other teams;
- handling incidents occurring within the constituency, but reported - handling incidents occurring within the constituency, but reported
from outside it. from outside it.
skipping to change at page 14, line 15 skipping to change at page 14, line 16
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 reports 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 Security IRT
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 they are distributed, the
template's reporting and disclosure policy should say so, and should template's reporting and disclosure policy should say so, and should
list the recipients. list the recipients.
4.4.4 Communication and authentication 4.3.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 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 SIRT have, as a minimum, a At the moment it is recommended that every SIRT have, as a minimum, a
PGP key available, since PGP is available world-wide. Teams may also PGP key available, since PGP is available world-wide. Teams may also
make other mechanisms available, for example PEM. make other mechanisms available, for example PEM.
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.5 Services 4.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 the incident, i.e. help in determining whether + verification of incident
the problem really is caused by a security compromise + technical assistance and analysis to understand
+ technical analysis assistance to understand the nature of the the compromise of a system
compromise
+ notification of other involved parties + notification of other involved parties
+ guidance with eradication of the incident, i.e. steps + eradication
to eliminate the compromise and prevent it recurring + recovery
+ guidance in recovery from the incident
* optional * optional
+ vulnerability analysis outside of direct incident activity
+ information provision + information provision
- maintaining a vulnerability archive - vulnerability archive
- developing and supplying patches and resolutions - patches and resolutions
+ tool development and distribution + tools
+ education + education
+ audit and consulting + audit and consulting
+ product evaluation + product evaluation
Security Incident response Teams may provide different kinds of services 4.5 Incident reporting Forms
to different sub-constituencies; this needs to be spelled out. For
example, 'we are willing to provide direct incident response to other
communities as follows ..'
4.6 Incident reporting Forms
Samples of reporting forms used by the SIRT (or pointers to them) should Samples of reporting forms used by the SIRT (or pointers to them) should
be included at this point in a template. As an example, the CERT be included at this point in a template.
Coordination Centre's incident reporting form is attached as Appendix C.
4.7 Disclaimers 4.6 Disclaimers
Although the template does not constitute a contract, liability might Although the template 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 recommended.
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 imply liability, and SIRTs
should consider the inclusion of disclaimers in such material. 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 template must be
skipping to change at page 16, line 16 skipping to change at page 16, line 4
The primary audience of this document are the administrators responsible The primary audience of this document are the administrators responsible
for communities of users, i.e. 'constituencies.' This section provides for communities of users, i.e. 'constituencies.' This section provides
some brief notes on what SIRT clients should expect of their teams. some brief notes on what SIRT clients should expect of their teams.
An incident response team exists primarily to support the clients in its An incident response team exists primarily to support the clients in its
constituency. It is vital that those clients understand what they constituency. It is vital that those clients understand what they
should expect of their team. Provided that a SIRT has published its should expect of their team. Provided that a SIRT has published its
template, a constituent/client should be able to read the template and template, a constituent/client should be able to read the template and
discover what to expect, for example in such areas as privacy and discover what to expect, for example in such areas as privacy and
confidentiality of information, and whether the response team will be confidentiality of information, and whether the response team will be
contacting downstream sites. Clients should certainly expect a SIRT to contacting downstream sites. Clients should certainly expect a SIRT to
provide the services they detail in their template. provide the services they detail in their template.
An important aspect of incident response is the 'follow through' - every An important aspect of incident response is the 'follow through' - every
incident should be investigated and appropriate actions taken. Clients incident should be investigated and appropriate actions taken. Clients
should be encouraged by their SIRT to report incidents so they can be should be encouraged by their SIRT to report incidents so that they can
acted upon. It must be emphasised that without active participation be acted upon. It must be emphasised that without active participation
(especially reporting) from clients the effectiveness of the services (especially reporting) from clients the effectiveness of the services
they depend on can be greatly diminished. As a minimum, clients need to 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 know that they should report security incidents, and know how and where
they should report them. they should report them.
Individual users (i.e. those who are not part of an organisation which Individual users (i.e. those who are not part of an organisation which
provides a SIRT for its members) who observe a security incident should provides a SIRT for its members) who observe a security incident should
ask their Internet Service Provider for details of the most suitable ask their Internet Service Provider for details of the most suitable
SIRT to report it to. SIRT to report it to.
skipping to change at page 17, line 32 skipping to change at page 17, line 22
7 Appendix B: Known Incident Response Teams 7 Appendix B: Known Incident Response Teams
FIRST is the Forum of Incident Response and Security Teams. Information FIRST is the Forum of Incident Response and Security Teams. Information
about FIRST can be found via their World Wide Web home page: about FIRST can be found via their World Wide Web home page:
http://www.first.org/first http://www.first.org/first
This page contains pointers to 'Team Contact Information' for SIRTs who This page contains pointers to 'Team Contact Information' for SIRTs who
are FIRST members, and to 'Teams with WWW Servers.' are FIRST members, and to 'Teams with WWW Servers.'
8 Appendix C: Sample Incident Reporting Form 8 Appendix C: Example: a 'filled-in' template
The following is the form which clients should use to report incidents
to the CERT Co-ordination Centre:
version 3.0
February 28, 1996
CERT(sm) Coordination Center
Incident Reporting Form
The CERT Coordination Center (CERT/CC) has developed the following
form in an effort to gather incident information. We would appreciate
your completing the form below in as much detail as possible. The
information is optional, but from our experience we have found that
having the answers to all the questions enables us to provide the best
assistance. Completing the form also helps avoid delays while we get
back to you requesting the information we need in order to help you.
Sites have told us, as well, that filling out the form has helped them
work through the incident.
Note that our policy is to keep any information specific to your site
confidential unless we receive your permission to release that
information.
Please feel free to duplicate any section as required. Please return
this form to cert@cert.org. If you are unable to email this form,
please send it by FAX. The CERT/CC FAX number is
+1 412 268 6989
Thank you for your cooperation and help.
............................................................................
1.0. General Information
1.1. Incident number (to be assigned by the CERT/CC): CERT#
1.2. Reporting site information
1.2.1. Name (e.g., CERT Coordination Center):
1.2.2. Domain Name (e.g., cert.org):
1.2.3. Brief description of the organization:
1.2.4. Is your site an Internet Service Provider (Yes/No):
2.0. Contact Information
2.1. Your contact information
2.1.1. Name:
2.1.2. Email address:
2.1.3. Telephone number:
2.1.4. FAX number:
2.1.5. Pager number:
2.1.6. Home telephone number (for CERT/CC internal use
only):
2.1.7. Secure communication channel (e.g., PGP, PEM, DES,
secure telephone/FAX) [NOTE -- we will call to
obtain the secure communication channel
information] (Yes/No):
2.2. Additional contact information (if available)
2.2.1. Name:
2.2.2. Email address:
2.2.3. Telephone number:
2.2.4. FAX number:
2.2.5. Pager number:
2.2.6. Home telephone number (for CERT/CC internal use
only):
2.2.7. Secure communication channel (Yes/No):
2.3. Site security contact information (if applicable)
2.3.1. Name:
2.3.2. Email address:
2.3.3. Telephone number:
2.3.4. FAX number:
2.3.5. Pager number:
2.3.6. Home telephone number (for our internal use only):
2.3.7. Secure communication channel (Yes/No):
2.4. Contact information for other site(s) involved in this
incident (if available)
2.4.1. Site name:
2.4.2. Contact person name:
2.4.3. Email address:
2.4.4. Telephone number:
2.4.5. FAX number:
2.4.6. Pager number:
2.4.7. Home telephone number (for CERT/CC internal use
only):
2.4.8. Secure communication channel (Yes/No):
2.5. Contact information for any other incident response team(s)
(IRTs) that has/have been notified (if available)
2.5.1. IRT name:
2.5.2. Constituency domain:
2.5.3. Contact person name:
2.5.4. Email address:
2.5.5. Telephone number:
2.5.6. FAX number:
2.5.7. Pager number:
2.5.8. Home telephone number (for CERT/CC internal use
only):
2.5.9. Secure communication channel (Yes/No):
2.5.10. IRT reference number:
2.6. Contact information for any law enforcement agency(ies) that
has/have been notified (if available)
2.6.1. Law enforcement agency name:
2.6.2. Contact person name:
2.6.3. Email address:
2.6.4. Telephone number:
2.6.5. FAX number:
2.6.6. Pager number:
2.6.7. Home telephone number (for CERT/CC internal use
only):
2.6.8. Secure communication channel (Yes/No):
2.6.9. Law enforcement agency reference number:
3.0. Contacting Sites Involved
3.1. We ask that reporting sites contact other sites involved in
incident activity. Please let us know if you need assistance
in obtaining contact information for the site(s) involved.
When contacting the other sites, we would very much
appreciate a cc to the "cert@cert.org" alias. This helps
us identify connections between incidents and understand
the scope of intruder activity. We would also appreciate
your including our incident number in the subject line of
any correspondence relating to this incident if one
has been assigned (see item 1.1.).
If you are unable to contact the involved sites, please get
in touch with us to discuss how we can assist you.
3.2. Disclosure information -- may we give the following types of
information to
3.2.1. the sites involved in this incident
3.2.1.1. your domain (Yes/No):
3.2.1.2. your host(s) involved (Yes/No):
3.2.1.3. your contact information (Yes/No):
3.2.2. incident response teams, for sites from their
constituencies involved in this incident
3.2.2.1. your domain (Yes/No): <HTML>
3.2.2.2. your host(s) involved (Yes/No): <HEAD>
3.2.2.3. your contact information (Yes/No): <TITLE>SIRT Template for XYZ SIRT</TITLE>
</HEAD>
3.2.3. law enforcement agency(ies) if there is a legal <P>
investigation Note: no digital signature is currently available for this SIRT
3.2.3.1. your domain (Yes/No): Template. We'll put one up as soon as the technology is adopted
3.2.3.2. your host(s) involved (Yes/No): by XYZ Enterprises.
3.2.3.3. your contact information (Yes/No): <P>
4.0. Host Information <XMP>
4.1. Host(s) involved at your site. Please provide information 1. Contact Information
on all host(s) involved in this incident at the time of the ----------------------
incident (one entry per host please)
4.1.1. Hostname: 1.1 Name of the Team
4.1.2. IP address(es): "XYZ-SIRT": the XYZ Computer Emergency Response Team.
4.1.3. Vendor hardware, OS, and version:
4.1.4. Security patches applied/installed as currently
recommended by the vendor and the CERT/CC
(Yes/No/Unknown):
4.1.5. Function(s) of the involved host
4.1.5.1. Router (Yes/No): 1.2 Address
4.1.5.2. Terminal server (Yes/No): XYZ SIRT
4.1.5.3. Other (e.g. mail hub, information server, XYZ Enterprises
DNS [external or internal], etc.):
4.1.6. Where on the network is the involved host (e.g. >> Private Bag 12-345
backbone, subnet): >> MyTown
4.1.7. Nature of the information at risk on the involved >> MyCountry
host (e.g. router configuration, proprietary,
personnel, financial, etc.):
4.1.8. Timezone of the involved host (relative to GMT):
4.1.9. In the attack, was the host the source, the victim,
or both:
4.1.10. Was this host compromised as a result of this attack
(Yes/No):
4.2. Host(s) involved at other other sites (one entry per host 1.3 Time Zone
please) >> MyCountry/Eastern (GMT-0500, and GMT-0400 from April to October)
4.2.1. Hostname: 1.4 Telephone Number
4.2.2. IP address(es): +1 234 567 7890 (ask for the XYZ-SIRT)
4.2.3. Vendor hardware, OS, and version:
4.2.4. Has the site been notified (Yes/No):
4.2.5. In the attack, was the host the source, the victim, or
both:
4.2.6. Was this host compromised as a result of this attack
(Yes/No):
5.0. Incident Categories 1.5 Facsimile Number
+1 234 567 7654 (this is *not* a secure fax)
5.1. Please mark as many categories as are appropriate to 1.6 Other Telecommunication
this incident None available.
5.1.1. Probe(s): 1.7 Electronic Mail Address
5.1.2. Scan(s): >> <xyz-sirt@sirt.xyz.org>
5.1.3. Prank:
5.1.4. Scam:
5.1.5. Email Spoofing:
5.1.6. Email bombardment:
5.1.6.1. was this denial-of-service attack successful 1.8 Public Keys and Other Encryption Information
(Yes/No): Encryption is not currently available, but we plan to install
PGP as soon as possible. Our PGP public key will appear here
as soon as it is available.
5.1.7. Sendmail attack: 1.9 Team Members
>> Jane Doe of Computing Services is the XYZ-SIRT
coordinator. Other team members will be listed here once
their participation is confirmed.
5.1.7.1. did this attack result in a compromise 2. Template Updates
(Yes/No): -------------------
5.1.8. Break-in 2.1 Date of Last Update
Please see the bottom of this Web page for this information.
5.1.8.1. Intruder gained root access (Yes/No): 2.2 Locations where this Template May Be Found
5.1.8.2. Intruder installed Trojan horse program(s) This template is available from the XYZ SIRT WWW
(Yes/No): site; its URL is
5.1.8.3. Intruder installed packet sniffer (Yes/No): http://www.xyz.org/THIS-INFORMATION-NOT-YET-AVAILABLE
>> The template will be signed with the XYZ-SIRT's private PGP
>> key. (WHAT TO DO? Sign just the template? The whole Web
>> page? Try ASCII armor? Or have the signature separate?)
5.1.8.3.1. What was the full pathname(s) of There are no plans for the automatic distribution of fresh
the sniffer output file(s): copies of this template after updates; please make sure that
5.1.8.3.2. How many sessions did the sniffer you are using the latest version by checking our Web site.
log (use "grep -c 'DATA'
<filename>" to obtain this
information):
5.1.8.4. NIS (yellow pages) attack (Yes/No): 3. Charter
5.1.8.5. NFS attack (Yes/No): ----------
5.1.8.6. TFTP attack (Yes/No): 3.1 Mission Statement
5.1.8.7. FTP attack (Yes/No): The purpose of the XYZ-SIRT is, first, to assist members of
5.1.8.8. Telnet attack (Yes/No): XYZ community in implementing proactive measures to reduce
5.1.8.9. Rlogin or rsh attack (Yes/No): the risks of computer security incidents, and second, to
5.1.8.10. Cracked password (Yes/No): assist XYZ community in responding to such incidents when
5.1.8.11. Easily-guessable password (Yes/No): they occur.
5.1.9. Anonymous FTP abuse (Yes/No): 3.2 Constituency
5.1.10. IP spoofing (Yes/No): The XYZ-SIRT's contituency is the XYZ SIRT community,
5.1.11. Product vulnerability (Yes/No): as defined in the context of the "XYZ Policy on Computing
Facilities".
5.1.11.1. Vulnerability exploited: 3.3 Sponsors and/or Affiliation
None.
5.1.12. Configuration error (Yes/No): 3.4 Authority
The XYZ-SIRT operates under the auspices of, and with
authority delegated by, the Department of Computing Services
of XYZ Enterprises. The Department in turn receives its
authority from the formal ruling bodies of XYZ, as
set out in the "Policy on Computing Facilities". The XYZ-SIRT
has no direct authority over systems at XYZ Enterprises
at large. However, it benefits from the direct authority of
Computing Services with respect to systems managed by this
Department. Also, because Computing Services manages the
XYZ Enterprises Network, and is responsible for connectivity
to it, the Department has indirect authority over systems
in other departments, inasmuch as the Department can order
such systems to be disconnected from the network should
circumstances warrant it.
5.1.12.1. Type of configuration error: The XYZ-SIRT expects to work cooperatively with system
administrators and users at XYZ, and, insofar as
possible, to avoid authoritarian relationships. However,
should circumstances warrant it, the XYZ-SIRT will appeal to
Computing Services to exert its authority, direct or indirect,
as necessary.
5.1.13. Misuse of host(s) resources (Yes/No): 4. Policies
-----------
5.1.14. Worm (Yes/No): 4.1 Types of Incidents
5.1.15. Virus (Yes/No): The XYZ-SIRT is authorized to address all types of computer
5.1.16. Other (please specify): security incidents which occur, or risk occurring, at
XYZ Enterprises.
6.0. Security Tools 4.2 Level of Support
The level of support given by XYZ-SIRT will vary depending on
the type and severity of the incident or issue, the type of
consituent, the size of the user community affected, and the
XYZ-SIRT's resources at the time.
6.1. At the time of the incident, were you any using the following No direct support will be given to end users; they are
security tools (Yes/No; How often) expected to contact their system administrator, network
administrator, or department head for assistance. The
XYZ-SIRT will support the latter people.
Network Monitoring tools While the XYZ-SIRT understands that there exists great
6.1.1. Argus: variation in the level of system administrator expertise at
6.1.2. netlog (part of the TAMU Security Package): XYZ, and while the XYZ-SIRT will endeavour to present
information and assistance at a level appropriate to
each person, the XYZ-SIRT cannot train system administrators,
and it cannot perform system maintenance on their behalf.
In most cases, the XYZ-SIRT will provide pointers to the
information needed to implement appropriate measures.
Authentication/Password tools 4.3 Disclosure of Information
6.1.3. Crack: >> &&&&&&&&&&&&&&&&&&&&
6.1.4. One-time passwords: >> Difficult section; not done yet. Also, it overlaps heavily
6.1.5. Proactive password checkers: >> with the section below; I'm not sure of the best way to
6.1.6. Shadow passwords: >> separate them. Questions not yet addressed:
6.1.7. Kerberos: - 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
Service filtering tools 4.4 Cooperation and Interaction with Other Entities
6.1.8. Host access control via modified daemons or - Other sites:
wrappers: The XYZ-SIRT will cooperate with other SIRTs (security
6.1.9. Drawbridge (part of the TAMU Security Package): incident response teams) and with system administrators at
6.1.10. Firewall (what product): other sites, to the extent that their bona fide can be
6.1.11. TCP access control using packet filtering: verified. Should provincial or national SIRTs be
constituted, XYZ-SIRT will explore the possibility of peer
relationships with them. The possibility of peer
relationships with close neighbours will also be explored;
unofficial cooperative climates already exist between XYZ
and several nearby universities and large corporations.
While there are no legal requirements that XYZ-SIRT provide
eny information to any body outside XYZ (aside from
law enforcement agencies), XYZ-SIRT will provide such
information when the good of the community justifies it.
However, unless identifying information is needed to track
an incident in progress, such information will be stripped
from the report (unless the affected department gives its
permission that the real information be used).
- Vendors:
The XYZ-SIRT wishes to encourage vendors of all kinds of
networking and computer equipment, software, and services
to improve the security of their products. In aid of
this, a vulnerability discovered in such a product will be
reported to its vendor, along with all technical details
needed to identify and fix the problem. Identifying
details will not be given to the vendor without the
permission of the affected parties.
- Law enforcement:
>> XYZ has its own Security Department. ( I NEED TO LOOK UP
>> THE RELATIONSHIP BETWEEN COMPUTING SERVICES, XYZ
>> SECURITY, AND OUTSIDE POLICE FORCES. ) Informal working
relationships already exist between some system
administrators at XYZ and the local police; interest
has been expressed by all parties in formalising these
relationships. Any progress
made in that area will be reflected in this section.
In the meantime, authorized and unauthorized users of the
XYZ Computing Facilities should be aware that the
XYZ-SIRT will cooperate fully with law enforcement
agencies in detecting, reporting, documenting, and
prosecuting violations of the law; users concerned about
confidentiality are referred to the XYZ "Policy on
Computing Facilities".
- The Press:
The XYZ-SIRT will not interect directly with the Press.
If necessary, information will be provided to the
XYZ Public Relations Department, and to the
Customer Relations group of the Computing Services
Department. All queries will be referred to these two
bodies.
- The XYZ SIRT community:
Details of incidents may be released to Computing Services
management, XYZ management, or the Computer
Resources Committee; these bodies will be charged with
maintaining the confidentiality of the information. General
report of incidents, summaries of multiple incidents, and
statistics may be made available to the general XYZ
community, with identifying information stripped (except
where permission has been obtained from the affected
parties). There is no obligation on the part of the
XYZ-SIRT to report incidents to the community, though it
may choose to do so; in particular, it is likely that the
XYZ-SIRT will inform all affected parties of the ways in
which they were affected.
- The public at large:
In general, no particular efforts will be made to
communicate with the public at large, though the XYZ-SIRT
recognizes that, for all intents and purposes, information
made available to the XYZ community is in effect
made available to the community at large, and will tailor
the information in consequence.
- The computer security community:
While members of XYZ-SIRT may participate in discussions
within the computer security community, such as newsgroups,
mailing lists (including the full-disclosure list
"bugtraq"), and conferences, they will treat such forums
as though they were the public at large. While technical
issues (including vulnerabilities) may be discussed to any
level of detail, any examples taken from XYZ-SIRT
experience will be disguised to avoid identifying the
affected parties.
Tools to scan hosts for known vulnerabilities In the paragraphs above, the "affected parties" refers to the
6.1.12. ISS: legitimate owners, operators, and users of the relevant
6.1.13. SATAN: computing facilities. It does not refer to unauthorized
users, including otherwise authorized users making
unauthorized usage of a facility; such intruders may have no
expectation of confidentiality from the XYZ-SIRT. They may or
may not have legal rights to confidentiality; such rights will
of course be respected where they exist.
Multi-purpose tools 4.5 Communication and Authentication
6.1.14. C2 security: In view of the types of information that the XYZ-SIRT will
6.1.15. COPS: likely be dealing with, telephones will be considered
6.1.16. Tiger (part of the TAMU Security Package): sufficiently secure to be used even unencrypted. Unencrypted
e-mail will not be considered particularly secure, but will be
sufficient for the transmission of low-sensitivity data. If
it is necessary to send highly sensitive data by e-mail, PGP
will be used. Network file transfers will be considered to
be similar to e-mail for these purposes.
File Integrity Checking tools Where it is necessary to establish trust, for example before
6.1.17. MD5: relying on information given to the XYZ-SIRT, or before
6.1.18. Tripwire: disclosing confidential information, the identity and bona
fide of the other party will be ascertained to a reasonable
degree of trust. Within XYZ, and with known
neighbour sites, referrals from known trusted people will
suffice to identify someone. Otherwise, appropriate methods
will be used, such as a search of FIRST members, the use of
WHOIS and other Internet registration information, etc, along
with telephone call-back or e-mail mail-back to ensure that
the party is not an impostor. Incoming e-mail whose data must
be trusted will be checked with the originator personally, or
by means of digital signatures.
Other tools 4.6 Points of Customer Contact
6.1.19. lsof: The preferred method for contacting the XYZ-SIRT will be
6.1.20. cpm: e-mail. If this is not possible, or not advisable for
6.1.21. smrsh: security reasons, the XYZ-SIRT can be reached by telephone
6.1.22. append-only file systems: during regular office hours.
Additional tools (please specify): 5. Services
-----------
6.2. At the time of the incident, which of the following logs were 5.1 Incident Response
you using, if any (Yes/No) >> &&&&&&&&&&&&&&&&&&&&&&&7
6.2.1. syslog: >> This section requires a lot of thought.
6.2.2. utmp:
6.2.3. wtmp:
6.2.4. TCP wrapper:
6.2.5. process accounting:
6.3. What do you believe to be the reliability and integrity of 5.2 Proactive Activities
these logs (e.g., are the logs stored offline or on a The XYZ-SIRT will coordinate and maintain the following
different host): services to the extent possible depending on its resources:
- Information services
- List of departmental security contacts, administrative
and technical.
- Mailing lists to inform security contacts of new
information relevant to their computing environments.
- Repository of vendor-provided and other security-related
patches for various operating systems.
- Repository of security tools for use by sysadmins.
- "Clipping" service for various existing resources, such
as major mailing lists and newsgroups; important issues
of relevance to operating environments in use at the
XYZ will be reported and archived.
- Auditing services
- Central file integrity checking service for Unix
machines.
- "Tiger teams".
- Security level assignments; machines at XYZ
will be audited and assigned a security level: not all
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
- Central logging services for Unix machines.
- Records of security incidents handled.
7.0. Detailed description of the incident 6. Incident Reporting Forms
---------------------------
7.1. Please complete in as much detail as possible >> &&&&&&&& Not done yet; I'll probably use an existing
>> one from somewhere initially.
7.1.1. Date and duration of incident: 7. Disclaimers
7.1.2. How you discovered the incident: --------------
7.1.3. Method used to gain access to the affected host(s):
7.1.4. Details of vulnerabilities exploited that are
not addressed in previous sections:
7.1.5. Other aspects of the "attack":
7.1.6. Hidden files/directories:
7.1.7. The source of the attack (if known):
7.1.8. Steps taken to address the incident (e.g., binaries
reinstalled, patches applied):
7.1.9. Planned steps to address the incident (if any):
7.1.10. Do you plan to start using any of the tools listed
above in question 6.0 (please list tools expected
to use):
7.1.11. Other:
7.2. Please append any log information or directory listings and >> -- resp. for technical disclosures (bugtraq) etc.?
timezone information (relative to GMT). >> -- resp. for results for XYZ-SIRT advice?
>> &&&&&&&&&&&&&&&&&&&7
>> WILL NEED XYZ LEGAL COUNSEL ON THIS?
7.3. Please indicate if any of the following were left on your 8. Additional Information
system by the intruder (Yes/No): -------------------------
7.3.1. intruder tool output (such as packet sniffer output The version of this template published in this RFC will undoubtedly be
logs): out of date by the time you see it; it is intended as an example only.
7.3.2. tools/scripts to exploit vulnerabilities: Please pick up a fresh copy from our Web site if you actually need
7.3.3. source code programs (such as Trojan horse programs, information about XYZ-SIRT.
sniffer programs):
7.3.4. binary code programs (such as Trojan horse programs,
sniffer programs):
7.3.5. other files:
If you answered yes to any of the last 5 questions, please History of this template:
call the CERT/CC hotline (+1 412 268 7090) for instructions
on uploading files to us by FTP. Thanks.
7.4. What assistance would you like from the CERT/CC? 1996/07/29 Jane Doe, version 1.0
THIS VERSION HAS ABSOLUTELY NO MANAGEMENT APPROVAL!
Copyright 1996 Carnegie Mellon University. </XMP>
This form may be reproduced and distributed without permission
provided it is used for noncommercial purposes and the CERT
Coordination Center is acknowledged.
CERT is a service mark of Carnegie Mellon University. </BODY>
</HTML>
9 Security Considerations 9 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 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. They
must also secure their own systems and infrastructure. must also secure their own systems and infrastructure.
10 Editor's Address 10 Author's Address
Nevil Brownlee Nevil Brownlee
ITSS Technology Developmenta 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
 End of changes. 112 change blocks. 
509 lines changed or deleted 519 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/