分享
 
 
 

RFC2350 - Expectations for Computer Security Incident Response

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group N. Brownlee

Request for Comments: 2350 The University of AUCkland

BCP: 21 E. Guttman

Category: Best Current Practice Sun Microsystems

June 1998

EXPectations for Computer Security Incident Response

Status of this Memo

This document specifies an Internet Best Current Practices for the

Internet Community, and requests discussion and suggestions for

improvements. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

The purpose of this document is to express the general Internet

community's expectations of Computer Security Incident Response Teams

(CSIRTs). It is not possible to define a set of requirements that

would be appropriate for all teams, but it is possible and helpful to

list and describe the general set of topics and issues which are of

concern and interest to constituent communities.

CSIRT constituents have a legitimate need and right to fully

understand the policies and procedures of 'their' Computer Security

Incident Response Team. One way to support this understanding is to

supply detailed information which users may consider, in the form of

a formal template completed by the CSIRT. An outline of such a

template and a filled in example are provided.

Table of Contents

1 Introduction ....................................................2

2 Scope............................................................4

2.1 Publishing CSIRT Policies and Procedures ....................4

2.2 Relationships between different CSIRTs ......................5

2.3 Establishing Secure Communications ..........................6

3 Information, Policies and Procedures.............................7

3.1 OBTaining the Document.......................................8

3.2 Contact Information .........................................9

3.3 Charter ....................................................10

3.3.1 Mission Statement.....................................10

3.3.2 Constituency..........................................10

3.3.3 Sponsoring Organization / Affiliation.................11

3.3.4 Authority.............................................11

3.4 Policies ...................................................11

3.4.1 Types of Incidents and Level of Support...............11

3.4.2 Co-operation, Interaction and Disclosure of

Information...........................................12

3.4.3 Communication and Authentication......................14

3.5 Services ...................................................15

3.5.1 Incident Response ....................................15

3.5.1.1 Incident Triage ..............................15

3.5.1.2 Incident Coordination ........................15

3.5.1.3 Incident Resolution...........................16

3.5.2 Proactive Activities .................................16

3.6 Incident Reporting Forms ...................................16

3.7 Disclaimers ................................................17

Appendix A: Glossary of Terms ....................................18

Appendix B: Related Material .....................................20

Appendix C: Known Computer Security Incident Response Teams ......21

Appendix D: Outline for CSIRT Template ...........................22

Appendix E: Example - 'filled-in' Template for a CSIRT ...........23

4 Acknowlegements ................................................36

5 References .....................................................36

6 Security Considerations ........................................36

7 Authors' Addresses .............................................37

8 Full Copyright Statement .......................................38

1 Introduction

The GRIP Working Group was formed to create a document that describes

the community's expectations of computer security incident response

teams (CSIRTs). Although the need for such a document originated in

the general Internet community, the expectations expressed should

also closely match those of more restricted communities.

In the past there have been misunderstandings regarding what to

expect from CSIRTs. The goal of this document is to provide a

framework for presenting the important subjects (related to incident

response) that are of concern to the community.

Before continuing, it is important to clearly understand what is

meant by the term "Computer Security Incident Response Team." For

the purposes of this document, a CSIRT is a team that performs,

coordinates, and supports the response to security incidents that

involve sites within a defined constituency (see Appendix A for a

more complete definition). Any group calling itself a CSIRT for a

specific constituency must therefore react to reported security

incidents, and to threats to "their" constituency in ways which the

specific community agrees to be in its general interest.

Since it is vital that each member of a constituent community be able

to understand what is reasonable to expect of their team, a CSIRT

should make it clear who belongs to their constituency and define the

services the team offers to the community. Additionally, each CSIRT

should publish its policies and operating procedures. Similarly,

these same constituents need to know what is expected of them in

order for them to receive the services of their team. This requires

that the team also publish how and where to report incidents.

This document details a template which will be used by CSIRTs to

communicate this information to their constituents. The constituents

should certainly expect a CSIRT to provide the services they describe

in the completed template.

It must be emphasized that without active participation from users,

the effectiveness of the CSIRT's services can be greatly diminished.

This is particularly the case with reporting. At a minimum, users

need to know that they should report security incidents, and know how

and to where they should report them.

Many computer security incidents originate outside local community

boundaries and affect inside sites, others originate inside the local

community and affect hosts or users on the outside. Often,

therefore, the handling of security incidents will involve multiple

sites and potentially multiple CSIRTs. Resolving these incidents

will require cooperation between individual sites and CSIRTs, and

between CSIRTs.

Constituent communities need to know exactly how their CSIRT will be

working with other CSIRTs and organizations outside their

constituency, and what information will be shared.

The rest of this document describes the set of topics and issues that

CSIRTs need to elaborate for their constituents. However, there is no

attempt to specify the "correct" answer to any one topic area.

Rather, each topic is discussed in terms of what that topic means.

Chapter two provides an overview of three major areas: the

publishing of information by a response team, the definition of the

response team's relationship to other response teams, and the need

for secure communications. Chapter three describes in detail all the

types of information that the community needs to know about their

response team.

For ease of use by the community, these topics are condensed into an

outline template found in Appendix D. This template can be used by

constituents to elicit information from their CSIRT.

It is the working group's sincere hope that through clarification of

the topics in this document, understanding between the community and

its CSIRTs will be increased.

2 Scope

The interactions between an incident response team and its

constituent community response team require first that the community

understand the policies and procedures of the response team. Second,

since many response teams collaborate to handle incidents, the

community must also understand the relationship between their

response team and other teams. Finally, many interactions will take

advantage of existing public infrastructures, so the community needs

to know how those communications will be protected. Each of these

subjects will be described in more detail in the following three

sections.

2.1 Publishing CSIRT Policies and Procedures

Each user who has Access to a Computer Security Incident Response

Team should know as much as possible about the services of and

interactions with this team long before he or she actually needs

them.

A clear statement of the policies and procedures of a CSIRT helps the

constituent understand how best to report incidents and what support

to expect afterwards. Will the CSIRT assist in resolving the

incident? Will it provide help in avoiding incidents in the future?

Clear expectations, particularly of the limitations of the services

provided by a CSIRT, will make interaction with it more efficient and

effective.

There are different kinds of response teams: some have very broad

constituencies (e.g., CERT Coordination Center and the Internet),

others have more bounded constituencies (e.g., DFN-CERT, CIAC), and

still others have very restricted constituencies (e.g., commercial

response teams, corporate response teams). Regardless of the type of

response team, the constituency supported by it must be knowledgeable

about the team's policies and procedures. Therefore, it is mandatory

that response teams publish such information to their constituency.

A CSIRT should communicate all necessary information about its

policies and services in a form suitable to the needs of its

