[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

INCH Working Group                                       Yuri Demchenko
Internet Draft                                  University of Amsterdam
Category: Informational                                   Hiroyuki Ohno
                                                           WIDE Project
Expires: November 6, 2005                                 Glenn M Keeni
                                                   Cyber Solutions Inc.

                                                            May 7, 2005




  Requirements for the Format for INcident information Exchange (FINE)
                 <draft-ietf-inch-requirements-04.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 "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"

   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 6, 2005

   Copyright Notice

      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.  This document describes the
   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 6, 2005                                       [Page 2]


Internet Draft                                               May 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 often required to respond to
   these threats.  The basis for this interaction is 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 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 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,
         and the authenticity of the report source.

   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 not be 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 security policy of the target.  These
   violations may include a compromise of a user account, denial-of-
   service, information theft, etc.

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. CSIRT
   A Computer Security Incident Response Team, CSIRT, is an individual
   or a group of individuals that coordinate and support the response to
   incidents in a defined constituency [7]. A CSIRT creates, processes,
   and maintains incident reports.

2.1.7. 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 other CSIRTs. A CSIRT may
   create an incident report when information is reported to it. A CSIRT
   may also receive incident reports from its constituency or from
   another CSIRT. As analysis is performed and investigation occurs,
   more information about an incident may be discovered causing updates
   to previously sent incident reports to be exchanged.

   Surrounding the creation and exchange of incident reports is often a
   work-flow process to prioritize and manage the information flow in
   the CSIRT.  These systems often associate CSIRT analysts with
   particular incidents or tag status onto a particular investigation.
   FINE does not address these representation issues.



Expires: November 6, 2005                                       [Page 4]


Internet Draft                                               May 7, 2005


   FINE serves as the external representation for the data exchanged
   between parties. Entities will have to make use of an interface to
   convert between an internal data representation and FINE to convey
   information to other parties as 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 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 of human
   readable text. Since some incidents will entail involvement of CSIRTs
   from different countries and geographic regions, FINE must have
   provisions for using local character sets and encodings.




Expires: November 6, 2005                                       [Page 5]


Internet Draft                                               May 7, 2005


   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.

4.2 FINE 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. FINE must support this
   flexibility.

4.3 FINE MUST support aggregation and filtering of incident report data.

   FINE must be defined with well-structured data elements and defined
   semantics to support aggregation and filtering on these data elements
   given a certain criteria.


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 on the incident report.  Earlier information may be
   modified and new information may be added.  FINE must support the
   recording of these changes.

4.5 FINE MUST support specifying a granular access restriction policy
   for the specific elements 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 of the
   incident report. 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 6, 2005                                       [Page 6]


Internet Draft                                               May 7, 2005


5. Communication Mechanism Requirements

5.1 The communication mechanisms MUST NOT solely be used to ensure the
   security of a FINE-encoded 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 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 support the description of various aspects of the
   source and target.

6.5 FINE SHOULD contain a 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 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.

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 the impact of the incident.

6.11 FINE SHOULD provide means for describing the actions taken during the
   course of handling the incident.

6.12 FINE SHOULD 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.,
   "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. 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 6, 2005                                       [Page 9]


Internet Draft                                               May 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


   Glenn Mansfield Keeni
   Cyber Solutions Inc.
   Sendai, Japan
   Email: glenn@cysols.com





















Expires: November 6, 2005                                      [Page 10]


Internet Draft                                               May 7, 2005


                        Full Copyright Statement


   Copyright (C) The Internet Society (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: November 6, 2005                                      [Page 11]


Internet Draft                                               May 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 6, 2005                                      [Page 12]


Internet Draft                                               May 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 -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
      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 6, 2005                                      [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/