draft-ietf-mile-rolie-csirt-01.txt   draft-ietf-mile-rolie-csirt-02.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: September 27, 2019 Pivotal
March 26, 2019 March 26, 2019
Definition of ROLIE CSIRT Extension Definition of ROLIE CSIRT Extension
draft-ietf-mile-rolie-csirt-01 draft-ietf-mile-rolie-csirt-02
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 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Additional Requirements for the Atom Publishing Protocol . . 4 3. Additional Requirements for the Atom Publishing Protocol . . 4
3.1. Use of HTTP requests . . . . . . . . . . . . . . . . . . 4 3.1. Use of HTTP requests . . . . . . . . . . . . . . . . . . 4
3.1.1. / (forward slash) Resource URL . . . . . . . . . . . 4 3.1.1. / (forward slash) Resource URL . . . . . . . . . . . 4
4. Additional Requirements for the Atom Syndication Format . . . 4 4. Information-type Extensions . . . . . . . . . . . . . . . . . 4
5. Information-type Extensions . . . . . . . . . . . . . . . . . 4 4.1. The "incident" information type . . . . . . . . . . . . . 4
5.1. The "incident" information type . . . . . . . . . . . . . 4 4.2. The "indicator" information type . . . . . . . . . . . . 5
5.2. The "indicator" information type . . . . . . . . . . . . 5 5. Data format requirements . . . . . . . . . . . . . . . . . . 5
5.3. Use of the rolie:format element . . . . . . . . . . . . . 5 5.1. Incident Object Description Exchange Format . . . . . . . 6
5.3.1. IODEF Format . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6
5.3.2. STIX Format . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 6
6. rolie:property Extensions . . . . . . . . . . . . . . . . . . 6 5.2. Structured Threat Information eXpression (STIX) Format . 7
6.1. urn:ietf:params:rolie:property:csirt:ID . . . . . . . . . 6 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7
7. Use of the atom:link element . . . . . . . . . . . . . . . . 6 5.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 7
7.1. Link relations for the 'incident' 5.3. Malware Information Sharing Platform (MISP) Format . . . 7
information-type . . . . . . . . . . . . . . . . . . . . 7 5.3.1. Creating MISP Event Entries . . . . . . . . . . . . . 8
7.2. Link relations for the 'indicator' 5.3.2. MISP Feeds and Manifests . . . . . . . . . . . . . . 8
information-type . . . . . . . . . . . . . . . . . . . . 7 6. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9
7.3. Link relations for both information-types . . . . . . . . 8 6.1. Link relations for the 'incident'
8. Other Extensions . . . . . . . . . . . . . . . . . . . . . . 8 information-type . . . . . . . . . . . . . . . . . . . . 9
8.1. Use of atom:category . . . . . . . . . . . . . . . . . . 8 6.2. Link relations for the 'indicator'
8.1.1. Newly registered category values . . . . . . . . . . 8 information-type . . . . . . . . . . . . . . . . . . . . 10
8.1.2. Expectation and Impact Classes . . . . . . . . . . . 9 6.3. Link relations for both information-types . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. atom:category Extensions . . . . . . . . . . . . . . . . . . 11
9.1. information-type registrations . . . . . . . . . . . . . 9 7.1. Newly registered category values . . . . . . . . . . . . 12
9.1.1. incident information-type . . . . . . . . . . . . . . 9 7.2. Expectation and Impact Classes . . . . . . . . . . . . . 12
9.1.2. indicator information-type . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.2. atom:category scheme registrations . . . . . . . . . . . 10 8.1. information-type registrations . . . . . . . . . . . . . 12
9.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 10 8.1.1. incident information-type . . . . . . . . . . . . . . 13
9.2.2. category:csirt:iodef:restriction . . . . . . . . . . 10 8.1.2. indicator information-type . . . . . . . . . . . . . 13
9.3. rolie:property name registrations . . . . . . . . . . . . 10 8.2. atom:category scheme registrations . . . . . . . . . . . 13
9.3.1. property:csirt:id . . . . . . . . . . . . . . . . . . 10 8.2.1. category:csirt:iodef:purpose . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8.2.2. category:csirt:iodef:restriction . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . 11 8.3. rolie:property name registrations . . . . . . . . . . . . 14
Appendix A. Non-Normative Examples . . . . . . . . . . . . . . . 12 8.3.1. property:csirt:id . . . . . . . . . . . . . . . . . . 14
A.1. Use of Link Relations . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
A.1.1. Use Case: Incident Sharing . . . . . . . . . . . . . 13 10. Normative References . . . . . . . . . . . . . . . . . . . . 14
A.1.2. Use Case: Collaborative Investigation . . . . . . . . 15 Appendix A. Examples of Use . . . . . . . . . . . . . . . . . . 15
A.1.3. Use Case: Cyber Data Repository . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
This document defines the following requirements on HTTP request This document defines the following requirements on HTTP request
behavior: behavior:
3.1.1. / (forward slash) Resource URL 3.1.1. / (forward slash) Resource URL
The forward slash resource URL SHOULD be supported as defined in The forward slash resource URL SHOULD be supported as defined in
Section 5.5 [RFC8322]. Note that this is a stricter requirement than Section 5.5 [RFC8322]. Note that this is a stricter requirement than
[RFC8322]. [RFC8322].
4. Additional Requirements for the Atom Syndication Format 4. Information-type Extensions
This document does not specify any additional requirements for the
Atom Syndication Format. [RFC4287]
5. Information-type Extensions 4.1. The "incident" information type
5.1. The "incident" information type When an "atom:category" element has a "scheme" attribute equal to
"urn:ietf:params:rolie:category:information-type", the "term"
attribute defines the information type of the associated resource. A
new valid "term" value for this "scheme": "incident", is described in
this section, and registered in Section 8.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 5, line 18
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.
5.2. The "indicator" information type 4.2. The "indicator" information type
When an "atom:category" element has a "scheme" attribute equal to
"urn:ietf:params:rolie:category:information-type", the "term"
attribute defines the information type of the associated resource. A
new valid "term" value for this "scheme": "indicator", is described
in this section, and registered in Section 8.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 41 skipping to change at page 5, line 47
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.3. Use of the rolie:format element 5. Data format requirements
This document does not contain any additional requirements for the This section defines usage guidance and additional requirements
rolie:format element; the formats that follow are provided as related to data formats above and beyond those specified in
examples of formats that describe the incident and indicator [RFC8322]. The following formats are expected to be commonly used to
information type. The formats are in no particular order, and are express software descriptor information. For this reason, this
not requirements, nor suggestions by the authors. document specifies additional requirements to ensure
interoperability.
5.3.1. IODEF Format 5.1. Incident Object Description Exchange Format
5.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 provides further high-level discussion The full IODEF specification [RFC7970] provides further high-level
and technical details. discussion and technical details.
5.3.2. STIX Format 5.1.2. Requirements
For an Entry to be considered as a "IODEF Entry", it MUST fulfill the
following conditions:
o The information-type of the Entry is "indicator" or "incident".
For a typical Entry, this is derived from the information type of
the Feed it is contained in. For a standalone Entry, this is
provided by an "atom:category" element.
o
o The document linked to by the "href" attribute of the
"atom:content" element is an IODEF document as per [RFC7970]
A "IODEF Entry" MUST conform to the following requirements:
o The value of the "type" attribute of the "atom:content" element
MUST be "application/xml".
o There MUST be at least one "rolie:property" with the "name"
attribute equal to "urn:ietf:params:rolie:property:content-id" and
the "value" attribute exactly equal to the "<Indicator-ID>" or the
"<Incident-ID>" element in the attached IODEF document. This
allows for ROLIE consumers to more easily search for IODEF
doucments without needing to download the doucment itself.
5.2. Structured Threat Information eXpression (STIX) Format
5.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 use of STIX as the content of an Entry does not impose any The full STIX specification [stix2] provides further high-level
additional requirements on ROLIE implementations. discussion and technical details.
6. rolie:property Extensions 5.2.2. Requirements
This document provides new registrations for valid rolie:property For an Entry to be considered as a "STIX Entry", it MUST fulfill the
names. These properties provide optional exposure point for valuable following conditions:
information in the linked content document. Exposing this
information in a rolie:property element means that clients do not
need to download the linked document to determine if it contains the
information they are looking for.
6.1. urn:ietf:params:rolie:property:csirt:ID o The information-type of the Entry is "indicator" or "incident".
For a typical Entry, this is derived from the information type of
the Feed it is contained in. For a standalone Entry, this is
provided by an "atom:category" element.
Provides an XML element that can be populated with an identifier from o
the indicator or incident document linked to by an atom:content
element. This value SHOULD be a uniquely identifying value for the
document linked to in this entry's atom:content element.
7. Use of the atom:link element o The document linked to by the "href" attribute of the
"atom:content" element is a STIX object as per [stix2]
These sections define requirements for atom:link elements in Entries. A "STIX Entry" MUST conform to the following requirements:
Note that the requirements are determined by the information type
that appears in either the Entry or in the parent Feed.
7.1. Link relations for the 'incident' information-type o The value of the "type" attribute of the "atom:content" element
MUST be "application/xml" or "application/json".
If the category of an Entry is the incident information type, then o There MUST be at least one "rolie:property" with the "name"
the following requirements MUST be followed for inclusion of attribute equal to "urn:ietf:params:rolie:property:content-id" and
atom:link elements. the "value" attribute exactly equal to the "<id>" element in the
attached STIX object . This allows for ROLIE consumers to more
easily search for STIX objects without needing to download the
document itself.
+------------+----------------------------------------+-------------+ 5.3. Malware Information Sharing Platform (MISP) Format
| Name | Description | Conformance |
+------------+----------------------------------------+-------------+ MISP involves documentation, utilities, and formats designed to
| indicators | Provides a link to a collection of | SHOULD | faciliate the day-to=day duties of security operators. MISP includes
| | zero or more instances of cyber | | it's own data format that is used to share between MISP features.
| | security indicators that are | | While MISP has Feed features that can share and distribute events, it
| | associated with the resource. | | has support for linking to other sharing methods like ROLIE.
| evidence | Provides a link to a collection of | SHOULD |
| | zero or more resources that provides | | MISP is defined by a family of internet drafts and are actively being
| | some proof of attribution for an | | worked on. With that in mind, this extension will provice non-
| | incident. The evidence may or may not | | normative guidance on using MISP format data in ROLIE. In the
| | have any identified chain of custody. | | future, when the MISP format is formally published, this document
| attacker | Provides a link to a collection of | SHOULD | will be updated to normative requirements around MISP content.
| | zero or more resources that provides a | |
| | representation of the attacker. | | 5.3.1. Creating MISP Event Entries
| vector | Provides a link to a collection of | SHOULD |
| | zero or more resources that provides a | | MISP content should be syndicated in ROLIE using the following
| | representation of the method used by | | guidance:
| | the attacker. | |
+------------+----------------------------------------+-------------+ 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
contained in. For a standalone Entry, this is provided by an
"atom:category" element.
o The document linked to by the "href" attribute of the
"atom:content" element is a MISP Event object as per
[I-D.dulaunoy-misp-core-format]
o The value of the "type" attribute of the "atom:content" element
should be "application/xml".
o There should be at least one "rolie:property" with the "name"
attribute equal to "urn:ietf:params:rolie:property:content-id" and
the "value" attribute exactly equal to the "<uuid>" element in the
attached MISP Event . This allows for ROLIE consumers to more
easily search for MISP Events without needing to download the
document itself.
o It is also recommended to expose information in the ROLIE Entry
that is required and recommended to expose in the MISP Manifest
format. THis ensures better compatability between a ROLIE Feed
and a MISP Manifest
* The following fields are required by the MISP draft: info,
Orgc, timestamp, date
* The following fields are recommended by the MISP draft:
analysis, threat_level_id
5.3.2. MISP Feeds and Manifests
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
the full Event on each request.
MISP Manifest files list MISP events by their uuids as well, but
provide a variety of metadata for each Event inline. After examining
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
files where the file name is the uuid of the Event.
ROLIE hosting MISP data would operate as a combination of these
approaches. Each ROLIE Feed would contain a list of Event Entries,
each with metadata and identifying information about a given Event.
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
Feed is minimumally mappable to a MISP Manifest file where a
resolvable link to the MISP Event was injected into each Event
described in the Manifest.
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
ROLIE repository. As a lower overhead alternative, a ROLIE server
could simply provide a view into MISP data.
6. atom:link Extensions
This section defines additional link relationships that
implementations MUST support. These relationships are not registered
in the Link Relation IANA table as their use case is too narrow.
Each relationship is named and described.
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
that the Entry is created. The second of each pair will often need
to be added retroactively to an Entry.
6.1. Link relations for the 'incident' information-type
If a ROLIE server supports either the incident information-types,
then these link relations MUST be support
+---------------------------+--------------------+------------------+
| Name | Description | Conformance |
+---------------------------+--------------------+------------------+
| indicators | Provides a link to | evidence |
| | a collection of | |
| | zero or more | |
| | instances of cyber | |
| | security | |
| | indicators that | |
| | are associated | |
| | with the resource. | |
| Provides a link to a | attacker | Provides a link |
| collection of zero or | | to a collection |
| more resources that | | of zero or more |
| provides some proof of | | resources that |
| attribution for an | | provides a |
| incident. The evidence | | representation |
| 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
7.2. Link relations for the 'indicator' information-type 6.2. Link relations for the 'indicator' information-type
If the category of an Entry is the indicator information type, then If a ROLIE server supports the indicator information-types, then
the following requirements MUST be followed for inclusion of these link relations MUST be supported.
atom:link elements.
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
| Name | Description | Conformance | | Name | Description | Conformance |
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
| incidents | Provides a link to a collection of zero | SHOULD | | incidents | Provides a link to a collection of zero |
| | or more instances of incident | | | | or more instances of incident |
| | representations associated with the | | | | representations associated with the |
| | resource. | | | | resource. |
+-----------+-----------------------------------------+-------------+ +-----------+-----------------------------------------+-------------+
Table 2: Link Relations for Resource-Oriented Lightweight Indicator Table 2: Link Relations for Resource-Oriented Lightweight Indicator
Exchange Exchange
7.3. Link relations for both information-types 6.3. Link relations for both information-types
If the category of an Entry is either information-type, the following If a ROLIE server supports either the incident or the indicator
requirements MUST be followed for inclusion of atom:link elements. information-types, then these link relations MUST be supported.
+-----------------------+-----------------------------+-------------+ +-----------------------+------------------------+------------------+
| Name | Description | Conformance | | Name | Description | Conformance |
+-----------------------+-----------------------------+-------------+ +-----------------------+------------------------+------------------+
| assessments | Provides a link to a | MAY | | assessments | Provides a link to a | reports |
| | collection of zero or more | | | | collection of zero or | |
| | resources that represent | | | | more resources that | |
| | the results of executing a | | | | represent the results | |
| | benchmark. | | | | of executing a | |
| reports | Provides a link to a | MAY | | | benchmark. | |
| | collection of zero or more | | | Provides a link to a | traceRequests | Provides a link |
| | resources that represent | | | collection of zero or | | to a collection |
| | RID reports. | | | more resources that | | of zero or more |
| traceRequests | Provides a link to a | MAY | | represent RID | | resources that |
| | collection of zero or more | | | reports. | | represent RID |
| | resources that represent | | | | | traceRequests. |
| | RID traceRequests. | | | investigationRequests | Provides a link to a |
| investigationRequests | Provides a link to a | MAY | | | collection of zero or |
| | collection of zero or more | | | | more resources that |
| | resources that represent | | | | represent RID |
| | RID investigationRequests. | | | | investigationRequests. |
+-----------------------+-----------------------------+-------------+ +-----------------------+------------------------+------------------+
Table 3: Link Relations for Resource-Oriented Lightweight Indicator Table 3: Link Relations for Resource-Oriented Lightweight Indicator
Exchange Exchange
8. Other Extensions 7. atom:category Extensions
7.1. Newly registered category values
This document defines additional extensions as follows:
8.1. Use of atom:category
8.1.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.
8.1.2. Expectation and Impact Classes 7.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.
9. IANA Considerations 8. IANA Considerations
9.1. information-type registrations 8.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> .
9.1.1. incident information-type 8.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 5.1 reference: This document, Section 4.1
9.1.2. indicator information-type 8.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 5.2 reference: This document, Section 4.2
9.2. atom:category scheme registrations 8.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/>.
9.2.1. category:csirt:iodef:purpose 8.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 8.1.1 Reference: This document, Section 7.1
Subregistry: None Subregistry: None
9.2.2. category:csirt:iodef:restriction 8.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 8.1.1 Reference: This document, Section 7.1
Subregistry: None Subregistry: None
9.3. rolie:property name registrations 8.3. rolie:property name 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/>.
9.3.1. property:csirt:id 8.3.1. property:csirt:id
The entry is as follows: The entry is as follows:
name: property:csirt:id name: property:csirt:id
Extension IRI: urn:ietf:params:rolie:property:csirt:id Extension IRI: urn:ietf:params:rolie:property:csirt:id
Reference: This document, section 6.3.1 Reference: This document, section 6.3.1
Subregistry: None Subregistry: None
10. Security Considerations 9. 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.
11. Normative References 10. Normative 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.
[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 12, line 10 skipping to change at page 15, line 31
[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>.
[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>.
Appendix A. Non-Normative Examples [stix2] "Structured Threat Information Expression 2.0", July 2017.
The following provide examples of some potential use cases of the
CSIRT ROLIE extension, and provides a showcase for some of its
benefits over traditional solutions.
The general non-normative examples provided in the core ROLIE
document remain an excellent reference resource for typical ROLIE
usage.
A.1. Use of Link Relations
A key benefit of using the RESTful architectural style is the ability
to enable the client to navigate to related resources through the use
of hypermedia links. In the Atom Syndication Format, the type of the
related resource identified in a <link> element is indicated via the
"rel" attribute, where the value of this attribute identifies the
kind of related resource available at the corresponding "href"
attribute. Thus, in lieu of a well-known URI template the URI itself
is effectively opaque to the client, and therefore the client must
understand the semantic meaning of the "rel" attribute in order to
successfully navigate. Broad interoperability may be based upon a
sharing consortium defining a well-known set of Atom Link Relation
types. These Link Relation types may either be registered with IANA,
or held in a private registry.
Individual CSIRTs may always define their own link relation types in
order to support specific use cases, however support for a core set
of well-known link relation types is encouraged as this will maximize
interoperability.
In addition, it may be beneficial to define use case profiles that
correspond to specific groupings of supported link relationship
types. In this way, a CSIRT may unambiguously specify the classes of
use cases for which a client can expect to find support.
The following sections provide non-normative examples of link
relation usage. Three distinct cyber security information sharing
use case scenarios are described. In each use case, the unique
benefits of adopting a resource-oriented approach to information
sharing are illustrated. It is important to note that these use
cases are intended to be a small representative set and is by no
means meant to be an exhaustive list. The intent is to illustrate
how the use of link relationship types will enable this resource-
oriented approach to cyber security information sharing to
successfully support the complete range of existing use cases, and
also to motivate an initial list of well-defined link relationship
types.
A.1.1. Use Case: Incident Sharing
This section provides a non-normative example of an incident sharing
use case.
In this use case, a member CSIRT shares incident information with
another member CSIRT in the same consortium. The client CSIRT
retrieves a feed of incidents, and is able to identify one particular
entry of interest. The client then does an HTTP GET on that entry,
and the representation of that resource contains link relationships
for both the associated "indicators" and the incident "history", and
so on. The client CSIRT recognizes that some of the indicator and
history may be relevant within her local environment, and can respond
proactively.
Example HTTP GET response for an incident entry:
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0">
<id>http://www.example.org/csirt/private/incidents/123456</id>
<title>Sample Incident</title>
<link href="http://www.example.org/csirt/private/incidents/123456"
rel="self"/>
<link href="http://www.example.org/csirt/private/incidents/123456"
rel="alternate"/>
<published>2012-08-04T18:13:51.0Z</published>
<updated>2012-08-05T18:13:51.0Z</updated>
<link href="http://www.example.org/csirt/private/incidents/123456"
rel="edit"/>
<!-- The links to indicators related to this incident,
and the history of this incident, and so on.... -->
<link href="http://www.example.org/csirt/private/incidents/123456
/relationships/indicators" rel="indicators"/>
<link href="http://www.example.org/csirt/private/incidents/123456
/relationships/history" rel="history"/>
<link href="http://www.example.org/csirt/private/incidents/123456
/relationships/campaign" rel="campaign"/>
<!-- navigate up to the full collection.
Might also be rel="collection" as per IANA registry -->
<link href="http://www.example.org/csirt/private/incidents" rel="up"/>
<rolie:format ns="urn:example:iodef"/>
<content type="application/xml" src="example.org/123456/source">
<!-- Content provided here as example, the content tag is only a
link to this file. -->
<iodef:IODEF-Document lang="en"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident purpose="traceback" restriction="need-to-know">
<iodef:IncidentID name="http://www.example.org/csirt/private/
incidents">123456</iodef:IncidentID>
<!-- ...additional incident data.... -->
</iodef:Incident>
</iodef:IODEF-Document>
</content>
</entry>
As can be seen in the example response, the Atom <link> elements
enable the client to navigate to the related indicator resources,
and/or the history entries associated with this incident.
A.1.2. Use Case: Collaborative Investigation
This section provides a non-normative example of a collaborative
investigation use case.
In this use case, two member CSIRTs that belong to a closed sharing
consortium are collaborating on an incident investigation. The
initiating CSIRT performs an HTTP GET to retrieve the service
document of the peer CSIRT, and determines the collection name to be
used for creating a new investigation request. The initiating CSIRT
then POSTs a new incident entry to the appropriate collection URL.
The target CSIRT acknowledges the request by responding with an HTTP
status code 201 Created.
Example HTTP GET response for the service document:
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:09:11 GMT
Content-Length: 934
Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace xml:lang="en-US"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<atom:title type="text">RID Use Case Requests</atom:title>
<collection
href="http://www.example.org/csirt/RID/InvestigationRequests">
<atom:title type="text">Investigation Requests</atom:title>
<accept>application/atom+xml; type=entry</accept>
</collection>
<collection href="http://www.example.org/csirt/RID/TraceRequests">
<atom:title type="text">Trace Requests</atom:title>
<accept>application/atom+xml; type=entry</accept>
</collection>
<!-- ...and so on.... -->
</workspace>
</service>
As can be seen in the example response, the Atom <collection>
elements enable the client to determine the appropriate collection
URL to request an investigation or a trace.
The client CSIRT then POSTs a new entry to the appropriate feed
collection. Note that the <content> element of the new entry may
contain a RID message of type "InvestigationRequest" if desired,
however this would NOT be required. The entry content itself need
only be an IODEF document, with the choice of the target collection
resource URL indicating the callers intent. A CSIRT would be free to
use any URI template to accept investigationRequests.
POST /csirt/RID/InvestigationRequests HTTP/1.1 Appendix A. Examples of Use
Host: www.example.org
Content-Type: application/atom+xml;type=entry
Content-Length: 852
<?xml version="1.0" encoding="UTF-8"?> Use of this extension in a ROLIE repository will not typically change
<entry xmlns="http://www.w3.org/2005/Atom" that repository's operation. As such, the general examples provided
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"> by the ROLIE core document would serve as examples. Provided below
<title>New Investigation Request</title> is a sample incident ROLIE entry containing an IODEF document:
<id>http://www.example2.org/csirt/private/incidents/123456</id>
<!-- id and updated not guranteed to be preserved -->
<!-- may want to profile that behavior in this document -->
<updated>2012-08-12T11:08:22Z</updated>
<author><name>Name of peer CSIRT</name></author>
<rolie:format ns="urn:example:iodef"/>
<content type="application/xml">
<iodef:IODEF-Document lang="en"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef:Incident purpose="traceback" restriction="need-to-know">
<iodef:IncidentID name="http://www.example2.org/csirt/
private/incidents">123</iodef:IncidentID>
<!-- ...additional incident data.... -->
</iodef:Incident>
</iodef:IODEF-Document>
</content>
</entry>
The receiving CSIRT acknowledges the request with HTTP return code <?xml version="1.0" encoding="UTF-8"?>
201 Created. <entry xmlns="http://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0">
<id>f762c77c-057d-45c9-b805-677ab89aaf7c</id>
<title>Sample Incident</title>
<published>2018-09-04T18:13:51.0Z</published>
<updated>2019-08-05T18:13:51.0Z</updated>
<summary>A document containing an indicator of comprimise. </summary>
<link rel="self" href="http://www.example.org/rolie/CSIRT/123456"/>
<link rel="feed" href="http://www.example.org/rolie/CSIRT/"/>
<rolie:property name=urn:ietf:params:rolie:property:content-id
value="id847201"/>
<category
scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/>
<rolie:format
ns="urn:ietf:params:xml:ns:iodef-2.0"/>
<content type="application/xml"
src="http://www.example.org/rolie/csirt/123456/data"/>
</entry>
HTTP/1.1 201 Created Below is a sample indicator ROLIE entry containing a STIX document:
Date: Fri, 24 Aug 2012 19:17:11 GMT
Content-Length: 906
Content-Type: application/atom+xml;type=entry
Location: http://www.example.org/csirt/RID/InvestigationRequests/823
ETag: "8a9h9he4qphqh"
<?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">
<title>New Investigation Request</title> <id>0c99df51-767f-4940-8a09-c4b607b6fe21</id>
<id>http://www.example.org/csirt/RID/InvestigationRequests/823</id> <title>Sample Indicator</title>
<!-- id and updated not guranteed to be preserved --> <published>2018-09-04T18:13:51.0Z</published>
<!-- may want to profile that behavior in this document --> <updated>2019-08-05T18:13:51.0Z</updated>
<updated>2012-08-12T11:08:30Z</updated> <summary>A document containing an incident report. </summary>
<published>2012-08-12T11:08:30Z</published> <link rel="self" href="http://www.example.org/rolie/CSIRT/654321"/>
<author><name>Name of peer CSIRT</name></author> <link rel="feed" href="http://www.example.org/rolie/CSIRT/"/>
<rolie:format ns="urn:example:iodef"/> <rolie:property name=urn:ietf:params:rolie:property:content-id
<content type="application/xml"> value="exmaple:indicator:654321"/>
<iodef:IODEF-Document lang="en" <category
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"> scheme="urn:ietf:params:rolie:category:information-type"
<iodef:Incident purpose="traceback" restriction="need-to-know"> term="indicator"/>
<iodef:IncidentID name="http://www.example.org/csirt/private <rolie:format
/incidents">123</iodef:IncidentID> ns=http://stix.mitre.org/XMLSchema/core/1.2/stix_core.xsd"/>
<!-- ...additional incident data.... --> <content type="application/xml"
</iodef:Incident> src="http://www.example.org/rolie/csirt/654321/data"/>
</iodef:IODEF-Document>
</content>
</entry> </entry>
Consistent with HTTP/1.1 RFC, the location header indicates the URL
of the newly created InvestigationRequest. If for some reason the
request were not authorized, the client would receive an HTTP status
code 403 Unauthorized. In this case the HTTP response body may
contain additional details, if an as appropriate.
A.1.3. Use Case: Cyber Data Repository
This section provides a non-normative example of a cyber security
data repository use case.
In this use case a client accesses a persistent repository of cyber
security data via a RESTful usage model. Retrieving a feed
collection is analogous to an SQL SELECT statement producing a result
set. Retrieving an individual Atom Entry is analogous to a SQL
SELECT statement based upon a primary key producing a unique record.
The cyber security data contained in the repository may include
different data types, including indicators, incidents, benchmarks, or
any other related resources. In this use case, the repository is
queried via HTTP GET, and the results that are returned to the client
may optionally contain URL references to other cyber security
resources that are known to be related. These related resources may
also be persisted locally, or they may exist at another (remote)
cyber data respository.
Example HTTP GET request to a persistent repository for any resources
representing Distributed Denial of Service (DDOS) attacks:
GET /csirt/repository/ddos
Host: www.example.org
Accept: application/atom+xml
The corresponding HTTP response would be an XML document containing
the DDOS feed.
Example HTTP GET response for a DDOS feed:
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:20:11 GMT
Content-Length: nnnn
Content-Type: application/atom+xml;type=feed;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2005/Atom
file:/C:/schemas/atom.xsd
urn:ietf:params:xml:ns:iodef-1.0
file:/C:/schemas/iodef-1.0.xsd"
xml:lang="en-US">
<generator version="1.0" xml:lang="en-US">
emc-csirt-iodef-feed-service</generator>
<id>http://www.example.org/csirt/repository/ddos</id>
<title type="text" xml:lang="en-US">
Atom formatted representation of a feed of known ddos resources.
</title>
<updated xml:lang="en-US">2012-05-04T18:13:51.0Z</updated>
<author>
<email>csirt@example.org</email>
<name>EMC CSIRT</name>
</author>
<!-- By convention there is usually a self link for the feed -->
<link href="http://www.example.org/csirt/repository/ddos"
rel="self"/>
<entry>
<id>http://www.example.org/csirt/repository/ddos/123456</id>
<title>Sample DDOS Incident</title>
<link href="http://www.example.org/csirt/repository/ddos/123456"
rel="self"/> <!-- by convention -->
<link href="http://www.example.org/csirt/repository/ddos/123456"
rel="alternate"/> <!-- required by Atom spec -->
<link href="http://www.example.org/csirt/repository/ddos/987654"
rel="related"/> <!-- link to a related DDOS resource
in this repository -->
<link href="http://www.cyber-agency.gov/repository/
indicators/1a2b3c" rel="related"/>
<!-- link to a related DDOS resource in another repository -->
<published>2012-08-04T18:13:51.0Z</published>
<updated>2012-08-05T18:13:51.0Z</updated>
<!-- The category is based upon IODEF
purpose and restriction attributes -->
<category term="traceback" scheme="purpose" label="trace back"/>
<category term="need-to-know" scheme="restriction"
label="need to know" />
<category term="ddos" scheme="ttp"
label="tactics, techniques, and procedures"/>
<summary>A short description of this DDOS attack, extracted
from the IODEF Incident class, <description> element. </summary>
<rolie:format ns="urn:example:iodef"/>
<content href="http://www.example.org/ddos/123456/data"/>
</entry>
<entry>
<!-- ...another entry... -->
</entry>
</feed>
This feed document has two atom entries, one of which has been
elided. The completed entry illustrates an Atom <entry> element that
provides a summary of essential details about one particular DDOS
incident. Based upon this summary information and the provided
category information, a client may choose to do an HTTP GET operation
to retrieve the full details of the DDOS incident. This example
shows how a persistent repository may provide links to additional
resources, both local and remote.
Note that the provider of a persistent repostory is not obligated to
follow any particular URL template scheme. The repository available
at the hypothetical provider "www.example.com" uses a different URL
pattern than the hypothetical repository available at "www.cyber-
agency.gov". When a client de-references a link to resource that is
located in a remote repository the client may be challenged for
authentication credentials acceptable to that provider. If the two
repository providers choose to support a federated identity scheme or
some other form of single-sign-on technology, then the user
experience can be improved for interactive clients (e.g., a human
user at a browser). However, this is not required and is an
implementation choice that is out of scope for this specification.
Authors' Addresses Authors' Addresses
Stephen A. Banghart Stephen A. Banghart
National Institute of Standards and Technology National Institute of Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, Maryland Gaithersburg, Maryland
USA USA
Phone: (301)975-4288 Phone: (301)975-4288
Email: sab3@nist.gov Email: sab3@nist.gov
 End of changes. 55 change blocks. 
493 lines changed or deleted 334 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/