constituency. It is important to understand that not all policies

and procedures need be publicly available. For example, it is not

necessary to understand the internal operation of a team in order to

interact with it, as when reporting an incident or receiving guidance

on how to analyze or secure one's systems.

In the past, some teams supplied a kind of Operational Framework,

others provided a Frequently Asked Questions list (FAQ), while still

others wrote papers for distribution at user conferences or sent

newsletters.

We recommend that each CSIRT publish its guidelines and procedures on

its own information server (e.g. a World Wide Web server). This

would allow constituents to easily access it, though the problem

remains of how a constituent can find his or her team; people within

the constituency have to discover that there is a CSIRT "at their

disposal."

It is foreseen that completed CSIRT templates will soon become

searchable by modern search engines, which will aid in distributing

information about the existence of CSIRTs and basic information

required to approach them.

It would be very useful to have a central repository containing all

the completed CSIRT templates. No such repository exists at the time

of writing, though this might change in the future.

Regardless of the source from which the information is retrieved, the

user of the template must check its authenticity. It is highly

recommended that such vital documents be protected by digital

signatures. These will allow the user to verify that the template

was indeed published by the CSIRT and that it has not been tampered

with. This document assumes the reader is familiar with the proper

use of digital signatures to determine whether a document is

authentic.

2.2 Relationships between different CSIRTs

In some cases a CSIRT may be able to operate effectively on its own

and in close cooperation with its constituency. But with today's

international networks it is much more likely that most of the

incidents handled by a CSIRT will involve parties external to its

constituency. Therefore the team will need to interact with other

CSIRTs and sites outside its constituency.

The constituent community should understand the nature and extent of

this collaboration, as very sensitive information about individual

constituents may be disclosed in the process.

Inter-CSIRT interactions could include aSKINg other teams for advice,

disseminating knowledge of problems, and working cooperatively to

resolve a security incident affecting one or more of the CSIRTs'

constituencies.

In establishing relationships to support such interactions, CSIRTs

must decide what kinds of agreements can exist between them so as to

share yet safeguard information, whether this relationship can be

disclosed, and if so to whom.

Note that there is a difference between a peering agreement, where

the CSIRTs involved agree to work together and share information, and

simple co-operation, where a CSIRT (or any other organization) simply

contacts another CSIRT and asks for help or advice.

Although the establishment of such relationships is very important

and affects the ability of a CSIRT to support its constituency, it is

up to the teams involved to decide about the details. It is beyond

the scope of this document to make recommendations for this process.

However, the same set of information used to set expectations for a

user community regarding sharing of information will help other

parties to understand the objectives and services of a specific

CSIRT, supporting a first contact.

2.3 Establishing Secure Communications

Once one party has decided to share information with another party,

or two parties have agreed to share information or work together - as

required for the coordination of computer security incident response

- all parties involved need secure communications channels. (In this

context, "secure" refers to the protected transmission of information

shared between different parties, and not to the appropriate use of

the information by the parties.)

The goals of secure communication are:

- Confidentiality:

Can somebody else access the content of the communication?

- Integrity:

Can somebody else manipulate the content of the communication?

- Authenticity:

Am I communicating with the "right" person?

It is very easy to send forged e-mail, and not hard to establish a

(false) identity by telephone. Cryptographic techniques, for

example Pretty Good Privacy (PGP) or Privacy Enhanced Mail (PEM) can

provide effective ways of securing e-mail. With the correct

equipment it is also possible to secure telephone communication. But

before using such mechanisms, both parties need the "right"

infrastructure, which is to say preparation in advance. The most

important preparation is ensuring the authenticity of the

cryptographic keys used in secure communication:

- Public keys (for techniques like PGP and PEM):

Because they are accessible through the Internet, public keys must

be authenticated before use. While PGP relies on a "Web of Trust"

(where users sign the keys of other users), PEM relies on a

hierarchy (where certification authorities sign the keys of users).

- Secret keys (for techniques like DES and PGP/conventional

encryption): Because these must be known to both sender and

receiver, secret keys must be exchanged before the communication

via a secure channel.

Communication is critical to all ASPects of incident response. A

team can best support the use of the above-mentioned techniques by

gathering all relevant information, in a consistent way. Specific

requirements (such as calling a specific number to check the

authenticity of keys) should be clear from the start. CSIRT

templates provide a standardized vehicle for delivering this

information.

It is beyond the scope of this document to address the technical and

administrative problems of secure communications. The point is that

response teams must support and use a method to secure the

communications between themselves and their constituents (or other

response teams). Whatever the mechanism is, the level of protection

it provides must be acceptable to the constituent community.

3 Information, Policies and Procedures

In chapter 2 it was mentioned that the policies and procedures of a

response team need to be published to their constituent community.

In this chapter we will list all the types of information that the

community needs to receive from its response team. How this

information is communicated to a community will differ from team to

team, as will the specific information content. The intent here is

to clearly describe the various kinds of information that a

constituent community expects from its response team.

To make it easier to understand the issues and topics relevant to the

interaction of constituents with "their" CSIRT, we suggest that a

CSIRT publish all information, policies, and procedures addressing

its constituency as a document, following the template given in

Appendix D. The template structure arranges items, making it easy to

supply specific information; in Appendix E we provide an example of a

filled-out template for the fictitious XYZ University. While no

recommendations are made as to what a CSIRT should adopt for its

policy or procedures, different possibilities are outlined to give

some examples. The most important thing is that a CSIRT have a

policy and that those who interact with the CSIRT be able to obtain

and understand it.

As always, not every aspect for every environment and/or team can be

covered. This outline should be seen as a suggestion. Each team

should feel free to include whatever they think is necessary to

support its constituency.

3.1 Obtaining the Document

Details of a CSIRT change with time, so the completed template must

indicate when it was last changed. Additionally, information should

be provided concerning how to find out about future updates. Without

this, it is inevitable that misunderstandings and misconceptions will

arise over time; outdated documents can do more harm than good.

- Date of last update This should be sufficient to allow

anyone interested to evaluate the

currency of the template.

- Distribution list Mailing lists are a convenient

mechanism to distribute up-to-date

information to a large number of

users. A team can decide to use its

own or an already existing list to

notify users whenever the document

changes. The list might normally be

groups the CSIRT has frequent

interactions with.

Digital signatures should be used

for update messages sent by a CSIRT.

- Location of the document The location where a current version

of the document is accessible through

a team's online information services.

Constituents can then easily learn

more about the team and check for

recent updates. This online version

should also be accompanied by a

digital signature.

3.2 Contact Information

Full details of how to contact the CSIRT should be listed here,

although this might be very different for different teams; for

example, some might choose not to publicize the names of their team

