draft-ietf-mile-rolie-csirt-05.txt   draft-ietf-mile-rolie-csirt-06.txt 
MILE Working Group S. Banghart MILE Working Group S. Banghart
Internet-Draft NIST Internet-Draft NIST
Intended status: Standards Track J. Field Intended status: Standards Track J. Field
Expires: March 8, 2020 Pivotal Expires: April 30, 2020 Pivotal
September 5, 2019 October 28, 2019
Definition of ROLIE CSIRT Extension Definition of ROLIE CSIRT Extension
draft-ietf-mile-rolie-csirt-05 draft-ietf-mile-rolie-csirt-06
Abstract Abstract
This document extends the Resource-Oriented Lightweight Information This document extends the Resource-Oriented Lightweight Information
Exchange (ROLIE) core to add the information type categories and Exchange (ROLIE) core to add the Indicator and Incident information
related requirements needed to support Computer Security Incident types, relevant categories, and related requirements needed to
Response Team (CSIRT) use cases. The indicator and incident support Computer Security Incident Response Team (CSIRT) use cases.
information types are defined as ROLIE extensions. Additional Additional supporting requirements are also defined that describe the
supporting requirements are also defined that describe the use of use of specific formats and link relations pertaining to the new
specific formats and link relations pertaining to the new information information types.
types.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 8, 2020. This Internet-Draft will expire on April 30, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Information-type Extensions . . . . . . . . . . . . . . . . . 4 3. Information-type Extensions . . . . . . . . . . . . . . . . . 4
3.1. The "incident" information type . . . . . . . . . . . . . 4 3.1. The "incident" information type . . . . . . . . . . . . . 4
3.2. The "indicator" information type . . . . . . . . . . . . 4 3.2. The "indicator" information type . . . . . . . . . . . . 5
4. Data format requirements . . . . . . . . . . . . . . . . . . 5 4. Data format requirements . . . . . . . . . . . . . . . . . . 5
4.1. Incident Object Description Exchange Format . . . . . . . 5 4.1. Incident Object Description Exchange Format . . . . . . . 6
4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 6
4.2. Structured Threat Information eXpression (STIX) Format . 6 4.2. Structured Threat Information eXpression (STIX) Format . 6
4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 7
4.3. Malware Information Sharing Platform (MISP) Format . . . 7 4.3. Malware Information Sharing Platform (MISP) Format . . . 7
4.3.1. Creating MISP Event Entries . . . . . . . . . . . . . 7 4.3.1. Creating MISP Event Entries . . . . . . . . . . . . . 8
4.3.2. MISP Feeds and Manifests . . . . . . . . . . . . . . 8 4.3.2. MISP Feeds and Manifests . . . . . . . . . . . . . . 8
5. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 8 5. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9
5.1. Link relations for the 'incident' 5.1. Link relations for the 'incident'
information-type . . . . . . . . . . . . . . . . . . . . 9 information-type . . . . . . . . . . . . . . . . . . . . 9
5.2. Link relations for the 'indicator' 5.2. Link relations for the 'indicator'
information-type . . . . . . . . . . . . . . . . . . . . 9 information-type . . . . . . . . . . . . . . . . . . . . 10
5.3. Link relations for both information-types . . . . . . . . 10 5.3. Link relations for both information-types . . . . . . . . 10
6. atom:category Extensions . . . . . . . . . . . . . . . . . . 10 6. atom:category Extensions . . . . . . . . . . . . . . . . . . 11
6.1. Newly registered category values . . . . . . . . . . . . 10 6.1. Newly registered category values . . . . . . . . . . . . 11
6.2. Expectation and Impact Classes . . . . . . . . . . . . . 11 6.2. Expectation and Impact Classes . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. information-type registrations . . . . . . . . . . . . . 11 7.1. information-type registrations . . . . . . . . . . . . . 12
7.1.1. incident information-type . . . . . . . . . . . . . . 11 7.1.1. incident information-type . . . . . . . . . . . . . . 12
7.1.2. indicator information-type . . . . . . . . . . . . . 11 7.1.2. indicator information-type . . . . . . . . . . . . . 12
7.2. atom:category scheme registrations . . . . . . . . . . . 12 7.2. atom:category scheme registrations . . . . . . . . . . . 12
7.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 12 7.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 13
7.2.2. category:csirt:iodef:restriction . . . . . . . . . . 12 7.2.2. category:csirt:iodef:restriction . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Examples of Use . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples of Use . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Threats to computer security are evolving ever more rapidly as time Threats to computer security are evolving ever more rapidly as time
goes on. As software increases in complexity, the number of goes on. As software increases in complexity, the number of
vulnerabilities in systems and networks can increase exponentially. vulnerabilities in systems and networks can increase exponentially.
Threat actors looking to exploit these vulnerabilities are making Threat actors looking to exploit these vulnerabilities are making
more frequent and more widely distributed attacks across a large more frequent and more widely distributed attacks across a large
variety of systems. The adoption of liberal information sharing variety of systems. The adoption of liberal information sharing
amongst attackers allows a discovered vulnerability to be shared and amongst attackers allows a discovered vulnerability to be shared and
used to attack a vulnerable system within a narrow window of time. used to attack a vulnerable system within a narrow window of time.
As the skills and knowledge required to identify and combat these As the skills and knowledge required to identify and combat these
attacks become more and more specialized, even a well established and attacks become more and more specialized, even a well established and
secure system may find itself unable to quickly respond to an secure system may find itself unable to quickly respond to an
incident. Effective identification of and response to a incident. Effective identification of and response to a
sophisticated attack requires open cooperation and collaboration sophisticated attack requires open cooperation and collaboration
skipping to change at page 3, line 20 skipping to change at page 3, line 25
As the skills and knowledge required to identify and combat these As the skills and knowledge required to identify and combat these
attacks become more and more specialized, even a well established and attacks become more and more specialized, even a well established and
secure system may find itself unable to quickly respond to an secure system may find itself unable to quickly respond to an
incident. Effective identification of and response to a incident. Effective identification of and response to a
sophisticated attack requires open cooperation and collaboration sophisticated attack requires open cooperation and collaboration
between defending operators, software vendors, and end-users. To between defending operators, software vendors, and end-users. To
improve the timeliness of responses, automation must be used to improve the timeliness of responses, automation must be used to
acquire, contextualize, and put to use shared computer security acquire, contextualize, and put to use shared computer security
information. information.
CSIRTs share two primary forms of information: incidents and Computer Security Incident Response Teams (CSIRTs) share two primary
indicators. Using these forms of information, analysts are able to forms of information: incidents and indicators. Using these forms of
perform a wide range of activities both proactive and reactive to information, analysts are able to perform a wide range of activities
ensure the security of their systems. both proactive and reactive to improve the security of their systems.
Incident information describes a cyber security incident. Such Incident information describes a cyber security incident. Such
information may include attack characteristics, information about the information may include attack characteristics, information about the
attacker, and attack vector data. Sharing this information helps attacker, and attack vector data. Sharing this information helps
analysts within the sharing community to inoculate their systems analysts within the sharing community to inoculate their systems
against similar attacks, providing proactive protection. against similar attacks, providing proactive protection.
Indicator information describes the symptoms or necessary pre- Indicator information describes the symptoms or necessary pre-
conditions of an attack. Everything from system vulnerabilities to conditions of an attack. Everything from system vulnerabilities to
unexpected network traffic can help analysts secure systems and unexpected network traffic can help analysts secure systems and
skipping to change at page 3, line 50 skipping to change at page 4, line 9
the Resource-Oriented Lightweight Information Exchange (ROLIE) core the Resource-Oriented Lightweight Information Exchange (ROLIE) core
[RFC8322] designed to address CSIRT use cases. The primary purpose [RFC8322] designed to address CSIRT use cases. The primary purpose
of this extension is to define two new information types: incident, of this extension is to define two new information types: incident,
and indicator, along with formats and link relations that support and indicator, along with formats and link relations that support
these information-types. these information-types.
2. Terminology 2. Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC8174].
Definitions for some of the common computer security-related Definitions for some of the common computer security-related
terminology used in this document can be found in Section 2 of terminology used in this document can be found in Section 2 of
[RFC5070]. [RFC5070].
As an extension of [RFC8322], this document refers to many terms
defined in that document. In particular, the use of "Entry" and
"Feed" are aligned with the definitions presented there.
Several places in this document refer to the "information-type" of a
Resource (Entry or Feed). This refers to the "term" attribute of an
"atom:category" element whose scheme is
"urn:ietf:params:rolie:category:information-type". For an Entry,
this value can be inherited from it's containing Feed as per
[RFC8322].
3. Information-type Extensions 3. Information-type Extensions
3.1. The "incident" information type 3.1. The "incident" information type
When an "atom:category" element has a "scheme" attribute equal to When an "atom:category" element has a "scheme" attribute equal to
"urn:ietf:params:rolie:category:information-type", the "term" "urn:ietf:params:rolie:category:information-type", the "term"
attribute defines the information type of the associated resource. A attribute defines the information type of the associated resource. A
new valid "term" value for this "scheme": "incident", is described in new valid "term" value for this "scheme": "incident", is described in
this section, and registered in Section 7.1.1. this section, and registered in Section 7.1.1.
skipping to change at page 4, line 40 skipping to change at page 5, line 8
o Response information: the methods and results of a response to the o Response information: the methods and results of a response to the
incident. incident.
o Meta and contact information: data about the CSIRT that recorded o Meta and contact information: data about the CSIRT that recorded
the information, or the operator that enacted the response. the information, or the operator that enacted the response.
o Effect and result information: data that describes the effects of o Effect and result information: data that describes the effects of
an incident, or what the final results of the incident are. an incident, or what the final results of the incident are.
Note again that this list is not exhaustive, any information that in Note again that this list is not exhaustive, any information that is
is the abstract realm of an incident should be classified under this in the abstract realm of an incident should be classified under this
information-type. information-type.
3.2. The "indicator" information type 3.2. The "indicator" information type
When an "atom:category" element has a "scheme" attribute equal to When an "atom:category" element has a "scheme" attribute equal to
"urn:ietf:params:rolie:category:information-type", the "term" "urn:ietf:params:rolie:category:information-type", the "term"
attribute defines the information type of the associated resource. A attribute defines the information type of the associated resource. A
new valid "term" value for this "scheme": "indicator", is described new valid "term" value for this "scheme": "indicator", is described
in this section, and registered in Section 7.1.2. in this section, and registered in Section 7.1.2.
The "indicator" information type represents computer security The "indicator" information type represents computer security
indicators or any information surrounding them. This document uses indicators or any information surrounding them. This document uses
the definition of indicator provided by [RFC4949]. Some examples of the definition of indicator provided by [RFC4949]. Some examples of
indicator information is provided below, but note that indicator is indicator information are provided below, but note that indicator is
defined in an abstract sense, to be understood as a flexible and defined in an abstract sense, to be understood as a flexible and
widely-applicable definition. widely-applicable definition.
o Specific vulnerabilities that indicate a vector for attack. o Specific vulnerabilities that indicate a vector for attack.
o Signs of malicious reconnaissance. o Signs of malicious reconnaissance.
o Definitions of patterns of other indicators. o Definitions of patterns of other indicators.
o Events that may indicate an attack and information regarding those o Events that may indicate an attack and information regarding those
skipping to change at page 7, line 20 skipping to change at page 7, line 41
o There MUST be at least one "rolie:property" with the "name" o There MUST be at least one "rolie:property" with the "name"
attribute equal to "urn:ietf:params:rolie:property:content-id" and attribute equal to "urn:ietf:params:rolie:property:content-id" and
the "value" attribute exactly equal to the "<id>" element in the the "value" attribute exactly equal to the "<id>" element in the
attached STIX object . This allows for ROLIE consumers to more attached STIX object . This allows for ROLIE consumers to more
easily search for STIX objects without needing to download the easily search for STIX objects without needing to download the
document itself. document itself.
4.3. Malware Information Sharing Platform (MISP) Format 4.3. Malware Information Sharing Platform (MISP) Format
MISP involves documentation, utilities, and formats designed to MISP involves documentation, utilities, and formats designed to
facilitate the day-to=day duties of security operators. MISP facilitate the day-to-day duties of security operators. MISP
includes it's own data format that is used to share between MISP includes it's own data format that is used to share between MISP
features. While MISP has Feed features that can share and distribute features. While MISP has Feed features that can share and distribute
events, it has support for linking to other sharing methods like events, it has support for linking to other sharing methods like
ROLIE. ROLIE.
MISP is defined by a family of internet drafts and are actively being MISP is defined by a family of internet drafts currently being
worked on. With that in mind, this extension will provide non- developed in the IETF. With that in mind, this extension will
normative guidance on using MISP format data in ROLIE. In the provide non-normative guidance on using MISP format data in ROLIE.
future, when the MISP format is formally published, this document In the future, when the MISP format is formally published, this
will be updated to normative requirements around MISP content. document will be updated to normative requirements around MISP
content.
4.3.1. Creating MISP Event Entries 4.3.1. Creating MISP Event Entries
MISP content should be syndicated in ROLIE using the following MISP content should be syndicated in ROLIE using the following
guidance: guidance:
o The information-type of the Entry is "indicator". For a typical o The information-type of the Entry is "indicator". For a typical
Entry, this is derived from the information type of the Feed it is Entry, this is derived from the information type of the Feed it is
contained in. For a standalone Entry, this is provided by an contained in. For a standalone Entry, this is provided by an
"atom:category" element. "atom:category" element.
skipping to change at page 7, line 52 skipping to change at page 8, line 27
o The document linked to by the "href" attribute of the o The document linked to by the "href" attribute of the
"atom:content" element is a MISP Event object as per "atom:content" element is a MISP Event object as per
[I-D.dulaunoy-misp-core-format] [I-D.dulaunoy-misp-core-format]
o The value of the "type" attribute of the "atom:content" element o The value of the "type" attribute of the "atom:content" element
should be "application/xml". should be "application/xml".
o There should be at least one "rolie:property" with the "name" o There should be at least one "rolie:property" with the "name"
attribute equal to "urn:ietf:params:rolie:property:content-id" and attribute equal to "urn:ietf:params:rolie:property:content-id" and
the "value" attribute exactly equal to the "<uuid>" element in the the "value" attribute exactly equal to the "<uuid>" element in the
attached MISP Event . This allows for ROLIE consumers to more attached MISP Event. This allows for ROLIE consumers to more
easily search for MISP Events without needing to download the easily search for MISP Events without needing to download the
document itself. document itself.
o It is also recommended to expose information in the ROLIE Entry o It is also recommended to expose information in the ROLIE Entry
that is required and recommended to expose in the MISP Manifest that is required and recommended to expose in the MISP Manifest
format. This ensures better compatibility between a ROLIE Feed format. This ensures better compatibility between a ROLIE Feed
and a MISP Manifest and a MISP Manifest.
* The following fields are required by the MISP draft: info, * The following fields are required by the MISP draft: info,
Orgc, timestamp, date Orgc, timestamp, date
* The following fields are recommended by the MISP draft: * The following fields are recommended by the MISP draft:
analysis, threat_level_id analysis, threat_level_id
4.3.2. MISP Feeds and Manifests 4.3.2. MISP Feeds and Manifests
MISP Feeds are hosted lists of MISP events, each event represented by MISP Feeds are hosted lists of MISP events, each event represented by
skipping to change at page 9, line 12 skipping to change at page 9, line 35
in the Link Relation IANA table as their use case is too narrow. in the Link Relation IANA table as their use case is too narrow.
Each relationship is named and described. Each relationship is named and described.
These relations come in related pairs. The first of each pair is These relations come in related pairs. The first of each pair is
expected to be more common, as they can be determined at the time expected to be more common, as they can be determined at the time
that the Entry is created. The second of each pair will often need that the Entry is created. The second of each pair will often need
to be added retroactively to an Entry. to be added retroactively to an Entry.
5.1. Link relations for the 'incident' information-type 5.1. Link relations for the 'incident' information-type
If a ROLIE server supports either the incident information-types, If a ROLIE server supports the incident information-type, then these
then these link relations MUST be support link relations MUST be supported.
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Name | Description | | Name | Description |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| indicators | Provides a link to a collection of zero or more | | indicators | Provides a link to a collection of zero or more |
| | instances of cyber security indicators that are | | | instances of cyber security indicators that are |
| | associated with the resource. | | | associated with the resource. |
| evidence | Provides a link to a collection of zero or more | | evidence | Provides a link to a collection of zero or more |
| | resources that provides some proof of attribution | | | resources that provides some proof of attribution |
| | for an incident. The evidence may or may not have | | | for an incident. The evidence may or may not have |
skipping to change at page 9, line 38 skipping to change at page 10, line 28
| vector | Provides a link to a collection of zero or more | | vector | Provides a link to a collection of zero or more |
| | resources that provides a representation of the | | | resources that provides a representation of the |
| | method used by the attacker. | | | method used by the attacker. |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
Table 1: Link Relations for Resource-Oriented Lightweight Indicator Table 1: Link Relations for Resource-Oriented Lightweight Indicator
Exchange Exchange
5.2. Link relations for the 'indicator' information-type 5.2. Link relations for the 'indicator' information-type
If a ROLIE server supports the indicator information-types, then If a ROLIE server supports the indicator information-type, then these
these link relations MUST be supported. link relations MUST be supported.
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Name | Description | | Name | Description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| incidents | Provides a link to a collection of zero or more | | incidents | Provides a link to a collection of zero or more |
| | instances of incident representations associated with | | | instances of incident representations associated with |
| | the resource. | | | the resource. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 2: Link Relations for Resource-Oriented Lightweight Indicator Table 2: Link Relations for Resource-Oriented Lightweight Indicator
skipping to change at page 12, line 37 skipping to change at page 13, line 32
Extension IRI: Extension IRI:
urn:ietf:params:rolie:category:csirt:iodef:restriction urn:ietf:params:rolie:category:csirt:iodef:restriction
Reference: This document, Section 6.1 Reference: This document, Section 6.1
Subregistry: None Subregistry: None
8. Security Considerations 8. Security Considerations
This document implies the use of ROLIE in high-security use cases, as This document implies the use of ROLIE in high-security use cases; as
such, added care should be taken to fortify and secure ROLIE such, added care should be taken to fortify and secure ROLIE
repositories and clients using this extension. The guidance in the repositories and clients using this extension. The guidance in the
ROLIE core specification is strongly recommended, and implementers ROLIE core specification is strongly recommended, and implementers
should consider adding additional security measures as they see fit. should consider adding additional security measures as they see fit.
When providing a private workspace for closed sharing, it is When providing a private workspace for closed sharing, it is
recommended that the ROLIE repository checks user authorization when recommended that the ROLIE repository checks user authorization when
the user sends a GET request to the service document. If the user is the user sends a GET request to the service document. If the user is
not authorized to send any requests to a given workspace or not authorized to send any requests to a given workspace or
collection, that workspace or collection should be truncated from the collection, that workspace or collection should be truncated from the
service document in the response. In this way the existence of service document in the response. In this way the existence of
unauthorized content remains unknown to potential attackers, unauthorized content remains unknown to potential attackers,
hopefully reducing attack surface. hopefully reducing attack surface.
When sharing IODEF 2 documents using a ROLIE server, care should be When sharing IODEF Version 2 documents using a ROLIE server, care
taken to seperate IODEF Entries into different workspaces based on should be taken to seperate IODEF Entries into different workspaces
the "restriction" attribute of the IODEF Document (and therefore the based on the "restriction" attribute of the IODEF Document (and
restriction property in ROLIE). Security and access controls are therefore the restriction property in ROLIE). Security and access
most effectively deployed at the workspace level, as such, keeping controls are most effectively deployed at the workspace level, as
private and need-to-know IODEF documents in their own workspace helps such, keeping private and need-to-know IODEF documents in their own
prevent unintended information leakage. workspace helps prevent unintended information leakage.
9. Normative References 9. References
[I-D.dulaunoy-misp-core-format] 9.1. Normative References
Dulaunoy, A. and A. Iklody, "MISP core format", draft-
dulaunoy-misp-core-format-07 (work in progress), February
2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <https://www.rfc-editor.org/info/rfc4287>. December 2005, <https://www.rfc-editor.org/info/rfc4287>.
skipping to change at page 13, line 46 skipping to change at page 14, line 37
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
DOI 10.17487/RFC5070, December 2007, DOI 10.17487/RFC5070, December 2007,
<https://www.rfc-editor.org/info/rfc5070>. <https://www.rfc-editor.org/info/rfc5070>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange [RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970, Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>. November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
Oriented Lightweight Information Exchange (ROLIE)", Oriented Lightweight Information Exchange (ROLIE)",
RFC 8322, DOI 10.17487/RFC8322, February 2018, RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/info/rfc8322>. <https://www.rfc-editor.org/info/rfc8322>.
[stix2] Organization for the Advancement of Structured Information [stix2] Organization for the Advancement of Structured Information
Standards (OASIS) Cyber Threat Intelligence (CTI) Standards (OASIS) Cyber Threat Intelligence (CTI)
Technical Committee, "Structured Threat Information Technical Committee, "Structured Threat Information
Expression 2.0", July 2017, <https://oasis-open.github.io/ Expression 2.0", July 2017, <https://oasis-open.github.io/
cti-documentation/resources#stix-20-specification>. cti-documentation/resources#stix-20-specification>.
9.2. Informative References
[I-D.dulaunoy-misp-core-format]
Dulaunoy, A. and A. Iklody, "MISP core format", draft-
dulaunoy-misp-core-format-07 (work in progress), February
2019.
Appendix A. Examples of Use Appendix A. Examples of Use
Use of this extension in a ROLIE repository will not typically change Use of this extension in a ROLIE repository will not typically change
that repository's operation. As such, the general examples provided that repository's operation. As such, the general examples provided
by the ROLIE core document would serve as examples. Provided below by the ROLIE core document would serve as examples. Provided below
is a sample incident ROLIE entry containing an IODEF document: is a sample incident ROLIE entry containing an IODEF document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" <entry xmlns="http://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"> xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0">
 End of changes. 32 change blocks. 
67 lines changed or deleted 87 lines changed or added

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