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

TERENA的事件对象描述和交换格式要求

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.

版权所有(C)互联网协会(2001年)。版权所有。

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.

事件对象描述和交换格式的目的是定义通用数据格式,用于描述、归档和交换CSIRT(计算机安全事件响应团队)之间的事件信息(包括警报、调查中的事件、归档、统计、报告等)。本文档描述了此类描述和交换格式的高级要求,包括这些要求的原因。必要时,使用示例来说明需求。

1. Conventions used in this document
1. 本文件中使用的公约

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

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。

2. Introduction
2. 介绍

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.

本文件定义了事故对象描述和交换格式(IODEF)的要求,该格式是TERENA事故分类工作组(ITDWG)的预期产品[2]。IODEF计划成为标准格式,允许CSIRT交换操作和统计信息;它还可以为开发用于事件记录、跟踪和交换的兼容和互操作工具提供基础。

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.

另一个目标是将IETF IDWG(目前专注于入侵检测交换格式和通信协议)的工作扩展到将事件描述为网络安全的更高级别元素。这将涉及CSIRT及其选区相关问题。

   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 <incident-taxonomy@terena.nl> or <iodef@terena.nl>, archives
   are available correspondently at
   http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and
   http://hypermail.terena.nl/iodef-list/mail-archive/
        
   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 <incident-taxonomy@terena.nl> or <iodef@terena.nl>, 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
2.1. 根本原因

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.

这项工作基于欧洲领先/先进的CSIRT之间以及第一社区之间建立合作和信息交流的尝试。这些CSIRT了解信息交换和合作在处理、跟踪和调查安全事件方面的优势。

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.

计算机事件正变得越来越分散和国际化,涉及许多跨国界、跨语言和跨文化的CSIRT。事件后信息和统计数据交换对于未来的事件预防和互联网安全改进非常重要。在所有这些情况下,信息交换的关键要素是事件(对象)描述的通用格式。

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.

在进一步的开发或实施中,IODEF可能用于法医目的,这意味着事件描述必须明确,并考虑到未来的保管(存档/文档)功能。

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.

开发IODEF的另一个目标问题是需要比IDS(入侵检测系统)和建议的IDEF(入侵检测交换格式)提供的更高级别的事件描述和交换格式。IODEF对模块化和可扩展性的要求将满足与IDEF和其他相关标准的兼容性。IODEF应与IDMEF垂直兼容,IODEF可能能够包含或引用IDMEF警报消息作为事件的初始信息。

2.2. Incident Description Terms
2.2. 事件描述术语

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

由TERENA的ITDWG[2]编制的计算机安全事件相关术语的分类在[12]中介绍。

2.2.1. Attack
2.2.1. 袭击

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
2.2.2. 攻击者

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

出于IODEF的目的,攻击者通过其网络ID、发起网络/计算机攻击的组织和物理位置信息(可选)进行描述。

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

IODEF中使用CSIRT(计算机安全事件响应团队)来指代处理事件和创建事件对象描述的机构。CSIRT还可能参与证据收集和保管、事件补救等。

In IODEF CSIRT represented by its ID, constituency, public key, etc.

在IODEF中,CSIRT由其ID、选区、公钥等表示。

2.2.4. Damage
2.2.4. 损坏

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
2.2.5. 事件

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.

针对目标的行动,旨在导致目标的状态(状态)改变。从事件起源的角度来看,可将其定义为系统或网络中导致产生警报的任何可观察事件。例如,10秒内三次失败的登录可能表示暴力登录攻击。

2.2.6. Evidence
2.2.6. 根据

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.

证据是与事件相关的信息,可以证明或支持关于事件的结论。关于安全事件(事件),它可能包括但不限于:入侵检测系统(IDS)创建的数据转储、来自系统日志文件的数据、内核统计信息、缓存、内存、临时文件系统或导致警报或在事件发生后收集的其他数据。

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
2.2.7. 发生的事情

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.

事件是IODEF的根元素。在IODEF的上下文中,术语事件用于表示计算机安全事件或IT安全事件。

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:

但是,我们应区分“事件”的一般定义,即可能导致损害或损害不太严重的事件,以及“安全事件”和“IT安全事件”,其定义如下:

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) 安全事件是指涉及安全违规的事件。这可能是违反安全政策、UAP、法律和司法管辖区等的事件。安全事件也可能是已升级为安全事件的事件。

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.

