RFC3093_防火墙增进协议 (FEP)

组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：郝国生（booking  gs_hao@263.net）  译文发布时间：2002-1-18 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。

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事件对象描述和转换格式要求  (RFC3067―TERENA's Incident Object Description and Exchange Format equirements)

备忘录状态 该备忘录专为Internet 组织提供信息。它不指定任何类型的Internet 标准。本备忘录的 发行不受任何限制。 版权声明 Copyright (C) The Internet Society (2001).  All Rights Reserved. 摘要 事件对象描述和转换格式的目的是要定义通用数据格式，该数据格式用于CSIRTs（计 算机安全事件响应组）（包括：报警、事件调查、存档、统计、报告等）之间事件信息的描 述、存档和转换。本文献描述了对于这样一种事件对象描述和转换格式的高级要求，包括那 些要求的原因。并在必要的地方引用例子对这些要求进一步解释。 目录 1本文献约定使用 3 2介绍 3 2.1基本原理 3 2.2事件描述术语 4 2.2.1攻击 4 2.2.2攻击者 4 2.2.3 CSIRT 4 2.2.4损害 4 2.2.5事件（Event） 4 2.2.6证据 5 2.2.7事件（Incident） 5 2.2.8效果 5 2.2.9目标 5 2.2.10受害者 6 2.2.11缺陷 6 2.2.12其它术语 6 3综合要求 6 4描述格式 6 4.1 IODEF将支持完全国际化和地方化 6 4.2 IODEF必须支持事件描述的模块化以允许数据集合与过滤 7 4.3 IODEF必须支持对每一个元件访问限制策略的应用 7 5通信机制要求 7 IODEF转换将通常由使用标准协议的人发起，例如，e-mail, WWW/HTTP, 7 6信息内容 8 6.1 IO描述的根部件应当包括唯一的辨别数字（或者标识符）、IO目标以及缺省许 可级别 8 6.2 IODEF描述的内容应当包括攻击的类型，如果攻击是可知的 8 6.3 IODEF描述必须结构化以便那些诸如来自CERT/CC, CVE的任何相关的咨询都 可以涉及到 8 6.4 IODEF可以包括引起当前事件攻击的详细描述 8 6.5 IODEF描述必须包括或者能够涉及与明确的优先事件/行为相关的额外详细数 据以及经常提到的证据 9 6.6 IODEF描述必须包括对攻击者和受害者的描述 9 6.7 IODEF描述必须支持设备地址不同类型的表述，例如IP地址（版本4.0或6.0） 和国际互联网名称 9 6.8 IODEF必须包括事件对象创建者（CSIRT或其他权威）的身份 9 6.9 IODEF描述必须包括事件对目标可能影响的说明 9 6.10 IODEF必须能够声明在报告信息中的可信度 10 6.11 IODEF描述必须提供关于事件过程中以前的CSIRTs采取措施的信息 10 6.12 IODEF必须支持沿事件生命周期全阶段的时间报告 10 6.13 时间应视作当地时间和来自UTC的时区偏移 10 6.14 报告日期的格式必须适应全部的当前标准2000年翻转法，并且必须有足够的 容量持续记录直到2038年的日期有效值 10 6.15 IO时间参数中的时间间隔尺寸将不由IODEF确定 11 6.16 IODEF应当支持描述内容的机密性 11 6.17 IODEF应当确保描述内容的完整性 11 6.18 IODEF应当确保信息内容的真实性和非批判性 11 6.19 IODEF描述必须支持可能被执行者使用的扩展机制 11 6.20 必须适当定义IODEF描述的语义学 12 7 IODEF扩展性 12 IODEF自身必须是可扩展的 12 8 安全考虑 12 9 参考文献 12 致谢 13 作者地址 14 全部版权声明 14 认证 14

1本文献约定使用 在本文献中使用的关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" 将按照在 RFC 2119 [1]中所描述的那样来解释。 2介绍 本文献定义了事件对象描述和转换格式(IODEF)的要求，这些要求是事件分类工作组 (ITDWG) 在TERENA [2]方面所期望的产物。IODEF计划将成为一种标准，该标准允许 CSIRTs转换可操作和可统计的信息。这一标准也可能为兼容的和可互联操作工具的发展提 供一种基础，这些工具则用于事件记录、跟踪和转换。 另一个目标是把IETF IDWG的工作（当前主要集中在侵入检测转换格式和通讯协议两 方面）扩展到和网络安全中较高级元件相同事件的描述。这一方案将涉及到CSIRTs以及与 他们的支持者相关的诸多问题。 本文献将第一次包括文献类的IODEF设置，IODEF数据模版和XML DTD说明。关于 该文献进一步的讨论请与以下邮件地址联系：incident-taxonomy@terena.nl或者  iodef@terena.nl ，相关文档可以通过以下网址得到： http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/  以及 http://hypermail.terena.nl/iodef-list/mail-archive/ 。 2.1基本原理 工作是以试图建立合作和信息转换为基础的，该合作以及信息转换将在欧洲最主要的/ 高级的CSIRTs和FIRST团体之间完成。这些CSIRTs懂得信息转换以及合作在处理、跟 踪和调查安全事件中的优势所在。 计算机事件正在逐渐变为分布式和国际化的事件，许多CSIRTs事件突破了国界、语言 和文化的约束。对于未来事件的预防和国际互联网安全性的改善来说，邮递事件信息以及统 计学转换便显得尤为重要。在所有这些事件中，信息转换的关键因素在于事件（对象）描述 的通用格式方面。 IODEF的进一步发展或者执行可能会用于辩论的目的，这意味着事件描述必须明确，并 且允许将来保管（档案/文件）这些特征。 把开发IODEF作为目标的另一方面原因是需要有比IDS（侵入检测系统）将要提出的和 IDEF（侵入检测转换格式）所建议的更高水平的事件描述和转换格式。与IDEF以及其他相 关标准的兼容性将由IODEF对模块化和扩展性的要求给予满足。IODEF应当与IDMEF纵 向兼容，IODEF可以能够包括或者参照IDMEF报警信息作为关于事件的初始信息。 2.2事件描述术语 下面清楚地给出了本文献其余部分所使用主要术语的定义。 其中，可能使用一些现有的定义。许多定义需要附加细节和进一步考虑。 由TERENA's ITDWG [2]创建的计算机安全事件相关术语分类法在[12]中被介绍。 2.2.1攻击 是指对系统安全的侵袭，这种袭击来源于一种智能威胁，例如，经过深思熟虑试图躲避 安全服务、避开系统安全策略的这样一种智能行为。 攻击可能是主动的也可能是被动的，可能是内部知情人员也可能是外部毫不相关人员， 或者是经由攻击的中间人员。 2.2.2攻击者 攻击者是指为达到某种（些）目的而尝试一次或多次攻击的个别人员。 对于IODEF的目的，可通过其网络身份来描述攻击者，网络身份组织是引起网络/计算 机攻击和物理位置信息（任意）的所在。 2.2.3 CSIRT CSIRT（计算机安全事件响应序列）在IODEF被用于提及权威人士处理事件和创建事件 对象描述。CSIRT也可能涉及到证据的收集和保管以及事件维护等。 在IODEF CSIRT中通过其身份、支持者、公共键等呈现出来。 2.2.4损害 是指影响目标系统或服务正常操作的攻击所产生的有意或无意后果。损害描述可以包括 实际攻击效果免费文本描述，如果可能，还会包括独特被破坏的系统、子系统或者服务的结 构化信息。 2.2.5事件（Event） 是指直接面对目标的一种行为，这种行为会趋向于引起目标状态（情形）的变化。从事 件起源的观点来看，该术语可以被定义为系统或网络中任何可见事件，而该事件会导致即将 产生的报警事件的发生。例如，在10秒钟时间内连续3次登录失败，就可能显示强行登录 攻击事件。 2.2.6证据 证据是指与事件相关的信息，该信息用来证明或支持关于事件的结论。对于安全事件（事 件），可能包括以下内容，但不局限于以下内容：由侵入检测系统(IDS)创建的数据累积、来 自系统日志文件的数据、要点统计、高速缓存、存储、临时文件系统或者其它引起报警或在 事件发生后收集的数据。 当存储、存档证据的时候必须采用专用的规则，必须十分小心，特别要保护证据的完整 性。必要的时候，证据应当加密存储。 根据证据收集和存档的指导方针，证据必须被严格保护。一系列证据保管需要被清楚证 明。 根据当地的法律进行收集、存档和保护证据是必不可少的。 2.2.7事件（Incident） 该术语是指涉及到安全违例的安全事件。事件可以定义为单个或群体攻击，无论单个或 群体攻击都可以通过攻击方法区分开来，如攻击者身份、受害者、地点、目标或定时等。 事件是指IODEF的根组件。在IODEF的上下文中，所使用的术语事件是指计算机安全 事件或者IT安全事件。 然而我们应当在事件的真正定义之间加以区分，事件Incident是指可能引起损害或者损 害不太严重的事件event，接下来给出安全事件、IT安全事件的定义。 a) 安全事件incident是指涉及安全违例的事件event。这可能是指违反安全策略、 UAP、规则以及权限等的事件event。安全事件incident也可能是指已经升级到安 全事件的事件incident。安全事件比事件incident对安全或组织中的影响更糟糕。 安全事件可能是逻辑的、物理的或者组织的，例如计算机入侵、秘密暴露、信息丢 失、火警或者不能正常工作的警报等。安全事件可能是有目的的引起，也可能是不 经意间产生。后者产生的可能情况是忘记锁门或者忘记激活路由器中的访问列表。 b) IT安全事件根据[9]定义为任何真实的或令人怀疑的与计算机或计算机网络安全相 关的不利事件event。在IT领域的典型安全事件是：计算机入侵、拒绝服务攻击、 信息丢失或者数据非法操作等。 2.2.8效果 效果用来根据用户群体所表述的描述攻击的结果，例如财政方面的花费或者其他破坏。 2.2.9目标 是指计算机或者网络逻辑实体（说明、进程或数据）或物理实体（组件、计算机、网络 或国际互联网）。 2.2.10受害者 受害者是指遭受攻击的个人或组织，这种攻击在事件报告中给予描述。 对于IODEF的这种目的，受害者可以通过其网络身份、组织以及位置信息来描述。 2.2.11缺陷 是指在系统的设计、执行或者操作、管理中的缺点或弱点，这些缺点或弱点可能会引起 违反系统的安全策略的事件发生。 大多数系统都有某些类型的缺陷，但是这并不意味着系统太差而不能使用。并不是每一 次攻击都会产生致命的结果，也并不是每一次攻击都会成功。成功攻击取决于缺陷的程度、 攻击的力度以及采用对策的有效度。如果攻击需要突破的缺陷非常难于逾越，那么这样的缺 陷是可以容忍的。如果对于攻击者来说仅得到非常小的利益，那么甚至容易被突破的缺陷也 是可以接受的。然而，如果攻击容易理解，易于实施，并且易受到攻击的系统被大范围内的 用户突破，那么实施攻击的人极有可能会得到足够多的利益。 2.2.12其它术语 其它使用的术语有：报警、行为、IDS、安全策略等，它们在相关的I-Ds, RFCs 和  standards [3, 6, 7, 8, 9, 10]中被定义。 3综合要求 IODEF将可能涉及和使用当前出版的RFCs 。 评论 IETF已经在网络和安全领域开发了大量的标准，这些标准已经在目前的国际互联网中得 到实际配置。考虑到当前的标准为IODEF和其它相关技术的兼容性提供框架，有必要在实 际中操作/执行IODEF。对于IODEF兼容性的另一个问题，是当前IETF IDEWG正在开发 的与IDEF的兼容性。出于对时间和兼容性的考虑，已定义的和公认的标准应当在任何可能 的地方使用。 特别地，IODEF分类协议应当主要依靠现有的计算机通讯、加密技术和语言标准，当然， 如果可能的话。 4描述格式 4.1 IODEF将支持完全国际化和地方化 评论 既然许多事件需要来自不同国家、不同文化、不同地理区域CSIRTs的参与，因此必须 形成IODEF描述，以便这些事件可以被使用地方语言并坚持采用地方陈述方式的操作员引 用。 尽管对于IODEF标识符和标签的分析语言考虑采用英语，但是如果有必要的话，地方 IODEF的执行可以把分析语言标识符和标签翻译成当地语言并给予陈述。 可能也需要日期、时间、名称的地方化表述。在信息包括文本串和名称的情况下就需要 不同于Latin-1(or ISO 8859-1)的特点，信息应当更适宜使用ISO/IEC IS 10646-1字符集被 重新提出，应用UTF-8转换格式进行编码，并且可以自由使用地方字符集和编码[13]。 4.2 IODEF必须支持事件描述的模块化以允许数据集合与过滤 评论 这表明带有IODEF的事件描述可以包括外部信息，例如，来自IDS或者涉及外部存储 证据保管数据，或者可能从当前IODEF描述被除去的那些信息，比如秘密和安全目的。对 于该要求的另一种实际/真实目的在于为CSIRTs/管理者提供可能性，用以实现对IODEF 描述的过滤和/或数据集合功能，而IODEF描述则是为了统计、报告以及CSIRTs和/或他 们的支持者和赞助者之间的高水平事件信息转换。 因此IODEF描述必须结构化以简化这些操作。这也意味着要加强IODEF语义学。 4.3 IODEF必须支持对每一个元件访问限制策略的应用 评论 IODEF事件描述潜在地包括敏感和私人信息（例如密码、个人/组织标识符或者辩论信息 （证据数据）），在某些情况下这些信息可能会暴露给未经授权的个人。特别地，在CSIRTs 或者其他涉及到的实体之间进行事件信息转换的情况下，这样的情形可能会出现。在某些情 况下可以通过加密IODEF组件来完成处理，然而事情不可能总是这样。 因此，为了防止敏感数据的意外泄漏，IODEF对象的部分必须用访问限制属性来标记。 当和自动操作处理系统一起使用的时候这些标记将会非常有用。 5通信机制要求  IODEF转换将通常由使用标准协议的人发起，例如，e-mail,  WWW/HTTP, LDAP. 评论 IODEF描述通常是由使用专用的或标准的文本编辑器的人创建的。IODEF以通过自动操作 事件处理系统实现处理为目标，但是对于人来说仍然必须是易读、可见和可用标准工具（例 如，浏览器或电子桌面处理器或类似于微软Excel 或者Access的数据库工具）浏览的。事 件信息转换将通常需要操作人员或者CSIRT管理人员的认可，因此并不是期望的那样自动 发起。事件处理系统的作用是为实现转换提供帮助和工具。 把机制易读、可交换的IDEF侵入信息格式、人员导向和创建IODEF事件描述各自的目 的区分开来是非常重要的。 通信安全要求根据地方策略将单独应用，因此在本文献中没有给出定义。 6信息内容 6.1 IO描述的根部件应当包括唯一的辨别数字（或者标识符）、IO目 标以及缺省许可级别 评论 唯一的辨别数字（或者标识符）对于把一个事件与另一个事件区分开来是非常必要的。 这意味着唯一的辨别数字将至少包括关于IO创建者的信息，例如CSIRT或相关实体。事件 的分类也可能被用来形成唯一的辨别数字。IO目的是将实际控制那些包含在IODEF对象中 的元件。这些目的可能包括事件报警/注册、事件处理、存档、报告或统计。目的、事件类 型或事件研究的状态可能需要事件信息访问许可的不同级别。 IODEF的根元件将看作事件，而额外的信息将被看作根元件的属性。 6.2 IODEF描述的内容应当包括攻击的类型，如果攻击是可知的 期望攻击类型能够从事件的标准列表中提取到，如果事件的类型还没有被标准化，则事 件的新类型可以使用暂时实行的特别类型。 评论 事件处理可能会涉及到许多不同的职员成员或工作组。因此必不可少地使用通用术语来 描述事件。 如果事件类型还没有标准化，暂时的类型定义可以由IO的创建组提供。期望新的类型名 将会是自解释性的并且来自类似现有的类型定义。 6.3 IODEF描述必须结构化以便那些诸如来自CERT/CC, CVE的任 何相关的咨询都可以涉及到 评论 使用标准咨询以及可知攻击和缺陷的列表将允许应用它们对事件处理/预防的评论。这样 的信息可能会作为攻击或缺陷类型定义的属性被包括进来。 6.4 IODEF可以包括引起当前事件攻击的详细描述 评论 攻击的描述包括关于攻击者和受害人的信息、攻击的表现现象以及可能的影响。在侵入 的初期阶段，报警和事件处理可能是最小的信息，在事件的处理过程中，对于事件调查和补 救来说这一信息将会逐渐变得足够大。元件攻击应当是事件描述的主要部分之一。 6.5 IODEF描述必须包括或者能够涉及与明确的优先事件/行为相关 的额外详细数据以及经常提到的证据 评论 许多目的事件描述并不需要导致事件发生的明确事件/行为的详细信息，这种信息可以被 参考作外部信息（通过URL方式）。在某些情况下可以方便地分别存储有不同访问许可的证 据。可以预测另一个将要被提议的标准针对证据保管[5]。 6.6 IODEF描述必须包括对攻击者和受害者的描述 评论 为了辨别攻击的来源和目标，信息是所必需的。关于攻击者和受害者的最少信息是他们 的IP或者网络地址，扩展信息将识别他们的组织，允许CSIRTs为他们的独特支持者采取 适当的保护措施。 6.7 IODEF描述必须支持设备地址不同类型的表述，例如IP地址（版 本4.0或6.0）和国际互联网名称 评论 发起攻击的站点可能在网络协议层的不同层次（例如，数据层2 MAC地址，网络层3 IP 地址）都有地址。另外，涉及到入侵事件的设备可以使用非IP中央的地址，例如ATM地址。 容易理解，关于攻击的来源和目标的信息可以从IDS中得到，并且包括IP地址或MAC地 址，或者两者都有。 6.8 IODEF必须包括事件对象创建者（CSIRT或其他权威）的身份 这可能是信息转换的发送者或当前处理事件的队列。 评论 事件描述创建者的身份对于事件响应来说通常是有价值的信息。在某一种可能的情况下， 攻击可能贯穿整个网络取得进展，通过比较不同权威记录的相应事件可能会获得某些关于攻 击来源的额外信息。这也是在传递事件信息处理/转换阶段的有用信息。 6.9 IODEF描述必须包括事件对目标可能影响的说明 如果攻击被看作是可知的，或者是由可靠CSIRT组成员用公开语言表述的，则该领域的 价值应当从标准列表的评价中得出。 评论 关于事件对目标可能影响的信息，系统提供对攻击者试图所要做的说明，提供CSIRTs 用来完成损害评估的关键数据的说明。如果没有可靠的参考信息（咨询委员会），该领域可 以基于CSIRT工作组的经验予以实现。 根据当今的资讯委员会（例如，那些来自CERT/CC, CVE等），预计大多数CSIRTs将 会开发事件处理支持系统。这些咨询委员会通常包括识别攻击可能影响的列表。 这也与IDEF的开发有关，IDEF将会在智能IDS中得以实现，并能够从遭受攻击和带有 缺陷的标准数据库中重新找回信息[3]。 6.10 IODEF必须能够声明在报告信息中的可信度 评论 在事件的创建阶段包含这一信息是必不可少的，特别是在智能自动化IDS或专用系统被 使用的情况下。这些通常使用统计方法用来估计事件的可能性。 6.11 IODEF描述必须提供关于事件过程中以前的CSIRTs采取措施 的信息 评论 IODEF对事件的描述贯穿其始终，从报警开始一直到结束和存档。跟踪全部相关成员采 取的措施是必不可少的。这将有助于确定进一步采取什么样的措施，如果需要的话。这对于 在CSIRTs调查过程之间的事件信息转换来说尤其重要。 6.12 IODEF必须支持沿事件生命周期全阶段的时间报告 评论 从报告和意见的相关点来说时间都是非常重要的。如果事件或攻击来自许多个站点或遍 布整个互联网络，时间是能够辨别相同事件或攻击的主要组成部分之一。对于能够跟踪事件 的全过程来说事件也是不可或缺的，这事件包括在CSIRTs调查过程之间的事件转换。 6.13 时间应视作当地时间和来自UTC的时区偏移 （注意：参见RFC 1902报告时间指导方针） 评论 对于事件相关性目的来说，管理者能够规范化记录在IODEF描述中的时间信息是非常重 要的。 6.14 报告日期的格式必须适应全部的当前标准2000年翻转法，并 且必须有足够的容量持续记录直到2038年的日期有效值 评论 由IODEF的目标所确定，IODEF将贯穿描述事件的整个生命周期。在事件存档的情况 下，这一持续时间可以是无限的。因此，必须避免限制时间有效值（例如，在"Unix time" 中注明2038日期表述限制）表达的执行。 6.15 IO时间参数中的时间间隔尺寸将不由IODEF确定 评论 通过现有的信息系统IODEF描述可以包括时间数据，重新找回事件报告信息或者从IDS 数据中得到或者是其它的注册工具。这些事件中的每一种都可以有它自己不同的时间间隔尺 寸。为了实现这一目的，根据当地系统的性能应该可以在不同的阶段处理时间。 6.16 IODEF应当支持描述内容的机密性 所选的设计应该能够支持加密算法的多样性和必须适应环境的广泛多样性。 评论 IODEF事件描述潜在地包含敏感和私人信息（例如，辩论数据（证据数据）、密码或者 个人/组织标识符等），这些信息对攻击者或犯罪分子有着极大诱惑力。事件信息通常会存储 在网络化的计算机上，而网络化的计算机可能潜在地暴露给攻击者。事件信息可以通过不受 控制的网段进行传送。因此，防止内容被未经授权访问和修改是非常重要的。另外，由于隐 私和加密技术会随着地区和国家的不同而有所差别，并且经常发生变化，所以，已选择的设 计能够支持大量的加密选项并可以适应用户和环境的多样性是非常重要的。为确保通信过程 中事件的安全，可采用额外的措施，但是这个问题超出了IODEF的范围，因为这意味着IO 的常规存档和存储会有更多的规则。 6.17 IODEF应当确保描述内容的完整性 所选的设计应当能够支持完整性机制的多样性，并且必须适应环境的广泛多样性。 评论 应当采取专门的措施防止恶意的IO变化。 为确保通信过程中事件的安全，可采用额外的措施，但是这个问题超出了IODEF的范围。 6.18 IODEF应当确保信息内容的真实性和非批判性 评论 信息内容的真实性和可说明性是许多工作组所需要的，特别是提供要求自动处理Ios的 工作组，因此，真实性和可说明性必须包括在IODEF中。由于IO真实性和非批判性对于 众多工作组的重要性，尤其是在工作组之间进行通信的情况下，因此强烈建议实现真实性和 非批判要求。 6.19 IODEF描述必须支持可能被执行者使用的扩展机制 这一点承认将来的执行细节或者实验数据。执行者必须指明如何解释任何包括在内的扩 展。 评论 执行者可能希望支持额外的信息，诸如内在的目的信息或者他们的事件处理系统的独特 实现所必需的信息。这些数据可能被删除或者并不在客观的通信中，但是把它们标记为额外 的信息用以防止不同系统的错误解释是必不可少的。 6.20 必须适当定义IODEF描述的语义学 评论 对于事件描述来说IODEF是一种人为导向格式，并且IODEF描述应该能够被人为的阅 读。自动解析工具可以用于预测，但是不应当将其视作是非常必要的。因此，IODEF必须 提供良好的语义学，该语义学将是理解描述所包括内容的关键因素。在某些情况下，IODEF 描述将用作自动确定决断，因此正确解释描述非常重要。这是使用基于语言的语义学的论据。 IODEF标识符和标签的语言分析用的语言被建议使用英语，如果需要，地方的IODEF执行 可以能够把语言分析用的语言标识符和标签翻译成当地语言和表述方法。 7 IODEF扩展性 IODEF自身必须是可扩展的 当使用新技术和开发自动化事件处理系统的时候，对IODEF扩展性的需要是必不可少 的，IODEF将能够包括新的信息。 评论 除了需要扩展IODEF支持新的事件处理工具外，也意味着IODEF将合并来自相关标准 化区域的新的发展，相关标准化区域如IDS的IDEF或者证据保管的专用格式开发。扩展程 序应当基于CSIRT/IODEF委员会接受/承认。 8 安全考虑  本备忘录介绍了对事件对象描述和转换格式的一些要求，并尝试为事件描述定义通用数 据格式，存档以及CSIRTs（包括报警、事件调查、存档、统计、报告等）之间关于事件信 息的转换。在IODEF执行的另一方面是出于对安全考虑的主题。访问限制指出的特殊安全 要求在4.3节给出了讨论，对事件描述的机密性、完整性、真实性和非批判性要求在6.16,  6.17, 6.18节给出了相应的描述。 9 参考文献     [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/ 致谢 本文献在事件分类和描述工作组研讨会上被讨论，(http://www.terena.nl/task-forces/tf- csirt/tf-csirt000929prg.html#itdwg)，采用TERENA 任务组TF-CSIRT (http://www.- terena.nl/task-forces/tf-csirt/)结构。可以通过以下邮件列表与在TERENA的事件分类和描 述工作组联系： incident-taxonomy@terena.nl或者iodef@terena.nl 文档可以通过以下相关网址得到： http://hypermail.terena.nl/incident-taxonomy-list/mail-archive/ 和 http://hypermail.terena.nl/iodef-list/mail-archive/ 作者地址 Jimmy Arvidsson    Telia CERT    EMail: Jimmy.J.Arvidsson@telia.se    Andrew Cormack    JANET-CERT    EMail: Andrew.Cormack@ukerna.ac.uk    Yuri Demchenko    TERENA    EMail: demch@terena.nl    Jan Meijer    SURFnet    EMail: jan.meijer@surfnet.nl 全部版权声明 Copyright (C) The Internet Society (2001). All Rights Reserved.  该文献及其译文可能被其他人员拷贝或转载，由此而产生的对本文献的评论或者其它不 同的解释或者对其执行的帮助等作品，可能会被筹备、复制、出版以及发布，假如上述版权 声明以及本段内容被包括在此类拷贝和派生作品中，则从整体或者局部来说，都没有任何类 型的限制。然而，除为发展Internet标准目的所需之外，本文献自身不可以采取任何形式进 行修改，诸如删除版权声明或者Internet协会或其它Internet组织，这种情况下，版权定义 程序必须遵循Internet标准进行，或者必须将其翻译成英语之外的其它语言。 上述有限许可的授予是永久的，不会被Internet协会、其继承者或者其委派者所废除。 本文献及包括于此的信息是基于“参见”和INTERNET协会以及INTERNET工程任务 组放弃的所有依据、表示或者暗示等，包括但不局限于任何依据，在此信息的使用将不违反 任何规则或任何商业性暗示依据或适用于特别的目的。 认证 RFC编辑功能基金当前由Internet协会提供。 RFC3067――TERENA's Incident Object Description and Exchange Format equirements TERENA'S事件对象描述和转换格式要求

1 RFC文档中文翻译计划