rfc3067.txt

RFC 的详细文档！

Network Working Group                                       J. Arvidsson
Request for Comments: 3067                                    Telia CERT
Category: Informational                                       A. Cormack
                                                              JANET-CERT
                                                            Y. Demchenko
                                                                  TERENA
                                                               J. Meijer
                                                                 SURFnet
                                                           February 2001


 TERENA's Incident Object Description and Exchange Format Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

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












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


2. Introduction

   This document defines requirements for the Incident object
   Description and Exchange Format (IODEF), which is the intended
   product of the Incident Taxonomy Working Group (ITDWG) at TERENA [2].
   IODEF is planned to be a standard format which allows 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.

   Another aim is to extend the work of IETF IDWG (currently focused on
   Intrusion Detection exchange format and communication protocol) to
   the description of incidents as higher level elements in Network
   Security.  This will involve CSIRTs and their constituency related
   issues.

   The IODEF set of documents of which this document is the first will
   contain IODEF Data Model and XML DTD specification.  Further
   discussion of this document will take place in the ITDWG 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/

2.1. Rationale

   This work is based on attempts to establish cooperation and
   information exchange between leading/advanced CSIRTs in Europe and
   among the FIRST community.  These CSIRTs understand the advantages of
   information exchange and cooperation in processing, tracking and
   investigating security incidents.

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








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


   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 IDEF
   (Intrusion Detection Exchange Format).  Compatibility with IDEF 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.

   Taxonomy of the Computer Security Incident related terminology made
   by TERENA's ITDWG [2] is presented in [12].

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




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


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.




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


   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.



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


   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
   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 [3, 6, 7, 8, 9, 10].

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 IDEF currently being developed by IETF
   IDEWG.  In the interest of time and compatibility, defined and
   accepted standards should be used wherever possible.