b) IT安全事件根据[9]定义为与计算机或计算机网络安全相关的任何真实或可疑的不利事件。IT领域内的典型安全事件包括:计算机入侵、拒绝服务攻击、信息盗窃或数据操纵等。

2.2.8. Impact
2.2.8. 影响

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
2.2.9. 目标

A computer or network logical entity (account, process or data) or physical entity (component, computer, network or internetwork).

计算机或网络逻辑实体(帐户、进程或数据)或物理实体(组件、计算机、网络或互联网)。

2.2.10. Victim
2.2.10. 受害者

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.

就IODEF而言,受害者通过其网络ID、组织和位置信息进行描述。

2.2.11. Vulnerability
2.2.11. 弱点

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 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
2.2.12. 其他术语

Other terms used: alert, activity, IDS, Security Policy, etc. - are defined in related I-Ds, RFCs and standards [3, 6, 7, 8, 9, 10].

使用的其他术语:警报、活动、ID、安全策略等-在相关的I-D、RFC和标准[3、6、7、8、9、10]中定义。

3. General Requirements
3. 一般要求

3.1. The IODEF shall reference and use previously published RFCs where possible.

3.1. IODEF应尽可能参考和使用先前发布的RFC。

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.

评论:IETF已经在网络和安全领域制定了许多标准,这些标准实际上已在当前的互联网中部署。现行标准为IODEF与其他相关技术的兼容性提供了框架,这些技术是在实践中操作/实施IODEF所必需的。IODEF的另一个兼容性问题是它与IETF IDEWG目前正在开发的IDEF的一般兼容性。为了时间和兼容性,应尽可能使用定义和接受的标准。

In particularly, IODEF specification proposals SHOULD rely heavily on existing communications, encryption and language standards, where possible.

特别是,在可能的情况下,IODEF规范建议应严重依赖现有的通信、加密和语言标准。

4. Description Format
4. 描述格式

4.1. IODEF shall support full internationalization and localization.

4.1. IODEF应支持完全国际化和本地化。

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.

注释:由于一些事件需要来自不同国家、文化和地理区域的CSIRT参与,因此必须对IODEF描述进行格式化,以便能够以当地语言向运营商呈现,并遵循当地呈现格式。

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.

虽然IODEF标识符和标签的元语言被认为是英语,但如果需要,本地IODEF实现可能能够将元语言标识符和标签翻译成本地语言和表示。

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

可能还需要本地化的日期、时间和名称。如果消息包含文本字符串和需要除拉丁语-1(或ISO 8859-1)以外的字符的名称,则最好使用ISO/IEC IS 10646-1字符集表示信息,并使用UTF-8转换格式进行编码,还可以选择使用本地字符集和编码[13]。

4.2. The IODEF must support modularity in Incident description to allow aggregation and filtering of data.

4.2. IODEF必须支持事件描述中的模块化,以允许数据的聚合和过滤。

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.

评论:建议IODEF的事件描述可能包括外部信息,例如来自IDS的信息,或参考外部存储的证据保管数据,或者出于隐私或安全目的,此类信息可能从当前IODEF描述中删除。这一要求的另一个实际/现实动机是,使一些CSIRT/经理能够对IODEF描述执行过滤和/或数据聚合功能,以便CSIRT和/或其支持者和赞助商之间进行统计、报告和高级事件信息交换。

Therefore the IODEF descriptions MUST be structured to facilitate these operations. This also implies to strong IODEF semantics.

因此,IODEF描述的结构必须便于这些操作。这也意味着要使用强IODEF语义。

4.3. IODEF must support the application of an access restriction policy attribute to every element.

4.3. IODEF必须支持对每个元素应用访问限制策略属性。

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.

备注:IODEF事件描述可能包含敏感或私人信息(如密码、人员/组织标识符或法医信息(证据数据)),在某些情况下可能会暴露给未经授权的人员。特别是在CSIRT或其他相关机构之间交换事件信息的情况下,可能会出现这种情况。某些情况下可以通过加密IODEF元素来解决,但是这并不总是可能的。

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.

因此,为了防止意外泄露敏感数据,IODEF对象的某些部分必须标记访问限制属性。当与自动处理系统一起使用时,这些标记将特别有用。

