draft-ietf-mile-rfc5070-bis-19.txt   draft-ietf-mile-rfc5070-bis-20.txt 
MILE Working Group R. Danyliw MILE Working Group R. Danyliw
Internet-Draft CERT Internet-Draft CERT
Obsoletes: 5070 (if approved) April 21, 2016 Obsoletes: 5070 (if approved) May 9, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: October 23, 2016 Expires: November 10, 2016
The Incident Object Description Exchange Format v2 The Incident Object Description Exchange Format v2
draft-ietf-mile-rfc5070-bis-19 draft-ietf-mile-rfc5070-bis-20
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 cyber
indicators commonly exchanged by operational security teams for indicators commonly exchanged by operational security teams for
mitigation and watch and warning. This document describes an updated mitigation and watch and warning. This document describes an updated
information model for the IODEF and provides an associated data model information model for the IODEF and provides an associated data model
specified with XML Schema. This new information and data model specified with XML Schema. This new information and data model
obsoletes [RFC5070]. obsoletes [RFC5070].
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 October 23, 2016. This Internet-Draft will expire on November 10, 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 26 skipping to change at page 2, line 26
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. About the IODEF Data Model . . . . . . . . . . . . . . . 6 1.3. About the IODEF Data Model . . . . . . . . . . . . . . . 6
2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Changelog . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . 7 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Characters and Strings . . . . . . . . . . . . . . . . . 7 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . 7 2.3. Characters and Strings . . . . . . . . . . . . . . . . . 8
2.5. Binary Strings . . . . . . . . . . . . . . . . . . . . . 8 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . 9
2.5.1. Base64 Bytes . . . . . . . . . . . . . . . . . . . . 8 2.5. Binary Strings . . . . . . . . . . . . . . . . . . . . . 10
2.5.2. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . 9 2.5.1. Base64 Bytes . . . . . . . . . . . . . . . . . . . . 10
2.6. Enumerated Types . . . . . . . . . . . . . . . . . . . . 9 2.5.2. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . 10
2.7. Date-Time String . . . . . . . . . . . . . . . . . . . . 9 2.6. Enumerated Types . . . . . . . . . . . . . . . . . . . . 10
2.8. Timezone String . . . . . . . . . . . . . . . . . . . . . 9 2.7. Date-Time String . . . . . . . . . . . . . . . . . . . . 10
2.9. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 9 2.8. Timezone String . . . . . . . . . . . . . . . . . . . . . 10
2.10. Postal Address . . . . . . . . . . . . . . . . . . . . . 10 2.9. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 11
2.11. Telephone Number . . . . . . . . . . . . . . . . . . . . 10 2.10. Postal Address . . . . . . . . . . . . . . . . . . . . . 11
2.12. Email String . . . . . . . . . . . . . . . . . . . . . . 10 2.11. Telephone Number . . . . . . . . . . . . . . . . . . . . 11
2.13. Uniform Resource Locator strings . . . . . . . . . . . . 10 2.12. Email String . . . . . . . . . . . . . . . . . . . . . . 11
2.14. Identifiers and Identifier References . . . . . . . . . . 10 2.13. Uniform Resource Locator strings . . . . . . . . . . . . 11
2.15. Software . . . . . . . . . . . . . . . . . . . . . . . . 11 2.14. Identifiers and Identifier References . . . . . . . . . . 12
2.15.1. SoftwareReference Class . . . . . . . . . . . . . . 11 2.15. Software . . . . . . . . . . . . . . . . . . . . . . . . 12
2.16. Extension . . . . . . . . . . . . . . . . . . . . . . . . 13 2.15.1. SoftwareReference Class . . . . . . . . . . . . . . 13
3. The IODEF Information Model . . . . . . . . . . . . . . . . . 16 2.16. Extension . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 16 3. The IODEF Information Model . . . . . . . . . . . . . . . . . 17
3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 17 3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 17
3.3. Common Attributes . . . . . . . . . . . . . . . . . . . . 21 3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 18
3.3.1. restriction Attribute . . . . . . . . . . . . . . . . 21 3.3. Common Attributes . . . . . . . . . . . . . . . . . . . . 22
3.3.2. observable-id Attribute . . . . . . . . . . . . . . . 22 3.3.1. restriction Attribute . . . . . . . . . . . . . . . . 22
3.3.2. observable-id Attribute . . . . . . . . . . . . . . . 23
3.4. IncidentID Class . . . . . . . . . . . . . . . . . . . . 23 3.4. IncidentID Class . . . . . . . . . . . . . . . . . . . . 24
3.5. AlternativeID Class . . . . . . . . . . . . . . . . . . . 24 3.5. AlternativeID Class . . . . . . . . . . . . . . . . . . . 25
3.6. RelatedActivity Class . . . . . . . . . . . . . . . . . . 24 3.6. RelatedActivity Class . . . . . . . . . . . . . . . . . . 25
3.7. ThreatActor Class . . . . . . . . . . . . . . . . . . . . 26 3.7. ThreatActor Class . . . . . . . . . . . . . . . . . . . . 27
3.8. Campaign Class . . . . . . . . . . . . . . . . . . . . . 27 3.8. Campaign Class . . . . . . . . . . . . . . . . . . . . . 28
3.9. Contact Class . . . . . . . . . . . . . . . . . . . . . . 28 3.9. Contact Class . . . . . . . . . . . . . . . . . . . . . . 29
3.9.1. RegistryHandle Class . . . . . . . . . . . . . . . . 31 3.9.1. RegistryHandle Class . . . . . . . . . . . . . . . . 32
3.9.2. PostalAddress Class . . . . . . . . . . . . . . . . . 32 3.9.2. PostalAddress Class . . . . . . . . . . . . . . . . . 33
3.9.3. Email Class . . . . . . . . . . . . . . . . . . . . . 33 3.9.3. Email Class . . . . . . . . . . . . . . . . . . . . . 34
3.9.4. Telephone Class . . . . . . . . . . . . . . . . . . . 34 3.9.4. Telephone Class . . . . . . . . . . . . . . . . . . . 35
3.10. Discovery Class . . . . . . . . . . . . . . . . . . . . . 35 3.10. Discovery Class . . . . . . . . . . . . . . . . . . . . . 36
3.10.1. DetectionPattern Class . . . . . . . . . . . . . . . 37 3.10.1. DetectionPattern Class . . . . . . . . . . . . . . . 38
3.11. Method Class . . . . . . . . . . . . . . . . . . . . . . 38 3.11. Method Class . . . . . . . . . . . . . . . . . . . . . . 39
3.11.1. Reference Class . . . . . . . . . . . . . . . . . . 39 3.11.1. Reference Class . . . . . . . . . . . . . . . . . . 40
3.12. Assessment Class . . . . . . . . . . . . . . . . . . . . 40 3.12. Assessment Class . . . . . . . . . . . . . . . . . . . . 41
3.12.1. SystemImpact Class . . . . . . . . . . . . . . . . . 42 3.12.1. SystemImpact Class . . . . . . . . . . . . . . . . . 43
3.12.2. BusinessImpact Class . . . . . . . . . . . . . . . . 44 3.12.2. BusinessImpact Class . . . . . . . . . . . . . . . . 45
3.12.3. TimeImpact Class . . . . . . . . . . . . . . . . . . 46 3.12.3. TimeImpact Class . . . . . . . . . . . . . . . . . . 47
3.12.4. MonetaryImpact Class . . . . . . . . . . . . . . . . 48 3.12.4. MonetaryImpact Class . . . . . . . . . . . . . . . . 49
3.12.5. Confidence Class . . . . . . . . . . . . . . . . . . 49 3.12.5. Confidence Class . . . . . . . . . . . . . . . . . . 50
3.13. History Class . . . . . . . . . . . . . . . . . . . . . . 50 3.13. History Class . . . . . . . . . . . . . . . . . . . . . . 51
3.13.1. HistoryItem Class . . . . . . . . . . . . . . . . . 51 3.13.1. HistoryItem Class . . . . . . . . . . . . . . . . . 52
3.14. EventData Class . . . . . . . . . . . . . . . . . . . . . 53 3.14. EventData Class . . . . . . . . . . . . . . . . . . . . . 54
3.14.1. Relating the Incident and EventData Classes . . . . 55 3.14.1. Relating the Incident and EventData Classes . . . . 56
3.14.2. Recursive Definition of EventData . . . . . . . . . 55 3.14.2. Recursive Definition of EventData . . . . . . . . . 56
3.15. Expectation Class . . . . . . . . . . . . . . . . . . . . 56 3.15. Expectation Class . . . . . . . . . . . . . . . . . . . . 57
3.16. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 59 3.16. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 60
3.17. System Class . . . . . . . . . . . . . . . . . . . . . . 60 3.17. System Class . . . . . . . . . . . . . . . . . . . . . . 61
3.18. Node Class . . . . . . . . . . . . . . . . . . . . . . . 63 3.18. Node Class . . . . . . . . . . . . . . . . . . . . . . . 64
3.18.1. Address Class . . . . . . . . . . . . . . . . . . . 64 3.18.1. Address Class . . . . . . . . . . . . . . . . . . . 65
3.18.2. NodeRole Class . . . . . . . . . . . . . . . . . . . 65 3.18.2. NodeRole Class . . . . . . . . . . . . . . . . . . . 66
3.18.3. Counter Class . . . . . . . . . . . . . . . . . . . 68 3.18.3. Counter Class . . . . . . . . . . . . . . . . . . . 69
3.19. DomainData Class . . . . . . . . . . . . . . . . . . . . 71 3.19. DomainData Class . . . . . . . . . . . . . . . . . . . . 72
3.19.1. Nameservers Class . . . . . . . . . . . . . . . . . 73 3.19.1. Nameservers Class . . . . . . . . . . . . . . . . . 74
3.19.2. DomainContacts Class . . . . . . . . . . . . . . . . 74 3.19.2. DomainContacts Class . . . . . . . . . . . . . . . . 75
3.20. Service Class . . . . . . . . . . . . . . . . . . . . . . 74 3.20. Service Class . . . . . . . . . . . . . . . . . . . . . . 75
3.20.1. ServiceName Class . . . . . . . . . . . . . . . . . 76 3.20.1. ServiceName Class . . . . . . . . . . . . . . . . . 77
3.20.2. ApplicationHeader Class . . . . . . . . . . . . . . 77 3.20.2. ApplicationHeader Class . . . . . . . . . . . . . . 78
3.21. EmailData Class . . . . . . . . . . . . . . . . . . . . . 77 3.21. EmailData Class . . . . . . . . . . . . . . . . . . . . . 78
3.22. Record Class . . . . . . . . . . . . . . . . . . . . . . 79 3.22. Record Class . . . . . . . . . . . . . . . . . . . . . . 80
3.22.1. RecordData Class . . . . . . . . . . . . . . . . . . 80 3.22.1. RecordData Class . . . . . . . . . . . . . . . . . . 81
3.22.2. RecordPattern Class . . . . . . . . . . . . . . . . 81 3.22.2. RecordPattern Class . . . . . . . . . . . . . . . . 82
3.23. WindowsRegistryKeysModified Class . . . . . . . . . . . . 83 3.23. WindowsRegistryKeysModified Class . . . . . . . . . . . . 84
3.23.1. Key Class . . . . . . . . . . . . . . . . . . . . . 84 3.23.1. Key Class . . . . . . . . . . . . . . . . . . . . . 85
3.24. CertificateData Class . . . . . . . . . . . . . . . . . . 85 3.24. CertificateData Class . . . . . . . . . . . . . . . . . . 86
3.24.1. Certificate Class . . . . . . . . . . . . . . . . . 85 3.24.1. Certificate Class . . . . . . . . . . . . . . . . . 86
3.25. FileData Class . . . . . . . . . . . . . . . . . . . . . 86 3.25. FileData Class . . . . . . . . . . . . . . . . . . . . . 87
3.25.1. File Class . . . . . . . . . . . . . . . . . . . . . 87 3.25.1. File Class . . . . . . . . . . . . . . . . . . . . . 88
3.26. HashData Class . . . . . . . . . . . . . . . . . . . . . 89
3.26. HashData Class . . . . . . . . . . . . . . . . . . . . . 88 3.26.1. Hash Class . . . . . . . . . . . . . . . . . . . . . 91
3.26.1. Hash Class . . . . . . . . . . . . . . . . . . . . . 90 3.26.2. FuzzyHash Class . . . . . . . . . . . . . . . . . . 91
3.26.2. FuzzyHash Class . . . . . . . . . . . . . . . . . . 90 3.27. SignatureData Class . . . . . . . . . . . . . . . . . . . 92
3.27. SignatureData Class . . . . . . . . . . . . . . . . . . . 91 3.28. IndicatorData Class . . . . . . . . . . . . . . . . . . . 93
3.28. IndicatorData Class . . . . . . . . . . . . . . . . . . . 92 3.29. Indicator Class . . . . . . . . . . . . . . . . . . . . . 93
3.29. Indicator Class . . . . . . . . . . . . . . . . . . . . . 92 3.29.1. IndicatorID Class . . . . . . . . . . . . . . . . . 96
3.29.1. IndicatorID Class . . . . . . . . . . . . . . . . . 95 3.29.2. AlternativeIndicatorID Class . . . . . . . . . . . . 96
3.29.2. AlternativeIndicatorID Class . . . . . . . . . . . . 95 3.29.3. Observable Class . . . . . . . . . . . . . . . . . . 97
3.29.3. Observable Class . . . . . . . . . . . . . . . . . . 96 3.29.4. IndicatorExpression Class . . . . . . . . . . . . . 103
3.29.4. IndicatorExpression Class . . . . . . . . . . . . . 102 3.29.5. Expressions with IndicatorExpression . . . . . . . . 104
3.29.5. Expressions with IndicatorExpression . . . . . . . . 103 3.29.6. ObservableReference Class . . . . . . . . . . . . . 106
3.29.6. ObservableReference Class . . . . . . . . . . . . . 105 3.29.7. IndicatorReference Class . . . . . . . . . . . . . . 106
3.29.7. IndicatorReference Class . . . . . . . . . . . . . . 105 3.29.8. AttackPhase Class . . . . . . . . . . . . . . . . . 107
3.29.8. AttackPhase Class . . . . . . . . . . . . . . . . . 106 4. Processing Considerations . . . . . . . . . . . . . . . . . . 108
4. Processing Considerations . . . . . . . . . . . . . . . . . . 107 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 108
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 107 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 109
4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 108 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 109
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 108 4.4. Incompatibilities with v1 . . . . . . . . . . . . . . . . 109
4.4. Incompatibilities with v1 . . . . . . . . . . . . . . . . 108 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 110
5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 109 5.1. Extending the Enumerated Values of Attributes . . . . . . 110
5.1. Extending the Enumerated Values of Attributes . . . . . . 109 5.1.1. Private Extension of Enumerated Values . . . . . . . 111
5.1.1. Private Extension of Enumerated Values . . . . . . . 110 5.1.2. Public Extension of Enumerated Values . . . . . . . . 111
5.1.2. Public Extension of Enumerated Values . . . . . . . . 110 5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 111
5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 110 5.3. Deconflicting Private Extensions . . . . . . . . . . . . 113
5.3. Deconflicting Private Extensions . . . . . . . . . . . . 112 6. Internationalization Issues . . . . . . . . . . . . . . . . . 114
6. Internationalization Issues . . . . . . . . . . . . . . . . . 113 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 115
7.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 114 7.2. Indicators from a Campaign . . . . . . . . . . . . . . . 116
7.2. Indicators from a Campaign . . . . . . . . . . . . . . . 115 8. The IODEF Data Model (XML Schema) . . . . . . . . . . . . . . 117
8. The IODEF Data Model (XML Schema) . . . . . . . . . . . . . . 116 9. Security Considerations . . . . . . . . . . . . . . . . . . . 157
9. Security Considerations . . . . . . . . . . . . . . . . . . . 156 9.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 157
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 156 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.1. Namespace and Schema . . . . . . . . . . . . . . . . . . 156 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 158
10.2. Enumerated Value Registries . . . . . . . . . . . . . . 157 10.1. Namespace and Schema . . . . . . . . . . . . . . . . . . 158
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 159 10.2. Enumerated Value Registries . . . . . . . . . . . . . . 158
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 160 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 161
12.1. Normative References . . . . . . . . . . . . . . . . . . 160 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 161
12.2. Informative References . . . . . . . . . . . . . . . . . 162 12.1. Normative References . . . . . . . . . . . . . . . . . . 161
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 163 12.2. Informative References . . . . . . . . . . . . . . . . . 164
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 164
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.
skipping to change at page 7, line 14 skipping to change at page 7, line 14
o Not all commonly exchanged information has a well-defined format o Not all commonly exchanged information has a well-defined format
or taxonomy. The IODEF attempts to strike a balance between or taxonomy. The IODEF attempts to strike a balance between
enforcing sufficient structure to allow automated processing and enforcing sufficient structure to allow automated processing and
supporting free-form content that enables maximum flexibility. supporting free-form content that enables maximum flexibility.
o The IODEF fits into a broader ecosystem of standards and o The IODEF fits into a broader ecosystem of standards and
conventions. An attempt was made to harmonize the data model with conventions. An attempt was made to harmonize the data model with
this context. this context.
1.4. Changelog
A detailed list of additions made to the [RFC5070] data model are
enumerated in this section. See Section 4.4 for a list of
incompatible changes.
o Updated the data types (Section 2) to improve
internationalization, clarify ambiguity, and ensure consistency in
extensions.
o Added the observable-id attribute (Section 3.3.2) and
IndicatorData (Section 3.28) class (Section 3.28) to represent
indicators.
o Added the private-enum-name and -id attributes to the IODEF-
Document class (Section 3.1) to disambiguate private extensions.
o Updated the Incident class (Section 3.2) to represent additional
timing and workflow information.
o Added the ThreatActor (Section 3.7) and Campaign (Section 3.8)
classes to represent attack attribution information.
o Updated the Contact class (Section 3.9) and its children to
improve internationalization and represent additional information
about an entity.
o Updated the Method class (Section 3.11) to improve extensibility
through externally referenced resources.
o Added the Discovery class (Section 3.10) to describe how an
incident was discovered.
o Updated the Assessment class (Section 3.12) to enable more
descriptive characterizations of the impact of an incident.
o Updated the HistoryItem (Section 3.13.1) and Expectation
(Section 3.15) classes to support a reference to a course of
action.
o Updated the EventData class (Section 3.14) with additional meta-
data added to the Incident class.
o Updated the System (Section 3.17) class with additional meta-data.
o Updated the Counter class (Section 3.18.3) to support additional
rate metrics.
o Added the DomainData (Section 3.19), EmailData (Section 3.21),
WindowsRegistryKeysModified (Section 3.23), CertificateData
(Section 3.24) and FileData (Section 3.25) to improve the
description of an incident and support this data as indicators.
o Added the SignatureData (Section 3.27) and HashData classes
(Section 3.26) to represent digital signatures and hashes.
o Added support for public enumerated attribute extensions using
IANA registries (Section 5.1.2).
o Updated numerous enumerated attributes for completeness.
2. IODEF Data Types 2. IODEF Data Types
The IODEF uses a number of simple and complex types. This section The IODEF uses a number of simple and complex types. This section
describes these data types. describes these data types.
2.1. Integers 2.1. Integers
An integer is represented in the information model by the INTEGER An integer is represented in the information model by the INTEGER
data type. Integer data MUST be encoded in Base 10. data type. Integer data MUST be encoded in Base 10.
skipping to change at page 12, line 27 skipping to change at page 13, line 32
The element content varies according to the value of the spec-name The element content varies according to the value of the spec-name
attribute. It is defined in the data model as "xs:any" per attribute. It is defined in the data model as "xs:any" per
[W3C.SCHEMA]. [W3C.SCHEMA].
The attributes of the SoftwareReference class are: The attributes of the SoftwareReference class are:
spec-name spec-name
Required. ENUM. Identifies the format and semantics of the Required. ENUM. Identifies the format and semantics of the
element body of this class. Formal standards and specifications element body of this class. Formal standards and specifications
can be referenced as well as a free-form text description with a a can be referenced as well as a free-form text description with a
user-provided data type. These values are maintained in the user-provided data type. These values are maintained in the
"SoftwareReference-spec-id" IANA registry per Section 10.2 "SoftwareReference-spec-id" IANA registry per Section 10.2
1. custom. The element content is free-form and of the data type 1. custom. The element content is free-form and of the data type
specified by the dtype attribute. If this value is selected, specified by the dtype attribute. If this value is selected,
then the dtype attribute MUST be set. then the dtype attribute MUST be set.
2. cpe. The element content describes a Common Platform 2. cpe. The element content describes a Common Platform
Enumeration (CPE) entry. Enumeration (CPE) entry.
skipping to change at page 28, line 32 skipping to change at page 29, line 32
class. Each child Contact class logically inherits contact class. Each child Contact class logically inherits contact
information from its ancestors. information from its ancestors.
+------------------------+ +------------------------+
| Contact | | Contact |
+------------------------+ +------------------------+
| ENUM role |<>--{0..*}--[ ContactName ] | ENUM role |<>--{0..*}--[ ContactName ]
| STRING ext-role |<>--{0..*}--[ ContactTitle ] | STRING ext-role |<>--{0..*}--[ ContactTitle ]
| ENUM type |<>--{0..*}--[ Description ] | ENUM type |<>--{0..*}--[ Description ]
| STRING ext-type |<>--{0..*}--[ RegistryHandle ] | STRING ext-type |<>--{0..*}--[ RegistryHandle ]
| ENUM restriction |<>--{0..1}--[ PostalAddress ] | ENUM restriction |<>--{0..*}--[ PostalAddress ]
| STRING ext-restriction |<>--{0..*}--[ Email ] | STRING ext-restriction |<>--{0..*}--[ Email ]
| |<>--{0..*}--[ Telephone ] | |<>--{0..*}--[ Telephone ]
| |<>--{0..1}--[ Timezone ] | |<>--{0..1}--[ Timezone ]
| |<>--{0..*}--[ Contact ] | |<>--{0..*}--[ Contact ]
| |<>--{0..*}--[ AdditionalData ] | |<>--{0..*}--[ AdditionalData ]
+------------------------+ +------------------------+
Figure 12: The Contact Class Figure 12: The Contact Class
The aggregate classes of the Contact class are: The aggregate classes of the Contact class are:
skipping to change at page 37, line 29 skipping to change at page 38, line 29
Optional. STRING. A means by which to extend the restriction Optional. STRING. A means by which to extend the restriction
attribute. See Section 5.1.1. attribute. See Section 5.1.1.
3.10.1. DetectionPattern Class 3.10.1. DetectionPattern Class
The DetectionPattern class describes a configuration or signature The DetectionPattern class describes a configuration or signature
that can be used by an IDS/IPS, SIEM, anti-virus, end-point that can be used by an IDS/IPS, SIEM, anti-virus, end-point
protection, network analysis, malware analysis, or host forensics protection, network analysis, malware analysis, or host forensics
tool to identify a particular phenomenon. This class requires the tool to identify a particular phenomenon. This class requires the
identification of the target application and allows the configuration identification of the target application and allows the configuration
to be describes in either free-form or machine readable form. to be described in either free-form or machine readable form.
+------------------------+ +------------------------+
| DetectionPattern | | DetectionPattern |
+------------------------+ +------------------------+
| ENUM restriction |<>----------[ Application ] | ENUM restriction |<>----------[ Application ]
| STRING ext-restriction |<>--{0..*}--[ Description ] | STRING ext-restriction |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ DetectionConfiguration ] | |<>--{0..*}--[ DetectionConfiguration ]
+------------------------+ +------------------------+
Figure 18: The DetectionPattern Class Figure 18: The DetectionPattern Class
skipping to change at page 55, line 31 skipping to change at page 56, line 31
Incident class. However, in the case where the summarized Incident class. However, in the case where the summarized
information in the Incident class conflicts the detailed information information in the Incident class conflicts the detailed information
in an EventData class the more specific EventData class MUST in an EventData class the more specific EventData class MUST
supersede the more generic information provided in Incident class. supersede the more generic information provided in Incident class.
3.14.2. Recursive Definition of EventData 3.14.2. Recursive Definition of EventData
The EventData class is container for the properties of an event in an The EventData class is container for the properties of an event in an
incident. These properties include: the hosts involved, impact of incident. These properties include: the hosts involved, impact of
the incident activity on the hosts, forensic logs, etc. The the incident activity on the hosts, forensic logs, etc. The
recursive definition of EvenData allows for the grouping of related recursive definition of EventData allows for the grouping of related
information with common properties. This approach eliminates the information with common properties. This approach eliminates the
need for explicit identifiers to relate information or duplicate it. need for explicit identifiers to relate information or duplicate it.
Instead, the relative depth (nesting) of a class is used to group Instead, the relative depth (nesting) of a class is used to group
(relate) information. (relate) information.
For example, consider a case where two hosts experience different For example, consider a case where two hosts experience different
impacts during an incident. However, these two hosts have common impacts during an incident. However, these two hosts have common
contact information. A depiction of how this situation would be contact information. A depiction of how this situation would be
represented can be found in Figure 30. EventData (2) and (3) group represented can be found in Figure 30. EventData (2) and (3) group
each of the two hosts with their unique impact. EventData (1) each of the two hosts with their unique impact. EventData (1)
skipping to change at page 109, line 35 skipping to change at page 110, line 35
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.
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 ad 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
document. Extensions can be implemented publicly or privately. With document. Extensions can be implemented publicly or privately. With
proven value, well documented extensions can be incorporated into proven value, well documented extensions can be incorporated into
future versions of the specification. future versions of the specification.
5.1. Extending the Enumerated Values of Attributes 5.1. Extending the Enumerated Values of Attributes
skipping to change at page 140, line 38 skipping to change at page 141, line 38
<xs:element name="EmailBody" type="xs:string"/> <xs:element name="EmailBody" type="xs:string"/>
<xs:element name="EmailMessage" type="xs:string"/> <xs:element name="EmailMessage" type="xs:string"/>
<!-- <!--
=================================================================== ===================================================================
== DomainData class == == DomainData class ==
=================================================================== ===================================================================
--> -->
<xs:element name="DomainData"> <xs:element name="DomainData">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="iodef:Name" maxOccurs="1"/> <xs:element ref="iodef:Name"/>
<xs:element ref="iodef:DateDomainWasChecked" <xs:element ref="iodef:DateDomainWasChecked"
minOccurs="0" maxOccurs="1"/> minOccurs="0"/>
<xs:element ref="iodef:RegistrationDate" <xs:element ref="iodef:RegistrationDate"
minOccurs="0" maxOccurs="1"/> minOccurs="0"/>
<xs:element ref="iodef:ExpirationDate" <xs:element ref="iodef:ExpirationDate"
minOccurs="0" maxOccurs="1"/> minOccurs="0"/>
<xs:element ref="iodef:RelatedDNS" <xs:element ref="iodef:RelatedDNS"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Nameservers" <xs:element ref="iodef:Nameservers"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:DomainContacts" <xs:element ref="iodef:DomainContacts"
minOccurs="0" maxOccurs="1"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="system-status" <xs:attribute name="system-status"
type="domaindata-system-status-type"/> type="domaindata-system-status-type"/>
<xs:attribute name="ext-system-status" <xs:attribute name="ext-system-status"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="domain-status" <xs:attribute name="domain-status"
type="domaindata-domain-status-type"/> type="domaindata-domain-status-type"/>
<xs:attribute name="ext-domain-status" <xs:attribute name="ext-domain-status"
type="xs:string" use="optional"/> type="xs:string" use="optional"/>
<xs:attribute name="observable-id" type="xs:ID" use="optional"/> <xs:attribute name="observable-id" type="xs:ID" use="optional"/>
skipping to change at page 156, line 7 skipping to change at page 157, line 7
<xs:enumeration value="csv"/> <xs:enumeration value="csv"/>
<xs:enumeration value="winreg"/> <xs:enumeration value="winreg"/>
<xs:enumeration value="xml"/> <xs:enumeration value="xml"/>
<xs:enumeration value="ext-value"/> <xs:enumeration value="ext-value"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
9. Security Considerations 9. Security Considerations
The IODEF data model does not directly introduce security issues. The IODEF data model does not directly introduce security or privacy
However, as the data encoded by the IODEF might be considered issues. However, as the data encoded by the IODEF might be
sensitive by the parties exchanging it or by those described by it, considered sensitive by the parties exchanging it or by those
care needs to be taken to ensure appropriate handling during the described by it, care needs to be taken to ensure appropriate
document exchange, subsequent processing or archiving. handling during the document construction, exchange, processing,
archiving, subsequent retrieval and analysis.
The contents of an IODEF document may include a request for action. 9.1. Security
An IODEF implementation may also initiate courses of action based on
the document contents. For these reasons, care must be taken by
IODEF implementations to properly authenticate the sender and
receiver of the document. The recipient must also ascribe
appropriate confidence to the data prior to action.
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 also initiate courses of action based on
the document contents. For these reasons, care must be taken by
IODEF implementations to properly authenticate the sender and
receiver of the document. The recipient must also ascribe
appropriate confidence to the data prior to action.
Executable content could be embedded into the IODEF document directly Executable content could be embedded into the IODEF document directly
or through an extension. The IODEF implementation MUST handle this or through an extension. The IODEF implementation MUST handle this
content with care to prevent unintentional automated execution. content with care to prevent unintentional automated execution.
9.2. Privacy
The IODEF contains numerous fields that are identifiers which could
be linked to an individual or organization. IODEF documents may
contain sensitive information about these identified parties; and
repeated document exchanges about the same and related parties may
enable the correlation of data about them. Likewise, a party may
report on another to a third party without their knowledge.
When creating an IODEF document, careful consideration must be given
to what information is shared. Personal identifiers and attributable
sensitive information should only be shared when necessary.
When exchanging documents, transport security MUST provide document-
level confidentiality. XML element-level confidentiality can also be
provided by using [W3C.XMLENC].
In order to suggest data processing and handling guidelines of the In order to suggest data processing and handling guidelines of the
encoded information, the IODEF allows a document sender to convey a encoded information, the IODEF allows a document sender to convey a
privacy policy using the restriction attribute. The various privacy policy using the restriction attribute. The various
instances of this attribute allow different data elements of the instances of this attribute allow different data elements of the
document to be covered by dissimilar policies. While flexible, it document to be covered by dissimilar policies. While flexible, it
must be stressed that this approach only serves as a guideline from must be stressed that this approach only serves as a guideline from
the sender, as the recipient is free to ignore it. the sender, as the recipient is free to ignore it.
Although outside of the scope of an IODEF implementation, the
contents of IODEF documents and any derived analysis should be
archived with at appropriate confidentiality controls. Likewise,
access to retrieve and analyze this data should be restricted to
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.
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]
skipping to change at page 160, line 43 skipping to change at page 162, line 22
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", W3C
Recommendation , January 1999, Recommendation , January 1999,
<http://www.w3.org/TR/REC-xml-names/>. <http://www.w3.org/TR/REC-xml-names/>.
[W3C.XPATH] [W3C.XPATH]
World Wide Web Consortium, "XML Path Language (XPath) World Wide Web Consortium, "XML Path Language (XPath)
2.0", W3C Candidate Recommendation , June 2006, 3.1", W3C Candidate Recommendation , December 2015,
<http://www.w3.org/TR/xpath20/>. <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 Candidate Recommendation , June 2008, Processing 2.0", W3C Recommendation , June 2008,
<http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/xmldsig-core/>.
[IEEE.POSIX] [IEEE.POSIX]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information Technology - Portable Operating System "Information Technology - Portable Operating System
Interface (POSIX) - Part 1: Base Definitions", Interface (POSIX) - Part 1: Base Definitions",
IEEE 1003.1, June 2001. IEEE 1003.1, June 2001.
[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.
skipping to change at page 163, line 20 skipping to change at page 164, line 43
Microsoft Corporation, "How to add, modify, or delete Microsoft Corporation, "How to add, modify, or delete
registry subkeys and values by using a registration registry subkeys and values by using a registration
entries (.reg) file", December 2007. entries (.reg) file", December 2007.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- [RFC4180] 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.
[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.
Author's Address [W3C.XMLENC]
World Wide Web Consortium, "XML Encryption Syntax and
Processing Version 1.1", W3C Recommendation , April 2013,
<https://www.w3.org/TR/xmlenc-core1/>.
Author's Address
Roman Danyliw Roman Danyliw
CERT - Carnegie Mellon University CERT - Carnegie Mellon University
Pittsburgh, PA Pittsburgh, PA
USA USA
EMail: rdd@cert.org EMail: rdd@cert.org
 End of changes. 25 change blocks. 
144 lines changed or deleted 236 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/