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

Versions: (RFC 3067) 00

     Network Working Group                                    Yuri Demchenko
     INTERNET DRAFT                                                   TERENA
     Category: Informational
     
     Expires April 2003
                                                               October, 2002
     
     
                   Incident Object Description and Exchange Format
                                    Requirements
                  <draft-ietf-inch-iodef-rfc3067bis-requirements-00.txt>
     
     
     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
        http://www.ietf.org/ietf/lid-abstracts.txt
     
        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html
     
        Distribution of this memo is unlimited.
     
     
        Copyright Notice
     
        Copyright (C) The Internet Society (2001). All Rights Reserved.
     
     1. Abstracts
     
        The purpose of the Incident Object Description and Exchange Format is
        to define a common data format for describing and exchanging incident
        information between collaborating Computer Security Incident Response
        Teams (CSIRTs). The specific goals and requirements of the IODEF are
        described in [2]. One of the design principles in the IODEF is
        compatibility with the Intrusion Detection Message Exchange Format
        (IDMEF) [3] developed for intrusion detection systems. For this
        reason, IODEF is heavily based on the IDMEF and provides upward
        compatibility with it.
     
     
                                                                   [Page 1]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
     
        The purpose of the Incident Object Description and Exchange Format is
        to define a common data format for the description, archiving and
        exchange of information about incidents between CSIRTs (Computer
        Security Incident Response Teams) (including alert, incident in
        investigation, archiving, statistics, reporting, etc.).  This
        document describes the high-level requirements for such a description
        and exchange format, including the reasons for those requirements.
        Examples are used to illustrate the requirements where necessary.
     
     
     
     1. Conventions used in this document
     
        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].
     
     
     2. Introduction
     
        This document is a revision of RFC 3067 [2] which defined
        requirements for the initial development of the Incident Object
        Description and Exchange Format (IODEF) by TERENA IODEF WG [3] which
        since IETF53 transferred further development of the IODEF to IETF
        INCH Working Group [4].
     
        This document itself defines requirements for the IODEF. IODEF is
        intended to be a standard format which allows Computer Security
        Incident Response Teams (CSIRTs) to exchange operational and
        statistical information; it may also provide a basis for the
        development of compatible and inter-operable tools for Incident
        recording, tracking and exchange.
     
        Most of revisions of RFC3067 are compliant to currently published
        IODEF Data Model and XML Data Type Description Internet-draft [5].
     
        This document also has intention to provide requirement document that
        is open for discussion in IETF INCH WG and will evolve together with
        ongoing IODEF development and implementation.
     
        Further discussion of this document will take place on the INCH WG
        mailing lists < inch@nic.surfnet.nl>, archive is available at
        http://listserv.surfnet.nl/archives/inch.html
     
     
        2.1. Rationale
     
        Computer Incidents are becoming distributed and International and
        involve many CSIRTs across borders, languages and cultures.  Post-
        Incident information and statistics exchange is important for future
        Incident prevention and Internet security improvement.  The key
     
     
     Demchenko             Expires April 2003              [Page 2]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        element for information exchange in all these cases is a common
        format for Incident (Object) description.
     
        It is probable that in further development or implementation the
        IODEF might be used for forensic purposes, and this means that
        Incident description must be unambiguous and allow for future custody
        (archiving/documentation) features.
     
        Another issue that is targeted by developing IODEF is a need to have
        higher level Incident description and exchange format than will be
        provided by IDS (Intrusion Detection Systems) and the proposed IDMEF
        (Intrusion Detection Message Exchange Format).  Compatibility with
        IDMEF and other related standards will be satisfied by the IODEF
        requirement on modularity and extensibility.  IODEF should vertically
        be compatible with IDMEF, IODEF might be able to include or reference
        IDMEF Alert message as initial information about Incident.
     
        2.2. Incident Description Terms
     
        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 the Taxonomy of the
        Computer Security Incident related terminology made by TERENA's IODEF
        WG [2] and presented in [6], other documents used include [7, 8].
     
        2.2.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.2.2. Attacker
     
        Attacker is individual who attempts one or more attacks in order to
        achieve an objective(s).
     
        For the purpose of IODEF attacker is described by its network ID,
        organisation which network/computer attack was originated and
        physical location information (optional).
     
        2.2.3. CSIRT
     
        CSIRT (Computer Security Incident Response Team) is used in IODEF to
        refer to the authority handling the Incident and creating Incident
     
     
     Demchenko             Expires April 2003              [Page 3]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        Object Description.  The CSIRT is also likely to be involved in
        evidence collection and custody, incident remedy, etc.
     
        In IODEF CSIRT represented by its ID, constituency, public key, etc.
     
        2.2.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.2.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.
     
        2.2.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
        (Evidence) 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.2.7. 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.
     
        An incident is a root element of the IODEF. In the context of IODEF,
        the term Incident is used to mean a Computer Security Incident or an
        IT Security Incident.
     
     
     Demchenko             Expires April 2003              [Page 4]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        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' and '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, UAP, 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
        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.2.8. Impact
     
        Impact describes result of attack expressed in terms of user
        community, for example the cost in terms of financial or other
        disruption
     
        2.2.9. Target
     
        A computer or network logical entity (account, process or data) or
        physical entity (component, computer, network or internetwork).
     
        2.2.10. Victim
     
        Victim is individual or organisation which suffered the attack which
        is described in incident report.
     
        For the purpose of IODEF victim is described by its network ID,
        organisation and location information.
     
        2.2.11. Vulnerability
     
        A flaw or weakness in a system's design, implementation, or operation
        and management that could be exploited to violate the system's
        security policy.
     
        Most systems have vulnerabilities of some sort, but this does not
        mean that the systems are too flawed to use.  Not every threat
        results in an attack, and not every attack succeeds.  Success depends
        on the degree of vulnerability, the strength of attacks, and the
     
     Demchenko             Expires April 2003              [Page 5]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        effectiveness of any countermeasures in use.  If the attacks needed
        to exploit a vulnerability are very difficult to carry out, then the
        vulnerability may be tolerable.  If the perceived benefit to an
        attacker is small, then even an easily exploited vulnerability may be
        tolerable.  However, if the attacks are well understood and easily
        made, and if the vulnerable system is employed by a wide range of
        users, then it is likely that there will be enough benefit for
        someone to make an attack.
     
        2.2.12. Other terms
     
        Other terms used: alert, activity, IDS, Security Policy, etc., - are
        defined in related I-Ds, RFCs and standards [7 - 12].
     
     3. General Requirements
     
        3.1. The IODEF shall reference and use previously published RFCs
        where possible.
     
        Comment: The IETF has already developed a number of standards in the
        areas of networks and security that are actually deployed in present
        Internet. Current standards provide framework for compatibility of
        IODEF with other related technologies necessary to operate /implement
        IODEF in practice.  Another issue of compatibility for the IODEF is
        its general compatibility with IDMEF developed by IETF IDWG.  In the
        interest of time and compatibility, defined and accepted standards
        should be used wherever possible.
     
        In particularly, IODEF specification proposals SHOULD rely heavily on
        existing communications, encryption and language standards, where
        possible.
     
     4. Description Format
     
        4.1. IODEF shall support full internationalization and localization.
     
        Comment: Since some Incidents need involvement of CSIRTs from
        different countries, cultural and geographic regions, the IODEF
        description must be formatted such that they can be presented to an
        operator in a local language and adhering to local presentation
        formats.
     
        Although metalanguage for IODEF identifiers and labels is considered
        to be English, a local IODEF implementation might be capable to
        translate metalanguage identifiers and labels into local language and
        presentations if necessary.
     
        Localized presentation of dates, time and names may also be required.
        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.
     
     Demchenko             Expires April 2003              [Page 6]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
     
        4.2. The IODEF must support modularity in Incident description to
        allow aggregation and filtering of data.
     
        Comment: It is suggested that Incident description with IODEF might
        include external information, e.g., from IDS, or reference externally
        stored evidence custody data, or such information might be removed
        from current IODEF description, e.g., in purposes of privacy or
        security. Another practical/real life motivation for this requirement
        is to give possibility for some CSIRTs/managers to perform filtering
        and/or data aggregation functions on IODEF descriptions for the
        purposes of statistics, reporting and high level Incident information
        exchange between CSIRTs and/or their constituency and sponsors.
     
        Therefore the IODEF descriptions MUST be structured to facilitate
        these operations.  This also implies to strong IODEF semantics.
     
        4.3. IODEF must support the application of an access restriction
        policy to individual components and to individual accessing entities.
     
        Comment: IODEF Incident descriptions 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.  Such situations may
        arise particularly in case of Incident information exchange between
        CSIRTs or other involved bodies. Technical realization may included
        using special restriction attributes or general external technology
        available with implementation format (like XSLT for XML based IODEF
        implementation), which can be applied by Incident Handling System.
        Some cases may be addressed by encrypting IODEF elements, however
        this will not always be possible.
     
        Therefore, to prevent accidental disclosure of sensitive data, parts
        of the IODEF object must be marked with access restriction
        attributes.  These markings will be particularly useful when used
        with automated processing systems.
     
     
     5. Communications Mechanisms Requirements
     
        5.1. IODEF exchange will normally be initiated by humans using
        standard communication protocols, for example, e-mail, HTTP, XML Web
        Services (based on SOAP XML Protocol).
     
        Comment: IODEF description is normally created by a human using
        special or standard text editors.  The IODEF is targeted to be
        processed by automated Incident handling systems but still must be
        human readable, able to be viewed and browsed with standard tools
        (e.g., browsers or electronic table processors or database tools like
        MS Excel or Access).  Incident information exchange will normally
        require authorisation by  an operator or CSIRT manager so is not
        expected to be initiated automatically.  The role of Incident
     
     
     Demchenko             Expires April 2003              [Page 7]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        handling system is to provide assistance and tools for performing the
        exchange.
     
        It is important to distinguish the purposes of the machine readable
        and exchangeable IDEF Intrusion message format and the human oriented
        and created IODEF Incident description.
     
        Communications security requirements will be applied separately
        according to local policy so are not defined by this document.
     
     6. Message Contents
     
        6.1. The root element of the IO description should contain a unique
        identification number (or identifier), IO purpose and default
        permission level
     
        Comment: Unique identification number (or identifier) is necessary to
        distinguish one Incident from another.  It is suggested that unique
        identification number will contain information at least about IO
        creator, i.e. CSIRT or related body.  The classification of the
        Incident may also be used to form a unique identification number.  IO
        purpose will actually control which elements are included in the
        IODEF object Purposes may include incident alert/registration,
        handling, archiving, reporting or statistics.  The purpose, incident
        type or status of Incident investigation may require different levels
        of access permission for the Incident information.
     
        It is considered that root element of the IODEF will be <INCIDENT>
        and additional information will be treated as attributes of the root
        element.
     
     
        6.2. The content of the IODEF description should contain the type of
        the attack if it is known.
     
        It is expected that this type will be drawn from a standardized list
        of events; a new type of event may use a temporary implementation-
        specific type if the event type has not yet been standardized.
     
        Comment: 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 IO.  It is expected that
        new type name will be self-explanatory and derived from a similar,
        existing type definition.
     
        6.3. The IODEF description must be structured such that any relevant
        advisories, such as those from CERT/CC, CVE, can be referenced.
     
        Comment: Using standard Advisories and lists of known Attacks and
        Vulnerabilities will allow the use of their recommendations on
     
     Demchenko             Expires April 2003              [Page 8]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        Incident handling/prevention.  Such information might be included as
        an attribute to the attack or vulnerability type definition.
     
        6.4. IODEF may include a detailed description of the attack that
        caused the current Incident.
     
        Comment: Description of attack includes information about attacker
        and victim, the appearance of the attack and possible impact.  At the
        early stage of Intrusion alert and Incident handling there is likely
        to be minimal information, during handling of the Incident this will
        grow to be sufficient for Incident investigation and remedy. Element
        <ATTACK> should be one of the main elements of Incident description.
     
        6.5. The IODEF description must include or be able to reference
        additional detailed data related to this specific underlying
        event(s)/activity, often referred as evidence.
     
        Comment: For many purposes Incident description does not need many
        details on specific event(s)/activity that caused the Incident; this
        information may be referenced as external information (by means of
        URL).  In some cases it might be convenient to store separately
        evidence that has different access permissions.  It is foreseen that
        another standard will be proposed for evidence custody [5].
     
     
        6.6. The IODEF description MUST contain the description of the
        attacker and victim.
     
        Comment: This information is necessary to identify the source and
        target of the attack.  The minimum information about attacker and
        victim is their IP or Internet addresses, extended information will
        identify their organisations allowing CSIRTs to take appropriate
        measures for their particular constituency.
     
        6.7. The IODEF description must support the representation of
        different types of device addresses, e.g., IP address (version 4 or
        6) and Internet name.
     
        Comment: The sites from which attack is launched might have addresses
        in various levels of the network protocol hierarchy (e.g., Data layer
        2 MAC addresses or Network layer 3 IP addresses).  Additionally, the
        devices involved in an intrusion event might use addresses that are
        not IP-centric, e.g., ATM-addresses.  It is also understood that
        information about the source and target of the attack might be
        obtained from IDS and include the IP address, MAC address or both.
     
        6.8. IODEF must include the Identity of the creator (or current
        owner) of the Incident Object (CSIRT or other authority).  This may
        be the sender in an information exchange or the team currently
        handling the incident.
     
        Comment: The identity of Incident description creator is often
        valuable information for Incident response.  In one possible scenario
     
     Demchenko             Expires April 2003              [Page 9]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        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 stage.
     
        Experience based on initial IODEF development also uses working
        concept of Incident Object ownership for resolving technical problems
        with identifying and tracking Incident reports.
     
        6.9. The IODEF description must contain an indication of the
        possible impact of this event on the target.  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.
     
        Comment: Information concerning the possible impact of the event on
        the target system provides an indication of what the attacker is
        attempting to do and is critical data for the CSIRTs to take actions
        and perform damage assessment.  If no reference information
        (Advisories) is available, this field may be filled in based on CSIRT
        team experience.
     
        It is expected that most CSIRTs will develop Incident handling
        support systems, based on existing Advisories (such as those from
        CERT/CC, CVE, etc.) that usually contain list of possible impacts for
        identified attacks.
     
        This also relates to the development of IDEF which will be
        implemented in intelligent IDS, able to retrieve information from
        standard databases of attacks and vulnerabilities.
     
        6.10. The IODEF must be able to state the degree of confidence in
        the report information.
     
        Comment: Including this information is essential at the stage of
        Incident creation, particularly in cases when intelligent automatic
        IDS or expert systems are used.  These normally use statistical
        engines to estimate the event probability.
     
        6.11. The IODEF description must provide information about the
        actions taken in the course of this incident by previous CSIRTs.
     
        Comment: The IODEF describes an Incident throughout its life-time
        from Alert to closing and archiving.  It is essential to track all
        actions taken by all involved parties.  This will help determine what
        further action needs to be taken, if any.  This is especially
        important in case of Incident information exchange between CSIRTs in
        process of investigation.
     
        6.12. The IODEF must support reporting of the time of all stages
        along Incident life-time.
     
     
     Demchenko             Expires April 2003              [Page 10]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        Comment: Time is important from both a reporting and correlation
        point of view.  Time is one of main components that can identify the
        same Incident or attack if launched from many sites or distributed
        over the network.  Time is also essential to be able to track the
        life of an Incident including Incident exchange between CSIRTs in
        process of investigating.
     
     
        6.13. Time shall be reported as the local time and time zone offset
        from UTC.  (Note: See RFC 1902 for guidelines on reporting time.)
     
        Comment: For event correlation purposes, it is important that the
        manager be able to normalize the time information reported in the
        IODEF descriptions.
     
        6.14. The format for reporting the date must be compliant with all
        current standards for Year 2000 rollover, and it must have
        sufficient capability to continue reporting date values past the
        year 2038.
     
        Comment: It is stated in the purposes of the IODEF that the IODEF
        shall describe the Incident throughout its life-time.  In the case of
        archiving this duration might be unlimited.  Therefore,
        implementations that limit expression of time value (such as 2038
        date representation limitation in "Unix time") MUST be avoided.
     
        6.15. Time granularity in IO time parameters shall not be specified
        by the IODEF.
     
        Comment: The time data may be included into IODEF 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.
     
        6.16. The IODEF should provide the possibility to secure the
        confidentiality of the description content.
     
        The selected design should be capable of supporting a variety of
        encryption algorithms and must be adaptable to a wide variety of
        environments. However, to simplify technical implementations,
        implementers may choose to use confidentiality preserving methods and
        solutions external to Incident Object itself.
     
        Comment: IODEF Incident descriptions potentially contain sensitive or
        private information (such as forensic data (evidence data),
        passwords, or person/organisation identifiers) which would be of
        great interest to an attacker or malefactor.  Incident information
        normally will be stored on a networked computer, which potentially
        may be exposed to attacks (or compromised).  Incident information may
        be transmitted across uncontrolled network segments.  Therefore, it
        is important that the content be protected from unauthorised access
     
     Demchenko             Expires April 2003              [Page 11]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        and modification.  Furthermore, since the legal environment for
        privacy and encryption technologies are varied from regions and
        countries and change often, it is important that the design selected
        be capable of supporting a number of different encryption options and
        be adaptable by the user to a variety of environments. Additional
        measures may be undertaken for securing the Incident during
        communication but this issue is outside of IODEF scope as it implies
        more strict rules for IO archiving and storing in general.
     
        6.17. The IODEF should ensure the integrity of the description
        content.
     
        The selected design should be capable of supporting a variety of
        integrity mechanisms and must be adaptable to a wide variety of
        environments.
     
        Comment: Special measures should be undertaken to prevent malicious
        IO changes.
     
        Additional measures may be undertaken for securing the Incident
        during communication but this issue is outside of IODEF scope.
     
        6.18. The IODEF should ensure the authenticity of the Incident
        description content.
     
        Authenticity ensuring method should be also capable to provide non-
        repudiation of Incident report exchanged between communicating
        CSIRTs.
     
        Comment: Authenticity and accountability is needed by many teams,
        especially given the desire to automatically handle IOs, therefore it
        MUST be included in the IODEF.  Because of the importance of IO
        authenticity and non-repudiation to many teams and especially in case
        of communication between them, the implementation of these
        requirements is strongly RECOMMENDED.
     
        6.19. The IODEF description must support an extension mechanism
        which may be used by implementers.  This allows future
        implementation-specific or experimental data.  The implementer
        MUST indicate how to interpret any included extensions.
     
        Comment: Implementers might wish to supply extra data such as
        information for internal purposes or necessary for the particular
        implementation of their Incident handling system.  These data may be
        removed or not in external communications but it is essential to mark
        them as additional to prevent wrong interpretation by different
        systems.
     
     
        6.20. The semantics of the IODEF description must be well defined.
     
        Comment: IODEF is a human oriented format for Incident description,
        and IODEF description should be capable of being read by humans.  The
     
     Demchenko             Expires April 2003              [Page 12]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
        use of automatic parsing tools is foreseen but should not be
        critically necessary.  Therefore, IODEF must provide  good semantics,
        which will be  key to understanding what the description contains.
        In some cases the IODEF description will be used for  automatic
        decision making, so it is important that the description be
        interpreted correctly.  This is an argument for using language-based
        semantics. The metalanguage for IODEF identifiers and labels is
        proposed to be English, a local IODEF implementation might be able to
        translate metalanguage identifiers and labels into local language and
        presentations if necessary.
     
     7. IODEF extensibility
     
        7.1. The IODEF itself MUST be extensible.  It is essential that when
        the use of new technologies and development of automated Incident
        handling system demands extension of IODEF, the IODEF will be
        capable to include new information.
     
        Comment: In addition to the need to extend IODEF to support new
        Incident handling tools, it is also suggested that IODEF will
        incorporate new developments from related standardisation areas such
        as IDEF for IDS or the development of special format for evidence
        custody.  The procedure for extension should be based on CSIRT/IODEF
        community acceptance/approval.
     
     
     8. Security Considerations
     
        This memo describes requirements to an Incident Object Description
        and Exchange Format, which intends to define a common data format for
        the description, archiving and exchange of information about
        incidents between CSIRTs (including alert, incident in investigation,
        archiving, statistics, reporting, etc.).  In that respect the
        implementation of the IODEF is a subject to security considerations.
        Particular security requirement to access restriction indication is
        discussed in section 4.3, requirements to Incident description
        confidentiality, integrity, authenticity and non-repudiation are
        described in sections 6.16, 6.17, 6.18.
     
     
     9. Acknowledgements
     
        This document is a revision of RFC 3067 and provided for further open
        discussion of IODEF requirements that evolves in the process of IODEF
        design.
     
        All credits are given to initial authors of RFC3067 and past
        discussion in TERENA IODEF WG.
     
     10. References
     
        [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997
     
     Demchenko             Expires April 2003              [Page 13]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
     
        [2]  Arvidsson, J., Cormack, A., Demchenko, Y., Meijer J. "TERENA's
        Incident Object Description and Exchange Format Requirements", RFC
        3067, February 2001
     
        [3] TERENA IODEF WG - http://www.terena.nl/tech/task-forces/tf-
        csirt/iodef/
     
        [4] IETF INCH WG - http://www.ietf.org/html.charters/inch-
        charter.html
     
        [5] Incident Object Description and Exchange Format Data Model and
        Extensible Markup Language (XML) Document Type Definition û October
        2002. Work in progress.
     
        [6]  Taxonomy of the Computer Security Incident related terminology
        - http://www.terena.nl/task-forces/tf-csirt/iiodef/docs/i-
        taxonomy_terms.html
     
        [7]  Intrusion Detection Exchange Format Requirements by Wood, M.,
        Erlinger, M. - October 2002, Work in Progress.
     
        [8]  Guidelines for Evidence Collection and Archiving by Dominique
        Brezinski, Tom Killalea - July 2000, Work in Progress.
     
        [9]  Brownlee, N. and E. Guttman, "Expectations for Computer Security
        Incident Response", BCP 21, RFC 2350, June 1998.
     
        [10]  Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
        2000.
     
        [11]  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.
     
        [12] A Common Language for Computer Security Incidents by John D.
        Howard and Thomas A. Longstaff. - Sandia Report: SAND98-8667, Sandia
        National Laboratories -
        http://www.cert.org/research/taxonomy_988667.pdf
     
     
     
     13. AuthorsÆ Addresses:
     
        Yuri Demchenko
        TERENA
        Email: demch@chello.nl
     
     
     
     
     
     
     Demchenko             Expires April 2003              [Page 14]


     INTERNET DRAFT            IODEF Requirements             October, 2002
     
     Full Copyright Statement
     
        Copyright (C) The Internet Society (2000). All Rights Reserved.
     
        This document and translations of it may be copied and furnished to
        others, and derivative works that comment on or otherwise explain it
        or assist in its implementation may be prepared, copied, published
        and distributed, in whole or in part, without restriction of any
        kind, provided that the above copyright notice and this paragraph
        are included on all such copies and derivative works. However, this
        document itself may not be modified in any way, such as by removing
        the copyright notice or references to the Internet Society or other
        Internet organizations, except as needed for the purpose of
        developing Internet standards in which case the procedures for
        copyrights defined in the Internet Standards process must be
        followed, or as required to translate it into languages other than
        English.
     
        The limited permissions granted above are perpetual and will not be
        revoked by the Internet Society or its successors or assigns.
     
        This document and the information contained herein is provided on an
        "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
        TASK FORCE DISCLAIMS 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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Demchenko             Expires April 2003              [Page 15]
     

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