view Side-By-Side changes
Network
INCH Working Group Yuri Demchenko
INTERNET DRAFT
Internet Draft University of Amsterdam
Category: Informational Hiroyuki Ohno
WIDE Project
Expires April 2004
Expires: August 6, 2005 Glenn M Keeni
Cyber Solutions Inc.
October, 2003
Fenruary 7, 2005
Requirements for the Format for INcident information Exchange (FINE)
<draft-ietf-inch-requirements-02.txt>
<draft-ietf-inch-requirements-03.txt>
Status of this Memo
This document is an Internet-Draft
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and is any of which we become aware will be
disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026. RFC 3668.
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 are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo
http://www.ietf.org/shadow.html"
This document is unlimited. a product of the inch Working Group. Comments should
be addressed to the authors or the mailing list at
inch@nic.surfnet.nl
This Internet-Draft will expire on August 6, 2005
Copyright Notice
Copyright (C) The Internet Society (2001). (2005). All Rights Reserved.
Expires: August 6, 2005 [Page 1]
Internet Draft February 7, 2005
Abstract
The purpose of the Format for INcident 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 parties. FINE can be used 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 the exchange of Incident related information across
organizations, regions and countries.
[Page 1]
INTERNET DRAFT FINE Requirements October, 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 3
2. Incident Handling Framework ................................ 3
3. The Goal ................................................... 6
4. General Requirements ....................................... 6
5. 5
4. Format Requirements ........................................ 6
6.
5. Communication Mechanism Requirements ................................. ....................... 7
7.
6. Content Requirements ....................................... 7
8.
7. Security Considerations .................................... 9 8
8. IANA Considerations ........................................ 8
9. Acknowledgements ........................................... 9
10. References ................................................. 9
10. Acknowledgements ........................................... 10
11. Authors' Addresses ......................................... 10
Full Copyright Statement ....................................... 11
Appendix: History of Changes
Expires: August 6, 2005 [Page 2]
Internet Draft February 7, 2005
1. Introduction
Computer security incidents occur across administrative domains domains,
often spanning different organizations and national borders. Therefore, the
exchange of incident information Hence,
a distributed response requiring coordination and statistics among collaboration
between the involved parties and the responsible Computer Security
Incident Response Teams (CSIRTs) is crucial are often required to respond to
these threats. The basis for both reactionary analysis of current intruder
activity this interaction is various data and proactive identification of trends that can lead to
incident prevention.
In
statistics describing the following we refer to nature of the information pertaining incident. This information,
referred to an
incident as an Incident Report.
Definition of a common well defined format to Incident Reports will
facilitate incident related information exchange across organizations,
regions and countries by achieving these particular goals:
+ to make the semantics of the report as clear and unambiguous as
possible, intended for use across organizational, regional and
national boundaries;
+ in this document, supports response
activity to ensure that the report (or parts specific incident, but may also inform historical
analysis or proactive responses.
This document merely defines the high-level functional requirements
for a transport format to exchange incident reports. This abstract
data representation, the Format for INcident report Exchange (FINE),
is not specified.
The intent of FINE is to decrease the response time to incidents and
facilitate by improving the ability of CSIRTs to process incident
reports. The definition of a well-defined format will facilitate the
exchange of incident reports across organizations, regions and
countries by achieving these particular goals:
+ to make the semantics of it) the report as clear and unambiguous;
+ to ensure that the data has a well defined syntax;
+ to ensure that the structure of the report allows easy
categorization and statistical analysis;
+ to ensure the verifiability of the integrity of the report, a
and the authenticity of the report source.
Expires April 2004 [Page 2]
INTERNET DRAFT FINE Requirements October, 2003
This
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document defines the high-level functional requirements of a
Format for INcident report Exchange (FINE). are to be interpreted as described in BCP
14, RFC 2119 [RFC2119].
2. Incident Handling Framework
2.1. Incident Description Descriptive Terms
For the purpose of clarify, clarity, certain commonly used terms from the
operational domain of CSIRTs are defined here. These are based on
related documents [7, 8, 9, 10, 11]
2.1.1. Attack
One or more steps taken by an attacker to achieve an unauthorised result.
An Attack can be active, passive. Event
An attack may be successful.
2.1.2. Attacker
Attacker event is an entity that attempts one occurrence in a system or more attacks. network that may be of
interest and warrant attention. An attacker event may or may not be an insider, an outsider, malicious
or an entity acting via
an deliberate.
Expires: August 6, 2005 [Page 3]
Internet Draft February 7, 2005
2.1.2. Attack
An attack mediator. For is a series of events caused either directly or indirectly
by a source that violates a security policy of the purpose target. These
violations may include a compromise of a user account, denial-of-
service, information theft, etc.
2.1.3. Source
The origin of FINE, an attacker is attack as described by the computer/network ID, from which the attack was launched. a host, user account,
computer program, network address, person, or organization.
2.1.4. Target
The
organization name and/or physical location target of the computer/network
are used an attack as additional information.
2.1.3. CSIRT
CSIRT (Computer Security Incident described by a host, user account,
computer program, network address, person, or organization.
2.1.5. Computer security incident
A computer security incident, referred to as incident, is a set of
one or more related attacks identified by a CSIRT.
2.1.6. CSIRT
A Computer Security Incident Response Team) Team, CSIRT, is an individual
or a team group of individuals that
coordinates coordinate and supports support the response to security
incidents that
involve sites within in a defined constituency [7]. The A CSIRT generates,
processes creates, processes,
and maintains incident reports.
2.1.4. Damage
The intended or unintended consequence of an attack. Description of
damage may include a free text description of the actual result of an
attack, and, where possible, structured information about the
particular damaged system, subsystem or service.
2.1.5. Event
An occurrence in a system or network, which maybe of interest and/or
warrants attention. An event may indicate an attack. An event may
also indicate an error or a fault or the result of a deliberate act
that is not an attack. For example, the occurrence of three failed
logins in 10 seconds is an event. It might indicate a brute- force
login attack. A program failure, network fault, system shutdown are
other examples of event.
Expires April 2004 [Page 3]
INTERNET DRAFT FINE Requirements October, 2003
2.1.6. Impact
2.1.7. Impact
An impact describes the result consequence of an attack incident on a target
expressed in terms of user
community, for example the cost in terms of financial or other
disruption
2.1.7. Computer/Network Security Incident
A Computer/Network Security Incident, referred relevant to as incident in this
work, is a set of one or more events. The events in the incident may
indicate attacks. There may be incidents which comprise of events
which are not indicative of attacks.
Typical computer security incidents are: a computer intrusion, a
denial-of-service attack, information theft or data manipulation, etc. user community.
2.1.8. Incident Report
In this document an Incident Report refers to the information
pertaining to an incident. In practice, an Incident Report may have
some internal proprietary format that
An incident report is adapted to the local
Incident Handling System (IHS) and Incident handling procedures.
Definition collection of the requirements to the format for Incident Report
exchange is the subject of this document.
2.1.9. Source
The source of an attack. This can be a logical entity (e.g. a user
account, a computer process or data, a logical network or
internetwork) or a physical entity (e.g. a computer interface, a
router etc.).
2.1.10. Target
The target of information describing an attack. This can be a logical entity( e.g. a user
account, a computer process or data, a logical network or
internetwork) or a physical entity, e.g. (a computer interface, a
router etc.)
2.1.11. Victim
The entity which suffered the attack. For the purpose of FINE a
victim is described by its network ID, organization and location
information.
2.1.12. Other terms
Other terms used: alert, activity, IDS, Security Policy, etc., - are
defined in related I-Ds, RFCs, standards and documents[2, 3, 6, 7, 8,
9, 10].
Expires April 2004 [Page 4]
INTERNET DRAFT FINE Requirements October, 2003
incident.
2.2 The Operational Model
Incident Reports reports are generated, received and updated. For example, An an
organization may send an Incident Report incident report to a CSIRT when an attack
has been detected. Computer Security
Incident Response Teams (CSIRTs) Team (CSIRT) when an attack is detected. CSIRTs
receive Incident Reports incident reports from customers, customers or from other CSIRTs. The
CSIRTs maintain these reports. They reports in an Incident Report Database in some
format that may be specific to the CSIRT. The CSIRTs may process the
reports to generate statistics, or investigate the Incident an incident further.
As part of the investigation, investigation or as part of the reporting reporting, the CSIRT
may forward the Incident Report 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 incidents from other CSIRTs.
In the context of FINE, the incident reports will be handled by a
CSIRT via an interface that is capable of converting a FINE formatted
Expires: August 6, 2005 [Page 4]
Internet Draft February 7, 2005
incident report into the internal format used by the CSIRT and vice
versa.
These operations are shown in fig. 1
+-----
CSIRT |
+---------------------+
+------------------+ +------------------+
| | | |
| +--------+ +---------+ +---------+ +--------+ |
| | |<--|Interface|<--Incident-->|Interface|-->| | |
| |Incident| +---------+ Report +---------+ |Incident| |
| | | | Incident Report | | |Incident|<---------|<----------------->| Customers/ | |ReportDB| | Report | CSIRTs/ |
| |Database| | |<=== |=== FINE ===>| Collaborators/ ===| | |Database| |
| | | Involved parties | | | | |
| +--------+ | | +--------+ |
| | | | |
| | |
| | |
+---------------------+ +-----
+------------------+ +------------------+
Fig. 1 Operational Model for FINE
From the operational point of view during the life-cycle of an
Incident Report
incident report the following may apply:
+ the report itself evolves. It may exist in one of the following
states:
- handling – - the Incident Report incident report is being handled
- complete/closed - the Incident Report is not being incident report has been processed
and no further processing is planned
- waiting - the Incident Report incident report is waiting on some event;
+ the report is exchanged between CSIRTs and may be
investigated/processed by multiple CSIRTs, simultaneously;
Expires April 2004 [Page 5]
INTERNET DRAFT FINE Requirements October, 2003
+ additions and/or changes to the report may be effected made by one or
more CSIRTs. So Therefore, a single CSIRT may not be in a position
to vouch for the veracity of all parts of the Incident Report,
3. The Goal. This section is eliminated but left as a placeholder until
final review
4. General Requirements
4.1 The definition of the Format for INcident Report Exchange (FINE)
shall incident report.
3. General Requirements
3.1 FINE SHALL reference and use previously published RFCs where
possible.
5.
3.2 FINE MUST have well defined semantics and provide a standard
Expires: August 6, 2005 [Page 5]
Internet Draft February 7, 2005
mechanism for extensibility.
The values of the various components of FINE should be typed, and the
meaning should be well specified. Likewise, there should be a
standardized method to deal with the representing data not defined in
the data model.
4. Format Requirements
5.1
4.1 FINE shall SHALL support full internationalization and localization.
A significant part of the Incident Report incident report will comprise be comprised of human- human
readable text. Since some Incidents need incidents will entail involvement of CSIRTs
from different countries and geographic regions, FINE must have
provisions
so that the Incident Report can be presented in the local language in
accordance with local rules and conventions.
FINE must have provisions to specify the naming rules and conventions
that have been applied in the 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 should
preferably be represented using the ISO/IEC IS 10646-1 character set
and encoded using the UTF-8 transformation format, and optionally for using local character sets and encodings.
In cases where local (non-standard) character sets and encodings are
used, the elements that carry encoding sensitive information should
be clearly indicated. It should be possible to preserve the content
of these elements when transferring an Incident Report.
5.2 incident report.
4.2 FINE must MUST allow multilingual reports.
Different parts of the incident report may be written in a different
language. Likewise, multiple versions of the same part of the report
may exist, each in a different language.
4.3 FINE MUST support aggregation and filtering of Incident Report incident report data.
The format of FINE must be structured with components that have a
well-defined syntax and semantics.
5.3 For example, an application may
want to generate the number of 'scan's that originated from a given
network. FINE must provide the possibility for recording support such filtering and aggregation.
4.4 FINE MUST be able to document the evolution of an Incident Report during its lifetime. incident.
An Incident Report incident report may evolve with time. As time, as further investigation proceeds,
it is likely that more information about an
performed on the incident will report. Earlier information may be revealed
modified and parts of the earlier new information will may be modified/deleted. added. FINE must support the
recording of these changes. changes with the level
of details defined by internal/adopted Incident Handling procedure.
Expires April 2004 [Page 6]
INTERNET DRAFT FINE Requirements October, 2003
5.4
4.5 FINE must MUST support the application of an specifying a granular access restriction policy
to individual components
for the specific elements of the Incident Report. incident report.
Various parts of an Incident Report incident report will have information of varying
degrees of sensitivity and will need to be handled with the
appropriate level of confidentiality. It must be possible to specify
the degree of confidentiality for the individual components of the
Incident Report.
Expires: August 6, 2005 [Page 6]
Internet Draft February 7, 2005
incident report. Applications can then implement different levels of
access restrictions, restrictions for the different components of the Incident incident
Report.
5.5
4.6 FINE must support globally unique identifiers for the exchanged
Incident reports.
It should be possible to refer to an Incident Report unambiguously
using the globally unique identifier. It should also be possible to
map SHOULD allow the origin/creator application of an Incident Report from its globally unique
identifier.
5.6. FINE must have a well defined semantics external mechanisms to
support authenticity, integrity, and provide a standard
way for extensibility in terms of addition non-repudiation checks of components and/or
extending the components.
5.7. FINE must allow multilingual
incident reports. In case there are multiple
language versions of a component of the report, the versions should
be consistent and, and
FINE itself need not guarantee authenticity, integrity, or non-
repudiation. However, the specification must provide detail a way standardized
mechanism to identify which
version is authentic.
An 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.
6. ensure these properties.
5. Communication Mechanisms Mechanism Requirements
6.1
5.1 The communication mechanisms must MUST NOT have no any bearing on the
authenticity, integrity, and confidentiality
security of a FINE formatted
Incident Report. Provisions for authenticity, integrity and
confidentiality should be made in FINE. incident report.
Incident Report report exchange will normally be conducted using standard
communication protocols and exchange mechanisms, for example, e-mail,
HTTP, FTP, XML Web Services, etc. FINE must not rely on communication
mechanisms or specific applications to ensure authenticity, integrity
and/or confidentiality of an Incident Report.
7. incident report. Provisions for
authenticity, integrity and confidentiality should be made in FINE.
6. Content Requirements
7.1
6.1 FINE must MUST be flexible enough to support various degrees of
completeness. At the same time it must
completeness, while still clearly state defining the minimal
Expires April 2004 [Page 7]
INTERNET DRAFT FINE Requirements October, 2003
information without which the
information in the Incident Report will
be seriously degraded.
7.2 required for describing an incident.
6.2 FINE must contain information about MUST support globally unique identifiers for each incident
report.
It should be possible to reference an incident report unambiguously
using a globally unique identifier. It should be possible to derive
the various entities involved
in creator of the incident. An Incident Report will generally refer to one or
more entities. The entity may be incident report from this identifier.
6.3 FINE MUST support the attacker, perpetrator, victim,
or an observer.
7.3 naming of the source and target.
6.4 FINE should SHOULD support the description of various aspects/details aspects of the entities involved in the incident. There may be several facets of
an entity involved in an Incident Report. The entity may have zero or
more network addresses
source and names as well as zero or more location
names, organizational names, person names, machine names etc..
7.4 target.
6.5 FINE should SHOULD contain the a description of the method how methodology used in
the attack
or security event was conducted if it is known. attacker.
Expires: August 6, 2005 [Page 7]
Internet Draft February 7, 2005
Well-known classification/enumeration classifications or enumeration schemes should be used to
describe the type of attack or exploited vulnerabilities and exposures that caused
particular Incident or security Event.
7.5 the
incident.
6.6 FINE must MUST include the identity of the creator of the Incident
Report (CSIRT or other authority). incident
report.
FINE should indicate the source of each component of the Incident Report incident
report if it’s is different from the
creator.
The source of a component of the Incident Report may be the creator
of the Incident Report, (e.g., the team handling the incident or, some other
party.
7.6
incident).
6.7 FINE should provide SHOULD support the possibility to include including or reference
additional detailed information/data referencing information
external to the incident report.
This information may include IDMEF [5] messages, which have been
generated by security devices.
7.7
6.8 FINE may contain a MUST support natural language description descriptions of the Incident
or related security events.
7.8 incident.
6.9 FINE should contain SHOULD support references to the appropriate advisories,
wherever applicable, corresponding to the related events , e.g.
CERT/CC, CVE, etc.
7.9 advisories
from coordination and analysis centers.
6.10 FINE should SHOULD provide the possibility for describing the impact of
an incident.
There should be guidelines to describe the impact on the target
to ensure a uniform interpretation of the description.
7.10 The Incident Report should describe the actions taken since the
occurrence of the 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 April 2004 [Page 8]
INTERNET DRAFT FINE Requirements October, 2003
Internal Incident Report may contain local presentation of time
related information, however incident
report.
6.11 FINE must SHOULD support unambiguous time
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. time-stamped log data), describing the actions taken during the
course of handling an incident.
6.12 FINE SHOULD use a standardized time offset specification.
Incident reports should be mentioned.
7.12 FINE will not have any specific requirement for granularity of
time. represent time in such a way that it is
possible to easily compare information reported from different
timezones.
Different systems will support different time granularities. FINE
should be able to support Incident Reports incident reports from various systems
irrespective of their time granularity.
7.13 FINE should allow the application of external mechanisms to
support authenticity, integrity and non-repudiation checks of
Incident Reports.
8.
7. 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
There are about no explicit security incidents. The contents considerations for this document since
no protocol or information model is specified. However, a number of the Incident
Reports will have significant direct and/or indirect impact on the
security and privacy of a network and/or individuals. relevant requirements are outlined for FINE implementers.
By its nature, FINE will represent sensitive information. Hence,
implementers should take care to analyze and implement the
requirements regarding ensure support for access restriction policy as stated in 5.4
(requirement 4.5); transport agnostic security guarantees
(requirement 5.1); and
requirements regarding support of external mechanisms for
authenticity, integrity confidentiality, integrity, and non-repudiation 7.13.
9. Acknowledgments.
The precursor of this non-
repudiation (requirement 4.8).
Expires: August 6, 2005 [Page 8]
Internet Draft February 7, 2005
8. IANA Considerations
This document is "RFC3067 TERENA's Incident Object
Description Exchange Format Requirements" [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. requires no action from IANA.
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
9.2 Informative References
[2] Arvidsson, J., Cormack, A., Demchenko, Y., Y. and Meijer J. J.,
"TERENA's Incident Object Description and Exchange Format
Requirements", RFC 3067, February 2001
Expires April 2004 [Page 9]
INTERNET DRAFT FINE Requirements October, 2003
[3] Incident Meijer, J., Danyliw, R. and Demchenko, Y., "Incident Object
Description and Exchange Format Data Model and Extensible Markup
Language (XML) Document Type Definition October
2002. Work Definition", work in progress. progress (currently
<draft-ietf-inch-iodef-03.txt>).
[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 Wood, M., "Intrusion Detection Exchange Format Requirements by Wood, M. -
October 2002, Work Requirements",
work in Progress. progress (currently <draft-ietf-idwg-requirements-12.txt>).
[6] Guidelines Brezinski, D., Killalea, T., "Guidelines for Evidence
Collection and Archiving by Dominique
Brezinski, Tom Killalea - Archiving". 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 "Establishing a Computer Security Incident Response Capability
(CSIRC).
(CSIRC)", NIST Special Publication 800-3, November, November 1991
[10] Handbook West-Brown, M., Stikvoort, D., Kossakowski, K., Killcrece G.,
Ruefle, R., Zajicek, M., "Handbook for Computer Security Incident
Response Teams (CSIRTs),
Moira J. West-Brown, Don Stikvoort, Klaus-Peter Kossakowski. -
CMU/SEI-98-HB-001. - Pittsburgh, PA: (CSIRTs)", CMU/SEI-98-HB-002, Carnegie Mellon
University, 1998. Pittsburgh, PA, April 2003.
Expires: August 6, 2005 [Page 9]
Internet Draft February 7, 2005
[11] A Howard, J. and Longstaff, A., "A Common Language for Computer
Security Incidents by John D.
Howard and Thomas A. Longstaff. - Incidents", Sandia Report: SAND98-8667, Sandia National Laboratories -
http://www.cert.org/research/taxonomy_988667.pdf
Laboratories, October 1998.
10. Acknowledgments.
The precursor of this document is "RFC3067 TERENA's Incident Object
Description Exchange Format Requirements" [2] which is based on the
work done at Incident Object Description Exchange Format Working
Group at TERENA. Subsequent work and discussion have been carried
out in the INCH-WG and in the WIDE-WG on Network Management and
Security.
The following individuals, in alphabetic order, have made substantial
contribution to this document
Hiroyuki Kido
Kathleen M. Moriarty
Roman Danyliw
11. Authors' Addresses:
Yuri Demchenko
University of Amsterdam, 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 April 2004
Expires: August 6, 2005 [Page 10]
INTERNET DRAFT FINE Requirements October, 2003
Internet Draft February 7, 2005
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Expires: August 6, 2005 [Page 11]
Internet Draft February 7, 2005
Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property
Intellectual Property Rights 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 nor does it
represent that it has made any independent effort to identify any
such rights. Information on the
IETF's procedures with respect to
rights in standards-track and
standards-related documentation RFC documents can be found in BCP-11. BCP 78 and BCP 79.
Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat 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. on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which that may cover technology that may be required
to practice implement this standard. Please address the information to the
IETF Executive
Director.
Acknowledgement at ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expires: August 6, 2005 [Page 12]
Internet Draft February 7, 2005
Appendix - non-normative non-normative.
Major Changes (reverse count)
Information about changes to the document since publishing -00
version will be documented here.
Major changes in version -03 (Second revision)
1) title changed to
Requirements for the Format for INcident information Exchange
(FINE)
2) editorial nits
3) RFC2119 key words used
4) added description to 4.6
5) reformatted 4.7 and 5.1 to have single statement requirements
followed by description of the requirements.
6) added an example to 4.2
7) moved 6.13 to Format requirements as 4.8
8) updated references #3, #5, #10
9) updated section 2.2
Major changes in version -03 (First revision)
1) editorial nits
2) in Security Considerations section an example is added to explain
the impact of the contents of the IR on the security and privacy
of individuals of organization.
3) Section 3 is deleted
Major changes in version -02
1) clarified definitions of some terms. Added a few definitions.
2) in 5.1, added requirement for handling non-standard/local
encoding and/or character codes.
3) in 5.7, added requirement that multiple versions of the report
should be consistent
4) in 7.5, added requirement that the source of each component of
the Incident Report report must be identified (if different from the
creator of the Incident Report). report).
5) some editorial nits are fixed.
Expires April 2004 [Page 11]
INTERNET DRAFT FINE Requirements October, 2003
Major changes in version -01
1) clarified definition of some terms - still in the process, needs
more discussion with concerned parties.
Expires: August 6, 2005 [Page 13]
Internet Draft February 7, 2005
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 report to item "5.1 FINE shall support full
internationalization and localization."
5) added item about the possibility of Incident description in
natural language:
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 April 2004
Expires: August 6, 2005 [Page 12] 14]
----