draft-ietf-mile-rfc5070-bis-22.txt   draft-ietf-mile-rfc5070-bis-23.txt 
MILE Working Group R. Danyliw MILE Working Group R. Danyliw
Internet-Draft CERT Internet-Draft CERT
Obsoletes: 5070 (if approved) May 26, 2016 Obsoletes: 5070, 6685 (if approved) June 20, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: November 27, 2016 Expires: December 22, 2016
The Incident Object Description Exchange Format v2 The Incident Object Description Exchange Format v2
draft-ietf-mile-rfc5070-bis-22 draft-ietf-mile-rfc5070-bis-23
Abstract Abstract
The Incident Object Description Exchange Format (IODEF) defines a The Incident Object Description Exchange Format (IODEF) defines a
data representation for security incident reports and cyber data representation for security incident reports and indicators
indicators commonly exchanged by operational security teams for commonly exchanged by operational security teams for mitigation and
mitigation and watch and warning. This document describes an updated watch and warning. This document describes an updated information
information model for the IODEF and provides an associated data model model for the IODEF and provides an associated data model specified
specified with XML Schema. This new information and data model with XML Schema. This new information and data model obsoletes
obsoletes Request for Comment (RFC) 5070, "The Incident Object Request for Comment (RFC) 5070 and 6685.
Description Exchange Format".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 27, 2016. This Internet-Draft will expire on December 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 47 skipping to change at page 2, line 46
2.7. Date-Time String . . . . . . . . . . . . . . . . . . . . 11 2.7. Date-Time String . . . . . . . . . . . . . . . . . . . . 11
2.8. Timezone String . . . . . . . . . . . . . . . . . . . . . 11 2.8. Timezone String . . . . . . . . . . . . . . . . . . . . . 11
2.9. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 11 2.9. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 11
2.10. Postal Address . . . . . . . . . . . . . . . . . . . . . 11 2.10. Postal Address . . . . . . . . . . . . . . . . . . . . . 11
2.11. Telephone Number . . . . . . . . . . . . . . . . . . . . 11 2.11. Telephone Number . . . . . . . . . . . . . . . . . . . . 11
2.12. Email String . . . . . . . . . . . . . . . . . . . . . . 12 2.12. Email String . . . . . . . . . . . . . . . . . . . . . . 12
2.13. Uniform Resource Locator strings . . . . . . . . . . . . 12 2.13. Uniform Resource Locator strings . . . . . . . . . . . . 12
2.14. Identifiers and Identifier References . . . . . . . . . . 12 2.14. Identifiers and Identifier References . . . . . . . . . . 12
2.15. Software . . . . . . . . . . . . . . . . . . . . . . . . 12 2.15. Software . . . . . . . . . . . . . . . . . . . . . . . . 12
2.15.1. SoftwareReference Class . . . . . . . . . . . . . . 13 2.15.1. SoftwareReference Class . . . . . . . . . . . . . . 13
2.16. Extension . . . . . . . . . . . . . . . . . . . . . . . . 14 2.16. Extension . . . . . . . . . . . . . . . . . . . . . . . . 15
3. The IODEF Information Model . . . . . . . . . . . . . . . . . 17 3. The IODEF Information Model . . . . . . . . . . . . . . . . . 17
3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 17 3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 17
3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 18 3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 19
3.3. Common Attributes . . . . . . . . . . . . . . . . . . . . 22 3.3. Common Attributes . . . . . . . . . . . . . . . . . . . . 22
3.3.1. restriction Attribute . . . . . . . . . . . . . . . . 22 3.3.1. restriction Attribute . . . . . . . . . . . . . . . . 22
3.3.2. observable-id Attribute . . . . . . . . . . . . . . . 23 3.3.2. observable-id Attribute . . . . . . . . . . . . . . . 24
3.4. IncidentID Class . . . . . . . . . . . . . . . . . . . . 24 3.4. IncidentID Class . . . . . . . . . . . . . . . . . . . . 24
3.5. AlternativeID Class . . . . . . . . . . . . . . . . . . . 25 3.5. AlternativeID Class . . . . . . . . . . . . . . . . . . . 25
3.6. RelatedActivity Class . . . . . . . . . . . . . . . . . . 25 3.6. RelatedActivity Class . . . . . . . . . . . . . . . . . . 26
3.7. ThreatActor Class . . . . . . . . . . . . . . . . . . . . 27 3.7. ThreatActor Class . . . . . . . . . . . . . . . . . . . . 27
3.8. Campaign Class . . . . . . . . . . . . . . . . . . . . . 28 3.8. Campaign Class . . . . . . . . . . . . . . . . . . . . . 28
3.9. Contact Class . . . . . . . . . . . . . . . . . . . . . . 29 3.9. Contact Class . . . . . . . . . . . . . . . . . . . . . . 29
3.9.1. RegistryHandle Class . . . . . . . . . . . . . . . . 32 3.9.1. RegistryHandle Class . . . . . . . . . . . . . . . . 32
3.9.2. PostalAddress Class . . . . . . . . . . . . . . . . . 33 3.9.2. PostalAddress Class . . . . . . . . . . . . . . . . . 33
3.9.3. Email Class . . . . . . . . . . . . . . . . . . . . . 34 3.9.3. Email Class . . . . . . . . . . . . . . . . . . . . . 34
3.9.4. Telephone Class . . . . . . . . . . . . . . . . . . . 35 3.9.4. Telephone Class . . . . . . . . . . . . . . . . . . . 35
3.10. Discovery Class . . . . . . . . . . . . . . . . . . . . . 36 3.10. Discovery Class . . . . . . . . . . . . . . . . . . . . . 36
3.10.1. DetectionPattern Class . . . . . . . . . . . . . . . 38 3.10.1. DetectionPattern Class . . . . . . . . . . . . . . . 39
3.11. Method Class . . . . . . . . . . . . . . . . . . . . . . 39 3.11. Method Class . . . . . . . . . . . . . . . . . . . . . . 40
3.11.1. Reference Class . . . . . . . . . . . . . . . . . . 40 3.11.1. Reference Class . . . . . . . . . . . . . . . . . . 41
3.12. Assessment Class . . . . . . . . . . . . . . . . . . . . 41 3.12. Assessment Class . . . . . . . . . . . . . . . . . . . . 41
3.12.1. SystemImpact Class . . . . . . . . . . . . . . . . . 43 3.12.1. SystemImpact Class . . . . . . . . . . . . . . . . . 44
3.12.2. BusinessImpact Class . . . . . . . . . . . . . . . . 45 3.12.2. BusinessImpact Class . . . . . . . . . . . . . . . . 46
3.12.3. TimeImpact Class . . . . . . . . . . . . . . . . . . 48 3.12.3. TimeImpact Class . . . . . . . . . . . . . . . . . . 48
3.12.4. MonetaryImpact Class . . . . . . . . . . . . . . . . 49 3.12.4. MonetaryImpact Class . . . . . . . . . . . . . . . . 50
3.12.5. Confidence Class . . . . . . . . . . . . . . . . . . 50 3.12.5. Confidence Class . . . . . . . . . . . . . . . . . . 51
3.13. History Class . . . . . . . . . . . . . . . . . . . . . . 51 3.13. History Class . . . . . . . . . . . . . . . . . . . . . . 52
3.13.1. HistoryItem Class . . . . . . . . . . . . . . . . . 52 3.13.1. HistoryItem Class . . . . . . . . . . . . . . . . . 52
3.14. EventData Class . . . . . . . . . . . . . . . . . . . . . 54 3.14. EventData Class . . . . . . . . . . . . . . . . . . . . . 54
3.14.1. Relating the Incident and EventData Classes . . . . 56 3.14.1. Relating the Incident and EventData Classes . . . . 57
3.14.2. Recursive Definition of EventData . . . . . . . . . 56 3.14.2. Recursive Definition of EventData . . . . . . . . . 57
3.15. Expectation Class . . . . . . . . . . . . . . . . . . . . 57 3.15. Expectation Class . . . . . . . . . . . . . . . . . . . . 58
3.16. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 60 3.16. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 61
3.17. System Class . . . . . . . . . . . . . . . . . . . . . . 61 3.17. System Class . . . . . . . . . . . . . . . . . . . . . . 61
3.18. Node Class . . . . . . . . . . . . . . . . . . . . . . . 64 3.18. Node Class . . . . . . . . . . . . . . . . . . . . . . . 65
3.18.1. Address Class . . . . . . . . . . . . . . . . . . . 65 3.18.1. Address Class . . . . . . . . . . . . . . . . . . . 66
3.18.2. NodeRole Class . . . . . . . . . . . . . . . . . . . 66 3.18.2. NodeRole Class . . . . . . . . . . . . . . . . . . . 67
3.18.3. Counter Class . . . . . . . . . . . . . . . . . . . 69 3.18.3. Counter Class . . . . . . . . . . . . . . . . . . . 70
3.19. DomainData Class . . . . . . . . . . . . . . . . . . . . 72 3.19. DomainData Class . . . . . . . . . . . . . . . . . . . . 73
3.19.1. Nameservers Class . . . . . . . . . . . . . . . . . 74 3.19.1. Nameservers Class . . . . . . . . . . . . . . . . . 75
3.19.2. DomainContacts Class . . . . . . . . . . . . . . . . 75 3.19.2. DomainContacts Class . . . . . . . . . . . . . . . . 76
3.20. Service Class . . . . . . . . . . . . . . . . . . . . . . 75 3.20. Service Class . . . . . . . . . . . . . . . . . . . . . . 76
3.20.1. ServiceName Class . . . . . . . . . . . . . . . . . 77 3.20.1. ServiceName Class . . . . . . . . . . . . . . . . . 78
3.20.2. ApplicationHeader Class . . . . . . . . . . . . . . 78 3.20.2. ApplicationHeader Class . . . . . . . . . . . . . . 79
3.21. EmailData Class . . . . . . . . . . . . . . . . . . . . . 78 3.21. EmailData Class . . . . . . . . . . . . . . . . . . . . . 79
3.22. Record Class . . . . . . . . . . . . . . . . . . . . . . 80 3.22. Record Class . . . . . . . . . . . . . . . . . . . . . . 81
3.22.1. RecordData Class . . . . . . . . . . . . . . . . . . 81 3.22.1. RecordData Class . . . . . . . . . . . . . . . . . . 82
3.22.2. RecordPattern Class . . . . . . . . . . . . . . . . 82 3.22.2. RecordPattern Class . . . . . . . . . . . . . . . . 83
3.23. WindowsRegistryKeysModified Class . . . . . . . . . . . . 84 3.23. WindowsRegistryKeysModified Class . . . . . . . . . . . . 85
3.23.1. Key Class . . . . . . . . . . . . . . . . . . . . . 85 3.23.1. Key Class . . . . . . . . . . . . . . . . . . . . . 86
3.24. CertificateData Class . . . . . . . . . . . . . . . . . . 86 3.24. CertificateData Class . . . . . . . . . . . . . . . . . . 87
3.24.1. Certificate Class . . . . . . . . . . . . . . . . . 86 3.24.1. Certificate Class . . . . . . . . . . . . . . . . . 87
3.25. FileData Class . . . . . . . . . . . . . . . . . . . . . 88
3.25. FileData Class . . . . . . . . . . . . . . . . . . . . . 87 3.25.1. File Class . . . . . . . . . . . . . . . . . . . . . 89
3.25.1. File Class . . . . . . . . . . . . . . . . . . . . . 88 3.26. HashData Class . . . . . . . . . . . . . . . . . . . . . 90
3.26. HashData Class . . . . . . . . . . . . . . . . . . . . . 89 3.26.1. Hash Class . . . . . . . . . . . . . . . . . . . . . 92
3.26.1. Hash Class . . . . . . . . . . . . . . . . . . . . . 91 3.26.2. FuzzyHash Class . . . . . . . . . . . . . . . . . . 92
3.26.2. FuzzyHash Class . . . . . . . . . . . . . . . . . . 91 3.27. SignatureData Class . . . . . . . . . . . . . . . . . . . 93
3.27. SignatureData Class . . . . . . . . . . . . . . . . . . . 92 3.28. IndicatorData Class . . . . . . . . . . . . . . . . . . . 94
3.28. IndicatorData Class . . . . . . . . . . . . . . . . . . . 93 3.29. Indicator Class . . . . . . . . . . . . . . . . . . . . . 94
3.29. Indicator Class . . . . . . . . . . . . . . . . . . . . . 93 3.29.1. IndicatorID Class . . . . . . . . . . . . . . . . . 97
3.29.1. IndicatorID Class . . . . . . . . . . . . . . . . . 96 3.29.2. AlternativeIndicatorID Class . . . . . . . . . . . . 97
3.29.2. AlternativeIndicatorID Class . . . . . . . . . . . . 96 3.29.3. Observable Class . . . . . . . . . . . . . . . . . . 98
3.29.3. Observable Class . . . . . . . . . . . . . . . . . . 97 3.29.4. IndicatorExpression Class . . . . . . . . . . . . . 104
3.29.4. IndicatorExpression Class . . . . . . . . . . . . . 103 3.29.5. Expressions with IndicatorExpression . . . . . . . . 106
3.29.5. Expressions with IndicatorExpression . . . . . . . . 105 3.29.6. ObservableReference Class . . . . . . . . . . . . . 107
3.29.6. ObservableReference Class . . . . . . . . . . . . . 106 3.29.7. IndicatorReference Class . . . . . . . . . . . . . . 108
3.29.7. IndicatorReference Class . . . . . . . . . . . . . . 107 3.29.8. AttackPhase Class . . . . . . . . . . . . . . . . . 109
3.29.8. AttackPhase Class . . . . . . . . . . . . . . . . . 107 4. Processing Considerations . . . . . . . . . . . . . . . . . . 109
4. Processing Considerations . . . . . . . . . . . . . . . . . . 108 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 110
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 108 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 110
4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 109 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 110
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 109 4.4. Incompatibilities with v1 . . . . . . . . . . . . . . . . 111
4.4. Incompatibilities with v1 . . . . . . . . . . . . . . . . 110 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 112
5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 111 5.1. Extending the Enumerated Values of Attributes . . . . . . 112
5.1. Extending the Enumerated Values of Attributes . . . . . . 111 5.1.1. Private Extension of Enumerated Values . . . . . . . 112
5.1.1. Private Extension of Enumerated Values . . . . . . . 111 5.1.2. Public Extension of Enumerated Values . . . . . . . . 113
5.1.2. Public Extension of Enumerated Values . . . . . . . . 112 5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 113
5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 112 5.3. Deconflicting Private Extensions . . . . . . . . . . . . 115
5.3. Deconflicting Private Extensions . . . . . . . . . . . . 114 6. Internationalization Issues . . . . . . . . . . . . . . . . . 116
6. Internationalization Issues . . . . . . . . . . . . . . . . . 115 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 117
7.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 116 7.2. Indicators from a Campaign . . . . . . . . . . . . . . . 117
7.2. Indicators from a Campaign . . . . . . . . . . . . . . . 116 8. The IODEF Data Model (XML Schema) . . . . . . . . . . . . . . 119
8. The IODEF Data Model (XML Schema) . . . . . . . . . . . . . . 118 9. Security Considerations . . . . . . . . . . . . . . . . . . . 158
9. Security Considerations . . . . . . . . . . . . . . . . . . . 157 9.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 158
9.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 157 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 159
9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 158 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 160
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 158 10.1. Namespace and Schema . . . . . . . . . . . . . . . . . . 160
10.1. Namespace and Schema . . . . . . . . . . . . . . . . . . 158 10.2. Enumerated Value Registries . . . . . . . . . . . . . . 161
10.2. Enumerated Value Registries . . . . . . . . . . . . . . 159 10.3. Expert Review of IODEF-Related XML Registry Entries . . 164
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 162 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 164
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 162 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 164
12.1. Normative References . . . . . . . . . . . . . . . . . . 162 12.1. Normative References . . . . . . . . . . . . . . . . . . 164
12.2. Informative References . . . . . . . . . . . . . . . . . 164 12.2. Informative References . . . . . . . . . . . . . . . . . 167
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 165 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 168
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 filter attack traffic, contacting a remote site to take down a
botnet, or sharing watch-lists of known malicious indicators in a botnet, or sharing watch-lists of known malicious indicators 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) or other
provides an XML representation for conveying: operational security teams. It provides an XML representation for
conveying:
o cyber intelligence to characterize threats; o indicators to characterize a threat;
o cyber incident reports to document particular cyber security o security incident reports to document attacks against an
events or relationships between events; organization;
o cyber event mitigation activity to proactively and reactively o response activity taken or that could be taken in response to an
mitigate activity; and incident; and
o meta-data so that these various classes of information can be o meta-data so that these various classes of information can be
exchanged among parties. exchanged among parties.
The purpose of the IODEF is to enhance the operational capabilities The purpose of the IODEF is to enhance the operational capabilities
of CSIRTs. Adoption of the IODEF will improve the ability of a CSIRT of CSIRTs. Adoption of the IODEF will improve the ability of a CSIRT
to resolve security incidents; understand cyber threats; and to resolve security incidents; understand threats; and coordinate
coordinate response activities and proactive mitigations by response activities and proactive mitigations by simplifying
simplifying collaboration and data sharing with its partners. This collaboration and data sharing with its partners. This structured
structured format provided by the IODEF allows for: format provided by the IODEF allows for:
o machine-to-machine exchange of incident and cyber intelligence o machine-to-machine exchange of incident and indicator data;
data;
o automated processing of this data whereby allowing more rapid o automated processing of this data whereby allowing more rapid
execution of appropriate courses of action; and execution of appropriate courses of action; and
o the development of an ecosystem of interoperable tools enabling o the development of an ecosystem of interoperable tools enabling
security operations. security operations.
Sharing and coordinating with other organizations is not strictly a Sharing and coordinating with other organizations is not strictly a
technical problem. There are numerous procedural, cultural, legal technical problem. There are numerous procedural, cultural, legal
and trust-related barriers to overcome. The IODEF does not attempt and trust-related barriers to overcome. The IODEF does not attempt
skipping to change at page 6, line 46 skipping to change at page 6, line 46
1.3. About the IODEF Data Model 1.3. About the IODEF Data Model
A number of considerations were made in the design of the IODEF data A number of considerations were made in the design of the IODEF data
model. model.
o The data model found in this document is an evolution of the one o The data model found in this document is an evolution of the one
previously specified in [RFC5070]. New fields were added to previously specified in [RFC5070]. New fields were added to
represent additional information. [RFC5070] was developed represent additional information. [RFC5070] was developed
primarily to represent incident reports. This document builds primarily to represent incident reports. This document builds
upon it by adding support for cyber indicators and revising it to upon it by adding support for indicators and revising it to
reflect the current challenges faced by CSIRTs. An attempt was reflect the current challenges faced by CSIRTs. An attempt was
made to preserve backward compatibility but this was not possible made to preserve backward compatibility but this was not possible
in all cases. See Section 4.4. This document obsoletes in all cases. See Section 4.4. This document obsoletes
[RFC5070]. [RFC5070].
o The IODEF is a transport format. Therefore, the data model may o The IODEF is a transport format. Therefore, the data model may
not be the optimal archival or in-memory processing format. not be the optimal archival or in-memory processing format.
o The IODEF is intended to be a framework to convey only commonly o The IODEF is intended to be a framework to convey only commonly
exchanged information. It ensures that there are mechanisms for exchanged information. It ensures that there are mechanisms for
skipping to change at page 11, line 18 skipping to change at page 11, line 18
represented in the information model by the DATETIME data type. represented in the information model by the DATETIME data type.
Ranges are not supported. Ranges are not supported.
The DATETIME data type is implemented in the data model as a The DATETIME data type is implemented in the data model as a
"xs:dateTime" type per Section 3.2.7 of [W3C.SCHEMA.DTYPES]. "xs:dateTime" type per Section 3.2.7 of [W3C.SCHEMA.DTYPES].
2.8. Timezone String 2.8. Timezone String
A timezone offset from UTC is represented in the information model by A timezone offset from UTC is represented in the information model by
the TIMEZONE data type. It is formatted according to the following the TIMEZONE data type. It is formatted according to the following
regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". regular expression:
"Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9](:[0-5][0-9])?".
The TIMEZONE data type is implemented in the data model as an The TIMEZONE data type is implemented in the data model as an
"iodef:TimezoneType" type. "iodef:TimezoneType" type.
2.9. Port Lists 2.9. Port Lists
A list of network ports is represented in the information model by A list of network ports is represented in the information model by
the PORTLIST data type. A PORTLIST consists of a comma-separated the PORTLIST data type. A PORTLIST consists of a comma-separated
list of numbers and ranges (N-M means ports N through M, inclusive). list of numbers and ranges (N-M means ports N through M, inclusive).
It is formatted according to the following regular expression: It is formatted according to the following regular expression:
skipping to change at page 11, line 49 skipping to change at page 11, line 50
in Section 2.23 of [RFC4519] as a free-form multi-line string in Section 2.23 of [RFC4519] as a free-form multi-line string
separated by the "$" character. separated by the "$" character.
The POSTAL data type is implemented in the data model as an The POSTAL data type is implemented in the data model as an
"iodef:MLStringType" type. "iodef:MLStringType" type.
2.11. Telephone Number 2.11. Telephone Number
A telephone number is represented in the information model by the A telephone number is represented in the information model by the
PHONE data type. The format of the PHONE data type is documented in PHONE data type. The format of the PHONE data type is documented in
Section 2.35 of [RFC4519]. [E.164].
The PHONE data type is implemented in the data model as a "xs:string" The PHONE data type is implemented in the data model as a "xs:string"
type per Section 3.2.1 of [W3C.SCHEMA.DTYPES]. type per Section 3.2.1 of [W3C.SCHEMA.DTYPES].
2.12. Email String 2.12. Email String
An email address is represented in the information model by the EMAIL An email address is represented in the information model by the EMAIL
data type. The format of the EMAIL data type is documented in data type. The format of the EMAIL data type is documented in
Section 3.4.1 [RFC5322]. Section 3.4.1 of [RFC5322] and Section 3.3 of [RFC6531].
The EMAIL data type is implemented in the data model as a "xs:string" The EMAIL data type is implemented in the data model as a "xs:string"
type per Section 3.2.1 of [W3C.SCHEMA.DTYPES]. type per Section 3.2.1 of [W3C.SCHEMA.DTYPES].
2.13. Uniform Resource Locator strings 2.13. Uniform Resource Locator strings
A uniform resource locator (URL) is represented in the information A uniform resource locator (URL) is represented in the information
model by the URL data type. The format of the URL data type is model by the URL data type. The format of the URL data type is
documented in [RFC3986]. documented in [RFC3986].
skipping to change at page 31, line 13 skipping to change at page 31, line 20
2. reporter. The entity that reported the information. 2. reporter. The entity that reported the information.
3. admin. An administrative contact or business owner for an 3. admin. An administrative contact or business owner for an
asset or organization. asset or organization.
4. tech. An entity responsible for the day-to-day management of 4. tech. An entity responsible for the day-to-day management of
technical issues for an asset or organization. technical issues for an asset or organization.
5. provider. An external hosting provider for an asset. 5. provider. An external hosting provider for an asset.
6. zone. An entity with authority over a DNS zone. 6. user. An end-user of an asset or part of an organization.
7. user. An end-user of an asset or part of an organization.
8. billing. An entity responsible for billing issues for an 7. billing. An entity responsible for billing issues for an
asset or organization. asset or organization.
9. legal. An entity responsible for legal issue related to an 8. legal. An entity responsible for legal issue related to an
asset or organization. asset or organization.
10. irt. An entity responsible for handling security issues for 9. irt. An entity responsible for handling security issues for
an asset or organization. an asset or organization.
11. abuse. An entity responsible for handling abuse originating 10. abuse. An entity responsible for handling abuse originating
from an asset or organization. from an asset or organization.
12. cc. An entity that is to be kept informed about the events 11. cc. An entity that is to be kept informed about the events
related to an asset or organization. related to an asset or organization.
13. cc-irt. A CSIRT or information sharing organization 12. cc-irt. A CSIRT or information sharing organization
coordinating activity related to an asset or organization. coordinating activity related to an asset or organization.
14. leo. A law enforcement organization supporting the 13. leo. A law enforcement organization supporting the
investigation of activity affecting an asset or organization. investigation of activity affecting an asset or organization.
15. vendor. The vendor that produces an asset. 14. vendor. The vendor that produces an asset.
16. vendor-support. A vendor that provides services. 15. vendor-support. A vendor that provides services.
17. victim. A victim in the incident. 16. victim. A victim in the incident.
18. victim-notified. A victim in the incident who has been 17. victim-notified. A victim in the incident who has been
notified. notified.
19. ext-value. A value used to indicate that this attribute is 18. ext-value. A value used to indicate that this attribute is
extended and the actual value is provided using the extended and the actual value is provided using the
corresponding ext-* attribute. See Section 5.1.1. corresponding ext-* attribute. See Section 5.1.1.
ext-role ext-role
Optional. STRING. A means by which to extend the role attribute. Optional. STRING. A means by which to extend the role attribute.
See Section 5.1.1. See Section 5.1.1.
type type
Required. ENUM. Indicates the type of contact being described. Required. ENUM. Indicates the type of contact being described.
This attribute is defined as an enumerated list. These values are This attribute is defined as an enumerated list. These values are
skipping to change at page 40, line 7 skipping to change at page 40, line 37
Reference Reference
Zero or more. A reference to a vulnerability, malware sample, Zero or more. A reference to a vulnerability, malware sample,
advisory, or analysis of an attack technique. See Section 3.11.1. advisory, or analysis of an attack technique. See Section 3.11.1.
Description Description
Zero or more. ML_STRING. A free-form text description of Zero or more. ML_STRING. A free-form text description of
techniques, tactics, or procedures used by the threat actor. techniques, tactics, or procedures used by the threat actor.
sci:AttackPattern sci:AttackPattern
Zero or more. A reference to an pattern of attack or exploitation Zero or more. A reference to an pattern of attack or exploitation
per [RFC-SCI] per [RFC7203]
sci:Vulnerability sci:Vulnerability
Zero or more. A reference to a vulnerability per [RFC-SCI] Zero or more. A reference to a vulnerability per [RFC7203]
sci:Weakness sci:Weakness
Zero or more. A reference to the exploited weakness per [RFC-SCI] Zero or more. A reference to the exploited weakness per [RFC7203]
AdditionalData AdditionalData
Zero or more. EXTENSION. A mechanism by which to extend the data Zero or more. EXTENSION. A mechanism by which to extend the data
model. model.
An instance of one of these child MUST be present. An instance of one of these child MUST be present.
The attributes of the Method class are: The attributes of the Method class are:
restriction restriction
skipping to change at page 40, line 49 skipping to change at page 41, line 31
| ID observable-id |<>--{0..1}--[ enum:ReferenceName ] | ID observable-id |<>--{0..1}--[ enum:ReferenceName ]
| |<>--{0..*}--[ URL ] | |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
+-------------------------+ +-------------------------+
Figure 20: The Reference Class Figure 20: The Reference Class
The aggregate classes of the Reference class are: The aggregate classes of the Reference class are:
enum:ReferenceName enum:ReferenceName
Zero or one. Reference identifier per [RFC-ENUM]. Zero or one. Reference identifier per [RFC7495].
URL URL
Zero or more. URL. A URL to a reference. Zero or more. URL. A URL to a reference.
Description Description
Zero or more. ML_STRING. A free-form text description of this Zero or more. ML_STRING. A free-form text description of this
reference. reference.
At least one of these classes MUST be present. At least one of these classes MUST be present.
skipping to change at page 44, line 26 skipping to change at page 45, line 13
shown below. The default value is "unknown". These values are shown below. The default value is "unknown". These values are
maintained in the "SystemImpact-type" IANA registry per maintained in the "SystemImpact-type" IANA registry per
Section 10.2. Section 10.2.
1. takeover-account. Control was taken of a given account. 1. takeover-account. Control was taken of a given account.
2. takeover-service. Control was taken of a given service. 2. takeover-service. Control was taken of a given service.
3. takeover-system. Control was taken of a given system. 3. takeover-system. Control was taken of a given system.
4. cps-manipulation. A cyber physical system was manipulated. 4. cps-manipulation. A cyber-physical system was manipulated.
5. cps-damage. A cyber physical system was damaged. 5. cps-damage. A cyber-physical system was damaged.
6. availability-data. Access to particular data was degraded or 6. availability-data. Access to particular data was degraded or
denied. denied.
7. availability-account. Access to an account was degraded or 7. availability-account. Access to an account was degraded or
denied. denied.
8. availability-service. Access to a service was degraded or 8. availability-service. Access to a service was degraded or
denied. denied.
skipping to change at page 53, line 27 skipping to change at page 53, line 42
Contact Contact
Zero or One. Provides contact information for the entity that Zero or One. Provides contact information for the entity that
performed the action documented in this class. See Section 3.9. performed the action documented in this class. See Section 3.9.
Description Description
Zero or more. ML_STRING. A free-form text description of the Zero or more. ML_STRING. A free-form text description of the
action or event. action or event.
DefinedCOA DefinedCOA
Zero or more. STRING. An identifier meaningful to the sender and Zero or more. STRING. An identifier meaningful to the sender and
recipient of this document that references a course of action. recipient of this document that references a course of action
This class MUST be present if the action attribute is set to (COA). This class MUST be present if the action attribute is set
"defined-coa". to "defined-coa".
AdditionalData AdditionalData
Zero or more. EXTENSION. A mechanism by which to extend the data Zero or more. EXTENSION. A mechanism by which to extend the data
model. model.
The attributes of the HistoryItem class are: The attributes of the HistoryItem class are:
action action
Required. ENUM. Classifies a performed action or occurrence Required. ENUM. Classifies a performed action or occurrence
documented in this history log entry. As activity will likely documented in this history log entry. As activity will likely
skipping to change at page 55, line 10 skipping to change at page 55, line 47
Zero or one. DATETIME. The time the event started. Zero or one. DATETIME. The time the event started.
EndTime EndTime
Zero or one. DATETIME. The time the event ended. Zero or one. DATETIME. The time the event ended.
RecoveryTime RecoveryTime
Zero or one. DATETIME. The time the site recovered from the Zero or one. DATETIME. The time the site recovered from the
event. event.
ReportTime ReportTime
One. DATETIME. The time the event was reported. Zero or one. DATETIME. The time the event was reported.
Contact Contact
Zero or more. Contact information for the parties involved in the Zero or more. Contact information for the parties involved in the
event. See Section 3.9. event. See Section 3.9.
Discovery Discovery
Zero or more. The means by which the event was detected. See Zero or more. The means by which the event was detected. See
Section 3.10. Section 3.10.
Assessment Assessment
skipping to change at page 65, line 40 skipping to change at page 66, line 38
category category
Required. ENUM. The type of address represented. The default Required. ENUM. The type of address represented. The default
value is "ipv6-addr". These values are maintained in the value is "ipv6-addr". These values are maintained in the
"Address-category" IANA registry per Section 10.2. "Address-category" IANA registry per Section 10.2.
1. asn. Autonomous System Number. 1. asn. Autonomous System Number.
2. atm. Asynchronous Transfer Mode (ATM) address. 2. atm. Asynchronous Transfer Mode (ATM) address.
3. e-mail. Email address (RFC 822). 3. e-mail. Email address, per the EMAIL data type.
4. ipv4-addr. IPv4 host address in dotted-decimal notation 4. ipv4-addr. IPv4 host address in dotted-decimal notation
(a.b.c.d). (a.b.c.d).
5. ipv4-net. IPv4 network address in dotted-decimal notation, 5. ipv4-net. IPv4 network address in dotted-decimal notation,
slash, significant bits (i.e., a.b.c.d/nn). slash, significant bits (i.e., a.b.c.d/nn).
6. ipv4-net-mask. IPv4 network address in dotted-decimal 6. ipv4-net-masked. A sanitized IPv4 address with significant
bits per "ipv4-net" but with the character 'x' replacing any
digit(s) in the address or prefix.
7. ipv4-net-mask. IPv4 network address in dotted-decimal
notation, slash, network mask in dotted-decimal notation notation, slash, network mask in dotted-decimal notation
(i.e., a.b.c.d/w.x.y.z). (i.e., a.b.c.d/w.x.y.z).
7. ipv6-addr. IPv6 host address. 8. ipv6-addr. IPv6 host address per Section 4 of [RFC5952].
8. ipv6-net. IPv6 network address, slash, significant bits. 9. ipv6-net. IPv6 network address, slash, prefix per
Section 2.3 of [RFC4291].
9. ipv6-net-mask. IPv6 network address, slash, network mask. 10. ipv6-net-masked. A sanitized IPv6 address and prefix per
"ipv6-net" but with the character 'x' replacing any
hexadecimal digit(s) in the address or digit(s) in the
prefix.
10. mac. Media Access Control (MAC) address (i.e., a:b:c:d:e:f). 11. mac. Media Access Control (MAC) address (i.e.,
aa:bb:cc:dd:ee:ff).
11. site-uri. A URL or URI for a resource. 12. site-uri. A URL or URI for a resource, per the URL data
type.
12. ext-value. A value used to indicate that this attribute is 13. ext-value. A value used to indicate that this attribute is
extended and the actual value is provided using the extended and the actual value is provided using the
corresponding ext-* attribute. See Section 5.1.1. corresponding ext-* attribute. See Section 5.1.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.1. attribute. See Section 5.1.1.
vlan-name vlan-name
Optional. STRING. The name of the Virtual LAN to which the Optional. STRING. The name of the Virtual LAN to which the
address belongs. address belongs.
vlan-num vlan-num
Optional. STRING. The number of the Virtual LAN to which the Optional. INTEGER. The number of the Virtual LAN to which the
address belongs. address belongs.
observable-id observable-id
Optional. ID. See Section 3.3.2. Optional. ID. See Section 3.3.2.
3.18.2. NodeRole Class 3.18.2. NodeRole Class
The NodeRole class describes the function performed by or role of a The NodeRole class describes the function performed by or role of a
particular system, asset or network. particular system, asset or network.
skipping to change at page 93, line 7 skipping to change at page 94, line 7
The aggregate class of the SignatureData class is: The aggregate class of the SignatureData class is:
Signature Signature
One or more. An given signature. See Section 4.2 of [W3C.XMLSIG] One or more. An given signature. See Section 4.2 of [W3C.XMLSIG]
The SignatureData class has no attributes. The SignatureData class has no attributes.
3.28. IndicatorData Class 3.28. IndicatorData Class
The IndicatorData class describes cyber indicators and meta-data The IndicatorData class describes indicators and meta-data associated
associated with them. with them.
+--------------------------+ +--------------------------+
| IndicatorData | | IndicatorData |
+--------------------------+ +--------------------------+
| |<>--{1..*}--[ Indicator ] | |<>--{1..*}--[ Indicator ]
+--------------------------+ +--------------------------+
Figure 58: The IndicatorData Class Figure 58: The IndicatorData Class
The aggregate class of the IndicatorData class is: The aggregate class of the IndicatorData class is:
Indicator Indicator
One or more. A description of an indicator. See Section 3.29. One or more. A description of an indicator. See Section 3.29.
The IndicatorData class has no attributes. The IndicatorData class has no attributes.
3.29. Indicator Class 3.29. Indicator Class
The Indicator class describes a cyber indicator. An indicator The Indicator class describes an indicator. An indicator consists of
consists of observable features and phenomenon that aid in the observable features and phenomenon that aid in the forensic or
forensic or proactive detection of malicious activity; and associated proactive detection of malicious activity; and associated meta-data.
meta-data. An indicator can be described outright; by referencing or An indicator can be described outright; by referencing or composing
composing previously defined indicators; or by referencing previously defined indicators; or by referencing observables
observables described in the incident report found in this document. described in the incident report found in this document.
+------------------------+ +------------------------+
| Indicator | | Indicator |
+------------------------+ +------------------------+
| ENUM restriction |<>----------[ IndicatorID ] | ENUM restriction |<>----------[ IndicatorID ]
| STRING ext-restriction |<>--{0..*}--[ AlternativeIndicatorID ] | STRING ext-restriction |<>--{0..*}--[ AlternativeIndicatorID ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ] | |<>--{0..1}--[ EndTime ]
| |<>--{0..1}--[ Confidence ] | |<>--{0..1}--[ Confidence ]
skipping to change at page 98, line 13 skipping to change at page 99, line 13
behavior. behavior.
+------------------------+ +------------------------+
| Observable | | Observable |
+------------------------+ +------------------------+
| ENUM restriction |<>--{0..1}--[ System ] | ENUM restriction |<>--{0..1}--[ System ]
| STRING ext-restriction |<>--{0..1}--[ Address ] | STRING ext-restriction |<>--{0..1}--[ Address ]
| |<>--{0..1}--[ DomainData ] | |<>--{0..1}--[ DomainData ]
| |<>--{0..1}--[ Service ] | |<>--{0..1}--[ Service ]
| |<>--{0..1}--[ EmailData ] | |<>--{0..1}--[ EmailData ]
| |<>--{0..1}--[ Service ]
| |<>--{0..1}--[ WindowsRegistryKeysModified ] | |<>--{0..1}--[ WindowsRegistryKeysModified ]
| |<>--{0..1}--[ FileData ] | |<>--{0..1}--[ FileData ]
| |<>--{0..1}--[ CertificateData ] | |<>--{0..1}--[ CertificateData ]
| |<>--{0..1]--[ RegistryHandle ] | |<>--{0..1]--[ RegistryHandle ]
| |<>--{0..1}--[ RecordData ] | |<>--{0..1}--[ RecordData ]
| |<>--{0..1}--[ EventData ] | |<>--{0..1}--[ EventData ]
| |<>--{0..1}--[ Incident ] | |<>--{0..1}--[ Incident ]
| |<>--{0..1}--[ Expectation ] | |<>--{0..1}--[ Expectation ]
| |<>--{0..1}--[ Reference ] | |<>--{0..1}--[ Reference ]
| |<>--{0..1}--[ Assessment ] | |<>--{0..1}--[ Assessment ]
skipping to change at page 99, line 23 skipping to change at page 100, line 21
RecordData RecordData
Zero or one. A RecordData observable. See Section 3.22.1. Zero or one. A RecordData observable. See Section 3.22.1.
EventData EventData
Zero or one. An EventData observable. See Section 3.14. Zero or one. An EventData observable. See Section 3.14.
Incident Incident
Zero or one. An Incident observable. See Section 3.2. Zero or one. An Incident observable. See Section 3.2.
EventData
Zero or one. An EventData observable. See Section 3.14.
Expectation Expectation
Zero or one. An Expectation observable. See Section 3.15. Zero or one. An Expectation observable. See Section 3.15.
Reference Reference
Zero or one. A Reference observable. See Section 3.11.1. Zero or one. A Reference observable. See Section 3.11.1.
Assessment Assessment
Zero or one. An Assessment observable. See Section 3.12. Zero or one. An Assessment observable. See Section 3.12.
DetectionPattern DetectionPattern
skipping to change at page 101, line 14 skipping to change at page 102, line 8
Optional. ENUM. The type of the observable listed in the child Optional. ENUM. The type of the observable listed in the child
ObservableList class. These values are maintained in the ObservableList class. These values are maintained in the
"BulkObservable-type" IANA registry per Section 10.2. "BulkObservable-type" IANA registry per Section 10.2.
1. asn. Autonomous System Number (per the Address@category 1. asn. Autonomous System Number (per the Address@category
attribute). attribute).
2. atm. Asynchronous Transfer Mode (ATM) address (per the 2. atm. Asynchronous Transfer Mode (ATM) address (per the
Address@category attribute). Address@category attribute).
3. e-mail. Electronic mail address (RFC 822) (per the 3. e-mail. Email address (per the Address@category attribute).
Address@category attribute).
4. ipv4-addr. IPv4 host address in dotted-decimal notation 4. ipv4-addr. IPv4 host address in dotted-decimal notation
(e.g., 192.0.2.1) (per the Address@category attribute). (e.g., 192.0.2.1) (per the Address@category attribute).
5. ipv4-net. IPv4 network address in dotted-decimal notation, 5. ipv4-net. IPv4 network address in dotted-decimal notation,
slash, significant bits (e.g., 192.0.2.0/24) (per the slash, significant bits (e.g., 192.0.2.0/24) (per the
Address@category attribute). Address@category attribute).
6. ipv4-net-mask. IPv4 network address in dotted-decimal 6. ipv4-net-mask. IPv4 network address in dotted-decimal
notation, slash, network mask in dotted-decimal notation notation, slash, network mask in dotted-decimal notation
skipping to change at page 104, line 12 skipping to change at page 105, line 12
boolean algebraic expression where the operator between them is boolean algebraic expression where the operator between them is
determined by the operator attribute. determined by the operator attribute.
+--------------------------+ +--------------------------+
| IndicatorExpression | | IndicatorExpression |
+--------------------------+ +--------------------------+
| ENUM operator |<>--{0..*}--[ IndicatorExpression ] | ENUM operator |<>--{0..*}--[ IndicatorExpression ]
| STRING ext-operator |<>--{0..*}--[ Observable ] | STRING ext-operator |<>--{0..*}--[ Observable ]
| |<>--{0..*}--[ ObservableReference ] | |<>--{0..*}--[ ObservableReference ]
| |<>--{0..*}--[ IndicatorReference ] | |<>--{0..*}--[ IndicatorReference ]
| |<>--{0..1}--[ Confidence ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+--------------------------+ +--------------------------+
Figure 65: The IndicatorExpression Class Figure 65: The IndicatorExpression Class
The aggregate classes of the IndicatorExpression class are: The aggregate classes of the IndicatorExpression class are:
IndicatorExpression IndicatorExpression
Zero or more. An expression composed of other observables or Zero or more. An expression composed of other observables or
indicators. See Section 3.29.4. indicators. See Section 3.29.4.
skipping to change at page 104, line 33 skipping to change at page 105, line 34
Observable Observable
Zero or more. A description of an observable. See Zero or more. A description of an observable. See
Section 3.29.3. Section 3.29.3.
ObservableReference ObservableReference
Zero or more. A reference to an observable. See Section 3.29.6. Zero or more. A reference to an observable. See Section 3.29.6.
IndicatorReference IndicatorReference
Zero or more. A reference to an indicator. See Section 3.29.7. Zero or more. A reference to an indicator. See Section 3.29.7.
Confidence
Zero or one. An estimate of the confidence in the quality of the
terms expressed in the expression. See Section 3.12.5.
AdditionalData AdditionalData
Zero or more. EXTENSION. Mechanism by which to extend the data Zero or more. EXTENSION. Mechanism by which to extend the data
model. model.
The attributes of the IndicatorExpression class are: The attributes of the IndicatorExpression class are:
operator operator
Optional. ENUM. The operator to be applied between the child Optional. ENUM. The operator to be applied between the child
elements. See Section 3.29.5 for parsing guidance. The default elements. See Section 3.29.5 for parsing guidance. The default
value is "and". These values are maintained in the value is "and". These values are maintained in the
skipping to change at page 105, line 27 skipping to change at page 106, line 31
1. The operator specified by the operator attribute is applied 1. The operator specified by the operator attribute is applied
between each of the child elements of the immediate parent between each of the child elements of the immediate parent
IndicatorExpression element. If no operator attribute is IndicatorExpression element. If no operator attribute is
specified, it should be assumed to be the conjunction operator specified, it should be assumed to be the conjunction operator
(i.e., operator="and"). (i.e., operator="and").
2. A nested IndicatorExpression element with a parent 2. A nested IndicatorExpression element with a parent
IndicatorExpression is the equivalent of a parentheses in the IndicatorExpression is the equivalent of a parentheses in the
expression. expression.
The following four examples in Figure 66 through Figure 69 illustrate The following four examples in Figure 66 through Figure 70 illustrate
these parsing rules: these parsing rules:
1 : <IndicatorExpression> 1 : <IndicatorExpression>
2 [O1]: <Observable>..</Observable> 2 [O1]: <Observable>..</Observable>
3 [O2]: <Observable>..</Observable> 3 [O2]: <Observable>..</Observable>
4 : </IndicatorExpression> 4 : </IndicatorExpression>
Equivalent expression: (O1 AND O2) Equivalent expression: (O1 AND O2)
Figure 66: Nested elements in an IndicatorExpression without an Figure 66: Nested elements in an IndicatorExpression without an
skipping to change at page 106, line 7 skipping to change at page 107, line 7
3 [O2]: <Observable>..</Observable> 3 [O2]: <Observable>..</Observable>
4 : </IndicatorExpression> 4 : </IndicatorExpression>
Equivalent expression: (O1 OR O2) Equivalent expression: (O1 OR O2)
Figure 67: Nested elements in an IndicatorExpression with an operator Figure 67: Nested elements in an IndicatorExpression with an operator
attribute specified attribute specified
1 : <IndicatorExpression operator="or"> 1 : <IndicatorExpression operator="or">
2 : <IndicatorExpression operator="or"> 2 : <IndicatorExpression operator="or">
2 [O1]: <Observable>..</Observable> 3 [O1]: <Observable>..</Observable>
3 [O2]: <Observable>..</Observable> 4 [O2]: <Observable>..</Observable>
4 : </IndicatorExpression> 5 : </IndicatorExpression>
2 [O3]: <Observable>..</Observable> 6 [O3]: <Observable>..</Observable>
4 : </IndicatorExpression> 7 : </IndicatorExpression>
Equivalent expression: ((O1 OR O2) OR O3) Equivalent expression: ((O1 OR O2) OR O3)
Figure 68: Nested elements with a recursive IndicatorExpression with Figure 68: Nested elements with a recursive IndicatorExpression with
an operator attribute specified an operator attribute specified
1 : <IndicatorExpression operator="not"> 1 : <IndicatorExpression operator="not">
2 : <IndicatorExpression operator="and"> 2 : <IndicatorExpression operator="and">
2 [O1]: <Observable>..</Observable> 3 [O1]: <Observable>..</Observable>
3 [O2]: <Observable>..</Observable> 4 [O2]: <Observable>..</Observable>
4 : </IndicatorExpression> 5 : </IndicatorExpression>
4 : </IndicatorExpression> 6 : </IndicatorExpression>
Equivalent expression: (NOT (O1 AND O2)) Equivalent expression: (NOT (O1 AND O2))
Figure 69: A recursive IndicatorExpression with an operator attribute Figure 69: A recursive IndicatorExpression with an operator attribute
specified specified
1 : <IndicatorExpression operator="or">
2 : <IndicatorExpression>
3 [O1 with low confidence] : <Observable>..</Observable>
4 : <Confidence rating="low" />
5 : </IndicatorExpression>
6 : <IndicatorExpression>
7 [O2 with high confidence]: <Observable>..</Observable>
8 : <Confidence rating="high" />
9 : </IndicatorExpression>
10 : </IndicatorExpression>
Equivalent expression: ((O1) OR (O2))
Figure 70: Varying confidence on particular Observables
Invalid algebraic expressions while valid XML, MUST NOT be specified. Invalid algebraic expressions while valid XML, MUST NOT be specified.
3.29.6. ObservableReference Class 3.29.6. ObservableReference Class
The ObservableReference describes a reference to an observable The ObservableReference describes a reference to an observable
feature or phenomenon described elsewhere in the document. feature or phenomenon described elsewhere in the document.
The ObservableReference class has no content. The ObservableReference class has no content.
+-------------------------+ +-------------------------+
| ObservableReference | | ObservableReference |
+-------------------------+ +-------------------------+
| IDREF uid-ref | | IDREF uid-ref |
+-------------------------+ +-------------------------+
Figure 70: The ObservableReference Class Figure 71: The ObservableReference Class
The ObservableReference class has no content. The ObservableReference class has no content.
The attribute of the ObservableReference class is: The attribute of the ObservableReference class is:
uid-ref uid-ref
Required. IDREF. An identifier that serves as a reference to a Required. IDREF. An identifier that serves as a reference to a
class in the IODEF document. The referenced class will have this class in the IODEF document. The referenced class will have this
identifier set in its observable-id attribute. identifier set in its observable-id attribute.
skipping to change at page 107, line 24 skipping to change at page 108, line 40
The IndicatorReference class has no content. The IndicatorReference class has no content.
+--------------------------+ +--------------------------+
| IndicatorReference | | IndicatorReference |
+--------------------------+ +--------------------------+
| IDREF uid-ref | | IDREF uid-ref |
| STRING euid-ref | | STRING euid-ref |
| STRING version | | STRING version |
+--------------------------+ +--------------------------+
Figure 71: The IndicatorReference Class Figure 72: The IndicatorReference Class
The attributes of the IndicatorReference class are: The attributes of the IndicatorReference class are:
uid-ref uid-ref
Optional. IDREF. An identifier that references an Indicator Optional. IDREF. An identifier that references an Indicator
class in the IODEF document. The referenced Indicator class will class in the IODEF document. The referenced Indicator class will
have this identifier set in its IndicatorID class. have this identifier set in its IndicatorID class.
euid-ref euid-ref
Optional. STRING. An identifier that references an IndicatorID Optional. STRING. An identifier that references an IndicatorID
skipping to change at page 108, line 14 skipping to change at page 109, line 24
+------------------------+ +------------------------+
| AttackPhase | | AttackPhase |
+------------------------+ +------------------------+
| |<>--{0..*}--[ AttackPhaseID ] | |<>--{0..*}--[ AttackPhaseID ]
| |<>--{0..*}--[ URL ] | |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ Description ] | |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+------------------------+ +------------------------+
Figure 72: AttackPhase Class Figure 73: AttackPhase Class
The aggregate classes of the AttackPhase class are: The aggregate classes of the AttackPhase class are:
AttackPhaseID AttackPhaseID
Zero or more. STRING. An identifier for the phase of the attack. Zero or more. STRING. An identifier for the phase of the attack.
URL URL
Zero or more. URL. A URL to a resource describing this phase of Zero or more. URL. A URL to a resource describing this phase of
the attack. the attack.
skipping to change at page 108, line 51 skipping to change at page 110, line 14
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. The character encoding MUST also be specify the XML version used. The character encoding MUST also be
explicitly specified. UTF-8 [RFC3629] SHOULD be used unless UTF-16 explicitly specified. UTF-8 [RFC3629] SHOULD be used unless UTF-16
[RFC2781] is necessary. Encodings other than UTF-8 and UTF-16 SHOULD [RFC2781] is necessary. Encodings other than UTF-8 and UTF-16 SHOULD
NOT be used. The IODEF conforms to all XML data encoding conventions NOT be used. The IODEF conforms to all XML data encoding conventions
and constraints. and constraints.
The XML declaration with no character encoding will read as follows: The XML declaration with UTF-8 character encoding will read as
follows:
<?xml version="1.0" ?>
When a character encoding is specified, the XML declaration will read
as follows:
<?xml version="1.0" encoding="charset" ?>
Where "charset" is the name of the character encoding as registered <?xml version="1.0" encoding="UTF-8" ?>
with the Internet Assigned Numbers Authority (IANA), see [RFC2978].
The following characters have special meaning in XML and MUST be Certain characters have special meaning in XML and MUST not appear in
escaped with their entity reference equivalent: "&", "<", ">", "\"" literal form. Per Section 2.4 of [W3C.XML], these characters MUST be
(double quotation mark), and "'" (apostrophe). These entity escaped with a numeric character or entity reference.
references are "&amp;", "&lt;", "&gt;", "&quot;", and "&apos;"
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-2.0" and registers it per [W3C.XMLNS]. "urn:ietf:params:xml:ns:iodef-2.0" and registers it per [W3C.XMLNS].
Each IODEF document MUST include a valid reference to the IODEF Each IODEF document MUST include a valid reference to the IODEF
schema using the "xsi:schemaLocation" attribute. An example of such schema using the "xsi:schemaLocation" attribute. An example of such
a declaration would look as follows: a declaration would look as follows:
<IODEF-Document <IODEF-Document
skipping to change at page 109, line 45 skipping to change at page 110, line 47
IODEF documents MUST be well-formed XML. It is RECOMMENDED that IODEF documents MUST be well-formed XML. It is RECOMMENDED that
recipients validate the document against the schema described in recipients validate the document against the schema described in
Section 8. However, mere conformance to this schema is not Section 8. However, mere conformance to this schema is not
sufficient for a semantically valid IODEF document. The text of sufficient for a semantically valid IODEF document. The text of
Section 3 describes further formatting and constraints; some that Section 3 describes further formatting and constraints; some that
cannot be conveniently encoded in the schema. These MUST must also cannot be conveniently encoded in the schema. These MUST must also
be considered by an IODEF implementation. Furthermore, the be considered by an IODEF implementation. Furthermore, the
enumerated values present in this document are a static list that enumerated values present in this document are a static list that
will be incomplete over time as select attributes can be extended by will be incomplete over time as select attributes can be extended by
a corresponding IANA registry per Section 10.2. Therefore, the a corresponding IANA registry per Section 10.2. Therefore, IODEF
schema to validate a given document MUST be dynamically generated implementations MUST periodically update their schema and MAY need to
from these registry values. update their parsing algorithms to incorporate newly registered
values.
4.4. Incompatibilities with v1 4.4. Incompatibilities with v1
The IODEF data model in this document makes a number of changes to The IODEF data model in this document makes a number of changes to
[RFC5070]. These changes were largely additive -- classes and [RFC5070]. These changes were largely additive -- classes and
enumerated values were added. However, some incompatibilities enumerated values were added. However, some incompatibilities
between [RFC5070] and this new specification were introduced. These between [RFC5070] and this new specification were introduced. These
incompatibilities are as follows: incompatibilities are as follows:
o The IODEF-Document@version attribute is set to "2.0". o The IODEF-Document@version attribute is set to "2.0".
skipping to change at page 110, line 31 skipping to change at page 111, line 31
o The Service@ip_protocol attribute was renamed to @ip-protocol. o The Service@ip_protocol attribute was renamed to @ip-protocol.
o The Node/NodeName class was removed in favor of representing o The Node/NodeName class was removed in favor of representing
domain names with Node/DomainData/Name class. The Node/DataTime domain names with Node/DomainData/Name class. The Node/DataTime
class was also removed so that the Node/DomainData/ class was also removed so that the Node/DomainData/
DateDomainWasChecked class can represent the time at which the DateDomainWasChecked class can represent the time at which the
name to address resolution occurred. name to address resolution occurred.
o The Node/NodeRole class was moved to System/NodeRole. o The Node/NodeRole class was moved to System/NodeRole.
o The Reference class is now defined by [RFC-ENUM]. o The Reference class is now defined by [RFC7495].
o The data previously represented in the Impact class is now in the o The data previously represented in the Impact class is now in the
SystemImpact and IncidentCategory classes. The Impact class has SystemImpact and IncidentCategory classes. The Impact class has
been removed. been removed.
o The semantics of Counter@type are now represented in Counter@unit. o The semantics of Counter@type are now represented in Counter@unit.
o The IODEF-Document@formatid attribute has been renamed to @format- o The IODEF-Document@formatid attribute has been renamed to @format-
id. id.
o Incident/ReportTime is no longer mandatory. However, o Incident/ReportTime is no longer mandatory. However,
GenerationTime is. GenerationTime is.
o The Fax class was removed and is now represented by a generic o The Fax class was removed and is now represented by a generic
Telephone class. Telephone class.
o The Telephone, Email and PostalAddress classes were redefined from o The Telephone, Email and PostalAddress classes were redefined from
improved internationalization. improved internationalization.
o The "ipv6-net-mask" value was remove from category attribute of
Address.
5. Extending the IODEF 5. Extending the IODEF
In order to support the dynamic nature of security operations, the In order to support the dynamic nature of security operations, the
IODEF data model will need to continue to evolve. This section IODEF data model will need to continue to evolve. This section
discusses how new data elements can be incorporated into the IODEF. discusses how new data elements can be incorporated into the IODEF.
There is support to add additional enumerated values and new classes. There is support to add additional enumerated values and new classes.
Adding additional attributes to existing classes is not supported. Adding additional attributes to existing classes is not supported.
These extension mechanisms are designed so that adding new data These extension mechanisms are designed so that adding new data
elements is possible without requiring a modifications to this elements is possible without requiring a modifications to this
skipping to change at page 113, line 8 skipping to change at page 114, line 8
inspection. 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. This too improves the convention of the IODEF data model. This too improves the
readability of extended IODEF documents. The names of all readability of extended IODEF documents. The names of all
elements SHOULD be capitalized. For elements with composed elements SHOULD be capitalized. For elements with composed
names, a capital letter SHOULD be used for each word. Attribute names, a capital letter SHOULD be used for each word. Attribute
names SHOULD be in lower case. Attributes with composed names names SHOULD be in lower case. Attributes with composed names
SHOULD be separated by a hyphen. SHOULD be separated by a hyphen.
4. Implementations that encounter an unrecognized element in a 4. Implementations that encounter an unrecognized element, attribute
supported namespace MUST reject the document as a syntax error. or attribute value in a supported namespace SHOULD reject the
document as a syntax error.
5. There are security and performance implications in requiring 5. There are security and performance implications in requiring
implementations to dynamically download schemas at run time. implementations to dynamically download schemas at run time.
Therefore, implementations SHOULD NOT download schemas at runtime Therefore, implementations MUST NOT download schemas at runtime
unless the appropriate precautions are taken. Implementations unless the appropriate precautions are taken. Implementations
also need to contend with the potential of significant network also need to contend with the potential of significant network
and processing issues. and processing issues.
6. Some adopters of the IODEF may have private schema definitions 6. Some adopters of the IODEF may have private schema definitions
that are not publicly available. Thus implementations may that are not publicly available. Thus implementations may
encounter IODEF documents with references to private schemas that encounter IODEF documents with references to private schemas that
may not be resolvable. Hence, IODEF document recipients MUST be may not be resolvable. Hence, IODEF document recipients MUST be
prepared for a schema definition in an IODEF document never to prepared for a schema definition in an IODEF document never to
resolve. resolve.
skipping to change at page 123, line 38 skipping to change at page 124, line 38
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name="contact-role-type"> <xs:simpleType name="contact-role-type">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="creator"/> <xs:enumeration value="creator"/>
<xs:enumeration value="reporter"/> <xs:enumeration value="reporter"/>
<xs:enumeration value="admin"/> <xs:enumeration value="admin"/>
<xs:enumeration value="tech"/> <xs:enumeration value="tech"/>
<xs:enumeration value="provider"/> <xs:enumeration value="provider"/>
<xs:enumeration value="zone"/>
<xs:enumeration value="user"/> <xs:enumeration value="user"/>
<xs:enumeration value="billing"/> <xs:enumeration value="billing"/>
<xs:enumeration value="legal"/> <xs:enumeration value="legal"/>
<xs:enumeration value="abuse"/> <xs:enumeration value="abuse"/>
<xs:enumeration value="irt"/> <xs:enumeration value="irt"/>
<xs:enumeration value="cc"/> <xs:enumeration value="cc"/>
<xs:enumeration value="cc-irt"/> <xs:enumeration value="cc-irt"/>
<xs:enumeration value="leo"/> <xs:enumeration value="leo"/>
<xs:enumeration value="vendor"/> <xs:enumeration value="vendor"/>
<xs:enumeration value="vendor-services"/> <xs:enumeration value="vendor-services"/>
skipping to change at page 137, line 26 skipping to change at page 138, line 25
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name="address-category-type"> <xs:simpleType name="address-category-type">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="asn"/> <xs:enumeration value="asn"/>
<xs:enumeration value="atm"/> <xs:enumeration value="atm"/>
<xs:enumeration value="e-mail"/> <xs:enumeration value="e-mail"/>
<xs:enumeration value="mac"/> <xs:enumeration value="mac"/>
<xs:enumeration value="ipv4-addr"/> <xs:enumeration value="ipv4-addr"/>
<xs:enumeration value="ipv4-net"/> <xs:enumeration value="ipv4-net"/>
<xs:enumeration value="ipv4-net-masked"/>
<xs:enumeration value="ipv4-net-mask"/> <xs:enumeration value="ipv4-net-mask"/>
<xs:enumeration value="ipv6-addr"/> <xs:enumeration value="ipv6-addr"/>
<xs:enumeration value="ipv6-net"/> <xs:enumeration value="ipv6-net"/>
<xs:enumeration value="ipv6-net-mask"/> <xs:enumeration value="ipv6-net-masked"/>
<xs:enumeration value="site-uri"/> <xs:enumeration value="site-uri"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="Location" type="iodef:MLStringType"/> <xs:element name="Location" type="iodef:MLStringType"/>
<xs:element name="NodeRole"> <xs:element name="NodeRole">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="iodef:Description" <xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
skipping to change at page 150, line 31 skipping to change at page 151, line 31
<xs:attribute name="ext-restriction" <xs:attribute name="ext-restriction"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="Observable"> <xs:element name="Observable">
<xs:complexType> <xs:complexType>
<xs:choice> <xs:choice>
<xs:element ref="iodef:System" minOccurs="0"/> <xs:element ref="iodef:System" minOccurs="0"/>
<xs:element ref="iodef:Address" minOccurs="0"/> <xs:element ref="iodef:Address" minOccurs="0"/>
<xs:element ref="iodef:DomainData" minOccurs="0"/> <xs:element ref="iodef:DomainData" minOccurs="0"/>
<xs:element ref="iodef:EmailData" minOccurs="0"/>
<xs:element ref="iodef:Service" minOccurs="0"/> <xs:element ref="iodef:Service" minOccurs="0"/>
<xs:element ref="iodef:EmailData" minOccurs="0"/>
<xs:element ref="iodef:WindowsRegistryKeysModified" <xs:element ref="iodef:WindowsRegistryKeysModified"
minOccurs="0"/> minOccurs="0"/>
<xs:element ref="iodef:FileData" minOccurs="0"/> <xs:element ref="iodef:FileData" minOccurs="0"/>
<xs:element ref="iodef:CertificateData" minOccurs="0"/> <xs:element ref="iodef:CertificateData" minOccurs="0"/>
<xs:element ref="iodef:RegistryHandle" minOccurs="0"/> <xs:element ref="iodef:RegistryHandle" minOccurs="0"/>
<xs:element ref="iodef:RecordData" minOccurs="0"/> <xs:element ref="iodef:RecordData" minOccurs="0"/>
<xs:element ref="iodef:EventData" minOccurs="0"/> <xs:element ref="iodef:EventData" minOccurs="0"/>
<xs:element ref="iodef:Incident" minOccurs="0"/> <xs:element ref="iodef:Incident" minOccurs="0"/>
<xs:element ref="iodef:Expectation" minOccurs="0"/> <xs:element ref="iodef:Expectation" minOccurs="0"/>
<xs:element ref="iodef:Reference" minOccurs="0"/> <xs:element ref="iodef:Reference" minOccurs="0"/>
skipping to change at page 152, line 23 skipping to change at page 153, line 23
<xs:element name="BulkObservableList" type="xs:string"/> <xs:element name="BulkObservableList" type="xs:string"/>
<xs:element name="IndicatorExpression"> <xs:element name="IndicatorExpression">
<xs:complexType> <xs:complexType>
<xs:sequence maxOccurs="unbounded"> <xs:sequence maxOccurs="unbounded">
<xs:choice> <xs:choice>
<xs:element ref="iodef:IndicatorExpression"/> <xs:element ref="iodef:IndicatorExpression"/>
<xs:element ref="iodef:Observable"/> <xs:element ref="iodef:Observable"/>
<xs:element ref="iodef:ObservableReference"/> <xs:element ref="iodef:ObservableReference"/>
<xs:element ref="iodef:IndicatorReference"/> <xs:element ref="iodef:IndicatorReference"/>
</xs:choice> </xs:choice>
<xs:element ref="iodef:Confidence" minOccurs="0"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="operator" <xs:attribute name="operator"
type="indicatorexpression-operator-type" type="indicatorexpression-operator-type"
use="optional" default="and"/> use="optional" default="and"/>
<xs:attribute name="ext-operator" <xs:attribute name="ext-operator"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name="indicatorexpression-operator-type"> <xs:simpleType name="indicatorexpression-operator-type">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
skipping to change at page 153, line 51 skipping to change at page 155, line 6
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="PortlistType"> <xs:simpleType name="PortlistType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="\d+(\-\d+)?(,\d+(\-\d+)?)*"/> <xs:pattern value="\d+(\-\d+)?(,\d+(\-\d+)?)*"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="TimezoneType"> <xs:simpleType name="TimezoneType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]"/> <xs:pattern
value="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9](:[0-5][0-9])?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="ExtensionType" mixed="true"> <xs:complexType name="ExtensionType" mixed="true">
<xs:sequence> <xs:sequence>
<xs:any namespace="##any" processContents="lax" <xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="name" type="xs:string" use="optional"/>
<xs:attribute name="dtype" <xs:attribute name="dtype"
skipping to change at page 157, line 41 skipping to change at page 158, line 45
9.1. Security 9.1. Security
The underlying messaging format and protocol used to exchange The underlying messaging format and protocol used to exchange
instances of the IODEF MUST provide appropriate guarantees of instances of the IODEF MUST provide appropriate guarantees of
confidentiality, integrity, and authenticity. The use of a confidentiality, integrity, and authenticity. The use of a
standardized security protocol is encouraged. The Real-time Inter- standardized security protocol is encouraged. The Real-time Inter-
network Defense (RID) protocol [RFC6545] and its associated transport network Defense (RID) protocol [RFC6545] and its associated transport
binding IODEF/RID over HTTP/TLS [RFC6546] provide such security. binding IODEF/RID over HTTP/TLS [RFC6546] provide such security.
The contents of an IODEF document may include a request for action. An IODEF implementation may act on the data in the document. These
An IODEF implementation may also initiate courses of action based on actions might be explicitly requested in the document or the result
the document contents. For these reasons, care must be taken by of analytical logic that triggered on data in the document. For this
IODEF implementations to properly authenticate the sender and reason, care must be taken by IODEF implementations to properly
receiver of the document. The recipient must also ascribe authenticate the sender and receiver of the document. The sender
appropriate confidence to the data prior to action. needs confidence that sensitive information and timely requests for
action are sent to the correct recipient. The recipient may
interpret the contents of the document differently based on who sent
it; or vary actions based on the sender. While the sender of the
document may explicitly convey confidence in the data in a granular
way using the Confidence class, the recipient is free to ignore or
refine this information to make its own assessment.
Executable content could be embedded into the IODEF document directly Certain classes may require out-of-band coordination to agree upon
or through an extension. The IODEF implementation MUST handle this their semantics (e.g., Confidence@rating="low" or DefinedCOA). This
content with care to prevent unintentional automated execution. coordination MUST occur prior to operational data exchange to prevent
the incorrect interpretation of these select data elements. When
parsing these data elements, implementations should validate, when
possible, that they conform to the agreed upon semantics. These
semantics may need to be periodically reevaluated.
Executable content of various forms could be embedded into the IODEF
document directly or through an extension. Implementation MUST
handle this content with care to prevent unintentional automated
execution. The following classes are explicitly intended to
represent content that might be executable:
o All classes of type iodef:ExtensionType and the RecordPattern
class can represent arbitrary binary strings such as legitimate
software programs or malware.
o The EmailMessage and EmailBody classes can represent email
attachments that can contain arbitrary content.
o The DetectionPattern class could specify a machine-readable
configuration that directs the execution of the corresponding
tool.
Per Section 4.3, IODEF implementations will need to periodically
consult the IANA registries specified in Section 10.2 to discover
newly registered enumerated attribute values. These implementations
MUST communicate with IANA in a way that ensures the integrity of the
values and the authenticity of the source. HTTPS over TLS
[RFC2818][RFC5246] provides such security.
9.2. Privacy 9.2. Privacy
The IODEF contains numerous fields that are identifiers which could The IODEF contains numerous fields that are identifiers which could
be linked to an individual or organization. IODEF documents may be linked to an individual or organization. IODEF documents may
contain sensitive information about these identified parties; and contain sensitive information about these identified parties; and
repeated document exchanges about the same and related parties may repeated document exchanges about the same and related parties may
enable the correlation of data about them. Likewise, a party may enable the correlation of data about them. Likewise, a party may
report on another to a third party without their knowledge. report on another to a third party without their knowledge.
skipping to change at page 158, line 40 skipping to change at page 160, line 31
Although outside of the scope of an IODEF implementation, the Although outside of the scope of an IODEF implementation, the
contents of IODEF documents and any derived analysis should be contents of IODEF documents and any derived analysis should be
archived with at appropriate confidentiality controls. Likewise, archived with at appropriate confidentiality controls. Likewise,
access to retrieve and analyze this data should be restricted to access to retrieve and analyze this data should be restricted to
authorized users. authorized users.
10. IANA Considerations 10. IANA Considerations
This document registers a namespace, an XML schema, and a number of This document registers a namespace, an XML schema, and a number of
registries that map to enumerated values defined in the data model. registries that map to enumerated values defined in the data model.
It also defines an expert review process for IODEF-related XML
registry entries.
10.1. Namespace and Schema 10.1. Namespace and Schema
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 [RFC3688] conforming to a registry mechanism described in [RFC3688]
Registration for the IODEF namespace: Registration for the IODEF namespace:
o URI: urn:ietf:params:xml:ns:iodef-2.0 o URI: urn:ietf:params:xml:ns:iodef-2.0
skipping to change at page 162, line 9 skipping to change at page 164, line 5
| | | | | | | |
| SoftwareReference- | softwarereference-spec- | Section | | SoftwareReference- | softwarereference-spec- | Section |
| spec-id | id-type | 2.15.1 | | spec-id | id-type | 2.15.1 |
| | | | | | | |
| SoftwareReference- | softwarereference-dtype- | Section | | SoftwareReference- | softwarereference-dtype- | Section |
| dtype | type | 2.15.1 | | dtype | type | 2.15.1 |
+-----------------------+---------------------------+---------------+ +-----------------------+---------------------------+---------------+
Table 1: IANA Enumerated Value Registries Table 1: IANA Enumerated Value Registries
10.3. Expert Review of IODEF-Related XML Registry Entries
IODEF class extensions, per Section 5.2, could register their
namespaces and schemas with the IANA XML Namespace ("ns",
http://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns)
and Schema registries ("schema", http://www.iana.org/assignments/xml-
registry/xml-registry.xhtml#schema) described in [RFC3688]. In
addition to any reviews required by IANA, changes to the XML Schema
registry for schema names beginning with
"urn:ietf:params:xml:schema:iodef" are subject to an additional IODEF
Expert Review [RFC5226] to ensure compatibility with IODEF and other
existing IODEF extensions.
The IODEF expert(s) for these reviews will be designated by the IETF
Security Area Directors.
This document obsoletes [RFC6685].
11. Acknowledgments 11. Acknowledgments
Thanks to Paul Stockler for his editorial leadership in the Thanks to Paul Stockler for his editorial leadership in the
transition of RFC5070bis to this document. transition of RFC5070bis to this document.
Thanks to Kathleen Moriarty, Brian Trammel, Alexey Melnikov, Takeshi Thanks to Kathleen Moriarty, Brian Trammel, Alexey Melnikov, Takeshi
Takahashi, David Waltermire and Sean Turner as the MILE working group Takahashi, David Waltermire and Sean Turner as the MILE working group
chairs, secretary or area directors for providing feedback and chairs, secretary or area directors for providing feedback and
coordination of this document. coordination of this document.
skipping to change at page 162, line 32 skipping to change at page 164, line 46
Toma Cejka, Patrick Curry, John Field, Christopher Harrington, Chris Toma Cejka, Patrick Curry, John Field, Christopher Harrington, Chris
Inacio, Panos Kampanakis, David Misell, Daisuke Miyamoto, Adam Inacio, Panos Kampanakis, David Misell, Daisuke Miyamoto, Adam
Montville, Robert Moskowitz, Lagadec Philippe, Tony Rutkowski, Mio Montville, Robert Moskowitz, Lagadec Philippe, Tony Rutkowski, Mio
Suzuki and Nik Teague. Suzuki and Nik Teague.
12. References 12. References
12.1. Normative References 12.1. Normative References
[W3C.XML] World Wide Web Consortium, "Extensible Markup Language [W3C.XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0 (Second Edition)", W3C Recommendation , October (XML) 1.0 (Fifth Edition)", W3C Recommendation , November
2000, <http://www.w3.org/TR/2000/REC-xml-20001006>. 2008, <http://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.SCHEMA] [W3C.SCHEMA]
World Wide Web Consortium, "XML XML Schema Part 1: World Wide Web Consortium, "XML XML Schema Part 1:
Structures Second Edition", W3C Recommendation , October Structures Second Edition", W3C Recommendation , October
2004, <http://www.w3.org/TR/xmlschema-1/>. 2004, <http://www.w3.org/TR/xmlschema-1/>.
[W3C.SCHEMA.DTYPES] [W3C.SCHEMA.DTYPES]
World Wide Web Consortium, "XML Schema Part 2: Datatypes World Wide Web Consortium, "XML Schema Part 2: Datatypes
Second 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/>.
[W3C.XMLNS] [W3C.XMLNS]
World Wide Web Consortium, "Namespaces in XML", W3C World Wide Web Consortium, "Namespaces in XML 1.0 (Third
Recommendation , January 1999, Edition)", W3C Recommendation , December 2009,
<http://www.w3.org/TR/REC-xml-names/>. <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.
[W3C.XPATH] [W3C.XPATH]
World Wide Web Consortium, "XML Path Language (XPath) World Wide Web Consortium, "XML Path Language (XPath)
3.1", W3C Candidate Recommendation , December 2015, 3.1", W3C Candidate Recommendation , December 2015,
<https://www.w3.org/TR/xpath-3/>. <https://www.w3.org/TR/xpath-3/>.
[W3C.XMLSIG] [W3C.XMLSIG]
World Wide Web Consortium, "XML Signature Syntax and World Wide Web Consortium, "XML Signature Syntax and
Processing 2.0", W3C Recommendation , June 2008, Processing 2.0", W3C Recommendation , June 2008,
<http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/xmldsig-core/>.
skipping to change at page 163, line 31 skipping to change at page 165, line 41
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC5646] Philips, A. and M. Davis, "Tags for Identifying of [RFC5646] Philips, A. and M. Davis, "Tags for Identifying of
Languages", RFC 5646, September 2009. Languages", RFC 5646, September 2009.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] 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`.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 2978, October 2000.
[RFC4519] Sciberras, A., "Schema for User Applications", RFC 4519, [RFC4519] Sciberras, A., "Schema for User Applications", RFC 4519,
June 2006. June 2006.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October
2008. 2008.
[RFC-ENUM] [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Montville, A. and D. Black, "IODEF Enumeration Reference Email", RFC 6531, February 2012.
[RFC7495] Montville, A. and D. Black, "IODEF Enumeration Reference
Format", RFC 7495, January 2015. Format", RFC 7495, January 2015.
[RFC-SCI] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An [RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
Incident Object Description Exchange Format (IODEF) Incident Object Description Exchange Format (IODEF)
Extension for Structured Cybersecurity Information", Extension for Structured Cybersecurity Information",
RFC 7203, April 2014. RFC 7203, April 2014.
[ISO4217] International Organization for Standardization, [ISO4217] International Organization for Standardization,
"International Standard: Codes for the representation of "International Standard: Codes for the representation of
currencies and funds, ISO 4217:2001", ISO 4217:2001, currencies and funds, ISO 4217:2001", ISO 4217:2001,
August 2001. August 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
skipping to change at page 164, line 42 skipping to change at page 167, line 5
The National Institute of Standards and Technology, The National Institute of Standards and Technology,
"Common Platform Enumeration", 2014, "Common Platform Enumeration", 2014,
<http://scap.nist.gov/specifications/cpe/>. <http://scap.nist.gov/specifications/cpe/>.
[ISO19770] [ISO19770]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- Software asset management -- "Information technology -- Software asset management --
Part 2: Software identification tag, ISO/IEC Part 2: Software identification tag, ISO/IEC
19770-2:2015", ISO 19770-2:2015, October 2015. 19770-2:2015", ISO 19770-2:2015, October 2015.
[E.164] ITU Telecommunication Standardization Sector, "The
International Public Telecommunication Numbering Plan",
ITU-T Recommendation E.164 (02/05), February 2005.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
12.2. Informative References 12.2. Informative References
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "Incident
Object Description Exchange Format", RFC 5070, December Object Description Exchange Format", RFC 5070, December
2007. 2007.
[RFC6685] Trammell, B., "Expert Review for Incident Object
Description Exchange Format (IODEF) Extensions in IANA XML
Registry", RFC 6685, July 2012.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6545, April 2012. RFC 6545, April 2012.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546, April Defense (RID) Messages over HTTP/TLS", RFC 6546, April
2012. 2012.
[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
Class for Reporting Phishing", RFC 5901, July 2010. Class for Reporting Phishing", RFC 5901, July 2010.
skipping to change at page 165, line 39 skipping to change at page 168, line 13
Separated Values (CSV) File", RFC 4180, October 2005. Separated Values (CSV) File", RFC 4180, October 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008. IANA Considerations Section in RFCs", RFC 5226, May 2008.
[W3C.XMLENC] [W3C.XMLENC]
World Wide Web Consortium, "XML Encryption Syntax and World Wide Web Consortium, "XML Encryption Syntax and
Processing Version 1.1", W3C Recommendation , April 2013, Processing Version 1.1", W3C Recommendation , April 2013,
<https://www.w3.org/TR/xmlenc-core1/>. <https://www.w3.org/TR/xmlenc-core1/>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Author's Address Author's Address
Roman Danyliw Roman Danyliw
CERT - Carnegie Mellon University CERT - Carnegie Mellon University
4500 Fifth Avenue 4500 Fifth Avenue
Pittsburgh, PA Pittsburgh, PA
USA USA
EMail: rdd@cert.org EMail: rdd@cert.org
 End of changes. 95 change blocks. 
214 lines changed or deleted 308 lines changed or added

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