draft-ietf-mile-rfc5070-bis-00.txt   draft-ietf-mile-rfc5070-bis-01.txt 
Extended Incident Handling Working R. Danyliw MILE Working Group R. Danyliw
Group CERT Internet-Draft CERT
Internet-Draft P. Stoecker Obsoletes: 5070 (if approved) P. Stoecker
Obsoletes: 5070 (if approved) RSA Intended status: Standards Track RSA
Intended status: Informational May 5, 2013 Expires: March 02, 2014 August 29, 2013
Expires: November 6, 2013
The Incident Object Description Exchange Format The Incident Object Description Exchange Format v2
draft-ietf-mile-rfc5070-bis-00 draft-ietf-mile-rfc5070-bis-01
Abstract Abstract
The Incident Object Description Exchange Format (IODEF) defines a The Incident Object Description Exchange Format (IODEF) defines a
data representation that provides a framework for sharing information data representation that provides a framework for sharing information
commonly exchanged by Computer Security Incident Response Teams commonly exchanged by Computer Security Incident Response Teams
(CSIRTs) about computer security incidents. This document describes (CSIRTs) about computer security incidents. This document describes
the information model for the IODEF and provides an associated data the information model for the IODEF and provides an associated data
model specified with XML Schema. model specified with XML Schema.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2013. This Internet-Draft will expire on March 02, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes from 5070 . . . . . . . . . . . . . . . . . . . . 5 1.1. Changes from 5070 . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. About the IODEF Data Model . . . . . . . . . . . . . . . 6 1.4. About the IODEF Data Model . . . . . . . . . . . . . . . 6
1.5. About the IODEF Implementation . . . . . . . . . . . . . 7 1.5. About the IODEF Implementation . . . . . . . . . . . . . 7
2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 7 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Characters and Strings . . . . . . . . . . . . . . . . . 8 2.3. Characters and Strings . . . . . . . . . . . . . . . . . 8
2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . 8 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . 8
2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 8 2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 8
2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . 8 2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . 9
2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 9 2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 9
2.9. Timezone String . . . . . . . . . . . . . . . . . . . . . 9 2.9. Timezone String . . . . . . . . . . . . . . . . . . . . . 9
2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 9 2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 9
2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . 9 2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . 10
2.12. Person or Organization . . . . . . . . . . . . . . . . . 9 2.12. Person or Organization . . . . . . . . . . . . . . . . . 10
2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 10 2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 10
2.14. Email String . . . . . . . . . . . . . . . . . . . . . . 10 2.14. Email String . . . . . . . . . . . . . . . . . . . . . . 10
2.15. Uniform Resource Locator strings . . . . . . . . . . . . 10 2.15. Uniform Resource Locator strings . . . . . . . . . . . . 10
3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . 10 3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . 10
3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 10 3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 11
3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 11 3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 11
3.3. IncidentID Class . . . . . . . . . . . . . . . . . . . . 14 3.3. IncidentID Class . . . . . . . . . . . . . . . . . . . . 15
3.4. AlternativeID Class . . . . . . . . . . . . . . . . . . . 15 3.4. AlternativeID Class . . . . . . . . . . . . . . . . . . . 16
3.5. RelatedActivity Class . . . . . . . . . . . . . . . . . . 16 3.5. RelatedActivity Class . . . . . . . . . . . . . . . . . . 16
3.6. AdditionalData Class . . . . . . . . . . . . . . . . . . 16 3.6. AdditionalData Class . . . . . . . . . . . . . . . . . . 17
3.7. Contact Class . . . . . . . . . . . . . . . . . . . . . . 19 3.7. Contact Class . . . . . . . . . . . . . . . . . . . . . . 19
3.7.1. RegistryHandle Class . . . . . . . . . . . . . . . . 21 3.7.1. RegistryHandle Class . . . . . . . . . . . . . . . . 22
3.7.2. PostalAddress Class . . . . . . . . . . . . . . . . . 22 3.7.2. PostalAddress Class . . . . . . . . . . . . . . . . . 22
3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 23 3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 23
3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23 3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23
3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . 24 3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . 24
3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24 3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24 3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . 24 3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . 24
3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . 25 3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . 25
3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 25 3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 25
3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . 25 3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 4 skipping to change at page 3, line 15
3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 23 3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 23
3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23 3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23
3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . 24 3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . 24
3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24 3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24 3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . 24 3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . 24
3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . 25 3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . 25
3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 25 3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . 25
3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . 25 3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . 25
3.9.1. Reference Class . . . . . . . . . . . . . . . . . . . 26 3.9.1. Reference Class . . . . . . . . . . . . . . . . . . . 26
3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . 27 3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . 27
3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . 28 3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . 28
3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . 30 3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . 30
3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . 32 3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . 32
3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . 33 3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . 32
3.11. History Class . . . . . . . . . . . . . . . . . . . . . . 34 3.11. History Class . . . . . . . . . . . . . . . . . . . . . . 33
3.11.1. HistoryItem Class . . . . . . . . . . . . . . . . . . 34 3.11.1. HistoryItem Class . . . . . . . . . . . . . . . . . 34
3.12. EventData Class . . . . . . . . . . . . . . . . . . . . . 36 3.12. EventData Class . . . . . . . . . . . . . . . . . . . . . 35
3.12.1. Relating the Incident and EventData Classes . . . . . 38 3.12.1. Relating the Incident and EventData Classes . . . . 37
3.12.2. Cardinality of EventData . . . . . . . . . . . . . . 38 3.12.2. Cardinality of EventData . . . . . . . . . . . . . . 38
3.13. Expectation Class . . . . . . . . . . . . . . . . . . . . 39 3.13. Expectation Class . . . . . . . . . . . . . . . . . . . . 39
3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 41 3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 41
3.15. System Class . . . . . . . . . . . . . . . . . . . . . . 42 3.15. System Class . . . . . . . . . . . . . . . . . . . . . . 42
3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . 44 3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . 44
3.16.1. Counter Class . . . . . . . . . . . . . . . . . . . . 45 3.16.1. Counter Class . . . . . . . . . . . . . . . . . . . 45
3.16.2. Address Class . . . . . . . . . . . . . . . . . . . . 47 3.16.2. Address Class . . . . . . . . . . . . . . . . . . . 46
3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . 48 3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . 48
3.17. Service Class . . . . . . . . . . . . . . . . . . . . . . 50 3.17. Service Class . . . . . . . . . . . . . . . . . . . . . . 50
3.17.1. Application Class . . . . . . . . . . . . . . . . . . 52 3.17.1. Application Class . . . . . . . . . . . . . . . . . 51
3.18. OperatingSystem Class . . . . . . . . . . . . . . . . . . 53 3.18. OperatingSystem Class . . . . . . . . . . . . . . . . . . 53
3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . 53 3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . 53
3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . 53 3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . 53
3.19.2. RecordPattern Class . . . . . . . . . . . . . . . . . 55 3.19.2. RecordPattern Class . . . . . . . . . . . . . . . . 55
3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . 56 3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . 56
3.20. Registry Key Modified Class . . . . . . . . . . . . . . . 56 3.20. RegistryKeyModified Class . . . . . . . . . . . . . . . . 56
3.20.1. Key Class . . . . . . . . . . . . . . . . . . . . . . 57 3.20.1. Key Class . . . . . . . . . . . . . . . . . . . . . 57
3.21. Hash Sig Details Class . . . . . . . . . . . . . . . . . 58 3.21. HashInformation Class . . . . . . . . . . . . . . . . . . 58
4. Processing Considerations . . . . . . . . . . . . . . . . . . 60 4. Processing Considerations . . . . . . . . . . . . . . . . . . 59
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 60 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 61 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 60
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 61 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 60
5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 62 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 61
5.1. Extending the Enumerated Values of Attributes . . . . . . 62 5.1. Extending the Enumerated Values of Attributes . . . . . . 62
5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 63 5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 62
6. Internationalization Issues . . . . . . . . . . . . . . . . . 65 6. Internationalization Issues . . . . . . . . . . . . . . . . . 64
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 67 7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 67
7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 69 7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 69
7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . 71 7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . 71
8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . 72 8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . 72
9. Security Considerations . . . . . . . . . . . . . . . . . . . 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 104
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 105
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.1. Normative References . . . . . . . . . . . . . . . . . . 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 106
12.2. Informative References . . . . . . . . . . . . . . . . . 106 12.2. Informative References . . . . . . . . . . . . . . . . . 107
1. Introduction 1. Introduction
Organizations require help from other parties to mitigate malicious Organizations require help from other parties to mitigate malicious
activity targeting their network and to gain insight into potential activity targeting their network and to gain insight into potential
threats. This coordination might entail working with an ISP to threats. This coordination might entail working with an ISP to
filter attack traffic, contacting a remote site to take down a bot- filter attack traffic, contacting a remote site to take down a bot-
network, or sharing watch-lists of known malicious IP addresses in a network, or sharing watch-lists of known malicious IP addresses in a
consortium. consortium.
The Incident Object Description Exchange Format (IODEF) is a format The Incident Object Description Exchange Format (IODEF) is a format
for representing computer security information commonly exchanged for representing computer security information commonly exchanged
between Computer Security Incident Response Teams (CSIRTs). It between Computer Security Incident Response Teams (CSIRTs). It
provides an XML representation for conveying incident information provides an XML representation for conveying:
across administrative domains between parties that have an
operational responsibility of remediation or a watch-and-warning over o cyber intelligence to characterize threats;
a defined constituency. The data model encodes information about
hosts, networks, and the services running on these systems; attack o cyber incident reports to document particular cyber security
methodology and associated forensic evidence; impact of the activity; events or relationships between events;
and limited approaches for documenting workflow.
o cyber event mitigation to request proactive and reactive
mitigation approaches to cyber intelligence or incidents; and
o cyber information sharing meta-data so that these various classes
of information can be exchanged among parties.
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.
The overriding purpose of the IODEF is to enhance the operational The overriding purpose of the IODEF is to enhance the operational
capabilities of CSIRTs. Community adoption of the IODEF provides an capabilities of CSIRTs. Community adoption of the IODEF provides an
improved ability to resolve incidents and convey situational improved ability to resolve incidents and convey situational
awareness by simplifying collaboration and data sharing. This awareness by simplifying collaboration and data sharing. This
structured format provided by the IODEF allows for: structured format provided by the IODEF allows for:
o increased automation in processing of incident data, since the o increased automation in processing of incident data, since the
resources of security analysts to parse free-form textual resources of security analysts to parse free-form textual
documents will be reduced; documents will be reduced;
skipping to change at page 5, line 4 skipping to change at page 5, line 27
There are numerous procedural, trust, and legal considerations that There are numerous procedural, trust, and legal considerations that
might prevent an organization from sharing information. The IODEF might prevent an organization from sharing information. The IODEF
does not attempt to address them. However, operational does not attempt to address them. However, operational
implementations of the IODEF will need to consider this broader implementations of the IODEF will need to consider this broader
context. context.
Sections 3 and 8 specify the IODEF data model with text and an XML 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. schema. The types used by the data model are covered in Section 2.
Processing considerations, the handling of extensions, and Processing considerations, the handling of extensions, and
internationalization issues related to the data model are covered in internationalization issues related to the data model are covered in
Sections 4, 5, and 6, respectively. Examples are listed in Section Sections 4, 5, and 6, respectively. Examples are listed in
7. Section 1 provides the background for the IODEF, and Section 9 Section 7. Section 1 provides the background for the IODEF, and
documents the security considerations. Section 9 documents the security considerations.
1.1. Changes from 5070 1.1. Changes from 5070
o This document contains changes with respect to its predecessor This document contains changes with respect to its predecessor
RFC5070: RFC5070.
o All of the Errata that has been submitted at RFC5070 Errata has
been implemented.
o Addition of xmlns:ds and import of same namespace. This is to use o All of the RFC5070 Errata was implemented.
the digital signature hash inclusion of a file by referencing the
existing standard as was done in RFC5901, RFC3275 is the
reference, see RFC5901 section 5.9.5.2">
o New indicator uid and set id values in the schema. The purpose of o Imported the xmlns:ds namespace to include digital signature hash
the proposed changes is to include commonly shared indicators in classes.
the base IODEF schema. This class will contain indicators from
the list below that are not represented elsewhere in the schema.
IODEF extensions or embedded schemas via the SCI classes will be
required to include additional data types. A table could be
maintained through IANA to extend or change this class in between
IODEF revisions.
o RFC5901 provides a method to include an entire email, the o The attributes @indicator-uid and @indicator-set-id were added to
following included indicators are ones commonly used when you do various classes to reference commonly shared indicators.
not need the entire email
o The following are in the Service class: Email Address, Email o The following classes were added to the Service class: Email,
Subject, and X-Mailer EmailSubject, X-Mailer, and DomainData.
o The following are in the Record class: File Name, File Hash o The following classes were added to the Record class: FileName,
(5.9.5.2 - using ds:reference), and WindowsRegistryKey (using ds:Reference, and WindowsRegistryKeysModified.
method from RFC5901
o The following are now in the Node class as a proposed location: o (for consideration) The following class was added to the Node
URL class: URL.
o HTTPUserAgent is included as a SoftwareType - HTTP User Agent o (for consideration) The following attributes was added to the
String SoftwareType complexType: user-agent.
o The following are already represented elsewhere in the schema o Additional enumerated values were added to the following
(Node): IP address, Network CIDR / ASN, Host Name, and Domain Name attributes: @restriction, {Expectation, HistoryItem}@action, and
(additional options for RFC5901 were not included in this revision NodeRole@category.
- can include point-in-time dig info)
1.2. Terminology 1.2. Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [6]. document are to be interpreted as described in RFC2119 [6].
Definitions for some of the common computer security-related Definitions for some of the common computer security-related
terminology used in this document can be found in Section 2 of [16]. terminology used in this document can be found in Section 2 of [16].
1.3. Notations 1.3. Notations
The normative IODEF data model is specified with the text in Section The normative IODEF data model is specified with the text in
3 and the XML schema in Section 8. To help in the understanding of Section 3 and the XML schema in Section 8. To help in the
the data elements, Section 3 also depicts the underlying information understanding of the data elements, Section 3 also depicts the
model using Unified Modeling Language (UML). This abstract underlying information model using Unified Modeling Language (UML).
presentation of the IODEF is not normative. This abstract presentation of the IODEF is not normative.
For clarity in this document, the term "XML document" will be used For clarity in this document, the term "XML document" will be used
when referring generically to any instance of an XML document. The when referring generically to any instance of an XML document. The
term "IODEF document" will be used to refer to specific elements and term "IODEF document" will be used to refer to specific elements and
attributes of the IODEF schema. The terms "class" and "element" will attributes of the IODEF schema. The terms "class" and "element" will
be used interchangeably to reference either the corresponding data be used interchangeably to reference either the corresponding data
element in the information or data models, respectively. element in the information or data models, respectively.
1.4. About the IODEF Data Model 1.4. About the IODEF Data Model
skipping to change at page 9, line 11 skipping to change at page 9, line 24
The ENUM data type is implemented as a series of "xs:NMTOKEN" in the The ENUM data type is implemented as a series of "xs:NMTOKEN" in the
schema. schema.
2.8. Date-Time Strings 2.8. Date-Time Strings
Date-time strings are represented by the DATETIME data type. Each Date-time strings are represented by the DATETIME data type. Each
date-time string identifies a particular instant in time; ranges are date-time string identifies a particular instant in time; ranges are
not supported. not supported.
Date-time strings are formatted according to a subset of ISO 8601: Date-time strings are formatted according to a subset of ISO
2000 [13] documented in RFC 3339 [12]. 8601:2000 [13] documented in RFC 3339 [12].
The DATETIME data type is implemented as an "xs:dateTime" [3] in the The DATETIME data type is implemented as an "xs:dateTime" [3] in the
schema. schema.
2.9. Timezone String 2.9. Timezone String
A timezone offset from UTC is represented by the TIMEZONE data type. A timezone offset from UTC is represented by the TIMEZONE data type.
It is formatted according to the following regular expression: It is formatted according to the following regular expression:
"Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".
The TIMEZONE data type is implemented as an "xs:string" with a The TIMEZONE data type is implemented as an "xs:string" with a
regular expression constraint in the schema. This regular expression regular expression constraint in the schema. This regular expression
is identical to the timezone representation implemented in an "xs: is identical to the timezone representation implemented in an
dateTime". "xs:dateTime".
2.10. Port Lists 2.10. Port Lists
A list of network ports are represented by the PORTLIST data type. A A list of network ports are represented by the PORTLIST data type. A
PORTLIST consists of a comma-separated list of numbers and ranges PORTLIST consists of a comma-separated list of numbers and ranges
(N-M means ports N through M, inclusive). It is formatted according (N-M means ports N through M, inclusive). It is formatted according
to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*".
For example, "2,5-15,30,32,40-50,55-60". For example, "2,5-15,30,32,40-50,55-60".
The PORTLIST data type is implemented as an "xs:string" with a The PORTLIST data type is implemented as an "xs:string" with a
skipping to change at page 11, line 15 skipping to change at page 11, line 30
The aggregate class that constitute IODEF-Document is: The aggregate class that constitute IODEF-Document is:
Incident Incident
One or more. The information related to a single incident. One or more. The information related to a single incident.
The IODEF-Document class has three attributes: The IODEF-Document class has three attributes:
version version
Required. STRING. The IODEF specification version number to Required. STRING. The IODEF specification version number to
which this IODEF document conforms. The value of this attribute which this IODEF document conforms. The value of this attribute
MUST be "1.00" MUST be "2.00"
lang lang
Required. ENUM. A valid language code per RFC 4646 [7] Required. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6. interpretation of this code is described in Section 6.
formatid formatid
Optional. STRING. A free-form string to convey processing Optional. STRING. A free-form string to convey processing
instructions to the recipient of the document. Its semantics must instructions to the recipient of the document. Its semantics must
be negotiated out-of-band. be negotiated out-of-band.
skipping to change at page 12, line 4 skipping to change at page 12, line 17
| |<>--{0..1}--[ EndTime ] | |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ] | |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ] | |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ] | |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ] | |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ] | |<>--{0..*}--[ EventData ]
| |<>--{0..1}--[ History ] | |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+--------------------+ +--------------------+
Figure 2: The Incident Class Figure 2: The Incident Class
The aggregate classes that constitute Incident are: The aggregate classes that constitute Incident are:
IncidentID IncidentID
One. An incident tracking number assigned to this incident by the One. An incident tracking number assigned to this incident by the
CSIRT that generated the IODEF document. CSIRT that generated the IODEF document.
AlternativeID AlternativeID
Zero or one. The incident tracking numbers used by other CSIRTs Zero or one. The incident tracking numbers used by other CSIRTs
to refer to the incident described in the document. to refer to the incident described in the document.
RelatedActivity RelatedActivity
Zero or one. The incident tracking numbers of related incidents. Zero or one. The incident tracking numbers of related incidents.
DetectTime DetectTime
Zero or one. The time the incident was first detected. Zero or one. The time the incident was first detected.
StartTime StartTime
Zero or one. The time the incident started. Zero or one. The time the incident started.
EndTime EndTime
Zero or one. The time the incident ended. Zero or one. The time the incident ended.
ReportTime ReportTime
One. The time the incident was reported. One. The time the incident was reported.
Description Description
Zero or more. ML_STRING. A free-form textual description of the Zero or more. ML_STRING. A free-form textual description of the
incident. incident.
Assessment Assessment
One or more. A characterization of the impact of the incident. One or more. A characterization of the impact of the incident.
Method Method
Zero or more. The techniques used by the intruder in the Zero or more. The techniques used by the intruder in the
skipping to change at page 14, line 25 skipping to change at page 14, line 33
selectively apply more rigid controls). The implicit value of the selectively apply more rigid controls). The implicit value of the
restriction attribute for a class that did not specify one can be restriction attribute for a class that did not specify one can be
found in the closest ancestor that did specify a value. found in the closest ancestor that did specify a value.
This attribute is defined as an enumerated value with a default This attribute is defined as an enumerated value with a default
value of "private". Note that the default value of the value of "private". Note that the default value of the
restriction attribute is only defined in the context of the restriction attribute is only defined in the context of the
Incident class. In other classes where this attribute is used, no Incident class. In other classes where this attribute is used, no
default is specified. default is specified.
1. public. There are no restrictions placed in the information. 1. public. The information can be freely distributed without
restriction.
2. need-to-know. The information may be shared with other 2. partner. The information may be shared within a closed
parties that are involved in the incident as determined by the community of peers, partners, or affected parties, but cannot
recipient of this document (e.g., multiple victim sites can be be openly published.
informed of each other).
3. private. The information may not be shared. 3. need-to-know. The information may be shared only within the
organization with individuals that have a need to know.
4. default. The information can be shared according to an 4. private. The information may not be shared.
5. default. The information can be shared according to an
information disclosure policy pre-arranged by the information disclosure policy pre-arranged by the
communicating parties. communicating parties.
5. 6. white. Same as 'public'.
Optional. STRING. The indicator set ID is used to group
releated indicators. 7. green. Same as 'partner'.
8. amber. Same as 'need-to-know'.
9. red. Same as 'private'.
indicator-set-id
Optional. STRING. The indicator set ID is used to group related
indicators.
3.3. IncidentID Class 3.3. IncidentID Class
The IncidentID class represents an incident tracking number that is The IncidentID class represents an incident tracking number that is
unique in the context of the CSIRT and identifies the activity unique in the context of the CSIRT and identifies the activity
characterized in an IODEF Document. This identifier would serve as characterized in an IODEF Document. This identifier would serve as
an index into the CSIRT incident handling system. The combination of an index into the CSIRT incident handling system. The combination of
the name attribute and the string in the element content MUST be a the name attribute and the string in the element content MUST be a
globally unique identifier describing the activity. Documents globally unique identifier describing the activity. Documents
generated by a given CSIRT MUST NOT reuse the same value unless they generated by a given CSIRT MUST NOT reuse the same value unless they
skipping to change at page 15, line 40 skipping to change at page 16, line 12
Optional. ENUM. This attribute has been defined in Section 3.2. Optional. ENUM. This attribute has been defined in Section 3.2.
The default value is "public". The default value is "public".
3.4. AlternativeID Class 3.4. AlternativeID Class
The AlternativeID class lists the incident tracking numbers used by The AlternativeID class lists the incident tracking numbers used by
CSIRTs, other than the one generating the document, to refer to the CSIRTs, other than the one generating the document, to refer to the
identical activity described the IODEF document. A tracking number identical activity described the IODEF document. A tracking number
listed as an AlternativeID references the same incident detected by listed as an AlternativeID references the same incident detected by
another CSIRT. The incident tracking numbers of the CSIRT that another CSIRT. The incident tracking numbers of the CSIRT that
generated the IODEF document should never be considered an generated the IODEF document must never be considered an
AlternativeID. AlternativeID.
+------------------+ +------------------+
| AlternativeID | | AlternativeID |
+------------------+ +------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ] | ENUM restriction |<>--{1..*}--[ IncidentID ]
| | | |
+------------------+ +------------------+
Figure 4: The AlternativeID Class Figure 4: The AlternativeID Class
The aggregate class that constitutes AlternativeID is: The aggregate class that constitutes AlternativeID is:
IncidentID IncidentID
One or more. The incident tracking number of another CSIRT. One or more. The incident tracking number of another CSIRT.
The AlternativeID class has one attribute: The AlternativeID class has one attribute:
skipping to change at page 16, line 25 skipping to change at page 16, line 44
3.5. RelatedActivity Class 3.5. RelatedActivity Class
The RelatedActivity class lists either incident tracking numbers of The RelatedActivity class lists either incident tracking numbers of
incidents or URLs (not both) that refer to activity related to the incidents or URLs (not both) that refer to activity related to the
one described in the IODEF document. These references may be to one described in the IODEF document. These references may be to
local incident tracking numbers or to those of other CSIRTs. local incident tracking numbers or to those of other CSIRTs.
The specifics of how a CSIRT comes to believe that two incidents are The specifics of how a CSIRT comes to believe that two incidents are
related are considered out of scope. related are considered out of scope.
+------------------+ +------------------+
| RelatedActivity | | RelatedActivity |
+------------------+ +------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ] | ENUM restriction |<>--{1..*}--[ IncidentID ]
| |<>--{1..*}--[ URL ] | |<>--{1..*}--[ URL ]
+------------------+ +------------------+
Figure 5: RelatedActivity Class Figure 5: RelatedActivity Class
The aggregate classes that constitutes RelatedActivity are: The aggregate classes that constitutes RelatedActivity are:
IncidentID IncidentID
One or more. The incident tracking number of a related incident. One or more. The incident tracking number of a related incident.
URL URL
One or more. URL. A URL to activity related to this incident. One or more. URL. A URL to activity related to this incident.
skipping to change at page 24, line 47 skipping to change at page 25, line 4
3.8.1. StartTime 3.8.1. StartTime
The StartTime class represents the time the incident began. The StartTime class represents the time the incident began.
3.8.2. EndTime 3.8.2. EndTime
The EndTime class represents the time the incident ended. The EndTime class represents the time the incident ended.
3.8.3. DetectTime 3.8.3. DetectTime
The DetectTime class represents the time the first activity of the The DetectTime class represents the time the first activity of the
incident was detected. incident was detected.
3.8.4. ReportTime 3.8.4. ReportTime
The ReportTime class represents the time the incident was reported. The ReportTime class represents the time the incident was reported.
This timestamp SHOULD coincide to the time at which the IODEF This timestamp MUST be the time at which the IODEF document was
document is generated. generated.
3.8.5. DateTime 3.8.5. DateTime
The DateTime class is a generic representation of a timestamp. Its The DateTime class is a generic representation of a timestamp. Infer
semantics should be inferred from the parent class in which it is its semantics from the parent class in which it is aggregated.
aggregated.
3.9. Method Class 3.9. Method Class
The Method class describes the methodology used by the intruder to The Method class describes the methodology used by the intruder to
perpetrate the events of the incident. This class consists of a list perpetrate the events of the incident. This class consists of a list
of references describing the attack method and a free form of references describing the attack method and a free form
description of the technique. description of the technique.
+------------------+ +------------------+
| Method | | Method |
skipping to change at page 26, line 27 skipping to change at page 26, line 27
| |<>----------[ ReferenceName ] | |<>----------[ ReferenceName ]
| |<>--{0..*}--[ URL ] | |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
+------------------+ +------------------+
Figure 14: The Reference Class Figure 14: The Reference Class
The aggregate classes that constitute Reference: The aggregate classes that constitute Reference:
ReferenceName ReferenceName
One. ML_STRING. Name of the reference. One. ML_STRING. Name of the reference.
URL URL
Zero or many. URL. A URL associated with the reference. Zero or many. URL. A URL associated with the reference.
Description Description
Zero or many. ML_STRING. A free-form text description of this Zero or many. ML_STRING. A free-form text description of this
reference. reference.
The Reference class has 4 attributes. The Reference class has 4 attributes.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group Optional. STRING. The indicator set ID is used to group
releated indicators. releated indicators.
attacktype attacktype
Optional. ENUM. A unique identifier for an Indicator. Optional. ENUM. A unique identifier for an Indicator.
ext-attacktype ext-attacktype
Optional. STRING. A mechanism by which to extend the Attack Optional. STRING. A mechanism by which to extend the
Type. Attack Type.
3.10. Assessment Class 3.10. Assessment Class
The Assessment class describes the technical and non-technical The Assessment class describes the technical and non-technical
repercussions of the incident on the CSIRT's constituency. repercussions of the incident on the CSIRT's constituency.
This class was derived from the IDMEF[17]. This class was derived from the IDMEF[17].
+------------------+ +------------------+
| Assessment | | Assessment |
+------------------+ +------------------+
| ENUM occurrence |<>--{0..*}--[ Impact ] | ENUM occurrence |<>--{0..*}--[ Impact ]
| ENUM restriction |<>--{0..*}--[ TimeImpact ] | ENUM restriction |<>--{0..*}--[ TimeImpact ]
| |<>--{0..*}--[ MonetaryImpact ] | |<>--{0..*}--[ MonetaryImpact ]
| |<>--{0..*}--[ Counter ] | |<>--{0..*}--[ Counter ]
| |<>--{0..1}--[ Confidence ] | |<>--{0..1}--[ Confidence ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+------------------+ +------------------+
Figure 15: Assessment Class Figure 15: Assessment Class
The aggregate classes that constitute Assessment are: The aggregate classes that constitute Assessment are:
Impact Impact
Zero or many. Technical impact of the incident on a network. Zero or many. Technical impact of the incident on a network.
TimeImpact TimeImpact
Zero or many. Impact of the activity measured with respect to Zero or many. Impact of the activity measured with respect to
skipping to change at page 28, line 21 skipping to change at page 28, line 21
2. potential. This assessment describes potential activity that 2. potential. This assessment describes potential activity that
might occur. might occur.
restriction restriction
Optional. ENUM. This attribute is defined in Section 3.2. Optional. ENUM. This attribute is defined in Section 3.2.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
3.10.1. Impact Class 3.10.1. Impact Class
The Impact class allows for categorizing and describing the technical The Impact class allows for categorizing and describing the technical
impact of the incident on the network of an organization. impact of the incident on the network of an organization.
This class is based on the IDMEF [17]. This class is based on the IDMEF [17].
+------------------+ +------------------+
skipping to change at page 32, line 17 skipping to change at page 32, line 13
attribute. See Section 5.1. attribute. See Section 5.1.
3.10.3. MonetaryImpact Class 3.10.3. MonetaryImpact Class
The MonetaryImpact class describes the financial impact of the The MonetaryImpact class describes the financial impact of the
activity on an organization. For example, this impact may consider activity on an organization. For example, this impact may consider
losses due to the cost of the investigation or recovery, diminished losses due to the cost of the investigation or recovery, diminished
productivity of the staff, or a tarnished reputation that will affect productivity of the staff, or a tarnished reputation that will affect
future opportunities. future opportunities.
+------------------+ +------------------+
| MonetaryImpact | | MonetaryImpact |
+------------------+ +------------------+
| REAL | | REAL |
| | | |
| ENUM severity | | ENUM severity |
| STRING currency | | STRING currency |
+------------------+ +------------------+
Figure 18: MonetaryImpact Class Figure 18: MonetaryImpact Class
The element content is a positive, floating point number (REAL) The element content is a positive, floating point number (REAL)
specifying a unit of currency described in the currency attribute. specifying a unit of currency described in the currency attribute.
The MonetaryImpact class has two attributes: The MonetaryImpact class has two attributes:
severity severity
Optional. ENUM. An estimate of the relative severity of the Optional. ENUM. An estimate of the relative severity of the
skipping to change at page 33, line 26 skipping to change at page 33, line 19
+------------------+ +------------------+
| REAL | | REAL |
| | | |
| ENUM rating | | ENUM rating |
+------------------+ +------------------+
Figure 19: Confidence Class Figure 19: Confidence Class
The element content expresses a numerical assessment in the The element content expresses a numerical assessment in the
confidence of the data when the value of the rating attribute is confidence of the data when the value of the rating attribute is
"numeric". Otherwise, this element should be empty. "numeric". Otherwise, this element MUST be empty.
The Confidence class has one attribute. The Confidence class has one attribute.
rating rating
Required. ENUM. A rating of the analytical validity of the Required. ENUM. A rating of the analytical validity of the
specified Assessment. The permitted values are shown below. specified Assessment. The permitted values are shown below.
There is no default value. There is no default value.
1. low. Low confidence in the validity. 1. low. Low confidence in the validity.
skipping to change at page 35, line 20 skipping to change at page 34, line 45
| STRING ext-action |<>--{0..1}--[ Contact ] | STRING ext-action |<>--{0..1}--[ Contact ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+-------------------+ +-------------------+
Figure 21: HistoryItem Class Figure 21: HistoryItem Class
The aggregate classes that constitute HistoryItem are: The aggregate classes that constitute HistoryItem are:
DateTime DateTime
One. Timestamp of this entry in the history log (e.g., when the One. Timestamp of this entry in the history log (e.g., when the
action described in the Description was taken). action described in the Description was taken).
IncidentID IncidentID
Zero or One. In a history log created by multiple parties, the Zero or One. In a history log created by multiple parties, the
IncidentID provides a mechanism to specify which CSIRT created a IncidentID provides a mechanism to specify which CSIRT created a
particular entry and references this organization's incident particular entry and references this organization's incident
tracking number. When a single organization is maintaining the tracking number. When a single organization is maintaining the
log, this class can be ignored. log, this class can be ignored.
Contact Contact
Zero or One. Provides contact information for the person that Zero or One. Provides contact information for the person that
performed the action documented in this class. performed the action documented in this class.
Description Description
Zero or many. ML_STRING. A free-form textual description of the Zero or many. ML_STRING. A free-form textual description of the
action or event. action or event.
AdditionalData AdditionalData
Zero or many. A mechanism by which to extend the data model. Zero or many. A mechanism by which to extend the data model.
The HistoryItem class has five attributes: The HistoryItem class has five attributes:
skipping to change at page 36, line 14 skipping to change at page 35, line 40
it has been completed. See Section 3.13. it has been completed. See Section 3.13.
ext-action ext-action
Optional. STRING. A means by which to extend the action Optional. STRING. A means by which to extend the action
attribute. See Section 5.1. attribute. See Section 5.1.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
3.12. EventData Class 3.12. EventData Class
The EventData class describes a particular event of the incident for The EventData class describes a particular event of the incident for
a given set of hosts or networks. This description includes the a given set of hosts or networks. This description includes the
systems from which the activity originated and those targeted, an systems from which the activity originated and those targeted, an
assessment of the techniques used by the intruder, the impact of the assessment of the techniques used by the intruder, the impact of the
activity on the organization, and any forensic evidence discovered. activity on the organization, and any forensic evidence discovered.
skipping to change at page 38, line 10 skipping to change at page 37, line 36
of the EventData class. This is not enforced in the IODEF schema as of the EventData class. This is not enforced in the IODEF schema as
there is no simple way to accomplish it. there is no simple way to accomplish it.
The EventData class has two attributes: The EventData class has two attributes:
restriction restriction
Optional. ENUM. This attribute is defined in Section 3.2. The Optional. ENUM. This attribute is defined in Section 3.2. The
default value is "default". default value is "default".
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
3.12.1. Relating the Incident and EventData Classes 3.12.1. Relating the Incident and EventData Classes
There is substantial overlap in the Incident and EventData classes. There is substantial overlap in the Incident and EventData classes.
Nevertheless, the semantics of these classes are quite different. Nevertheless, the semantics of these classes are quite different.
The Incident class provides summary information about the entire The Incident class provides summary information about the entire
incident, while the EventData class provides information about the incident, while the EventData class provides information about the
individual events comprising the incident. In the most common case, individual events comprising the incident. In the most common case,
the EventData class will provide more specific information for the the EventData class will provide more specific information for the
general description provided in the Incident class. However, it may general description provided in the Incident class. However, it may
also be possible that the overall summarized information about the also be possible that the overall summarized information about the
incident conflicts with some individual information in an EventData incident conflicts with some individual information in an EventData
class when there is a substantial composition of various events in class when there is a substantial composition of various events in
skipping to change at page 39, line 44 skipping to change at page 39, line 31
Figure 24: The Expectation Class Figure 24: The Expectation Class
The aggregate classes that constitute Expectation are: The aggregate classes that constitute Expectation are:
Description Description
Zero or many. ML_STRING. A free-form description of the desired Zero or many. ML_STRING. A free-form description of the desired
action(s). action(s).
StartTime StartTime
Zero or one. The time at which the action should be performed. A Zero or one. The time at which the sender would like the action
timestamp that is earlier than the ReportTime specified in the performed. A timestamp that is earlier than the ReportTime
Incident class denotes that the expectation should be fulfilled as specified in the Incident class denotes that the sender would like
soon as possible. The absence of this element leaves the the action performed as soon as possible. The absence of this
execution of the expectation to the discretion of the recipient. element indicates no expections of when the recipient would like
the action performed.
EndTime EndTime
Zero or one. The time by which the action should be completed. Zero or one. The time by which the sensor expects the recipient
If the action is not carried out by this time, it should no longer to complete the action. If the recipient cannot complete the
be performed. action before EndTime, the recipient MUST NOT carry out the
action. Because of transit delays, clock drift, and so on, the
sender MUST be prepared for the recipient to have carried out the
action, even if it completes past EndTime.
Contact Contact
Zero or one. The expected actor for the action. Zero or one. The expected actor for the action.
The Expectations class has six attributes: The Expectations class has six attributes:
restriction restriction
Optional. ENUM. This attribute is defined in Section 3.2. The Optional. ENUM. This attribute is defined in Section 3.2. The
default value is "default". default value is "default".
skipping to change at page 41, line 25 skipping to change at page 41, line 14
12. remediate-other. Remediate the activity in a way other than 12. remediate-other. Remediate the activity in a way other than
by rate limiting or blocking. by rate limiting or blocking.
13. status-triage. Conveys receipts and the triaging of an 13. status-triage. Conveys receipts and the triaging of an
incident. incident.
14. status-new-info. Conveys that new information was received 14. status-new-info. Conveys that new information was received
for this incident. for this incident.
15. other. Perform some custom action described in the 15. watch-and-report. Watch for the described activity and share
if seen.
16. other. Perform some custom action described in the
Description class. Description class.
16. ext-value. An escape value used to extend this attribute. 17. ext-value. An escape value used to extend this attribute.
See Section 5.1. See Section 5.1.
ext-action ext-action
Optional. STRING. A means by which to extend the action Optional. STRING. A means by which to extend the action
attribute. See Section 5.1. attribute. See Section 5.1.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
3.14. Flow Class 3.14. Flow Class
The Flow class groups related the source and target hosts. The Flow class groups related the source and target hosts.
+------------------+ +------------------+
| Flow | | Flow |
+------------------+ +------------------+
| |<>--{1..*}--[ System ] | |<>--{1..*}--[ System ]
skipping to change at page 42, line 43 skipping to change at page 42, line 35
| STRING interface |<>--{0..*}--[ Counter ] | STRING interface |<>--{0..*}--[ Counter ]
| ENUM spoofed |<>--{0..*}--[ Description ] | ENUM spoofed |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+---------------------+ +---------------------+
Figure 26: The System Class Figure 26: The System Class
The aggregate classes that constitute System are: The aggregate classes that constitute System are:
Node Node
One. A host or network involved in the incident. One. A host or network involved in the incident.
Service Service
Zero or more. A network service running on the system. Zero or more. A network service running on the system.
OperatingSystem OperatingSystem
Zero or more. The operating system running on the system. Zero or more. The operating system running on the system.
Counter Counter
Zero or more. A counter with which to summarize properties of Zero or more. A counter with which to summarize properties of
this host or network. this host or network.
skipping to change at page 43, line 48 skipping to change at page 43, line 37
IODEF document exchange. IODEF document exchange.
8. ext-value. An escape value used to extend this attribute. 8. ext-value. An escape value used to extend this attribute.
See Section 5.1. See Section 5.1.
ext-category ext-category
Optional. STRING. A means by which to extend the category Optional. STRING. A means by which to extend the category
attribute. See Section 5.1. attribute. See Section 5.1.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
interface interface
Optional. STRING. Specifies the interface on which the event(s) Optional. STRING. Specifies the interface on which the event(s)
on this System originated. If the Node class specifies a network on this System originated. If the Node class specifies a network
rather than a host, this attribute has no meaning. rather than a host, this attribute has no meaning.
spoofed spoofed
Optional. ENUM. An indication of confidence in whether this Optional. ENUM. An indication of confidence in whether this
System was the true target or attacking host. The permitted System was the true target or attacking host. The permitted
skipping to change at page 44, line 35 skipping to change at page 44, line 21
3.16. Node Class 3.16. Node Class
The Node class names a system (e.g., PC, router) or network. The Node class names a system (e.g., PC, router) or network.
This class was derived from the IDMEF [17]. This class was derived from the IDMEF [17].
+---------------+ +---------------+
| Node | | Node |
+---------------+ +---------------+
| |<>--{0..*}--[ NodeName ] | |<>--{0..*}--[ NodeName ]
| |<>--{0..*}--[ DomainData ] | |<>--{0..*}--[ DomainData ]
| |<>--{0..*}--[ Address ] | |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ Location ] | |<>--{0..1}--[ Location ]
| |<>--{0..1}--[ DateTime ] | |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ NodeRole ] | |<>--{0..*}--[ NodeRole ]
| |<>--{0..*}--[ Counter ] | |<>--{0..*}--[ Counter ]
+---------------+ +---------------+
Figure 27: The Node Class Figure 27: The Node Class
The aggregate classes that constitute Node are: The aggregate classes that constitute Node are:
NodeName NodeName
Zero or more. ML_STRING. The name of the Node (e.g., fully Zero or more. ML_STRING. The name of the Node (e.g., fully
qualified domain name). This information MUST be provided if no qualified domain name). This information MUST be provided if no
Address information is given. Address information is given.
DomainData DomainData
Zero or more. ML_STRING. The DomainData Class and Subclasses Zero or more. The DomainData Class and Subclasses from RFC 5901.
from RFC 5901.
Address Address
Zero or more. The hardware, network, or application address of Zero or more. The hardware, network, or application address of
the Node. If a NodeName is not provided, at least one Address the Node. If a NodeName is not provided, at least one Address
MUST be specified. MUST be specified.
Location Location
Zero or one. ML_STRING. A free-from description of the physical Zero or one. ML_STRING. A free-from description of the physical
location of the equipment. location of the equipment.
DateTime DateTime
Zero or one. A timestamp of when the resolution between the name Zero or one. A timestamp of when the resolution between the name
and address was performed. This information SHOULD be provided if and address was performed. This information MAY be provided if
both an Address and NodeName are specified. both an Address and NodeName are specified.
NodeRole NodeRole
Zero or more. The intended purpose of the Node. Zero or more. The intended purpose of the Node.
Counter Counter
Zero or more. A counter with which to summarizes properties of Zero or more. A counter with which to summarizes properties of
this host or network. this host or network.
3.16.1. Counter Class 3.16.1. Counter Class
skipping to change at page 48, line 42 skipping to change at page 48, line 15
address belongs. address belongs.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
3.16.3. NodeRole Class 3.16.3. NodeRole Class
The NodeRole class describes the intended function performed by a The NodeRole class describes the intended function performed by a
particular host. particular host.
+---------------------+ +---------------------+
| NodeRole | | NodeRole |
+---------------------+ +---------------------+
| ENUM category | | ENUM category |
| STRING ext-category | | STRING ext-category |
| ENUM lang | | ENUM lang |
+---------------------+ +---------------------+
Figure 30: The NodeRole Class Figure 30: The NodeRole Class
The NodeRole class has three attributes: The NodeRole class has three attributes:
category category
Required. ENUM. Functionality provided by a node. Required. ENUM. Functionality provided by a node.
1. client. Client computer 1. client. Client computer
2. server-internal. Server with internal services 2. client-enterprise. Client computer on the enterprise network
3. server-public. Server with public services 3. client-partner. Client computer on network of a partner
4. www. WWW server 4. client-remote. Client computer remotely connected to the
enterprise network
5. mail. Mail server 5. client-kiosk. Client computer is serves as a kiosk
6. messaging. Messaging server (e.g., NNTP, IRC, IM) 6. client-mobile. Client is a mobile device
7. streaming. Streaming-media server 7. server-internal. Server with internal services
8. voice. Voice server (e.g., SIP, H.323) 8. server-public. Server with public services
9. file. File server (e.g., SMB, CVS, AFS) 9. www. WWW server
10. ftp. FTP server 10. mail. Mail server
11. p2p. Peer-to-peer node 11. messaging. Messaging server (e.g., NNTP, IRC, IM)
12. streaming. Streaming-media server
12. name. Name server (e.g., DNS, WINS) 13. voice. Voice server (e.g., SIP, H.323)
13. directory. Directory server (e.g., LDAP, finger, whois) 14. file. File server (e.g., SMB, CVS, AFS)
14. credential. Credential server (e.g., domain controller, 15. ftp. FTP server
16. p2p. Peer-to-peer node
17. name. Name server (e.g., DNS, WINS)
18. directory. Directory server (e.g., LDAP, finger, whois)
19. credential. Credential server (e.g., domain controller,
Kerberos) Kerberos)
15. print. Print server 20. print. Print server
16. application. Application server 21. application. Application server
17. database. Database server 22. database. Database server
18. infra. Infrastructure server (e.g., router, firewall, DHCP) 23. backup. Backup server
19. log. Logserver (e.g., syslog) 24. dhcp. DHCP server
20. ext-value. An escape value used to extend this attribute. 25. infra. Infrastructure server (e.g., router, firewall, DHCP)
26. infra-firewall. Firewall
27. infra-router. Router
28. infra-switch. Switch
29. camera. Camera server
30. proxy. Proxy server
31. remote-access. Remote access server
32. log. Logserver (e.g., syslog)
33. virtualization. Server running virtual machines
34. pos. Point-of-sale device
35. scada. Supervisory control and data acquisition system
36. scada-supervisory. Supervisory system for a SCADA
37. ext-value. An escape value used to extend this attribute.
See Section 5.1. See Section 5.1.
ext-category ext-category
Optional. STRING. A means by which to extend the category Optional. STRING. A means by which to extend the category
attribute. See Section 5.1. attribute. See Section 5.1.
lang lang
Optional. ENUM. A valid language code per RFC 4646 [7] Optional. ENUM. A valid language code per RFC 4646 [7]
constrained by the definition of "xs:language". The constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6. interpretation of this code is described in Section 6.
skipping to change at page 51, line 24 skipping to change at page 51, line 26
Zero or one. INTEGER. A layer-4 protocol specific flag field Zero or one. INTEGER. A layer-4 protocol specific flag field
(e.g., TCP flag field). (e.g., TCP flag field).
Application Application
Zero or one. The application bound to the specified Port or Zero or one. The application bound to the specified Port or
Portlist. Portlist.
Either a Port or Portlist class MUST be specified for a given Either a Port or Portlist class MUST be specified for a given
instance of a Service class. instance of a Service class.
For a given source, System@type="source", a corresponding target, When a given System classes with category="source" and another with
System@type="target", maybe defined, or vice versa. When a Portlist category="target" are aggregated into a single Flow class, and each
class is defined in the Service class of both the source and target of these System classes has a Service and Portlist class, an implicit
in a given instance of the Flow class, there MUST be symmetry in the relationship between these Porlists exists. If N ports are listed
enumeration of the ports. Thus, if n-ports are listed for a source, for a System@category="source", and M ports are listed for
n-ports should be listed for the target. Likewise, the ports should System@category="target", the number of ports in N must be equal to
be listed in an identical sequence such that the n-th port in the M. Likewise, the ports MUST be listed in an identical sequence such
source corresponds to the n-th port of the target. This symmetry in that the n-th port in the source corresponds to the n-th port of the
listing and sequencing of ports applies whether there are 1-to-1, target. If N is greater than 1, a given instance of a a Flow class
1-to-many, or many-to-many sources-to-targets. In the 1-to-many or MUST only have a single instance of a System@category="source" and
many-to-many, the exact order in which the System classes are System@category="target".
enumerated in the Flow class is significant.
The Service class has three attributes: The Service class has three attributes:
ip_protocol ip_protocol
Required. INTEGER. The IANA protocol number. Required. INTEGER. The IANA protocol number.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
3.17.1. Application Class 3.17.1. Application Class
The Application class describes an application running on a System The Application class describes an application running on a System
providing a Service. providing a Service.
+--------------------+ +--------------------+
| Application | | Application |
+--------------------+ +--------------------+
| STRING swid |<>--{0..1}--[ URL ] | STRING swid |<>--{0..1}--[ URL ]
| STRING configid | | STRING configid |
| STRING vendor | | STRING vendor |
| STRING family | | STRING family |
skipping to change at page 53, line 22 skipping to change at page 53, line 16
The OperatingSystem class describes the operating system running on a The OperatingSystem class describes the operating system running on a
System. The definition is identical to the Application class System. The definition is identical to the Application class
(Section 3.17.1). (Section 3.17.1).
3.19. Record Class 3.19. Record Class
The Record class is a container class for log and audit data that The Record class is a container class for log and audit data that
provides supportive information about the incident. The source of provides supportive information about the incident. The source of
this data will often be the output of monitoring tools. These logs this data will often be the output of monitoring tools. These logs
should substantiate the activity described in the document. substantiate the activity described in the document.
+------------------+ +------------------+
| Record | | Record |
+------------------+ +------------------+
| ENUM restriction |<>--{1..*}--[ RecordData ] | ENUM restriction |<>--{1..*}--[ RecordData ]
+------------------+ +------------------+
Figure 33: Record Class Figure 33: Record Class
The aggregate class that constitutes Record is: The aggregate class that constitutes Record is:
skipping to change at page 54, line 13 skipping to change at page 53, line 51
(e.g., IDS, firewall log) and provides a way to annotate the output. (e.g., IDS, firewall log) and provides a way to annotate the output.
+------------------+ +------------------+
| RecordData | | RecordData |
+------------------+ +------------------+
| ENUM restriction |<>--{0..1}--[ DateTime ] | ENUM restriction |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ Application ] | |<>--{0..1}--[ Application ]
| |<>--{0..*}--[ RecordPattern ] | |<>--{0..*}--[ RecordPattern ]
| |<>--{0..*}--[ RecordItem ] | |<>--{0..*}--[ RecordItem ]
| |<>--{0..1}--[ HashInformation ] | |<>--{0..1}--[ HashInformation ]
| |<>--{0..*}--[ WindowsRegistryKeysModified ] | |<>--{0..*}--[ WindowsRegistryKeysModified ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+------------------+ +------------------+
Figure 34: The RecordData Class Figure 34: The RecordData Class
The aggregate classes that constitutes RecordData is: The aggregate classes that constitutes RecordData is:
DateTime DateTime
Zero or one. Timestamp of the RecordItem data. Zero or one. Timestamp of the RecordItem data.
skipping to change at page 54, line 42 skipping to change at page 54, line 31
RecordItem data. RecordItem data.
RecordPattern RecordPattern
Zero or more. A search string to precisely find the relevant data Zero or more. A search string to precisely find the relevant data
in a RecordItem. in a RecordItem.
RecordItem RecordItem
Zero or more. Log, audit, or forensic data. Zero or more. Log, audit, or forensic data.
HashInformation HashInformation
Zero or one. ML_STRING. The file name and hash of a file Zero or one. The file name and hash of a file indicator.
indicator.
WindowsRegistryKeysModified WindowsRegistryKeysModified
Zero or more. The registry keys that were modified that are Zero or more. The registry keys that were modified that are
indicator(s). indicator(s).
AdditionalData AdditionalData
Zero or more. An extension mechanism for data not explicitly Zero or more. An extension mechanism for data not explicitly
represented in the data model. represented in the data model.
The RecordData class has three attribute: The RecordData class has three attribute:
restriction restriction
Optional. ENUM. This attribute has been defined in Section 3.2. Optional. ENUM. This attribute has been defined in Section 3.2.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
3.19.2. RecordPattern Class 3.19.2. RecordPattern Class
The RecordPattern class describes where in the content of the The RecordPattern class describes where in the content of the
RecordItem relevant information can be found. It provides a way to RecordItem relevant information can be found. It provides a way to
reference subsets of information, identified by a pattern, in a large reference subsets of information, identified by a pattern, in a large
log file, audit trail, or forensic data. log file, audit trail, or forensic data.
+-----------------------+ +-----------------------+
skipping to change at page 55, line 46 skipping to change at page 55, line 34
Figure 35: The RecordPattern Class Figure 35: The RecordPattern Class
The specific pattern to search with in the RecordItem is defined in The specific pattern to search with in the RecordItem is defined in
the body of the element. It is further annotated by four attributes: the body of the element. It is further annotated by four attributes:
type type
Required. ENUM. Describes the type of pattern being specified in Required. ENUM. Describes the type of pattern being specified in
the element content. The default is "regex". the element content. The default is "regex".
1. regex. regular expression, per Appendix F of [3]. 1. regex. regular expression, per Appendix F of [3].
2. binary. Binhex encoded binary pattern, per the HEXBIN data 2. binary. Binhex encoded binary pattern, per the HEXBIN data
type. type.
3. xpath. XML Path (XPath) [5] 3. xpath. XML Path (XPath) [5]
4. ext-value. An escape value used to extend this attribute. 4. ext-value. An escape value used to extend this attribute.
See Section 5.1. See Section 5.1.
ext-type ext-type
skipping to change at page 56, line 48 skipping to change at page 56, line 34
3.19.3. RecordItem Class 3.19.3. RecordItem Class
The RecordItem class provides a way to incorporate relevant logs, The RecordItem class provides a way to incorporate relevant logs,
audit trails, or forensic data to support the conclusions made during audit trails, or forensic data to support the conclusions made during
the course of analyzing the incident. The class supports both the the course of analyzing the incident. The class supports both the
direct encapsulation of the data, as well as, provides primitives to direct encapsulation of the data, as well as, provides primitives to
reference data stored elsewhere. reference data stored elsewhere.
This class is identical to AdditionalData class (Section 3.6). This class is identical to AdditionalData class (Section 3.6).
3.20. Registry Key Modified Class 3.20. RegistryKeyModified Class
The Registry Key Modified class represents operating system regsitry The Registry Key Modified class represents operating system registry
keys that have been modified as part and may constitue an indicator keys that have been modified as part and may constitue an indicator
of compromise. of compromise.
+-----------------------+ +-----------------------+
| Regsitry Key Modified | | RegistryKeyModified |
+-----------------------+ +-----------------------+
| |<>----------[ Key ] | |<>----------[ Key ]
+-----------------------+ +-----------------------+
Figure 36: The Registry Key Modified Class Figure 36: The RegistryKeyModified Class
The aggregate class that constitutes the Registry Key Modified class The aggregate class that constitutes the Registry Key Modified class
is: is:
Key Key
One. The Window Registry Key. One. The Window Registry Key.
3.20.1. Key Class 3.20.1. Key Class
The Key class shows name and value pairs representing an operating The Key class shows name and value pairs representing an operating
system registry key and its value. The key and value are encoded as system registry key and its value. The key and value are encoded as
in Microsoft .reg files. in Microsoft .reg files.
+--------------------------+ +--------------------------+
| Key | | Key |
+--------------------------+ +--------------------------+
| ENUM regsitryaction |<>--{0..*}--[ KeyName ] | ENUM regsitryaction |<>--{0..*}--[ KeyName ]
| STRING ext-category |<>--{0..*}--[ Value ] | STRING ext-category |<>--{0..*}--[ Value ]
| ENUM type | | ENUM type |
| STRING ext-type | | STRING ext-type |
| STRING indicator-uid | | STRING indicator-uid |
| STRING inidicator-set-id | | STRING inidicator-set-id |
+--------------------------+ +--------------------------+
Figure 37: The Key Class Figure 37: The Registry Key Modified Class
The aggregate classes that constitutes Key are: The aggregate classes that constitutes Key are:
KeyName KeyName
Zero or more. The name of the registry key. Zero or more. The name of the registry key.
Value Value
Zero or more. The value of the registry key. Zero or more. The value of the registry key.
The Key class has six attributes: The Key class has six attributes:
registryaction registryaction
Optional. ENUM. The type of action. Optional. ENUM. The type of action.
1. add_key. Registry key added. 1. add-key. Registry key added.
2. add_value. Value added to registry key. 2. add-value. Value added to registry key.
3. delete_key. Registry key deleted. 3. delete-key. Registry key deleted.
4. delete_value. Value deleted from registry key. 4. delete-value. Value deleted from registry key.
5. modify_key. Registry key modified. 5. modify-key. Registry key modified.
6. modify_value. Value modified for registry key. 6. modify-value. Value modified for registry key.
7. ext-value. External value. 7. ext-value. External value.
ext-category ext-category
Optional. Extension catetory. Optional. Extension category.
type type
Optional. Type Optional. Type
1. watchlist. Registry key information that is provided in a 1. watchlist. Registry key information that is provided in a
watchlist. watchlist.
2. ext-value. Registry key information from an external source. 2. ext-value. Registry key information from an external source.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group relfated
indicators. indicators.
3.21. Hash Sig Details Class 3.21. HashInformation Class
This class are the hash and signature details that are needed for This class are the hash and signature details that are needed for
providing context for indicators. providing context for indicators.
+--------------------------+ +--------------------------+
| HashSigDetails | | HashInformation |
+--------------------------+ +--------------------------+
| ENUM type |<>--{0..*}--[ FileName ] | ENUM type |<>--{0..*}--[ FileName ]
| STRING ext-category |<>--{0..*}--[ FileSize ] | STRING ext-category |<>--{0..*}--[ FileSize ]
| BOOL valid |<>--{0..*}--[ds:Signature] | BOOL valid |<>--{0..*}--[ ds:Signature ]
| STRING indicator-uid |<>--{0..*}--[ds:KeyInfo] | STRING indicator-uid |<>--{0..*}--[ ds:KeyInfo ]
| STRING inidicator-set-id |<>--{0..*}--[ds:Reference] | STRING inidicator-set-id |<>--{0..*}--[ ds:Reference ]
+--------------------------+ +--------------------------+
Figure 38: The Hash Sig Details Class Figure 38: The Hash Sig Details Class
The aggregate classes that constitute HashSigDetails are: The aggregate classes that constitutes HashInformation are:
FileName FileName
Zero or more. The name of the file. Zero or more. ML_STRING. The name of the file.
FileSize FileSize
Zero or more. The size of the file. Zero or more. INTEGER. The size of the file in bytes.
ds:Signature ds:Signature
Zero or more. The name of the file. Zero or more.
ds:KeyInfo ds:KeyInfo
Zero or more. Zero or more.
ds:Reference ds:Reference
Zero or more. The algorithm identification and value of a hash Zero or more. The algorithm identification and value of a hash
computed over the malware executable. This entire element is computed over the malware executable. This entire element is
imported from [RFC3275]. Refer to RFC 5901. imported from [RFC3275]. Refer to RFC 5901.
The HashSigDetails class has five attributes: The HashInformation class has five attributes:
type type
Optional. ENUM. The Hash Type. Optional. ENUM. The Hash Type.
1. PKI_email_ds. PKI email digital signature. 1. PKI-email-ds. PKI email digital signature.
2. PKI_file_ds. PKI file digital signature. 2. PKI-file-ds. PKI file digital signature.
3. PKI_email_ds_watchlist. Watchlist of PKI email digital 3. PKI-email-ds_watchlist. Watchlist of PKI email digital
signatures. signatures.
4. PKI_file_ds_watchlist. Watchlist of PKI file digital 4. PKI-file-ds_watchlist. Watchlist of PKI file digital
signatures. signatures.
5. PGP_email_ds. PGP email digital signature. 5. PGP-email-ds. PGP email digital signature.
6. PGP_file_ds. PGP file digital signature. 6. PGP-file-ds. PGP file digital signature.
7. PGP_email_ds_watchlist. Watchlist of PGP email digital 7. PGP-email-ds-watchlist. Watchlist of PGP email digital
signatures. signatures.
8. PGP_file_ds_watchlist. Watchlist of PGP file digital 8. PGP-file-ds-watchlist. Watchlist of PGP file digital
signatures signatures
9. file_hash. A file hash. 9. file-hash. A file hash.
10. email_hash. An email hash. 10. email-hash. An email hash.
11. file_hash_watchlist. Watchlist of file hashes 11. file-hash-watchlist. Watchlist of file hashes
12. email_hash_watchlist. Watchlist of email hashes 12. email-hash-watchlist. Watchlist of email hashes
13. ext-value. Extension value. 13. ext-value. Extension value.
indicator-uid indicator-uid
Optional. STRING. A unique identifier for an Indicator. Optional. STRING. A unique identifier for an Indicator.
indicator-set-id indicator-set-id
Optional. STRING. The indicator set ID is used to group releated Optional. STRING. The indicator set ID is used to group related
indicators. indicators.
4. Processing Considerations 4. Processing Considerations
This section defines additional requirements on creating and parsing This section defines additional requirements on creating and parsing
IODEF documents. IODEF documents.
4.1. Encoding 4.1. Encoding
Every IODEF document MUST begin with an XML declaration, and MUST Every IODEF document MUST begin with an XML declaration, and MUST
specify the XML version used. If UTF-8 encoding is not used, the specify the XML version used. If UTF-8 encoding is not used, the
character encoding MUST also be explicitly specified. The IODEF character encoding MUST also be explicitly specified. The IODEF
conforms to all XML data encoding conventions and constraints. conforms to all XML data encoding conventions and constraints.
skipping to change at page 61, line 9 skipping to change at page 60, line 36
The following characters have special meaning in XML and MUST be The following characters have special meaning in XML and MUST be
escaped with their entity reference equivalent: "&", "<", ">", "\"" escaped with their entity reference equivalent: "&", "<", ">", "\""
(double quotation mark), and "'" (apostrophe). These entity (double quotation mark), and "'" (apostrophe). These entity
references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;" references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;"
respectively. respectively.
4.2. IODEF Namespace 4.2. IODEF Namespace
The IODEF schema declares a namespace of The IODEF schema declares a namespace of
"urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. Each "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 IODEF document MUST include a valid reference to the IODEF schema
using the "xsi:schemaLocation" attribute. An example of such a using the "xsi:schemaLocation" attribute. An example of such a
declaration would look as follows: declaration would look as follows:
<IODEF-Document <IODEF-Document
version="1.00" lang="en-US" version="1.00" lang="en-US"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xsi:schemaLocation="urn:ietf:params:xmls:schema:iodef-1.0" xsi:schemaLocation="urn:ietf:params:xmls:schema:iodef-1.0"
4.3. Validation 4.3. Validation
The IODEF documents MUST be well-formed XML and SHOULD be validated The IODEF documents MUST be well-formed XML. It is RECOMMENDED that
against the schema described in Section 8. However, mere conformance recipients validate the document against the schema described in
to the schema is not sufficient for a semantically valid IODEF Section 8. However, mere conformance to the schema is not sufficient
document. There is additional specification in the text of Section 3 for a semantically valid IODEF document. There is additional
that cannot be readily encoded in the schema and it must also be specification in the text of Section 3 that cannot be readily encoded
considered by an IODEF parser. The following is a list of in the schema and it must also be considered by an IODEF parser. The
discrepancies in what is more strictly specified in the normative following is a list of discrepancies in what is more strictly
text (Section 3), but not enforced in the IODEF schema: specified in the normative text (Section 3), but not enforced in the
IODEF schema:
o The elements or attributes that are defined as POSTAL, NAME, o The elements or attributes that are defined as POSTAL, NAME,
PHONE, and EMAIL data-types are implemented as "xs:string", but PHONE, and EMAIL data-types are implemented as "xs:string", but
more rigid formatting requirements are specified in the text. more rigid formatting requirements are specified in the text.
o The IODEF-Document@lang and MLStringType@lang attributes are o The IODEF-Document@lang and MLStringType@lang attributes are
declared as an "xs:language" that constrains values with a regular declared as an "xs:language" that constrains values with a regular
expression. However, the value of this attribute still needs to expression. However, the value of this attribute still needs to
be validated against the list of possible enumerated values is be validated against the list of possible enumerated values is
defined in [7]. defined in [7].
o The MonetaryImpact@currency attribute is declared as an "xs: o The MonetaryImpact@currency attribute is declared as an
string", but the list of valid values as defined in [14]. "xs:string", but the list of valid values as defined in [14].
o All of the aggregated classes Contact and EventData are optional o All of the aggregated classes Contact and EventData are optional
in the schema, but at least one of these aggregated classes MUST in the schema, but at least one of these aggregated classes MUST
be present. be present.
o There are multiple conventions that can be used to categorize a o There are multiple conventions that can be used to categorize a
system using the NodeRole class or to specify software with the system using the NodeRole class or to specify software with the
Application and OperatingSystem classes. IODEF parsers MUST Application and OperatingSystem classes. IODEF parsers MUST
accept incident reports that do not use these fields in accordance accept incident reports that do not use these fields in accordance
with local conventions. with local conventions.
skipping to change at page 63, line 5 skipping to change at page 62, line 33
attribute has "ext-value" as one its possible values. This attribute has "ext-value" as one its possible values. This
particular value serves as an escape sequence and has no valid particular value serves as an escape sequence and has no valid
meaning. meaning.
In order to add a new enumerated value to an extensible attribute, 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 the value of this attribute MUST be set to "ext-value", and the new
desired value MUST be set in the corresponding extension attribute. desired value MUST be set in the corresponding extension attribute.
For example, an extended instance of the type attribute of the Impact For example, an extended instance of the type attribute of the Impact
class would look as follows: 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 A given extension attribute MUST NOT be set unless the corresponding
extensible attribute has been set to "ext-value". 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 classes of the data model can be extended only through the use of
the AdditionalData and RecordItem classes. These container classes, the AdditionalData and RecordItem classes. These container classes,
collectively referred to as the extensible classes, are implemented collectively referred to as the extensible classes, are implemented
with the iodef:ExtensionType data type in the schema. They provide with the iodef:ExtensionType data type in the schema. They provide
skipping to change at page 63, line 39 skipping to change at page 63, line 20
2. Set the dtype attribute to correspond to the data type of the 2. Set the dtype attribute to correspond to the data type of the
element content. 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 1. The element content of the extensible class MUST be set to the
desired value and the dtype attribute MUST be set to "xml". desired value and the dtype attribute MUST be set to "xml".
2. The extension schema MUST declare a separate namespace. It is 2. The extension schema MUST declare a separate namespace. It is
RECOMMENDED that these extensions have the prefix "iodef-". RECOMMENDED that these extensions have the prefix "iodef-". This
recommendation makes readability of the document easier by
allowing the reader to infer which namespaces relate to IODEF by
inspection.
3. It is RECOMMENDED that extension schemas follow the naming 3. It is RECOMMENDED that extension schemas follow the naming
convention of the IODEF data model. The names of all elements convention of the IODEF data model. This makes reading an
are capitalized. For composed names, a capital letter is used extended IODEF document look like any other IODEF document. The
for each word. Attribute names are lower case. names of all elements are capitalized. For elements with
composed names, a capital letter is used for each word.
Attribute names are lower case. Attributes with composed names
are seperated by a hyphen.
4. When a parser encounters an IODEF document with an extension it 4. Parsers that encounter an unrecognized element in a namespace
does not understand, this extension MUST be ignored (and not that they do support MUST reject the document as a syntax error.
processed), but the remainder of the document MUST be processed.
Parsers will 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 5. There are security and performance implications in requiring
security implications, and extensions MUST NOT be required to implementations to dynamically download schemas at run time.
provide a resolvable location of their schema. Thus, implementations SHOULD NOT download schemas at runtime,
unless implementations take appropriate precautions and are
prepared for potentially significant network, processing, and
time-out demands.
6. Some users of the IODEF may have private schema definitions that
might not be available on the Internet. In this situation, if a
IODEF document leaks out of the private use space, references to
some of those document schemas may not be resolvable. This has
two implications. First, references to private schemas may never
resolve. As such, in addition to the suggestion that
implementations do not download schemas at runtime mentioned
above, recipients MUST be prepared for a schema definition in an
IODEF document never to resolve.
The following schema and XML document excerpt provide a template for The following schema and XML document excerpt provide a template for
an extension schema and its use in the IODEF document. an extension schema and its use in the IODEF document.
This example schema defines a namespace of "iodef-extension1" and a This example schema defines a namespace of "iodef-extension1" and a
single element named "newdata". single element named "newdata".
<xs:schema <xs:schema
targetNamespace="iodef-extension1.xsd" targetNamespace="iodef-extension1.xsd"
xmlns:iodef-extension1="iodef-extension1.xsd" xmlns:iodef-extension1="iodef-extension1.xsd"
skipping to change at page 64, line 32 skipping to change at page 64, line 27
<xs:import <xs:import
namespace="urn:ietf:params:xml:ns:iodef-1.0" namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation=" urn:ietf:params:xml:schema:iodef-1.0"/> schemaLocation=" urn:ietf:params:xml:schema:iodef-1.0"/>
<xs:element name="newdata" type="xs:string" /> <xs:element name="newdata" type="xs:string" />
</xs:schema> </xs:schema>
The following XML excerpt demonstrates the use of the above schema as The following XML excerpt demonstrates the use of the above schema as
an extension to the IODEF. an extension to the IODEF.
<IODEF-Document <IODEF-Document
version="1.00" lang="en-US" version="1.00" lang="en-US"
xmlns="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:iodef=" urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef-extension1="iodef-extension1.xsd" xmlns:iodef-extension1="iodef-extension1.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="iodef-extension1.xsd"> xsi:schemaLocation="iodef-extension1.xsd">
<Incident purpose="reporting"> <Incident purpose="reporting">
... ...
<AdditionalData dtype="xml" meaning="xml"> <AdditionalData dtype="xml" meaning="xml">
<iodef-extension1:newdata> <iodef-extension1:newdata>
Field that could not be represented elsewhere Field that could not be represented elsewhere
</iodef-extension1:newdata> </iodef-extension1:newdata>
</AdditionalData> </AdditionalData>
</IODEF-Document </IODEF-Document
6. Internationalization Issues 6. Internationalization Issues
Internationalization and localization is of specific concern to the Internationalization and localization is of specific concern to the
IODEF, since it is only through collaboration, often across language IODEF, since it is only through collaboration, often across language
barriers, that certain incidents be resolved. The IODEF supports barriers, that certain incidents be resolved. The IODEF supports
this goal by depending on XML constructs, and through explicit design this goal by depending on XML constructs, and through explicit design
choices in the data model. choices in the data model.
Since IODEF is implemented as an XML Schema, it implicitly supports Since IODEF is implemented as an XML Schema, it implicitly supports
all the different character encodings, such as UTF-8 and UTF-16, all the different character encodings, such as UTF-8 and UTF-16,
possible with XML. Additionally, each IODEF document MUST specify possible with XML. Additionally, each IODEF document MUST specify
the language in which their contents are encoded. The language can the language in which their contents are encoded. The language can
be specified with the attribute "xml:lang" (per Section 2.12 of [1]) 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 in the top-level element (i.e., IODEF-Document@lang) and letting all
other elements inherit that definition. All IODEF classes with a other elements inherit that definition. All IODEF classes with a
free-form text definition (i.e., all those defined of type iodef: free-form text definition (i.e., all those defined of type
MLStringType) can also specify a language different from the rest of iodef:MLStringType) can also specify a language different from the
the document. The valid language codes for the "xml:lang" attribute rest of the document. The valid language codes for the "xml:lang"
are described in RFC 4646 [7]. attribute are described in RFC 4646 [7].
The data model supports multiple translations of free-form text. In The data model supports multiple translations of free-form text. In
the places where free-text is used for descriptive purposes, the 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., 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 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 encoded in different instances of the same class, but each being in a
different language. This approach allows an IODEF document author to different language. This approach allows an IODEF document author to
send recipients speaking different languages an identical document. send recipients speaking different languages an identical document.
The IODEF parser SHOULD extract the appropriate language relevant to The IODEF parser SHOULD extract the appropriate language relevant to
the recipient. the recipient.
skipping to change at page 66, line 9 skipping to change at page 65, line 46
7. Examples 7. Examples
This section provides examples of an incident encoded in the IODEF. This section provides examples of an incident encoded in the IODEF.
These examples do not necessarily represent the only way to encode a These examples do not necessarily represent the only way to encode a
particular incident. 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"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This example demonstrates a report for a very <!-- This example demonstrates a report for a very
old worm (Code Red) --> old worm (Code Red) -->
<IODEF-Document version="1.00" lang="en" <IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting"> <Incident purpose="reporting">
<IncidentID name="csirt.example.com">189493</IncidentID> <IncidentID name="csirt.example.com">189493</IncidentID>
<ReportTime>2001-09-13T23:19:24+00:00</ReportTime> <ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
<Description>Host sending out Code Red probes</Description> <Description>Host sending out Code Red probes</Description>
<!-- An administrative privilege was attempted, but failed --> <!-- An administrative privilege was attempted, but failed -->
<Assessment> <Assessment>
<Impact completion="failed" type="admin"/> <Impact completion="failed" type="admin"/>
</Assessment> </Assessment>
<Contact role="creator" type="organization"> <Contact role="creator" type="organization">
<ContactName>Example.com CSIRT</ContactName> <ContactName>Example.com CSIRT</ContactName>
<RegistryHandle registry="arin">example-com</RegistryHandle> <RegistryHandle registry="arin">example-com</RegistryHandle>
<Email>contact@csirt.example.com</Email> <Email>contact@csirt.example.com</Email>
</Contact> </Contact>
<EventData> <EventData>
<Flow> <Flow>
<System category="source"> <System category="source">
<Node> <Node>
<Address category="ipv4-addr">192.0.2.200</Address> <Address category="ipv4-addr">192.0.2.200</Address>
<Counter type="event">57</Counter> <Counter type="event">57</Counter>
</Node> </Node>
</System> </System>
<System category="target"> <System category="target">
<Node> <Node>
<Address category="ipv4-net">192.0.2.16/28</Address> <Address category="ipv4-net">192.0.2.16/28</Address>
</Node> </Node>
<Service ip_protocol="6"> <Service ip_protocol="6">
<Port>80</Port> <Port>80</Port>
</Service> </Service>
</System> </System>
</Flow> </Flow>
<Expectation action="block-host" /> <Expectation action="block-host" />
<!-- <RecordItem> has an excerpt from a log --> <!-- <RecordItem> has an excerpt from a log -->
<Record> <Record>
<RecordData> <RecordData>
<DateTime>2001-09-13T18:11:21+02:00</DateTime> <DateTime>2001-09-13T18:11:21+02:00</DateTime>
<Description>Web-server logs</Description> <Description>Web-server logs</Description>
<RecordItem dtype="string"> <RecordItem dtype="string">
192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida? 192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</RecordItem> </RecordItem>
<!-- Additional logs --> <!-- Additional logs -->
<RecordItem dtype="url"> <RecordItem dtype="url">
http://mylogs.example.com/logs/httpd_access</RecordItem> http://mylogs.example.com/logs/httpd_access</RecordItem>
</RecordData> </RecordData>
</Record>
</EventData> </Record>
<History> </EventData>
<!-- Contact was previously made with the source network owner --> <History>
<HistoryItem action="contact-source-site"> <!-- Contact was previously made with the source network
<DateTime>2001-09-14T08:19:01+00:00</DateTime> owner -->
<Description>Notification sent to <HistoryItem action="contact-source-site">
constituency-contact@192.0.2.200</Description> <DateTime>2001-09-14T08:19:01+00:00</DateTime>
</HistoryItem> <Description>Notification sent to
</History> constituency-contact@192.0.2.200</Description>
</Incident> </HistoryItem>
</IODEF-Document> </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" ?> <?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes reconnaissance activity: one-to-one and <!-- This example describes reconnaissance activity: one-to-one
one-to-many scanning --> and one-to-many scanning -->
<IODEF-Document version="1.00" lang="en" <IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting"> <Incident purpose="reporting">
<IncidentID name="csirt.example.com">59334</IncidentID> <IncidentID name="csirt.example.com">59334</IncidentID>
<ReportTime>2006-08-02T05:54:02-05:00</ReportTime> <ReportTime>2006-08-02T05:54:02-05:00</ReportTime>
<Assessment> <Assessment>
<Impact type="recon" completion="succeeded" /> <Impact type="recon" completion="succeeded" />
</Assessment> </Assessment>
skipping to change at page 68, line 14 skipping to change at page 67, line 49
<ReferenceName>nmap</ReferenceName> <ReferenceName>nmap</ReferenceName>
<URL>http://nmap.toolsite.example.com</URL> <URL>http://nmap.toolsite.example.com</URL>
</Reference> </Reference>
</Method> </Method>
<!-- Organizational contact and that for staff in that <!-- Organizational contact and that for staff in that
organization --> organization -->
<Contact role="creator" type="organization"> <Contact role="creator" type="organization">
<ContactName>CSIRT for example.com</ContactName> <ContactName>CSIRT for example.com</ContactName>
<Email>contact@csirt.example.com</Email> <Email>contact@csirt.example.com</Email>
<Telephone>+1 412 555 12345</Telephone> <Telephone>+1 412 555 12345</Telephone>
<!-- Since this <Contact> is nested, Joe Smith is part of the <!-- Since this <Contact> is nested, Joe Smith is part of
CSIRT for example.com --> the CSIRT for example.com -->
<Contact role="tech" type="person" restriction="need-to-know"> <Contact role="tech" type="person" restriction="need-to-know">
<ContactName>Joe Smith</ContactName> <ContactName>Joe Smith</ContactName>
<Email>smith@csirt.example.com</Email> <Email>smith@csirt.example.com</Email>
</Contact> </Contact>
</Contact> </Contact>
<EventData> <EventData>
<!-- Scanning activity as follows: <!-- Scanning activity as follows:
192.0.2.1:60524 >> 192.0.2.3:137 192.0.2.1:60524 >> 192.0.2.3:137
192.0.2.1:60526 >> 192.0.2.3:138 192.0.2.1:60526 >> 192.0.2.3:138
192.0.2.1:60527 >> 192.0.2.3:139 192.0.2.1:60527 >> 192.0.2.3:139
skipping to change at page 69, line 16 skipping to change at page 69, line 4
</System> </System>
<System category="target"> <System category="target">
<Node> <Node>
<Address category="ipv4-net">192.0.2.64/28</Address> <Address category="ipv4-net">192.0.2.64/28</Address>
</Node> </Node>
<Service ip_protocol="6"> <Service ip_protocol="6">
<Port>445</Port> <Port>445</Port>
</Service> </Service>
</System> </System>
</Flow> </Flow>
</EventData> </EventData>
</Incident> </Incident>
</IODEF-Document> </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" ?> <?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes a compromise and subsequent installation <!-- This example describes a compromise and subsequent installation
of bots --> of bots -->
<IODEF-Document version="1.00" lang="en" <IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="mitigation"> <Incident purpose="mitigation">
<IncidentID name="csirt.example.com">908711</IncidentID> <IncidentID name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-06-08T05:44:53-05:00</ReportTime> <ReportTime>2006-06-08T05:44:53-05:00</ReportTime>
<Description>Large bot-net</Description> <Description>Large bot-net</Description>
<Assessment> <Assessment>
<Impact type="dos" severity="high" completion="succeeded" /> <Impact type="dos" severity="high" completion="succeeded" />
</Assessment> </Assessment>
<Method> <Method>
<!-- References a given piece of malware, "GT Bot" --> <!-- References a given piece of malware, "GT Bot" -->
<Reference> <Reference>
<ReferenceName>GT Bot</ReferenceName> <ReferenceName>GT Bot</ReferenceName>
</Reference> </Reference>
<!-- References the vulnerability used to compromise the <!-- References the vulnerability used to compromise the
machines --> machines -->
<Reference> <Reference>
<ReferenceName>CA-2003-22</ReferenceName> <ReferenceName>CA-2003-22</ReferenceName>
<URL>http://www.cert.org/advisories/CA-2003-22.html</URL> <URL>http://www.cert.org/advisories/CA-2003-22.html</URL>
<Description>Root compromise via this IE vulnerability to <Description>Root compromise via this IE vulnerability to
install the GT Bot</Description> 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>
</Reference> <Flow>
</Method> <!-- bot running on 192.0.2.1 and sending DoS traffic at
<!-- A member of the CSIRT that is coordinating this 10,000 bytes/second -->
incident --> <System category="source">
<Contact type="person" role="irt"> <Node>
<ContactName>Joe Smith</ContactName> <Address category="ipv4-addr">192.0.2.1</Address>
<Email>jsmith@csirt.example.com</Email> </Node>
</Contact> <Counter type="byte" duration="second">10000</Counter>
<EventData> <Description>bot</Description>
<Description>These hosts are compromised and acting as bots </System>
communicating with irc.example.com.</Description> <!-- a second bot on 192.0.2.3 -->
<Flow> <System category="source">
<!-- bot running on 192.0.2.1 and sending DoS traffic at <Node>
10,000 bytes/second --> <Address category="ipv4-addr">192.0.2.3</Address>
<System category="source"> </Node>
<Node> <Counter type="byte" duration="second">250000</Counter>
<Address category="ipv4-addr">192.0.2.1</Address> <Description>bot</Description>
</Node> </System>
<Counter type="byte" duration="second">10000</Counter> <!-- Command-and-control IRC server for these bots-->
<Description>bot</Description> <System category="intermediate">
</System> <Node>
<!-- a second bot on 192.0.2.3 --> <NodeName>irc.example.com</NodeName>
<System category="source"> <Address category="ipv4-addr">192.0.2.20</Address>
<Node> <DateTime>2006-06-08T01:01:03-05:00</DateTime>
<Address category="ipv4-addr">192.0.2.3</Address> </Node>
</Node> <Description>
<Counter type="byte" duration="second">250000</Counter> IRC server on #give-me-cmd channel
<Description>bot</Description> </Description>
</System> </System>
<!-- Command-and-control IRC server for these bots--> </Flow>
<System category="intermediate"> <!-- Request to take these machines offline -->
<Node> <Expectation action="investigate">
<NodeName>irc.example.com</NodeName> <Description>
<Address category="ipv4-addr">192.0.2.20</Address> Confirm the source and take machines off-line and
<DateTime>2006-06-08T01:01:03-05:00</DateTime> remediate
</Node> </Description>
<Description>IRC server on #give-me-cmd channel</Description> </Expectation>
</System> </EventData>
</Flow> </Incident>
<!-- Request to take these machines offline --> </IODEF-Document>
<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" ?> <?xml version="1.0" encoding="UTF-8" ?>
<!-- This example demonstrates a trivial IP watch-list --> <!-- This example demonstrates a trivial IP watch-list -->
<!-- @formatid is set to "watch-list-043" to demonstrate how additional <!-- @formatid is set to "watch-list-043" to demonstrate how
semantics about this document could be conveyed assuming both additional semantics about this document could be conveyed
parties understood it--> assuming both parties understood it-->
<IODEF-Document version="1.00" lang="en" formatid="watch-list-043" <IODEF-Document version="1.00" lang="en" formatid="watch-list-043"
xmlns="urn:ietf:params:xml:ns:iodef-1.0" xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0"> xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting" restriction="private"> <Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">908711</IncidentID> <IncidentID name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-08-01T00:00:00-05:00</ReportTime> <ReportTime>2006-08-01T00:00:00-05:00</ReportTime>
<Description>Watch-list of known bad IPs or networks</Description> <Description>
<Assessment> Watch-list of known bad IPs or networks
<Impact type="admin" completion="succeeded" /> </Description>
<Impact type="recon" completion="succeeded" /> <Assessment>
</Assessment> <Impact type="admin" completion="succeeded" />
<Contact type="organization" role="creator"> <Impact type="recon" completion="succeeded" />
<ContactName>CSIRT for example.com</ContactName> </Assessment>
<Email>contact@csirt.example.com</Email> <Contact type="organization" role="creator">
</Contact> <ContactName>CSIRT for example.com</ContactName>
<!-- Separate <EventData> used to convey different <Expectation> --> <Email>contact@csirt.example.com</Email>
<EventData> </Contact>
<Flow> <!-- Separate <EventData> is used to convey
<System category="source"> different <Expectation> -->
<Node> <EventData>
<Address category="ipv4-addr">192.0.2.53</Address> <Flow>
</Node> <System category="source">
<Description>Source of numerous attacks</Description> <Node>
</System> <Address category="ipv4-addr">192.0.2.53</Address>
</Flow> </Node>
<!-- Expectation class indicating that sender of list would like <Description>Source of numerous attacks</Description>
to be notified if activity from the host is seen --> </System>
<Expectation action="contact-sender" /> </Flow>
</EventData> <!-- Expectation class indicating that sender of list would
<EventData> like to be notified if activity from the host is seen -->
<Flow> <Expectation action="contact-sender" />
<System category="source"> </EventData>
<Node> <EventData>
<Address category="ipv4-net">192.0.2.16/28</Address> <Flow>
</Node> <System category="source">
<Description> <Node>
Source of heavy scanning over past 1-month <Address category="ipv4-net">192.0.2.16/28</Address>
</Description>
</System> </Node>
</Flow> <Description>
<Flow> Source of heavy scanning over past 1-month
<System category="source"> </Description>
<Node> </System>
<Address category="ipv4-addr">192.0.2.241</Address> </Flow>
</Node> <Flow>
<Description>C2 IRC server</Description> <System category="source">
</System> <Node>
</Flow> <Address category="ipv4-addr">192.0.2.241</Address>
<!-- Expectation class recommends that these networks </Node>
be filtered --> <Description>C2 IRC server</Description>
<Expectation action="block-host" /> </System>
</EventData> </Flow>
</Incident> <!-- Expectation class recommends that these networks
</IODEF-Document> 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-2.0"
<xs:schema targetNamespace="urn:ietf:params:xml:ns:iodef-1.40" xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.40" xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.40" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="qualified"
elementFormDefault="qualified" attributeFormDefault="unqualified">
attributeFormDefault="unqualified"> <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/
schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/> REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
Incident Object Description Exchange Format v1.11, RFC5070-bis Incident Object Description Exchange Format v2.0, RFC5070-bis
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<!-- CHANGE: See above addition of xmlns:ds and import of same <!-- CHANGE: See above addition of xmlns:ds and import of same
namespace. This is to use the digital signature hash inclusion namespace. This is to use the digital signature hash
of a file by referencing the existing standard as was done in inclusion of a file by referencing the existing standard as
RFC5901, RFC3275 is the reference, see RFC5901 section 5.9.5.2 was done in RFC5901, RFC3275 is the reference, see RFC5901
<!-- section 5.9.5.2
==================================================================== -->
=== List of changes === <!--
==================================================================== ==================================================================
CHANGE - new indicator values in the schema == List of changes ==
==================================================================
The purpose of the proposed changes is to include commonly shared CHANGE - new indicator values in the schema
indicators in the base IODEF schema. This class will contain
indicators from the list below that are not represented elsewhere
in the schema. IODEF extensions or embedded schemas via the SCI
classes will be required to include additional data types.
A table could be maintained through IANA to extend or change this
class in between IODEF revisions.
RFC5901 provides a method to include an entire email, the following The purpose of the proposed changes is to include commonly shared
included indicators are ones commonly used when you do not need the indicators in the base IODEF schema. This class will contain
entire email indicators from the list below that are not represented elsewhere
The following are in the Service Class: in the schema. IODEF extensions or embedded schemas via the SCI
Email address classes will be required to include additional data types.
Email subject A table could be maintained through IANA to extend or change this
X-Mailer class in between IODEF revisions.
The following are in the Record class:
File Name
File Hash - 5.9.5.2 - using ds:reference
WindowsRegistryKey - using method from RFC5901
The following are now in the Node class as a proposed location.
URL
HTTPUserAgent is included as a SoftwareType
HTTP User Agent String
The following are already represented elsewhere in the schema (Node):
IP address
Network CIDR / ASN
Host Name
Domain Name (additional options for RFC5901 were not included in
this revision - can include point-in-time dig info)
-->
<!--
====================================================================
== 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" RFC5901 provides a method to include an entire email, the following
type="xs:string"/> included indicators are ones commonly used when you do not need the
</xs:complexType> entire email
</xs:element> The following are in the Service Class:
<!-- Email address
==================================================================== Email subject
=== Incident class === X-Mailer
==================================================================== The following are in the Record class:
--> File Name
<xs:element name="Incident"> File Hash - 5.9.5.2 - using ds:reference
<xs:complexType> WindowsRegistryKey - using method from RFC5901
<xs:sequence> The following are now in the Node class as a proposed location.
<xs:choice> URL
<xs:element ref="iodef:IncidentID"/> HTTPUserAgent is included as a SoftwareType
<!-- CHANGE - the incidentID can still be used, HTTP User Agent String
but when you have a set of indictaors or include -->
a watch list, a ReportID may be preferred. If <!--
this is agreed upon, do we make them both unique ==================================================================
so the same key can be used in databases? This == IODEF-Document class ==
should not be used as your index value unless you ==================================================================
are the issueing entity. --> -->
<xs:element ref="iodef:ReportID"/> <xs:element name="IODEF-Document">
</xs:choice> <xs:complexType>
<xs:element ref="iodef:AlternativeID" <xs:sequence>
minOccurs="0"/> <xs:element ref="iodef:Incident"
<xs:element ref="iodef:RelatedActivity" maxOccurs="unbounded"/>
minOccurs="0"/> </xs:sequence>
<xs:element ref="iodef:DetectTime" <xs:attribute name="version"
minOccurs="0"/> type="xs:string" fixed="2.00"/>
<xs:element ref="iodef:StartTime" <xs:attribute name="lang"
minOccurs="0"/> type="xs:language" use="required"/>
<xs:element ref="iodef:EndTime" <xs:attribute name="formatid"
minOccurs="0"/> type="xs:string"/>
<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"/>
<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:complexType>
<xs:attribute name="purpose" use="required"> </xs:element>
<xs:simpleType> <!--
<xs:restriction base="xs:NMTOKEN"> ==================================================================
<xs:enumeration value="traceback"/> === Incident class ===
<xs:enumeration value="mitigation"/> ==================================================================
<xs:enumeration value="reporting"/> -->
<xs:enumeration value="other"/> <xs:element name="Incident">
<xs:enumeration value="ext-value"/> <xs:complexType>
</xs:restriction> <xs:sequence>
</xs:simpleType> <xs:choice>
</xs:attribute> <xs:element ref="iodef:IncidentID"/>
<xs:attribute name="ext-purpose" <!-- CHANGE - the incidentID can still be used,
type="xs:string" use="optional"/> but when you have a set of indictaors or include
<xs:attribute name="lang" a watch list, a ReportID may be preferred. If
type="xs:language"/> this is agreed upon, do we make them both unique
<xs:attribute name="restriction" so the same key can be used in databases? This
type="iodef:restriction-type" default="private"/> should not be used as your index value unless you
<!-- CHANGE - adding an attribute to mark sets of indicators --> are the issueing entity. -->
<xs:attribute name="indicator-set-id" <xs:element name="ReportID" type="IncidentIDType"/>
type="xs:string" use="optional"/> </xs:choice>
</xs:complexType> <xs:element ref="iodef:AlternativeID"
</xs:element> minOccurs="0"/>
<!-- <xs:element ref="iodef:RelatedActivity"
==================================================================== minOccurs="0"/>
== IncidentID class == <xs:element ref="iodef:DetectTime"
==================================================================== minOccurs="0"/>
--> <xs:element ref="iodef:StartTime"
<xs:element name="IncidentID" type="iodef:IncidentIDType"/> minOccurs="0"/>
<xs:complexType name="IncidentIDType"> <xs:element ref="iodef:EndTime"
<xs:simpleContent> minOccurs="0"/>
<xs:extension base="xs:string"> <xs:element ref="iodef:ReportTime"/>
<xs:attribute name="name" <xs:element ref="iodef:Description"
type="xs:string" use="required"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:attribute name="instance" <xs:element ref="iodef:Assessment"
type="xs:string" use="optional"/> maxOccurs="unbounded"/>
<xs:attribute name="restriction" <xs:element ref="iodef:Method"
type="iodef:restriction-type" default="public"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:extension> <xs:element ref="iodef:Contact"
</xs:simpleContent> maxOccurs="unbounded"/>
</xs:complexType> <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"/>
<!-- CHANGE - added attribute to mark sets of indicators -->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
</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>
<!-- <!--
==================================================================== ==================================================================
== ReportID class == == ReportID class ==
==================================================================== ==================================================================
--> -->
<xs:element name="ReportID"> <xs:element name="ReportID">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="iodef:IncidentID" <xs:element ref="iodef:IncidentID"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="restriction" <xs:attribute name="restriction"
type="iodef:restriction-type"/> type="iodef:restriction-type"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<!--
====================================================================
== 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"/>
<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> == AlternativeID class ==
<xs:attribute name="ext-type" ==================================================================
type="xs:string" use="optional"/> -->
<xs:attribute name="restriction" <xs:element name="AlternativeID">
type="iodef:restriction-type"/> <xs:complexType>
</xs:complexType> <xs:sequence>
</xs:element> <xs:element ref="iodef:IncidentID"
<!-- CHANGE - UML states the type disambiguates the type of Name maxOccurs="unbounded"/>
person or organization. Do we want this added to the schema? --> </xs:sequence>
<xs:element name="ContactName" <xs:attribute name="restriction"
type="iodef:MLStringType"/> type="iodef:restriction-type"/>
<xs:element name="RegistryHandle"> </xs:complexType>
<xs:complexType> </xs:element>
<xs:simpleContent> <!--
<xs:extension base="xs:string"> ==================================================================
<xs:attribute name="registry"> == RelatedActivity class ==
<xs:simpleType> ==================================================================
<xs:restriction base="xs:NMTOKEN"> -->
<xs:enumeration value="internic"/> <xs:element name="RelatedActivity">
<xs:enumeration value="apnic"/> <xs:complexType>
<xs:enumeration value="arin"/> <xs:choice>
<xs:enumeration value="lacnic"/> <xs:element ref="iodef:IncidentID"
<xs:enumeration value="ripe"/> maxOccurs="unbounded"/>
<xs:enumeration value="afrinic"/> <xs:element ref="iodef:URL"
<xs:enumeration value="local"/> maxOccurs="unbounded"/>
<xs:enumeration value="ext-value"/> </xs:choice>
</xs:restriction> <xs:attribute name="restriction"
</xs:simpleType> type="iodef:restriction-type"/>
</xs:attribute> </xs:complexType>
<xs:attribute name="ext-registry" </xs:element>
type="xs:string" use="optional"/> <!--
</xs:extension> ==================================================================
</xs:simpleContent> == AdditionalData class ==
</xs:complexType> ==================================================================
</xs:element> -->
<xs:element name="AdditionalData" type="iodef:ExtensionType"/>
<!--
==================================================================
== Contact class ==
==================================================================
-->
<xs:element name="Contact">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:ContactName"
minOccurs="0"/>
<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:element name="PostalAddress"> </xs:restriction>
<xs:complexType> </xs:simpleType>
<xs:simpleContent> </xs:attribute>
<xs:extension base="iodef:MLStringType"> <xs:attribute name="ext-type"
<xs:attribute name="meaning" type="xs:string" use="optional"/>
type="xs:string" use="optional"/> <xs:attribute name="restriction"
</xs:extension> type="iodef:restriction-type"/>
</xs:simpleContent> </xs:complexType>
</xs:complexType> </xs:element>
</xs:element> <!-- CHANGE - UML states the type disambiguates the type of
<xs:element name="Email" type="iodef:ContactMeansType"/> Name person or organization. Do we want this added to the
<xs:element name="Telephone" type="iodef:ContactMeansType"/> schema? -->
<xs:element name="Fax" type="iodef:ContactMeansType"/> <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:complexType name="ContactMeansType"> <xs:element name="PostalAddress">
<xs:simpleContent> <xs:complexType>
<xs:extension base="xs:string"> <xs:simpleContent>
<xs:attribute name="meaning" <xs:extension base="iodef:MLStringType">
type="xs:string" use="optional"/> <xs:attribute name="meaning"
</xs:extension> type="xs:string" use="optional"/>
</xs:simpleContent> </xs:extension>
</xs:complexType> </xs:simpleContent>
</xs:complexType>
<!-- </xs:element>
==================================================================== <xs:element name="Email" type="iodef:ContactMeansType"/>
=== Time-based classes === <xs:element name="Telephone" type="iodef:ContactMeansType"/>
==================================================================== <xs:element name="Fax" type="iodef:ContactMeansType"/>
-->
<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:complexType name="ContactMeansType">
</xs:element> <xs:simpleContent>
<xs:element name="HistoryItem"> <xs:extension base="xs:string">
<xs:complexType> <xs:attribute name="meaning"
<xs:sequence> type="xs:string" use="optional"/>
<xs:element ref="iodef:DateTime"/> </xs:extension>
<xs:element ref="iodef:IncidentID" </xs:simpleContent>
minOccurs="0"/> </xs:complexType>
<xs:element ref="iodef:Contact"
minOccurs="0"/>
<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="action"
type="iodef:action-type" use="required"/>
<xs:attribute name="ext-action"
type="xs:string" use="optional"/>
<!-- CHANGE: Including a unique ID for indicators, may be
used to connect indicators in different representations
-->
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
<!-- CHANGE: Including an indicator set ID that may be used
to detail changes int he history class as it relates to
indicators or sets.
-->
<xs:attribute name="indicator-set-id"
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> == Time-based classes ==
<xs:attribute name="restriction" ==================================================================
type="iodef:restriction-type" default="default"/> -->
<xs:attribute name="severity" <xs:element name="DateTime"
type="iodef:severity-type"/> type="xs:dateTime"/>
<xs:attribute name="action" <xs:element name="ReportTime"
type="iodef:action-type" default="other"/> type="xs:dateTime"/>
<xs:attribute name="ext-action" <xs:element name="DetectTime"
type="xs:string" use="optional"/> type="xs:dateTime"/>
<!-- CHANGE - adding indicator set id to connect the reference <xs:element name="StartTime"
to the appropriate set of indicators --> type="xs:dateTime"/>
<xs:attribute name="indicator-set-id" <xs:element name="EndTime"
type="xs:string" use="optional"/> type="xs:dateTime"/>
<!-- CHANGE: Including a unique ID for indicators, may be <xs:element name="Timezone"
used to connect indicators in different representations type="iodef:TimezoneType"/>
--> <xs:simpleType name="TimezoneType">
<xs:attribute name="indicator-uid" <xs:restriction base="xs:string">
type="xs:string" use="optional"/> <xs:pattern value="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]"/>
</xs:complexType> </xs:restriction>
</xs:element> </xs:simpleType>
<!-- <!--
==================================================================== ==================================================================
=== Method class === == History class ==
==================================================================== ==================================================================
--> -->
<xs:element name="Method"> <xs:element name="History">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:choice maxOccurs="unbounded"> <xs:element ref="iodef:HistoryItem"
<xs:element ref="iodef:Reference"/> maxOccurs="unbounded"/>
<xs:element ref="iodef:Description"/> </xs:sequence>
</xs:choice> <xs:attribute name="restriction"
<xs:element ref="iodef:AdditionalData" type="iodef:restriction-type"
minOccurs="0" maxOccurs="unbounded"/> default="default"/>
</xs:sequence> </xs:complexType>
<xs:attribute name="restriction" </xs:element>
type="iodef:restriction-type"/> <xs:element name="HistoryItem">
</xs:complexType> <xs:complexType>
</xs:element> <xs:sequence>
<!-- <xs:element ref="iodef:DateTime"/>
==================================================================== <xs:element ref="iodef:IncidentID"
=== Reference class === minOccurs="0"/>
==================================================================== <xs:element ref="iodef:Contact"
--> minOccurs="0"/>
<xs:element name="Reference"> <xs:element ref="iodef:Description"
<xs:complexType> minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence> <xs:element ref="iodef:AdditionalData"
<xs:element name="ReferenceName" minOccurs="0" maxOccurs="unbounded"/>
type="iodef:MLStringType"/> </xs:sequence>
<xs:element ref="iodef:URL" <xs:attribute name="restriction"
minOccurs="0" maxOccurs="unbounded"/> type="iodef:restriction-type"/>
<xs:element ref="iodef:Description" <xs:attribute name="action"
minOccurs="0" maxOccurs="unbounded"/> type="iodef:action-type" use="required"/>
</xs:sequence> <xs:attribute name="ext-action"
<!-- CHANGE: Do we want an indicator_set_id here to connect type="xs:string" use="optional"/>
data in the reference class to specific indicators? <!-- CHANGE: Including a unique ID for indicators, may be
is there a better way to do this? used to connect indicators in different representations
Should the indicator_uid be used to mark data so that -->
you have a way to limit who you share that data with <xs:attribute name="indicator-uid"
in products? type="xs:string" use="optional"/>
--> <!-- CHANGE: Including an indicator set ID that may be used
<xs:attribute name="indicator-set-id" to detail changes int he history class as it relates to
type="xs:string" use="optional"/> indicators or sets.
<!-- CHANGE: Including a unique ID for indicators, may be -->
used to connect indicators in different representations <xs:attribute name="indicator-set-id"
--> type="xs:string" use="optional"/>
<xs:attribute name="indicator-uid" </xs:complexType>
type="xs:string" use="optional"/> </xs:element>
<!-- Adding in Attack Type --> <!--
<xs:attribute name="attacktype" type="att-type" use="optional"/> ==================================================================
<xs:attribute name="ext-attacktype" == Expectation class ==
type="xs:string" use="optional"/> ==================================================================
</xs:complexType> -->
</xs:element> <xs:element name="Expectation">
<!-- <xs:complexType>
==================================================================== <xs:sequence>
=== Assessment class === <xs:element ref="iodef:Description"
==================================================================== minOccurs="0" maxOccurs="unbounded"/>
--> <xs:element ref="iodef:StartTime"
<xs:element name="Assessment"> minOccurs="0"/>
<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:attribute>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<!-- CHANGE: Including an indicator set ID for indicators, may be
used to connect indicators in different representations
-->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
<!-- CHANGE: Including a unique ID for indicators, may be
used to connect indicators in different representations.
May need separate confidence ratings for different indicators.
-->
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
</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">
<!-- CHANGE question: do we wnt to allow multiple values
to be selected in case it is a combination? -->
<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 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" <xs:element ref="iodef:EndTime"
type="xs:string"/> minOccurs="0"/>
</xs:extension> <xs:element ref="iodef:Contact"
</xs:simpleContent> minOccurs="0"/>
</xs:complexType> </xs:sequence>
</xs:element> <xs:attribute name="restriction"
<xs:element name="Confidence"> type="iodef:restriction-type"
<xs:complexType mixed="true"> default="default"/>
<xs:attribute name="rating" use="required"> <xs:attribute name="severity"
<xs:simpleType> type="iodef:severity-type"/>
<xs:restriction base="xs:NMTOKEN"> <xs:attribute name="action"
<xs:enumeration value="low"/> type="iodef:action-type" default="other"/>
<xs:enumeration value="medium"/> <xs:attribute name="ext-action"
<xs:enumeration value="high"/> type="xs:string" use="optional"/>
<xs:enumeration value="numeric"/> <!-- CHANGE - adding indicator set id to connect the
<xs:enumeration value="unknown"/> reference to the appropriate set of indicators -->
</xs:restriction> <xs:attribute name="indicator-set-id"
</xs:simpleType> type="xs:string" use="optional"/>
</xs:attribute> <!-- CHANGE: Including a unique ID for indicators, may be
</xs:complexType> used to connect indicators in different representations
</xs:element> -->
<!-- <xs:attribute name="indicator-uid"
==================================================================== type="xs:string" use="optional"/>
=== EventData class === </xs:complexType>
==================================================================== </xs:element>
--> <!--
<xs:element name="EventData"> ==================================================================
<xs:complexType> == Method class ==
<xs:sequence> ==================================================================
<xs:element ref="iodef:Description" -->
minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Method">
<xs:element ref="iodef:DetectTime" <xs:complexType>
minOccurs="0"/> <xs:sequence>
<xs:element ref="iodef:StartTime" <xs:choice maxOccurs="unbounded">
minOccurs="0"/> <xs:element ref="iodef:Reference"/>
<xs:element ref="iodef:EndTime" <xs:element ref="iodef:Description"/>
minOccurs="0"/> </xs:choice>
<xs:element ref="iodef:Contact" <xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Assessment" </xs:sequence>
minOccurs="0"/> <xs:attribute name="restriction"
<xs:element ref="iodef:Method" type="iodef:restriction-type"/>
minOccurs="0" maxOccurs="unbounded"/> </xs:complexType>
<xs:element ref="iodef:Flow" </xs:element>
minOccurs="0" maxOccurs="unbounded"/> <!--
<xs:element ref="iodef:Expectation" ==================================================================
minOccurs="0" maxOccurs="unbounded"/> == Reference class ==
<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"/>
<!-- CHANGE - adding an attribute to mark sets of indicators -->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Flow class ===
====================================================================
-->
<!-- Added System unbounded for use only when the source or target watchlist is in use, otherwise only one system entry is expected. -->
<xs:element name="Flow">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:System" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== System class ===
====================================================================
-->
<xs:element name="System">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Node" maxOccurs="unbounded"/>
<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:element name="Reference">
<xs:attribute name="category"> <xs:complexType>
<xs:simpleType> <xs:sequence>
<xs:restriction base="xs:NMTOKEN"> <xs:element name="ReferenceName"
<xs:enumeration value="source"/> type="iodef:MLStringType"/>
<xs:enumeration value="target"/> <xs:element ref="iodef:URL"
<!-- CHANGE - adding two new values to cover watchlist groups --> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="watchlist-source"/> <xs:element ref="iodef:Description"
<xs:enumeration value="watchlist-target"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="intermediate"/> </xs:sequence>
<xs:enumeration value="sensor"/> <!-- CHANGE: Do we want an indicator_set_id here to connect
<xs:enumeration value="infrastructure"/> data in the reference class to specific indicators?
<xs:enumeration value="ext-value"/> is there a better way to do this?
</xs:restriction> Should the indicator_uid be used to mark data so that
</xs:simpleType> you have a way to limit who you share that data with
</xs:attribute> in products?
<xs:attribute name="ext-category" -->
type="xs:string" use="optional"/> <xs:attribute name="indicator-set-id"
<!-- CHANGE - adding an attribute to mark sets of indicators --> type="xs:string" use="optional"/>
<xs:attribute name="indicator-set-id" <!-- CHANGE: Including a unique ID for indicators, may be
type="xs:string" use="optional"/> used to connect indicators in different representations
<xs:attribute name="spoofed" -->
default="unknown"> <xs:attribute name="indicator-uid"
<xs:simpleType> type="xs:string" use="optional"/>
<xs:restriction base="xs:NMTOKEN"> <!-- Adding in Attack Type -->
<xs:enumeration value="unknown"/> <xs:attribute name="attacktype" type="att-type"
<xs:enumeration value="yes"/> use="required">
<xs:enumeration value="no"/> </xs:attribute>
</xs:restriction> <xs:attribute name="ext-attacktype"
</xs:simpleType> type="xs:string" use="optional"/>
</xs:attribute> </xs:complexType>
</xs:complexType> </xs:element>
</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"/>
<!-- CHANGE - added DomainData class and subclasses from RFC5901 -->
<xs:element ref="iodef:DomainData" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="iodef:Address" <!--
minOccurs="0" maxOccurs="unbounded"/> ==================================================================
<!-- Proposed CHANGE: include a URI indicator. == Assessment class ==
Common complaint that URIs were only in the ==================================================================
IODEF schema as references and not part of the -->
incident or included indicators. <xs:element name="Assessment">
Included right now as an address type, below is a <xs:complexType>
second option for how to add it. <xs:sequence>
<xs:element ref="iodef:URL" <xs:choice maxOccurs="unbounded">
minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Impact"/>
--> <xs:element ref="iodef:TimeImpact"/>
</xs:choice> <xs:element ref="iodef:MonetaryImpact"/>
<xs:element ref="iodef:Location" </xs:choice>
minOccurs="0"/> <xs:element ref="iodef:Counter"
<xs:element ref="iodef:DateTime" minOccurs="0" maxOccurs="unbounded"/>
minOccurs="0"/> <xs:element ref="iodef:Confidence" minOccurs="0"/>
<xs:element ref="iodef:NodeRole" <xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter" </xs:sequence>
minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="occurrence">
</xs:sequence> <xs:simpleType>
</xs:complexType> <xs:restriction base="xs:NMTOKEN">
</xs:element> <xs:enumeration value="actual"/>
<xs:element name="Address"> <xs:enumeration value="potential"/>
<xs:complexType> </xs:restriction>
<xs:simpleContent> </xs:simpleType>
<xs:extension base="xs:string"> </xs:attribute>
<xs:attribute name="category" default="ipv4-addr"> <xs:attribute name="restriction"
<xs:simpleType> type="iodef:restriction-type"/>
<xs:restriction base="xs:NMTOKEN"> <!-- CHANGE: Including an indicator set ID for indicators,
<xs:enumeration value="asn"/> may be used to connect indicators in different
<xs:enumeration value="atm"/> representations
<xs:enumeration value="e-mail"/> -->
<xs:enumeration value="mac"/> <xs:attribute name="indicator-set-id"
<xs:enumeration value="ipv4-addr"/> type="xs:string" use="optional"/>
<xs:enumeration value="ipv4-net"/> <!-- CHANGE: Including a unique ID for indicators, may be
<xs:enumeration value="ipv4-net-mask"/> used to connect indicators in different representations.
<xs:enumeration value="ipv6-addr"/> May need separate confidence ratings for different
<xs:enumeration value="ipv6-net"/> indicators.
<xs:enumeration value="ipv6-net-mask"/> -->
<!-- CHANGE - added uri type for site url/uris --> <xs:attribute name="indicator-uid"
<xs:enumeration value="site-uri"/> type="xs:string" use="optional"/>
<xs:enumeration value="ext-value"/> </xs:complexType>
</xs:restriction> </xs:element>
</xs:simpleType> <xs:element name="Impact">
</xs:attribute> <xs:complexType>
<xs:attribute name="ext-category" <xs:simpleContent>
type="xs:string" use="optional"/> <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:attribute name="vlan-name" <!-- CHANGE question: do we want to allow multiple
type="xs:string"/> values to be selected in case it is a combination?
<xs:attribute name="vlan-num" -->
type="xs:integer"/> <xs:enumeration value="admin"/>
<!-- CHANGE: Including a unique ID for indicators, may be <xs:enumeration value="dos"/>
used to connect indicators in different representations <xs:enumeration value="extortion"/>
--> <xs:enumeration value="file"/>
<xs:attribute name="indicator-uid" <xs:enumeration value="info-leak"/>
type="xs:string" use="optional"/> <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 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:extension> </xs:simpleContent>
</xs:simpleContent> </xs:complexType>
</xs:complexType> </xs:element>
</xs:element> <xs:element name="MonetaryImpact">
<xs:element name="Location" type="iodef:MLStringType"/> <xs:complexType>
<xs:element name="NodeRole"> <xs:simpleContent>
<xs:complexType> <xs:extension base="iodef:PositiveFloatType">
<xs:simpleContent> <xs:attribute name="severity"
<xs:extension base="iodef:MLStringType"> type="iodef:severity-type"/>
<xs:attribute name="category" use="required"> <xs:attribute name="currency"
<xs:simpleType> type="xs:string"/>
<xs:restriction base="xs:NMTOKEN"> </xs:extension>
<xs:enumeration value="client"/> </xs:simpleContent>
<xs:enumeration value="server-internal"/> </xs:complexType>
<xs:enumeration value="server-public"/> </xs:element>
<xs:enumeration value="www"/> <xs:element name="Confidence">
<xs:enumeration value="mail"/> <xs:complexType mixed="true">
<xs:enumeration value="messaging"/> <xs:attribute name="rating" use="required">
<xs:enumeration value="streaming"/> <xs:simpleType>
<xs:enumeration value="voice"/> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="file"/> <xs:enumeration value="low"/>
<xs:enumeration value="ftp"/> <xs:enumeration value="medium"/>
<xs:enumeration value="p2p"/> <xs:enumeration value="high"/>
<xs:enumeration value="name"/> <xs:enumeration value="numeric"/>
<xs:enumeration value="directory"/> <xs:enumeration value="unknown"/>
<xs:enumeration value="credential"/> </xs:restriction>
<xs:enumeration value="print"/> </xs:simpleType>
<xs:enumeration value="application"/> </xs:attribute>
<xs:enumeration value="database"/> </xs:complexType>
<xs:enumeration value="infra"/> </xs:element>
<xs:enumeration value="log"/> <!--
<xs:enumeration value="ext-value"/> ==================================================================
</xs:restriction> == EventData class ==
</xs:simpleType> ==================================================================
</xs:attribute> -->
<xs:attribute name="ext-category" <xs:element name="EventData">
type="xs:string" use="optional"/> <xs:complexType>
<xs:attribute name="attacktype" type="att-type" use="optional"/> <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:extension> <xs:element ref="iodef:Assessment"
</xs:simpleContent> minOccurs="0"/>
</xs:complexType> <xs:element ref="iodef:Method"
</xs:element> minOccurs="0" maxOccurs="unbounded"/>
<!-- <xs:element ref="iodef:Flow"
==================================================================== minOccurs="0" maxOccurs="unbounded"/>
=== Service Class === <xs:element ref="iodef:Expectation"
==================================================================== minOccurs="0" maxOccurs="unbounded"/>
--> <xs:element ref="iodef:Record"
<xs:element name="Service"> minOccurs="0"/>
<xs:complexType> <xs:element ref="iodef:EventData"
<xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
<xs:choice minOccurs="0"> <xs:element ref="iodef:AdditionalData"
<xs:element name="Port" minOccurs="0" maxOccurs="unbounded"/>
type="xs:integer"/> </xs:sequence>
<xs:element name="Portlist" <xs:attribute name="restriction"
type="iodef:PortlistType"/> type="iodef:restriction-type" default="default"/>
</xs:choice> <!-- CHANGE - added attribute to mark sets of indicators -->
<xs:element name="ProtoType" <xs:attribute name="indicator-set-id"
type="xs:integer" minOccurs="0"/> type="xs:string" use="optional"/>
<xs:element name="ProtoCode" </xs:complexType>
type="xs:integer" minOccurs="0"/> </xs:element>
<xs:element name="ProtoField" <!--
type="xs:integer" minOccurs="0"/> ==================================================================
<xs:element ref="iodef:Application" == Flow class ==
minOccurs="0"/> ==================================================================
<!-- CHANGE - email from address indicator, may be better as a sub class? -->
CHANGED to a sub-class <!-- Added System unbounded for use only when the source or
Would only make sense with the service set to email ports target watchlist is in use, otherwise only one system entry
or none at all here or a new class. --> is expected.
<xs:element name="EmailInfo" type="EmailDetails" minOccurs="0"/> -->
<!-- CHANGE - added DomainData class and subclasses from RFC5901 -->
<xs:element ref="iodef:DomainData" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ip_protocol"
type="xs:integer" use="required"/>
<!-- CHANGE: Including a unique ID for indicators, may be
used to connect indicators in different representations
-->
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
<!-- CHANGE: Including an indicator set ID that may be used
to detail changes int he history class as it relates to
indicators or sets.
-->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
</xs:complexType> <xs:element name="Flow">
</xs:element> <xs:complexType>
<xs:simpleType name="PortlistType"> <xs:sequence>
<xs:restriction base="xs:string"> <xs:element ref="iodef:System"
<xs:pattern value="\d+(\-\d+)?(,\d+(\-\d+)?)*"/> maxOccurs="unbounded"/>
</xs:restriction> </xs:sequence>
</xs:simpleType> </xs:complexType>
<!-- </xs:element>
==================================================================== <!--
=== Counter class === ==================================================================
==================================================================== == System class ==
--> ==================================================================
<xs:element name="Counter"> -->
<xs:complexType> <xs:element name="System">
<xs:simpleContent> <xs:complexType>
<xs:extension base="xs:double"> <xs:sequence>
<xs:attribute name="type" use="required"> <xs:element ref="iodef:Node" maxOccurs="unbounded"/>
<xs:simpleType> <xs:element ref="iodef:Service"
<xs:restriction base="xs:NMTOKEN"> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="byte"/> <xs:element ref="iodef:OperatingSystem"
<xs:enumeration value="packet"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="flow"/> <xs:element ref="iodef:Counter"
<xs:enumeration value="session"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="event"/> <xs:element ref="iodef:Description"
<xs:enumeration value="alert"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="message"/> <xs:element ref="iodef:AdditionalData"
<xs:enumeration value="host"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="site"/> </xs:sequence>
<xs:enumeration value="organization"/> <xs:attribute name="restriction"
<xs:enumeration value="ext-value"/> type="iodef:restriction-type"/>
</xs:restriction> <xs:attribute name="interface"
</xs:simpleType> type="xs:string"/>
</xs:attribute> <xs:attribute name="category">
<xs:attribute name="ext-type" <xs:simpleType>
type="xs:string" use="optional"/> <xs:restriction base="xs:NMTOKEN">
<xs:attribute name="meaning" <xs:enumeration value="source"/>
type="xs:string" use="optional"/> <xs:enumeration value="target"/>
<xs:attribute name="duration" <!-- CHANGE - adding two new values to cover
type="iodef:duration-type"/> watchlist groups -->
<xs:attribute name="ext-duration" <xs:enumeration value="watchlist-source"/>
type="xs:string" use="optional"/> <xs:enumeration value="watchlist-target"/>
</xs:extension> <xs:enumeration value="intermediate"/>
</xs:simpleContent> <xs:enumeration value="sensor"/>
</xs:complexType> <xs:enumeration value="infrastructure"/>
</xs:element> <xs:enumeration value="ext-value"/>
<!-- </xs:restriction>
==================================================================== </xs:simpleType>
=== EMailDetails class === </xs:attribute>
==================================================================== <xs:attribute name="ext-category"
--> type="xs:string" use="optional"/>
<!-- CHANGE: added the email details in a subclass for use when you <!-- CHANGE - adding an attribute to mark sets of
do not need all of the email details provided in the RFC5901 or ARF indicators -->
extensions. No extension mechanism here, is it needed? <xs:attribute name="indicator-set-id"
Possible to create an IANA table to extend this class if needed type="xs:string" use="optional"/>
in the future outside of schema edit cycles --> <xs:attribute name="spoofed"
<xs:complexType name="EmailDetails"> default="unknown">
<xs:sequence> <xs:simpleType>
<!-- Email is the From email --> <xs:restriction base="xs:NMTOKEN">
<xs:element ref="Email" minOccurs="0"/> <xs:enumeration value="unknown"/>
<xs:element name="EmailSubject" <xs:enumeration value="yes"/>
type="iodef:MLStringType" minOccurs="0"/> <xs:enumeration value="no"/>
<xs:element name="X-Mailer" </xs:restriction>
type="iodef:MLStringType" minOccurs="0"/> </xs:simpleType>
</xs:sequence> </xs:attribute>
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
</xs:complexType>
<!-- </xs:complexType>
==================================================================== </xs:element>
=== DomainData class - from RFC5901 === <!--
==================================================================== ==================================================================
--> == Node class ==
<xs:element name="DomainData"> ==================================================================
<xs:complexType id="DomainData.type"> -->
<xs:sequence> <xs:element name="Node">
<xs:element maxOccurs="1" <xs:complexType>
name="Name" type="iodef:MLStringType"/> <xs:sequence>
<xs:element maxOccurs="1" minOccurs="0" <xs:choice maxOccurs="unbounded">
name="DateDomainWasChecked" type="xs:dateTime"/> <xs:element name="NodeName"
<xs:element maxOccurs="1" minOccurs="0" name="RegistrationDate" type="iodef:MLStringType" minOccurs="0"/>
type="xs:dateTime"/> <!-- CHANGE - added DomainData class and subclasses from
<xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate" RFC5901 -->
type="xs:dateTime"/> <xs:element ref="iodef:DomainData" minOccurs="0"
<xs:element maxOccurs="unbounded" minOccurs="0" name="RelatedDNS" maxOccurs="unbounded"/>
type="iodef:RelatedDNSEntryType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="Nameservers">
<xs:complexType id="Nameservers.type">
<xs:sequence>
<xs:element name="Server" type="iodef:MLStringType"/>
<xs:element ref="iodef:Address" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice id="DomainContacts" maxOccurs="1" minOccurs="0">
<xs:element name="SameDomainContact"
type="iodef:MLStringType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:Contact"/>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attribute name="SystemStatus">
<xs:simpleType id="SystemStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="spoofed"/>
<xs:enumeration value="fraudulent"/>
<xs:enumeration value="innocent-hacked"/>
<xs:enumeration value="innocent-hijacked"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="DomainStatus"> <xs:element ref="iodef:Address"
<xs:simpleType id="DomainStatus.type"> minOccurs="0" maxOccurs="unbounded"/>
<xs:restriction base="xs:string"> <!-- Proposed CHANGE: include a URI indicator.
<xs:enumeration value="reservedDelegation"/> Common complaint that URIs were only in the
<xs:enumeration value="assignedAndActive"/> IODEF schema as references and not part of the
<xs:enumeration value="assignedAndInactive"/> incident or included indicators.
<xs:enumeration value="assignedAndOnHold"/> Included right now as an address type, below is a
<xs:enumeration value="revoked"/> second option for how to add it.
<xs:enumeration value="transferPending"/> <xs:element ref="iodef:URL"
<xs:enumeration value="registryLock"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="registrarLock"/> -->
<xs:enumeration value="other"/> </xs:choice>
<xs:enumeration value="unknown"/> <xs:element ref="iodef:Location"
</xs:restriction> minOccurs="0"/>
</xs:simpleType> <xs:element ref="iodef:DateTime"
</xs:attribute> minOccurs="0"/>
</xs:complexType> <xs:element ref="iodef:NodeRole"
</xs:element> 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"/>
<!-- CHANGE - added uri type for site url/uris -->
<xs:enumeration value="site-uri"/>
<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"/>
<!-- CHANGE: Including a unique ID for indicators, may be
used to connect indicators in different representations
-->
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
<xs:element name="RelatedDNS" </xs:extension>
type="iodef:RelatedDNSEntryType"/> </xs:simpleContent>
<xs:complexType name="RelatedDNSEntryType"> </xs:complexType>
<xs:simpleContent> </xs:element>
<xs:extension base="xs:string"> <xs:element name="Location" type="iodef:MLStringType"/>
<xs:attribute name="RecordType" use="optional"> <xs:element name="NodeRole">
<xs:simpleType> <xs:complexType>
<xs:restriction base="xs:NMTOKEN"> <xs:simpleContent>
<xs:enumeration value="A"/> <xs:extension base="iodef:MLStringType">
<xs:enumeration value="AAAA"/> <xs:attribute name="category" use="required">
<xs:enumeration value="AFSDB"/> <xs:simpleType>
<xs:enumeration value="APL"/> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="AXFR"/> <xs:enumeration value="client"/>
<xs:enumeration value="CAA"/> <xs:enumeration value="client-enterprise"/>
<xs:enumeration value="CERT"/> <xs:enumeration value="client-partner"/>
<xs:enumeration value="CNAME"/> <xs:enumeration value="client-remote"/>
<xs:enumeration value="DHCID"/> <xs:enumeration value="client-kiosk"/>
<xs:enumeration value="DLV"/> <xs:enumeration value="client-mobile"/>
<xs:enumeration value="DNAME"/> <xs:enumeration value="server-internal"/>
<xs:enumeration value="DNSKEY"/> <xs:enumeration value="server-public"/>
<xs:enumeration value="DS"/> <xs:enumeration value="www"/>
<xs:enumeration value="HIP"/> <xs:enumeration value="mail"/>
<xs:enumeration value="IXFR"/> <xs:enumeration value="messaging"/>
<xs:enumeration value="IPSECKEY"/> <xs:enumeration value="streaming"/>
<xs:enumeration value="LOC"/> <xs:enumeration value="voice"/>
<xs:enumeration value="MX"/> <xs:enumeration value="file"/>
<xs:enumeration value="NAPTR"/> <xs:enumeration value="ftp"/>
<xs:enumeration value="NS"/> <xs:enumeration value="p2p"/>
<xs:enumeration value="NSEC"/> <xs:enumeration value="name"/>
<xs:enumeration value="NSEC3"/> <xs:enumeration value="directory"/>
<xs:enumeration value="NSEC3PARAM"/> <xs:enumeration value="credential"/>
<xs:enumeration value="OPT"/> <xs:enumeration value="print"/>
<xs:enumeration value="PTR"/> <xs:enumeration value="application"/>
<xs:enumeration value="RRSIG"/> <xs:enumeration value="database"/>
<xs:enumeration value="RP"/> <xs:enumeration value="backup"/>
<xs:enumeration value="SIG"/> <xs:enumeration value="dhcp"/>
<xs:enumeration value="SOA"/> <xs:enumeration value="infra"/>
<xs:enumeration value="SPF"/> <xs:enumeration value="infra-firewall"/>
<xs:enumeration value="SRV"/> <xs:enumeration value="infra-router"/>
<xs:enumeration value="SSHFP"/> <xs:enumeration value="infra-switch"/>
<xs:enumeration value="TA"/> <xs:enumeration value="camera"/>
<xs:enumeration value="TKEY"/> <xs:enumeration value="proxy"/>
<xs:enumeration value="TLSA"/> <xs:enumeration value="remote-access"/>
<xs:enumeration value="TSIG"/> <xs:enumeration value="log"/>
<xs:enumeration value="TXT"/> <xs:enumeration value="virtualization"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="pos"/>
</xs:restriction> <xs:enumeration value="scada"/>
</xs:simpleType> <xs:enumeration value="scada-supervisory"/>
</xs:attribute> <xs:enumeration value="ext-value"/>
<xs:attribute name="ext-category" </xs:restriction>
type="xs:string" use="optional"/> </xs:simpleType>
</xs:extension> </xs:attribute>
</xs:simpleContent> <xs:attribute name="ext-category"
</xs:complexType> type="xs:string" use="optional"/>
<!-- <xs:attribute name="attacktype" type="att-type"
==================================================================== use="optional"/>
=== 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"
minOccurs="0"/>
<xs:element ref="iodef:RecordPattern"
minOccurs="0" maxOccurs="unbounded"/>
<!-- Added a minOccurs of 0 since you can just have HashInformation now -->
<xs:element ref="iodef:RecordItem" minOccurs="0"
maxOccurs="unbounded"/>
<!-- CHANGE: Class to represent file and hash or digital signature </xs:extension>
information --> </xs:simpleContent>
<xs:element name="HashInformation" type="HashSigDetails" </xs:complexType>
minOccurs="0" maxOccurs="unbounded"/> </xs:element>
<!-- CHANGE: Windows Registry Key Modifications: <!--
Here, we include the classes from iodef-phish, to ==================================================================
prevent the need to pull in the full schema. == Service Class ==
Ensure reference to RFC5901 Section 5.9.7 remains ==================================================================
included in UML description. -->
<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"/>
<!-- CHANGE - email from address indicator, may be better as a sub
class? Would only make sense with the service set to
email ports or none at all here or a new class. -->
<xs:element ref="Email" minOccurs="0"/>
<xs:element name="EmailSubject"
type="iodef:MLStringType" minOccurs="0"/>
<xs:element name="X-Mailer"
type="iodef:MLStringType" minOccurs="0"/>
<xs:element name="EmailInfo"
type="EmailDetails" minOccurs="0"/>
<!-- CHANGE - added DomainData class and subclasses from
RFC5901 -->
<xs:element ref="iodef:DomainData" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ip_protocol"
type="xs:integer" use="required"/>
<!-- CHANGE: Including a unique ID for indicators, may be
used to connect indicators in different representations
--> -->
<xs:element name="WindowsRegistryKeysModified" type="RegistryKeyModified" <xs:attribute name="indicator-uid"
minOccurs="0" maxOccurs="unbounded"/> type="xs:string" use="optional"/>
<xs:element ref="iodef:AdditionalData" <!-- CHANGE: Including an indicator set ID that may be used
minOccurs="0" maxOccurs="unbounded"/> to detail changes int he history class as it relates to
indicators or sets.
-->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
</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: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>
<!--
==================================================================
== EMailDetails class ==
==================================================================
-->
<!-- CHANGE: added the email details in a subclass for use when
you do not need all of the email details provided in the
RFC5901 or ARF extensions. No extension mechanism here, is it
needed? Possible to create an IANA table to extend this class
if needed in the future outside of schema edit cycles -->
<xs:complexType name="EmailDetails">
<xs:sequence>
<!-- Email is the From email -->
<xs:element ref="Email" minOccurs="0"/>
<xs:element name="EmailSubject"
type="iodef:MLStringType" minOccurs="0"/>
<xs:element name="X-Mailer"
type="iodef:MLStringType" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<!-- CHANGE: Including a unique ID for an indicator.
-->
<xs:attribute name="indicator-uid" <xs:attribute name="indicator-uid"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<!-- CHANGE: Including a unique ID for sets of indicators, may be
used to connect indicators in different representations
-->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:element name="RecordPattern"> <!--
<xs:complexType> ==================================================================
== DomainData class - from RFC5901 ==
==================================================================
-->
<xs:element name="DomainData">
<xs:complexType id="DomainData.type">
<xs:sequence>
<xs:element maxOccurs="1"
name="Name" type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="DateDomainWasChecked" type="xs:dateTime"/>
<xs:element name="RegistrationDate"
type="xs:dateTime" maxOccurs="1" minOccurs="0"/>
<xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
type="xs:dateTime"/>
<xs:element name="RelatedDNS"
type="iodef:RelatedDNSEntryType"
maxOccurs="unbounded" minOccurs="0" />
<xs:element name="Nameservers"
maxOccurs="unbounded" minOccurs="0" />
<xs:complexType id="Nameservers.type">
<xs:sequence>
<xs:element name="Server" type="iodef:MLStringType"/>
<xs:element ref="iodef:Address" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice id="DomainContacts" maxOccurs="1" minOccurs="0">
<xs:element name="SameDomainContact"
type="iodef:MLStringType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:Contact"/>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attribute name="SystemStatus">
<xs:simpleType id="SystemStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="spoofed"/>
<xs:enumeration value="fraudulent"/>
<xs:enumeration value="innocent-hacked"/>
<xs:enumeration value="innocent-hijacked"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="DomainStatus">
<xs:simpleType id="DomainStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="reservedDelegation"/>
<xs:enumeration value="assignedAndActive"/>
<xs:enumeration value="assignedAndInactive"/>
<xs:enumeration value="assignedAndOnHold"/>
<xs:enumeration value="revoked"/>
<xs:enumeration value="transferPending"/>
<xs:enumeration value="registryLock"/>
<xs:enumeration value="registrarLock"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="RelatedDNS"
type="iodef:RelatedDNSEntryType"/>
<xs:complexType name="RelatedDNSEntryType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="type" use="required"> <xs:attribute name="RecordType" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="regex"/> <xs:enumeration value="A"/>
<xs:enumeration value="binary"/> <xs:enumeration value="AAAA"/>
<xs:enumeration value="xpath"/> <xs:enumeration value="AFSDB"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="APL"/>
</xs:restriction> <xs:enumeration value="AXFR"/>
</xs:simpleType> <xs:enumeration value="CAA"/>
</xs:attribute> <xs:enumeration value="CERT"/>
<xs:attribute name="ext-type" <xs:enumeration value="CNAME"/>
type="xs:string" use="optional"/> <xs:enumeration value="DHCID"/>
<xs:attribute name="offset" <xs:enumeration value="DLV"/>
type="xs:integer" use="optional"/> <xs:enumeration value="DNAME"/>
<xs:attribute name="offsetunit" <xs:enumeration value="DNSKEY"/>
use="optional" default="line"> <xs:enumeration value="DS"/>
<xs:simpleType> <xs:enumeration value="HIP"/>
<xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="IXFR"/>
<xs:enumeration value="line"/> <xs:enumeration value="IPSECKEY"/>
<xs:enumeration value="byte"/> <xs:enumeration value="LOC"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="MX"/>
</xs:restriction> <xs:enumeration value="NAPTR"/>
</xs:simpleType> <xs:enumeration value="NS"/>
</xs:attribute> <xs:enumeration value="NSEC"/>
<xs:attribute name="ext-offsetunit" <xs:enumeration value="NSEC3"/>
type="xs:string" use="optional"/> <xs:enumeration value="NSEC3PARAM"/>
<xs:attribute name="instance" <xs:enumeration value="OPT"/>
type="xs:integer" use="optional"/> <xs:enumeration value="PTR"/>
</xs:extension> <xs:enumeration value="RRSIG"/>
</xs:simpleContent> <xs:enumeration value="RP"/>
<xs:enumeration value="SIG"/>
<xs:enumeration value="SOA"/>
<xs:enumeration value="SPF"/>
<xs:enumeration value="SRV"/>
<xs:enumeration value="SSHFP"/>
<xs:enumeration value="TA"/>
<xs:enumeration value="TKEY"/>
<xs:enumeration value="TLSA"/>
<xs:enumeration value="TSIG"/>
<xs:enumeration value="TXT"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:element name="RecordItem"
type="iodef:ExtensionType"/>
<!--
====================================================================
=== Class to describe Windows Registry Keys ===
====================================================================
-->
<xs:complexType name="RegistryKeyModified">
<xs:sequence>
<xs:element name="Key" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<!-- Allows for the value to be optional for cases such as,
the registry key was deleted -->
<xs:element name="KeyName" type="xs:string"/>
<xs:element name="Value" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="registryaction">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="add_key"/>
<xs:enumeration value="add_value"/>
<xs:enumeration value="delete_key"/>
<xs:enumeration value="delete_value"/>
<xs:enumeration value="modify_key"/>
<xs:enumeration value="modify_value"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<!-- CHANGE: Including the ability to set the grouping as a watchlist. -->
<xs:attribute name="type" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="watchlist"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
<!-- CHANGE: Including a unique ID for indicators, may be
used to connect indicators in different representations
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
<!-- CHANGE: Including an indicator set ID that may be used
to detail changes in the history class as it relates to
indicators or sets.
<xs:attribute name="indicator-set-id" <!--
type="xs:string" use="optional"/> ==================================================================
== 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"
minOccurs="0"/>
<xs:element ref="iodef:RecordPattern"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:RecordItem"
maxOccurs="unbounded"/>
</xs:complexType> <!-- CHANGE: File name and hash of file indicator
</xs:element> information -->
<xs:element name="FileName"
type="iodef:MLStringType" minOccurs="0"/>
<!-- Represent file hash information via digsig schema
Reference class -->
<xs:element ref="ds:Reference" minOccurs="0"/>
<!-- CHANGE: Windows Registry Key Modifications:
Here, we include the classes from iodef-phish, to
prevent the need to pull in the full schema.
Ensure reference to RFC5901 Section 5.9.7 remains
included in UML description.
-->
<xs:element name="WindowsRegistryKeysModified"
type="RegistryKeyModified"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<!-- CHANGE: Including a unique ID for an indicator.
-->
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
<!-- CHANGE: Including a unique ID for sets of indicators,
may be used to connect indicators in different
representations
-->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
</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>
<xs:element name="RecordItem"
type="iodef:ExtensionType"/>
<!--
==================================================================
== Class to describe Windows Registry Keys ==
==================================================================
-->
<xs:complexType name="RegistryKeyModified">
<xs:sequence>
<xs:element name="Key" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<!-- Allows for the value to be optional for cases
such as, the registry key was deleted -->
<xs:element name="KeyName" type="xs:string"/>
<xs:element name="Value"
type="xs:string" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> <xs:attribute name="registryaction">
<!-- CHANGE: Should this be broken out as another class <xs:simpleType>
for WindowsRegistryKeyModified and add attributes <xs:restriction base="xs:NMTOKEN">
for indicator_ID and action - add_value, removes_value, etc. <xs:enumeration value="add-key"/>
as is demonstrated? <xs:enumeration value="add-value"/>
<xs:enumeration value="delete-key"/>
<xs:enumeration value="delete-value"/>
<xs:enumeration value="modify-key"/>
<xs:enumeration value="modify-value"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<!-- CHANGE: Including a unique ID for indicators, may be
used to connect indicators in different representations
-->
<xs:attribute name="indicator-uid"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!-- CHANGE: Including an indicator set ID that may be used
to detail changes int he history class as it relates to
indicators or sets.
-->
<xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/>
</xs:sequence>
</xs:complexType>
<!-- CHANGE: Should this be broken out as another class
for WindowsRegistryKeyModified and add attributes
for indicator_ID and action - add_value, removes_value, etc.
as is demonstrated?
-->
<!-- <!--
==================================================================== ==================================================================
=== Classes that describe hash types, file information === == Classes that describe hash types, file information ==
=== with certificate properties and digital signature info === == with certificate properties and digital signature info ==
=== provided through the W3C digital signature schema === == provided through the W3C digital signature schema ==
=== so it does not need to be maintained here. === == so it does not need to be maintained here. ==
==================================================================== ==================================================================
--> -->
<xs:complexType name="HashSigDetails"> <xs:complexType name="HashSigDetails">
<xs:sequence> <xs:sequence>
<xs:element name="FileName" <xs:element name="FileName" type="iodef:MLStringType"
type="iodef:MLStringType" minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<!-- QUESTION: For FileSize, need to specify the unit this is provided in <xs:element name="FileSize" type="xs:integer"
assume kb? --> minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="FileSize" <!-- CHANGE: Represent file hash information via digsig schema
type="xs:integer" minOccurs="0" maxOccurs="unbounded"/> and the Reference class. You may need any of the other classes
<!-- CHANGE: Represent file hash information via digsig schema and in particular the KeyInfo (see RFC3275 sect 4.4.4/4.4.5),
and the Reference class. You may need any of the other classes which has been added. KeyName, KeyValue, SignatureProperties
and in particular the KeyInfo (see RFC3275 sect 4.4.4 and 4.4.5), classes may be useful, so Signature was added, but you can use
which has been added. KeyName, KeyValue, SignatureProperties KeyInfo and Reference directly to avoid some bloat. -->
classes may be useful, so Signature was added, but you can use <xs:element ref="ds:Signature"
KeyInfo and Reference directly to avoid some bloat. --> minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ds:Signature" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="ds:KeyInfo"
<xs:element ref="ds:KeyInfo" minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="ds:Reference" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="ds:Reference"
<!-- QUESTION: Do we want an AdditionalData here? --> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> <!-- QUESTION: Do we want an AdditionalData here? -->
<xs:attribute name="type" use="optional"> </xs:sequence>
<xs:simpleType> <xs:attribute name="type" use="optional">
<xs:restriction base="xs:NMTOKEN"> <xs:simpleType>
<!-- W3C digsig should be used to denote PGP or PKI --> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="PKI_email_ds"/> <xs:enumeration value="PKI-email-ds"/>
<xs:enumeration value="PKI_file_ds"/> <xs:enumeration value="PKI-file-ds"/>
<xs:enumeration value="PKI_email_ds_watchlist"/> <xs:enumeration value="PKI-email-ds-watchlist"/>
<xs:enumeration value="PKI_file_ds_watchlist"/> <xs:enumeration value="PKI-file-ds-watchlist"/>
<xs:enumeration value="PGP_email_ds"/> <xs:enumeration value="PGP-email-ds"/>
<xs:enumeration value="PGP_file_ds"/> <xs:enumeration value="PGP-file-ds"/>
<xs:enumeration value="PGP_email_ds_watchlist"/> <xs:enumeration value="PGP-email-ds-watchlist"/>
<xs:enumeration value="PGP_file_ds_watchlist"/> <xs:enumeration value="PGP-file-ds-watchlist"/>
<!-- hash of the file or email and not a digital signature hash --> <xs:enumeration value="file-hash"/>
<xs:enumeration value="file_hash"/> <xs:enumeration value="email-hash"/>
<xs:enumeration value="email_hash"/> <xs:enumeration value="file-hash-watchlist"/>
<xs:enumeration value="file_hash_watchlist"/> <xs:enumeration value="email-hash-watchlist"/>
<xs:enumeration value="email_hash_watchlist"/> <!-- QUESTION: Are values needed to differentiate the
<!-- QUESTION: Are values needed to differentiate the key information key information shared when the ds:KeyInfo class
shared when the ds:KeyInfo class is referenced? --> is referenced? -->
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="ext-category" <xs:attribute name="ext-category"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<!-- Adding a boolean yes/no, 0/1option to indicate if the <!-- Adding a boolean yes/no, 0/1option to indicate if the
signature or hash is valid --> signature or hash is valid -->
<xs:attribute name="valid" type="xs:boolean" use="optional"></xs:attribute> <xs:attribute name="valid" type="xs:boolean" use="optional" />
<!-- Indicator-uid and indicator-set-id to connect to the related <!-- Indicator-uid and indicator-set-id to connect to the
file or email indicators outside of this class --> related file or email indicators outside of this class -->
<xs:attribute name="indicator-uid" <xs:attribute name="indicator-uid"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="indicator-set-id" <xs:attribute name="indicator-set-id"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="restriction" <xs:attribute name="restriction"
type="iodef:restriction-type"/> type="iodef:restriction-type"/>
</xs:complexType> </xs:complexType>
<!--
====================================================================
=== 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"/> ==================================================================
<!-- CHANGE: Should UserAgent or HTTPUserAgent fit in == Classes that describe software ==
SoftwareTypes? This is typically intended to mean ==================================================================
servers, but the category seems more appropriate
than others.
--> -->
<xs:attribute name="user-agent" <xs:complexType name="SoftwareType">
type="xs:string"/> <xs:sequence>
<xs:attribute name="version" <xs:element ref="iodef:URL"
type="xs:string"/> minOccurs="0"/>
<xs:attribute name="patch" </xs:sequence>
type="xs:string"/> <xs:attribute name="swid"
</xs:complexType> type="xs:string" default="0"/>
<xs:element name="Application" <xs:attribute name="configid"
type="iodef:SoftwareType"/> type="xs:string" default="0"/>
<xs:element name="OperatingSystem" <xs:attribute name="vendor"
type="iodef:SoftwareType"/> type="xs:string"/>
<xs:attribute name="family"
type="xs:string"/>
<xs:attribute name="name"
type="xs:string"/>
<!-- CHANGE: Should UserAgent or HTTPUserAgent fit in
SoftwareTypes? This is typically intended to mean
servers, but the category seems more appropriate
than others.
-->
<xs:attribute name="user-agent"
type="xs:string"/>
<!-- <xs:attribute name="version"
==================================================================== type="xs:string"/>
=== Miscellaneous simple classes === <xs:attribute name="patch"
==================================================================== type="xs:string"/>
--> </xs:complexType>
<xs:element name="Description" <xs:element name="Application"
type="iodef:MLStringType"/> type="iodef:SoftwareType"/>
<xs:element name="URL" <xs:element name="OperatingSystem"
type="xs:anyURI"/> type="iodef:SoftwareType"/>
<!--
====================================================================
=== Data Types ===
====================================================================
-->
<xs:simpleType name="PositiveFloatType">
<xs:restriction base="xs:float">
<xs:minExclusive value="0"/>
</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"/> == Miscellaneous simple classes ==
<xs:enumeration value="medium"/> ==================================================================
<xs:enumeration value="high"/> -->
</xs:restriction> <xs:element name="Description"
</xs:simpleType> type="iodef:MLStringType"/>
<xs:simpleType name="duration-type"> <xs:element name="URL"
<xs:restriction base="xs:NMTOKEN"> type="xs:anyURI"/>
<xs:enumeration value="second"/> <!--
<xs:enumeration value="minute"/> ==================================================================
<xs:enumeration value="hour"/> == Data Types ==
<xs:enumeration value="day"/> ==================================================================
<xs:enumeration value="month"/> -->
<xs:enumeration value="quarter"/> <xs:simpleType name="PositiveFloatType">
<xs:enumeration value="year"/> <xs:restriction base="xs:float">
<xs:enumeration value="ext-value"/> <xs:minExclusive value="0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="action-type"> <xs:complexType name="MLStringType">
<xs:restriction base="xs:NMTOKEN"> <xs:simpleContent>
<xs:enumeration value="nothing"/> <xs:extension base="xs:string">
<xs:enumeration value="contact-source-site"/> <xs:attribute name="lang"
<xs:enumeration value="contact-target-site"/> type="xs:language" use="optional"/>
<xs:enumeration value="contact-sender"/> </xs:extension>
<xs:enumeration value="investigate"/> </xs:simpleContent>
<xs:enumeration value="block-host"/> </xs:complexType>
<xs:enumeration value="block-network"/> <xs:complexType name="ExtensionType" mixed="true">
<xs:enumeration value="block-port"/> <xs:sequence>
<xs:enumeration value="rate-limit-host"/> <xs:any namespace="##any" processContents="lax"
<xs:enumeration value="rate-limit-network"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:enumeration value="rate-limit-port"/> </xs:sequence>
<xs:enumeration value="remediate-other"/> <xs:attribute name="dtype"
<xs:enumeration value="status-triage"/> type="iodef:dtype-type" use="required"/>
<xs:enumeration value="status-new-info"/> <xs:attribute name="ext-dtype"
<xs:enumeration value="other"/> type="xs:string" use="optional"/>
<xs:enumeration value="ext-value"/> <xs:attribute name="meaning"
</xs:restriction> type="xs:string"/>
</xs:simpleType>
<xs:simpleType name="dtype-type"> <xs:attribute name="formatid"
<xs:restriction base="xs:NMTOKEN"> type="xs:string"/>
<xs:enumeration value="boolean"/> <xs:attribute name="restriction"
<xs:enumeration value="byte"/> type="iodef:restriction-type"/>
<xs:enumeration value="character"/> </xs:complexType>
<xs:enumeration value="date-time"/> <!--
<xs:enumeration value="integer"/> ==================================================================
<xs:enumeration value="ntpstamp"/> == Global attribute type declarations ==
<xs:enumeration value="portlist"/> ==================================================================
<xs:enumeration value="real"/> -->
<xs:enumeration value="string"/> <xs:simpleType name="restriction-type">
<xs:enumeration value="file"/> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="path"/> <xs:enumeration value="default"/>
<xs:enumeration value="frame"/> <xs:enumeration value="public"/>
<xs:enumeration value="packet"/> <xs:enumeration value="partner"/>
<xs:enumeration value="ipv4-packet"/> <xs:enumeration value="need-to-know"/>
<xs:enumeration value="ipv6-packet"/> <xs:enumeration value="private"/>
<xs:enumeration value="url"/> <xs:enumeration value="white"/>
<xs:enumeration value="csv"/> <xs:enumeration value="green"/>
<xs:enumeration value="winreg"/> <xs:enumeration value="amber"/>
<xs:enumeration value="xml"/> <xs:enumeration value="red"/>
<xs:enumeration value="ext-value"/> </xs:restriction>
</xs:restriction> </xs:simpleType>
</xs:simpleType>
<xs:simpleType name="att-type"> <xs:simpleType name="severity-type">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<!-- CHANGE - added two values per July IETF discussion <xs:enumeration value="low"/>
adding command and control server and sink hole <xs:enumeration value="medium"/>
bringing forward the 'FraudType' from RFC5901 <xs:enumeration value="high"/>
--> </xs:restriction>
<xs:enumeration value="c2-server"/> </xs:simpleType>
<xs:enumeration value="sink-hole"/> <xs:simpleType name="duration-type">
<xs:enumeration value="malware-distribution"/> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="phishing"/> <xs:enumeration value="second"/>
<xs:enumeration value="spear-phishing"/> <xs:enumeration value="minute"/>
<xs:enumeration value="recruiting"/> <xs:enumeration value="hour"/>
<xs:enumeration value="fraudulent-site"/> <xs:enumeration value="day"/>
<xs:enumeration value="dns-spoof"/> <xs:enumeration value="month"/>
<xs:enumeration value="other"/> <xs:enumeration value="quarter"/>
<xs:enumeration value="unknown"/> <xs:enumeration value="year"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema>
<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="watch-and-report"/>
<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: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:simpleType name="att-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="c2-server"/>
<xs:enumeration value="sink-hole"/>
<xs:enumeration value="malware-distribution"/>
<xs:enumeration value="phishing"/>
<xs:enumeration value="spear-phishing"/>
<xs:enumeration value="recruiting"/>
<xs:enumeration value="fraudulent-site"/>
<xs:enumeration value="dns-spoof"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
<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 The IODEF data model itself does not directly introduce security
issues. Rather, it simply defines a representation for incident issues. Rather, it simply defines a representation for incident
information. As the data encoded by the IODEF might be considered information. As the data encoded by the IODEF might be considered
privacy sensitive by the parties exchanging the information or by privacy sensitive by the parties exchanging the information or by
those described by it, care needs to be taken in ensuring the those described by it, care needs to be taken in ensuring the
appropriate disclosure during both document exchange and subsequent appropriate disclosure during both document exchange and subsequent
processing. The former must be handled by a messaging format, but processing. The former must be handled by a messaging format, but
skipping to change at page 104, line 18 skipping to change at page 105, line 12
the sender, as the recipient is free to ignore it. The issue of the sender, as the recipient is free to ignore it. The issue of
enforcement is not a technical problem. enforcement is not a technical problem.
10. IANA Considerations 10. IANA Considerations
This document uses URNs to describe an XML namespace and schema This document uses URNs to describe an XML namespace and schema
conforming to a registry mechanism described in [15] 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-2.0
o Registrant Contact: See the first author of the "Author's Address" o Registrant Contact: See the first author of the "Author's Address"
section of this document. 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-2.0
o Registrant Contact: See the first author of the "Author's Address" o Registrant Contact: See the first author of the "Author's Address"
section of this document. 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, The following groups and individuals, listed alphabetically,
contributed substantially to this document and should be recognized contributed substantially to this document and should be recognized
skipping to change at page 105, line 16 skipping to change at page 106, line 9
o Brian Trammell, ETH Zurich o Brian Trammell, ETH Zurich
o Jan Meijer, SURFnet bv o Jan Meijer, SURFnet bv
o Yuri Demchenko, University of Amsterdam o Yuri Demchenko, University of Amsterdam
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] World Wide Web Consortium, "Extensible Markup Language (XML) [1] World Wide Web Consortium, "Extensible Markup Language
1.0 (Second Edition)", W3C Recommendation , October 2000, (XML) 1.0 (Second Edition)", W3C Recommendation , October
<http://www.w3.org/TR/2000/REC-xml-20001006>. 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[2] World Wide Web Consortium, "XML XML Schema Part 1: Structures [2] World Wide Web Consortium, "XML XML Schema Part 1:
Second Edition", W3C Recommendation , October 2004, Structures Second Edition", W3C Recommendation , October
<http://www.w3.org/TR/xmlschema-1/>. 2004, <http://www.w3.org/TR/xmlschema-1/>.
[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes
Edition", W3C Recommendation , October 2004, Second Edition", W3C Recommendation , October 2004,
<http://www.w3.org/TR/xmlschema-2/>. <http://www.w3.org/TR/xmlschema-2/>.
[4] World Wide Web Consortium, "Namespaces in XML", W3C [4] World Wide Web Consortium, "Namespaces in XML", W3C
Recommendation , January 1999, Recommendation , January 1999,
<http://www.w3.org/TR/REC-xml-names/>. <http://www.w3.org/TR/REC-xml-names/>.
[5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C [5] World Wide Web Consortium, "XML Path Language (XPath)
Candidate Recommendation , June 2006, 2.0", W3C Candidate Recommendation , June 2006,
<http://www.w3.org/TR/xpath20/>. <http://www.w3.org/TR/xpath20/>.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate
Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[7] Philips, A. and M. Davis, "Tags for Identifying of Languages", [7] Philips, A. and M. Davis, "Tags for Identifying of
RFC 4646, September 2006. Languages", RFC 4646, September 2006.
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986, Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005`. January 2005`.
[9] Freed, N. and J. Postel, "IANA Charset Registration [9] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 2978, October 2000. Procedures", BCP 2978, October 2000.
[10] Sciberras, A., "Schema for User Applications", RFC 4519, [10] Sciberras, A., "Schema for User Applications", RFC 4519,
June 2006. 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: [12] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, July 2002.
[13] International Organization for Standardization, "International [13] International Organization for Standardization,
Standard: Data elements and interchange formats - Information "International Standard: Data elements and interchange
interchange - Representation of dates and times", ISO 8601, formats - Information interchange - Representation of
Second Edition, December 2000. dates and times", ISO 8601, Second Edition, December 2000.
[14] International Organization for Standardization, "International [14] International Organization for Standardization,
Standard: Codes for the representation of currencies and funds, "International Standard: Codes for the representation of
ISO 4217:2001", ISO 4217:2001, August 2001. 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 [16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements
Format for Incident Information Exchange (FINE)", Work for the Format for Incident Information Exchange (FINE)",
in Progress, June 2006. Work in Progress, June 2006.
[17] Debar, H., Curry, D., Debar, H., and B. Feinstein, "Intrusion [17] Debar, H., Curry, D., Debar, H., and B. Feinstein,
Detection Message Exchange Format", RFC 4765, March 2007. "Intrusion Detection Message Exchange Format", RFC 4765,
March 2007.
[18] Moriarty, K., "Real-time Inter-network Defense", Work [18] Moriarty, K., "Real-time Inter-network Defense", Work in
in Progress, April 2007. Progress, April 2007.
[19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work [19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work
in Progress, April 2007. in Progress, April 2007.
[20] Shafranovich, Y., "Common Format and MIME Type for Comma- [20] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) File", RFC 4180, October 2005. Separated Values (CSV) File ", RFC 4180, October 2005.
Authors' Addresses Authors' Addresses
Roman Danyliw Roman Danyliw
CERT - Software Engineering Institute CERT - Software Engineering Institute
Pittsburgh, PA Pittsburgh, PA
USA USA
EMail: rdd@cert.org EMail: rdd@cert.org
Paul Stoecker Paul Stoecker
RSA RSA
Reston, VA Reston, VA
USA USA
EMail: paul.stoecker@rsa.com EMail: paul.stoecker@rsa.com
 End of changes. 221 change blocks. 
2019 lines changed or deleted 2144 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/