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

Versions: 00 01 02 03 04 05 06 07 08

     Network Working Group                                    Yuri Demchenko
     INTERNET DRAFT                                  University of Amsterdam
     Category: Informational                                   Hiroyuki Ohno
                                                                WIDE Project
     Expires April 2004                                        Glenn M Keeni
                                                        Cyber Solutions Inc.
                                                                October, 2003
           Requirements for Format for INcident information Exchange (FINE)
     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 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
        The list of Internet-Draft Shadow Directories can be accessed at
        Distribution of this memo is unlimited.
        Copyright Notice
        Copyright (C) The Internet Society (2001). All Rights Reserved.
        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 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
        2.  Incident Handling Framework ................................  3
        3.  The Goal ...................................................  6
        4.  General Requirements .......................................  6
        5.  Format Requirements ........................................  6
        6.  Communication Requirements .................................  7
        7.  Content Requirements .......................................  7
        8.  Security Considerations ....................................  9
        9.  Acknowledgements ...........................................  9
        10. References .................................................  9
        11. Authors' Addresses ......................................... 10
        Full Copyright Statement ....................................... 11
     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.
        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;
        + to ensure that the report (or parts of it) has a well defined
        + 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 the
           authenticity of the report source.
     Expires April 2004                                           [Page 2]

     INTERNET DRAFT            FINE Requirements             October, 2003
        This document defines the high-level functional requirements of a
        Format for INcident report Exchange (FINE).
     2. Incident Handling Framework
        2.1. Incident Description Terms
        For the purpose of clarify, 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. An attack may be successful.
        2.1.2. Attacker
        Attacker is an entity that attempts one or more attacks.
        An attacker may be an insider, an outsider, or an entity acting via
        an attack mediator. For the purpose of FINE, an attacker is described
        by the computer/network ID, from which the attack was launched. The
        organization name and/or physical location of the computer/network
        are used as additional information.
        2.1.3. CSIRT
        CSIRT (Computer Security Incident Response Team) is a team that
        coordinates and supports the response to security incidents that
        involve sites within a defined constituency [7]. The CSIRT generates,
        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
        Impact describes the result of an attack expressed in terms of user
        community, for example the cost in terms of financial or other
        2.1.7. Computer/Network Security Incident
        A Computer/Network Security Incident, referred 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.
        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 is adapted to the local
        Incident Handling System (IHS) and Incident handling procedures.
        Definition 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 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
        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
        2.2 The Operational Model
        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 from 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
                       CSIRT                             |
               +---------------------+                   |
               |                     |                   |
               | +--------+          |                   |
               | |        |          |                   |
               | |        |          |  Incident Report  |
               | |Incident|<---------|<----------------->| Customers/
               | |ReportDB|          |                   | CSIRTs/
               | |        |         |<===   FINE    ===>| Collaborators/
               | |        |          |                   | Involved parties
               | |        |          |                   |
               | +--------+          |                   |
               |                     |                   |
               |                     |                   |
               |                     |                   |
               |                     |                   |
               +---------------------+                   +-----
                     Fig. 1 Operational Model for FINE
        From the operational point of view during the life-cycle of an
        Incident Report the following may apply:
        + the report itself evolves. It may exist in one of the following
           - handling – the Incident Report is being handled
           - complete/closed - the Incident Report is not being processed and
           no processing is planned
           - waiting - the 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 by one or
           more CSIRTs. So 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 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 Incident Report will comprise of human-
        readable text. Since some Incidents need 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
        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 FINE must support aggregation and filtering of Incident Report
        The format of FINE must be structured with components that have a
        well-defined syntax and semantics.
        5.3 FINE must provide the possibility for recording the evolution of
        an Incident Report during its lifetime.
        An Incident Report may evolve with time. As investigation proceeds,
        it is likely that more information about an incident will be revealed
        and parts of the earlier information will be modified/deleted.  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 FINE must support the application of an access restriction policy
        to individual components 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
        5.5 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 the origin/creator of an Incident Report from its globally unique
        5.6. FINE must have a well defined semantics and provide a standard
        way for extensibility in terms of addition of components and/or
        extending the components.
        5.7. FINE must allow multilingual reports. In case there are multiple
        language versions of a component of the report, the versions should
        be consistent and, and FINE must provide a way 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. Communication Mechanisms Requirements
        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 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. 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
     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 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 the attacker, perpetrator, victim,
        or an observer.
        7.3 FINE should support the description of various aspects/details 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 and names as well as zero or more location
        names, organizational names, person names, machine names etc..
        7.4 FINE should contain the description of the method how the attack
        or security event was conducted if it is known.
        Well-known classification/enumeration schemes should be used to
        describe the type of attack or vulnerabilities and exposures caused
        particular Incident or security Event.
        7.5 FINE must include the identity of the creator of the Incident
        Report (CSIRT or other authority). FINE should indicate the source of
        each component of the Incident Report if it’s different from the
        The source of a component of the Incident Report may be the creator
        of the Incident Report, the team handling the incident or, some other
        7.6 FINE should provide the possibility to include or reference
        additional detailed information/data external to report.
        This information may include IDMEF [5] messages, which have been
        generated by security devices.
        7.7 FINE may contain a natural language description of the Incident
        or related security events.
        7.8 FINE should contain references to the appropriate advisories,
        wherever applicable, corresponding to the related events , e.g.
        CERT/CC, CVE, etc.
        7.9 FINE 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 FINE must 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), the
        time offset should be mentioned.
        7.12 FINE will not have any specific requirement for granularity of
        Different systems will support different time granularities. FINE
        should be able to support 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. 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. FINE
        implementers should take care to analyze and implement the
        requirements regarding access restriction policy as stated in 5.4 and
        requirements regarding support of external mechanisms for
        authenticity, integrity and non-repudiation 7.13.
     9. 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 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 April 2004                                           [Page 9]

     INTERNET DRAFT            FINE Requirements             October, 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 -
        [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
        [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
        National Laboratories -
     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                                           [Page 10]

     INTERNET DRAFT            FINE Requirements             October, 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
        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 -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 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.
        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 April 2004                                           [Page 12]

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