5. Communications Mechanisms Requirements
5. 通信机制要求

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

5.1. IODEF交换通常由人类使用标准通信协议启动,例如电子邮件、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.

注释:IODEF描述通常由人工使用特殊或标准文本编辑器创建。IODEF的目标是由自动事件处理系统处理,但仍然必须是人类可读的,能够使用标准工具(例如浏览器或电子表格处理器或MS Excel或Access等数据库工具)查看和浏览。事件信息交换通常需要操作员或CSIRT经理的授权,因此预计不会自动启动。事件处理系统的作用是为执行交换提供协助和工具。

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.

区分机器可读和可交换的IDEF入侵消息格式以及面向人和创建的IODEF事件描述的目的非常重要。

Communications security requirements will be applied separately according to local policy so are not defined by this document.

通信安全要求将根据当地政策单独应用,因此本文件未定义。

6. Message Contents
6. 消息内容

6.1. The root element of the IO description should contain a unique identification number (or identifier), IO purpose and default permission level

6.1. IO描述的根元素应包含唯一标识号(或标识符)、IO用途和默认权限级别

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.

注释:唯一标识号(或标识符)是区分一个事件和另一个事件所必需的。建议唯一标识号至少包含IO创建者的信息,即CSIRT或相关机构。事件的分类也可用于形成唯一的识别号。IO目的将实际控制IODEF对象中包含的元素。目的可能包括事件警报/登记、处理、归档、报告或统计。事件调查的目的、事件类型或状态可能需要不同级别的事件信息访问权限。

It is considered that root element of the IODEF will be <INCIDENT> and additional information will be treated as attributes of the root element.

我们认为IODEF的根元素将是<INCIDENT>,附加信息将被视为根元素的属性。

6.2. The content of the IODEF description should contain the type of the attack if it is known.

6.2. IODEF描述的内容应包含已知的攻击类型。

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.

如果事件类型尚未标准化,则团队创建的IO可能会给出临时类型定义。新的类型名应该是自解释的,并从类似的现有类型定义派生。

6.3. The IODEF description must be structured such that any relevant advisories, such as those from CERT/CC, CVE, can be referenced.

6.3. IODEF说明的结构必须确保可以引用任何相关咨询,例如来自CERT/CC、CVE的咨询。

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.

6.4. IODEF可能包括导致当前事件的攻击的详细描述。

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.

6.5. IODEF描述必须包括或能够参考与该特定基础事件/活动相关的额外详细数据,通常称为证据。

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

注释:出于许多目的,事件描述不需要关于导致事件的特定事件/活动的许多细节;此信息可以作为外部信息(通过URL)引用。在某些情况下,单独存储具有不同访问权限的证据可能比较方便。可以预见,将为证据保管提出另一个标准[5]。

6.6. The IODEF description MUST contain the description of the attacker and victim.

6.6. IODEF描述必须包含攻击者和受害者的描述。

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.

备注:此信息对于确定攻击源和目标是必要的。关于攻击者和受害者的最低信息是他们的IP或Internet地址,扩展信息将识别他们的组织,使CSIRT能够为他们的特定选区采取适当措施。

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.

6.7. IODEF描述必须支持不同类型设备地址的表示,例如IP地址(版本4或6)和Internet名称。

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.

注释:发起攻击的站点可能在网络协议层次结构的不同级别上具有地址(例如,数据层2 MAC地址或网络层3 IP地址)。此外,入侵事件中涉及的设备可能使用非以IP为中心的地址,例如ATM地址。也可以理解,关于攻击源和目标的信息可能从IDS获得,包括IP地址、MAC地址或两者。

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.

6.8. IODEF必须包含事件对象创建者的身份(CSIRT或其他机构)。这可能是信息交换中的发送者或当前处理事件的团队。

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.

6.9. IODEF描述必须包含此事件对目标可能产生影响的指示。如果攻击被认为是已知的,或者由负责的CSIRT团队成员以自由语言表示,则该字段的值应从标准化的值列表中提取。

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

注释:有关事件对目标系统可能产生的影响的信息提供了攻击者试图做什么的指示,是CSIRT采取行动和执行的关键数据

damage assessment. If no reference information (Advisories) is available, this field may be filled in based on CSIRT team experience.

损害评估。如果没有可用的参考信息(咨询),可根据CSIRT团队经验填写此字段。

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.

