view Side-By-Side changes
INCH Working Group Yuri Demchenko
Internet Draft University of Amsterdam
Category: Informational Hiroyuki Ohno
WIDE Project
Expires: November February 6, 2005 2006 WIDE Project
Roman Danyliw
CERT/CC
Glenn M Keeni
Cyber Solutions Inc.
May
September 7, 2005
Requirements for the Format for INcident information Exchange (FINE)
<draft-ietf-inch-requirements-04.txt>
<draft-ietf-inch-requirements-05.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html"
http://www.ietf.org/shadow.html
This document is 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 November February 6, 2005 2006
Copyright Notice
Expires: February 6, 2006 [Page 1]
Internet Draft September 7, 2005
Copyright (C) The Internet Society (2005). All Rights Reserved.
Expires: November 6, 2005 [Page 1]
Internet Draft May 7, 2005
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. 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 the exchange of Incident
related information across organizations, regions and countries.
FINE will also be useful for reactionary analysis of current security
incidents and proactive identification of trends that can lead to
incident prevention. This document describes the high-level
functional requirements for an Incident Report Exchange Format.
Table of Contents
1. Introduction ............................................... 3
2. Incident Handling Framework ................................ 3
3. General Requirements ....................................... 5
4. Format Requirements ........................................ 6
5. Communication Mechanism Requirements ....................... 7
6. Content Requirements ....................................... 7
7. Security Considerations .................................... 8
8. IANA Considerations ........................................ 8
9. References ................................................. 9
10. Acknowledgements ........................................... 10
11. Authors' Addresses ......................................... 10
Full Copyright Statement ....................................... 11
Appendix: History of Changes
Expires: November February 6, 2005 2006 [Page 2]
Internet Draft May September 7, 2005
1. Introduction
Computer security incidents occur across administrative domains,
often spanning different organizations and national borders. Hence,
a distributed response requiring coordination and collaboration between the
involved parties and the responsible Computer Security Incident
Response Teams (CSIRTs) are is often required to respond to
these threats. required. The basis for this
interaction is often the various data and statistics describing the
nature of the incident. This information, referred to as an incident
report in this document, supports response activity to the specific
incident, but may also inform be used for historical analysis or proactive
responses.
This document merely defines the high-level functional requirements for a transport
format to that would support the exchange of incident reports. This The
abstract
data representation, format being discussed is referred to as the Format for
INcident report Exchange (FINE), (FINE). The implementation of the
requirements, the format itself is not specified. provided in this document.
The intent of FINE is to decrease the enable quick and effective response time to
incidents and
facilitate by improving the ability of CSIRTs to exchange and process
incident reports. The definition of a well-defined format This will facilitate the
exchange of incident reports across organizations, regions and
countries be achieved by achieving these particular goals: ensuring that FINE
+ to make makes the semantics of the report as clear and unambiguous;
+ to ensure that ensures the data has a well defined syntax; and
+ to ensure that the structure of the report allows supports easy categorization and statistical analysis;
+ to ensure the verifiability of the integrity of the report,
and the authenticity of the report source. analysis.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [RFC2119].
2. Incident Handling Framework
2.1. Descriptive Terms
For the purpose of 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. Event
An event is an occurrence in a system or network that may be of
interest and warrant attention. An event may or may is not be necessarily malicious
or deliberate.
Expires: November 6, 2005 [Page 3]
Internet Draft May 7, 2005
2.1.2. Attack
An attack is a series of events caused either directly or indirectly
by a source that violates a the security policy of the target. These
violations may include a compromise of a user account, denial-of-
service, information theft, etc.
Expires: February 6, 2006 [Page 3]
Internet Draft September 7, 2005
2.1.3. Source
The origin of an attack as described by a host, user account,
computer program, network address, person, or organization.
2.1.4. Target
The target of an attack as 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. Incident Report
An incident report is the collection of information describing an
incident.
2.1.7. CSIRT
A Computer Security Incident Response Team, CSIRT, is an individual
or a group of individuals that has the responsibility to coordinate
and support the response to incidents in a defined constituency [7].
A CSIRT creates, processes, receives, processes and maintains incident reports.
2.1.7.
2.1.8. Impact
An impact describes the consequence of an incident on a target
expressed in terms relevant to a user community.
2.1.8. Incident Report
An incident report is the collection of the information describing an
incident.
2.2 The Operational Model
Incident reports are an important subset of information exchanged
between a CSIRT and its constituency and or other CSIRTs. These reports
form the basis for resolving and understanding activity in a
constituency. A CSIRT may create an incident report when information an incident
is reported to it. A CSIRT reported; or may also receive incident reports from its constituency or from
another CSIRT. from, and send them to,
other CSIRTs. As analysis is performed and investigation occurs, progresses,
more information about an incident may be discovered causing updates
to previously sent incident reports to be exchanged.
Surrounding the
The creation and exchange of incident reports is often driven by a
work-flow process to prioritize that prioritizes and manage manages the information flow
in the CSIRT. These systems often associate CSIRT analysts personnel with
particular incidents or tag maintain status onto a particular
investigation. FINE does not address these provide a representation issues.
Expires: November 6, 2005 [Page 4]
Internet Draft May 7, 2005 for these
internal processes.
FINE serves as the external is a representation for the data exchanged between external
parties. Entities In order to integrate FINE into CSIRT operations, entities
will have to make use of an interface to convert between an to and from the internal
Expires: February 6, 2006 [Page 4]
Internet Draft September 7, 2005
data representation (of a propriety work-flow application or database
for the incident report) and FINE FINE. Hence, the sender of an incident
report must convert from the local format to convey FINE, while the
recipient must translate FINE back into its own local format. The
communicating CSIRTs need not have the same local format for storing
incident reports. This information to other parties as exchange is depicted in Figure 1.
CSIRT CSIRT
+------------------+ +------------------+
| | | |
| +--------+ +---------+ +---------+ +--------+ |
| | |<--|Interface|<--Incident-->|Interface|-->| | |
| |Incident| +---------+ Report +---------+ |Incident| |
| | Report | | | | Report | |
| |Database| | |=== FINE ===| | |Database| |
| | | | | | | |
| +--------+ | | +--------+ |
| | | |
+------------------+ +------------------+
Fig. 1 Operational Model for FINE
3. General Requirements
3.1 FINE SHALL reference and use previously published RFCs where
possible.
3.2 FINE MUST have well defined semantics and provide a standard
mechanism for extensibility.
The values data elements of the various components of FINE should be typed,
and the meaning should be well specified. Likewise, there should be
a standardized method to address representing data not defined in the
data model.
4. Format Requirements
4.1 FINE SHALL support full internationalization and localization.
A significant part of the incident report will be comprised may comprise of human
readable natural
language text. Since some incidents will entail involvement of may involve CSIRTs from different
countries and geographic regions, FINE must have provisions for using local character sets and encodings.
Expires: November February 6, 2005 2006 [Page 5]
Internet Draft May September 7, 2005
local character sets and encodings.
In cases where local (non-standard) character sets and encodings are
used, the data elements that carry encoding sensitive encoding-sensitive information
should be clearly indicated. It Furthermore, it should be possible to
preserve the content of these elements when transferring an incident
report.
4.2 FINE MUST allow multilingual reports.
Different parts of the incident report may be written in a different
natural language. Likewise, Furthermore, FINE must support multiple versions
translations of the same part of the report
may exist, each in a different language. FINE must support this
flexibility. report.
4.3 FINE MUST support aggregation and filtering of incident report data.
The structure of the FINE must be defined with well-structured data elements and defined their associated
semantics to must support aggregation and filtering on these data elements
given a certain criteria. filtering.
4.4 FINE MUST be able to document the evolution of an incident.
An incident report may evolve with time as further investigation is
performed
carried out on the incident report. incident. Earlier information may be modified and
new information may be added. FINE must support the
recording documentation of
these changes.
4.5 FINE MUST support specifying a granular access restriction policy
for the specific elements
on subsets of the incident report.
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. It must be possible to specify
the degree of confidentiality for the individual components subsets of the incident report. Applications
With this information applications can then implement different
levels of access restrictions for the different components of the
incident report.
4.6 FINE SHOULD allow the application of external mechanisms to
support authenticity, integrity, and non-repudiation checks of
incident reports.
FINE itself need not guarantee authenticity, integrity, or non-
repudiation. However, the specification must detail a standardized
mechanism to ensure these properties.
Expires: November February 6, 2005 2006 [Page 6]
Internet Draft May September 7, 2005
5. Communication Mechanism Requirements
5.1 The communication mechanisms MUST NOT solely be used to ensure the
security of a FINE-encoded FINE incident report.
Incident 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. Provisions for
authenticity, integrity and confidentiality should be made in FINE.
6. Content Requirements
6.1 FINE MUST be flexible enough to support various degrees of
completeness, while still clearly defining the minimal
information required for describing an incident.
6.2 FINE 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 Furthermore, it should be
possible to derive the creator of the incident report from this
identifier.
6.3 FINE MUST support the naming of the source and target.
6.4 FINE SHOULD MUST support the description of various aspects of the
source and target.
6.5 FINE SHOULD contain a MUST support the description of the methodology used by
the attacker.
Well-known classifications or enumeration schemes should be used to
describe the attack that caused the incident.
6.6 FINE MUST identify SHOULD support the identification of the creator of the
incident report.
FINE should indicate the source of each component of the incident
report if it is different from the creator (e.g., the team handling
the incident).
6.7 FINE SHOULD support the inclusion or referencing of information
external to the incident report.
Expires: February 6, 2006 [Page 7]
Internet Draft September 7, 2005
6.8 FINE MUST support natural language descriptions of the incident.
Expires: November 6, 2005 [Page 7]
Internet Draft May 7, 2005
6.9 FINE SHOULD support references to the appropriate advisories
from coordination and analysis centers.
6.10 FINE SHOULD provide means for describing support a description of the impact of the incident.
6.11 FINE SHOULD provide means for describing support a description of the actions taken during the
course of handling the incident.
6.12 FINE SHOULD MUST use a standardized time specification.
Incident reports should 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 from various systems
irrespective of their time granularity.
7. Security Considerations
There are no explicit security considerations for this document since
no protocol or information model is specified. However, a number of
security relevant requirements are outlined for FINE implementers.
By its nature, FINE will represent sensitive information. Hence,
implementers should ensure support for access restriction
(requirement 4.5); transport agnostic security guarantees
(requirement 5.1); and confidentiality, integrity, and non-
repudiation (requirement 4.6).
8. IANA Considerations
This document 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. and Meijer J.,
Expires: February 6, 2006 [Page 8]
Internet Draft September 7, 2005
"TERENA's Incident Object Description and Exchange Format
Requirements", RFC 3067, February 2001
Expires: November 6, 2005 [Page 8]
Internet Draft May 7, 2005
[3] Meijer, J., Danyliw, R. R., Meijer, J. and Demchenko, Y., "Incident Object
Description and Exchange Format Data Model and Extensible Markup
Language (XML) Document Type Definition", work in 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] Wood, M., "Intrusion Detection Exchange Format Requirements",
work in progress (currently <draft-ietf-idwg-requirements-12.txt>).
[6] Brezinski, D., Killalea, T., "Guidelines for Evidence
Collection and 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 a Computer Security Incident Response Capability
(CSIRC)", NIST Special Publication 800-3, November 1991
[10] West-Brown, M., Stikvoort, D., Kossakowski, K., Killcrece G.,
Ruefle, R., Zajicek, M., "Handbook for Computer Security Incident
Response Teams (CSIRTs)", CMU/SEI-98-HB-002, Carnegie Mellon
University, Pittsburgh, PA, April 2003.
[11] Howard, J. and Longstaff, A., "A Common Language for Computer
Security Incidents", Sandia Report: SAND98-8667, Sandia National
Laboratories, October 1998.
Expires: November February 6, 2005 2006 [Page 9]
Internet Draft May September 7, 2005
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
Roman Danyliw
CERT Coordination Center
4500 Fifth Ave.
Pittsburgh, PA 15213
USA
Email: rdd@cert.org
Glenn Mansfield Keeni
Cyber Solutions Inc.
Sendai, Japan
Email: glenn@cysols.com
Expires: November February 6, 2005 2006 [Page 10]
Internet Draft May September 7, 2005
Full Copyright Statement
Copyright (C) The Internet Society (2004). (2005). 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: November February 6, 2005 2006 [Page 11]
Internet Draft May September 7, 2005
Intellectual Property
The IETF takes no position regarding the validity or scope of any
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; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made 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 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 that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expires: November February 6, 2005 2006 [Page 12]
Internet Draft May September 7, 2005
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-05
1) In 2.1 the definitions have been rearranged. Incident Report
(earlier 2.1.8 have been moved to 2.1.6)
2) Section 2.2, Operational model, revised
3) Editorial nits
4) IDnits
5) Added Roman Danyliw to the authors list.
Major changes in version -04
1) Operational model rewritten
2) Editorial nits
3) IPR notice updated
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
Expires: February 6, 2006 [Page 13]
Internet Draft September 7, 2005
should be consistent
4) in 7.5, added requirement that the source of each component of
the Incident report must be identified (if different from the
creator of the Incident report).
5) some editorial nits are fixed.
Expires: November 6, 2005 [Page 13]
Internet Draft May 7, 2005
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:
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: November February 6, 2005 2006 [Page 14]
----