members. No further clarification is given when the meaning of the

item can be assumed.

- Name of the CSIRT

- Mailing Address

- Time zone This is useful for coordinating

incidents which cross time zones.

- Telephone number

- Facsimile number

- Other telecommunication Some teams might provide secure

voice communication (e.g. STU III).

- Electronic mail address

- Public keys and encryption The use of specific techniques

depends on the ability of the

communication partners to have

access to programs, keys and so on.

Relevant information should be

given to enable users to determine

if and how they can make use of

encrypted communication while

interacting with the CSIRT.

- Team members

- Operating Hours The operating hours and holiday

schedule should be provided here.

Is there a 24 hour hotline?

- Additional Contact Info Is there any specific customer

contact info?

More detailed contact information can be provided. This might

include different contacts for different services, or might be a list

of online information services. If specific procedures for access to

some services exist (for example addresses for mailing list

requests), these should be explained here.

3.3 Charter

Every CSIRT must have a charter which specifies what it is to do, and

the authority under which it will do it. The charter should include

at least the following items:

- Mission statement

- Constituency

- Sponsorship / affiliation

- Authority

3.3.1 Mission Statement

The mission statement should focus on the team's core activities,

already stated in the definition of a CSIRT. In order to be

considered a Computer Security Incident Response Team, the team must

support the reporting of incidents and support its constituency by

dealing with incidents.

The goals and purposes of a team are especially important, and

require clear, unambiguous definition.

3.3.2 Constituency

A CSIRT's constituency can be determined in any of several ways. For

example it could be a company's employees or its paid subscribers, or

it could be defined in terms of a technological focus, such as the

users of a particular operating system.

The definition of the constituency should create a perimeter around

the group to whom the team will provide service. The policy section

of the document (see below) should explain how requests from outside

this perimeter will be handled.

If a CSIRT decides not to disclose its constituency, it should

explain the reasoning behind this decision. For example, for-fee

CSIRTs will not list their clients but will declare that they provide

a service to a large group of customers that are kept confidential

because of the clients' contracts.

Constituencies might overlap, as when an ISP provides a CSIRT which

delivers services to customer sites that also have CSIRTs. The

Authority section of the CSIRT's description (see below) should make

such relationships clear.

3.3.3 Sponsoring Organization / Affiliation

The sponsoring organization, which authorizes the actions of the

CSIRT, should be given next. Knowing this will help the users to

understand the background and set-up of the CSIRT, and it is vital

information for building trust between a constituent and a CSIRT.

3.3.4 Authority

This section will vary greatly from one CSIRT to another, based on

the relationship between the team and its constituency. While an

organizational CSIRT will be given its authority by the management of

the organization, a community CSIRT will be supported and chosen by

the community, usually in a advisory role.

A CSIRT may or may not have the authority to intervene in the

operation of all of the systems within its perimeter. It should

identify the scope of its control as distinct from the perimeter of

its constituency. If other CSIRTs operate hierarchically within its

perimeter, this should be mentioned here, and the related CSIRTs

identified.

Disclosure of a team's authority may expose it to claims of

liability. Every team should seek legal advice on these matters.

(See section 3.7 for more on liability.)

3.4 Policies

It is critical that Incident Response Teams define their policies.

The following sections discuss communication of these policies to the

constituent community.

3.4.1 Types of Incidents and Level of Support

The types of incident which the team is able to address, and the

level of support which the team will offer when responding to each

type of incident, should be summarized here in list form. The

Services section (see below) provides the opportunity to give more

detailed descriptions, and to address non-incident-related topics.

The level of support may change depending on factors such as the

team's workload and the completeness of the information available.

Such factors should be outlined and their impact should be explained.

As a list of known types of incidents will be incomplete with regard

to possible or future incidents, a CSIRT should also give some

background on the "default" support for incident types not otherwise

mentioned.

The team should state whether it will act on information it receives

about vulnerabilities which create opportunities for future

incidents. A commitment to act on such information on behalf of its

constituency is regarded as an optional proactive service policy

rather than a core service requirement for a CSIRT.

3.4.2 Co-operation, Interaction and Disclosure of Information

This section should make explicit which related groups the CSIRT

routinely interacts with. Such interactions are not necessarily

related to the computer security incident response provided, but are

used to facilitate better cooperation on technical topics or

services. By no means need details about cooperation agreements be

given out; the main objective of this section is to give the

constituency a basic understanding of what kind of interactions are

established and what their purpose is.

Cooperation between CSIRTs can be facilitated by the use of unique

ticket number assignment combined with explicit handoff procedures.

This reduces the chance of misunderstandings, duplications of effort,

assists in incident tracking and prevents 'loops' in communication.

The reporting and disclosure policy should make clear who will be the

recipients of a CSIRT's report in each circumstance. It should also

note whether the team will expect to operate through another CSIRT or

directly with a member of another constituency over matters

specifically concerning that member.

Related groups a CSIRT will interact with are listed below:

Incident Response Teams:

A CSIRT will often need to interact with other CSIRTs. For

example a CSIRT within a large company may need to report

incidents to a national CSIRT, and a national CSIRT may need to

report incidents to national CSIRTs in other countries to deal

with all sites involved in a large-scale attack.

Collaboration between CSIRTs may lead to disclosure of

information. The following are examples of such disclosure, but

are not intended to be an exhaustive list:

- Reporting incidents within the constituency to other teams.

If this is done, site-related information may become public

knowledge, accessible to everyone, in particular the press.

- Handling incidents occurring within the constituency, but

reported from outside it (which implies that some information

has already been disclosed off-site).

- Reporting observations from within the constituency indicating

suspected or confirmed incidents outside it.

- Acting on reports of incidents from outside the constituency.

- Passing information about vulnerabilities to vendors, to

partner CSIRTs or directly to affected sites lying within or

outside the constituency.

- Feedback to parties reporting incidents or vulnerabilities.

- The provision of contact information relating to members of

the constituency, members of other constituencies, other

CSIRTs, or law-enforcement agencies.

Vendors:

Some vendors have their own CSIRTs, but some vendors may not. In

such cases a CSIRT will need to work directly with a vendor to

suggest improvements or modifications, to analyze the technical

problem or to test provided solutions. Vendors play a special

role in handling an incident if their products' vulnerabilities

are involved in the incident.

Law-enforcement agencies:

These include the police and other investigative agencies. CSIRTs

and users of the template should be sensitive to local laws and

regulations, which may vary considerably in different countries.

A CSIRT might advise on technical details of attacks or seek

advice on the legal implications of an incident. Local laws and

regulations may include specific reporting and confidentiality

requirements.

Press:

A CSIRT may be approached by the press for information and comment

from time to time.