预计大多数CSIRT将根据现有咨询(如来自CERT/CC、CVE等的咨询)开发事件处理支持系统,这些咨询通常包含已识别攻击的可能影响列表。

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

这也与IDEF的开发有关,IDEF将在智能IDS中实现,能够从攻击和漏洞的标准数据库中检索信息[3]。

6.10. The IODEF must be able to state the degree of confidence in the report information.

6.10. IODEF必须能够说明报告信息的可信度。

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.

备注:在事件创建阶段,包括这些信息非常重要,尤其是在使用智能自动IDS或专家系统的情况下。它们通常使用统计引擎来估计事件概率。

6.11. The IODEF description must provide information about the actions taken in the course of this incident by previous CSIRTs.

6.11. IODEF说明必须提供有关先前CSIRT在此事件过程中采取的行动的信息。

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.

注释:IODEF描述了从警报到关闭和归档的整个生命周期内的事件。必须跟踪所有相关方采取的所有行动。这将有助于确定需要采取的进一步行动(如有)。在调查过程中,CSIRT之间的事件信息交换情况下,这一点尤为重要。

6.12. The IODEF must support reporting of the time of all stages along Incident life-time.

6.12. IODEF必须支持报告事件生命周期内所有阶段的时间。

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.

评论:从报告和关联的角度来看,时间都很重要。如果从多个站点发起或分布在网络上,时间是可以识别相同事件或攻击的主要组件之一。时间对于跟踪事件的生命周期(包括调查过程中CSIRT之间的事件交换)也至关重要。

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

6.13. 时间应报告为当地时间和时区与UTC的偏移量。(注:有关报告时间的指南,请参见RFC 1902。)

Comment: For event correlation purposes, it is important that the manager be able to normalize the time information reported in the IODEF descriptions.

注释:出于事件关联的目的,管理器必须能够规范化IODEF描述中报告的时间信息。

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.

6.14. 报告日期的格式必须符合2000年过渡的所有现行标准,并且必须有足够的能力继续报告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.

注释:IODEF的目的是说明IODEF应在整个生命周期内描述事件。在存档的情况下,此持续时间可能是无限的。因此,必须避免限制时间值表达式的实现(例如“Unix时间”中的2038日期表示限制)。

6.15. Time granularity in IO time parameters shall not be specified by the IODEF.

6.15. IODEF不应指定IO时间参数中的时间粒度。

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.

注释:时间数据可能由现有信息系统包含在IODEF描述中,从事件报告消息中检索,或从IDS数据或其他事件注册工具中获取。每种情况都可能有自己不同的时间粒度。为了实现的目的,应该能够根据本地系统能力在不同阶段处理时间。

6.16. The IODEF should support confidentiality of the description content.

6.16. IODEF应支持描述内容的保密性。

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

备注:IODEF事件描述可能包含攻击者或罪犯非常感兴趣的敏感或私人信息(如法医数据(证据数据)、密码或个人/组织标识符)。事件信息通常存储在网络计算机上,可能会受到攻击(或受到破坏)。事件信息可通过不受控制的网段传输。因此,保护内容免受未经授权的访问和修改非常重要。此外,由于隐私权的法律环境

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.

加密技术因地区和国家而异,并且经常发生变化。因此,所选设计必须能够支持多种不同的加密选项,并由用户适应各种环境,这一点很重要。在通信过程中,可能会采取其他措施来保护事件的安全,但该问题超出了IODEF的范围,因为它意味着IO归档和存储的一般规则更加严格。

6.17. The IODEF should ensure the integrity of the description content.

6.17. IODEF应确保描述内容的完整性。

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.

备注:应采取特殊措施防止恶意IO更改。

Additional measures may be undertaken for securing the Incident during communication but this issue is outside of IODEF scope.

在通信期间,可采取额外措施确保事件安全,但该问题不在IODEF范围内。

6.18. The IODEF should ensure the authenticity and non-repudiation of the message content.

6.18. IODEF应确保消息内容的真实性和不可否认性。

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.

评论:许多团队都需要真实性和责任感,特别是考虑到自动处理IOs的愿望,因此必须将其包括在IODEF中。由于IO真实性和不可否认性对许多团队的重要性,特别是在团队之间进行通信的情况下,强烈建议实施这些要求。

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.

