rfc3067.txt

最新的RFC

   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.





Arvidsson, et al.            Informational                      [Page 6]

RFC 3067                   IODEF Requirements              February 2001


   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 [13].

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 attribute to every element.

   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.  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.






Arvidsson, et al.            Informational                      [Page 7]

RFC 3067                   IODEF Requirements              February 2001


5. Communications Mechanisms Requirements

5.1. IODEF exchange will normally be initiated by humans using
     standard communication protocols, for example, e-mail, WWW/HTTP,
     LDAP.

   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 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.






Arvidsson, et al.            Informational                      [Page 8]

RFC 3067                   IODEF Requirements              February 2001


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
   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].



Arvidsson, et al.            Informational                      [Page 9]

RFC 3067                   IODEF Requirements              February 2001


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 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 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.

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





Arvidsson, et al.            Informational                     [Page 10]

RFC 3067                   IODEF Requirements              February 2001


   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 [3].

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.

   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.








Arvidsson, et al.            Informational                     [Page 11]

RFC 3067                   IODEF Requirements              February 2001


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