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

Versions: 00 01 02 03 04 05 06 07 08

     Network Working Group                                    Yuri Demchenko
     INTERNET DRAFT                                               NLnet Labs
     Category: Informational                                   Hiroyuki Ohno
                                                                WIDE Project
     Expires August 2003                                       Glenn M Keeni
                                                        Cyber Solutions Inc.
                                                              February, 2003
             Requirements for Format for INcident Report 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-
        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, retrieving and archiving Incident Reports across
        organizations, regions and countries.
                                                                   [Page 1]

     INTERNET DRAFT            FINE Requirements            February, 2003
        This document describes the requirements for an Incident Report
        Exchange Format.
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC 2119 [1].
     Table of Contents
        1.  Introduction ...............................................  2
        2.  Incident Handling Framework ................................  2
        3.  The Goal ...................................................  7
        4.  General Requirements .......................................  8
        5.  Format Requirements ........................................  8
        6.  Communication Requirements .................................  9
        7.  Content Requirements .......................................  9
        8.  Security Considerations .................................... 11
        9.  Acknowledgements ........................................... 12
        10. References ................................................. 12
        11. Authors' Addresses ......................................... 13
        Full Copyright Statement ....................................... 13
     1. Introduction
        Computer security incidents occur across administrative domains
        often spanning different organizations and national borders.
        Therefore, the exchange of incident information and statistics among
        involved parties and the responsible Computer Security Incident
        Response Teams (CSIRTs) is crucial for both reactionary analysis of
        current intruder activity and proactive identification of trends
        that can lead to incident prevention.
        In the following we refer to the information pertaining to an
        incident as an Incident Report. Actually Incident Report created and
        handled by CSIRT may have internal proprietary format that is
        adopted to local Incident handling procedure and used Incident
        Handling System (IHS). It is intended that exchange of Incident
        information will be conducted in a common format referred in this
        document as Format for INcident report Exchange (FINE).
        This document defines the high-level functional requirements to the
        FINE intended to facilitate collaboration between CSIRTs and parties
        involved when handling computer security incidents.
     2. Incident Handling Framework
        2.1. Incident Description Terms
     Expires August 2003                                           [Page 2]

     INTERNET DRAFT            FINE Requirements            February, 2003
        A definition of the main terms used in the rest of document is given
        for clarity.
        Where possible, existing definitions will be used; some definitions
        will need additional detail and further consideration. Currently
        proposed definitions are based on well-known in the CSIRT community
        documents [7, 8, 9, 10].
        2.1.1. Attack
        An assault on system security that derives from an intelligent
        threat, i.e., an intelligent act that is a deliberate attempt
        (especially in the sense of a method or technique) to evade security
        services and violate the security policy of a system.
        Attack can be active or passive, by insider or by outsider, or via
        attack mediator.
        2.1.2. Attacker
        Attacker is individual who attempts one or more attacks in order to
        achieve an objective(s).
        For the purpose of FINE attacker is described by its network ID,
        organisation which network/computer attack was originated and
        physical location information (optional).
        2.1.3. CSIRT
        CSIRT (Computer Security Incident Response Team) is used in FINE to
        refer to the authority handling the Incident and creating Incident
        Report.  The CSIRT is also likely to be involved in evidence
        collection and custody, incident remedy, etc.
        In FINE CSIRT represented by its ID, constituency, public key, etc.
        2.1.4. Damage
        An intended or unintended consequence of an attack which affects the
        normal operation of the targeted system or service.  Description of
        damage may include free text description of actual result of attack,
        and, where possible, structured information about the particular
        damaged system, subsystem or service.
        2.1.5. Event
        An action directed at a target which is intended to result in a
        change of state (status) of the target.  From the point of view of
        event origination, it can be defined as any observable occurrence in
        a system or network which resulted in an alert being generated.  For
        example, three failed logins in 10 seconds might indicate a brute-
        force login attack.
     Expires August 2003                                           [Page 3]

     INTERNET DRAFT            FINE Requirements            February, 2003
        2.1.6. Evidence
        Evidence is information relating to an event that proves or supports
        a conclusion about the event. With respect to security incidents (the
        events), it may include but is not limited to: data dump created by
        Intrusion Detection System (IDS), data from syslog file, kernel
        statistics, cache, memory, temporary file system, or other data that
        caused the alert or were collected after the incident happened.
        Special rules and care must be taken when storing and archiving
        evidence, particularly to preserve its integrity. When necessary
        evidence should be stored encrypted.
        According to the Guidelines for Evidence Collection and Archiving [6]
        evidence must be strictly secured.  The chain of evidence custody
        needs to be clearly documented.
        It is essential that evidence should be collected, archived and
        preserved according to local legislation.
        2.1.7. Impact
        Impact describes result of attack expressed in terms of user
        community, for example the cost in terms of financial or other
        2.1.8. Incident
        An Incident is a security event that involves a security violation.
        An incident can be defined as a single attack or a group of attacks
        that can be distinguished from other attacks by the method of attack,
        identity of attackers, victims, sites, objectives or timing, etc.
        In the context of FINE, the term Incident is used to mean a Computer
        Security Incident or an IT Security Incident.
        However we should distinguish between the generic definition of
        'Incident' which is an event that might lead to damage or damage
        which is not too serious, and 'Security Incident' or 'IT Security
        Incident' which are defined below:
        a) Security incident is an event that involves a security violation.
        This may be an event that violates a security policy, AUP, laws and
        jurisdictions, etc. A security incident may also be an incident that
        has been escalated to a security incident.
        A security incident is worse than an incident as it affects the
        security of or in the organisation. A security incident may be
        logical, physical or organisational, for example a computer
        intrusion, loss of secrecy, information theft, fire or an alarm that
        doesn't work properly.  A security incident may be caused on purpose
     Expires August 2003                                           [Page 4]

     INTERNET DRAFT            FINE Requirements            February, 2003
        or by accident.  The latter may be if somebody forgets to lock a door
        or forgets to activate an access list in a router.
        b) An IT security incident is defined according to [9] as any real or
        suspected adverse event in relation to the security of a computer or
        computer network.  Typical security incidents within the IT area are:
        a computer intrusion, a denial-of-service attack, information theft
        or data manipulation, etc.
        2.1.9. Incident Report
        Document describing in details Incident processed by CSIRT.
        We distinguish general definition of Incident report that is created
        and handled by CSIRT and may have internal proprietary format
        adopted to local Incident handling procedures or defined by used
        Incident Handling System, and Format for INcident report Exchange
        (FINE) used for exchange of Incident information between CSIRTs.
        Definition of the requirements to FINE is a subject of this
        2.1.10. Incident Handling System
        Incident Handling System (IHS) is used by CSIRT to handle Incidents.
        It may include user interface, underlying database and may be
        integrated with ticketing or customer service system. During Incident
        investigation CSIRT may use specific tools, e.g. for examining log
        files, mapping network addresses to Internet names and organisations,
        etc., which also may be integrated into IHS.
        In current document, it is suggested that IHS can produce a document
        in FINE.
        2.1.11. Target
        A computer or network logical entity (account, process or data) or
        physical entity (component, computer, network or internetwork).
        2.1.12. Victim
        Victim is individual or organisation which suffered the attack which
        is described in incident report.
        For the purpose of FINE victim is described by its network ID,
        organisation and location information.
        2.1.13. Other terms
        Other terms used: alert, activity, IDS, Security Policy, etc., - are
        defined in related I-Ds, RFCs and standards [2, 3, 6, 7, 8, 9, 10].
        2.2 The Operational Model
     Expires August 2003                                           [Page 5]

     INTERNET DRAFT            FINE Requirements            February, 2003
        Incident Reports are generated, received and updated. For example,
        An organization may send an Incident Report to a CSIRT when an
        attack has been detected. Computer Security Incident Response Teams
        (CSIRTs) receive Incident Reports via different channels including
        Incident reports from constituency or customers, or from other
        CSIRTs. The CSIRTs maintain these reports. They may process the
        reports to generate statistics, or investigate 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
        From the operational point of view during the whole life-cycle of an
        Incident Report:
        +  the report itself evolves;
        +  the report is exchanged between CSIRT and can be
          investigated/processed by few CSIRTs at the same moment;
        +  the changes in the report may be effected by one or more CSIRTs
        +  a single CSIRT may not be in a position to vouch for the veracity
          of all parts of the Incident Report
        + the Incident Report may exist in several states:
          - complete/closed - the Incident Report is not being processed and
          no processing is planned
          - waiting - the Incident Report is waiting on some event, in
          particular case, a response from one or more CSIRTs
        Also, due to the nature of the operations:
        + the various parts of an Incident Report will have information of
          varying degrees of sensitivity and will need to be handled with
          the  appropriate level of confidentiality.
        + the Incident Report may be multilingual i.e. different parts of
          the Incident Report may use different languages. It is also
          possible that  multiple versions of parts of the report exist,
          each version in a different language. The versions may not be
        It is essential to distinguish between internal Incident Report
        processing procedures and respectfully requirements to internal
        Incident Report format and Incident Report participating in
        information exchange between CSIRTs for different purposes, whether
        itÆs aimed for cooperative investigation, specific information or
        action request, or just for information or statistics, and therefore
        complying to FINE.
                       Database <--------- Incident Reports
                       (Local)             (in internal format)
                          | ^
                          | |                   FINE
                          | |                  (Exchange Format)
     Expires August 2003                                           [Page 6]

     INTERNET DRAFT            FINE Requirements            February, 2003
                          | |                     |
                          v |                     v
        Initial        Incident | Internal      Incident
        Incident --->  Handling | Incident ---> Exchange
        Report         System   | Report        Gateway
           |            (IHS)   | Format        (FINE)
           |             ^ |    |                  | ^
           |             | |                       | |
           |             | |                       | |
           |             | v                       | |
           +---------- CSIRT                       | | FINE
                       (Triage/                    | | (Exchange
                        Operator)                  | | Format)
                          ^                        | |
                          |                        v |
                          |                      Other CSIRTs
                          +------------------->  (other parties)
                            Other forms of
        Fig. 1 Operational Model of an Incident Handling Procedure
        Initial Incident Report may be based on information or request
        received from the constituency/victim, Network Operation Center,
        other CSIRTs or in a form of Alert from automated Intrusion
        Detection System. It should be noted that there is a generic
        difference between "Alerts" generated by IDS (as defined in
        Intrusion Description and Exchange Format (IDMEF) [5] and Incident
        Reports. The IDMEF Alerts are generated by "sensors" and processed
        by managers (applications). On the other hand the Incident reports
        will be created by human beings (although with the support of
        automated IHS) and will also be finally consumed primarily by human
     3. The Goal
        The purpose of the Format for INcident Report Exchange (FINE) is to
        facilitate the exchange of incident information and statistics among
        involved parties and Computer Security Incident Response Teams
        (CSIRTs) for reactionary analysis of current security incidents and
        proactive identification of trends that can lead to incident
        prevention. A common and well-defined format for Incident Reports
        will help in exchanging, retrieving and archiving Incident Reports
        across organizations, regions and countries.
        There is need to
        + to make its semantics as clear and unambiguous as possible even
          across regional and national boundaries;
        + to have a well defined syntax (at least for parts of it);
        + to enable categorization and statistical analysis;
     Expires August 2003                                           [Page 7]

     INTERNET DRAFT            FINE Requirements            February, 2003
        + to make it possible to ensure integrity of the message, and the
          authenticity of the message source.
     4. General Requirements
        4.1 The definition of the Format for INcident Report Exchange (FINE)
        shall reference and use previously published RFCs where possible.
     5. Format Requirements
        5.1 FINE shall support full internationalization and localization.
        A significant part of the FINE will comprise of human-readable text.
        Since some Incidents need involvement of CSIRTs from different
        countries, cultural and geographic regions, the FINE description
        must be formatted such that they can be presented to an operator in
        a local language and adhering to local presentation formats and
        local naming rules and conventions. Localized presentation of dates,
        time and names may also be required.
        In case, if used, the format must be able to identify the rules or
        conventions that is used in the naming.
        In cases where the messages contain text strings and names that need
        characters other than Latin-1 (or ISO 8859-1), the information
        preferably should 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.
        5.2  FINE must support modularity in Incident description to allow
        aggregation and filtering of data.
        The structure will contain several components and some components
        may be structures themselves. Each component of a structure will
        have a well defined semantics.
        5.3 FINE must provide the possibility for recording the evolution of
        Incident Report during its whole lifetime. In particular, FINE
        should contain the record of all communications that happened in
        course of current Incident.
        An Incident Report may evolve with time. As investigation proceeds
        information about an incident may be revealed and parts of the
        earlier information will be refined/obsolete.  The Format for
        Incident report Exchange should be able to support the record of the
        evolution of the Incident Report with the level of details defined
        internal/adopted Incident Handling procedure Appropriate timestamps
        identifying the epochs in the lifetime of an Incident Report should
        be also possible/applied.
        5.4 FINE must support the application of an access restriction
        policy to individual components.
     Expires August 2003                                           [Page 8]

     INTERNET DRAFT            FINE Requirements            February, 2003
        An Incident Report may potentially contain sensitive or private
        information (such as passwords, persons/organisations identifiers or
        forensic information (evidence data)) and in some cases may be
        exposed to non-authorised persons. It must be possible to define the
        degree of confidentiality for the individual components of the
        Incident Report and for different roles and parties involved.
        Such situations may arise particularly in case of Incident
        information exchange between CSIRTs or other involved bodies.
        Technical realization may include using special restriction
        attributes or general external technology available with
        implementation format, which can be applied by Incident Handling
        System. Some cases may be addressed by encrypting FINE elements,
        however this will not always be possible. Therefore, to prevent
        accidental disclosure of sensitive data, parts of the FINE object
        must be marked with access restriction attributes.  These markings
        will be particularly useful when used with automated processing
        5.5 An FINE report must be globally uniquely identifiable.
        It should be possible to map the origin/creator of an Incident
        Report from its globally unique identifier.
        5.6. The Format for Incident report Exchange itself must be
        extensible. The extension will be in terms of addition of components
        and/or extending the components.
     6. Communication Mechanisms Requirements
        6.1. Incident Report exchange will normally be initiated by humans
        using standard communication protocols and exchange mechanisms, for
        example, e-mail, HTTP, XML Web Services, FTP, etc. FINE must not
        rely on communication mechanisms to satisfy requirements of current
        document. The communication mechanisms must have no bearing on the
        authenticity, integrity, and confidentiality of the Incident Report
        itself. Communications security requirements may be applied
        separately according to local policy so are not defined by this
     7. Content Requirements
        FINE must be flexible enough to support various degrees of
        completeness. At the same time it must clearly state the minimal
        information without which the information in the Incident Report
        will be seriously degraded.
        7.1  An Incident Report will generally refer to one or more
        entities. The entity may be an attacker, a victim or an observer.
        There are several facets of an entity involved in an Incident
     Expires August 2003                                           [Page 9]

     INTERNET DRAFT            FINE Requirements            February, 2003
        Report. The entity may have zero or more network addresses and names
        as well as zero or more location names, organizational name, person
        names, machine names etc. FINE should support various facets
        describing the entities involved.
        7.2  The Incident Report should contain the type of the attack if
        it's known.
        FINE must support well-known classification/enumeration schemes. It
        is expected that this type will be drawn from a standardized list of
        events/attacks; a new type of event may use a temporary
        implementation- specific type if the event type has not yet been
        Incident handling may involve many different staff members and
        teams. It is therefore essential that common terms are used to
        describe incidents. If the event type has not yet been standardized,
        temporary type definition might be given by team created Incident
        Report.  It is expected that new type name will be self-explanatory
        and derived from a similar, existing type definition.
        7.3. FINE must include the Identity of the creator (or current
        owner) of the Incident Report (CSIRT or other authority).  This may
        be the sender in an information exchange or the team currently
        handling the incident.
        The identity of Incident description creator is often valuable
        information for Incident response.  In one possible scenario the
        attack may progress through the network, comparison of corresponding
        incidents reported by different authorities might provide some
        additional information about the origin of the attack.  This is also
        useful information at post-incident information handling/exchange
        7.4  The FINE should contain information about the attacker and
        victim, if known.
        7.5  The FINE should contain reference to advisories corresponding
        to the Incident Report, e.g. CERT/CC, CVE, and others.
        7.6  The FINE should contain a detailed description of the attack
        that caused the current Incident. In particular, FINE should contain
        information about AttackerÆs and VictimÆs systems participated or
        targeted in that Attack.
        7.7 The FINE may contain a description of the incident in a natural
        7.8  The Incident Report should contain or be able to reference
        additional detailed information/data related to this specific
        underlying event(s)/activity, often referred as evidence.
     Expires August 2003                                           [Page 10]

     INTERNET DRAFT            FINE Requirements            February, 2003
        This information may include IDMEF [5] messages, which have been
        generated by security devices.
        7.9 The Incident Report should describe the Impact on the target, if
        There should be guidelines to describe the impact on the target
        to ensure a uniform interpretation of the description.
        The value of this field should be drawn from a standardized list of
        values if the attack is recognized as known, or expressed in a free
        language by responsible CSIRT team member.
        7.10 The Incident Report should describe the actions taken since the
        occurrence of the incidence.
        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.)
        Internal Incident Report may contain local presentation of time
        related information, however FINE must provide unambiguous time
        presentation. For event correlation purposes, it is important that
        the manager be able to normalize the time information reported in
        the FINE descriptions. In case when normalization of the time
        information is not possible (like in case of referencing additional
        data about the Incident that cannot be changed, e.g. timestamped log
        data), the time offset should be mentioned.
        7.12 Time granularity in FINE time parameters shall not be specified
        by the FINE.
        The time data may be included into FINE description by existing
        information systems, retrieved from incident reporting messages or
        taken from IDS data or other event registration tools.  Each of
        these cases may have its own different time granularity.  For the
        purposes of implementation, it should be possible to handle time at
        different stages according to the local system capabilities.
        7.13 The Incident Report should allow application of (external)
        mechanisms or assertions to assure its authenticity, integrity and
        non-repudiation can be verified.
        7.14 The semantics of FINE must be well defined.  The various
        components of FINE should have a well defined semantics.
     8. Security Considerations
        This memo does not describe a protocol by itself. This memo
        describes the requirements for an Incident Report Exchange Format.
        The reports themselves are about security incidents. The contents of
        the Incident Reports will have significant direct and/or indirect
        impact on the security and privacy of a network and/or individuals.
     Expires August 2003                                           [Page 11]

     INTERNET DRAFT            FINE Requirements            February, 2003
        FINE implementers should take care to analyze and implement the
        requirements stated in 5.5 and 7.12.
     9. Acknowledgments.
        The precursor of this document is "TERENAÆs Incident Object
        Description Exchange Format Requirements" [RFC3067] 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
        [3] Incident Object Description and Exchange Format Data Model and
        Extensible Markup Language (XML) Document Type Definition û October
        2002. Work in progress.
        [4]  Taxonomy of the Computer Security Incident related terminology
        - http://www.terena.nl/task-forces/tf-csirt/iiodef/docs/i-
        [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
     Expires August 2003                                           [Page 12]

     INTERNET DRAFT            FINE Requirements            February, 2003
        National Laboratories -
     11. AuthorsÆ Addresses:
        Yuri Demchenko
        NLnet Labs
        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
     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.
     Expires August 2003                                           [Page 13]

     INTERNET DRAFT            FINE Requirements            February, 2003
     Appendix û non-normative
     Major Changes (reverse count)
     Expires August 2003                                           [Page 14]

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