6.19. IODEF描述必须支持可由实现者使用的扩展机制。这允许将来实现特定数据或实验数据。实现者必须指明如何解释任何包含的扩展。

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.

6.20. 必须很好地定义IODEF描述的语义。

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.

注释:IODEF是一种面向人的事件描述格式,IODEF描述应该能够被人阅读。自动解析工具的使用是可以预见的,但不应该是非常必要的。因此,IODEF必须提供良好的语义,这将是理解描述所包含内容的关键。在某些情况下,IODEF描述将用于自动决策,因此正确解释描述非常重要。这是一个使用基于语言的语义的论点。IODEF标识符和标签的元语言建议为英语,如果需要,本地IODEF实现可能能够将元语言标识符和标签翻译为本地语言和表示。

7. IODEF extensibility
7. IODEF可扩展性

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.

7.1. IODEF本身必须是可扩展的。当新技术的使用和自动化事件处理系统的开发需要扩展IODEF时,IODEF将能够包含新信息,这一点至关重要。

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.

评论:除了需要扩展IODEF以支持新的事件处理工具外,还建议IODEF将纳入相关标准化领域的新发展,如ID的IDEF或证据保管特殊格式的开发。延期程序应基于CSIRT/IODEF社区接受/批准。

8. Security Considerations
8. 安全考虑

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.

本备忘录描述了事件对象描述和交换格式的要求,旨在定义一种通用数据格式,用于描述、归档和交换CSIRT之间的事件信息(包括警报、调查中的事件、归档、统计、报告等)。在这方面,IODEF的实施取决于安全考虑。第4.3节讨论了访问限制指示的特殊安全要求,第6.16、6.17、6.18节描述了事件描述的保密性、完整性、真实性和不可否认性要求。

9. References
9. 工具书类

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

[1] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

   [2]  Incident Taxonomy and Description Working Group Charter -
        http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/
        
   [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.

[3] Wood提出的入侵检测交换格式要求,M.-2000年12月,正在进行中。

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

[4] 入侵检测消息交换格式可扩展标记语言(XML)文档类型定义,D.Curry,H.Debar,2001年2月,正在进行中。

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

[5] 多米尼克·布雷津斯基(Dominique Brezinski,Tom Killalea)的证据收集和归档指南——2000年7月,正在进行中。

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

[6] Brownlee,N.和E.Guttman,“对计算机安全事件响应的期望”,BCP 21,RFC 23501998年6月。

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

[7] Shirey,R.,“互联网安全词汇表”,供参考36,RFC 28282000年5月。

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

[8] 建立计算机安全事件响应能力(CSIRC)。NIST特别出版物800-3,1991年11月

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

[9] 计算机安全事故响应小组(CSIRT)手册,莫伊拉·J·西布朗,唐·斯蒂克沃特,克劳斯·彼得·科萨科夫斯基。-CMU/SEI-98-HB-001-宾夕法尼亚州匹兹堡:卡内基梅隆大学,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
        
   [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
        
   [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
        
   [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/
        
   [13] Multilingual Support in Internet/IT Applications. -
        http://www.terena.nl/projects/multiling/
        

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 <incident-taxonomy@terena.nl> or <iodef@terena.nl>,
   archives are available correspondently at
   http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ and
   http://hypermail.terena.nl/iodef-list/mail-archive/
        
   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 <incident-taxonomy@terena.nl> or <iodef@terena.nl>,
   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

Jimmy Arvidsson Telia证书

   EMail: Jimmy.J.Arvidsson@telia.se
        
   EMail: Jimmy.J.Arvidsson@telia.se
        

Andrew Cormack JANET-CERT

Andrew Cormack JANET-CERT

   EMail: Andrew.Cormack@ukerna.ac.uk
        
   EMail: Andrew.Cormack@ukerna.ac.uk
        

Yuri Demchenko TERENA

尤里·德姆琴科·特雷娜

   EMail: demch@terena.nl
        
   EMail: demch@terena.nl
        

Jan Meijer SURFnet

Jan Meijer冲浪网

   EMail: jan.meijer@surfnet.nl
        
   EMail: jan.meijer@surfnet.nl
        

Full Copyright Statement

完整版权声明

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

版权所有(C)互联网协会(2001年)。版权所有。

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.

RFC编辑功能的资金目前由互联网协会提供。