RFC5070 日本語訳
5070 The Incident Object Description Exchange Format. R. Danyliw, J.Meijer, Y. Demchenko. December 2007. (Format: TXT=171529 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Danyliw
Request for Comments: 5070 CERT
Category: Standards Track J. Meijer
UNINETT
Y. Demchenko
University of Amsterdam
December 2007
Danyliwがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5070年の本命カテゴリ: 規格は2007年12月にアムステルダムのJ.Meijer UNINETT Y.Demchenko大学を追跡します。
The Incident Object Description Exchange Format
付随している物の記述交換形式
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema.
Incident Object記述Exchange Format(IODEF)はコンピュータセキュリティインシデントに関してコンピュータセキュリティ事件対応チーム(CSIRTs)によって一般的に交換された情報交換に枠組みを提供するデータ表現を定義します。 このドキュメントは、IODEFのために情報モデルについて説明して、XML Schemaと共に指定された関連データモデルを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. About the IODEF Data Model . . . . . . . . . . . . . . . . 5
1.4. About the IODEF Implementation . . . . . . . . . . . . . . 6
2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Characters and Strings . . . . . . . . . . . . . . . . . . 7
2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . . 7
2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 7
2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . . 8
2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 5 1.2。 記法. . . . . . . . . . . . . . . . . . . . . . . . 5 1.3。 IODEFに関して、データは.51.4をモデル化します。 IODEF実現. . . . . . . . . . . . . . 6 2に関して。 IODEFデータ型. . . . . . . . . . . . . . . . . . . . . . . 6 2.1。 整数. . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2。 実数. . . . . . . . . . . . . . . . . . . . . . . 7 2.3。 キャラクターとストリング. . . . . . . . . . . . . . . . . . 7 2.4。 多言語ストリング. . . . . . . . . . . . . . . . . . . 7 2.5。 バイト. . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6。 16進バイト. . . . . . . . . . . . . . . . . . . . 7 2.7。 列挙型. . . . . . . . . . . . . . . . . . . . . 8 2.8。 日付-時間ストリング. . . . . . . . . . . . . . . . . . . . 8
Danyliw, et al. Standards Track [Page 1] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[1ページ]。
2.9. Timezone String . . . . . . . . . . . . . . . . . . . . . 8
2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . . 8
2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . . 9
2.12. Person or Organization . . . . . . . . . . . . . . . . . . 9
2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 9
2.14. Email String . . . . . . . . . . . . . . . . . . . . . . . 9
2.15. Uniform Resource Locator strings . . . . . . . . . . . . . 9
3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . . 9
3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . . 10
3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . . 10
3.3. IncidentID Class . . . . . . . . . . . . . . . . . . . . . 14
3.4. AlternativeID Class . . . . . . . . . . . . . . . . . . . 14
3.5. RelatedActivity Class . . . . . . . . . . . . . . . . . . 15
3.6. AdditionalData Class . . . . . . . . . . . . . . . . . . . 16
3.7. Contact Class . . . . . . . . . . . . . . . . . . . . . . 18
3.7.1. RegistryHandle Class . . . . . . . . . . . . . . . . . 21
3.7.2. PostalAddress Class . . . . . . . . . . . . . . . . . 22
3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 22
3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23
3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . . 23
3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . . 24
3.9.1. Reference Class . . . . . . . . . . . . . . . . . . . 25
3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . . 25
3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . . 27
3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . . 29
3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . . 30
3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . . 31
3.11. History Class . . . . . . . . . . . . . . . . . . . . . . 32
3.11.1. HistoryItem Class . . . . . . . . . . . . . . . . . . 33
3.12. EventData Class . . . . . . . . . . . . . . . . . . . . . 34
3.12.1. Relating the Incident and EventData Classes . . . . . 36
3.12.2. Cardinality of EventData . . . . . . . . . . . . . . . 37
3.13. Expectation Class . . . . . . . . . . . . . . . . . . . . 37
3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . . 40
3.15. System Class . . . . . . . . . . . . . . . . . . . . . . . 40
3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . . 42
3.16.1. Counter Class . . . . . . . . . . . . . . . . . . . . 43
3.16.2. Address Class . . . . . . . . . . . . . . . . . . . . 45
3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . . 46
3.17. Service Class . . . . . . . . . . . . . . . . . . . . . . 48
3.17.1. Application Class . . . . . . . . . . . . . . . . . . 50
3.18. OperatingSystem Class . . . . . . . . . . . . . . . . . . 51
3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . . 51
2.9. タイムゾーンストリング. . . . . . . . . . . . . . . . . . . . . 8 2.10。 リスト. . . . . . . . . . . . . . . . . . . . . . . . 8 2.11を移植してください。 郵便の宛先. . . . . . . . . . . . . . . . . . . . . . 9 2.12。 人か組織. . . . . . . . . . . . . . . . . . 9 2.13。 No.. . . . . . . . . . . . . . . . 9 2.14に電話をして、ファックスで送ってください。 ストリング. . . . . . . . . . . . . . . . . . . . . . . 9 2.15をメールしてください。 Uniform Resource Locatorは.9 3を結びます。 IODEFデータは.93.1をモデル化します。 IODEF-ドキュメントのクラス. . . . . . . . . . . . . . . . . . . 10 3.2。 付随しているクラス. . . . . . . . . . . . . . . . . . . . . . 10 3.3。 IncidentIDのクラス. . . . . . . . . . . . . . . . . . . . . 14 3.4。 AlternativeIDのクラス. . . . . . . . . . . . . . . . . . . 14 3.5。 RelatedActivityのクラス. . . . . . . . . . . . . . . . . . 15 3.6。 AdditionalDataのクラス. . . . . . . . . . . . . . . . . . . 16 3.7。 クラス. . . . . . . . . . . . . . . . . . . . . . 18 3.7.1に連絡してください。 RegistryHandleのクラス. . . . . . . . . . . . . . . . . 21 3.7.2。 PostalAddressのクラス. . . . . . . . . . . . . . . . . 22 3.7.3。 クラス. . . . . . . . . . . . . . . . . . . . . 22 3.7.4をメールしてください。 クラス. . . . . . . . . . . . . . 23 3.8に電話をして、ファックスしてください。 時間は.1に.233.8を分類します。 StartTime. . . . . . . . . . . . . . . . . . . . . . 24 3.8.2。 EndTime. . . . . . . . . . . . . . . . . . . . . . . 24 3.8.3。 DetectTime. . . . . . . . . . . . . . . . . . . . . . 24 3.8.4。 ReportTime. . . . . . . . . . . . . . . . . . . . . . 24 3.8.5。 DateTime. . . . . . . . . . . . . . . . . . . . . . . 24 3.9。 方法のクラス. . . . . . . . . . . . . . . . . . . . . . . 24 3.9.1。 参照のクラス. . . . . . . . . . . . . . . . . . . 25 3.10。 査定のクラス. . . . . . . . . . . . . . . . . . . . . 25 3.10.1。 クラス. . . . . . . . . . . . . . . . . . . . . 27 3.10.2に影響を与えてください。 TimeImpactのクラス. . . . . . . . . . . . . . . . . . . 29 3.10.3。 MonetaryImpactのクラス. . . . . . . . . . . . . . . . . 30 3.10.4。 信用のクラス. . . . . . . . . . . . . . . . . . . 31 3.11。 歴史の授業. . . . . . . . . . . . . . . . . . . . . . 32 3.11.1。 HistoryItemのクラス. . . . . . . . . . . . . . . . . . 33 3.12。 EventDataのクラス. . . . . . . . . . . . . . . . . . . . . 34 3.12.1。 .2に事件とEventDataのクラス. . . . . 36 3.12を関係づけます。 EventData. . . . . . . . . . . . . . . 37 3.13の基数。 期待のクラス. . . . . . . . . . . . . . . . . . . . 37 3.14。 流れのクラス. . . . . . . . . . . . . . . . . . . . . . . . 40 3.15。 システムのクラス. . . . . . . . . . . . . . . . . . . . . . . 40 3.16。 ノードのクラス. . . . . . . . . . . . . . . . . . . . . . . . 42 3.16.1。 クラス. . . . . . . . . . . . . . . . . . . . 43 3.16.2を打ち返してください。 クラス. . . . . . . . . . . . . . . . . . . . 45 3.16.3を記述してください。 NodeRoleのクラス. . . . . . . . . . . . . . . . . . . . 46 3.17。 クラス. . . . . . . . . . . . . . . . . . . . . . 48 3.17.1を修理してください。 アプリケーションのクラス. . . . . . . . . . . . . . . . . . 50 3.18。 OperatingSystemのクラス. . . . . . . . . . . . . . . . . . 51 3.19。 レコード・クラス. . . . . . . . . . . . . . . . . . . . . . . 51
Danyliw, et al. Standards Track [Page 2] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[2ページ]。
3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . . 51
3.19.2. RecordPattern Class . . . . . . . . . . . . . . . . . 53
3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . . 54
4. Processing Considerations . . . . . . . . . . . . . . . . . . 54
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 55
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 55
5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 56
5.1. Extending the Enumerated Values of Attributes . . . . . . 56
5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 57
6. Internationalization Issues . . . . . . . . . . . . . . . . . 59
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 61
7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 63
7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . . 65
8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . . 87
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 88
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12.1. Normative References . . . . . . . . . . . . . . . . . . . 89
12.2. Informative References . . . . . . . . . . . . . . . . . . 90
3.19.1. RecordDataのクラス. . . . . . . . . . . . . . . . . . . 51 3.19.2。 RecordPatternのクラス. . . . . . . . . . . . . . . . . 53 3.19.3。 RecordItemのクラス. . . . . . . . . . . . . . . . . . . 54 4。 問題. . . . . . . . . . . . . . . . . . 54 4.1を処理します。 .544.2をコード化します。 IODEF名前空間. . . . . . . . . . . . . . . . . . . . . 55 4.3。 合法化. . . . . . . . . . . . . . . . . . . . . . . . 55 5。 IODEF. . . . . . . . . . . . . . . . . . . . . 56 5.1を広げています。 属性. . . . . . 56 5.2の列挙された値を広げています。 クラス. . . . . . . . . . . . . . . . . . . . 57 6を広げます。 国際化問題. . . . . . . . . . . . . . . . . 59 7。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.1。 .607.2をはうように進んでください。 偵察. . . . . . . . . . . . . . . . . . . . . . 61 7.3。 ボットネット報告. . . . . . . . . . . . . . . . . . . . 63 7.4。 リスト. . . . . . . . . . . . . . . . . . . . . . . . 65 8を見てください。 IODEF図式. . . . . . . . . . . . . . . . . . . . . . . 66 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 87 10。 IANA問題. . . . . . . . . . . . . . . . . . . . . 88 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 88 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 89 12.1。 引用規格. . . . . . . . . . . . . . . . . . . 89 12.2。 有益な参照. . . . . . . . . . . . . . . . . . 90
Danyliw, et al. Standards Track [Page 3] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[3ページ]。
1. Introduction
1. 序論
Organizations require help from other parties to mitigate malicious activity targeting their network and to gain insight into potential threats. This coordination might entail working with an ISP to filter attack traffic, contacting a remote site to take down a bot- network, or sharing watch-lists of known malicious IP addresses in a consortium.
組織は、彼らのネットワークを狙う悪意がある活動を緩和して、潜在的な脅威に関する洞察を獲得するために相手から助けを必要とします。 このコーディネートは、攻撃交通をフィルターにかけるためにISPで働くのを伴うかもしれません、ウマバエの幼虫ネットワークを降ろすためにリモートサイトに接触するか、または共同体で知られている悪意があるIPアドレスに関する警戒リストを共有して。
The Incident Object Description Exchange Format (IODEF) is a format for representing computer security information commonly exchanged between Computer Security Incident Response Teams (CSIRTs). It provides an XML representation for conveying incident information across administrative domains between parties that have an operational responsibility of remediation or a watch-and-warning over a defined constituency. The data model encodes information about hosts, networks, and the services running on these systems; attack methodology and associated forensic evidence; impact of the activity; and limited approaches for documenting workflow.
Incident Object記述Exchange Format(IODEF)は、コンピュータセキュリティ事件対応チーム(CSIRTs)の間で一般的に交換されたコンピュータセキュリティ情報を表すための形式です。 それは定義された選挙民の上の治療教育の操作上の責任を持っているパーティーの間の管理ドメインの向こう側に付随している情報を伝えるXML表現か腕時計と警告を提供します。 データモデルはこれらのシステムで動くホスト、ネットワーク、およびサービスの情報をコード化します。 方法論と関連法廷の証拠を攻撃してください。 活動の影響。 そして、作業フローを記録するための限られたアプローチ。
The overriding purpose of the IODEF is to enhance the operational capabilities of CSIRTs. Community adoption of the IODEF provides an improved ability to resolve incidents and convey situational awareness by simplifying collaboration and data sharing. This structured format provided by the IODEF allows for:
IODEFの最優先の目的はCSIRTsの運用能力を高めることです。 IODEFの共同体採用は共同とデータ共有を簡素化することによって事件を決議して、状況により異なる認識を伝える改良された能力を提供します。 IODEFによって提供されたこの構造化された形式は以下を考慮します。
o increased automation in processing of incident data, since the
resources of security analysts to parse free-form textual
documents will be reduced;
o 自由形式の原文のドキュメントを分析する証券アナリストのリソースが減らされて以来の付随しているデータの処理における増加するオートメーション。
o decreased effort in normalizing similar data (even when highly
structured) from different sources; and
o さまざまな原因から同様のデータを正常にすることにおける(非常に構造化されると)減少している努力。 そして
o a common format on which to build interoperable tools for incident
handling and subsequent analysis, specifically when data comes
from multiple constituencies.
o 付随している取り扱いのための共同利用できるツールを組立てる一般的な形式と特にデータが複数の選挙民から来るときのその後の分析。
Coordinating with other CSIRTs is not strictly a technical problem. There are numerous procedural, trust, and legal considerations that might prevent an organization from sharing information. The IODEF does not attempt to address them. However, operational implementations of the IODEF will need to consider this broader context.
他のCSIRTsと共に調整するのは、厳密にa技術的な問題ではありません。 組織が情報を共有するのを防ぐかもしれない多数の手続き上的、そして、信用的、そして、法的な問題があります。 IODEFは、それらを記述するのを試みません。 しかしながら、IODEFの操作上の実現は、このより広い文脈を考える必要があるでしょう。
Sections 3 and 8 specify the IODEF data model with text and an XML schema. The types used by the data model are covered in Section 2. Processing considerations, the handling of extensions, and internationalization issues related to the data model are covered in
セクション3と8はテキストとXML図式でIODEFデータモデルを指定します。 データモデルによって使用されたタイプはセクション2でカバーされています。 問題、拡大の取り扱い、および関連する国際化問題を処理することデータモデルがカバーである。
Danyliw, et al. Standards Track [Page 4] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[4ページ]。
Sections 4, 5, and 6, respectively. Examples are listed in Section 7. Section 1 provides the background for the IODEF, and Section 9 documents the security considerations.
それぞれセクション4、5、および6。 例はセクション7にリストアップされています。 セクション1はIODEF、およびセクション9ドキュメントのためのバックグラウンドにセキュリティ問題を提供します。
1.1. Terminology
1.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 RFC2119 [6].
キーワード「必須」、「必須NOT」が「必要である」、「」、「」、「」、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
Definitions for some of the common computer security-related terminology used in this document can be found in Section 2 of [16].
[16]のセクション2で本書では使用されるいくつかの一般的なコンピュータセキュリティ関連の用語の定義を見つけることができます。
1.2. Notations
1.2. 記法
The normative IODEF data model is specified with the text in Section 3 and the XML schema in Section 8. To help in the understanding of the data elements, Section 3 also depicts the underlying information model using Unified Modeling Language (UML). This abstract presentation of the IODEF is not normative.
テキストがセクション3にあって、XML図式がセクション8にある状態で、標準のIODEFデータモデルは指定されます。 また、データ要素の理解で助けるために、セクション3は、統一モデリング言語(UML)を使用することで基本的な情報モデルについて表現します。 IODEFのこの抽象的なプレゼンテーションは規範的ではありません。
For clarity in this document, the term "XML document" will be used when referring generically to any instance of an XML document. The term "IODEF document" will be used to refer to specific elements and attributes of the IODEF schema. The terms "class" and "element" will be used interchangeably to reference either the corresponding data element in the information or data models, respectively.
このドキュメントの明快ために、一般的にXMLドキュメントのどんな例も示すと、「XMLドキュメント」という用語は使用されるでしょう。 「IODEFドキュメント」という用語は、IODEF図式の特定の要素と属性を示すのに使用されるでしょう。 用語「クラス」と「要素」は情報かデータの対応するデータ要素がそれぞれモデル化する参照に互換性を持って使用されるでしょう。
1.3. About the IODEF Data Model
1.3. IODEFデータモデルに関して
The IODEF data model is a data representation that provides a framework for sharing information commonly exchanged by CSIRTs about computer security incidents. A number of considerations were made in the design of the data model.
IODEFデータモデルはコンピュータセキュリティインシデントに関してCSIRTsによって一般的に交換された情報交換に枠組みを提供するデータ表現です。 多くの問題がデータモデルのデザインで作られました。
o The data model serves as a transport format. Therefore, its
specific representation is not the optimal representation for on-
disk storage, long-term archiving, or in-memory processing.
o データモデルは輸送形式として役立ちます。 したがって、特定の表現が最適の表現でない、オンである、ディスク格納、長期の格納、またはメモリにおける処理。
o As there is no precise widely agreed upon definition for an
incident, the data model does not attempt to dictate one through
its implementation. Rather, a broad understanding is assumed in
the IODEF that is flexible enough to encompass most operators.
o 事件のためのどんな正確な広く同意された定義もないとき、データモデルは、実現で1を書き取るのを試みません。 むしろ、広い理解はほとんどのオペレータを包含するほどフレキシブルなIODEFで想定されます。
o Describing an incident for all definitions would require an
extremely complex data model. Therefore, the IODEF only intends
to be a framework to convey commonly exchanged incident
information. It ensures that there are ample mechanisms for
o すべての定義のために出来事を描写するのは非常に複雑なデータモデルを必要とするでしょう。 したがって、IODEFは、一般的に交換された付随している情報を伝えるために枠組みであることを意図するだけです。 それは、十分なメカニズムがあるのを確実にします。
Danyliw, et al. Standards Track [Page 5] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[5ページ]。
extensibility to support organization-specific information, and
techniques to reference information kept outside of the explicit
data model.
組織特殊情報、およびテクニックを参考情報にサポートする伸展性は明白なデータモデルの外に保たれました。
o The domain of security analysis is not fully standardized and must
rely on free-form textual descriptions. The IODEF attempts to
strike a balance between supporting this free-form content, while
still allowing automated processing of incident information.
o 証券分析のドメインは、完全に標準化されるというわけではなくて、自由形式の原文の記述に依存しなければなりません。 IODEFは、まだ付随している情報の自動化された処理を許している間、この自由形式内容を支持することの間のバランスをとるのを試みます。
o The IODEF is only one of several security relevant data
representations being standardized. Attempts were made to ensure
they were complimentary. The data model of the Intrusion
Detection Message Exchange Format [17] influenced the design of
the IODEF.
o IODEFは標準化されるいくつかのセキュリティの関連データ表現の1つにすぎません。 確実に賞賛であったのになるようにするのを試みをしました。 Intrusion Detection Message Exchange Format[17]のデータモデルはIODEFのデザインに影響を及ぼしました。
Further discussion of the desirable properties for the IODEF can be found in the Requirements for the Format for Incident Information Exchange (FINE) [16].
Incident情報Exchange(おかげさまで元気です)[16]のためにRequirementsでFormatに関してIODEFに、望ましい特性のさらなる議論を見つけることができます。
1.4. About the IODEF Implementation
1.4. IODEF実現に関して
The IODEF implementation is specified as an Extensible Markup Language (XML) [1] Schema [2] in Section 8.
IODEF実現はセクション8の拡張マークアップ言語(XML)[1]図式[2]として指定されます。
Implementing the IODEF in XML provides numerous advantages. Its extensibility makes it ideal for specifying a data encoding framework that supports various character encodings. Likewise, the abundance of related technologies (e.g., XSL, XPath, XML-Signature) makes for simplified manipulation. However, XML is fundamentally a text representation, which makes it inherently inefficient when binary data must be embedded or large volumes of data must be exchanged.
XMLでIODEFを実行すると、多数の利点は提供されます。 伸展性で、それは様々なキャラクタencodingsを支持するzデータの符号化枠組みを指定するのに理想的になります。 同様に、関連技術(例えば、XSL、XPath、XML-署名)の豊富は簡易型の操作になります。 しかしながら、XMLは基本的にテキスト表現です。(2進のデータを埋め込まなければならないか、またはデータの大量を交換しなければならないとき、その表現はそれを本来効率が悪くします)。
2. IODEF Data Types
2. IODEFデータ型
The various data elements of the IODEF data model are typed. This section discusses these data types. When possible, native Schema data types were adopted, but for more complicated formats, regular expressions (see Appendix F of [3]) or external standards were used.
IODEFデータモデルの様々なデータ原理はタイプされます。 このセクションはこれらのデータ型について論じます。 可能であるときに、固有のSchemaデータ型は採用されました、より複雑な形式がなければ、正規表現。(Appendix Fの[3])か外部の規格が使用されたのを確実にしてください。
2.1. Integers
2.1. 整数
An integer is represented by the INTEGER data type. Integer data MUST be encoded in Base 10.
整数はINTEGERデータ型によって表されます。 基地10で整数データをコード化しなければなりません。
The INTEGER data type is implemented as an "xs:integer" [3] in the schema.
INTEGERデータ型は[3] 中の「xs: 整数」として実行されます。図式。
Danyliw, et al. Standards Track [Page 6] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[6ページ]。
2.2. Real Numbers
2.2. 実数
Real (floating-point) attributes are represented by the REAL data type. Real data MUST be encoded in Base 10.
本当(浮動小数点の)の属性はレアルデータ型によって表されます。 基地10で本当のデータをコード化しなければなりません。
The REAL data type is implemented as an "xs:float" [3] in the schema.
レアルデータ型は図式の「xs: 浮いてください」という[3]として実行されます。
2.3. Characters and Strings
2.3. キャラクターとストリング
A single character is represented by the CHARACTER data type. A character string is represented by the STRING data type. Special characters must be encoded using entity references. See Section 4.1.
単独のキャラクタはキャラクターデータ型によって代理をされます。 文字列はSTRINGデータ型によって表されます。 実体参照を使用することで特殊文字をコード化しなければなりません。 セクション4.1を見てください。
The CHARACTER and STRING data types are implement as an "xs:string" [3] in the schema.
キャラクターとSTRINGデータ型はそうです。[3] 中の「xs: ストリング」として、図式を実行してください。
2.4. Multilingual Strings
2.4. 多言語ストリング
STRING data that represents multi-character attributes in a language different than the default encoding of the document is of the ML_STRING data type.
ドキュメントのデフォルトコード化と異なった言語のマルチキャラクタ属性を表すSTRINGデータはML_STRINGデータ型のものです。
The ML_STRING data type is implemented as an "iodef:MLStringType" in the schema.
ML_STRINGデータ型は図式の「iodef: MLStringType」として実行されます。
2.5. Bytes
2.5. バイト
A binary octet is represented by the BYTE data type. A sequence of binary octets is represented by the BYTE[] data type. These octets are encoded using base64.
2進の八重奏はBYTEデータ型によって表されます。 2進の八重奏の系列はBYTE[]データ型によって表されます。 これらの八重奏は、base64を使用することでコード化されます。
The BYTE data type is implemented as an "xs:base64Binary" [3] in the schema.
BYTEデータ型は図式の「xs: base64Binary」[3]として実行されます。
2.6. Hexadecimal Bytes
2.6. 16進バイト
A binary octet is represented by the HEXBIN (and HEXBIN[]) data type. This octet is encoded as a character tuple consisting of two hexadecimal digits.
バイナリー八重奏はHEXBINによって表されます。(そして、HEXBIN[])データ型。 この八重奏は2つの16進数字から成るキャラクタtupleとしてコード化されます。
The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the schema.
HEXBINデータ型は図式の「xs: hexBinary」[3]として実行されます。
Danyliw, et al. Standards Track [Page 7] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[7ページ]。
2.7. Enumerated Types
2.7. 列挙型
Enumerated types are represented by the ENUM data type, and consist of an ordered list of acceptable values. Each value has a representative keyword. Within the IODEF schema, the enumerated type keywords are used as attribute values.
列挙型は、ENUMデータ型によって表されて、許容値の規則正しいリストから成ります。 各値には、代表しているキーワードがあります。 IODEF図式の中では、列挙型キーワードは属性値として使用されます。
The ENUM data type is implemented as a series of "xs:NMTOKEN" in the schema.
ENUMデータ型は図式の「xs: NMTOKEN」のシリーズとして実行されます。
2.8. Date-Time Strings
2.8. 日付-時間ストリング
Date-time strings are represented by the DATETIME data type. Each date-time string identifies a particular instant in time; ranges are not supported.
日付-時間ストリングはDATETIMEデータ型によって表されます。 それぞれの日付-時間ストリングは時間内に、特定の瞬間を特定します。 範囲は支持されません。
Date-time strings are formatted according to a subset of ISO 8601: 2000 [13] documented in RFC 3339 [12].
ISO8601の部分集合によると、日付-時間ストリングはフォーマットされます: 2000[13]は3339[12]をRFCに記録しました。
The DATETIME data type is implemented as an "xs:dateTime" [3] in the schema.
DATETIMEデータ型は図式の「xs: dateTime」[3]として実行されます。
2.9. Timezone String
2.9. タイムゾーンストリング
A timezone offset from UTC is represented by the TIMEZONE data type. It is formatted according to the following regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".
UTCから相殺されたタイムゾーンはTIMEZONEデータ型によって表されます。 以下の正規表現に従って、それはフォーマットされます: 「Z」|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".
The TIMEZONE data type is implemented as an "xs:string" with a regular expression constraint in the schema. This regular expression is identical to the timezone representation implemented in an "xs: dateTime".
TIMEZONEデータ型は図式における正規表現規制がある「xs: ストリング」として実行されます。 この正規表現が中で実行されたタイムゾーン表現と同じである、「xs:」 "dateTime"。
2.10. Port Lists
2.10. 左舷傾斜
A list of network ports are represented by the PORTLIST data type. A PORTLIST consists of a comma-separated list of numbers and ranges (N-M means ports N through M, inclusive). It is formatted according to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". For example, "2,5-15,30,32,40-50,55-60".
ネットワークポートのリストはPORTLISTデータ型によって表されます。 PORTLISTは数のコンマで切り離されたリストから成って、及びます(N-MはMを通して包括的にポートNを意味します)。 以下の正規表現に従って、それはフォーマットされます: 「\d+、(\、-、\d+)、--、(\d+、(\、-、\d+)? *、」 例えば、「2 5-15 30 32 40-50、5560インチ、」
The PORTLIST data type is implemented as an "xs:string" with a regular expression constraint in the schema.
PORTLISTデータ型は図式における正規表現規制がある「xs: ストリング」として実行されます。
Danyliw, et al. Standards Track [Page 8] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[8ページ]。
2.11. Postal Address
2.11. 郵便の宛先
A postal address is represented by the POSTAL data type. This data type is an ML_STRING whose format is documented in Section 2.23 of RFC 4519 [10]. It defines a postal address as a free-form multi-line string separated by the "$" character.
郵便の宛先はPOSTALデータ型によって表されます。 このデータ型は書式がRFC4519[10]のセクション2.23に記録されるML_STRINGです。 それは「$」キャラクタによって分離された自由形式マルチ線ストリングと郵便の宛先を定義します。
The POSTAL data type is implemented as an "xs:string" in the schema.
POSTALデータ型は図式の「xs: ストリング」として実行されます。
2.12. Person or Organization
2.12. 人か組織
The name of an individual or organization is represented by the NAME data type. This data type is an ML_STRING whose format is documented in Section 2.3 of RFC 4519 [10].
個人の名前か組織がNAMEデータ型によって代表されます。 このデータ型は書式がRFC4519[10]のセクション2.3に記録されるML_STRINGです。
The NAME data type is implemented as an "xs:string" in the schema.
NAMEデータ型は図式の「xs: ストリング」として実行されます。
2.13. Telephone and Fax Numbers
2.13. 電話とファックス番号
A telephone or fax number is represented by the PHONE data type. The format of the PHONE data type is documented in Section 2.35 of RFC 4519 [10].
電話かファックス番号が電話データ型によって表されます。 電話データ型の書式はRFC4519[10]のセクション2.35に記録されます。
The PHONE data type is implemented as an "xs:string" in the schema.
電話データ型は図式の「xs: ストリング」として実行されます。
2.14. Email String
2.14. メールストリング
An email address is represented by the EMAIL data type. The format of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11]
Eメールアドレスはメールデータ型によって表されます。 メールデータ型の書式はセクション3.4.1RFC2822に記録されます。[11]
The EMAIL data type is implemented as an "xs:string" in the schema.
メールデータ型は図式の「xs: ストリング」として実行されます。
2.15. Uniform Resource Locator strings
2.15. Uniform Resource Locatorストリング
A uniform resource locator (URL) is represented by the URL data type. The format of the URL data type is documented in RFC 2396 [8].
一定のリソースロケータ(URL)はURLデータ型によって表されます。 URLデータ型の書式はRFC2396[8]に記録されます。
The URL data type is implemented as an "xs:anyURI" in the schema.
URLデータ型は図式の「xs: anyURI」として実行されます。
3. The IODEF Data Model
3. IODEFデータモデル
In this section, the individual components of the IODEF data model will be discussed in detail. For each class, the semantics will be described and the relationship with other classes will be depicted with UML. When necessary, specific comments will be made about corresponding definition in the schema in Section 8
このセクションで、詳細にIODEFデータモデルの個々の部品について議論するでしょう。 各クラスにおいて、意味論は説明されるでしょう、そして、他のクラスとの関係はUMLと共に表現されるでしょう。 セクション8の図式との対応する定義に関して必要で、特定のコメントをするとき
Danyliw, et al. Standards Track [Page 9] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[9ページ]。
3.1. IODEF-Document Class
3.1. IODEF-ドキュメントのクラス
The IODEF-Document class is the top level class in the IODEF data model. All IODEF documents are an instance of this class.
IODEF-ドキュメントのクラスはIODEFデータモデルのトップ平らなクラスです。 すべてのIODEFドキュメントがこのクラスの例です。
+-----------------+
| IODEF-Document |
+-----------------+
| STRING version |<>--{1..*}--[ Incident ]
| ENUM lang |
| STRING formatid |
+-----------------+
+-----------------+ | IODEF-ドキュメント| +-----------------+ | STRINGバージョン| <>--1..*--[事件]| ENUM lang| | STRING formatid| +-----------------+
Figure 1: IODEF-Document Class
図1: IODEF-ドキュメントのクラス
The aggregate class that constitute IODEF-Document is:
IODEF-ドキュメントを構成する集約クラスは以下の通りです。
Incident
One or more. The information related to a single incident.
付随しているOneか以上。 情報は単一の事件に関連しました。
The IODEF-Document class has three attributes:
IODEF-ドキュメントのクラスには、3つの属性があります:
version
Required. STRING. The IODEF specification version number to
which this IODEF document conforms. The value of this attribute
MUST be "1.00"
バージョンRequired。 結びます。 このIODEFドキュメントが. この属性の値を従わせるIODEF仕様バージョン番号は「1インチ」であるに違いありません。
lang
Required. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6.
lang Required。 ENUM。 「xs: 言語」の定義で抑制されたRFC4646[7]あたり1つの有効な言語コード。 このコードの解釈はセクション6で説明されます。
formatid
Optional. STRING. A free-form string to convey processing
instructions to the recipient of the document. Its semantics must
be negotiated out-of-band.
formatid Optional。 結びます。 ドキュメントの受取人に指示を処理する運ぶ自由形式ストリング。 バンドの外で意味論を交渉しなければなりません。
3.2. Incident Class
3.2. 付随しているクラス
Every incident is represented by an instance of the Incident class. This class provides a standardized representation for commonly exchanged incident data.
あらゆる事件がIncidentのクラスの例によって表されます。 このクラスは一般的に交換された付随しているデータの標準化された表現を提供します。
Danyliw, et al. Standards Track [Page 10] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[10ページ]。
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+--------------------+
+--------------------+ | 事件| +--------------------+ | ENUM目的| <>、-、-、-、-、-、-、-、-、--[IncidentID]| STRING ext-目的| <>--0..1--[AlternativeID]| ENUM lang| <>--0..1--[RelatedActivity]| ENUM制限| <>--0..1--[DetectTime]| | <>--0..1--[StartTime]| | <>--0..1--[EndTime]| | <>、-、-、-、-、-、-、-、-、--[ReportTime]| | <>--0..*--[記述]| | <>--1..*--[査定]| | <>--0..*--[方法]| | <>--1..*--[接触]| | <>--0..*--[EventData]| | <>--0..1--[歴史]| | <>--0..*--[AdditionalData]+--------------------+
Figure 2: The Incident Class
図2: 付随しているクラス
The aggregate classes that constitute Incident are:
Incidentを構成する集約クラスは以下の通りです。
IncidentID
One. An incident tracking number assigned to this incident by the
CSIRT that generated the IODEF document.
IncidentID1。 IODEFドキュメントを作ったCSIRTによってこの事件に割り当てられた数を追跡する事件。
AlternativeID
Zero or one. The incident tracking numbers used by other CSIRTs
to refer to the incident described in the document.
AlternativeID Zeroか1。 ドキュメントで説明された事件について言及するのに他のCSIRTsによって使用された数を追跡する事件。
RelatedActivity
Zero or one. The incident tracking numbers of related incidents.
RelatedActivity Zeroか1。 関連する事件の数を追跡する事件。
DetectTime
Zero or one. The time the incident was first detected.
DetectTime Zeroか1。 事件が最初に検出された時。
StartTime
Zero or one. The time the incident started.
StartTime Zeroか1。 事件時。
EndTime
Zero or one. The time the incident ended.
EndTime Zeroか1。 事件が終わった時。
ReportTime
One. The time the incident was reported.
ReportTime1。 事件が報告された時。
Danyliw, et al. Standards Track [Page 11] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[11ページ]。
Description
Zero or more. ML_STRING. A free-form textual description of the
incident.
記述Zeroか以上。 ミリリットル_ストリング。 事件の自由形式の原文の記述。
Assessment
One or more. A characterization of the impact of the incident.
査定Oneか以上。 事件の衝撃の特殊化。
Method
Zero or more. The techniques used by the intruder in the
incident.
方法Zeroか以上。 事件に侵入者によって使用されたテクニック。
Contact
One or more. Contact information for the parties involved in the
incident.
Oneか以上に連絡してください。 事件にかかわるパーティーへの問い合わせ先。
EventData
Zero or more. Description of the events comprising the incident.
EventData Zeroか以上。 事件を包括する出来事の記述。
History
Zero or one. A log of significant events or actions that occurred
during the course of handling the incident.
歴史Zeroか1。 事件を扱うコースの間に起こった重大な行事か動作に関するログ。
AdditionalData
Zero or more. Mechanism by which to extend the data model.
AdditionalData Zeroか以上。 データモデルを広げるメカニズム。
The Incident class has four attributes:
Incidentのクラスには、4つの属性があります:
purpose
Required. ENUM. The purpose attribute represents the reason why
the IODEF document was created. It is closely related to the
Expectation class (Section 3.13). This attribute is defined as an
enumerated list:
目的Required。 ENUM。 目的属性はIODEFドキュメントが作成された理由を表します。 それは密接にExpectationのクラス(セクション3.13)に関連します。 この属性は列挙されたリストと定義されます:
1. traceback. The document was sent for trace-back purposes.
1. traceback。 跡の逆目的のためにドキュメントを送りました。
2. mitigation. The document was sent to request aid in
mitigating the described activity.
2. 緩和。 説明された活動を緩和する際に援助を請うためにドキュメントを送りました。
3. reporting. The document was sent to comply with reporting
requirements.
3. 報告。 要件を報告するのに応じるためにドキュメントを送りました。
4. other. The document was sent for purposes specified in the
Expectation class.
4. 他です。 Expectationのクラスで指定された目的のためにドキュメントを送りました。
5. ext-value. An escape value used to extend this attribute.
See Section 5.1.
5. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
Danyliw, et al. Standards Track [Page 12] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[12ページ]。
ext-purpose
Optional. STRING. A means by which to extend the purpose
attribute. See Section 5.1.
ext-目的Optional。 結びます。 目的属性を広げる手段。 セクション5.1を見てください。
lang
Optional. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6.
lang Optional。 ENUM。 「xs: 言語」の定義で抑制されたRFC4646[7]あたり1つの有効な言語コード。 このコードの解釈はセクション6で説明されます。
restriction
Optional. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient to adhere for
the information represented in this class and its children. This
guideline provides no security since there are no specified
technical means to ensure that the recipient of the document
handles the information as the sender requested.
制限Optional。 ENUM。 この属性は送付者が、受取人がこのクラスで表された情報のために付着すると予想する公開ガイドラインとその子供を示します。 送付者が要求したようにドキュメントの受取人が情報を扱うのを保証する指定された技術手段が全くないので、このガイドラインはセキュリティを全く提供しません。
The value of this attribute is logically inherited by the children
of this class. That is to say, the disclosure rules applied to
this class, also apply to its children.
この属性の値はこのクラスの子供によって論理的に引き継がれます。 すなわち、開示のルールは、このクラスに適用して、また、子供に適用されます。
It is possible to set a granular disclosure policy, since all of
the high-level classes (i.e., children of the Incident class) have
a restriction attribute. Therefore, a child can override the
guidelines of a parent class, be it to restrict or relax the
disclosure rules (e.g., a child has a weaker policy than an
ancestor; or an ancestor has a weak policy, and the children
selectively apply more rigid controls). The implicit value of the
restriction attribute for a class that did not specify one can be
found in the closest ancestor that did specify a value.
粒状の公開方針を設定するのは可能です、ハイレベルのクラス(すなわち、Incidentのクラスの子供)のすべてには制限属性があるので。 したがって、子供は親のクラスのガイドラインに優越できます、公開を制限するか、または弛緩するのが統治される(例えば、子供には、先祖より弱い方針があります; または、先祖では、弱い方針があって、子供は選択的により堅いコントロールを適用します)か否かに関係なく。 値を指定した最も近い先祖で1つを指定しなかったクラスのための制限属性の暗黙の値を見つけることができます。
This attribute is defined as an enumerated value with a default
value of "private". Note that the default value of the
restriction attribute is only defined in the context of the
Incident class. In other classes where this attribute is used, no
default is specified.
この属性は「個人的」のデフォルト値で列挙された値と定義されます。 制限属性のデフォルト値がIncidentのクラスの文脈で定義されるだけであることに注意してください。 この属性が使用されている他のクラスでは、デフォルトは全く指定されません。
1. public. There are no restrictions placed in the information.
1. 公共です。 情報に置かれた制限が全くありません。
2. need-to-know. The information may be shared with other
parties that are involved in the incident as determined by the
recipient of this document (e.g., multiple victim sites can be
informed of each other).
2. 知る必要性。 情報はこのドキュメントの受取人によって決定されるようにインシデントにかかわる相手と共有されるかもしれません(例えば、互いについて複数の犠牲者サイトを知らすことができます)。
3. private. The information may not be shared.
3. 個人的です。 情報は共有されないかもしれません。
Danyliw, et al. Standards Track [Page 13] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[13ページ]。
4. default. The information can be shared according to an
information disclosure policy pre-arranged by the
communicating parties.
4. デフォルトとしてください。 交信パーティーによって根回しされた情報公開方針によると、情報を共有できます。
3.3. IncidentID Class
3.3. IncidentIDのクラス
The IncidentID class represents an incident tracking number that is unique in the context of the CSIRT and identifies the activity characterized in an IODEF Document. This identifier would serve as an index into the CSIRT incident handling system. The combination of the name attribute and the string in the element content MUST be a globally unique identifier describing the activity. Documents generated by a given CSIRT MUST NOT reuse the same value unless they are referencing the same incident.
IncidentIDのクラスは、CSIRTの文脈でユニークな数を追跡するインシデントを表して、IODEF Documentで特徴付けられた活動を特定します。 この識別子はインデックスとしてCSIRTの付随している取り扱いシステムに機能するでしょう。 名前属性と要素含有量のストリングの組み合わせは活動について説明するグローバルにユニークな識別子であるに違いありません。 同じインシデントに参照をつけていない場合、ドキュメントは、与えられたCSIRT MUST NOTで再利用が同じ値であると生成しました。
+------------------+ | IncidentID | +------------------+ | STRING | | | | STRING name | | STRING instance | | ENUM restriction | +------------------+
+------------------+ | IncidentID| +------------------+ | ストリング| | | | STRING名| | STRINGインスタンス| | ENUM制限| +------------------+
Figure 3: The IncidentID Class
図3: IncidentIDのクラス
The IncidentID class has three attributes:
IncidentIDのクラスには、3つの属性があります:
name
Required. STRING. An identifier describing the CSIRT that
created the document. In order to have a globally unique CSIRT
name, the fully qualified domain name associated with the CSIRT
MUST be used.
Requiredを命名してください。 結びます。 ドキュメントを作成したCSIRTについて説明する識別子。 グローバルにユニークなCSIRT名を持つために、完全修飾ドメイン名は使用されるCSIRT MUSTと交際しました。
instance
Optional. STRING. An identifier referencing a subset of the
named incident.
インスタンスOptional。 結びます。 命名されたインシデントの部分集合に参照をつける識別子。
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されました。
3.4. AlternativeID Class
3.4. AlternativeIDのクラス
The AlternativeID class lists the incident tracking numbers used by CSIRTs, other than the one generating the document, to refer to the identical activity described the IODEF document. A tracking number listed as an AlternativeID references the same incident detected by
付随している問い合わせ番号が同じ活動について言及するためにドキュメントを作るもの以外のCSIRTsで使用したAlternativeIDクラスリストはIODEFドキュメントについて説明しました。 数が同じインシデントが検出したAlternativeID参照として記載した追跡
Danyliw, et al. Standards Track [Page 14] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[14ページ]。
another CSIRT. The incident tracking numbers of the CSIRT that generated the IODEF document should never be considered an AlternativeID.
別のCSIRT。 IODEFドキュメントを作ったCSIRTの数を追跡するインシデントはAlternativeIDであると決して考えられるべきではありません。
+------------------+
| AlternativeID |
+------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ]
| |
+------------------+
+------------------+ | AlternativeID| +------------------+ | ENUM制限| <>--1..*--[IncidentID]| | +------------------+
Figure 4: The AlternativeID Class
図4: AlternativeIDのクラス
The aggregate class that constitutes AlternativeID is:
AlternativeIDを構成する集約クラスは以下の通りです。
IncidentID
One or more. The incident tracking number of another CSIRT.
IncidentID Oneか以上。 別のCSIRTの数を追跡するインシデント。
The AlternativeID class has one attribute:
AlternativeIDのクラスには、1つの属性があります:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されました。
3.5. RelatedActivity Class
3.5. RelatedActivityのクラス
The RelatedActivity class lists either incident tracking numbers of incidents or URLs (not both) that refer to activity related to the one described in the IODEF document. These references may be to local incident tracking numbers or to those of other CSIRTs.
RelatedActivityのクラスはIODEFドキュメントで説明されたものに関連する活動について言及する付随している問い合わせ番号のインシデントかURL(両方でない)のどちらかを記載します。 地方の付随している問い合わせ番号、または、他のCSIRTsのものにこれらの参照があるかもしれません。
The specifics of how a CSIRT comes to believe that two incidents are related are considered out of scope.
CSIRTがどう2つのインシデントが関係づけられると信じるようになるかに関する詳細は範囲から考えられます。
+------------------+
| RelatedActivity |
+------------------+
| ENUM restriction |<>--{0..*}--[ IncidentID ]
| |<>--{0..*}--[ URL ]
+------------------+
+------------------+ | RelatedActivity| +------------------+ | ENUM制限| <>--0..*--[IncidentID]| | <>--0..*--[URL]+------------------+
Figure 5: RelatedActivity Class
図5: RelatedActivityのクラス
Danyliw, et al. Standards Track [Page 15] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[15ページ]。
The aggregate classes that constitutes RelatedActivity are:
RelatedActivityを構成する集約クラスは以下の通りです。
IncidentID
One or more. The incident tracking number of a related incident.
IncidentID Oneか以上。 関連するインシデントの数を追跡するインシデント。
URL
One or more. URL. A URL to activity related to this incident.
URL Oneか以上。 URL。 活動へのURLはこのインシデントに関連しました。
The RelatedActivity class has one attribute:
RelatedActivityのクラスには、1つの属性があります:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されました。
3.6. AdditionalData Class
3.6. AdditionalDataのクラス
The AdditionalData class serves as an extension mechanism for information not otherwise represented in the data model. For relatively simple information, atomic data types (e.g., integers, strings) are provided with a mechanism to annotate their meaning. The class can also be used to extend the data model (and the associated Schema) to support proprietary extensions by encapsulating entire XML documents conforming to another Schema (e.g., IDMEF). A detailed discussion for extending the data model and the schema can be found in Section 5.
AdditionalDataのクラスは別の方法でデータモデルで表されなかった情報のための拡張機能として機能します。 比較的簡単な情報に関しては、それらの意味を注釈するために原子データ型(例えば、整数、ストリング)にメカニズムを提供します。 また、別のSchema(例えば、IDMEF)に一致している全体のXMLドキュメントをカプセル化することによって独占拡大をサポートするために、データモデル(そして、関連Schema)を広げるのにクラスを使用できます。 セクション5でデータモデルと図式を広げるための詳細な論議を見つけることができます。
Unlike XML, which is self-describing, atomic data must be documented to convey its meaning. This information is described in the 'meaning' attribute. Since these description are outside the scope of the specification, some additional coordination may be required to ensure that a recipient of a document using the AdditionalData classes can make sense of the custom extensions.
XMLと異なって、意味を伝えるために原子データを記録しなければなりません。XMLは自己説明です。 この情報は'意味'属性で説明されます。 仕様の範囲の外にこれらの記述があるので、何らかの追加コーディネートがAdditionalDataのクラスを使用するドキュメントの受取人がカスタム拡大を理解できることができるのを保証するのに必要であるかもしれません。
+------------------+ | AdditionalData | +------------------+ | ANY | | | | ENUM dtype | | STRING ext-dtype | | STRING meaning | | STRING formatid | | ENUM restriction | +------------------+
+------------------+ | AdditionalData| +------------------+ | 少しも| | | | ENUM dtype| | STRING ext-dtype| | STRING意味| | STRING formatid| | ENUM制限| +------------------+
Figure 6: The AdditionalData Class
図6: AdditionalDataのクラス
Danyliw, et al. Standards Track [Page 16] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[16ページ]。
The AdditionalData class has five attributes:
AdditionalDataのクラスには、5つの属性があります:
dtype
Required. ENUM. The data type of the element content. The
permitted values for this attribute are shown below. The default
value is "string".
dtype Required。 ENUM。 要素含有量に関するデータ型。 この属性のための受入れられた値は以下に示されます。 デフォルト値は「ストリング」です。
1. boolean. The element content is of type BOOLEAN.
1. 論理演算子。 内容がある要素はブールでタイプされます。
2. byte. The element content is of type BYTE.
2. バイト。 タイプBYTEには要素含有量があります。
3. character. The element content is of type CHARACTER.
3. キャラクタ。 要素含有量はタイプキャラクターのものです。
4. date-time. The element content is of type DATETIME.
4.日付-時間。 タイプDATETIMEには要素含有量があります。
5. integer. The element content is of type INTEGER.
5. 整数。 タイプINTEGERには要素含有量があります。
6. portlist. The element content is of type PORTLIST.
6. 「恰幅のい-者」。 タイプPORTLISTには要素含有量があります。
7. real. The element content is of type REAL.
7. 本当です。 タイプレアルには要素含有量があります。
8. string. The element content is of type STRING.
8. ストリング。 タイプSTRINGには要素含有量があります。
9. file. The element content is a base64 encoded binary file
encoded as a BYTE[] type.
9. ファイルしてください。 要素含有量はコード化されたバイナリーファイルがBYTE[]タイプとしてコード化したbase64です。
10. frame. The element content is a layer-2 frame encoded as a
HEXBIN type.
10. フレーム。 要素含有量はHEXBINタイプとしてコード化された層-2フレームです。
11. packet. The element content is a layer-3 packet encoded as a
HEXBIN type.
11. パケット。 要素含有量はHEXBINタイプとしてコード化された層-3パケットです。
12. ipv4-packet. The element content is an IPv4 packet encoded
as a HEXBIN type.
12. ipv4-パケット。 要素含有量はHEXBINタイプとしてコード化されたIPv4パケットです。
13. ipv6-packet. The element content is an IPv6 packet encoded
as a HEXBIN type.
13. ipv6-パケット。 要素含有量はHEXBINタイプとしてコード化されたIPv6パケットです。
14. path. The element content is a file-system path encoded as a
STRING type.
14. 経路。 要素含有量はSTRINGタイプとしてコード化されたファイルシステム経路です。
15. url. The element content is of type URL.
15. url。 要素含有量はタイプURLのものです。
16. csv. The element content is a common separated value (CSV)
list per Section 2 of [20] encoded as a STRING type.
16. csv。 STRINGタイプとしてコード化された[20]のセクション2あたり要素含有量は1つの一般的な切り離された値(CSV)のリストです。
17. winreg. The element content is a Windows registry key
encoded as a STRING type.
17. winreg要素含有量はSTRINGタイプとしてコード化されたWindows登録キーです。
Danyliw, et al. Standards Track [Page 17] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[17ページ]。
18. xml. The element content is XML (see Section 5).
18. xml。 要素含有量はXML(セクション5を見る)です。
19. ext-value. An escape value used to extend this attribute.
See Section 5.1.
19. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-dtype
Optional. STRING. A means by which to extend the dtype
attribute. See Section 5.1.
ext-dtype Optional。 結びます。 dtype属性を広げる手段。 セクション5.1を見てください。
meaning
Optional. STRING. A free-form description of the element
content.
Optionalを意味します。 結びます。 要素含有量の自由形式記述。
formatid
Optional. STRING. An identifier referencing the format and
semantics of the element content.
formatid Optional。 結びます。 要素含有量の形式と意味論に参照をつける識別子。
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されました。
3.7. Contact Class
3.7. 接触のクラス
The Contact class describes contact information for organizations and personnel involved in the incident. This class allows for the naming of the involved party, specifying contact information for them, and identifying their role in the incident.
Contactのクラスはインシデントにかかわる組織と人員のために問い合わせ先について説明します。 このクラスはかかわったパーティーの命名を考慮します、それらに問い合わせ先を指定して、インシデントでそれらの役割を特定して。
People and organizations are treated interchangeably as contacts; one can be associated with the other using the recursive definition of the class (the Contact class is aggregated into the Contact class). The 'type' attribute disambiguates the type of contact information being provided.
人々と組織は接触として互換性を持って扱われます。 クラスの回帰的定義を使用するもう片方に1つを関連づけることができます(ContactのクラスはContactのクラスに集められます)。 'タイプ'属性は提供される問い合わせ先のタイプのあいまいさを除きます。
The inheriting definition of Contact provides a way to relate information without requiring the explicit use of identifiers in the classes or duplication of data. A complete point of contact is derived by a particular traversal from the root Contact class to the leaf Contact class. As such, multiple points of contact might be specified in a single instance of a Contact class. Each child Contact class logically inherits contact information from its ancestors.
Contactの世襲定義はクラスかデータの重複における識別子の明白な使用を必要としないで情報について話す方法を提供します。 完全な連絡先は特定の根のContactのクラスから葉のContactのクラスまでの縦断で引き出されます。 そういうものとして、複数の連絡先がContactのクラスのただ一つのインスタンスで指定されるかもしれません。 それぞれの子供Contactのクラスは先祖から問い合わせ先を論理的に引き継ぎます。
Danyliw, et al. Standards Track [Page 18] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[18ページ]。
+------------------+
| Contact |
+------------------+
| ENUM role |<>--{0..1}--[ ContactName ]
| STRING ext-role |<>--{0..*}--[ Description ]
| ENUM type |<>--{0..*}--[ RegistryHandle ]
| STRING ext-type |<>--{0..1}--[ PostalAddress ]
| ENUM restriction |<>--{0..*}--[ Email ]
| |<>--{0..*}--[ Telephone ]
| |<>--{0..1}--[ Fax ]
| |<>--{0..1}--[ Timezone ]
| |<>--{0..*}--[ Contact ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
+------------------+ | 接触| +------------------+ | ENUMの役割| <>--0..1--[ContactName]| STRING ext-役割| <>--0..*--[記述]| ENUMはタイプします。| <>--0..*--[RegistryHandle]| STRING ext-タイプ| <>--0..1--[PostalAddress]| ENUM制限| <>--0..*--[メール]| | <>--0..*--[電話]| | <>--0..1--[ファックス]| | <>--0..1--[タイムゾーン]| | <>--0..*--[接触]| | <>--0..*--[AdditionalData]+------------------+
Figure 7: The Contact Class
図7: 接触のクラス
The aggregate classes that constitute the Contact class are:
Contactのクラスを構成する集約クラスは以下の通りです。
ContactName
Zero or one. ML_STRING. The name of the contact. The contact
may either be an organization or a person. The type attribute
disambiguates the semantics.
ContactName Zeroか1。 ミリリットル_ストリング。 接触の名前。 接触は、組織か人のどちらかであるかもしれません。 タイプ属性は意味論のあいまいさを除きます。
Description
Zero or many. ML_STRING. A free-form description of this
contact. In the case of a person, this is often the
organizational title of the individual.
記述Zeroか多く。 ミリリットル_ストリング。 この接触の自由形式記述。 人の場合では、しばしばこれは個人の組織的なタイトルです。
RegistryHandle
Zero or many. A handle name into the registry of the contact.
RegistryHandle Zeroか多く。 接触の登録へのハンドルネーム。
PostalAddress
Zero or one. The postal address of the contact.
PostalAddress Zeroか1。 接触の郵便の宛先。
Email
Zero or many. The email address of the contact.
Zeroか多くをメールしてください。 接触のEメールアドレス。
Telephone
Zero or many. The telephone number of the contact.
Zeroか多くに電話をしてください。 接触の電話番号。
Fax
Zero or one. The facsimile telephone number of the contact.
ファックスで、Zeroか1つを送ってください。 接触のファクシミリ電話番号。
Timezone
Zero or one. TIMEZONE. The timezone in which the contact resides
formatted according to Section 2.9.
タイムゾーンZeroか1。 タイムゾーン。 接触がセクション2.9によると、フォーマットされていた状態で住んでいるタイムゾーン。
Danyliw, et al. Standards Track [Page 19] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[19ページ]。
Contact
Zero or many. A Contact instance contained within another Contact
instance inherits the values of the parent(s). This recursive
definition can be used to group common data pertaining to multiple
points of contact and is especially useful when listing multiple
contacts at the same organization.
Zeroか多くに連絡してください。 別のContactインスタンスの中に含まれたContactインスタンスは親の値を引き継ぎます。 この回帰的定義は、複数の連絡先に関係する一般的なデータを分類するのに使用できて、同じ組織での複数の接触を記載するとき、特に役に立ちます。
AdditionalData
Zero or many. A mechanism by which to extend the data model.
AdditionalData Zeroか多く。 データモデルを広げるメカニズム。
At least one of the aggregate classes MUST be present in an instance of the Contact class. This is not enforced in the IODEF schema as there is no simple way to accomplish it.
少なくとも集約クラスの1つはContactのクラスのインスタンスで存在していなければなりません。 それを達成するどんな簡単な方法もなくて、これはIODEF図式で実施されません。
The Contact class has five attributes:
Contactのクラスには、5つの属性があります:
role
Required. ENUM. Indicates the role the contact fulfills. This
attribute is defined as an enumerated list:
役割のRequired。 ENUM。 接触が実現させる役割を示します。 この属性は列挙されたリストと定義されます:
1. creator. The entity that generate the document.
1. クリエイター。 ドキュメントを作る実体。
2. admin. An administrative contact for a host or network.
2. アドミン。 ホストかネットワークのドメイン管理者。
3. tech. A technical contact for a host or network.
3. 科学技術です。 ホストかネットワークの技術連絡担当者。
4. irt. The CSIRT involved in handling the incident.
4. irt。 CSIRTはインシデントに取り扱いにかかわりました。
5. cc. An entity that is to be kept informed about the handling
of the incident.
5. cc。 インシデントの取り扱いに関して知識があるように保たれることになっている実体。
6. ext-value. An escape value used to extend this attribute.
See Section 5.1.
6. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-role
Optional. STRING. A means by which to extend the role attribute.
See Section 5.1.
ext-役割のOptional。 結びます。 役割の属性を広げる手段。 セクション5.1を見てください。
type
Required. ENUM. Indicates the type of contact being described.
This attribute is defined as an enumerated list:
Requiredをタイプしてください。 ENUM。 説明される接触のタイプを示します。 この属性は列挙されたリストと定義されます:
1. person. The information for this contact references an
individual.
1. 人。 この接触のための情報は個人に参照をつけます。
2. organization. The information for this contact references an
organization.
2. 組織。 この接触のための情報は組織に参照をつけます。
Danyliw, et al. Standards Track [Page 20] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[20ページ]。
3. ext-value. An escape value used to extend this attribute.
See Section 5.1.
3. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-type
Optional. STRING. A means by which to extend the type attribute.
See Section 5.1.
Optionalをextタイプしてください。 結びます。 タイプ属性を広げる手段。 セクション5.1を見てください。
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されます。
3.7.1. RegistryHandle Class
3.7.1. RegistryHandleのクラス
The RegistryHandle class represents a handle into an Internet registry or community-specific database. The handle is specified in the element content and the type attribute specifies the database.
RegistryHandleのクラスはインターネット登録か共同体特有のデータベースにハンドルを表します。 ハンドルは要素含有量で指定されます、そして、タイプ属性はデータベースを指定します。
+---------------------+ | RegistryHandle | +---------------------+ | STRING | | | | ENUM registry | | STRING ext-registry | +---------------------+
+---------------------+ | RegistryHandle| +---------------------+ | ストリング| | | | ENUM登録| | STRING ext-登録| +---------------------+
Figure 8: The RegistryHandle Class
エイト環: RegistryHandleのクラス
The RegistryHandle class has two attributes:
RegistryHandleのクラスには、2つの属性があります:
registry
Required. ENUM. The database to which the handle belongs. The
default value is 'local'. The possible values are:
登録Required。 ENUM。 ハンドルが属するデータベース。 デフォルト値は'地方です'。 可能な値は以下の通りです。
1. internic. Internet Network Information Center
1. internicです。 インターネットネットワーク情報センター
2. apnic. Asia Pacific Network Information Center
2. apnicです。 エイピーニック
3. arin. American Registry for Internet Numbers
3. arin。 インターネット番号のためのアメリカの登録
4. lacnic. Latin-American and Caribbean IP Address Registry
4. lacnicです。 ラテンアメリカの、そして、カリブ海のIPアドレス登録
5. ripe. Reseaux IP Europeens
5. 熟します。 Reseaux IP Europeens
6. afrinic. African Internet Numbers Registry
6. afrinicです。 アフリカのインターネット数の登録
7. local. A database local to the CSIRT
7. 地方です。 CSIRTへのローカルのデータベース
Danyliw, et al. Standards Track [Page 21] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[21ページ]。
8. ext-value. An escape value used to extend this attribute.
See Section 5.1.
8. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-registry
Optional. STRING. A means by which to extend the registry
attribute. See Section 5.1.
ext-登録Optional。 結びます。 登録属性を広げる手段。 セクション5.1を見てください。
3.7.2. PostalAddress Class
3.7.2. PostalAddressのクラス
The PostalAddress class specifies a postal address formatted according to the POSTAL data type (Section 2.11).
PostalAddressのクラスはPOSTALデータ型(セクション2.11)によると、フォーマットされた郵便の宛先を指定します。
+---------------------+ | PostalAddress | +---------------------+ | POSTAL | | | | ENUM meaning | | ENUM lang | +---------------------+
+---------------------+ | PostalAddress| +---------------------+ | 郵便| | | | ENUM意味| | ENUM lang| +---------------------+
Figure 9: The PostalAddress Class
図9: PostalAddressのクラス
The PostalAddress class has two attributes:
PostalAddressのクラスには、2つの属性があります:
meaning
Optional. ENUM. A free-form description of the element content.
Optionalを意味します。 ENUM。 要素含有量の自由形式記述。
lang
Required. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6.
lang Required。 ENUM。 「xs: 言語」の定義で抑制されたRFC4646[7]あたり1つの有効な言語コード。 このコードの解釈はセクション6で説明されます。
3.7.3. Email Class
3.7.3. メールのクラス
The Email class specifies an email address formatted according to EMAIL data type (Section 2.14).
メールのクラスはメールデータ型(セクション2.14)によると、フォーマットされたEメールアドレスを指定します。
+--------------+ | Email | +--------------+ | EMAIL | | | | ENUM meaning | +--------------+
+--------------+ | メール| +--------------+ | メール| | | | ENUM意味| +--------------+
Figure 10: The Email Class
図10: メールのクラス
Danyliw, et al. Standards Track [Page 22] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[22ページ]。
The Email class has one attribute:
メールのクラスには、1つの属性があります:
meaning
Optional. ENUM. A free-form description of the element content.
Optionalを意味します。 ENUM。 要素含有量の自由形式記述。
3.7.4. Telephone and Fax Classes
3.7.4. 電話とファックスのクラス
The Telephone and Fax classes specify a voice or fax telephone number respectively, and are formatted according to PHONE data type (Section 2.13).
Telephoneとファックスのクラスは、それぞれ声かファックス電話番号を指定して、電話データ型(セクション2.13)によると、フォーマットされます。
+--------------------+
| {Telephone | Fax } |
+--------------------+
| PHONE |
| |
| ENUM meaning |
+--------------------+
+--------------------+ | {電話をしてください| ファックス}| +--------------------+ | 電話| | | | ENUM意味| +--------------------+
Figure 11: The Telephone and Fax Classes
図11: 電話とファックスのクラス
The Telephone class has one attribute:
Telephoneのクラスには、1つの属性があります:
meaning
Optional. ENUM. A free-form description of the element content
(e.g., hours of coverage for a given number).
Optionalを意味します。 ENUM。 要素含有量(例えば、与えられた数のための何時間もの適用範囲)の自由形式記述。
3.8. Time Classes
3.8. 時間のクラス
The data model uses five different classes to represent a timestamp. Their definition is identical, but each has a distinct name to convey a difference in semantics.
データモデルは、タイムスタンプを表すのに5つの異なったクラスを使用します。 彼らの定義は同じですが、それぞれには、意味論の違いを伝える別個の名前があります。
The element content of each class is a timestamp formatted according to the DATETIME data type (see Section 2.8).
それぞれのクラスの要素含有量はDATETIMEデータ型によると、フォーマットされたタイムスタンプ(セクション2.8を見る)です。
+----------------------------------+
| {Start| End| Report| Detect}Time |
+----------------------------------+
| DATETIME |
+----------------------------------+
+----------------------------------+ | 始め| 終わり| 報告してください|、検出、時間| +----------------------------------+ | DATETIME| +----------------------------------+
Figure 12: The Time Classes
図12: 時間のクラス
Danyliw, et al. Standards Track [Page 23] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[23ページ]。
3.8.1. StartTime
3.8.1. StartTime
The StartTime class represents the time the incident began.
StartTimeのクラスはインシデントが始まった時を表します。
3.8.2. EndTime
3.8.2. EndTime
The EndTime class represents the time the incident ended.
EndTimeのクラスはインシデントが終わった時を表します。
3.8.3. DetectTime
3.8.3. DetectTime
The DetectTime class represents the time the first activity of the incident was detected.
DetectTimeのクラスはインシデントの最初の活動が検出された時を表します。
3.8.4. ReportTime
3.8.4. ReportTime
The ReportTime class represents the time the incident was reported. This timestamp SHOULD coincide to the time at which the IODEF document is generated.
ReportTimeのクラスはインシデントが報告された時を表します。 このタイムスタンプSHOULDはIODEFドキュメントが発生している時まで一致します。
3.8.5. DateTime
3.8.5. DateTime
The DateTime class is a generic representation of a timestamp. Its semantics should be inferred from the parent class in which it is aggregated.
DateTimeのクラスはタイムスタンプのジェネリック表現です。 意味論はそれが集められる親のクラスから推論されるべきです。
3.9. Method Class
3.9. メソッドのクラス
The Method class describes the methodology used by the intruder to perpetrate the events of the incident. This class consists of a list of references describing the attack method and a free form description of the technique.
Methodのクラスはインシデントのイベントを犯すのに侵入者によって使用された方法論について説明します。 このクラスはテクニックの攻撃メソッドと自由形式記述について説明する参考文献一覧から成ります。
+------------------+
| Method |
+------------------+
| ENUM restriction |<>--{0..*}--[ Reference ]
| |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
+------------------+ | メソッド| +------------------+ | ENUM制限| <>--0..*--[参照]| | <>--0..*--[記述]| | <>--0..*--[AdditionalData]+------------------+
Figure 13: The Method Class
図13: メソッドのクラス
The Method class is composed of three aggregate classes.
Methodのクラスは3つの集約クラスで構成されます。
Reference
Zero or many. A reference to a vulnerability, malware sample,
advisory, or analysis of an attack technique.
参照Zeroか多く。 攻撃のテクニックの脆弱性、マルウェアのサンプル、状況報告、または分析の参照。
Danyliw, et al. Standards Track [Page 24] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[24ページ]。
Description
Zero or many. ML_STRING. A free-form text description of the
methodology used by the intruder.
記述Zeroか多く。 ミリリットル_ストリング。 侵入者によって使用された方法論の自由形式テキスト記述。
AdditionalData
Zero or many. A mechanism by which to extend the data model.
AdditionalData Zeroか多く。 データモデルを広げるメカニズム。
Either an instance of the Reference or Description class MUST be present.
Referenceのインスタンスか記述のクラスのどちらかが存在していなければなりません。
The Method class has one attribute:
Methodのクラスには、1つの属性があります:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されます。
3.9.1. Reference Class
3.9.1. 参照のクラス
The Reference class is a reference to a vulnerability, IDS alert, malware sample, advisory, or attack technique. A reference consists of a name, a URL to this reference, and an optional description.
Referenceのクラスは脆弱性、IDS警戒、マルウェアのサンプル、状況報告、または攻撃のテクニックの参照です。 参照は名前、この参照へのURL、および任意の記述から成ります。
+------------------+
| Reference |
+------------------+
| |<>----------[ ReferenceName ]
| |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ Description ]
+------------------+
+------------------+ | 参照| +------------------+ | | <>、-、-、-、-、-、-、-、-、--[ReferenceName]| | <>--0..*--[URL]| | <>--0..*--[記述]+------------------+
Figure 14: The Reference Class
図14: 参照のクラス
The aggregate classes that constitute Reference:
Referenceを構成する集約クラス:
ReferenceName
One. ML_STRING. Name of the reference.
ReferenceName1。 ミリリットル_ストリング。 参照の名前。
URL
Zero or many. URL. A URL associated with the reference.
URL Zeroか多く。 URL。 参照に関連しているURL。
Description
Zero or many. ML_STRING. A free-form text description of this
reference.
記述Zeroか多く。 ミリリットル_ストリング。 この参照の自由形式テキスト記述。
3.10. Assessment Class
3.10. 査定のクラス
The Assessment class describes the technical and non-technical repercussions of the incident on the CSIRT's constituency.
AssessmentのクラスはCSIRTの選挙民の上でインシデントの技術的で非技術系の跳ね返りについて説明します。
Danyliw, et al. Standards Track [Page 25] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[25ページ]。
This class was derived from the IDMEF[17].
IDMEF[17]からこのクラスを得ました。
+------------------+
| Assessment |
+------------------+
| ENUM occurrence |<>--{0..*}--[ Impact ]
| ENUM restriction |<>--{0..*}--[ TimeImpact ]
| |<>--{0..*}--[ MonetaryImpact ]
| |<>--{0..*}--[ Counter ]
| |<>--{0..1}--[ Confidence ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
+------------------+ | 査定| +------------------+ | ENUM発生| <>--0..*--[影響]| ENUM制限| <>--0..*--[TimeImpact]| | <>--0..*--[MonetaryImpact]| | <>--0..*--[カウンタ]| | <>--0..1--[信用]| | <>--0..*--[AdditionalData]+------------------+
Figure 15: Assessment Class
図15: 査定のクラス
The aggregate classes that constitute Assessment are:
Assessmentを構成する集約クラスは以下の通りです。
Impact
Zero or many. Technical impact of the incident on a network.
Zeroか多くに影響を与えてください。 ネットワークのインシデントの技術的な影響。
TimeImpact
Zero or many. Impact of the activity measured with respect to
time.
TimeImpact Zeroか多く。 活動の影響は時間に関して測定しました。
MonetaryImpact
Zero or many. Impact of the activity measured with respect to
financial loss.
MonetaryImpact Zeroか多く。 活動の影響は金融赤字に関して測定しました。
Counter
Zero or more. A counter with which to summarize the magnitude of
the activity.
Zeroか以上を打ち返してください。 活動の大きさをまとめるカウンタ。
Confidence
Zero or one. An estimate of confidence in the assessment.
信用Zeroか1。 査定における信用の見積り。
AdditionalData
Zero or many. A mechanism by which to extend the data model.
AdditionalData Zeroか多く。 データモデルを広げるメカニズム。
A least one instance of the possible three impact classes (i.e., Impact, TimeImpact, or MonetaryImpact) MUST be present.
3つの可能な影響のクラス(すなわち、Impact、TimeImpact、またはMonetaryImpact)の最少の1つのインスタンスが存在していなければなりません。
The Assessment class has two attributes:
Assessmentのクラスには、2つの属性があります:
occurrence
Optional. ENUM. Specifies whether the assessment is describing
actual or potential outcomes. The default is "actual" and is
assumed if not specified.
発生Optional。 ENUM。 査定が実際の、または、潜在的の結果について説明しているかどうか指定します。 デフォルトは、「実際」、想定されるか、または指定されます。
Danyliw, et al. Standards Track [Page 26] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[26ページ]。
1. actual. This assessment describes activity that has occurred.
1. 実際です。 この査定は起こった活動について説明します。
2. potential. This assessment describes potential activity that
might occur.
2. 潜在的です。 この査定は起こるかもしれない潜在的活動について説明します。
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されます。
3.10.1. Impact Class
3.10.1. 影響のクラス
The Impact class allows for categorizing and describing the technical impact of the incident on the network of an organization.
Impactのクラスは、組織のネットワークでインシデントの技術的な影響を分類して、説明すると考慮します。
This class is based on the IDMEF [17].
このクラスはIDMEF[17]に基づいています。
+------------------+ | Impact | +------------------+ | ML_STRING | | | | ENUM lang | | ENUM severity | | ENUM completion | | ENUM type | | STRING ext-type | +------------------+
+------------------+ | 影響| +------------------+ | ミリリットル_ストリング| | | | ENUM lang| | ENUMの厳しさ| | ENUM完成| | ENUMはタイプします。| | STRING ext-タイプ| +------------------+
Figure 16: Impact Class
図16: 影響のクラス
The element content will be a free-form textual description of the impact.
要素含有量は影響の自由形式の原文の記述になるでしょう。
The Impact class has five attributes:
Impactのクラスには、5つの属性があります:
lang
Required. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6.
lang Required。 ENUM。 「xs: 言語」の定義で抑制されたRFC4646[7]あたり1つの有効な言語コード。 このコードの解釈はセクション6で説明されます。
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
厳しさOptional。 ENUM。 活動の相対的な厳しさの見積り。 受入れられた値は以下に示されます。 デフォルト値が全くありません。
Danyliw, et al. Standards Track [Page 27] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[27ページ]。
1. low. Low severity
1. 低いです。 低厳しさ
2. medium. Medium severity
2. 中型です。 中型の厳しさ
3. high. High severity
3. 高いです。 高い厳しさ
completion
Optional. ENUM. An indication whether the described activity was
successful. The permitted values are shown below. There is no
default value.
完成Optional。 ENUM。 指示、説明された活動はうまくいくのであったかどうか 受入れられた値は以下に示されます。 デフォルト値が全くありません。
1. failed. The attempted activity was not successful.
1. 失敗されています。 試みられた活動はうまくいきませんでした。
2. succeeded. The attempted activity succeeded.
2. 引き継がれます。 試みられた活動は成功しました。
type
Required. ENUM. Classifies the malicious activity into incident
categories. The permitted values are shown below. The default
value is "other".
Requiredをタイプしてください。 ENUM。 悪意がある活動を付随しているカテゴリに分類します。 受入れられた値は以下に示されます。 デフォルト値は「他です」。
1. admin. Administrative privileges were attempted.
1. アドミン。 管理特権は試みられました。
2. dos. A denial of service was attempted.
2. dos。 サービスの否定は試みられました。
3. file. An action that impacts the integrity of a file or
database was attempted.
3. ファイルしてください。 ファイルかデータベースの保全に影響を与える動作は試みられました。
4. info-leak. An attempt was made to exfiltrate information.
4. インフォメーションで漏れてください。 試みを外濾過情報にしました。
5. misconfiguration. An attempt was made to exploit a mis-
configuration in a system.
5. misconfiguration。 システムでの誤構成を利用するのを試みをしました。
6. policy. Activity violating site's policy was attempted.
6. 方針。 サイトの方針に違反する活動が試みられました。
7. recon. Reconnaissance activity was attempted.
7. 探察。 偵察活動は試みられました。
8. social-engineering. A social engineering attack was
attempted.
8. ソーシャルエンジニアリング。 ソーシャルエンジニアリング攻撃は試みられました。
9. user. User privileges were attempted.
9. ユーザ。 ユーザ特権は試みられました。
10. unknown. The classification of this activity is unknown.
10. 未知です。 この活動の分類は未知です。
11. ext-value. An escape value used to extend this attribute.
See Section 5.1.
11. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
Danyliw, et al. Standards Track [Page 28] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[28ページ]。
ext-type
Optional. STRING. A means by which to extend the type attribute.
See Section 5.1.
Optionalをextタイプしてください。 結びます。 タイプ属性を広げる手段。 セクション5.1を見てください。
3.10.2. TimeImpact Class
3.10.2. TimeImpactのクラス
The TimeImpact class describes the impact of the incident on an organization as a function of time. It provides a way to convey down time and recovery time.
TimeImpactのクラスは、組織でインシデントの影響を時間の関数と説明します。 それは休止時間と回復時間を伝える方法を提供します。
+---------------------+
| TimeImpact |
+---------------------+
| REAL |
| |
| ENUM severity |
| ENUM metric |
| STRING ext-metric |
| ENUM duration |
| STRING ext-duration |
+---------------------+
+---------------------+ | TimeImpact| +---------------------+ | 本当| | | | ENUMの厳しさ| | ENUMメートル法です。| | STRING extメートル法です。| | ENUM持続時間| | STRING ext-持続時間| +---------------------+
Figure 17: TimeImpact Class
図17: TimeImpactのクラス
The element content is a positive, floating point (REAL) number specifying a unit of time. The duration and metric attributes will imply the semantics of the element content.
要素含有量は時間の単位を指定する積極的な浮動小数点(レアル)番号です。 持続時間とメートル法の属性は要素含有量の意味論を含意するでしょう。
The TimeImpact class has five attributes:
TimeImpactのクラスには、5つの属性があります:
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
厳しさOptional。 ENUM。 活動の相対的な厳しさの見積り。 受入れられた値は以下に示されます。 デフォルト値が全くありません。
1. low. Low severity
1. 低いです。 低厳しさ
2. medium. Medium severity
2. 中型です。 中型の厳しさ
3. high. High severity
3. 高いです。 高い厳しさ
metric
Required. ENUM. Defines the metric in which the time is
expressed. The permitted values are shown below. There is no
default value.
メートル法のRequired。 ENUM。 時間が言い表されるメートル法を定義します。 受入れられた値は以下に示されます。 デフォルト値が全くありません。
Danyliw, et al. Standards Track [Page 29] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[29ページ]。
1. labor. Total staff-time to recovery from the activity (e.g.,
2 employees working 4 hours each would be 8 hours).
1. 働いてください。 活動からの回復にスタッフ時間を合計してください(例えば、4時間それぞれ働いている2人の従業員が8時間でしょう)。
2. elapsed. Elapsed time from the beginning of the recovery to
its completion (i.e., wall-clock time).
2. 経過しています。 完成への回復(すなわち、柱時計時間)の始まりからの経過時間。
3. downtime. Duration of time for which some provided service(s)
was not available.
3. 休止時間。 或るものがサービスを提供した時間の持続時間は利用可能ではありませんでした。
4. ext-value. An escape value used to extend this attribute.
See Section 5.1.
4. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-metric
Optional. STRING. A means by which to extend the metric
attribute. See Section 5.1.
extメートル法のOptional。 結びます。 メートル法の属性を広げる手段。 セクション5.1を見てください。
duration
Required. ENUM. Defines a unit of time, that when combined with
the metric attribute, fully describes a metric of impact that will
be conveyed in the element content. The permitted values are
shown below. The default value is "hour".
持続時間Required。 ENUM。 定義、時間の単位、いつがメートル法の属性に完全に結合したかが要素含有量で伝えられる影響におけるメートル法のaについて説明します。 受入れられた値は以下に示されます。 デフォルト値は「時間」です。
1. second. The unit of the element content is seconds.
1. 2番目。 要素含有量の単位は秒です。
2. minute. The unit of the element content is minutes.
2. 微小です。 要素含有量の単位は数分です。
3. hour. The unit of the element content is hours.
3.時間。 要素含有量の単位は何時間であるのも。
4. day. The unit of the element content is days.
4. 日。 要素含有量の単位は何日であるのも。
5. month. The unit of the element content is months.
5. 月。 要素含有量の単位は何カ月であるのも。
6. quarter. The unit of the element content is quarters.
6. 4分の1。 要素含有量の単位は四半期です。
7. year. The unit of the element content is years.
7. 年。 要素含有量の単位は何年であるのも。
8. ext-value. An escape value used to extend this attribute.
See Section 5.1.
8. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-duration
Optional. STRING. A means by which to extend the duration
attribute. See Section 5.1.
ext-持続時間Optional。 結びます。 持続時間属性を広げる手段。 セクション5.1を見てください。
3.10.3. MonetaryImpact Class
3.10.3. MonetaryImpactのクラス
The MonetaryImpact class describes the financial impact of the activity on an organization. For example, this impact may consider losses due to the cost of the investigation or recovery, diminished
MonetaryImpactのクラスは組織で活動の財政的な影響について説明します。 この影響は、調査か回復の費用による損失であると例えば、減少すると考えるかもしれません。
Danyliw, et al. Standards Track [Page 30] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[30ページ]。
productivity of the staff, or a tarnished reputation that will affect future opportunities.
スタッフの生産性、または将来の機会に影響する汚れた名声。
+------------------+
| MonetaryImpact |
+------------------+
| REAL |
| |
| ENUM severity |
| STRING currency |
+------------------+
+------------------+ | MonetaryImpact| +------------------+ | 本当| | | | ENUMの厳しさ| | STRING通貨| +------------------+
Figure 18: MonetaryImpact Class
図18: MonetaryImpactのクラス
The element content is a positive, floating point number (REAL) specifying a unit of currency described in the currency attribute.
要素含有量は通貨属性で説明された通貨のユニットを指定する積極的な浮動小数点(レアル)です。
The MonetaryImpact class has two attributes:
MonetaryImpactのクラスには、2つの属性があります:
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
厳しさOptional。 ENUM。 活動の相対的な厳しさの見積り。 受入れられた値は以下に示されます。 デフォルト値が全くありません。
1. low. Low severity
1. 低いです。 低厳しさ
2. medium. Medium severity
2. 中型です。 中型の厳しさ
3. high. High severity
3. 高いです。 高い厳しさ
currency
Required. STRING. Defines the currency in which the monetary
impact is expressed. The permitted values are defined in ISO
4217:2001, Codes for the representation of currencies and funds
[14]. There is no default value.
通貨Required。 結びます。 通貨の影響が言い表される通貨を定義します。 受入れられた値はISOで定義されます。4217:2001 通貨と基金[14]の表現のためのCodes。 デフォルト値が全くありません。
3.10.4. Confidence Class
3.10.4. 信用のクラス
The Confidence class represents a best estimate of the validity and accuracy of the described impact (see Section 3.10) of the incident activity. This estimate can be expressed as a category or a numeric calculation.
Confidenceのクラスは付随している活動の説明された影響(セクション3.10を見る)の正当性と精度の最高の見積もりを表します。 カテゴリか数値計算としてこの見積りを表すことができます。
This class if based upon the IDMEF [17]).
IDMEF[17])に基づいているなら、これは属します。
Danyliw, et al. Standards Track [Page 31] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[31ページ]。
+------------------+
| Confidence |
+------------------+
| REAL |
| |
| ENUM rating |
+------------------+
+------------------+ | 信用| +------------------+ | 本当| | | | ENUM格付け| +------------------+
Figure 19: Confidence Class
図19: 信用のクラス
The element content expresses a numerical assessment in the confidence of the data when the value of the rating attribute is "numeric". Otherwise, this element should be empty.
格付けの属性の値が「数値である」ときに、要素含有量はデータの信用で数字の査定を言い表します。 さもなければ、この要素は空であるべきです。
The Confidence class has one attribute.
Confidenceのクラスには、1つの属性があります。
rating
Required. ENUM. A rating of the analytical validity of the
specified Assessment. The permitted values are shown below.
There is no default value.
Requiredを評定します。 ENUM。 指定されたAssessmentの分析正当性の格付け。 受入れられた値は以下に示されます。 デフォルト値が全くありません。
1. low. Low confidence in the validity.
1. 低いです。 正当性における低い信用。
2. medium. Medium confidence in the validity.
2. 中型です。 正当性における中型の信用。
3. high. High confidence in the validity.
3. 高いです。 正当性における高い信用。
4. numeric. The element content contains a number that conveys
the confidence of the data. The semantics of this number
outside the scope of this specification.
4. 数値です。 要素含有量はデータの信用を伝える数を含んでいます。 この仕様の範囲の外のこの数の意味論。
3.11. History Class
3.11. 歴史の授業
The History class is a log of the significant events or actions performed by the involved parties during the course of handling the incident.
歴史のクラスはインシデントを扱うコースの間に関係者によって実行された重大な行事か動作に関するログです。
The level of detail maintained in this log is left up to the discretion of those handling the incident.
このログで維持された詳細のレベルはインシデントを扱うものの思慮深さに任せられます。
+------------------+
| History |
+------------------+
| ENUM restriction |<>--{1..*}--[ HistoryItem ]
| |
+------------------+
+------------------+ | 歴史| +------------------+ | ENUM制限| <>--1..*--[HistoryItem]| | +------------------+
Danyliw, et al. Standards Track [Page 32] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[32ページ]。
Figure 20: The History Class
図20: 歴史の授業
The class that constitutes History is:
歴史を構成するクラスは以下の通りです。
HistoryItem
One or many. Entry in the history log of significant events or
actions performed by the involved parties.
HistoryItem Oneか多く。 重大な行事か動作に関する活動ログにおけるエントリーは関係者で働きました。
The History class has one attribute:
歴史のクラスには、1つの属性があります:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されます。
3.11.1. HistoryItem Class
3.11.1. HistoryItemのクラス
The HistoryItem class is an entry in the History (Section 3.11) log that documents a particular action or event that occurred in the course of handling the incident. The details of the entry are a free-form description, but each can be categorized with the type attribute.
HistoryItemのクラスはインシデントを扱うことの間に起こった特定の動作かイベントを記録する歴史(セクション3.11)ログでエントリーです。 エントリーの詳細は自由形式記述ですが、タイプ属性でそれぞれを分類できます。
+-------------------+
| HistoryItem |
+-------------------+
| ENUM restriction |<>----------[ DateTime ]
| ENUM action |<>--{0..1}--[ IncidentId ]
| STRING ext-action |<>--{0..1}--[ Contact ]
| |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ]
+-------------------+
+-------------------+ | HistoryItem| +-------------------+ | ENUM制限| <>、-、-、-、-、-、-、-、-、--[DateTime]| ENUM動作| <>--0..1--[IncidentId]| STRING ext-動作| <>--0..1--[接触]| | <>--0..*--[記述]| | <>--0..*--[AdditionalData]+-------------------+
Figure 21: HistoryItem Class
図21: HistoryItemのクラス
The aggregate classes that constitute HistoryItem are:
HistoryItemを構成する集約クラスは以下の通りです。
DateTime
One. Timestamp of this entry in the history log (e.g., when the
action described in the Description was taken).
DateTime1。 活動ログ(例えば、記述で説明された行動を取ったとき)におけるこのエントリーに関するタイムスタンプ。
IncidentID
Zero or One. In a history log created by multiple parties, the
IncidentID provides a mechanism to specify which CSIRT created a
particular entry and references this organization's incident
tracking number. When a single organization is maintaining the
log, this class can be ignored.
IncidentIDゼロか1。 複数のパーティーによって作成された活動ログでは、IncidentIDは、数を追跡しながら、どのCSIRTが特定のエントリーを作成したかを指定するメカニズムと参照にこの組織のインシデントを供給します。 単純組織がログを維持しているとき、このクラスを無視できます。
Danyliw, et al. Standards Track [Page 33] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[33ページ]。
Contact
Zero or One. Provides contact information for the person that
performed the action documented in this class.
ゼロか1つに連絡してください。 このクラスで記録された動作を実行した人に問い合わせ先を提供します。
Description
Zero or many. ML_STRING. A free-form textual description of the
action or event.
記述Zeroか多く。 ミリリットル_ストリング。 動作かイベントの自由形式の原文の記述。
AdditionalData
Zero or many. A mechanism by which to extend the data model.
AdditionalData Zeroか多く。 データモデルを広げるメカニズム。
The HistoryItem class has three attributes:
HistoryItemのクラスには、3つの属性があります:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されました。
action
Required. ENUM. Classifies a performed action or occurrence
documented in this history log entry. As activity will likely
have been instigated either through a previously conveyed
expectation or internal investigation, this attribute is identical
to the category attribute of the Expectation class. The
difference is only one of tense. When an action is in this class,
it has been completed. See Section 3.13.
動作Required。 ENUM。 この活動ログエントリーに記録された実行された動作か発生を分類します。 活動が以前に運ばれた期待か内部調査でおそらく扇動されてしまうだろうので、この属性はExpectationのクラスのカテゴリ属性と同じです。 違いは1であるだけです。時制について。 このクラスに動作があるとき、それは完成しました。 セクション3.13を見てください。
ext-action
Optional. STRING. A means by which to extend the action
attribute. See Section 5.1.
ext-動作Optional。 結びます。 動作属性を広げる手段。 セクション5.1を見てください。
3.12. EventData Class
3.12. EventDataのクラス
The EventData class describes a particular event of the incident for a given set of hosts or networks. This description includes the systems from which the activity originated and those targeted, an assessment of the techniques used by the intruder, the impact of the activity on the organization, and any forensic evidence discovered.
EventDataのクラスは与えられたセットのホストかネットワークのためにインシデントの特定のイベントについて説明します。 この記述は活動が起因したシステムと狙うものを含んでいます、と侵入者によって使用されたテクニックの評価、組織の活動の影響、およびどんな法医学的証拠も発見しました。
Danyliw, et al. Standards Track [Page 34] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[34ページ]。
+------------------+
| EventData |
+------------------+
| ENUM restriction |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>--{0..*}--[ Contact ]
| |<>--{0..1}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{0..*}--[ Flow ]
| |<>--{0..*}--[ Expectation ]
| |<>--{0..1}--[ Record ]
| |<>--{0..*}--[ EventData ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
+------------------+ | EventData| +------------------+ | ENUM制限| <>--0..*--[記述]| | <>--0..1--[DetectTime]| | <>--0..1--[StartTime]| | <>--0..1--[EndTime]| | <>--0..*--[接触]| | <>--0..1--[査定]| | <>--0..*--[メソッド]| | <>--0..*--[流れ]| | <>--0..*--[期待]| | <>--0..1--[記録]| | <>--0..*--[EventData]| | <>--0..*--[AdditionalData]+------------------+
Figure 22: The EventData Class
図22: EventDataのクラス
The aggregate classes that constitute EventData are:
EventDataを構成する集約クラスは以下の通りです。
Description
Zero or more. ML_STRING. A free-form textual description of the
event.
記述Zeroか以上。 ミリリットル_ストリング。 イベントの自由形式の原文の記述。
DetectTime
Zero or one. The time the event was detected.
DetectTime Zeroか1。 イベントが検出された時。
StartTime
Zero or one. The time the event started.
StartTime Zeroか1。 イベントが始まった時。
EndTime
Zero or one. The time the event ended.
EndTime Zeroか1。 イベントが終わった時。
Contact
Zero or more. Contact information for the parties involved in the
event.
Zeroか以上に連絡してください。 イベントにかかわるパーティーへの問い合わせ先。
Assessment
Zero or one. The impact of the event on the target and the
actions taken.
査定Zeroか1。 目標と取られた行動でのイベントの影響。
Method
Zero or more. The technique used by the intruder in the event.
メソッドZeroか以上。 イベントにおける侵入者によって使用されたテクニック。
Danyliw, et al. Standards Track [Page 35] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[35ページ]。
Flow
Zero or more. A description of the systems or networks involved.
流れZeroか以上。 かかわったシステムかネットワークの記述。
Expectation
Zero or more. The expected action to be performed by the
recipient for the described event.
期待Zeroか以上。 説明されたイベントのために受取人によって実行されるべき予想された動作。
Record
Zero or one. Supportive data (e.g., log files) that provides
additional information about the event.
Zeroか1を記録してください。 イベントに関する追加情報を提供する支持しているデータ(例えば、ログファイル)。
EventData
Zero or more. EventData instances contained within another
EventData instance inherit the values of the parent(s); this
recursive definition can be used to group common data pertaining
to multiple events. When EventData elements are defined
recursively, only the leaf instances (those EventData instances
not containing other EventData instances) represent actual events.
EventData Zeroか以上。 別のEventDataインスタンスの中に含まれたEventDataインスタンスは親の値を引き継ぎます。 複数のイベントに関係する一般的なデータを分類するのにこの回帰的定義を使用できます。 EventData要素が再帰的に定義されるとき、葉のインスタンス(他のEventDataインスタンスを含まないそれらのEventDataインスタンス)だけが現実の出来事を表します。
AdditionalData
Zero or more. An extension mechanism for data not explicitly
represented in the data model.
AdditionalData Zeroか以上。 データモデルで明らかに表されなかったデータのための拡張機能。
At least one of the aggregate classes MUST be present in an instance of the EventData class. This is not enforced in the IODEF schema as there is no simple way to accomplish it.
少なくとも集約クラスの1つはEventDataのクラスのインスタンスで存在していなければなりません。 それを達成するどんな簡単な方法もなくて、これはIODEF図式で実施されません。
The EventData class has one attribute:
EventDataのクラスには、1つの属性があります:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されます。
3.12.1. Relating the Incident and EventData Classes
3.12.1. インシデントとEventDataのクラスを関係づけます。
There is substantial overlap in the Incident and EventData classes. Nevertheless, the semantics of these classes are quite different. The Incident class provides summary information about the entire incident, while the EventData class provides information about the individual events comprising the incident. In the most common case, the EventData class will provide more specific information for the general description provided in the Incident class. However, it may also be possible that the overall summarized information about the incident conflicts with some individual information in an EventData class when there is a substantial composition of various events in the incident. In such a case, the interpretation of the more specific EventData MUST supersede the more generic information provided in IncidentData.
IncidentとEventDataのクラスにはかなりのオーバラップがあります。 それにもかかわらず、これらのクラスの意味論は全く異なっています。 Incidentのクラスは全体のインシデントの概要情報を提供します、EventDataのクラスがインシデントを包括する個人種目の情報を提供しますが。 最も一般的な場合では、EventDataのクラスはIncidentのクラスに提供された概説のための、より特定の情報を提供するでしょう。 しかしながら、また、様々なイベントのかなりの構成がインシデントにあるとき、インシデントの総合的なまとめられた情報がEventDataのクラスにおける何らかの個人情報と衝突するのも、可能であるかもしれません。 このような場合には、より特定のEventDataの解釈はIncidentDataに提供されたより多くのジェネリック情報に取って代わらなければなりません。
Danyliw, et al. Standards Track [Page 36] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[36ページ]。
3.12.2. Cardinality of EventData
3.12.2. EventDataの基数
The EventData class can be thought of as a container for the properties of an event in an incident. These properties include: the hosts involved, impact of the incident activity on the hosts, forensic logs, etc. With an instance of the EventData class, hosts (i.e., System class) are grouped around these common properties.
イベントの特性のためのコンテナとしてインシデントでEventDataのクラスを考えることができます。 これらの特性は: かかわったホスト、ホストにおける付随している活動の影響、法廷のログなど EventDataのクラスのインスタンスで、ホスト(すなわち、Systemのクラス)はこれらの通有性の周りで分類されます。
The recursive definition (or instance property inheritance) of the EventData class (the EventData class is aggregated into the EventData class) provides a way to related information without requiring the explicit use of unique attribute identifiers in the classes or duplicating information. Instead, the relative depth (nesting) of a class is used to group (relate) information.
クラスにおけるユニークな属性識別子の明白な使用を必要とするか、または情報を二重化しないで、EventDataのクラス(EventDataのクラスはEventDataのクラスに集められる)の回帰的定義(または、インスタンス財産相続)は関連する情報への道を提供します。 代わりに、クラスの相対的な深さ(巣篭もり)は、情報を分類すること(関係する)に使用されます。
For example, an EventData class might be used to describe two machines involved in an incident. This description can be achieved using multiple instances of the Flow class. It happens that there is a common technical contact (i.e., Contact class) for these two machines, but the impact (i.e., Assessment class) on them is different. A depiction of the representation for this situation can be found in Figure 23.
例えば、EventDataのクラスは、インシデントにかかわる2台のマシンについて説明するのに使用されるかもしれません。 Flowのクラスの複数のインスタンスを使用することでこの記述を達成できます。 これらの2台のマシンのための一般的な技術連絡担当者(すなわち、Contactのクラス)が偶然いますが、それらの上の影響(すなわち、Assessmentのクラス)は異なっています。 図23でこの状況の表現の描写を見つけることができます。
+------------------+ | EventData | +------------------+ | |<>----[ Contact ] | | | |<>----[ EventData ]<>----[ Flow ] | | [ ]<>----[ Assessment ] | | | |<>----[ EventData ]<>----[ Flow ] | | [ ]<>----[ Assessment ] +------------------+
+------------------+ | EventData| +------------------+ | | <>、-、-、--[接触]| | | | <>、-、-、--[EventData]<>。----[流れ]| | [ ] <>。----[査定]| | | | <>、-、-、--[EventData]<>。----[流れ]| | [ ] <>。----[査定] +------------------+
Figure 23: Recursion in the EventData Class
図23: EventDataのクラスにおける再帰
3.13. Expectation Class
3.13. 期待のクラス
The Expectation class conveys to the recipient of the IODEF document the actions the sender is requesting. The scope of the requested action is limited to purview of the EventData class in which this class is aggregated.
Expectationのクラスは送付者が要求している動作をIODEFドキュメントの受取人に伝えます。 要求された動作の範囲はこのクラスが集められるEventDataのクラスの範囲に制限されます。
Danyliw, et al. Standards Track [Page 37] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[37ページ]。
+-------------------+
| Expectation |
+-------------------+
| ENUM restriction |<>--{0..*}--[ Description ]
| ENUM severity |<>--{0..1}--[ StartTime ]
| ENUM action |<>--{0..1}--[ EndTime ]
| STRING ext-action |<>--{0..1}--[ Contact ]
+-------------------+
+-------------------+ | 期待| +-------------------+ | ENUM制限| <>--0..*--[記述]| ENUMの厳しさ| <>--0..1--[StartTime]| ENUM動作| <>--0..1--[EndTime]| STRING ext-動作| <>--0..1--[接触]+-------------------+
Figure 24: The Expectation Class
図24: 期待のクラス
The aggregate classes that constitute Expectation are:
Expectationを構成する集約クラスは以下の通りです。
Description
Zero or many. ML_STRING. A free-form description of the desired
action(s).
記述Zeroか多く。 ミリリットル_ストリング。 必要な動作の自由形式記述。
StartTime
Zero or one. The time at which the action should be performed. A
timestamp that is earlier than the ReportTime specified in the
Incident class denotes that the expectation should be fulfilled as
soon as possible. The absence of this element leaves the
execution of the expectation to the discretion of the recipient.
StartTime Zeroか1。 動作が実行されるべきである時。 ReportTimeがIncidentのクラスで指定したより初期のタイムスタンプは、期待ができるだけ早く実現するべきであるのを指示します。 この要素の欠如は期待の実行を受取人に任せます。
EndTime
Zero or one. The time by which the action should be completed.
If the action is not carried out by this time, it should no longer
be performed.
EndTime Zeroか1。 時間。操作が完了するべきである 今回までに動作を行わないなら、もうそれを実行するべきではありません。
Contact
Zero or one. The expected actor for the action.
Zeroか1つに連絡してください。 動作のための予想された俳優。
The Expectations class has four attributes:
Expectationsのクラスには、4つの属性があります:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されます。
severity
Optional. ENUM. Indicates the desired priority of the action.
This attribute is an enumerated list with no default value, and
the semantics of these relative measures are context dependent.
厳しさOptional。 ENUM。 動作の必要な優先権を示します。 この属性はデフォルト値がなければ列挙されたリストです、そして、これらの相対的な測定の意味論は文脈に依存しています。
1. low. Low priority
1. 低いです。 低い優先度
2. medium. Medium priority
2. 中型です。 中型の優先権
3. high. High priority
3. 高いです。 高い優先度
Danyliw, et al. Standards Track [Page 38] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[38ページ]。
action
Optional. ENUM. Classifies the type of action requested. This
attribute is an enumerated list with no default value.
動作Optional。 ENUM。 要求された動作のタイプを分類します。 この属性はデフォルト値がなければ列挙されたリストです。
1. nothing. No action is requested. Do nothing with the
information.
1. 何でもない。 動作は全く要求されていません。 情報で何もしないでください。
2. contact-source-site. Contact the site(s) identified as the
source of the activity.
2. ソースサイトに接触してください。 活動の源として特定されたサイトに接触してください。
3. contact-target-site. Contact the site(s) identified as the
target of the activity.
3. 目標サイトに接触してください。 活動の目標として特定されたサイトに接触してください。
4. contact-sender. Contact the originator of the document.
4. 接触送付者。 ドキュメントの創始者に連絡してください。
5. investigate. Investigate the systems(s) listed in the event.
5. 調査してください。 イベントで記載されたシステムを調査してください。
6. block-host. Block traffic from the machine(s) listed as
sources the event.
6. ブロックホスト。 マシンからのブロックトラフィックはソースとしてイベントを記載しました。
7. block-network. Block traffic from the network(s) lists as
sources in the event.
7. ブロックネットワーク。 ネットワークからのブロックトラフィックはソースとしてイベントで記載します。
8. block-port. Block the port listed as sources in the event.
8. ブロック港。 ソースとしてイベントで記載されたポートを妨げてください。
9. rate-limit-host. Rate-limit the traffic from the machine(s)
listed as sources in the event.
9. 限界ホストを評定してください。 ソースとしてイベントで記載されたマシンからのトラフィックをレートで制限してください。
10. rate-limit-network. Rate-limit the traffic from the
network(s) lists as sources in the event.
10. 限界ネットワークを評定してください。 イベントにおけるソースとしてのネットワークリストからのトラフィックをレートで制限してください。
11. rate-limit-port. Rate-limit the port(s) listed as sources in
the event.
11. 限界ポートを評定してください。 ソースとしてイベントで記載されたポートをレートで制限してください。
12. remediate-other. Remediate the activity in a way other than
by rate limiting or blocking.
12. remediate他です。 Remediate、レート制限かブロッキング以外の道における活動。
13. status-triage. Conveys receipts and the triaging of an
incident.
13. 状態選別。 インシデントの領収書と「3-年をと」ることを伝えます。
14. status-new-info. Conveys that new information was received
for this incident.
14. 状態の新しいインフォメーション。 新情報がこのインシデントのために受け取られたのを運びます。
15. other. Perform some custom action described in the
Description class.
15. 他です。 記述のクラスで説明された何らかのカスタム動作を実行してください。
16. ext-value. An escape value used to extend this attribute.
See Section 5.1.
16. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
Danyliw, et al. Standards Track [Page 39] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[39ページ]。
ext-action
Optional. STRING. A means by which to extend the action
attribute. See Section 5.1.
ext-動作Optional。 結びます。 動作属性を広げる手段。 セクション5.1を見てください。
3.14. Flow Class
3.14. 流れのクラス
The Flow class groups related the source and target hosts.
Flow階級集団はソースと目標ホストを関係づけました。
+------------------+
| Flow |
+------------------+
| |<>--{1..*}--[ System ]
+------------------+
+------------------+ | 流れ| +------------------+ | | <>--1..*--[システム]+------------------+
Figure 25: The Flow Class
図25: 流れのクラス
The aggregate class that constitutes Flow is:
Flowを構成する集約クラスは以下の通りです。
System
One or More. A host or network involved in an event.
より多くのシステム1。 イベントにかかわるホストかネットワーク。
The Flow System class has no attributes.
Flow Systemのクラスには、属性が全くありません。
3.15. System Class
3.15. システムのクラス
The System class describes a system or network involved in an event. The systems or networks represented by this class are categorized according to the role they played in the incident through the category attribute. The value of this category attribute dictates the semantics of the aggregated classes in the System class. If the category attribute has a value of "source", then the aggregated classes denote the machine and service from which the activity is originating. With a category attribute value of "target" or "intermediary", then the machine or service is the one targeted in the activity. A value of "sensor" dictates that this System was part of an instrumentation to monitor the network.
Systemのクラスはイベントにかかわるシステムかネットワークについて説明します。 それらがカテゴリ属性を通してインシデントで果たした役割に従って、このクラスによって代表されたシステムかネットワークが分類されます。 このカテゴリ属性の値はSystemのクラスで集められたクラスの意味論を決めます。 「ソース」の値がカテゴリ属性にあるなら、集められたクラスは活動が起因しているマシンとサービスを指示します。 そして、「目標」か「仲介者」のカテゴリ属性値で、マシンかサービスが活動で狙うものです。 「センサ」の値は、ネットワークをモニターするためにこのSystemが計装の一部であったと決めます。
Danyliw, et al. Standards Track [Page 40] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[40ページ]。
+---------------------+
| System |
+---------------------+
| ENUM restriction |<>----------[ Node ]
| ENUM category |<>--{0..*}--[ Service ]
| STRING ext-category |<>--{0..*}--[ OperatingSystem ]
| STRING interface |<>--{0..*}--[ Counter ]
| ENUM spoofed |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ]
+---------------------+
+---------------------+ | システム| +---------------------+ | ENUM制限| <>、-、-、-、-、-、-、-、-、--[ノード]| ENUMカテゴリ| <>--0..*--[サービス]| STRING ext-カテゴリ| <>--0..*--[OperatingSystem]| STRINGインタフェース| <>--0..*--[カウンタ]| ENUMはだましました。| <>--0..*--[記述]| | <>--0..*--[AdditionalData]+---------------------+
Figure 26: The System Class
図26: システムのクラス
The aggregate classes that constitute System are:
Systemを構成する集約クラスは以下の通りです。
Node
One. A host or network involved in the incident.
ノード1。 インシデントにかかわるホストかネットワーク。
Service
Zero or more. A network service running on the system.
Zeroか以上を調整してください。 システムで動くネットワーク・サービス。
OperatingSystem
Zero or one. The operating system running on the system.
OperatingSystem Zeroか1。 システムで動くオペレーティングシステム。
Counter
Zero or more. A counter with which to summarize properties of
this host or network.
Zeroか以上を打ち返してください。 このホストかネットワークの特性をまとめるカウンタ。
Description
Zero or more. ML_STRING. A free-form text description of the
System.
記述Zeroか以上。 ミリリットル_ストリング。 Systemの自由形式テキスト記述。
AdditionalData
Zero or many. A mechanism by which to extend the data model.
AdditionalData Zeroか多く。 データモデルを広げるメカニズム。
The System class has five attributes:
Systemのクラスには、5つの属性があります:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されます。
category
Required. ENUM. Classifies the role the host or network played
in the incident. The possible values are:
カテゴリRequired。 ENUM。 ホストかネットワークがインシデントで果たした役割を分類します。 可能な値は以下の通りです。
1. source. The System was the source of the event.
1. ソース。 Systemはイベントの源でした。
2. target. The System was the target of the event.
2. 目標。 Systemはイベントの目標でした。
Danyliw, et al. Standards Track [Page 41] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[41ページ]。
3. intermediate. The System was an intermediary in the event.
3. 中間的です。 Systemはイベントで仲介者でした。
4. sensor. The System was a sensor monitoring the event.
4. センサ。 Systemはイベントをモニターするセンサでした。
5. infrastructure. The System was an infrastructure node of
IODEF document exchange.
5. インフラストラクチャ。 SystemはIODEFドキュメント交換のインフラストラクチャノードでした。
6. ext-value. An escape value used to extend this attribute.
See Section 5.1.
6. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-category
Optional. STRING. A means by which to extend the category
attribute. See Section 5.1.
ext-カテゴリOptional。 結びます。 カテゴリ属性を広げる手段。 セクション5.1を見てください。
interface
Optional. STRING. Specifies the interface on which the event(s)
on this System originated. If the Node class specifies a network
rather than a host, this attribute has no meaning.
Optionalを連結してください。 結びます。 このSystemの上のイベントが起因したインタフェースを指定します。 Nodeのクラスがホストよりむしろネットワークを指定するなら、この属性に、意味がありません。
spoofed
Optional. ENUM. An indication of confidence in whether this
System was the true target or attacking host. The permitted
values for this attribute are shown below. The default value is
"unknown".
Optionalであると偽造されます。 ENUM。 このSystemが本当の目標かそれともホストを攻撃したことであるかにおける信用のしるし。 この属性のための受入れられた値は以下に示されます。 デフォルト値は「未知です」。
1. unknown. The accuracy of the category attribute value is
unknown.
1. 未知です。 カテゴリ属性値の精度は未知です。
2. yes. The category attribute value is probably incorrect. In
the case of a source, the System is likely a decoy; with a
target, the System was likely not the intended victim.
2. はい。 カテゴリ属性値はたぶん不正確です。 ソースの場合では、Systemはありそうなaおとりです。 目標で、Systemはありそうでした。意図している犠牲者でない。
3. no. The category attribute value is believed to be correct.
3. No. カテゴリ属性値が正しいと信じられています。
3.16. Node Class
3.16. ノードのクラス
The Node class names a system (e.g., PC, router) or network.
Nodeクラス名aシステム(例えば、PC、ルータ)かネットワーク。
This class was derived from the IDMEF [17].
IDMEF[17]からこのクラスを得ました。
Danyliw, et al. Standards Track [Page 42] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[42ページ]。
+---------------+
| Node |
+---------------+
| |<>--{0..*}--[ NodeName ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ Location ]
| |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ NodeRole ]
| |<>--{0..*}--[ Counter ]
+---------------+
+---------------+ | ノード| +---------------+ | | <>--0..*--[NodeName]| | <>--0..*--[アドレス]| | <>--0..1--[位置]| | <>--0..1--[DateTime]| | <>--0..*--[NodeRole]| | <>--0..*--[打ち返します]+---------------+
Figure 27: The Node Class
図27: ノードのクラス
The aggregate classes that constitute Node are:
Nodeを構成する集約クラスは以下の通りです。
NodeName
Zero or more. ML_STRING. The name of the Node (e.g., fully
qualified domain name). This information MUST be provided if no
Address information is given.
NodeName Zeroか以上。 ミリリットル_ストリング。 Node(例えば、完全修飾ドメイン名)という名前。 Address情報を全く与えないなら、この情報を提供しなければなりません。
Address
Zero or more. The hardware, network, or application address of
the Node. If a NodeName is not provided, at least one Address
MUST be specified.
Zeroか以上を扱ってください。 Nodeのハードウェア、ネットワーク、またはアプリケーションアドレス。 NodeNameが提供されないなら、少なくとも1Addressを指定しなければなりません。
Location
Zero or one. ML_STRING. A free-from description of the physical
location of the equipment.
位置のZeroか1。 ミリリットル_ストリング。 Aは設備の物理的な位置の記述を解放します。
DateTime
Zero or one. A timestamp of when the resolution between the name
and address was performed. This information SHOULD be provided if
both an Address and NodeName are specified.
DateTime Zeroか1。 名前とアドレスの間の解決が実行された時に関するタイムスタンプ。 この情報SHOULDは両方であるならAddressとNodeNameがそうであるならそうです。指定にされる。
NodeRole
Zero or more. The intended purpose of the Node.
NodeRole Zeroか以上。 Nodeの本来の目的。
Counter
Zero or more. A counter with which to summarizes properties of
this host or network.
Zeroか以上を打ち返してください。 Aがどれに対抗するか、このホストかネットワークの特性をまとめます。
3.16.1. Counter Class
3.16.1. カウンタのクラス
The Counter class summarize multiple occurrences of some event, or conveys counts or rates on various features (e.g., packets, sessions, events).
Counterのクラスは、様々な特徴(例えば、パケット、セッション、イベント)で何らかのイベントの複数の発生をまとめるか、またはカウントかレートを伝えます。
Danyliw, et al. Standards Track [Page 43] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[43ページ]。
The value of the counter is the element content with its units represented in the type attribute. A rate for a given feature can be expressed by setting the duration attribute. The complete semantics are entirely context dependent based on the class in which the Counter is aggregated.
カウンタの値はユニットがタイプ属性で表されている要素含有量です。 持続時間属性を設定することによって、与えられた特徴のレートを表すことができます。 完全な意味論は文脈にCounterが集められるクラスに基づいた状態で完全に依存しています。
+---------------------+ | Counter | +---------------------+ | REAL | | | | ENUM type | | STRING ext-type | | STRING meaning | | ENUM duration | | STRING ext-duration | +---------------------+
+---------------------+ | カウンタ| +---------------------+ | 本当| | | | ENUMはタイプします。| | STRING ext-タイプ| | STRING意味| | ENUM持続時間| | STRING ext-持続時間| +---------------------+
Figure 28: The Counter Class
図28: カウンタのクラス
The Counter class has three attribute:
Counterのクラスには、3属性があります:
type
Required. ENUM. Specifies the units of the element content.
Requiredをタイプしてください。 ENUM。 要素含有量の単位を指定します。
1. byte. Count of bytes.
1. バイト。 バイトのカウント。
2. packet. Count of packets.
2. パケット。 パケットのカウント。
3. flow. Count of flow (e.g., NetFlow records).
3. 流れてください。 流れ(例えば、NetFlow記録)のカウント。
4. session. Count of sessions.
4. セッション。 セッションのカウント。
5. alert. Count of notifications generated by another system
(e.g., IDS or SIM).
5. 注意深いです。 通知のカウントは、別のものでシステムが(例えば、IDSかSIM)であると生成しました。
6. message. Count of messages (e.g., mail messages).
6. メッセージ。 メッセージ(例えば、メール・メッセージ)のカウント。
7. event. Count of events.
7. イベント。 イベントのカウント。
8. host. Count of hosts.
8. ホスト。 ホストのカウント。
9. site. Count of site.
9. サイト。 サイトのカウント。
10. organization. Count of organizations.
10. 組織。 組織のカウント。
Danyliw, et al. Standards Track [Page 44] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[44ページ]。
11. ext-value. An escape value used to extend this attribute.
See Section 5.1.
11. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-type
Optional. STRING. A means by which to extend the type attribute.
See Section 5.1.
Optionalをextタイプしてください。 結びます。 タイプ属性を広げる手段。 セクション5.1を見てください。
duration
Optional. ENUM. If present, the Counter class represents a rate
rather than a count over the entire event. In that case, this
attribute specifies the denominator of the rate (where the type
attribute specified the nominator). The possible values of this
attribute are defined in Section 3.10.2
持続時間Optional。 ENUM。 存在しているなら、Counterのクラスは全体のイベントの上のカウントよりむしろレートを表します。 その場合、この属性はレート(タイプ属性が指名者を指定したところ)の分母を指定します。 この属性の可能な値はセクション3.10.2で定義されます。
ext-duration
Optional. STRING. A means by which to extend the duration
attribute. See Section 5.1.
ext-持続時間Optional。 結びます。 持続時間属性を広げる手段。 セクション5.1を見てください。
3.16.2. Address Class
3.16.2. アドレスのクラス
The Address class represents a hardware (layer-2), network (layer-3), or application (layer-7) address.
Addressのクラスはハードウェア(層-2)、ネットワーク(層-3)、またはアプリケーション(層-7)アドレスを表します。
This class was derived from the IDMEF [17].
IDMEF[17]からこのクラスを得ました。
+---------------------+ | Address | +---------------------+ | ENUM category | | STRING ext-category | | STRING vlan-name | | INTEGER vlan-num | +---------------------+
+---------------------+ | アドレス| +---------------------+ | ENUMカテゴリ| | STRING ext-カテゴリ| | STRING vlan-名前| | INTEGER vlan-num| +---------------------+
Figure 29: The Address Class
図29: アドレスのクラス
The Address class has four attributes:
Addressのクラスには、4つの属性があります:
category
Required. ENUM. The type of address represented. The permitted
values for this attribute are shown below. The default value is
"ipv4-addr".
カテゴリRequired。 ENUM。 表されたアドレスのタイプ。 この属性のための受入れられた値は以下に示されます。 デフォルト値は"ipv4-addr"です。
1. asn. Autonomous System Number
1. asn。 自律システム番号
2. atm. Asynchronous Transfer Mode (ATM) address
2. 気圧。 非同期なTransfer Mode(ATM)アドレス
Danyliw, et al. Standards Track [Page 45] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[45ページ]。
3. e-mail. Electronic mail address (RFC 822)
3. メールしてください。 電子メールアドレス(RFC822)
4. ipv4-addr. IPv4 host address in dotted-decimal notation
(a.b.c.d)
4. ipv4-addr。 ドット付き10進法によるIPv4ホスト・アドレス(a.b.c.d)
5. ipv4-net. IPv4 network address in dotted-decimal notation,
slash, significant bits (a.b.c.d/nn)
5. ipv4ネットです。 ドット付き10進法によるIPv4ネットワーク・アドレス、スラッシュ、重要なビット(a.b.c.d/nn)
6. ipv4-net-mask. IPv4 network address in dotted-decimal
notation, slash, network mask in dotted-decimal notation
(a.b.c.d/w.x.y.z)
6. ipv4-ネットマスク。 ドット付き10進法によるIPv4ネットワーク・アドレス、スラッシュ、ドット付き10進法によるネットワークマスク(a.b.c.d/w.x.y.z)
7. ipv6-addr. IPv6 host address
7. ipv6-addr。 IPv6ホスト・アドレス
8. ipv6-net. IPv6 network address, slash, significant bits
8. ipv6ネットです。 IPv6ネットワーク・アドレス、スラッシュ、重要なビット
9. ipv6-net-mask. IPv6 network address, slash, network mask
9. ipv6-ネットマスク。 IPv6ネットワーク・アドレス、スラッシュ、ネットワークマスク
10. mac. Media Access Control (MAC) address
10. mac。 メディアAccess Control(MAC)アドレス
11. ext-value. An escape value used to extend this attribute.
See Section 5.1.
11. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-category
Optional. STRING. A means by which to extend the category
attribute. See Section 5.1.
ext-カテゴリOptional。 結びます。 カテゴリ属性を広げる手段。 セクション5.1を見てください。
vlan-name
Optional. STRING. The name of the Virtual LAN to which the
address belongs.
vlan-名前Optional。 結びます。 アドレスが属するバーチャルLANの名前。
vlan-num
Optional. STRING. The number of the Virtual LAN to which the
address belongs.
vlan-num Optional。 結びます。 アドレスが属するバーチャルLANの数。
3.16.3. NodeRole Class
3.16.3. NodeRoleのクラス
The NodeRole class describes the intended function performed by a particular host.
NodeRoleのクラスは特定のホストによって実行された意図している機能について説明します。
Danyliw, et al. Standards Track [Page 46] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[46ページ]。
+---------------------+
| NodeRole |
+---------------------+
| ENUM category |
| STRING ext-category |
| ENUM lang |
+---------------------+
+---------------------+ | NodeRole| +---------------------+ | ENUMカテゴリ| | STRING ext-カテゴリ| | ENUM lang| +---------------------+
Figure 30: The NodeRole Class
図30: NodeRoleのクラス
The NodeRole class has three attributes:
NodeRoleのクラスには、3つの属性があります:
category
Required. ENUM. Functionality provided by a node.
カテゴリRequired。 ENUM。 ノードによって提供された機能性。
1. client. Client computer
1. クライアント。 クライアントコンピュータ
2. server-internal. Server with internal services
2. サーバ内部です。 内部のサービスがあるサーバ
3. server-public. Server with public services
3. サーバ公共です。 社会奉仕とのサーバ
4. www. WWW server
4. www. WWWサーバ
5. mail. Mail server
5. メール。 サーバを郵送してください。
6. messaging. Messaging server (e.g., NNTP, IRC, IM)
6. メッセージング。 メッセージングサーバ(例えば、NNTP、IRC、不-、)
7. streaming. Streaming-media server
7. ストリーミングです。 ストリーミング・メディアサーバ
8. voice. Voice server (e.g., SIP, H.323)
8. 声。 音声サーバー(例えば、一口、H.323)
9. file. File server (e.g., SMB, CVS, AFS)
9. ファイルしてください。 ファイルサーバー(例えば、SMB、cvs、AFS)
10. ftp. FTP server
10. ftp。 FTPサーバ
11. p2p. Peer-to-peer node
11. p2p。 ピアツーピアノード
12. name. Name server (e.g., DNS, WINS)
12. 名前。 ネームサーバ(例えば、DNS、勝利)
13. directory. Directory server (e.g., LDAP, finger, whois)
13. ディレクトリ。 ディレクトリサーバ(例えば、LDAP、指、whois)
14. credential. Credential server (e.g., domain controller,
Kerberos)
14. 資格証明です。 資格証明サーバ(例えば、ドメインコントローラ、ケルベロス)
15. print. Print server
15. 印刷してください。 プリント・サーバ
16. application. Application server
16. アプリケーション。 アプリケーション・サーバー
Danyliw, et al. Standards Track [Page 47] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[47ページ]。
17. database. Database server
17. データベース。 データベースサーバー
18. infra. Infrastructure server (e.g., router, firewall, DHCP)
18. 下に。 インフラストラクチャサーバ(例えば、ルータ、ファイアウォール、DHCP)
19. log. Logserver (e.g., syslog)
19. ログ。 Logserver(例えば、syslog)
20. ext-value. An escape value used to extend this attribute.
See Section 5.1.
20. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-category
Optional. STRING. A means by which to extend the category
attribute. See Section 5.1.
ext-カテゴリOptional。 結びます。 カテゴリ属性を広げる手段。 セクション5.1を見てください。
lang
Required. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6.
lang Required。 ENUM。 「xs: 言語」の定義で抑制されたRFC4646[7]あたり1つの有効な言語コード。 このコードの解釈はセクション6で説明されます。
3.17. Service Class
3.17. サービスのクラス
The Service class describes a network service of a host or network. The service is identified by specific port or list of ports, along with the application listening on that port.
Serviceのクラスはホストかネットワークのネットワーク・サービスについて説明します。 サービスはそのポートの上で聴かれるアプリケーションに伴うポートの特定のポートかリストによって特定されます。
When Service occurs as an aggregate class of a System that is a source, then this service is the one from which activity of interest is originating. Conversely, when Service occurs as an aggregate class of a System that is a target, then that service is the one to which activity of interest is directed.
ServiceがソースであるSystemの集約クラスとして起こると、このサービスは興味がある活動が起因しているものです。 そして、逆に、Serviceが目標であるSystemの集約クラスとして起こるとき、そのサービスは興味がある活動が向けられるものです。
This class was derived from the IDMEF [17].
IDMEF[17]からこのクラスを得ました。
+---------------------+
| Service |
+---------------------+
| INTEGER ip_protocol |<>--{0..1}--[ Port ]
| |<>--{0..1}--[ Portlist ]
| |<>--{0..1}--[ ProtoCode ]
| |<>--{0..1}--[ ProtoType ]
| |<>--{0..1}--[ ProtoFlags ]
| |<>--{0..1}--[ Application ]
+---------------------+
+---------------------+ | サービス| +---------------------+ | INTEGER ip_プロトコル| <>--0..1--[ポート]| | <>--0..1--[Portlist]| | <>--0..1--[ProtoCode]| | <>--0..1--[プロトタイプ]| | <>--0..1--[ProtoFlags]| | <>--0..1--[アプリケーション]+---------------------+
Figure 31: The Service Class
図31: サービスのクラス
The aggregate classes that constitute Service are:
Serviceを構成する集約クラスは以下の通りです。
Danyliw, et al. Standards Track [Page 48] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[48ページ]。
Port
Zero or one. INTEGER. A port number.
Zeroか1つを移植してください。 整数。 ポートナンバー。
Portlist
Zero or one. PORTLIST. A list of port numbers formatted
according to Section 2.10.
Portlist Zeroか1。 PORTLISTセクション2.10によると、フォーマットされたポートナンバーのリスト。
ProtoCode
Zero or one. INTEGER. A layer-4 protocol-specific code field
(e.g., ICMP code field).
ProtoCode Zeroか1。 整数。 層-4のプロトコル特有のコード分野(例えば、ICMPコード分野)。
ProtoType
Zero or one. INTEGER. A layer-4 protocol specific type field
(e.g., ICMP type field).
ProtoType Zeroか1。 整数。 層-4プロトコル特定のタイプ分野(例えば、ICMPは分野をタイプします)。
ProtoFlags
Zero or one. INTEGER. A layer-4 protocol specific flag field
(e.g., TCP flag field).
ProtoFlags Zeroか1。 整数。 層-4は特定の旗の分野(例えば、TCP旗の分野)について議定書の中で述べます。
Application
Zero or more. The application bound to the specified Port or
Portlist.
アプリケーションZeroか以上。 アプリケーションは指定されたPortかPortlistに付きました。
Either a Port or Portlist class MUST be specified for a given instance of a Service class.
Serviceのクラスの与えられたインスタンスにPortかPortlistのクラスのどちらかを指定しなければなりません。
For a given source, System@type="source", a corresponding target, System@type="target", maybe defined, or vice versa. When a Portlist class is defined in the Service class of both the source and target in a given instance of the Flow class, there MUST be symmetry in the enumeration of the ports. Thus, if n-ports are listed for a source, n-ports should be listed for the target. Likewise, the ports should be listed in an identical sequence such that the n-th port in the source corresponds to the n-th port of the target. This symmetry in listing and sequencing of ports applies whether there are 1-to-1, 1-to-many, or many-to-many sources-to-targets. In the 1-to-many or many-to-many, the exact order in which the System classes are enumerated in the Flow class is significant.
与えられたソースと、 System@type =「目標」という対応する目標は、多分 System@type =「ソース」と定義したか、逆もまた同様です。 PortlistのクラスがFlowのクラスの与えられたインスタンスにおける、ソースと目標の両方のServiceのクラスで定義されるとき、ポートの列挙における対称があるに違いありません。 したがって、n-ポートがソースに記載されるなら、n-ポートは目標のために記載されるべきです。 同様に、ポートが同じ系列で記載されているべきであるので、ソースにおけるn番目のポートは目標のn番目のポートに対応しています。 1〜1、多くへの1、または目標への多くへの多くソースがあるか否かに関係なく、ポートのリストと配列におけるこの対称は適用されます。 多くへの1か多くへの多くでは、SystemのクラスがFlowのクラスで数え上げられる正確なオーダーは重要です。
The Service class has one attribute:
Serviceのクラスには、1つの属性があります:
ip_protocol
Required. INTEGER. The IANA protocol number.
ip_プロトコルRequired。 整数。 IANAは数について議定書の中で述べます。
Danyliw, et al. Standards Track [Page 49] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[49ページ]。
3.17.1. Application Class
3.17.1. アプリケーションのクラス
The Application class describes an application running on a System providing a Service.
ApplicationのクラスはServiceを提供しながらSystemの上で作業するアプリケーションについて説明します。
+--------------------+
| Application |
+--------------------+
| STRING swid |<>--{0..1}--[ URL ]
| STRING configid |
| STRING vendor |
| STRING family |
| STRING name |
| STRING version |
| STRING patch |
+--------------------+
+--------------------+ | アプリケーション| +--------------------+ | STRING swid| <>--0..1--[URL]| STRING configid| | STRINGベンダー| | STRINGファミリー| | STRING名| | STRINGバージョン| | STRINGパッチ| +--------------------+
Figure 32: The Application Class
図32: アプリケーションのクラス
The aggregate class that constitutes Application is:
Applicationを構成する集約クラスは以下の通りです。
URL
Zero or one. URL. A URL describing the application.
URL Zeroか1。 URL。 アプリケーションについて説明するURL。
The Application class has seven attributes:
Applicationのクラスには、7つの属性があります:
swid
Optional. STRING. An identifier that can be used to reference
this software.
swid Optional。 結びます。 このソフトウェアに参照をつけるのに使用できる識別子。
configid
Optional. STRING. An identifier that can be used to reference a
particular configuration of this software.
configid Optional。 結びます。 このソフトウェアの特定の構成に参照をつけるのに使用できる識別子。
vendor
Optional. STRING. Vendor name of the software.
ベンダーOptional。 結びます。 ソフトウェアのベンダー名。
family
Optional. STRING. Family of the software.
ファミリーOptional。 結びます。 ソフトウェアのファミリー。
name
Optional. STRING. Name of the software.
Optionalを命名してください。 結びます。 ソフトウェアの名前。
version
Optional. STRING. Version of the software.
バージョンOptional。 結びます。 ソフトウェアのバージョン。
Danyliw, et al. Standards Track [Page 50] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[50ページ]。
patch
Optional. STRING. Patch or service pack level of the software.
Optionalにパッチしてください。 結びます。 ソフトウェアのパックレベルをパッチするか、または修理してください。
3.18. OperatingSystem Class
3.18. OperatingSystemのクラス
The OperatingSystem class describes the operating system running on a System. The definition is identical to the Application class (Section 3.17.1).
OperatingSystemのクラスはSystemの上で作業するオペレーティングシステムを説明します。 定義はApplicationのクラス(セクション3.17.1)と同じです。
3.19. Record Class
3.19. レコード・クラス
The Record class is a container class for log and audit data that provides supportive information about the incident. The source of this data will often be the output of monitoring tools. These logs should substantiate the activity described in the document.
Recordのクラスはインシデントの支持している情報を提供するログと監査データのためのコンテナのクラスです。 このデータの源はしばしばモニターしているツールの出力になるでしょう。 これらのログはドキュメントで説明された活動を実体化するべきです。
+------------------+
| Record |
+------------------+
| ENUM restriction |<>--{1..*}--[ RecordData ]
+------------------+
+------------------+ | 記録| +------------------+ | ENUM制限| <>--1..*--[RecordData]+------------------+
Figure 33: Record Class
図33: レコード・クラス
The aggregate class that constitutes Record is:
Recordを構成する集約クラスは以下の通りです。
RecordData
One or more. Log or audit data generated by a particular type of
sensor. Separate instances of the RecordData class SHOULD be used
for each sensor type.
RecordData Oneか以上。 特定のタイプのセンサによって生成されたデータを、登録するか、または監査してください。 RecordDataのクラスSHOULDのインスタンスを切り離してください。それぞれのセンサタイプのために、使用されます。
The Record class has one attribute:
Recordのクラスには、1つの属性があります:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されました。
3.19.1. RecordData Class
3.19.1. RecordDataのクラス
The RecordData class groups log or audit data from a given sensor (e.g., IDS, firewall log) and provides a way to annotate the output.
RecordDataのクラスは、与えられたセンサ(例えば、IDS、ファイアウォールログ)からログか監査データを分類して、出力を注釈する方法を提供します。
Danyliw, et al. Standards Track [Page 51] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[51ページ]。
+------------------+
| RecordData |
+------------------+
| ENUM restriction |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ Application ]
| |<>--{0..*}--[ RecordPattern ]
| |<>--{1..*}--[ RecordItem ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
+------------------+ | RecordData| +------------------+ | ENUM制限| <>--0..1--[DateTime]| | <>--0..*--[記述]| | <>--0..1--[アプリケーション]| | <>--0..*--[RecordPattern]| | <>--1..*--[RecordItem]| | <>--0..*--[AdditionalData]+------------------+
Figure 34: The RecordData Class
図34: RecordDataのクラス
The aggregate classes that constitutes RecordData is:
RecordDataを構成する集約クラスは以下の通りです。
DateTime
Zero or one. Timestamp of the RecordItem data.
DateTime Zeroか1。 RecordItemデータに関するタイムスタンプ。
Description
Zero or more. ML_STRING. Free-form textual description of the
provided RecordItem data. At minimum, this description should
convey the significance of the provided RecordItem data.
記述Zeroか以上。 ミリリットル_ストリング。 提供されたRecordItemデータの自由形式の原文の記述。 最小限では、この記述は提供されたRecordItemデータの意味を伝えるべきです。
Application
Zero or one. Information about the sensor used to generate the
RecordItem data.
アプリケーションZeroか1。 センサに関する情報は、以前はよくRecordItemがデータであると生成していました。
RecordPattern
Zero or more. A search string to precisely find the relevant data
in a RecordItem.
RecordPattern Zeroか以上。 RecordItemで正確に関連データを見つける検索ストリング。
RecordItem
One or more. Log, audit, or forensic data.
RecordItem Oneか以上。 ログ、監査、または法廷のデータ。
AdditionalData
Zero or one. An extension mechanism for data not explicitly
represented in the data model.
AdditionalData Zeroか1。 データモデルで明らかに表されなかったデータのための拡張機能。
The RecordData class has one attribute:
RecordDataのクラスには、1つの属性があります:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
制限Optional。 ENUM。 この属性はセクション3.2で定義されました。
Danyliw, et al. Standards Track [Page 52] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[52ページ]。
3.19.2. RecordPattern Class
3.19.2. RecordPatternのクラス
The RecordPattern class describes where in the content of the RecordItem relevant information can be found. It provides a way to reference subsets of information, identified by a pattern, in a large log file, audit trail, or forensic data.
RecordPatternのクラスは、RecordItemの内容では、どこで関連情報を見つけることができるかを説明します。 それは情報の参照部分集合へのパターンによって特定された道を大きいログファイル、監査証跡、または法廷のデータに提供します。
+-----------------------+ | RecordPattern | +-----------------------+ | STRING | | | | ENUM type | | STRING ext-type | | INTEGER offset | | ENUM offsetunit | | STRING ext-offsetunit | | INTEGER instance | +-----------------------+
+-----------------------+ | RecordPattern| +-----------------------+ | ストリング| | | | ENUMはタイプします。| | STRING ext-タイプ| | INTEGERは相殺します。| | ENUM offsetunit| | STRING ext-offsetunit| | INTEGERインスタンス| +-----------------------+
Figure 35: The RecordPattern Class
図35: RecordPatternのクラス
The specific pattern to search with in the RecordItem is defined in the body of the element. It is further annotated by four attributes:
RecordItemで探す特定のパターンは要素のボディーで定義されます。 それは4つの属性によってさらに注釈されます:
type
Required. ENUM. Describes the type of pattern being specified in
the element content. The default is "regex".
Requiredをタイプしてください。 ENUM。 要素含有量で指定されるパターンのタイプについて説明します。 デフォルトは"regex"です。
1. regex. regular expression, per Appendix F of [3].
1. regex[3]のAppendix Fあたりの正規表現。
2. binary. Binhex encoded binary pattern, per the HEXBIN data
type.
2. 2進です。 BinhexはHEXBINデータ型あたりのバイナリパターンをコード化しました。
3. xpath. XML Path (XPath) [5]
3. xpath。 XML経路(XPath)[5]
4. ext-value. An escape value used to extend this attribute.
See Section 5.1.
4. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-type
Optional. STRING. A means by which to extend the type attribute.
See Section 5.1.
Optionalをextタイプしてください。 結びます。 タイプ属性を広げる手段。 セクション5.1を見てください。
offset
Optional. INTEGER. Amount of units (determined by the offsetunit
attribute) to seek into the RecordItem data before matching the
pattern.
Optionalを相殺してください。 整数。 パターンを合わせる前にRecordItemデータに求めるユニット(offsetunit属性で断固とした)の量。
Danyliw, et al. Standards Track [Page 53] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[53ページ]。
offsetunit
Optional. ENUM. Describes the units of the offset attribute.
The default is "line".
offsetunit Optional。 ENUM。 オフセット属性の単位を説明します。 デフォルトは「系列」です。
1. line. Offset is a count of lines.
1. 立ち並んでください。 相殺されているのは、系列のカウントです。
2. binary. Offset is a count of bytes.
2. 2進です。 相殺されているのは、バイトのカウントです。
3. ext-value. An escape value used to extend this attribute.
See Section 5.1.
3. ext-値。 エスケープ値は以前はよくこの属性を広げていました。 セクション5.1を見てください。
ext-offsetunit
Optional. STRING. A means by which to extend the offsetunit
attribute. See Section 5.1.
ext-offsetunit Optional。 結びます。 offsetunit属性を広げる手段。 セクション5.1を見てください。
instance
Optional. INTEGER. Number of types to apply the specified
pattern.
インスタンスOptional。 整数。 指定されたパターンを適用するタイプの数。
3.19.3. RecordItem Class
3.19.3. RecordItemのクラス
The RecordItem class provides a way to incorporate relevant logs, audit trails, or forensic data to support the conclusions made during the course of analyzing the incident. The class supports both the direct encapsulation of the data, as well as, provides primitives to reference data stored elsewhere.
RecordItemのクラスは、インシデントを分析するコースの間にされた結論をサポートするために関連ログ、監査証跡、または法廷のデータを取り入れる方法を提供します。 クラスは両方をサポートします。データのダイレクト良いカプセル化はほかの場所に保存された参考資料に基関数を提供します。
This class is identical to AdditionalData class (Section 3.6).
このクラスはAdditionalDataのクラス(セクション3.6)と同じです。
4. Processing Considerations
4. 処理問題
This section defines additional requirements on creating and parsing IODEF documents.
このセクションはIODEFドキュメントを作成して、分析することに関する追加要件を定義します。
4.1. Encoding
4.1. コード化
Every IODEF document MUST begin with an XML declaration, and MUST specify the XML version used. If UTF-8 encoding is not used, the character encoding MUST also be explicitly specified. The IODEF conforms to all XML data encoding conventions and constraints.
あらゆるIODEFドキュメントが、XML宣言で始まらなければならなくて、使用されるXMLバージョンを指定しなければなりません。 また、UTF-8コード化が使用されていないなら、明らかに文字符号化を指定しなければなりません。 IODEFはすべてのXML zデータの符号化コンベンションと規制に従います。
The XML declaration with no character encoding will read as follows:
文字符号化のないXML宣言は以下の通り読むでしょう:
<?xml version="1.0" ?>
<?「1インチ?>」というxmlバージョン=
When a character encoding is specified, the XML declaration will read like the following:
文字符号化が指定されるとき、XML宣言は以下のように読めるでしょう:
Danyliw, et al. Standards Track [Page 54] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[54ページ]。
<?xml version="1.0" encoding="charset" ?>
<?「="charset?" >をコード化する1インチ」というxmlバージョン=
Where "charset" is the name of the character encoding as registered with the Internet Assigned Numbers Authority (IANA), see [9].
"charset"が登録されるとしてのインターネットAssigned民数記Authority(IANA)がある文字符号化の名前であるところでは、[9]を見てください。
The following characters have special meaning in XML and MUST be escaped with their entity reference equivalent: "&", "<", ">", "\"" (double quotation mark), and "'" (apostrophe). These entity references are "&", "<", ">", """, and "'" respectively.
以下のキャラクタをXMLに特別な意味を持って、彼らの実体参照同等物で逃げなければなりません: 「"&"、"<"、">"「\」」(ダブル・クォーテーション・マーク)、および「'「(アポストロフィ)'。」 「」 "&"、"<"が">"であるというこれらの実体参照、"""、およびapos」 それぞれ。
4.2. IODEF Namespace
4.2. IODEF名前空間
The IODEF schema declares a namespace of "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. Each IODEF document SHOULD include a valid reference to the IODEF schema using the "xsi:schemaLocation" attribute. An example of such a declaration would look as follows:
そして、IODEF図式が名前空間を宣言する、「つぼ:ietf:params:xml:ナノ秒:、iodef-1インチ、[4]単位でそれを登録する、」 それぞれのIODEFドキュメントSHOULDは、「xsi: schemaLocation」属性を使用することでIODEF図式の有効な指示するものを含んでいます。 そのような宣言に関する例は以下の通りに見えるでしょう:
<IODEF-Document
version="1.00" lang="en-US"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xsi:schemaLocation="urn:ietf:params:xmls:schema:iodef-1.0">
「<IODEF-ドキュメントバージョン=「1インチのlang=」アン米国」xmlns: iodef=「つぼ:ietf:params:xml:ナノ秒: iodef-1インチのxsi: schemaLocation=」つぼ:ietf:params: xmls:図式:iodef-1インチの>。
4.3. Validation
4.3. 合法化
The IODEF documents MUST be well-formed XML and SHOULD be validated against the schema described in Section 8. However, mere conformance to the schema is not sufficient for a semantically valid IODEF document. There is additional specification in the text of Section 3 that cannot be readily encoded in the schema and it must also be considered by an IODEF parser. The following is a list of discrepancies in what is more strictly specified in the normative text (Section 3), but not enforced in the IODEF schema:
IODEFドキュメントは、整形式のXMLとSHOULDであるに違いありません。セクション8で説明されて、図式に対して有効にされてください。 しかしながら、図式への単なる順応は意味的に有効なIODEFドキュメントに十分ではありません。 図式で容易にコード化できないセクション3のテキストには追加仕様があります、そして、また、IODEFパーサでそれを考えなければなりません。 ↓これは標準のテキスト(セクション3)で、より厳密に指定されますが、IODEF図式では励行されないことにおける食い違いのリストです:
o The elements or attributes that are defined as POSTAL, NAME,
PHONE, and EMAIL data-types are implemented as "xs:string", but
more rigid formatting requirements are specified in the text.
o POSTAL、NAME、電話、およびメールデータ型と定義される要素か属性が「xs: ストリング」として実装されますが、より堅い形式要件はテキストで指定されます。
o The IODEF-Document@lang and MLStringType@lang attributes are
declared as an "xs:language" that constrains values with a regular
expression. However, the value of this attribute still needs to
be validated against the list of possible enumerated values is
defined in [7].
o IODEF-Document@lang とMLStringType@lang属性はそれが抑制する「xs: 言語」値として正規表現で申告されます。 しかしながら、この属性の値は、まだ可能の列挙された値が[7]で定義されるのをリストに対して有効にされる必要があります。
o The MonetaryImpact@currency attribute is declared as an "xs:
string", but the list of valid values as defined in [14].
o MonetaryImpact@currency 属性が宣言される、「xs:」 しかし、「ストリング」、[14]の定義されるとしての有効値のリスト。
Danyliw, et al. Standards Track [Page 55] RFC 5070 IODEF December 2007
Danyliw、他 規格はIODEF2007年12月にRFC5070を追跡します[55ページ]。
o All of the aggregated classes Contact and EventData are optional
in the schema, but at least one of these aggregated classes MUST
be present.
o 集められたクラスのContactとEventDataのすべてが図式で任意ですが、少なくともこれらの集められたクラスの1つは存在していなければなりません。
o There are multiple conventions that can be used to categorize a
system using the NodeRole class or to specify software with the
Application and OperatingSystem classes. IODEF parsers MUST
accept incident reports that do not use these fields in accordance
with local conventions.
o There are multiple conventions that can be used to categorize a system using the NodeRole class or to specify software with the Application and OperatingSystem classes. IODEF parsers MUST accept incident reports that do not use these fields in accordance with local conventions.
o The Confidence@rating attribute determines whether the element
content of Confidence should be empty.
o The Confidence@rating attribute determines whether the element content of Confidence should be empty.
o The Address@type attribute determines the format of the element
content.
o The Address@type attribute determines the format of the element content.
o The attributes AdditionalData@dtype and RecordItem@dtype derived
from iodef:ExtensionType determine the semantics and formatting of
the element content.
o The attributes AdditionalData@dtype and RecordItem@dtype derived from iodef:ExtensionType determine the semantics and formatting of the element content.
o Symmetry in the enumerated ports of a Portlist class is required
between sources and targets. See Section 3.17.
o Symmetry in the enumerated ports of a Portlist class is required between sources and targets. See Section 3.17.
5. Extending the IODEF
5. Extending the IODEF
In order to support the changing activity of CSIRTS, the IODEF data model will need to evolve along with them. This section discusses how new data elements that have no current representation in the data model can be incorporated into the IODEF. These techniques are designed so that adding new data will not require a change to the IODEF schema. With proven value, well documented extensions can be incorporated into future versions of the specification. However, this approach also supports private extensions relevant only to a closed consortium.
In order to support the changing activity of CSIRTS, the IODEF data model will need to evolve along with them. This section discusses how new data elements that have no current representation in the data model can be incorporated into the IODEF. These techniques are designed so that adding new data will not require a change to the IODEF schema. With proven value, well documented extensions can be incorporated into future versions of the specification. However, this approach also supports private extensions relevant only to a closed consortium.
5.1. Extending the Enumerated Values of Attributes
5.1. Extending the Enumerated Values of Attributes
The data model supports a means by which to add new enumerated values to an attribute. For each attribute that supports this extension technique, there is a corresponding attribute in the same element whose name is identical, less a prefix of "ext-". This special attribute is referred to as the extension attribute, and the attribute being extended is referred to as an extensible attribute. For example, an extensible attribute named "foo" will have a corresponding extension attribute named "ext-foo". An element may have many extensible, and therefore many extension, attributes.
The data model supports a means by which to add new enumerated values to an attribute. For each attribute that supports this extension technique, there is a corresponding attribute in the same element whose name is identical, less a prefix of "ext-". This special attribute is referred to as the extension attribute, and the attribute being extended is referred to as an extensible attribute. For example, an extensible attribute named "foo" will have a corresponding extension attribute named "ext-foo". An element may have many extensible, and therefore many extension, attributes.
Danyliw, et al. Standards Track [Page 56] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 56] RFC 5070 IODEF December 2007
In addition to a corresponding extension attribute, each extensible attribute has "ext-value" as one its possible values. This particular value serves as an escape sequence and has no valid meaning.
In addition to a corresponding extension attribute, each extensible attribute has "ext-value" as one its possible values. This particular value serves as an escape sequence and has no valid meaning.
In order to add a new enumerated value to an extensible attribute, the value of this attribute MUST be set to "ext-value", and the new desired value MUST be set in the corresponding extension attribute. For example, an extended instance of the type attribute of the Impact class would look as follows:
In order to add a new enumerated value to an extensible attribute, the value of this attribute MUST be set to "ext-value", and the new desired value MUST be set in the corresponding extension attribute. For example, an extended instance of the type attribute of the Impact class would look as follows:
<Impact type="ext-value" ext-type="new-attack-type">
<Impact type="ext-value" ext-type="new-attack-type">
A given extension attribute MUST NOT be set unless the corresponding extensible attribute has been set to "ext-value".
A given extension attribute MUST NOT be set unless the corresponding extensible attribute has been set to "ext-value".
5.2. Extending Classes
5.2. Extending Classes
The classes of the data model can be extended only through the use of the AdditionalData and RecordItem classes. These container classes, collectively referred to as the extensible classes, are implemented with the iodef:ExtensionType data type in the schema. They provide the ability to have new atomic or XML-encoded data elements in all of the top-level classes of the Incident class and a few of the more complicated subordinate classes. As there are multiple instances of the extensible classes in the data model, there is discretion on where to add a new data element. It is RECOMMENDED that the extension be placed in the most closely related class to the new information.
The classes of the data model can be extended only through the use of the AdditionalData and RecordItem classes. These container classes, collectively referred to as the extensible classes, are implemented with the iodef:ExtensionType data type in the schema. They provide the ability to have new atomic or XML-encoded data elements in all of the top-level classes of the Incident class and a few of the more complicated subordinate classes. As there are multiple instances of the extensible classes in the data model, there is discretion on where to add a new data element. It is RECOMMENDED that the extension be placed in the most closely related class to the new information.
Extensions using the atomic data types (i.e., all values of the dtype attributes other than "xml") MUST:
Extensions using the atomic data types (i.e., all values of the dtype attributes other than "xml") MUST:
1. Set the element content of extensible class to the desired value,
and
1. Set the element content of extensible class to the desired value, and
2. Set the dtype attribute to correspond to the data type of the
element content.
2. Set the dtype attribute to correspond to the data type of the element content.
The following guidelines exist for extensions using XML:
The following guidelines exist for extensions using XML:
1. The element content of the extensible class MUST be set to the
desired value and the dtype attribute MUST be set to "xml".
1. The element content of the extensible class MUST be set to the desired value and the dtype attribute MUST be set to "xml".
2. The extension schema MUST declare a separate namespace. It is
RECOMMENDED that these extensions have the prefix "iodef-".
2. The extension schema MUST declare a separate namespace. It is RECOMMENDED that these extensions have the prefix "iodef-".
Danyliw, et al. Standards Track [Page 57] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 57] RFC 5070 IODEF December 2007
3. It is RECOMMENDED that extension schemas follow the naming
convention of the IODEF data model. The names of all elements
are capitalized. For composed names, a capital letter is used
for each word. Attribute names are lower case.
3. It is RECOMMENDED that extension schemas follow the naming convention of the IODEF data model. The names of all elements are capitalized. For composed names, a capital letter is used for each word. Attribute names are lower case.
4. When a parser encounters an IODEF document with an extension it
does not understand, this extension MUST be ignored (and not
processed), but the remainder of the document MUST be processed.
Parsers will be able to identify these extensions for which they
have no processing logic through the namespace declaration.
Parsers that encounter an unrecognized element in a namespace
that they do support SHOULD reject the document as a syntax
error.
4. When a parser encounters an IODEF document with an extension it does not understand, this extension MUST be ignored (and not processed), but the remainder of the document MUST be processed. Parsers will be able to identify these extensions for which they have no processing logic through the namespace declaration. Parsers that encounter an unrecognized element in a namespace that they do support SHOULD reject the document as a syntax error.
5. Implementations SHOULD NOT download schemas at runtime due to the
security implications, and extensions MUST NOT be required to
provide a resolvable location of their schema.
5. Implementations SHOULD NOT download schemas at runtime due to the security implications, and extensions MUST NOT be required to provide a resolvable location of their schema.
The following schema and XML document excerpt provide a template for an extension schema and its use in the IODEF document.
The following schema and XML document excerpt provide a template for an extension schema and its use in the IODEF document.
This example schema defines a namespace of "iodef-extension1" and a single element named "newdata".
This example schema defines a namespace of "iodef-extension1" and a single element named "newdata".
<xs:schema
targetNamespace="iodef-extension1.xsd"
xmlns:iodef-extension1="iodef-extension1.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
attributeFormDefault="unqualified"
elementFormDefault="qualified">
<xs:import
namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation=" urn:ietf:params:xml:schema:iodef-1.0"/>
<xs:schema targetNamespace="iodef-extension1.xsd" xmlns:iodef-extension1="iodef-extension1.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"> attributeFormDefault="unqualified" elementFormDefault="qualified"> <xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation=" urn:ietf:params:xml:schema:iodef-1.0"/>
<xs:element name="newdata" type="xs:string" />
</xs:schema>
<xs:element name="newdata" type="xs:string" /> </xs:schema>
The following XML excerpt demonstrates the use of the above schema as an extension to the IODEF.
The following XML excerpt demonstrates the use of the above schema as an extension to the IODEF.
Danyliw, et al. Standards Track [Page 58] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 58] RFC 5070 IODEF December 2007
<IODEF-Document
version="1.00" lang="en-US"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef=" urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef-extension1="iodef-extension1.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="iodef-extension1.xsd">
<Incident purpose="reporting">
...
<AdditionalData dtype="xml" meaning="xml">
<iodef-extension1:newdata>
Field that could not be represented elsewhere
</iodef-extension1:newdata>
</AdditionalData>
</Incident>
</IODEF-Document>
<IODEF-Document version="1.00" lang="en-US" xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef=" urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef-extension1="iodef-extension1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="iodef-extension1.xsd"> <Incident purpose="reporting"> ... <AdditionalData dtype="xml" meaning="xml"> <iodef-extension1:newdata> Field that could not be represented elsewhere </iodef-extension1:newdata> </AdditionalData> </Incident> </IODEF-Document>
6. Internationalization Issues
6. Internationalization Issues
Internationalization and localization is of specific concern to the IODEF, since it is only through collaboration, often across language barriers, that certain incidents be resolved. The IODEF supports this goal by depending on XML constructs, and through explicit design choices in the data model.
Internationalization and localization is of specific concern to the IODEF, since it is only through collaboration, often across language barriers, that certain incidents be resolved. The IODEF supports this goal by depending on XML constructs, and through explicit design choices in the data model.
Since IODEF is implemented as an XML Schema, it implicitly supports all the different character encodings, such as UTF-8 and UTF-16, possible with XML. Additionally, each IODEF document MUST specify the language in which their contents are encoded. The language can be specified with the attribute "xml:lang" (per Section 2.12 of [1]) in the top-level element (i.e., IODEF-Document@lang) and letting all other elements inherit that definition. All IODEF classes with a free-form text definition (i.e., all those defined of type iodef: MLStringType) can also specify a language different from the rest of the document. The valid language codes for the "xml:lang" attribute are described in RFC 4646 [7].
Since IODEF is implemented as an XML Schema, it implicitly supports all the different character encodings, such as UTF-8 and UTF-16, possible with XML. Additionally, each IODEF document MUST specify the language in which their contents are encoded. The language can be specified with the attribute "xml:lang" (per Section 2.12 of [1]) in the top-level element (i.e., IODEF-Document@lang) and letting all other elements inherit that definition. All IODEF classes with a free-form text definition (i.e., all those defined of type iodef: MLStringType) can also specify a language different from the rest of the document. The valid language codes for the "xml:lang" attribute are described in RFC 4646 [7].
The data model supports multiple translations of free-form text. In the places where free-text is used for descriptive purposes, the given class always has a one-to-many cardinality to its parent (e.g., Description class). The intent is to allow the identical text to be encoded in different instances of the same class, but each being in a different language. This approach allows an IODEF document author to send recipients speaking different languages an identical document. The IODEF parser SHOULD extract the appropriate language relevant to the recipient.
The data model supports multiple translations of free-form text. In the places where free-text is used for descriptive purposes, the given class always has a one-to-many cardinality to its parent (e.g., Description class). The intent is to allow the identical text to be encoded in different instances of the same class, but each being in a different language. This approach allows an IODEF document author to send recipients speaking different languages an identical document. The IODEF parser SHOULD extract the appropriate language relevant to the recipient.
Danyliw, et al. Standards Track [Page 59] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 59] RFC 5070 IODEF December 2007
While the intent of the data model is to provide internationalization and localization, the intent is not to do so at the detriment of interoperability. While the IODEF does support different languages, the data model also relies heavily on standardized enumerated attributes that can crudely approximate the contents of the document. With this approach, a CSIRT should be able to make some sense of an IODEF document it receives even if the text based data elements are written in a language unfamiliar to the analyst.
While the intent of the data model is to provide internationalization and localization, the intent is not to do so at the detriment of interoperability. While the IODEF does support different languages, the data model also relies heavily on standardized enumerated attributes that can crudely approximate the contents of the document. With this approach, a CSIRT should be able to make some sense of an IODEF document it receives even if the text based data elements are written in a language unfamiliar to the analyst.
7. Examples
7. Examples
This section provides examples of an incident encoded in the IODEF. These examples do not necessarily represent the only way to encode a particular incident.
This section provides examples of an incident encoded in the IODEF. These examples do not necessarily represent the only way to encode a particular incident.
7.1. Worm
7.1. Worm
An example of a CSIRT reporting an instance of the Code Red worm.
An example of a CSIRT reporting an instance of the Code Red worm.
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example demonstrates a report for a very
old worm (Code Red) -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting">
<IncidentID name="csirt.example.com">189493</IncidentID>
<ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
<Description>Host sending out Code Red probes</Description>
<!-- An administrative privilege was attempted, but failed -->
<Assessment>
<Impact completion="failed" type="admin"/>
</Assessment>
<Contact role="creator" type="organization">
<ContactName>Example.com CSIRT</ContactName>
<RegistryHandle registry="arin">example-com</RegistryHandle>
<Email>contact@csirt.example.com</Email>
</Contact>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
<Counter type="event">57</Counter>
</Node>
</System>
<System category="target">
<?xml version="1.0" encoding="UTF-8"?> <!-- This example demonstrates a report for a very old worm (Code Red) --> <IODEF-Document version="1.00" lang="en" xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> <Incident purpose="reporting"> <IncidentID name="csirt.example.com">189493</IncidentID> <ReportTime>2001-09-13T23:19:24+00:00</ReportTime> <Description>Host sending out Code Red probes</Description> <!-- An administrative privilege was attempted, but failed --> <Assessment> <Impact completion="failed" type="admin"/> </Assessment> <Contact role="creator" type="organization"> <ContactName>Example.com CSIRT</ContactName> <RegistryHandle registry="arin">example-com</RegistryHandle> <Email>contact@csirt.example.com</Email> </Contact> <EventData> <Flow> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.200</Address> <Counter type="event">57</Counter> </Node> </System> <System category="target">
Danyliw, et al. Standards Track [Page 60] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 60] RFC 5070 IODEF December 2007
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Service ip_protocol="6">
<Port>80</Port>
</Service>
</System>
</Flow>
<Expectation action="block-host" />
<!-- <RecordItem> has an excerpt from a log -->
<Record>
<RecordData>
<DateTime>2001-09-13T18:11:21+02:00</DateTime>
<Description>Web-server logs</Description>
<RecordItem dtype="string">
192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</RecordItem>
<!-- Additional logs -->
<RecordItem dtype="url">
http://mylogs.example.com/logs/httpd_access</RecordItem>
</RecordData>
</Record>
</EventData>
<History>
<!-- Contact was previously made with the source network owner -->
<HistoryItem action="contact-source-site">
<DateTime>2001-09-14T08:19:01+00:00</DateTime>
<Description>Notification sent to
constituency-contact@192.0.2.200</Description>
</HistoryItem>
</History>
</Incident>
</IODEF-Document>
<Node> <Address category="ipv4-net">192.0.2.16/28</Address> </Node> <Service ip_protocol="6"> <Port>80</Port> </Service> </System> </Flow> <Expectation action="block-host" /> <!-- <RecordItem> has an excerpt from a log --> <Record> <RecordData> <DateTime>2001-09-13T18:11:21+02:00</DateTime> <Description>Web-server logs</Description> <RecordItem dtype="string"> 192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida? XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX </RecordItem> <!-- Additional logs --> <RecordItem dtype="url"> http://mylogs.example.com/logs/httpd_access</RecordItem> </RecordData> </Record> </EventData> <History> <!-- Contact was previously made with the source network owner --> <HistoryItem action="contact-source-site"> <DateTime>2001-09-14T08:19:01+00:00</DateTime> <Description>Notification sent to constituency-contact@192.0.2.200</Description> </HistoryItem> </History> </Incident> </IODEF-Document>
7.2. Reconnaissance
7.2. Reconnaissance
An example of a CSIRT reporting a scanning activity.
An example of a CSIRT reporting a scanning activity.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes reconnaissance activity: one-to-one and
one-to-many scanning -->
<?xml version="1.0" encoding="UTF-8" ?> <!-- This example describes reconnaissance activity: one-to-one and one-to-many scanning -->
Danyliw, et al. Standards Track [Page 61] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 61] RFC 5070 IODEF December 2007
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting">
<IncidentID name="csirt.example.com">59334</IncidentID>
<ReportTime>2006-08-02T05:54:02-05:00</ReportTime>
<Assessment>
<Impact type="recon" completion="succeeded" />
</Assessment>
<Method>
<!-- Reference to the scanning tool "nmap" -->
<Reference>
<ReferenceName>nmap</ReferenceName>
<URL>http://nmap.toolsite.example.com</URL>
</Reference>
</Method>
<!-- Organizational contact and that for staff in that
organization -->
<Contact role="creator" type="organization">
<ContactName>CSIRT for example.com</ContactName>
<Email>contact@csirt.example.com</Email>
<Telephone>+1 412 555 12345</Telephone>
<!-- Since this <Contact> is nested, Joe Smith is part of the
CSIRT for example.com -->
<Contact role="tech" type="person" restriction="need-to-know">
<ContactName>Joe Smith</ContactName>
<Email>smith@csirt.example.com</Email>
</Contact>
</Contact>
<EventData>
<!-- Scanning activity as follows:
192.0.2.1:60524 >> 192.0.2.3:137
192.0.2.1:60526 >> 192.0.2.3:138
192.0.2.1:60527 >> 192.0.2.3:139
192.0.2.1:60531 >> 192.0.2.3:445
-->
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
</Node>
<Service ip_protocol="6">
<Portlist>60524,60526,60527,60531</Portlist>
</Service>
</System>
<System category="target">
<Node>
<IODEF-Document version="1.00" lang="en" xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> <Incident purpose="reporting"> <IncidentID name="csirt.example.com">59334</IncidentID> <ReportTime>2006-08-02T05:54:02-05:00</ReportTime> <Assessment> <Impact type="recon" completion="succeeded" /> </Assessment> <Method> <!-- Reference to the scanning tool "nmap" --> <Reference> <ReferenceName>nmap</ReferenceName> <URL>http://nmap.toolsite.example.com</URL> </Reference> </Method> <!-- Organizational contact and that for staff in that organization --> <Contact role="creator" type="organization"> <ContactName>CSIRT for example.com</ContactName> <Email>contact@csirt.example.com</Email> <Telephone>+1 412 555 12345</Telephone> <!-- Since this <Contact> is nested, Joe Smith is part of the CSIRT for example.com --> <Contact role="tech" type="person" restriction="need-to-know"> <ContactName>Joe Smith</ContactName> <Email>smith@csirt.example.com</Email> </Contact> </Contact> <EventData> <!-- Scanning activity as follows: 192.0.2.1:60524 >> 192.0.2.3:137 192.0.2.1:60526 >> 192.0.2.3:138 192.0.2.1:60527 >> 192.0.2.3:139 192.0.2.1:60531 >> 192.0.2.3:445 --> <Flow> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.200</Address> </Node> <Service ip_protocol="6"> <Portlist>60524,60526,60527,60531</Portlist> </Service> </System> <System category="target"> <Node>
Danyliw, et al. Standards Track [Page 62] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 62] RFC 5070 IODEF December 2007
<Address category="ipv4-addr">192.0.2.201</Address>
</Node>
<Service ip_protocol="6">
<Portlist>137-139,445</Portlist>
</Service>
</System>
</Flow>
<!-- Scanning activity as follows:
192.0.2.2 >> 192.0.2.3/28:445 -->
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.240</Address>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.64/28</Address>
</Node>
<Service ip_protocol="6">
<Port>445</Port>
</Service>
</System>
</Flow>
</EventData>
</Incident>
</IODEF-Document>
<Address category="ipv4-addr">192.0.2.201</Address> </Node> <Service ip_protocol="6"> <Portlist>137-139,445</Portlist> </Service> </System> </Flow> <!-- Scanning activity as follows: 192.0.2.2 >> 192.0.2.3/28:445 --> <Flow> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.240</Address> </Node> </System> <System category="target"> <Node> <Address category="ipv4-net">192.0.2.64/28</Address> </Node> <Service ip_protocol="6"> <Port>445</Port> </Service> </System> </Flow> </EventData> </Incident> </IODEF-Document>
7.3. Bot-Net Reporting
7.3. Bot-Net Reporting
An example of a CSIRT reporting a bot-network.
An example of a CSIRT reporting a bot-network.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes a compromise and subsequent installation
of bots -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="mitigation">
<IncidentID name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-06-08T05:44:53-05:00</ReportTime>
<Description>Large bot-net</Description>
<Assessment>
<Impact type="dos" severity="high" completion="succeeded" />
<?xml version="1.0" encoding="UTF-8" ?> <!-- This example describes a compromise and subsequent installation of bots --> <IODEF-Document version="1.00" lang="en" xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> <Incident purpose="mitigation"> <IncidentID name="csirt.example.com">908711</IncidentID> <ReportTime>2006-06-08T05:44:53-05:00</ReportTime> <Description>Large bot-net</Description> <Assessment> <Impact type="dos" severity="high" completion="succeeded" />
Danyliw, et al. Standards Track [Page 63] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 63] RFC 5070 IODEF December 2007
</Assessment>
<Method>
<!-- References a given piece of malware, "GT Bot" -->
<Reference>
<ReferenceName>GT Bot</ReferenceName>
</Reference>
<!-- References the vulnerability used to compromise the
machines -->
<Reference>
<ReferenceName>CA-2003-22</ReferenceName>
<URL>http://www.cert.org/advisories/CA-2003-22.html</URL>
<Description>Root compromise via this IE vulnerability to
install the GT Bot</Description>
</Reference>
</Method>
<!-- A member of the CSIRT that is coordinating this
incident -->
<Contact type="person" role="irt">
<ContactName>Joe Smith</ContactName>
<Email>jsmith@csirt.example.com</Email>
</Contact>
<EventData>
<Description>These hosts are compromised and acting as bots
communicating with irc.example.com.</Description>
<Flow>
<!-- bot running on 192.0.2.1 and sending DoS traffic at
10,000 bytes/second -->
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.1</Address>
</Node>
<Counter type="byte" duration="second">10000</Counter>
<Description>bot</Description>
</System>
<!-- a second bot on 192.0.2.3 -->
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.3</Address>
</Node>
<Counter type="byte" duration="second">250000</Counter>
<Description>bot</Description>
</System>
<!-- Command-and-control IRC server for these bots-->
<System category="intermediate">
<Node>
<NodeName>irc.example.com</NodeName>
<Address category="ipv4-addr">192.0.2.20</Address>
<DateTime>2006-06-08T01:01:03-05:00</DateTime>
</Assessment> <Method> <!-- References a given piece of malware, "GT Bot" --> <Reference> <ReferenceName>GT Bot</ReferenceName> </Reference> <!-- References the vulnerability used to compromise the machines --> <Reference> <ReferenceName>CA-2003-22</ReferenceName> <URL>http://www.cert.org/advisories/CA-2003-22.html</URL> <Description>Root compromise via this IE vulnerability to install the GT Bot</Description> </Reference> </Method> <!-- A member of the CSIRT that is coordinating this incident --> <Contact type="person" role="irt"> <ContactName>Joe Smith</ContactName> <Email>jsmith@csirt.example.com</Email> </Contact> <EventData> <Description>These hosts are compromised and acting as bots communicating with irc.example.com.</Description> <Flow> <!-- bot running on 192.0.2.1 and sending DoS traffic at 10,000 bytes/second --> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.1</Address> </Node> <Counter type="byte" duration="second">10000</Counter> <Description>bot</Description> </System> <!-- a second bot on 192.0.2.3 --> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.3</Address> </Node> <Counter type="byte" duration="second">250000</Counter> <Description>bot</Description> </System> <!-- Command-and-control IRC server for these bots--> <System category="intermediate"> <Node> <NodeName>irc.example.com</NodeName> <Address category="ipv4-addr">192.0.2.20</Address> <DateTime>2006-06-08T01:01:03-05:00</DateTime>
Danyliw, et al. Standards Track [Page 64] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 64] RFC 5070 IODEF December 2007
</Node>
<Description>IRC server on #give-me-cmd channel</Description>
</System>
</Flow>
<!-- Request to take these machines offline -->
<Expectation action="investigate">
<Description>Confirm the source and take machines off-line and
remediate</Description>
</Expectation>
</EventData>
</Incident>
</IODEF-Document>
</Node> <Description>IRC server on #give-me-cmd channel</Description> </System> </Flow> <!-- Request to take these machines offline --> <Expectation action="investigate"> <Description>Confirm the source and take machines off-line and remediate</Description> </Expectation> </EventData> </Incident> </IODEF-Document>
7.4. Watch List
7.4. Watch List
An example of a CSIRT conveying a watch-list.
An example of a CSIRT conveying a watch-list.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example demonstrates a trivial IP watch-list -->
<!-- @formatid is set to "watch-list-043" to demonstrate how additional
semantics about this document could be conveyed assuming both
parties understood it-->
<IODEF-Document version="1.00" lang="en" formatid="watch-list-043"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-08-01T00:00:00-05:00</ReportTime>
<Description>Watch-list of known bad IPs or networks</Description>
<Assessment>
<Impact type="admin" completion="succeeded" />
<Impact type="recon" completion="succeeded" />
</Assessment>
<Contact type="organization" role="creator">
<ContactName>CSIRT for example.com</ContactName>
<Email>contact@csirt.example.com</Email>
</Contact>
<!-- Separate <EventData> used to convey different <Expectation> -->
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.53</Address>
</Node>
<?xml version="1.0" encoding="UTF-8" ?> <!-- This example demonstrates a trivial IP watch-list --> <!-- @formatid is set to "watch-list-043" to demonstrate how additional semantics about this document could be conveyed assuming both parties understood it--> <IODEF-Document version="1.00" lang="en" formatid="watch-list-043" xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> <Incident purpose="reporting" restriction="private"> <IncidentID name="csirt.example.com">908711</IncidentID> <ReportTime>2006-08-01T00:00:00-05:00</ReportTime> <Description>Watch-list of known bad IPs or networks</Description> <Assessment> <Impact type="admin" completion="succeeded" /> <Impact type="recon" completion="succeeded" /> </Assessment> <Contact type="organization" role="creator"> <ContactName>CSIRT for example.com</ContactName> <Email>contact@csirt.example.com</Email> </Contact> <!-- Separate <EventData> used to convey different <Expectation> --> <EventData> <Flow> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.53</Address> </Node>
Danyliw, et al. Standards Track [Page 65] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 65] RFC 5070 IODEF December 2007
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<!-- Expectation class indicating that sender of list would like
to be notified if activity from the host is seen -->
<Expectation action="contact-sender" />
</EventData>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Description>
Source of heavy scanning over past 1-month
</Description>
</System>
</Flow>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.241</Address>
</Node>
<Description>C2 IRC server</Description>
</System>
</Flow>
<!-- Expectation class recommends that these networks
be filtered -->
<Expectation action="block-host" />
</EventData>
</Incident>
</IODEF-Document>
<Description>Source of numerous attacks</Description> </System> </Flow> <!-- Expectation class indicating that sender of list would like to be notified if activity from the host is seen --> <Expectation action="contact-sender" /> </EventData> <EventData> <Flow> <System category="source"> <Node> <Address category="ipv4-net">192.0.2.16/28</Address> </Node> <Description> Source of heavy scanning over past 1-month </Description> </System> </Flow> <Flow> <System category="source"> <Node> <Address category="ipv4-addr">192.0.2.241</Address> </Node> <Description>C2 IRC server</Description> </System> </Flow> <!-- Expectation class recommends that these networks be filtered --> <Expectation action="block-host" /> </EventData> </Incident> </IODEF-Document>
8. The IODEF Schema
8. The IODEF Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:iodef-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:iodef-1.0" xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
Incident Object Description Exchange Format v1.00, see RFC 5070
<xs:annotation> <xs:documentation> Incident Object Description Exchange Format v1.00, see RFC 5070
Danyliw, et al. Standards Track [Page 66] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 66] RFC 5070 IODEF December 2007
</xs:documentation>
</xs:annotation>
</xs:documentation> </xs:annotation>
<!--
====================================================================
== IODEF-Document class ==
====================================================================
-->
<xs:element name="IODEF-Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Incident"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version"
type="xs:string" fixed="1.00"/>
<xs:attribute name="lang"
type="xs:language" use="required"/>
<xs:attribute name="formatid"
type="xs:string"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Incident class ===
====================================================================
-->
<xs:element name="Incident">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID"/>
<xs:element ref="iodef:AlternativeID"
minOccurs="0"/>
<xs:element ref="iodef:RelatedActivity"
minOccurs="0"/>
<xs:element ref="iodef:DetectTime"
minOccurs="0"/>
<xs:element ref="iodef:StartTime"
minOccurs="0"/>
<xs:element ref="iodef:EndTime"
minOccurs="0"/>
<xs:element ref="iodef:ReportTime"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Assessment"
maxOccurs="unbounded"/>
<xs:element ref="iodef:Method"
minOccurs="0" maxOccurs="unbounded"/>
<!-- ==================================================================== == IODEF-Document class == ==================================================================== --> <xs:element name="IODEF-Document"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:Incident" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="version" type="xs:string" fixed="1.00"/> <xs:attribute name="lang" type="xs:language" use="required"/> <xs:attribute name="formatid" type="xs:string"/> </xs:complexType> </xs:element> <!-- ==================================================================== === Incident class === ==================================================================== --> <xs:element name="Incident"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:IncidentID"/> <xs:element ref="iodef:AlternativeID" minOccurs="0"/> <xs:element ref="iodef:RelatedActivity" minOccurs="0"/> <xs:element ref="iodef:DetectTime" minOccurs="0"/> <xs:element ref="iodef:StartTime" minOccurs="0"/> <xs:element ref="iodef:EndTime" minOccurs="0"/> <xs:element ref="iodef:ReportTime"/> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Assessment" maxOccurs="unbounded"/> <xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/>
Danyliw, et al. Standards Track [Page 67] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 67] RFC 5070 IODEF December 2007
<xs:element ref="iodef:Contact"
maxOccurs="unbounded"/>
<xs:element ref="iodef:EventData"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:History"
minOccurs="0"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="purpose" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="traceback"/>
<xs:enumeration value="mitigation"/>
<xs:enumeration value="reporting"/>
<xs:enumeration value="other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-purpose"
type="xs:string" use="optional"/>
<xs:attribute name="lang"
type="xs:language"/>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="private"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
== IncidentID class ==
====================================================================
-->
<xs:element name="IncidentID" type="iodef:IncidentIDType"/>
<xs:complexType name="IncidentIDType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name"
type="xs:string" use="required"/>
<xs:attribute name="instance"
type="xs:string" use="optional"/>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="public"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element ref="iodef:Contact" maxOccurs="unbounded"/> <xs:element ref="iodef:EventData" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:History" minOccurs="0"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="purpose" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="traceback"/> <xs:enumeration value="mitigation"/> <xs:enumeration value="reporting"/> <xs:enumeration value="other"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-purpose" type="xs:string" use="optional"/> <xs:attribute name="lang" type="xs:language"/> <xs:attribute name="restriction" type="iodef:restriction-type" default="private"/> </xs:complexType> </xs:element> <!-- ==================================================================== == IncidentID class == ==================================================================== --> <xs:element name="IncidentID" type="iodef:IncidentIDType"/> <xs:complexType name="IncidentIDType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="instance" type="xs:string" use="optional"/> <xs:attribute name="restriction" type="iodef:restriction-type" default="public"/> </xs:extension> </xs:simpleContent> </xs:complexType>
Danyliw, et al. Standards Track [Page 68] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 68] RFC 5070 IODEF December 2007
<!--
====================================================================
== AlternativeID class ==
====================================================================
-->
<xs:element name="AlternativeID">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
== RelatedActivity class ==
====================================================================
-->
<xs:element name="RelatedActivity">
<xs:complexType>
<xs:choice>
<xs:element ref="iodef:IncidentID"
maxOccurs="unbounded"/>
<xs:element ref="iodef:URL"
maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== AdditionalData class ===
====================================================================
-->
<xs:element name="AdditionalData" type="iodef:ExtensionType"/>
<!--
====================================================================
=== Contact class ===
====================================================================
-->
<xs:element name="Contact">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:ContactName"
minOccurs="0"/>
<!-- ==================================================================== == AlternativeID class == ==================================================================== --> <xs:element name="AlternativeID"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:IncidentID" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <!-- ==================================================================== == RelatedActivity class == ==================================================================== --> <xs:element name="RelatedActivity"> <xs:complexType> <xs:choice> <xs:element ref="iodef:IncidentID" maxOccurs="unbounded"/> <xs:element ref="iodef:URL" maxOccurs="unbounded"/> </xs:choice> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <!-- ==================================================================== === AdditionalData class === ==================================================================== --> <xs:element name="AdditionalData" type="iodef:ExtensionType"/> <!-- ==================================================================== === Contact class === ==================================================================== --> <xs:element name="Contact"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:ContactName" minOccurs="0"/>
Danyliw, et al. Standards Track [Page 69] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 69] RFC 5070 IODEF December 2007
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:RegistryHandle"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:PostalAddress"
minOccurs="0"/>
<xs:element ref="iodef:Email"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Telephone"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Fax"
minOccurs="0"/>
<xs:element ref="iodef:Timezone"
minOccurs="0"/>
<xs:element ref="iodef:Contact"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="role" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="creator"/>
<xs:enumeration value="admin"/>
<xs:enumeration value="tech"/>
<xs:enumeration value="irt"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-role"
type="xs:string" use="optional"/>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="person"/>
<xs:enumeration value="organization"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:RegistryHandle" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:PostalAddress" minOccurs="0"/> <xs:element ref="iodef:Email" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Telephone" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Fax" minOccurs="0"/> <xs:element ref="iodef:Timezone" minOccurs="0"/> <xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="role" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="creator"/> <xs:enumeration value="admin"/> <xs:enumeration value="tech"/> <xs:enumeration value="irt"/> <xs:enumeration value="cc"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-role" type="xs:string" use="optional"/> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="person"/> <xs:enumeration value="organization"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element>
Danyliw, et al. Standards Track [Page 70] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 70] RFC 5070 IODEF December 2007
<xs:element name="ContactName"
type="iodef:MLStringType"/>
<xs:element name="RegistryHandle">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="registry">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="internic"/>
<xs:enumeration value="apnic"/>
<xs:enumeration value="arin"/>
<xs:enumeration value="lacnic"/>
<xs:enumeration value="ripe"/>
<xs:enumeration value="afrinic"/>
<xs:enumeration value="local"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-registry"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="ContactName" type="iodef:MLStringType"/> <xs:element name="RegistryHandle"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="registry"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="internic"/> <xs:enumeration value="apnic"/> <xs:enumeration value="arin"/> <xs:enumeration value="lacnic"/> <xs:enumeration value="ripe"/> <xs:enumeration value="afrinic"/> <xs:enumeration value="local"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-registry" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name="PostalAddress">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="meaning"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Email" type="iodef:ContactMeansType"/>
<xs:element name="Telephone" type="iodef:ContactMeansType"/>
<xs:element name="Fax" type="iodef:ContactMeansType"/>
<xs:element name="PostalAddress"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:MLStringType"> <xs:attribute name="meaning" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="Email" type="iodef:ContactMeansType"/> <xs:element name="Telephone" type="iodef:ContactMeansType"/> <xs:element name="Fax" type="iodef:ContactMeansType"/>
<xs:complexType name="ContactMeansType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="meaning"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
<xs:complexType name="ContactMeansType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="meaning" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent>
Danyliw, et al. Standards Track [Page 71] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 71] RFC 5070 IODEF December 2007
</xs:complexType>
</xs:complexType>
<!--
====================================================================
=== Time-based classes ===
====================================================================
-->
<xs:element name="DateTime"
type="xs:dateTime"/>
<xs:element name="ReportTime"
type="xs:dateTime"/>
<xs:element name="DetectTime"
type="xs:dateTime"/>
<xs:element name="StartTime"
type="xs:dateTime"/>
<xs:element name="EndTime"
type="xs:dateTime"/>
<xs:element name="Timezone"
type="iodef:TimezoneType"/>
<xs:simpleType name="TimezoneType">
<xs:restriction base="xs:string">
<xs:pattern value="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]"/>
</xs:restriction>
</xs:simpleType>
<!--
====================================================================
=== History class ===
====================================================================
-->
<xs:element name="History">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:HistoryItem"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="default"/>
</xs:complexType>
</xs:element>
<xs:element name="HistoryItem">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:DateTime"/>
<xs:element ref="iodef:IncidentID"
minOccurs="0"/>
<xs:element ref="iodef:Contact"
minOccurs="0"/>
<xs:element ref="iodef:Description"
<!-- ==================================================================== === Time-based classes === ==================================================================== --> <xs:element name="DateTime" type="xs:dateTime"/> <xs:element name="ReportTime" type="xs:dateTime"/> <xs:element name="DetectTime" type="xs:dateTime"/> <xs:element name="StartTime" type="xs:dateTime"/> <xs:element name="EndTime" type="xs:dateTime"/> <xs:element name="Timezone" type="iodef:TimezoneType"/> <xs:simpleType name="TimezoneType"> <xs:restriction base="xs:string"> <xs:pattern value="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]"/> </xs:restriction> </xs:simpleType> <!-- ==================================================================== === History class === ==================================================================== --> <xs:element name="History"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:HistoryItem" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type" default="default"/> </xs:complexType> </xs:element> <xs:element name="HistoryItem"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:DateTime"/> <xs:element ref="iodef:IncidentID" minOccurs="0"/> <xs:element ref="iodef:Contact" minOccurs="0"/> <xs:element ref="iodef:Description"
Danyliw, et al. Standards Track [Page 72] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 72] RFC 5070 IODEF December 2007
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<xs:attribute name="action"
type="iodef:action-type" use="required"/>
<xs:attribute name="ext-action"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Expectation class ===
====================================================================
-->
<xs:element name="Expectation">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:StartTime"
minOccurs="0"/>
<xs:element ref="iodef:EndTime"
minOccurs="0"/>
<xs:element ref="iodef:Contact"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="default"/>
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="action"
type="iodef:action-type" default="other"/>
<xs:attribute name="ext-action"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Method class ===
====================================================================
-->
<xs:element name="Method">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> <xs:attribute name="action" type="iodef:action-type" use="required"/> <xs:attribute name="ext-action" type="xs:string" use="optional"/> </xs:complexType> </xs:element> <!-- ==================================================================== === Expectation class === ==================================================================== --> <xs:element name="Expectation"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:StartTime" minOccurs="0"/> <xs:element ref="iodef:EndTime" minOccurs="0"/> <xs:element ref="iodef:Contact" minOccurs="0"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type" default="default"/> <xs:attribute name="severity" type="iodef:severity-type"/> <xs:attribute name="action" type="iodef:action-type" default="other"/> <xs:attribute name="ext-action" type="xs:string" use="optional"/> </xs:complexType> </xs:element> <!-- ==================================================================== === Method class === ==================================================================== --> <xs:element name="Method"> <xs:complexType> <xs:sequence> <xs:choice maxOccurs="unbounded">
Danyliw, et al. Standards Track [Page 73] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 73] RFC 5070 IODEF December 2007
<xs:element ref="iodef:Reference"/>
<xs:element ref="iodef:Description"/>
</xs:choice>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element name="Reference">
<xs:complexType>
<xs:sequence>
<xs:element name="ReferenceName"
type="iodef:MLStringType"/>
<xs:element ref="iodef:URL"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Assessment class ===
====================================================================
-->
<xs:element name="Assessment">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:Impact"/>
<xs:element ref="iodef:TimeImpact"/>
<xs:element ref="iodef:MonetaryImpact"/>
</xs:choice>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Confidence" minOccurs="0"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="occurrence">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="actual"/>
<xs:enumeration value="potential"/>
</xs:restriction>
</xs:simpleType>
<xs:element ref="iodef:Reference"/> <xs:element ref="iodef:Description"/> </xs:choice> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="Reference"> <xs:complexType> <xs:sequence> <xs:element name="ReferenceName" type="iodef:MLStringType"/> <xs:element ref="iodef:URL" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <!-- ==================================================================== === Assessment class === ==================================================================== --> <xs:element name="Assessment"> <xs:complexType> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element ref="iodef:Impact"/> <xs:element ref="iodef:TimeImpact"/> <xs:element ref="iodef:MonetaryImpact"/> </xs:choice> <xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Confidence" minOccurs="0"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="occurrence"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="actual"/> <xs:enumeration value="potential"/> </xs:restriction> </xs:simpleType>
Danyliw, et al. Standards Track [Page 74] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 74] RFC 5070 IODEF December 2007
</xs:attribute>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element name="Impact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="completion">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="failed"/>
<xs:enumeration value="succeeded"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="type"
use="optional" default="unknown">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="admin"/>
<xs:enumeration value="dos"/>
<xs:enumeration value="extortion"/>
<xs:enumeration value="file"/>
<xs:enumeration value="info-leak"/>
<xs:enumeration value="misconfiguration"/>
<xs:enumeration value="recon"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="social-engineering"/>
<xs:enumeration value="user"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="TimeImpact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:PositiveFloatType">
</xs:attribute> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="Impact"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:MLStringType"> <xs:attribute name="severity" type="iodef:severity-type"/> <xs:attribute name="completion"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="failed"/> <xs:enumeration value="succeeded"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="type" use="optional" default="unknown"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="admin"/> <xs:enumeration value="dos"/> <xs:enumeration value="extortion"/> <xs:enumeration value="file"/> <xs:enumeration value="info-leak"/> <xs:enumeration value="misconfiguration"/> <xs:enumeration value="recon"/> <xs:enumeration value="policy"/> <xs:enumeration value="social-engineering"/> <xs:enumeration value="user"/> <xs:enumeration value="unknown"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="TimeImpact"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:PositiveFloatType">
Danyliw, et al. Standards Track [Page 75] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 75] RFC 5070 IODEF December 2007
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="metric"
use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="labor"/>
<xs:enumeration value="elapsed"/>
<xs:enumeration value="downtime"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-metric"
type="xs:string" use="optional"/>
<xs:attribute name="duration"
type="iodef:duration-type"/>
<xs:attribute name="ext-duration"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="MonetaryImpact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:PositiveFloatType">
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="currency"
type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Confidence">
<xs:complexType mixed="true">
<xs:attribute name="rating" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="high"/>
<xs:enumeration value="numeric"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="severity" type="iodef:severity-type"/> <xs:attribute name="metric" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="labor"/> <xs:enumeration value="elapsed"/> <xs:enumeration value="downtime"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-metric" type="xs:string" use="optional"/> <xs:attribute name="duration" type="iodef:duration-type"/> <xs:attribute name="ext-duration" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="MonetaryImpact"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:PositiveFloatType"> <xs:attribute name="severity" type="iodef:severity-type"/> <xs:attribute name="currency" type="xs:string"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="Confidence"> <xs:complexType mixed="true"> <xs:attribute name="rating" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="low"/> <xs:enumeration value="medium"/> <xs:enumeration value="high"/> <xs:enumeration value="numeric"/> <xs:enumeration value="unknown"/> </xs:restriction> </xs:simpleType> </xs:attribute>
Danyliw, et al. Standards Track [Page 76] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 76] RFC 5070 IODEF December 2007
</xs:complexType>
</xs:element>
<!--
====================================================================
=== EventData class ===
====================================================================
-->
<xs:element name="EventData">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:DetectTime"
minOccurs="0"/>
<xs:element ref="iodef:StartTime"
minOccurs="0"/>
<xs:element ref="iodef:EndTime"
minOccurs="0"/>
<xs:element ref="iodef:Contact"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Assessment"
minOccurs="0"/>
<xs:element ref="iodef:Method"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Flow"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Expectation"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Record"
minOccurs="0"/>
<xs:element ref="iodef:EventData"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="default"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Flow class ===
====================================================================
-->
<xs:element name="Flow">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:System"
</xs:complexType> </xs:element> <!-- ==================================================================== === EventData class === ==================================================================== --> <xs:element name="EventData"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:DetectTime" minOccurs="0"/> <xs:element ref="iodef:StartTime" minOccurs="0"/> <xs:element ref="iodef:EndTime" minOccurs="0"/> <xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Assessment" minOccurs="0"/> <xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Flow" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Expectation" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Record" minOccurs="0"/> <xs:element ref="iodef:EventData" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type" default="default"/> </xs:complexType> </xs:element> <!-- ==================================================================== === Flow class === ==================================================================== --> <xs:element name="Flow"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:System"
Danyliw, et al. Standards Track [Page 77] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 77] RFC 5070 IODEF December 2007
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== System class ===
====================================================================
-->
<xs:element name="System">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef:Service"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:OperatingSystem"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<xs:attribute name="interface"
type="xs:string"/>
<xs:attribute name="category">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="source"/>
<xs:enumeration value="target"/>
<xs:enumeration value="intermediate"/>
<xs:enumeration value="sensor"/>
<xs:enumeration value="infrastructure"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<xs:attribute name="spoofed"
default="unknown">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="unknown"/>
<xs:enumeration value="yes"/>
maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <!-- ==================================================================== === System class === ==================================================================== --> <xs:element name="System"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:Node"/> <xs:element ref="iodef:Service" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:OperatingSystem" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> <xs:attribute name="interface" type="xs:string"/> <xs:attribute name="category"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="source"/> <xs:enumeration value="target"/> <xs:enumeration value="intermediate"/> <xs:enumeration value="sensor"/> <xs:enumeration value="infrastructure"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-category" type="xs:string" use="optional"/> <xs:attribute name="spoofed" default="unknown"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="unknown"/> <xs:enumeration value="yes"/>
Danyliw, et al. Standards Track [Page 78] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 78] RFC 5070 IODEF December 2007
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Node class ===
====================================================================
-->
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element name="NodeName"
type="iodef:MLStringType" minOccurs="0"/>
<xs:element ref="iodef:Address"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:element ref="iodef:Location"
minOccurs="0"/>
<xs:element ref="iodef:DateTime"
minOccurs="0"/>
<xs:element ref="iodef:NodeRole"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Address">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="category" default="ipv4-addr">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="asn"/>
<xs:enumeration value="atm"/>
<xs:enumeration value="e-mail"/>
<xs:enumeration value="mac"/>
<xs:enumeration value="ipv4-addr"/>
<xs:enumeration value="ipv4-net"/>
<xs:enumeration value="ipv4-net-mask"/>
<xs:enumeration value="ipv6-addr"/>
<xs:enumeration value="ipv6-net"/>
<xs:enumeration value="ipv6-net-mask"/>
<xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <!-- ==================================================================== === Node class === ==================================================================== --> <xs:element name="Node"> <xs:complexType> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element name="NodeName" type="iodef:MLStringType" minOccurs="0"/> <xs:element ref="iodef:Address" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> <xs:element ref="iodef:Location" minOccurs="0"/> <xs:element ref="iodef:DateTime" minOccurs="0"/> <xs:element ref="iodef:NodeRole" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Address"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="category" default="ipv4-addr"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="asn"/> <xs:enumeration value="atm"/> <xs:enumeration value="e-mail"/> <xs:enumeration value="mac"/> <xs:enumeration value="ipv4-addr"/> <xs:enumeration value="ipv4-net"/> <xs:enumeration value="ipv4-net-mask"/> <xs:enumeration value="ipv6-addr"/> <xs:enumeration value="ipv6-net"/> <xs:enumeration value="ipv6-net-mask"/>
Danyliw, et al. Standards Track [Page 79] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 79] RFC 5070 IODEF December 2007
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<xs:attribute name="vlan-name"
type="xs:string"/>
<xs:attribute name="vlan-num"
type="xs:integer"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Location" type="iodef:MLStringType"/>
<xs:element name="NodeRole">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="category" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="client"/>
<xs:enumeration value="server-internal"/>
<xs:enumeration value="server-public"/>
<xs:enumeration value="www"/>
<xs:enumeration value="mail"/>
<xs:enumeration value="messaging"/>
<xs:enumeration value="streaming"/>
<xs:enumeration value="voice"/>
<xs:enumeration value="file"/>
<xs:enumeration value="ftp"/>
<xs:enumeration value="p2p"/>
<xs:enumeration value="name"/>
<xs:enumeration value="directory"/>
<xs:enumeration value="credential"/>
<xs:enumeration value="print"/>
<xs:enumeration value="application"/>
<xs:enumeration value="database"/>
<xs:enumeration value="infra"/>
<xs:enumeration value="log"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
</xs:extension>
<xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-category" type="xs:string" use="optional"/> <xs:attribute name="vlan-name" type="xs:string"/> <xs:attribute name="vlan-num" type="xs:integer"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="Location" type="iodef:MLStringType"/> <xs:element name="NodeRole"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:MLStringType"> <xs:attribute name="category" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="client"/> <xs:enumeration value="server-internal"/> <xs:enumeration value="server-public"/> <xs:enumeration value="www"/> <xs:enumeration value="mail"/> <xs:enumeration value="messaging"/> <xs:enumeration value="streaming"/> <xs:enumeration value="voice"/> <xs:enumeration value="file"/> <xs:enumeration value="ftp"/> <xs:enumeration value="p2p"/> <xs:enumeration value="name"/> <xs:enumeration value="directory"/> <xs:enumeration value="credential"/> <xs:enumeration value="print"/> <xs:enumeration value="application"/> <xs:enumeration value="database"/> <xs:enumeration value="infra"/> <xs:enumeration value="log"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-category" type="xs:string" use="optional"/> </xs:extension>
Danyliw, et al. Standards Track [Page 80] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 80] RFC 5070 IODEF December 2007
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Service Class ===
====================================================================
-->
<xs:element name="Service">
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs="0">
<xs:element name="Port"
type="xs:integer"/>
<xs:element name="Portlist"
type="iodef:PortlistType"/>
</xs:choice>
<xs:element name="ProtoType"
type="xs:integer" minOccurs="0"/>
<xs:element name="ProtoCode"
type="xs:integer" minOccurs="0"/>
<xs:element name="ProtoField"
type="xs:integer" minOccurs="0"/>
<xs:element ref="iodef:Application"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ip_protocol"
type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="PortlistType">
<xs:restriction base="xs:string">
<xs:pattern value="\d+(\-\d+)?(,\d+(\-\d+)?)*"/>
</xs:restriction>
</xs:simpleType>
<!--
====================================================================
=== Counter class ===
====================================================================
-->
<xs:element name="Counter">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="byte"/>
</xs:simpleContent> </xs:complexType> </xs:element> <!-- ==================================================================== === Service Class === ==================================================================== --> <xs:element name="Service"> <xs:complexType> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="Port" type="xs:integer"/> <xs:element name="Portlist" type="iodef:PortlistType"/> </xs:choice> <xs:element name="ProtoType" type="xs:integer" minOccurs="0"/> <xs:element name="ProtoCode" type="xs:integer" minOccurs="0"/> <xs:element name="ProtoField" type="xs:integer" minOccurs="0"/> <xs:element ref="iodef:Application" minOccurs="0"/> </xs:sequence> <xs:attribute name="ip_protocol" type="xs:integer" use="required"/> </xs:complexType> </xs:element> <xs:simpleType name="PortlistType"> <xs:restriction base="xs:string"> <xs:pattern value="\d+(\-\d+)?(,\d+(\-\d+)?)*"/> </xs:restriction> </xs:simpleType> <!-- ==================================================================== === Counter class === ==================================================================== --> <xs:element name="Counter"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:double"> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="byte"/>
Danyliw, et al. Standards Track [Page 81] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 81] RFC 5070 IODEF December 2007
<xs:enumeration value="packet"/>
<xs:enumeration value="flow"/>
<xs:enumeration value="session"/>
<xs:enumeration value="event"/>
<xs:enumeration value="alert"/>
<xs:enumeration value="message"/>
<xs:enumeration value="host"/>
<xs:enumeration value="site"/>
<xs:enumeration value="organization"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
<xs:attribute name="meaning"
type="xs:string" use="optional"/>
<xs:attribute name="duration"
type="iodef:duration-type"/>
<xs:attribute name="ext-duration"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Record class ===
====================================================================
-->
<xs:element name="Record">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:RecordData"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element name="RecordData">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:DateTime"
minOccurs="0"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Application"
<xs:enumeration value="packet"/> <xs:enumeration value="flow"/> <xs:enumeration value="session"/> <xs:enumeration value="event"/> <xs:enumeration value="alert"/> <xs:enumeration value="message"/> <xs:enumeration value="host"/> <xs:enumeration value="site"/> <xs:enumeration value="organization"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> <xs:attribute name="meaning" type="xs:string" use="optional"/> <xs:attribute name="duration" type="iodef:duration-type"/> <xs:attribute name="ext-duration" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <!-- ==================================================================== === Record class === ==================================================================== --> <xs:element name="Record"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:RecordData" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="RecordData"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:DateTime" minOccurs="0"/> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Application"
Danyliw, et al. Standards Track [Page 82] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 82] RFC 5070 IODEF December 2007
minOccurs="0"/>
<xs:element ref="iodef:RecordPattern"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:RecordItem"
maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element name="RecordPattern">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="regex"/>
<xs:enumeration value="binary"/>
<xs:enumeration value="xpath"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
<xs:attribute name="offset"
type="xs:integer" use="optional"/>
<xs:attribute name="offsetunit"
use="optional" default="line">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="line"/>
<xs:enumeration value="byte"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-offsetunit"
type="xs:string" use="optional"/>
<xs:attribute name="instance"
type="xs:integer" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
minOccurs="0"/> <xs:element ref="iodef:RecordPattern" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:RecordItem" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="RecordPattern"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="regex"/> <xs:enumeration value="binary"/> <xs:enumeration value="xpath"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> <xs:attribute name="offset" type="xs:integer" use="optional"/> <xs:attribute name="offsetunit" use="optional" default="line"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="line"/> <xs:enumeration value="byte"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-offsetunit" type="xs:string" use="optional"/> <xs:attribute name="instance" type="xs:integer" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
Danyliw, et al. Standards Track [Page 83] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 83] RFC 5070 IODEF December 2007
<xs:element name="RecordItem"
type="iodef:ExtensionType"/>
<!--
====================================================================
=== Classes that describe software ===
====================================================================
-->
<xs:complexType name="SoftwareType">
<xs:sequence>
<xs:element ref="iodef:URL"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="swid"
type="xs:string" default="0"/>
<xs:attribute name="configid"
type="xs:string" default="0"/>
<xs:attribute name="vendor"
type="xs:string"/>
<xs:attribute name="family"
type="xs:string"/>
<xs:attribute name="name"
type="xs:string"/>
<xs:attribute name="version"
type="xs:string"/>
<xs:attribute name="patch"
type="xs:string"/>
</xs:complexType>
<xs:element name="Application"
type="iodef:SoftwareType"/>
<xs:element name="OperatingSystem"
type="iodef:SoftwareType"/>
<!--
====================================================================
=== Miscellaneous simple classes ===
====================================================================
-->
<xs:element name="Description"
type="iodef:MLStringType"/>
<xs:element name="URL"
type="xs:anyURI"/>
<!--
====================================================================
=== Data Types ===
====================================================================
-->
<xs:simpleType name="PositiveFloatType">
<xs:restriction base="xs:float">
<xs:minExclusive value="0"/>
<xs:element name="RecordItem" type="iodef:ExtensionType"/> <!-- ==================================================================== === Classes that describe software === ==================================================================== --> <xs:complexType name="SoftwareType"> <xs:sequence> <xs:element ref="iodef:URL" minOccurs="0"/> </xs:sequence> <xs:attribute name="swid" type="xs:string" default="0"/> <xs:attribute name="configid" type="xs:string" default="0"/> <xs:attribute name="vendor" type="xs:string"/> <xs:attribute name="family" type="xs:string"/> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="version" type="xs:string"/> <xs:attribute name="patch" type="xs:string"/> </xs:complexType> <xs:element name="Application" type="iodef:SoftwareType"/> <xs:element name="OperatingSystem" type="iodef:SoftwareType"/> <!-- ==================================================================== === Miscellaneous simple classes === ==================================================================== --> <xs:element name="Description" type="iodef:MLStringType"/> <xs:element name="URL" type="xs:anyURI"/> <!-- ==================================================================== === Data Types === ==================================================================== --> <xs:simpleType name="PositiveFloatType"> <xs:restriction base="xs:float"> <xs:minExclusive value="0"/>
Danyliw, et al. Standards Track [Page 84] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 84] RFC 5070 IODEF December 2007
</xs:restriction>
</xs:simpleType>
<xs:complexType name="MLStringType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang"
type="xs:language" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ExtensionType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="dtype"
type="iodef:dtype-type" use="required"/>
<xs:attribute name="ext-dtype"
type="xs:string" use="optional"/>
<xs:attribute name="meaning"
type="xs:string"/>
<xs:attribute name="formatid"
type="xs:string"/>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
<!--
====================================================================
=== Global attribute type declarations ===
====================================================================
-->
<xs:simpleType name="restriction-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="default"/>
<xs:enumeration value="public"/>
<xs:enumeration value="need-to-know"/>
<xs:enumeration value="private"/>
</xs:restriction>
</xs:simpleType>
</xs:restriction> </xs:simpleType> <xs:complexType name="MLStringType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="lang" type="xs:language" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="ExtensionType" mixed="true"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="dtype" type="iodef:dtype-type" use="required"/> <xs:attribute name="ext-dtype" type="xs:string" use="optional"/> <xs:attribute name="meaning" type="xs:string"/> <xs:attribute name="formatid" type="xs:string"/> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> <!-- ==================================================================== === Global attribute type declarations === ==================================================================== --> <xs:simpleType name="restriction-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="default"/> <xs:enumeration value="public"/> <xs:enumeration value="need-to-know"/> <xs:enumeration value="private"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="severity-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="high"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="severity-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="low"/> <xs:enumeration value="medium"/> <xs:enumeration value="high"/> </xs:restriction> </xs:simpleType>
Danyliw, et al. Standards Track [Page 85] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 85] RFC 5070 IODEF December 2007
<xs:simpleType name="duration-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="second"/>
<xs:enumeration value="minute"/>
<xs:enumeration value="hour"/>
<xs:enumeration value="day"/>
<xs:enumeration value="month"/>
<xs:enumeration value="quarter"/>
<xs:enumeration value="year"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="duration-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="second"/> <xs:enumeration value="minute"/> <xs:enumeration value="hour"/> <xs:enumeration value="day"/> <xs:enumeration value="month"/> <xs:enumeration value="quarter"/> <xs:enumeration value="year"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="action-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="nothing"/>
<xs:enumeration value="contact-source-site"/>
<xs:enumeration value="contact-target-site"/>
<xs:enumeration value="contact-sender"/>
<xs:enumeration value="investigate"/>
<xs:enumeration value="block-host"/>
<xs:enumeration value="block-network"/>
<xs:enumeration value="block-port"/>
<xs:enumeration value="rate-limit-host"/>
<xs:enumeration value="rate-limit-network"/>
<xs:enumeration value="rate-limit-port"/>
<xs:enumeration value="remediate-other"/>
<xs:enumeration value="status-triage"/>
<xs:enumeration value="status-new-info"/>
<xs:enumeration value="other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="action-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="nothing"/> <xs:enumeration value="contact-source-site"/> <xs:enumeration value="contact-target-site"/> <xs:enumeration value="contact-sender"/> <xs:enumeration value="investigate"/> <xs:enumeration value="block-host"/> <xs:enumeration value="block-network"/> <xs:enumeration value="block-port"/> <xs:enumeration value="rate-limit-host"/> <xs:enumeration value="rate-limit-network"/> <xs:enumeration value="rate-limit-port"/> <xs:enumeration value="remediate-other"/> <xs:enumeration value="status-triage"/> <xs:enumeration value="status-new-info"/> <xs:enumeration value="other"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="dtype-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="boolean"/>
<xs:enumeration value="byte"/>
<xs:enumeration value="character"/>
<xs:enumeration value="date-time"/>
<xs:enumeration value="integer"/>
<xs:enumeration value="ntpstamp"/>
<xs:enumeration value="portlist"/>
<xs:enumeration value="real"/>
<xs:enumeration value="string"/>
<xs:enumeration value="file"/>
<xs:enumeration value="path"/>
<xs:enumeration value="frame"/>
<xs:simpleType name="dtype-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="boolean"/> <xs:enumeration value="byte"/> <xs:enumeration value="character"/> <xs:enumeration value="date-time"/> <xs:enumeration value="integer"/> <xs:enumeration value="ntpstamp"/> <xs:enumeration value="portlist"/> <xs:enumeration value="real"/> <xs:enumeration value="string"/> <xs:enumeration value="file"/> <xs:enumeration value="path"/> <xs:enumeration value="frame"/>
Danyliw, et al. Standards Track [Page 86] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 86] RFC 5070 IODEF December 2007
<xs:enumeration value="packet"/>
<xs:enumeration value="ipv4-packet"/>
<xs:enumeration value="ipv6-packet"/>
<xs:enumeration value="url"/>
<xs:enumeration value="csv"/>
<xs:enumeration value="winreg"/>
<xs:enumeration value="xml"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<xs:enumeration value="packet"/> <xs:enumeration value="ipv4-packet"/> <xs:enumeration value="ipv6-packet"/> <xs:enumeration value="url"/> <xs:enumeration value="csv"/> <xs:enumeration value="winreg"/> <xs:enumeration value="xml"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:schema>
9. Security Considerations
9. Security Considerations
The IODEF data model itself does not directly introduce security issues. Rather, it simply defines a representation for incident information. As the data encoded by the IODEF might be considered privacy sensitive by the parties exchanging the information or by those described by it, care needs to be taken in ensuring the appropriate disclosure during both document exchange and subsequent processing. The former must be handled by a messaging format, but the latter risk must be addressed by the systems that process, store, and archive IODEF documents and information derived from them.
The IODEF data model itself does not directly introduce security issues. Rather, it simply defines a representation for incident information. As the data encoded by the IODEF might be considered privacy sensitive by the parties exchanging the information or by those described by it, care needs to be taken in ensuring the appropriate disclosure during both document exchange and subsequent processing. The former must be handled by a messaging format, but the latter risk must be addressed by the systems that process, store, and archive IODEF documents and information derived from them.
The contents of an IODEF document may include a request for action or an IODEF parser may independently have logic to take certain actions based on information that it finds. For this reason, care must be taken by the parser to properly authenticate the recipient of the document and ascribe an appropriate confidence to the data prior to action.
The contents of an IODEF document may include a request for action or an IODEF parser may independently have logic to take certain actions based on information that it finds. For this reason, care must be taken by the parser to properly authenticate the recipient of the document and ascribe an appropriate confidence to the data prior to action.
The underlying messaging format and protocol used to exchange instances of the IODEF MUST provide appropriate guarantees of confidentiality, integrity, and authenticity. The use of a standardized security protocol is encouraged. The Real-time Inter- network Defense (RID) protocol [18] and its associated transport binding IODEF/RID over SOAP [19] provide such security.
The underlying messaging format and protocol used to exchange instances of the IODEF MUST provide appropriate guarantees of confidentiality, integrity, and authenticity. The use of a standardized security protocol is encouraged. The Real-time Inter- network Defense (RID) protocol [18] and its associated transport binding IODEF/RID over SOAP [19] provide such security.
In order to suggest data processing and handling guidelines of the encoded information, the IODEF allows a document sender to convey a privacy policy using the restriction attribute. The various instances of this attribute allow different data elements of the document to be covered by dissimilar policies. While flexible, it must be stressed that this approach only serves as a guideline from the sender, as the recipient is free to ignore it. The issue of enforcement is not a technical problem.
In order to suggest data processing and handling guidelines of the encoded information, the IODEF allows a document sender to convey a privacy policy using the restriction attribute. The various instances of this attribute allow different data elements of the document to be covered by dissimilar policies. While flexible, it must be stressed that this approach only serves as a guideline from the sender, as the recipient is free to ignore it. The issue of enforcement is not a technical problem.
Danyliw, et al. Standards Track [Page 87] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 87] RFC 5070 IODEF December 2007
10. IANA Considerations
10. IANA Considerations
This document uses URNs to describe an XML namespace and schema conforming to a registry mechanism described in [15]
This document uses URNs to describe an XML namespace and schema conforming to a registry mechanism described in [15]
Registration for the IODEF namespace:
Registration for the IODEF namespace:
o URI: urn:ietf:params:xml:ns:iodef-1.0
o URI: urn:ietf:params:xml:ns:iodef-1.0
o Registrant Contact: See the first author of the "Author's Address"
section of this document.
o Registrant Contact: See the first author of the "Author's Address" section of this document.
o XML: None. Namespace URIs do not represent an XML specification.
o XML: None. Namespace URIs do not represent an XML specification.
Registration for the IODEF XML schema:
Registration for the IODEF XML schema:
o URI: urn:ietf:params:xml:schema:iodef-1.0
o URI: urn:ietf:params:xml:schema:iodef-1.0
o Registrant Contact: See the first author of the "Author's Address"
section of this document.
o Registrant Contact: See the first author of the "Author's Address" section of this document.
o XML: See the "IODEF Schema" in Section 8 of this document.
o XML: See the "IODEF Schema" in Section 8 of this document.
11. Acknowledgments
11. Acknowledgments
The following groups and individuals, listed alphabetically, contributed substantially to this document and should be recognized for their efforts.
The following groups and individuals, listed alphabetically, contributed substantially to this document and should be recognized for their efforts.
o Patrick Cain, Cooper-Cain Group, Inc.
o Patrick Cain, Cooper-Cain Group, Inc.
o The eCSIRT.net Project
o The eCSIRT.net Project
o The Incident Object Description and Exchange Format Working-Group
of the TERENA task-force (TF-CSIRT)
o The Incident Object Description and Exchange Format Working-Group of the TERENA task-force (TF-CSIRT)
o Glenn Mansfield Keeni, Cyber Solutions, Inc.
o Glenn Mansfield Keeni, Cyber Solutions, Inc.
o Hiroyuki Kido, NARA Institute of Science and Technology
o Hiroyuki Kido, NARA Institute of Science and Technology
o Kathleen Moriarty, MIT Lincoln Laboratory
o Kathleen Moriarty, MIT Lincoln Laboratory
o Brian Trammell, CERT/NetSA
o Brian Trammell, CERT/NetSA
Danyliw, et al. Standards Track [Page 88] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 88] RFC 5070 IODEF December 2007
12. References
12. References
12.1. Normative References
12.1. Normative References
[1] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0 (Second Edition)", W3C Recommendation , October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation , October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[2] World Wide Web Consortium, "XML XML Schema Part 1: Structures
Second Edition", W3C Recommendation , October 2004,
<http://www.w3.org/TR/xmlschema-1/>.
[2] World Wide Web Consortium, "XML XML Schema Part 1: Structures Second Edition", W3C Recommendation , October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second
Edition", W3C Recommendation , October 2004,
<http://www.w3.org/TR/xmlschema-2/>.
[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation , October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[4] World Wide Web Consortium, "Namespaces in XML", W3C
Recommendation , January 1999,
<http://www.w3.org/TR/REC-xml-names/>.
[4] World Wide Web Consortium, "Namespaces in XML", W3C Recommendation , January 1999, <http://www.w3.org/TR/REC-xml-names/>.
[5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C
Candidate Recommendation , June 2006,
<http://www.w3.org/TR/xpath20/>.
[5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C Candidate Recommendation , June 2006, <http://www.w3.org/TR/xpath20/>.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[7] Philips, A. and M. Davis, "Tags for Identifying of Languages",
RFC 4646, September 2006.
[7] Philips, A. and M. Davis, "Tags for Identifying of Languages", RFC 4646, September 2006.
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005`.
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005`.
[9] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 2978, October 2000.
[9] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 2978, October 2000.
[10] Sciberras, A., "Schema for User Applications", RFC 4519,
June 2006.
[10] Sciberras, A., "Schema for User Applications", RFC 4519, June 2006.
[11] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[11] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[12] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[12] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
Danyliw, et al. Standards Track [Page 89] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 89] RFC 5070 IODEF December 2007
[13] International Organization for Standardization, "International
Standard: Data elements and interchange formats - Information
interchange - Representation of dates and times", ISO 8601,
Second Edition, December 2000.
[13] International Organization for Standardization, "International Standard: Data elements and interchange formats - Information interchange - Representation of dates and times", ISO 8601, Second Edition, December 2000.
[14] International Organization for Standardization, "International
Standard: Codes for the representation of currencies and funds,
ISO 4217:2001", ISO 4217:2001, August 2001.
[14] International Organization for Standardization, "International Standard: Codes for the representation of currencies and funds, ISO 4217:2001", ISO 4217:2001, August 2001.
[15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
12.2. Informative References
12.2. Informative References
[16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the
Format for Incident Information Exchange (FINE)", Work
in Progress, June 2006.
[16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the Format for Incident Information Exchange (FINE)", Work in Progress, June 2006.
[17] Debar, H., Curry, D., Debar, H., and B. Feinstein, "Intrusion
Detection Message Exchange Format", RFC 4765, March 2007.
[17] Debar, H., Curry, D., Debar, H., and B. Feinstein, "Intrusion Detection Message Exchange Format", RFC 4765, March 2007.
[18] Moriarty, K., "Real-time Inter-network Defense", Work
in Progress, April 2007.
[18] Moriarty, K., "Real-time Inter-network Defense", Work in Progress, April 2007.
[19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work
in Progress, April 2007.
[19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work in Progress, April 2007.
[20] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) File", RFC 4180, October 2005.
[20] Shafranovich, Y., "Common Format and MIME Type for Comma- Separated Values (CSV) File", RFC 4180, October 2005.
Danyliw, et al. Standards Track [Page 90] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 90] RFC 5070 IODEF December 2007
Authors' Addresses
Authors' Addresses
Roman Danyliw CERT - Software Engineering Institute Pittsburgh, PA USA
Roman Danyliw CERT - Software Engineering Institute Pittsburgh, PA USA
EMail: rdd@cert.org
EMail: rdd@cert.org
Jan Meijer
Jan Meijer
EMail: jan@flyingcloggies.nl
EMail: jan@flyingcloggies.nl
Yuri Demchenko University of Amsterdam Amsterdam Netherlands
Yuri Demchenko University of Amsterdam Amsterdam Netherlands
EMail: demch@chello.nl
EMail: demch@chello.nl
Danyliw, et al. Standards Track [Page 91] RFC 5070 IODEF December 2007
Danyliw, et al. Standards Track [Page 91] RFC 5070 IODEF December 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Danyliw, et al. Standards Track [Page 92]
Danyliw, et al. Standards Track [Page 92]
一覧
スポンサーリンク
