rfc3067.txt

最新的RFC

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

   Comment:
   IODEF Incident descriptions potentially contain sensitive or private
   information (such as forensic data (evidence data), passwords, or
   persons/organisations 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 and
   modification.  Furthermore, since the legal environment for privacy



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


   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 and non-repudiation
      of the message content.

   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.







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


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








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


9. References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Incident Taxonomy and Description Working Group Charter -
        http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/

   [3]  Intrusion Detection Exchange Format Requirements by Wood, M. -
        December 2000, Work in Progress.

   [4]  Intrusion Detection Message Exchange Format Extensible Markup
        Language (XML) Document Type Definition by D. Curry, H. Debar -
        February 2001, Work in Progress.

   [5]  Guidelines for Evidence Collection and Archiving by Dominique
        Brezinski, Tom Killalea - July 2000, Work in Progress.

   [6]  Brownlee, N. and E. Guttman, "Expectations for Computer Security
        Incident Response", BCP 21, RFC 2350, June 1998.

   [7]  Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
        2000.

   [8]  Establishing a Computer Security Incident Response Capability
        (CSIRC). NIST Special Publication 800-3, November, 1991

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

   [10] 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

   [11] Best Current Practice of incident classification and reporting
        schemes currently used by active CSIRTs. -
        http://www.terena.nl/task-forces/tf-csirt/i-
        taxonomy/docs/BCPreport1.rtf

   [12] Taxonomy of the Computer Security Incident related terminology -
        http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/i-
        taxonomy_terms.html

   [13] Multilingual Support in Internet/IT Applications. -
        http://www.terena.nl/projects/multiling/



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


Acknowledgements:

   This document was discussed at the Incident Taxonomy and Description
   Working Group seminars (http://www.terena.nl/task-forces/tf-
   csirt/tf-csirt000929prg.html#itdwg) in the frame of TERENA Task Force
   TF-CSIRT (http://www.terena.nl/task-forces/tf-csirt/).  Incident
   Taxonomy and Description Working Group at TERENA can be contacted via
   the mailing lists <[e-mail]> or <[e-mail]>,
   archives are available correspondently at
   http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and
   http://hypermail.terena.nl/iodef-list/mail-archive/

Authors' Addresses

   Jimmy Arvidsson
   Telia CERT

   EMail: [e-mail]


   Andrew Cormack
   JANET-CERT

   EMail: [e-mail]


   Yuri Demchenko
   TERENA

   EMail: [e-mail]


   Jan Meijer
   SURFnet

   EMail: [e-mail]















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


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Arvidsson, et al.            Informational                     [Page 17]