draft-ietf-mile-rolie-csirt-02.txt   draft-ietf-mile-rolie-csirt-03.txt 
MILE Working Group S. Banghart MILE Working Group S. Banghart
Internet-Draft NIST Internet-Draft NIST
Intended status: Informational J. Field Intended status: Informational J. Field
Expires: September 27, 2019 Pivotal Expires: January 21, 2020 Pivotal
March 26, 2019 July 20, 2019
Definition of ROLIE CSIRT Extension Definition of ROLIE CSIRT Extension
draft-ietf-mile-rolie-csirt-02 draft-ietf-mile-rolie-csirt-03
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 information type categories and
related requirements needed to support Computer Security Incident related requirements needed to support Computer Security Incident
Response Team (CSIRT) use cases. The indicator and incident Response Team (CSIRT) use cases. The indicator and incident
information types are defined as ROLIE extensions. Additional information types are defined as ROLIE extensions. Additional
supporting requirements are also defined that describe the use of supporting requirements are also defined that describe the use of
specific formats and link relations pertaining to the new information specific formats and link relations pertaining to the new information
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 27, 2019. This Internet-Draft will expire on January 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Additional Requirements for the Atom Publishing Protocol . . 4 3. Information-type Extensions . . . . . . . . . . . . . . . . . 4
3.1. Use of HTTP requests . . . . . . . . . . . . . . . . . . 4 3.1. The "incident" information type . . . . . . . . . . . . . 4
3.1.1. / (forward slash) Resource URL . . . . . . . . . . . 4 3.2. The "indicator" information type . . . . . . . . . . . . 4
4. Information-type Extensions . . . . . . . . . . . . . . . . . 4 4. Data format requirements . . . . . . . . . . . . . . . . . . 5
4.1. The "incident" information type . . . . . . . . . . . . . 4 4.1. Incident Object Description Exchange Format . . . . . . . 5
4.2. The "indicator" information type . . . . . . . . . . . . 5 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5
5. Data format requirements . . . . . . . . . . . . . . . . . . 5 4.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 6
5.1. Incident Object Description Exchange Format . . . . . . . 6 4.2. Structured Threat Information eXpression (STIX) Format . 6
5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 6
5.2. Structured Threat Information eXpression (STIX) Format . 7 4.3. Malware Information Sharing Platform (MISP) Format . . . 7
5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Creating MISP Event Entries . . . . . . . . . . . . . 7
5.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 7 4.3.2. MISP Feeds and Manifests . . . . . . . . . . . . . . 8
5.3. Malware Information Sharing Platform (MISP) Format . . . 7 5. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Creating MISP Event Entries . . . . . . . . . . . . . 8 5.1. Link relations for the 'incident'
5.3.2. MISP Feeds and Manifests . . . . . . . . . . . . . . 8
6. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9
6.1. Link relations for the 'incident'
information-type . . . . . . . . . . . . . . . . . . . . 9 information-type . . . . . . . . . . . . . . . . . . . . 9
6.2. Link relations for the 'indicator' 5.2. Link relations for the 'indicator'
information-type . . . . . . . . . . . . . . . . . . . . 10 information-type . . . . . . . . . . . . . . . . . . . . 9
6.3. Link relations for both information-types . . . . . . . . 11 5.3. Link relations for both information-types . . . . . . . . 10
7. atom:category Extensions . . . . . . . . . . . . . . . . . . 11 6. atom:category Extensions . . . . . . . . . . . . . . . . . . 10
7.1. Newly registered category values . . . . . . . . . . . . 12 6.1. Newly registered category values . . . . . . . . . . . . 10
7.2. Expectation and Impact Classes . . . . . . . . . . . . . 12 6.2. Expectation and Impact Classes . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. information-type registrations . . . . . . . . . . . . . 12 7.1. information-type registrations . . . . . . . . . . . . . 11
8.1.1. incident information-type . . . . . . . . . . . . . . 13 7.1.1. incident information-type . . . . . . . . . . . . . . 11
8.1.2. indicator information-type . . . . . . . . . . . . . 13 7.1.2. indicator information-type . . . . . . . . . . . . . 12
8.2. atom:category scheme registrations . . . . . . . . . . . 13 7.2. atom:category scheme registrations . . . . . . . . . . . 12
8.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 13 7.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 12
8.2.2. category:csirt:iodef:restriction . . . . . . . . . . 13 7.2.2. category:csirt:iodef:restriction . . . . . . . . . . 12
8.3. rolie:property name registrations . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.3.1. property:csirt:id . . . . . . . . . . . . . . . . . . 14 9. Normative References . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 Appendix A. Examples of Use . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Examples of Use . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 25 skipping to change at page 3, line 20
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 CSIRTs share two primary forms of information: incidents and
indicators. Using these forms of information, analysts are able to indicators. Using these forms of information, analysts are able to
perform a wide range of activities both proactive and reactive to perform a wide range of activities both proactive and reactive to
ensure the security of their systems. ensure 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.
skipping to change at page 4, line 15 skipping to change at page 4, line 9
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 [RFC2119].
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].
3. Additional Requirements for the Atom Publishing Protocol 3. Information-type Extensions
This document specifies the following additional requirements for use
of the Atom Publishing Protocol.[RFC5023]
3.1. Use of HTTP requests
This document defines the following requirements on HTTP request
behavior:
3.1.1. / (forward slash) Resource URL
The forward slash resource URL SHOULD be supported as defined in
Section 5.5 [RFC8322]. Note that this is a stricter requirement than
[RFC8322].
4. Information-type Extensions
4.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 8.1.1. this section, and registered in Section 7.1.1.
The "incident" information type represents any information describing The "incident" information type represents any information describing
or pertaining to a computer security incident. This document uses or pertaining to a computer security incident. This document uses
the definition of incident provided by [RFC4949]. Provided below is the definition of incident provided by [RFC4949]. Provided below is
a non-exhaustive list of information that may be considered to be an a non-exhaustive list of information that may be considered to be an
incident information type. incident information type.
o Timing information: start and end times for the incident and/or o Timing information: start and end times for the incident and/or
the response. the response.
skipping to change at page 5, line 18 skipping to change at page 4, line 44
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 in
is the abstract realm of an incident should be classified under this is the abstract realm of an incident should be classified under this
information-type. information-type.
4.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 8.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 is 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.
skipping to change at page 5, line 47 skipping to change at page 5, line 26
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
events. events.
o Meta information about the collecting agent. o Meta information about the collecting agent.
This list is intended to provide examples of the indicator This list is intended to provide examples of the indicator
information-type, not to define it. information-type, not to define it.
5. Data format requirements 4. Data format requirements
This section defines usage guidance and additional requirements This section defines usage guidance and additional requirements
related to data formats above and beyond those specified in related to data formats above and beyond those specified in
[RFC8322]. The following formats are expected to be commonly used to [RFC8322]. The following formats are expected to be commonly used to
express software descriptor information. For this reason, this express software descriptor information. For this reason, this
document specifies additional requirements to ensure document specifies additional requirements to ensure
interoperability. interoperability.
5.1. Incident Object Description Exchange Format 4.1. Incident Object Description Exchange Format
5.1.1. Description 4.1.1. Description
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) or other between Computer Security Incident Response Teams (CSIRTs) or other
operational security teams. operational security teams.
IODEF conveys indicators, incident reports, response activities, and IODEF conveys indicators, incident reports, response activities, and
related meta-data in an XML serialization. This information is related meta-data in an XML serialization. This information is
formally structured in order to support and encourage automated formally structured in order to support and encourage automated
machine-to-machine security communication, as well as enhanced machine-to-machine security communication, as well as enhanced
processing at the endpoint. processing at the endpoint.
The full IODEF specification [RFC7970] provides further high-level The full IODEF specification [RFC7970] provides further high-level
discussion and technical details. discussion and technical details.
5.1.2. Requirements 4.1.2. Requirements
For an Entry to be considered as a "IODEF Entry", it MUST fulfill the For an Entry to be considered as a "IODEF Entry", it MUST fulfill the
following conditions: following conditions:
o The information-type of the Entry is "indicator" or "incident". o The information-type of the Entry is "indicator" or "incident".
For a typical Entry, this is derived from the information type of For a typical Entry, this is derived from the information type of
the Feed it is contained in. For a standalone Entry, this is the Feed it is contained in. For a standalone Entry, this is
provided by an "atom:category" element. provided by an "atom:category" element.
o o
skipping to change at page 6, line 50 skipping to change at page 6, line 30
A "IODEF Entry" MUST conform to the following requirements: A "IODEF Entry" MUST conform to the following requirements:
o The value of the "type" attribute of the "atom:content" element o The value of the "type" attribute of the "atom:content" element
MUST be "application/xml". MUST be "application/xml".
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 "<Indicator-ID>" or the the "value" attribute exactly equal to the "<Indicator-ID>" or the
"<Incident-ID>" element in the attached IODEF document. This "<Incident-ID>" element in the attached IODEF document. This
allows for ROLIE consumers to more easily search for IODEF allows for ROLIE consumers to more easily search for IODEF
doucments without needing to download the doucment itself. documents without needing to download the document itself.
5.2. Structured Threat Information eXpression (STIX) Format 4.2. Structured Threat Information eXpression (STIX) Format
5.2.1. Description 4.2.1. Description
STIX is a structured language for describing a wide range of security STIX is a structured language for describing a wide range of security
resources. STIX approaches the problem with a focus on flexibility, resources. STIX approaches the problem with a focus on flexibility,
automation, readability, and extensibility. automation, readability, and extensibility.
The full STIX specification [stix2] provides further high-level The full STIX specification [stix2] provides further high-level
discussion and technical details. discussion and technical details.
5.2.2. Requirements 4.2.2. Requirements
For an Entry to be considered as a "STIX Entry", it MUST fulfill the For an Entry to be considered as a "STIX Entry", it MUST fulfill the
following conditions: following conditions:
o The information-type of the Entry is "indicator" or "incident". o The information-type of the Entry is "indicator" or "incident".
For a typical Entry, this is derived from the information type of For a typical Entry, this is derived from the information type of
the Feed it is contained in. For a standalone Entry, this is the Feed it is contained in. For a standalone Entry, this is
provided by an "atom:category" element. provided by an "atom:category" element.
o o
skipping to change at page 7, line 43 skipping to change at page 7, line 22
o The value of the "type" attribute of the "atom:content" element o The value of the "type" attribute of the "atom:content" element
MUST be "application/xml" or "application/json". MUST be "application/xml" or "application/json".
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.
5.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
faciliate the day-to=day duties of security operators. MISP includes facilitate the day-to=day duties of security operators. MISP
it's own data format that is used to share between MISP features. includes it's own data format that is used to share between MISP
While MISP has Feed features that can share and distribute events, it features. While MISP has Feed features that can share and distribute
has support for linking to other sharing methods like ROLIE. events, it has support for linking to other sharing methods like
ROLIE.
MISP is defined by a family of internet drafts and are actively being MISP is defined by a family of internet drafts and are actively being
worked on. With that in mind, this extension will provice non- worked on. With that in mind, this extension will provide non-
normative guidance on using MISP format data in ROLIE. In the normative guidance on using MISP format data in ROLIE. In the
future, when the MISP format is formally published, this document future, when the MISP format is formally published, this document
will be updated to normative requirements around MISP content. will be updated to normative requirements around MISP content.
5.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.
o The document linked to by the "href" attribute of the o The document linked to by the "href" attribute of the
skipping to change at page 8, line 34 skipping to change at page 8, line 14
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 compatability 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
5.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
its uuid. Users request Events on a one-by-one basis and are served its UUID. Users request Events on a one-by-one basis and are served
the full Event on each request. the full Event on each request.
MISP Manifest files list MISP events by their uuids as well, but MISP Manifest files list MISP events by their UUIDs as well, but
provide a variety of metadata for each Event inline. After examining provide a variety of metadata for each Event inline. After examining
the minimized and stripped Event in the manifest, a user could search the minimized and stripped Event in the manifest, a user could search
for the Event uuid of interest in a locally located folder of Event for the Event UUID of interest in a locally located folder of Event
files where the file name is the uuid of the Event. files where the file name is the UUID of the Event.
ROLIE hosting MISP data would operate as a combination of these ROLIE hosting MISP data would operate as a combination of these
approaches. Each ROLIE Feed would contain a list of Event Entries, approaches. Each ROLIE Feed would contain a list of Event Entries,
each with metadata and identifying information about a given Event. each with metadata and identifying information about a given Event.
SHould the user be interested in the Event, the Event Entry provides Should the user be interested in the Event, the Event Entry provides
a direct link to download the full Event. In short, a ROLIE MISP a direct link to download the full Event. In short, a ROLIE MISP
Feed is minimumally mappable to a MISP Manifest file where a Feed is minimally mappable to a MISP Manifest file where a resolvable
resolvable link to the MISP Event was injected into each Event link to the MISP Event was injected into each Event described in the
described in the Manifest. Manifest.
With that in mind, a MISP Feed as well as a MISP Manifest with With that in mind, a MISP Feed as well as a MISP Manifest with
attached local file list could be fully converted and hosted as a attached local file list could be fully converted and hosted as a
ROLIE repository. As a lower overhead alternative, a ROLIE server ROLIE repository. As a lower overhead alternative, a ROLIE server
could simply provide a view into MISP data. could simply provide a view into MISP data.
6. atom:link Extensions 5. atom:link Extensions
This section defines additional link relationships that This section defines additional link relationships that
implementations MUST support. These relationships are not registered implementations MUST support. These relationships are not registered
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.
6.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 either the incident information-types,
then these link relations MUST be support then these link relations MUST be support
+---------------------------+--------------------+------------------+
| Name | Description | Conformance | +------------+------------------------------------------------------+
+---------------------------+--------------------+------------------+ | Name | Description |
| indicators | Provides a link to | evidence | +------------+------------------------------------------------------+
| | a collection of | | | indicators | Provides a link to a collection of zero or more |
| | zero or more | | | | instances of cyber security indicators that are |
| | instances of cyber | | | | associated with the resource. |
| | security | | | evidence | Provides a link to a collection of zero or more |
| | indicators that | | | | resources that provides some proof of attribution |
| | are associated | | | | for an incident. The evidence may or may not have |
| | with the resource. | | | | any identified chain of custody. |
| Provides a link to a | attacker | Provides a link | | attacker | Provides a link to a collection of zero or more |
| collection of zero or | | to a collection | | | resources that provides a representation of the |
| more resources that | | of zero or more | | | attacker. |
| provides some proof of | | resources that | | vector | Provides a link to a collection of zero or more |
| attribution for an | | provides a | | | resources that provides a representation of the |
| incident. The evidence | | representation | | | method used by the attacker. |
| may or may not have any | | of the attacker. | +------------+------------------------------------------------------+
| identified chain of | | |
| custody. | | |
| vector | Provides a link to |
| | a collection of |
| | zero or more |
| | resources that |
| | provides a |
| | representation of |
| | the 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
6.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-types, then
these link relations MUST be supported. these link relations MUST be supported.
+-----------+-----------------------------------------+-------------+ +-----------+-------------------------------------------------------+
| Name | Description | Conformance | | Name | Description |
+-----------+-----------------------------------------+-------------+ +-----------+-------------------------------------------------------+
| incidents | Provides a link to a collection of zero | | incidents | Provides a link to a collection of zero or more |
| | or more instances of incident | | | instances of incident representations associated with |
| | representations associated with the | | | the resource. |
| | resource. | +-----------+-------------------------------------------------------+
+-----------+-----------------------------------------+-------------+
Table 2: Link Relations for Resource-Oriented Lightweight Indicator Table 2: Link Relations for Resource-Oriented Lightweight Indicator
Exchange Exchange
6.3. Link relations for both information-types 5.3. Link relations for both information-types
If a ROLIE server supports either the incident or the indicator If a ROLIE server supports either the incident or the indicator
information-types, then these link relations MUST be supported. information-types, then these link relations MUST be supported.
+-----------------------+------------------------+------------------+ +-----------------------+-------------------------------------------+
| Name | Description | Conformance | | Name | Description |
+-----------------------+------------------------+------------------+ +-----------------------+-------------------------------------------+
| assessments | Provides a link to a | reports | | assessments | Provides a link to a collection of zero |
| | collection of zero or | | | | or more resources that represent the |
| | more resources that | | | | results of executing a benchmark. |
| | represent the results | | | reports | Provides a link to a collection of zero |
| | of executing a | | | | or more resources that represent RID |
| | benchmark. | | | | reports. |
| Provides a link to a | traceRequests | Provides a link | | traceRequests | Provides a link to a collection of zero |
| collection of zero or | | to a collection | | | or more resources that represent RID |
| more resources that | | of zero or more | | | traceRequests. |
| represent RID | | resources that | | investigationRequests | Provides a link to a collection of zero |
| reports. | | represent RID | | | or more resources that represent RID |
| | | traceRequests. | | | investigationRequests. |
| investigationRequests | Provides a link to a | +-----------------------+-------------------------------------------+
| | collection of zero or |
| | more resources that |
| | represent RID |
| | investigationRequests. |
+-----------------------+------------------------+------------------+
Table 3: Link Relations for Resource-Oriented Lightweight Indicator Table 3: Link Relations for Resource-Oriented Lightweight Indicator
Exchange Exchange
7. atom:category Extensions 6. atom:category Extensions
7.1. Newly registered category values
6.1. Newly registered category values
This document registers two additional registered atom:category This document registers two additional registered atom:category
names: 'urn:ietf:params:rolie:category:csirt:iodef:purpose' and names: 'urn:ietf:params:rolie:category:csirt:iodef:purpose' and
'urn:ietf:params:rolie:category:csirt:iodef:restriction'. These 'urn:ietf:params:rolie:category:csirt:iodef:restriction'. These
categories IODEF content exposure provides valuable metadata for the categories IODEF content exposure provides valuable metadata for the
searching and organization of IODEF documents. searching and organization of IODEF documents.
When the name attribute of the category is When the name attribute of the category is
'urn:ietf:params:rolie:category:csirt:iodef:purpose', the value 'urn:ietf:params:rolie:category:csirt:iodef:purpose', the value
attribute SHOULD be constrained as per section 3.2 of IODEF attribute SHOULD be constrained as per section 3.2 of IODEF
[RFC7970], e.g. traceback, mitigation, reporting, or other. [RFC7970], e.g. traceback, mitigation, reporting, or other.
When the name attribute of the category is When the name attribute of the category is
'urn:ietf:params:rolie:category:csirt:iodef:restriction', the value 'urn:ietf:params:rolie:category:csirt:iodef:restriction', the value
attribute SHOULD be constrained as per section 3.2 of IODEF attribute SHOULD be constrained as per section 3.2 of IODEF
[RFC7970], e.g. public, need-to-know, private, default. [RFC7970], e.g. public, need-to-know, private, default.
7.2. Expectation and Impact Classes 6.2. Expectation and Impact Classes
It is frequently the case that an organization will need to triage It is frequently the case that an organization will need to triage
their investigation and response activities based upon, e.g., the their investigation and response activities based upon, e.g., the
state of the current threat environment, or simply as a result of state of the current threat environment, or simply as a result of
having limited resources. having limited resources.
In order to enable operators to effectively prioritize their response In order to enable operators to effectively prioritize their response
activity, it is RECOMMENDED that feed implementers provide Atom activity, it is RECOMMENDED that feed implementers provide Atom
categories that correspond to the IODEF Expectation and Impact categories that correspond to the IODEF Expectation and Impact
classes. The availability of these feed categories will enable classes. The availability of these feed categories will enable
clients to more easily retrieve and prioritize cyber security clients to more easily retrieve and prioritize cyber security
information that has already been identified as having a specific information that has already been identified as having a specific
potential impact, or having a specific expectation. potential impact, or having a specific expectation.
Support for these categories may also enable efficiencies for Support for these categories may also enable efficiencies for
organizations that already have established (or plan to establish) organizations that already have established (or plan to establish)
operational processes and workflows that are based on these IODEF operational processes and workflows that are based on these IODEF
classes. classes.
8. IANA Considerations 7. IANA Considerations
8.1. information-type registrations 7.1. information-type registrations
IANA has added the following entries to the "ROLIE Security Resource IANA has added the following entries to the "ROLIE Security Resource
Information Type Sub-Registry" registry located at Information Type Sub-Registry" registry located at
<https://www.iana.org/assignments/rolie/category/information-type> . <https://www.iana.org/assignments/rolie/category/information-type> .
8.1.1. incident information-type 7.1.1. incident information-type
The entry is as follows: The entry is as follows:
name: incident name: incident
index: TBD index: TBD
reference: This document, Section 4.1 reference: This document, Section 3.1
8.1.2. indicator information-type 7.1.2. indicator information-type
The entry is as follows: The entry is as follows:
name: indicator name: indicator
index: TBD index: TBD
reference: This document, Section 4.2 reference: This document, Section 3.2
8.2. atom:category scheme registrations 7.2. atom:category scheme registrations
IANA has added the following entries to the "ROLIE URN Parameters" IANA has added the following entries to the "ROLIE URN Parameters"
registry located in <https://www.iana.org/assignments/rolie/>. registry located in <https://www.iana.org/assignments/rolie/>.
8.2.1. category:csirt:iodef:purpose 7.2.1. category:csirt:iodef:purpose
The entry is as follows: The entry is as follows:
name: category:csirt:iodef:purpose name: category:csirt:iodef:purpose
Extension IRI: urn:ietf:params:rolie:category:csirt:iodef:purpose Extension IRI: urn:ietf:params:rolie:category:csirt:iodef:purpose
Reference: This document, Section 7.1 Reference: This document, Section 6.1
Subregistry: None Subregistry: None
8.2.2. category:csirt:iodef:restriction 7.2.2. category:csirt:iodef:restriction
The entry is as follows: The entry is as follows:
name: category:csirt:iodef:restriction name: category:csirt:iodef:restriction
Extension IRI: Extension IRI:
urn:ietf:params:rolie:category:csirt:iodef:restriction urn:ietf:params:rolie:category:csirt:iodef:restriction
Reference: This document, Section 7.1 Reference: This document, Section 6.1
Subregistry: None
8.3. rolie:property name registrations
IANA has added the following entries to the "ROLIE URN Parameters"
registry located in <https://www.iana.org/assignments/rolie/>.
8.3.1. property:csirt:id
The entry is as follows:
name: property:csirt:id
Extension IRI: urn:ietf:params:rolie:property:csirt:id
Reference: This document, section 6.3.1
Subregistry: None Subregistry: None
9. 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.
10. Normative References 9. Normative References
[I-D.dulaunoy-misp-core-format] [I-D.dulaunoy-misp-core-format]
Dulaunoy, A. and A. Iklody, "MISP core format", draft- Dulaunoy, A. and A. Iklody, "MISP core format", draft-
dulaunoy-misp-core-format-07 (work in progress), February dulaunoy-misp-core-format-07 (work in progress), February
2019. 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>.
 End of changes. 53 change blocks. 
184 lines changed or deleted 133 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/