view Side-By-Side changes
Network Working Group Yuri Demchenko
INTERNET DRAFT NLnet Labs
Category: Informational Hiroyuki Ohno
WIDE Project
Expires August December 2003 Glenn M Keeni
Cyber Solutions Inc.
February,
June, 2003
Requirements for Format for INcident Report Exchange (FINE)
<draft-ietf-inch-requirements-00.txt>
<draft-ietf-inch-requirements-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstracts
Abstract
The purpose of the Format for INcident report Exchange (FINE) is to
facilitate the exchange of incident information and statistics among
responsible Computer Security Incident Response Teams (CSIRTs) and
involved parties for reactionary analysis of current intruder
activity and proactive identification of trends that can lead to
incident prevention. A common and well-defined format will help in
exchanging, retrieving and archiving Incident Reports related information
across organizations, regions and countries.
[Page 1]
INTERNET DRAFT FINE Requirements February, June, 2003
This document describes the requirements for an Incident Report
Exchange Format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction ............................................... 2
2. Incident Handling Framework ................................ 2
3. The Goal ................................................... 7
4. General Requirements ....................................... 8
5. Format Requirements ........................................ 8
6. Communication Requirements ................................. 9
7. Content Requirements ....................................... 9
8. Security Considerations .................................... 11
9. Acknowledgements ........................................... 12
10. References ................................................. 12
11. Authors' Addresses ......................................... 13
Full Copyright Statement ....................................... 13
1. Introduction
Computer security incidents occur across administrative domains often
spanning different organizations and national borders. Therefore, the
exchange of incident information and statistics among involved
parties and the responsible Computer Security Incident Response Teams
(CSIRTs) is crucial for both reactionary analysis of current intruder
activity and proactive identification of trends that can lead to
incident prevention.
In the following we refer to the information pertaining to an
incident as an Incident Report. Actually Incident Report created and
handled by CSIRT may have internal proprietary format that is
adopted to local Incident handling procedure and used Incident
Handling System (IHS). It is intended that exchange of Incident
To facilitate the incident related information will be conducted in exchange a common well
defined format referred in this
document as Format for INcident report Exchange (FINE). is needed.
This document defines the high-level functional requirements to the
FINE intended to facilitate collaboration between CSIRTs and parties
involved when handling computer security incidents. of a
Format for INcident report Exchange (FINE).
2. Incident Handling Framework
2.1. Incident Description Terms
Expires August 2003 [Page 2]
INTERNET DRAFT FINE Requirements February, 2003
A definition of
In the following we define the main terms used in the rest of document is given
for clarity.
Where possible, existing definitions will be used; some definitions
will need additional detail and further consideration. Currently
proposed definitions this document.
There are based on well-known current definitions in the CSIRT community related documents [7, 8, 9, 10].
10, 11].
Expires December 2003 [Page 2]
INTERNET DRAFT FINE Requirements June, 2003
2.1.1. Attack
An assault on system security that derives from an intelligent
threat, i.e., an intelligent act that is a deliberate attempt
(especially in the sense of a method or technique) to evade security
services and violate the security policy of a system.
An Attack can be active or passive, by insider or active, passive. It may be perpetrated by outsider, or an
insider, an outsider or, via an attack mediator.
2.1.2. Attacker
Attacker is individual who attempts one or more attacks in order to
achieve an objective(s). attacks.
For the purpose of FINE FINE, an attacker is described by its network the
computer/network ID,
organisation from which network/computer the attack was originated and launched. The
organisation name and/or physical location information (optional). of the computer/network
are used as additional information.
2.1.3. CSIRT
CSIRT (Computer Security Incident Response Team) is used in FINE to
refer to the authority handling the Incident a team that
coordinates and creating Incident
Report. supports the response to security incidents that
involve sites within a defined constituency [7]. The CSIRT is also likely to be involved in evidence
collection generates,
processes and custody, maintains incident remedy, etc.
In FINE CSIRT represented by its ID, constituency, public key, etc. reports.
2.1.4. Damage
An
The intended or unintended consequence of an attack which affects the
normal operation of the targeted system or service. attack. Description of
damage may include free text description of actual result of attack,
and, where possible, structured information about the particular
damaged system, subsystem or service.
2.1.5. Event
An action directed at a target target, which is intended to result in a
change of state (status) of the target. From the point of view of
event origination, it can be defined as any observable occurrence in
a system or network network, which resulted in an alert being generated. For
example, three failed logins in 10 seconds might indicate a brute-
force login attack.
Expires August 2003 [Page 3]
INTERNET DRAFT FINE Requirements February, 2003
2.1.6. Evidence
Evidence is information relating to an event that proves or supports
a conclusion about the event. With respect to security incidents (the
events), it may include but is not limited to: data dump created by
Intrusion Detection System (IDS), data from syslog file, kernel
statistics, cache, memory, temporary file system, or other data that
caused the alert or were collected after the incident happened.
Special rules and care must be taken when storing and archiving
evidence, particularly to preserve its integrity. When necessary
evidence should be stored encrypted.
According to the Guidelines for Evidence Collection and Archiving [6]
evidence must be strictly secured. The chain of evidence custody
needs to be clearly documented.
It is essential that evidence should be collected, archived and
preserved according to local legislation.
2.1.7. Impact
Impact describes result of attack expressed in terms of user
community, for example the cost in terms of financial or other
disruption
2.1.8. Incident
An Incident is a security event that involves a security violation.
An incident can be defined as a single attack or a group of attacks
that can be distinguished from other attacks by the method of attack,
identity of attackers, victims, sites, objectives or timing, etc.
In the context of FINE, the term Incident is used to mean a Computer
2.1.7. Computer/Network Security Incident or an IT
A Computer/Network Security Incident.
However we should distinguish between the generic definition of
'Incident' which is an event that might lead Incident, referred to damage or damage
which is not too serious, and 'Security Incident' or 'IT Security
Incident' which are defined below:
a) Security as incident in this
work, is an event that involves a security violation.
This may be an any adverse event that violates a security policy, AUP, laws and
jurisdictions, etc. A security incident may also be an incident that
has been escalated to a security incident.
A security incident is worse than an incident as it affects the
security of or in the organisation. A security incident may be
logical, physical or organisational, for example a computer
intrusion, loss (or group of secrecy, information theft, fire or events) wherein an alarm that
doesn't work properly. A security incident may be caused on purpose attempt
Expires August December 2003 [Page 4] 3]
INTERNET DRAFT FINE Requirements February, June, 2003
has been made, successfully or by accident. The latter may be if somebody forgets to lock a door
or forgets to activate an access list in a router.
b) An IT security incident is defined according to [9] as any real or
suspected adverse event in relation otherwise, to the security compromise some aspect
of a computer system or
computer network. network security.
Typical computer security incidents within the IT area are: a computer intrusion, a
denial-of-service attack, information theft or data manipulation,
etc.
2.1.9.
2.1.8. Incident Report
In this document an Incident Report
Document describing in details Incident processed by CSIRT.
We distinguish general definition of refers to the information
pertaining to an incident. In practice, Incident report that is created
and handled by CSIRT and Report may have
internal proprietary format
adopted that is adapted to local Incident
handling procedures or defined by used
Incident Handling System, procedure and Format for INcident report Exchange
(FINE) used for exchange of Incident information between CSIRTs. Handling System (IHS).
Definition of the requirements to FINE the format for Incident Report
exchange is a the subject of this document.
2.1.10. Incident Handling System
Incident Handling System (IHS) is used by CSIRT to handle Incidents.
It may include user interface, underlying database and may
2.1.9. Target
The target of an attack. This can be
integrated with ticketing or customer service system. During Incident
investigation CSIRT may use specific tools, a logical entity( e.g. for examining log
files, mapping network addresses to Internet names and organisations,
etc., which also may be integrated into IHS.
In current document, it is suggested that IHS can produce a document
in FINE.
2.1.11. Target
A user
account, a computer process or network data, a logical entity (account, process network or data)
internetwork) or a physical entity (component, computer, network or internetwork).
2.1.12. Victim entity, e.g. (a computer interface, a
router etc.)
2.1.10. Victim is individual or organisation
The entity which suffered the attack which
is described in incident report. attack. For the purpose of FINE victim
is described by its network ID, organisation and location
information.
2.1.13.
2.1.11. Other terms
Other terms used: alert, activity, IDS, Security Policy, etc., - are
defined in related I-Ds, RFCs and standards [2, 3, 6, 7, 8, 9, 10].
2.2 The Operational Model
Expires August 2003 [Page 5]
INTERNET DRAFT FINE Requirements February, 2003
Incident Reports are generated, received and updated. For example, An
organization may send an Incident Report to a CSIRT when an attack
has been detected. Computer Security Incident Response Teams (CSIRTs)
receive Incident Reports via different channels including
Incident reports from constituency or customers, or from other CSIRTs. The
CSIRTs maintain these reports. They may process the reports to
generate statistics, or investigate the Incident further. As part of
the investigation, or as part of the reporting the CSIRT may forward
the Incident Report or parts of it to other CSIRTs. The CSIRTs may
also receive results of investigation, or additional information
related to currently active Incident from other CSIRTs.
These operations are shown in fig. 1
Expires December 2003 [Page 4]
INTERNET DRAFT FINE Requirements June, 2003
+-----
CSIRT |
+---------------------+ |
| | |
| +--------+ | |
| | | | |
| | | | Incident Report |
| |Incident|<---------|<----------------->| Customers/
| |ReportDB| | | CSIRTs/
| | |<---+ |<=== FINE ===>| Other Org
| | | | | |
| | | +------+ | |
| +--------+ |Stats | | |
| | |Pkg | | |
| | +-+--+-+ | |
| | | | | |
| +--------+ | | |
+---------------------+ |
| |
V |
Alerts, Reports |
Statistics |
+-----
Fig. 1 Operational Model for FINE
From the operational point of view during the whole life-cycle of an
Incident Report: Report the following may apply:
+ the report itself evolves;
+ the report is exchanged between CSIRT CSIRTs and can may be
investigated/processed by few CSIRTs at the same moment; multiple CSIRTs, simultaneously;
+ the changes in the report may be effected by one or more CSIRTs CSIRTs;
+ a single CSIRT may not be in a position to vouch for the veracity
of all parts of the Incident Report Report;
+ the Incident Report may exist in several states:
- complete/closed - the handling û Incident Report is not being processed and
no processing is planned
- waiting - the Incident Report is waiting on some event, in
particular case, a response from one or more CSIRTs
Also, due to the nature of the operations:
+ the various parts of an Incident Report will have information of
varying degrees of sensitivity and will need to be handled with
the appropriate level of confidentiality.
+ the Incident Report may be multilingual i.e. different parts of
the Incident Report may use different languages. It is also
possible that multiple versions of parts of the report exist,
each version in a different language. The versions may not be
consistent.
It is essential to distinguish between internal Incident Report
processing procedures and respectfully requirements to internal
Incident Report format and Incident Report participating in
information exchange between CSIRTs for different purposes, whether
itÆs aimed for cooperative investigation, specific information or
action request, or just for information or statistics, and therefore
complying to FINE.
Incident
Database <--------- Incident Reports
(Local) (in internal format)
| ^
| | FINE
| | (Exchange Format)
Expires August 2003 [Page 6]
INTERNET DRAFT FINE Requirements February, 2003
| | |
v | v
Initial Incident | Internal Incident
Incident ---> Handling | Incident ---> Exchange
Report System | Report Gateway
| (IHS) | Format (FINE)
| ^ | | | ^
| | | | |
| | | | |
| | v | |
+---------- CSIRT | | FINE
(Triage/ | | (Exchange
Operator) | | Format)
^ | |
| v |
| Other CSIRTs
+-------------------> (other parties)
Other forms of
Information
Exchange
Fig. 1 Operational Model of an
- complete/closed - the Incident Handling Procedure
Initial Report is not being processed and
no processing is planned
- waiting - the Incident Report may be based is waiting on information or request
received from some event;
From the constituency/victim, Network Operation Center,
other CSIRTs or in a form content point of Alert from automated Intrusion
Detection System. It should be noted that there is a generic
difference between "Alerts" generated by IDS (as defined in
Intrusion Description and Exchange Format (IDMEF) [5] and Incident
Reports. The IDMEF Alerts are generated by "sensors" view and processed
by managers (applications). On due to the other hand nature of operations
the following should be also considered for defining requirements to
FINE:
+ various parts of an Incident reports Report will have information of
varying degrees of sensitivity and will need to be created by human beings (although handled with
the support appropriate level of
automated IHS) and will confidentiality.
+ Incident Report may be multilingual i.e. different parts of the
Incident Report may use different languages. It is also possible
that multiple versions of parts of the report exist, each version
in a different language. The versions may not be finally consumed primarily by human
beings. consistent.
Expires December 2003 [Page 5]
INTERNET DRAFT FINE Requirements June, 2003
3. The Goal
The purpose of the Format for INcident Report Exchange (FINE) is to
facilitate the exchange of incident information and statistics among
involved parties and Computer Security Incident Response Teams
(CSIRTs) for reactionary analysis of current security incidents and
proactive identification of trends that can lead to incident
prevention. A common and well-defined format for Incident Reports
will help in exchanging, retrieving and archiving Incident Reports related
information across organizations, regions and countries.
There
The goal of the FINE format is need to
+ to make its the semantics of the report as clear and unambiguous as possible even
possible, intended for use across organizational, regional and
national boundaries;
+ to have ensure that the report (or parts of it) has a well defined syntax (at least for parts of it);
syntax;
+ to enable ensure that the structure of the report allows easy
categorization and statistical analysis;
Expires August 2003 [Page 7]
INTERNET DRAFT FINE Requirements February, 2003
+ to make it possible to ensure the verifiability of the integrity of the message, and report, a the
authenticity of the message report source.
4. General Requirements
4.1 The definition of the Format for INcident Report Exchange (FINE)
shall reference and use previously published RFCs where possible.
5. Format Requirements
5.1 FINE shall support full internationalization and localization.
A significant part of the FINE Incident Report will comprise of human-readable human-
readable text. Since some Incidents need involvement of CSIRTs from
different
countries, cultural countries and geographic regions, the FINE description must be formatted such have provisions
so that they the Incident Report can be presented to an operator in
a the local language and adhering to local presentation formats and in
accordance with local naming rules and conventions. Localized presentation of dates,
time and names may also be required.
In case, if used, the format rules and conventions.
FINE must be able have provisions to identify specify the naming rules or and conventions
that is used have been applied in the naming. Incident Report.
In cases where the messages contain text strings and names that need
characters other than Latin-1 (or ISO 8859-1), the information
preferably should
preferably be represented using the ISO/IEC IS 10646-1 character set
and encoded using the UTF-8 transformation format, and optionally
using local character sets and encodings.
In case when Incident information/data is received by party that may
not correctly display and process other encoding than UTF-8, or
information is exchanged between parties that priory known may not
process correctly non-native (but other than UTF-8) encoding, the
elements that can carry encoding sensitive information should marked
with the special attribute and/or necessary transformation should be
Expires December 2003 [Page 6]
INTERNET DRAFT FINE Requirements June, 2003
applied. Use of this attribute can be initiated by sending party, or
re-sending party that wants to preserve the specific content.
5.2 FINE must support modularity in Incident description to allow aggregation and filtering of Incident Report
data.
The structure will contain several components and some components
may be structures themselves. Each component format of a structure will FINE must be structured with components that have a well defined
well-defined syntax and semantics.
5.3 FINE must provide the possibility for recording the evolution of
an Incident Report during its whole lifetime. In particular, FINE
should contain the record of all communications that happened in
course of current Incident.
An Incident Report may evolve with time. As investigation proceeds proceeds,
it is likely that more information about an incident may will be revealed
and parts of the earlier information will be refined/obsolete. The Format for
Incident report Exchange should be able to modified/deleted. FINE
must support the record of the
evolution recording of the Incident Report these changes. changes with the level
of details defined by internal/adopted Incident Handling procedure Appropriate timestamps
identifying the epochs in the lifetime of an Incident Report should
be also possible/applied. procedure.
5.4 FINE must support the application of an access restriction policy
to individual components.
Expires August 2003 [Page 8]
INTERNET DRAFT FINE Requirements February, 2003 components of the Incident Report.
An Incident Report may potentially contain sensitive or private
information (such as passwords, persons/organisations identifiers or
forensic information (evidence data)) and in some cases may be
exposed to non-authorised persons. information. It must be
possible to define specify the degree of confidentiality for the individual
components of the Incident Report and for different roles and parties involved.
Such situations may arise particularly in case of Incident
information exchange between CSIRTs or other involved bodies.
Technical realization may include using special restriction
attributes or general external technology available with
implementation format, which Report. Applications can be applied by Incident Handling
System. Some cases may be addressed by encrypting FINE elements,
however this will not always be possible. Therefore, to prevent
accidental disclosure then implement
different levels of sensitive data, parts access restrictions, for the different components
of the FINE object
must be marked with access restriction attributes. These markings
will be particularly useful when used with automated processing
systems Incident Report.
5.5 An FINE report must be globally uniquely identifiable.
It should be possible to refer to an Incident Report unambiguously
using the globally unique identifier. It should also be possible to
map the origin/creator of an Incident Report from its globally unique
identifier.
5.6. The Format for Incident report Exchange itself must be
extensible. The extension will be in terms of addition of components
and/or extending the components.
6. Communication Mechanisms Requirements
6.1.
6.1 The communication mechanisms must have no bearing on the
authenticity, integrity, and confidentiality of a FINE formatted
Incident Report. Provisions for authenticity, integrity and
confidentiality should be made in FINE.
Incident Report exchange will normally be initiated by humans conducted using standard
communication protocols and exchange mechanisms, for example, e-mail,
HTTP, FTP, XML Web Services, FTP, etc. FINE must not rely on communication
mechanisms or specific applications to satisfy requirements of current
document. The communication mechanisms must have no bearing on the ensure authenticity, integrity, and integrity
and/or confidentiality of the an Incident Report
itself. Communications security requirements may be applied
separately according to local policy so are not defined by this
document. Report.
Expires December 2003 [Page 7]
INTERNET DRAFT FINE Requirements June, 2003
7. Content Requirements
7.1 FINE must be flexible enough to support various degrees of
completeness. At the same time it must clearly state the minimal
information without which the information in the Incident Report will
be seriously degraded.
7.1
7.2 FINE must contain information about the various entities involved
in the incident. An Incident Report will generally refer to one or
more entities. The entity may be an the attacker, a victim perpetrator, victim,
or an observer.
7.3 FINE should support the description of various aspects/details of
the entities involved in the incident. There are may be several facets of
an entity involved in an Incident
Expires August 2003 [Page 9]
INTERNET DRAFT FINE Requirements February, 2003 Report. The entity may have zero or
more network addresses and names as well as zero or more location
names, organizational name, names, person names, machine names etc. etc..
7.4 FINE should support various facets
describing the entities involved.
7.2 The Incident Report should contain the type description of the method how the attack if
it's known.
FINE must support well-known classification/enumeration schemes. It
is expected that this type will be drawn from a standardized list of
events/attacks; a new type of
or security event may use a temporary
implementation- specific type was conducted if the event type has not yet been
standardized.
Incident handling may involve many different staff members and
teams. It is therefore essential that common terms are used to
describe incidents. If the event type has not yet been standardized,
temporary type definition might be given by team created Incident
Report. It it is expected that new type name will known.
Well-known classification/enumeration schemes should be self-explanatory
and derived from a similar, existing used to
describe the type definition.
7.3. of attack or vulnerabilities and exposures caused
particular Incident or security Event.
7.5 FINE must include the Identity identity of the creator (or current owner)
of the Incident Report (CSIRT or other authority). This may be the
sender in an information exchange or the team currently handling the
incident.
The identity of Incident description creator is often valuable
information for Incident response. In one possible scenario the
attack may progress through the network, comparison of corresponding
incidents reported by different authorities might provide some
additional information about the origin of the attack. This is also
useful information at post-incident information handling/exchange
stage.
7.4 The FINE should contain information about the attacker and
victim, if known.
7.5 The
7.6 FINE should contain reference to advisories corresponding to the
Incident Report, e.g. CERT/CC, CVE, and others.
7.6 The FINE should contain a detailed description of the attack
that caused the current Incident. In particular, FINE should contain
information about AttackerÆs and VictimÆs systems participated or
targeted in that Attack.
7.7 The FINE may contain a description of the incident Incident or comprising
security events in a natural language.
7.8 The Incident Report FINE should contain or be able provide the possibility to include or reference
additional detailed information/data related to this the specific
underlying event(s)/activity, often referred as evidence.
Expires August 2003 [Page 10]
INTERNET DRAFT FINE Requirements February, 2003 event(s)/activity.
This information may include IDMEF [5] messages, which have been
generated by security devices.
7.9 The Incident Report FINE should describe provide the Impact on possibility for describing the target, if
known. impact of
an incident.
There should be guidelines to describe the impact on the target
to ensure a uniform interpretation of the description.
The value of this field should be drawn from a standardized list of
values if the attack is recognized as known, or expressed in a free
language by responsible CSIRT team member.
7.10 The Incident Report should describe the actions taken since the
occurrence of the incidence. incident.
7.11 Time shall be reported as the local time and time zone offset
from UTC. (Note: See RFC 1902 for guidelines on reporting time.)
Expires December 2003 [Page 8]
INTERNET DRAFT FINE Requirements June, 2003
Internal Incident Report may contain local presentation of time
related information, however FINE must provide support unambiguous time
presentation. For event correlation purposes, it is important that
the manager be able to normalize the time information reported in
the FINE descriptions.
specification. In case when normalization of the time information is
not possible (like in case of referencing additional data about the
Incident that cannot be changed, e.g. timestamped log
data), the time offset should be mentioned.
7.12 Time granularity in FINE time parameters shall not be specified
by the FINE.
The time data may be included into FINE description by existing
information systems, retrieved from incident reporting messages or
taken from IDS data or other event registration tools. Each of
these cases may that cannot be changed, e.g. timestamped log data), the time
offset should be mentioned.
7.12 FINE will not have its own any specific requirement for granularity of
time.
Different systems will support different time granularity. For the
purposes of implementation, it granularities. FINE
should be possible able to handle support Incident Reports from various systems
irrespective of their time at
different stages according to the local system capabilities. granularity.
7.13 The Incident Report FINE should allow the application of (external) external mechanisms or assertions to assure its
support authenticity, integrity and non-repudiation can be verified.
7.14 The semantics checks of
Incident Reports.
7.14 FINE must be well defined. The various
components of FINE should have a well defined semantics.
8. Security Considerations
This memo does not describe a protocol by itself. This memo describes
the requirements for an Incident Report Exchange Format. The reports
themselves are about security incidents. The contents of the Incident
Reports will have significant direct and/or indirect impact on the
security and privacy of a network and/or individuals.
Expires August 2003 [Page 11]
INTERNET DRAFT FINE Requirements February, 2003 FINE
implementers should take care to analyze and implement the
requirements stated in 5.5 and 7.12.
9. Acknowledgments.
The precursor of this document is "TERENAÆs "RFC3067 TERENAÆs Incident Object
Description Exchange Format Requirements" [RFC3067] [2] which is based on the
work done at Incident Object Description Exchange Format Working
Group at TERENA. Subsequent work and discussion has been carried out
in the INCH-WG and in the WIDE-WG on Network Management and Security.
10. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] Arvidsson, J., Cormack, A., Demchenko, Y., Meijer J. "TERENA's
Incident Object Description and Exchange Format Requirements", RFC
3067, February 2001
Expires December 2003 [Page 9]
INTERNET DRAFT FINE Requirements June, 2003
[3] Incident Object Description and Exchange Format Data Model and
Extensible Markup Language (XML) Document Type Definition û October
2002. Work in progress.
[4] Taxonomy of the Computer Security Incident related terminology -
http://www.terena.nl/task-forces/tf-csirt/iiodef/docs/i-
taxonomy_terms.html
[5] Intrusion Detection Exchange Format Requirements by Wood, M. -
October 2002, Work in Progress.
[6] Guidelines for Evidence Collection and Archiving by Dominique
Brezinski, Tom Killalea û BCP 55, RFC 3227, February 2002.
[7] Brownlee, N. and E. Guttman, "Expectations for Computer Security
Incident Response", BCP 21, RFC 2350, June 1998.
[8] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
2000.
[9] Establishing a Computer Security Incident Response Capability
(CSIRC). NIST Special Publication 800-3, November, 1991
[10] Handbook for Computer Security Incident Response Teams
(CSIRTs), Moira J. West-Brown, Don Stikvoort, Klaus-Peter
Kossakowski. - CMU/SEI-98-HB-001. - Pittsburgh, PA: Carnegie Mellon
University, 1998.
[11] A Common Language for Computer Security Incidents by John D.
Howard and Thomas A. Longstaff. - Sandia Report: SAND98-8667, Sandia
Expires August 2003 [Page 12]
INTERNET DRAFT FINE Requirements February, 2003
National Laboratories -
http://www.cert.org/research/taxonomy_988667.pdf
11. AuthorsÆ Addresses:
Yuri Demchenko
NLnet Labs Labs, The Netherlands
Email: demch@chello.nl
Hiroyuki Ohno
WIDE Project, Japan
Email: hohno@wide.ad.jp
Glenn Mansfield Keeni
Cyber Solutions Inc.
Sendai, Japan
Email: glenn@cysols.com
Expires December 2003 [Page 10]
INTERNET DRAFT FINE Requirements June, 2003
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Appendix û non-normative
Major Changes (reverse count)
Information about changes to the document since publishing û00
version will be documented here.
Major changes in version û01
1) clarified definition of some terms û still in the process, needs
more discussion with concerned parties.
2) re-written section 2. Operational model
3) added text about multilingual support for non-utf-8 character sets
to item ô5.1 FINE shall support full internationalization and
localizationö û results of discussion at IETF-56
4) included clear statement about unique identification of the
Incident Report to item ô5.1 FINE shall support full
internationalization and localization.ö
5) added item about the possibility of Incident description in
natural language:
Expires August December 2003 [Page 13] 11]
INTERNET DRAFT FINE Requirements February, June, 2003
Appendix û non-normative
Major Changes (reverse count)
7.7 The FINE may contain a description of the Incident or comprising
security events in a natural language.
6) requirement about describing impact of the Incident extended (item
7.9) with recommendation to provide guidelines to describe the impact
on the target to ensure a uniform interpretation of the description.
7) item 7.11 about time normalization extended with the possibility
to describe time offset when normalization is not possible.
Expires August December 2003 [Page 14] 12]
----