An explicit policy concerning disclosure to the press can be

helpful, particularly in clarifying the expectations of a CSIRT's

constituency. The press policy will have to clarify the same

topics as above more specifically, as the constituency will

usually be very sensitive to press contacts.

Other:

This might include research activities or the relation to the

sponsoring organization.

The default status of any and all security-related information which

a team receives will usually be 'confidential,' but rigid adherence

to this makes the team to appear to be an informational 'black hole,'

which may reduce the likelihood of the team's obtaining cooperation

from clients and from other organizations. The CSIRT's template

should define what information it will report or disclose, to whom,

and when.

Different teams are likely to be subject to different legal

restraints requiring or limiting disclosure, especially if they work

in different jurisdictions. In addition, they may have reporting

requirements imposed by their sponsoring organization. Each team's

template should specify any such constraints, both to clarify users'

expectations and to inform other teams.

Conflicts of interest, particularly in commercial matters, may also

restrain disclosure by a team; this document does not recommend on

how such conflicts should be addressed.

A team will normally collect statistics. If statistical information

is distributed, the template's reporting and disclosure policy should

say so, and should describe how to obtain such statistics.

3.4.3 Communication and Authentication

You must have a policy which describes methods of secure and

verifiable communication that you will use. This is necessary for

communication between CSIRTs and between a CSIRT and its

constituents. The template should include public keys or pointers to

them, including key fingerprints, together with guidelines on how to

use this information to check authenticity and how to deal with

corrupted information (for example where to report this fact).

At the moment it is recommended that as a minimum every CSIRT have

(if possible), a PGP key available. A team may also make other

mechanisms available (for example PEM, MOSS, S/MIME), according to

its needs and the needs of its constituents. Note however, that

CSIRTs and users should be sensitive to local laws and regulations.

Some countries do not allow strong encryption, or enforce specific

policies on the use of encryption technology. In addition to

encrypting sensitive information whenever possible, correspondence

should include digital signatures. (Please note that in most

countries, the protection of authenticity by using digital signatures

is not affected by existing encryption regulations.)

For communication via telephone or facsimile a CSIRT may keep secret

authentication data for parties with whom they may deal, such as an

agreed passWord or phrase. Obviously, such secret keys must not be

published, though their existence may be.

3.5 Services

Services provided by a CSIRT can be roughly divided into two

categories: real-time activities directly related to the main task of

incident response, and non-real-time proactive activities, supportive

of the incident response task. The second category and part of the

first category consist of services which are optional in the sense

that not all CSIRTs will offer them.

3.5.1 Incident Response

Incident response usually includes assessing incoming reports about

incidents ("Incident Triage") and following up on these with other

CSIRTs, ISPs and sites ("Incident Coordination"). A third range of

services, helping a local site to recover from an incident ("Incident

Resolution"), is comprised of typically optional services, which not

all CSIRTs will offer.

3.5.1.1 Incident Triage

Incident triage usually includes:

- Report assessment Interpretion of incoming incident

reports, prioritizing them, and

relating them to ongoing incidents

and trends.

- Verification Help in determining whether an

incident has really occurred, and

its scope.

3.5.1.2 Incident Coordination

Incident Coordination normally includes:

- Information categorization Categorization of the incident related

information (logfiles, contact

information, etc.) with respect to

the information disclosure policy.

- Coordination Notification of other involved

parties on a need-to-know basis, as

per the information disclosure

policy.

3.5.1.3 Incident Resolution

Usually additional or optional, incident resolution services

include:

- Technical Assistance This may include analysis of

compromised systems.

- Eradication Elimination of the cause of a

security incident (the vulnerability

exploited), and its effects (for

example, continuing access to the

system by an intruder).

- Recovery Aid in restoring affected systems

and services to their status before

the security incident.

3.5.2. Proactive Activities

Usually additional or optional, proactive services might include:

- Information provision This might include an archive of

known vulnerabilities, patches or

resolutions of past problems, or

advisory mailing lists.

- Security Tools This may include tools for auditing

a Site's security.

- Education and training

- Product evaluation

- Site security auditing and consulting

3.6 Incident Reporting Forms

The use of reporting forms makes it simpler for both users and teams

to deal with incidents. The constituent can prepare answers to

various important questions before he or she actually contacts the

team, and can therefore come well prepared. The team gets all the

necessary information at once with the first report and can proceed

efficiently.

Depending on the objectives and services of a particular CSIRT,

multiple forms may be used, for example a reporting form for a new

vulnerability may be very different from the form used for reporting

incidents.

It is most efficient to provide forms through the online information

services of the team. The exact pointers to them should be given in

the CSIRT description document, together with statements about

appropriate use, and guidelines for when and how to use the forms. If

separate e-mail addresses are supported for form-based reporting,

they should be listed here again.

One example of such a form is the Incident Reporting Form provided by

the CERT Coordination Center:

- FTP://info.cert.org/incident_reporting_form

3.7 Disclaimers

Although the CSIRT description document does not constitute a

contract, liability may conceivably result from its descriptions of

services and purposes. The inclusion of a disclaimer at the end of

the template is therefore recommended and should warn the user about

possible limitations.

In situations where the original version of a document must be

translated into another language, the translation should carry a

disclaimer and a pointer to the original. For example:

Although we tried to carefully translate the original document

from German into English, we can not be certain that both

documents express the same thoughts in the same level of detail

and correctness. In all cases, where there is a difference

between both versions, the German version will prevail.

The use of and protection by disclaimers is affected by local laws

and regulations, of which each CSIRT should be aware. If in doubt the

CSIRT should check the disclaimer with a lawyer.

Appendix A: Glossary of Terms

This glossary defines terms used in describing security incidents and

Computer Security Incident Response Teams. Only a limited list is

included. For more definitions please refer to other sources, for

example to the Internet User's Glossary [RFC1983].

Constituency:

Implicit in the purpose of a Computer Security Incident Response

Team is the existence of a constituency. This is the group of

users, sites, networks or organizations served by the team. The

team must be recognized by its constituency in order to be

effective.

Security Incident:

For the purpose of this document, this term is a synonym of

Computer Security Incident: any adverse event which compromises

some aspect of computer or network security.

The definition of an incident may vary between organizations, but

at least the following categories are generally applicable:

- Loss of confidentiality of information.

- Compromise of integrity of information.

- Denial of service.

- Misuse of service, systems or information.

- Damage to systems.

These are very general categories. For instance the replacement

of a system utility program by a Trojan Horse is an example of '

compromise of integrity,' and a successful password attack is an

example of 'loss of confidentiality.' Attacks, even if they

failed because of proper protection, can be regarded as Incidents.

Within the definition of an incident the word 'compromised' is

used. Sometimes an administrator may only 'suspect' an incident.

During the response it must be established whether or not an

incident has really occurred.

Computer Security Incident Response Team:

Based on two of the definitions given above, a CSIRT is a team

that coordinates and supports the response to security incidents

that involve sites within a defined constituency.

In order to be considered a CSIRT, a team must:

- Provide a (secure) channel for receiving reports about

suspected incidents.

- Provide assistance to members of its constituency in

handling these incidents.

- Disseminate incident-related information to its

constituency and to other involved parties.

Note that we are not referring here to police or other law

enforcement bodies which may investigate computer-related crime.

CSIRT members, indeed, need not have any powers beyond those of

ordinary citizens.

Vendor:

A 'vendor' is any entity that produces networking or computing

technology, and is responsible for the technical content of that

technology. Examples of 'technology' include hardware (desktop

computers, routers, switches, etc.), and software (operating

systems, mail forwarding systems, etc.).

Note that the supplier of a technology is not necessarily the '

vendor' of that technology. As an example, an Internet Service

Provider (ISP) might supply routers to each of its customers, but

the 'vendor' is the manufacturer, since the manufacturer, rather

than the ISP, is the entity responsible for the technical content

of the router.

Vulnerability:

A 'vulnerability' is a characteristic of a piece of technology

which can be exploited to perpetrate a security incident. For

example, if a program unintentionally allowed ordinary users to

execute arbitrary operating system commands in privileged mode,

this "feature" would be a vulnerability.

Appendix B: Related Material

Important issues in responding to security incidents on a site level

are contained in [RFC2196], the Site Security Handbook, produced by

the Site Security Handbook Working Group (SSH). This document will

be updated by the SSH working group and will give recommendations for

local policies and procedures, mainly related to the avoidance of

security incidents.

Other documents of interest for the discussion of CSIRTs and their

tasks are available by anonymous FTP. A collection can be found on:

- ftp://ftp.cert.dfn.de/pub/docs/csir/

Please refer to file 01-README for further information about

the content of this Directory.

Some especially interesting documents in relation to this document

are as follows:

- ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/

reports/R-92-01

This report contains the Operational Framework of CERT-NL, the

CSIRT of SURFnet (network provider in the Netherlands).

- For readers interested in the operation of FIRST (Forum of

Incident Response and Security Teams) more information is

collected in Appendix C.

- http://hightop.nrl.navy.mil/news/incident.Html

This document leads to the NRL Incident Response Manual.

- http://www.cert.dfn.de/eng/team/kpk/certbib.html

This document contains an annotated bibliography of available

material, documents and files about the operation of CSIRTs

with links to many of the referenced items.

- ftp://info.cert.org/incident_reporting_form

This Incident Reporting Form is provided by the CERT

Coordination Center to gather incident information and to avoid

additional delays caused by the need to request more detailed

information from the reporting site.

- http://www.cert.org/cert.faqintro.html

A collection of frequently asked questions from the CERT

Coordination Center.

Appendix C: Known Computer Security Incident Response Teams

Today, there are many different CSIRTs but no single source lists

every team. Most of the major and long established teams (the first

CSIRT was founded in 1988) are nowadays members of FIRST, the

worldwide Forum of Incident Response and Security Teams. At the time

of writing, more than 55 teams are members (1 in Australia, 13 in

Europe, all others in North America). Information about FIRST can be

found:

- http://www.first.org/

The current list of members is available also, with the relevant

contact information and some additional information provided by the

particular teams:

- http://www.first.org/team-info/

For CSIRTs which want to become members of this forum (please note

that a team needs a sponsor - a team which is already a full member

of FIRST - to be introduced), the following files contain more

information:

- http://www.first.org/about/op_frame.html

The Operational Framework of FIRST.

- http://www.first.org/docs/newmem.html

Guidelines for teams which want to become members of FIRST.

Many of the European teams, regardless of whether they are members

of FIRST or not, are listed by countries on a page maintained by

the German CSIRT:

- http://www.cert.dfn.de/eng/csir/europe/certs.html

To learn about existing teams suitable to one's needs it is

often helpful to ask either known teams or an Internet Service

Provider for the "right" contact.

Appendix D: Outline for CSIRT Template

This outline summarizes in point form the issues addressed in this

document, and is the recommended template for a CSIRT description

document. Its structure is designed to facilitate the communication

of a CSIRT's policies, procedures, and other relevant information to

its constituency and to outside organizations such as other CSIRTs. A

'filled-in' example of this template is given as Appendix E.

1. Document Information

1.1 Date of Last Update

1.2 Distribution List for Notifications

1.3 Locations where this Document May Be Found

2. Contact Information

2.1 Name of the Team

2.2 Address

2.3 Time Zone

2.4 Telephone Number

2.5 Facsimile Number

2.6 Other Telecommunication

2.7 Electronic Mail Address

2.8 Public Keys and Encryption Information

2.9 Team Members

2.10 Other Information

2.11 Points of Customer Contact

3. Charter

3.1 Mission Statement

3.2 Constituency

3.3 Sponsorship and/or Affiliation

3.4 Authority

4. Policies

4.1 Types of Incidents and Level of Support

4.2 Co-operation, Interaction and Disclosure of Information

4.3 Communication and Authentication

5. Services

5.1 Incident Response

5.1.1. Incident Triage

5.1.2. Incident Coordination

5.1.3. Incident Resolution

5.2 Proactive Activities

6. Incident Reporting Forms

7. Disclaimers

Appendix E: Example - 'filled-in' Template for a CSIRT

Below is an example of a filled-in template for a fictitious CSIRT

called XYZ-CSIRT. This text is for example purposes only, and does

not constitute endorsement by the working group or the IETF of any

particular set of procedures or policies. While CSIRTs are welcome

to use any or all of this text if they wish, such use is of course

not mandatory, or even appropriate in most cases.

CSIRT Description for XYZ-CERT

-----------------------------

1. About this document

1.1 Date of Last Update

This is version 1.01, published 1997/03/31.

1.2 Distribution List for Notifications

Notifications of updates are submitted to our mailing list

<xyz-cert-info@xyz-univ.ca>. Subscription requests for this

list should be sent to the Majordomo at

<xyz-cert-info-request@xyz-univ.ca>; the body of the message

should consist of the word "subscribe". Send the word "help"

instead if you don't know how to use a Majordomo list manager.

This mailing list is moderated.

1.3 Locations where this Document May Be Found

The current version of this CSIRT description document is

available from the XYZ-CERT WWW site; its URL is

http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.txt

Une version francaise de ce document est igalement disponible:

http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.txt

Please make sure you are using the latest version.

1.4 Authenticating this Document

Both the English and French versions of this document have

been signed with the XYZ-CERT's PGP key. The signatures are

also on our Web site, under:

http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.asc

http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.asc

2. Contact Information

2.1 Name of the Team

"XYZ-CERT": the XYZ University Computer Emergency Response

Team.

2.2 Address

XYZ-CERT

XYZ University, Computing Services Department

12345 Rue Principale

UniversityTown, Quebec

Canada H0H 0H0

2.3 Time Zone

Canada/Eastern (GMT-0500, and GMT-0400 from April to October)

2.4 Telephone Number

+1 234 567 7890 (ask for the XYZ-CERT)

2.5 Facsimile Number

+1 234 567 7899 (this is *not* a secure fax)

2.6 Other Telecommunication

None available.

2.7 Electronic Mail Address

<xyz-cert@xyz-univ.ca> This is a mail alias that relays mail

to the human(s) on duty for the XYZ-CERT.

2.8 Public Keys and Other Encryption Information

The XYZ-CERT has a PGP key, whose KeyID is 12345678 and

whose fingerprint is

11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11.

The key and its signatures can be found at the usual large

public keyservers.

Because PGP is still a relatively new technology at XYZ

University, this key still has relatively few signatures;

efforts are underway to increase the number of links to this

key in the PGP "web of trust". In the meantime, since most

fellow universities in Quebec have at least one staff member

who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has

signed the XYZ-CERT key, and will be happy to confirm its

fingerprint and that of her own key to those people who know

her, by telephone or in person.

2.9 Team Members

Zoe Doe of Computing Services is the XYZ-CERT coordinator.

Backup coordinators and other team members, along with their

areas of expertise and contact information, are listed in the

XYZ-CERT web pages, at

http://www.xyz-univ.ca/xyz-cert/teamlist.html

Management, liaison and supervision are provided by Steve Tree,

Assistant Director (Technical Services), Computing Services.

2.10 Other Information

General information about the XYZ-CERT, as well as links to

various recommended security resources, can be found at

http://www.xyz-univ.ca/xyz-cert/index.html

2.11 Points of Customer Contact

The preferred method for contacting the XYZ-CERT is via

e-mail at <xyz-cert@xyz-univ.ca>; e-mail sent to this address

will "biff" the responsible human, or be automatically

forwarded to the appropriate backup person, immediately. If

you require urgent assistance, put "urgent" in your subject

line.

If it is not possible (or not advisable for security reasons)

to use e-mail, the XYZ-CERT can be reached by telephone during

regular Office hours. Telephone messages are checked less

often than e-mail.

The XYZ-CERT's hours of operation are generally restricted to

regular business hours (09:00-17:00 Monday to Friday except

holidays).

If possible, when submitting your report, use the form

mentioned in section 6.

3. Charter

3.1 Mission Statement

The purpose of the XYZ-CERT is, first, to assist members of XYZ

University community in implementing proactive measures to

reduce the risks of computer security incidents, and second, to

assist XYZ community in responding to such incidents when they

occur.

3.2 Constituency

The XYZ-CERT's constituency is the XYZ University community,

as defined in the context of the "XYZ University Policy on

Computing Facilities". This policy is available at

http://www-compserv.xyz-univ.ca/policies/pcf.html

However, please note that, notwithtanding the above, XYZ-CERT

services will be provided for on-site systems only.

3.3 Sponsorship and/or Affiliation

The XYZ-CERT is sponsored by the ACME Canadian Research

Network. It maintains affiliations with various University

CSIRTs throughout Canada and the USA on an as needed basis.

3.4 Authority

The XYZ-CERT operates under the auspices of, and with authority

delegated by, the Department of Computing Services of XYZ

University. For further information on the mandate and

authority of the Department of Computing Services, please

refer to the XYZ University "Policy on Computing Facilities",

available at

http://www-compserv.xyz-univ.ca/policies/pcf.html

The XYZ-CERT expects to work cooperatively with system

administrators and users at XYZ University, and, insofar as

possible, to avoid authoritarian relationships. However,

should circumstances warrant it, the XYZ-CERT will appeal to

Computing Services to exert its authority, direct or indirect,

as necessary. All members of the XYZ-CERT are members of the

CCSA (Committee of Computer Systems Administrators), and have

all of the powers and responsibilities assigned to Systems

Administrators by the Policy on Computing Facilities, or are

members of University management.

Members of the XYZ University community who wish to appeal the

actions of the XYZ-CERT should contact the Assistant Director

(Technical Services), Computing Services. If this recourse is

not satisfactory, the matter may be referred to the Director

of Computing Services (in the case of perceived

problems with existing policy), or to the XYZ University

Office of Rights and Responsibilities (in the case of perceived

errors in the application of existing policy).

4. Policies

4.1 Types of Incidents and Level of Support

The XYZ-CERT is authorized to address all types of computer

security incidents which occur, or threaten to occur, at

XYZ University.

The level of support given by XYZ-CERT will vary depending on

the type and severity of the incident or issue, the type of

constituent, the size of the user community affected, and the

XYZ-CERT's resources at the time, though in all cases some

response will be made within one working day. Resources will

be assigned according to the following priorities, listed in

decreasing order:

- Threats to the physical safety of human beings.

- Root or system-level attacks on any Management Information

System, or any part of the backbone network infrastructure.

- Root or system-level attacks on any large public service

machine, either multi-user or dedicated-purpose.

- Compromise of restricted confidential service accounts or

software installations, in particular those used for MIS

applications containing confidential data, or those used

for system administration.

- Denial of service attacks on any of the above three items.

- Any of the above at other sites, originating from XYZ

University.

- Large-scale attacks of any kind, e.g. sniffing attacks,

IRC "social engineering" attacks, password cracking

attacks.

- Threats, harassment, and other criminal offenses

involving individual user accounts.

- Compromise of individual user accounts on multi-user

systems.

- Compromise of desktop systems.

- Forgery and misrepresentation, and other security-related

violations of local rules and regulations, e.g. netnews

and e-mail forgery, unauthorized use of IRC bots.

- Denial of service on individual user accounts, e.g.

mailbombing.

Types of incidents other than those mentioned above will be

prioritized according to their apparent severity and extent.

Note that no direct support will be given to end users; they

are expected to contact their system administrator, network

administrator, or department head for assistance. The XYZ-CERT

will support the latter people.

While the XYZ-CERT understands that there exists great

variation in the level of system administrator expertise at XYZ

University, and while the XYZ-CERT will endeavor to present

information and assistance at a level appropriate to each

person, the XYZ-CERT cannot train system administrators on the

fly, and it cannot perform system maintenance on their behalf.

In most cases, the XYZ-CERT will provide pointers to the

information needed to implement appropriate measures.

The XYZ-CERT is committed to keeping the XYZ University system

administration community informed of potential vulnerabilities,

and where possible, will inform this community of such

vulnerabilities before they are actively exploited.

4.2 Co-operation, Interaction and Disclosure of Information

While there are legal and ethical restrictions on the flow of

information from XYZ-CERT, many of which are also outlined in

the XYZ University Policy on Computing Facilities, and all of

which will be respected, the XYZ-CERT acknowledges its

indebtedness to, and declares its intention to contribute to,

the spirit of cooperation that created the Internet.

Therefore, while appropriate measures will be taken to protect

the identity of members of our constituency and members of

neighbouring sites where necessary, the XYZ-CERT will otherwise

share information freely when this will assist others in

resolving or preventing security incidents.

In the paragraphs below, "affected parties" refers to the

legitimate owners, operators, and users of the relevant

computing facilities. It does not refer to unauthorized

users, including otherwise authorized users making

unauthorized use of a facility; such intruders may have no

expectation of confidentiality from the XYZ-CERT. They may or

may not have legal rights to confidentiality; such rights will

of course be respected where they exist.

Information being considered for release will be classified as

follows:

- Private user information is information about particular

users, or in some cases, particular applications, which

must be considered confidential for legal, contractual,

and/or ethical reasons.

Private user information will be not be released in

identifiable form outside the XYZ-CERT, except as provided

for below. If the identity of the user is disguised, then

the information can be released freely (for example to show

a sample .cshrc file as modified by an intruder, or to

demonstrate a particular social engineering attack).

- Intruder information is similar to private user

information, but concerns intruders.

While intruder information, and in particular identifying

information, will not be released to the public (unless it

becomes a matter of public record, for example because

criminal charges have been laid), it will be exchanged

freely with system administrators and CSIRTs tracking an

incident.

- Private site information is technical information about

particular systems or sites.

It will not be released without the permission of the site

in question, except as provided for below.

- Vulnerability information is technical information about

vulnerabilities or attacks, including fixes and

workarounds.

Vulnerability information will be released freely, though

every effort will be made to inform the relevant vendor

before the general public is informed.

- Embarrassing information includes the statement that an

incident has occurred, and information about its extent or

severity. Embarrassing information may concern a site or

a particular user or group of users.

Embarrassing information will not be released without the

permission of the site or users in question, except as

provided for below.

- Statistical information is embarrassing information with

the identifying information stripped off.

Statistical information will be released at the discretion

of the Computing Services Department.

- Contact information explains how to reach system

administrators and CSIRTs.

Contact information will be released freely, except where

the contact person or entity has requested that this not

be the case, or where XYZ-CERT has reason to believe that

the dissemination of this information would not be

appreciated.

Potential recipients of information from the XYZ-CERT will be

classified as follows:

- Because of the nature of their responsibilities and

consequent expectations of confidentiality, members of XYZ

University management are entitled to receive whatever

information is necessary to facilitate the handling of

computer security incidents which occur in their

jurisdictions.

- Members of the Office of Rights and Responsibilities are

entitled to receive whatever information they request

concerning a computer security incident or related matter

which has been referred to them for resolution. The same is

true for the XYZ Security Department, when its assistance in

an investigation has been enlisted, or when the investigation

has been instigated at its request.

- System administrators at XYZ University who are members of

the CCSA are also, by virtue of their responsibilities,

trusted with confidential information. However, unless such

people are also members of XYZ-CERT, they will be given only

that confidential information which they must have in order

to assist with an investigation, or in order to secure their

own systems.

- Users at XYZ University are entitled to information which

pertains to the security of their own computer accounts,

even if this means revealing "intruder information", or

"embarrassing information" about another user. For

example, if account aaaa is cracked and the intruder attacks

account bbbb, user bbbb is entitled to know that aaaa was

cracked, and how the attack on the bbbb account was

executed. User bbbb is also entitled, if she or he requests

it, to information about account aaaa which might enable

bbbb to investigate the attack. For example, if bbbb was

attacked by someone remotely connected to aaaa, bbbb should

be told the provenance of the connections to aaaa, even

though this information would ordinarily be considered

private to aaaa. Users at XYZ University are entitled to be

notified if their account is believed to have been

compromised.

- The XYZ University community will receive no restricted

information, except where the affected parties have given

permission for the information to be disseminated.

Statistical information may be made available to the general

XYZ community. There is no obligation on the part of the

XYZ-CERT to report incidents to the community, though it may

choose to do so; in particular, it is likely that the

XYZ-CERT will inform all affected parties of the ways in

which they were affected, or will encourage the affected site

to do so.

- The public at large will receive no restricted information.

In fact, no particular effort will be made to communicate

with the public at large, though the XYZ-CERT recognizes

that, for all intents and purposes, information made

available to the XYZ University community is in effect made

available to the community at large, and will tailor the

information in consequence.

- The computer security community will be treated the same way

the general public is treated. While members of XYZ-CERT may

participate in discussions within the computer security

community, such as newsgroups, mailing lists (including the

full-disclosure list "bugtraq"), and conferences, they will

treat such forums as though they were the public at large.

While technical issues (including vulnerabilities) may be

discussed to any level of detail, any examples taken from

XYZ-CERT experience will be disguised to avoid identifying

the affected parties.

- The press will also be considered as part of the general

public. The XYZ-CERT will not interact directly with the

Press concerning computer security incidents, except to point

them toward information already released to the general

public. If necessary, information will be provided to the

XYZ University Public Relations Department, and to the

Customer Relations group of the Computing Services

Department. All incident-related queries will be referred to

these two bodies. The above does not affect the ability of

members of XYZ-CERT to grant interviews on general computer

security topics; in fact, they are encouraged to do to, as a

public service to the community.

- Other sites and CSIRTs, when they are partners in the

investigation of a computer security incident, will in some

cases be trusted with confidential information. This will

happen only if the foreign site's bona fide can be verified,

and the information transmitted will be limited to that which

is likely to be helpful in resolving the incident. Such

information sharing is most likely to happen in the case of

sites well known to XYZ-CERT (for example, several other

Quebec universities have informal but well-established

working relationships with XYZ University in such matters).

For the purposes of resolving a security incident, otherwise

semi-private but relatively harmless user information such as

the provenance of connections to user accounts will not be

considered highly sensitive, and can be transmitted to a

foreign site without excessive precautions. "Intruder

information" will be transmitted freely to other system

administrators and CSIRTs. "Embarrassing information" can be

transmitted when there is reasonable assurance that it will

remain confidential, and when it is necessary to resolve an

incident.

- Vendors will be considered as foreign CSIRTs for most intents

and purposes. The XYZ-CERT wishes to encourage vendors of

all kinds of networking and computer equipment, software, and

services to improve the security of their products. In aid

of this, a vulnerability discovered in such a product will be

reported to its vendor, along with all technical details

needed to identify and fix the problem. Identifying details

will not be given to the vendor without the permission of the

affected parties.

- Law enforcement officers will receive full cooperation from

the XYZ-CERT, including any information they require to

pursue an investigation, in accordance with the Policy on

Computing Facilities.

4.3 Communication and Authentication

In view of the types of information that the XYZ-CERT will

likely be dealing with, telephones will be considered

sufficiently secure to be used even unencrypted. Unencrypted

e-mail will not be considered particularly secure, but will be

sufficient for the transmission of low-sensitivity data. If

it is necessary to send highly sensitive data by e-mail, PGP

will be used. Network file transfers will be considered to

be similar to e-mail for these purposes: sensitive data should

be encrypted for transmission.

Where it is necessary to establish trust, for example before

relying on information given to the XYZ-CERT, or before

disclosing confidential information, the identity and bona

fide of the other party will be ascertained to a reasonable

degree of trust. Within XYZ University, and with known

neighbor sites, referrals from known trusted people will

suffice to identify someone. Otherwise, appropriate methods

will be used, such as a search of FIRST members, the use of

WHOIS and other Internet registration information, etc, along

with telephone call-back or e-mail mail-back to ensure that

the party is not an impostor. Incoming e-mail whose data must

be trusted will be checked with the originator personally, or

by means of digital signatures (PGP in particular is

supported).

5. Services

5.1 Incident Response

XYZ-CERT will assist system administrators in handling the

technical and organizational aspects of incidents. In

particular, it will provide assistance or advice with respect

to the following aspects of incident management:

5.1.1 Incident Triage

- Investigating whether indeed an incident occured.

- Determining the extent of the incident.

5.1.2 Incident Coordination

- Determining the initial cause of the incident

(vulnerability exploited).

- Facilitating contact with other sites which may be

involved.

- Facilitating contact with XYZ University Security and/or

appropriate law enforcement officials, if necessary.

- Making reports to other CSIRTs.

- Composing announcements to users, if applicable.

5.1.3 Incident Resolution

- Removing the vulnerability.

- Securing the system from the effects of the incident.

- Evaluating whether certain actions are likely to reap

results in proportion to their cost and risk, in

particular those actions aimed at an eventual prosecution

or disciplinary action: collection of evidence after the

fact, observation of an incident in progress, setting

traps for intruders, etc.

- Collecting evidence where criminal prosecution, or

University disciplinary action, is contemplated.

In addition, XYZ-CERT will collect statistics concerning

incidents which occur within or involve the XYZ University

community, and will notify the community as necessary to

assist it in protecting against known attacks.

To make use of XYZ-CERT's incident response services, please

send e-mail as per section 2.11 above. Please remember that

the amount of assistance available will vary according to

the parameters described in section 4.1.

5.2 Proactive Activities

The XYZ-CERT coordinates and maintains the following

services to the extent possible depending on its resources:

- Information services

- List of departmental security contacts, administrative

and technical. These lists will be available to the

general public, via commonly-available channels such as

the World Wide Web and/or the Domain Name Service.

- Mailing lists to inform security contacts of new

information relevant to their computing environments.

These lists will be available only to XYZ University

system administrators.

- Repository of vendor-provided and other security-related

patches for various operating systems. This repository

will be available to the general public wherever

license restrictions allow it, and will be provided via

commonly-available channels such as the World Wide Web

and/or ftp.

- Repository of security tools and documentation for

use by sysadmins. Where possible, precompiled

ready-to-install versions will be supplied. These will

be supplied to the general public via www or ftp as

above.

- "Clipping" service for various existing resources, such

as major mailing lists and newsgroups. The resulting

clippings will be made available either on the

restricted mailing list or on the web site, depending

on their sensitivity and urgency.

- Training services

- Members of the XYZ-CERT will give periodic seminars on

computer security related topics; these seminars will

be open to XYZ University system administrators.

- Auditing services

- Central file integrity checking service for Unix

machines, and for any other platforms capable of

running "tripwire".

- Security level assignments; machines and subnetworks

at XYZ University will be audited and assigned a

security level. This security level information will be

available to the XYZ University community, to facilitate

the setting of appropriate access privileges. However,

details of the security analyses will be confidential,

and available only to the concerned parties.

- Archiving services

- Central logging service for machines capable of

Unix-style remote logging. Incoming log entries will

be watched by an automated log analysis program, and

events or trends indicative of a potential security

problem will be reported to the affected system

administrators.

- Records of security incidents handled will be kept.

While the records will remain confidential, periodic

statistical reports will be made available to the XYZ

University community.

Detailed descriptions of the above services, along with

instructions for joining mailing lists, downloading

information, or participating in certain services such as the

central logging and file integrity checking services, are

available on the XYZ-CERT web site, as per section 2.10

above.

6. Incident Reporting Forms

There are no local forms developed yet for reporting incidents

to XYZ-CERT. If possible, please make use of the Incident

Reporting Form of the CERT Coordination Center (Pittsburgh,

PA). The current version is available from:

ftp://info.cert.org/incident_reporting_form

7. Disclaimers

While every precaution will be taken in the preparation of

information, notifications and alerts, XYZ-CERT assumes no

responsibility for errors or omissions, or for damages

resulting from the use of the information contained within.

4 Acknowlegdements

The editors gratefully acknowledge the contributed material and

editorial scrutiny of Anne Bennett. Thanks also to Don Stikvoort

for assistance reworking the description of Incident Response Team

services.

5 References

[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC2196,

September 1997.

[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC1983,

August 1996.

6 Security Considerations

This document discusses the operation of Computer Security Incident

Response Teams, and the teams' interactions with their constituencies

and with other organizations. It is, therefore, not directly

concerned with the security of protocols, applications, or network

systems themselves. It is not even concerned with particular

responses and reactions to security incidents, but only with the

appropriate description of the responses provided by CSIRTs.

Nonetheless, it is vital that the CSIRTs themselves operate securely,

which means that they must establish secure communication channels

with other teams, and with members of their constituency. They must

also secure their own systems and infrastructure, to protect the

interests of their constituency and to maintain the confidentiality

of the identity of victims and reporters of security incidents.

7 Authors' Addresses

Nevil Brownlee

ITSS Technology Development

The University of Auckland

Phone: +64 9 373 7599 x8941

EMail: n.brownlee@auckland.ac.nz

Erik Guttman

Sun Microsystems, Inc.

Bahnstr. 2

74915 Waibstadt Germany

Phone: +49 7263 911484

EMail: Erik.Guttman@sun.com

8 Full Copyright Statement

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有