MILE Working Group                                           S. Banghart
Internet-Draft                                                      NIST
Intended status: Informational                                  J. Field
Expires: September 27, 2019                                      Pivotal
                                                          March 26, 2019

                  Definition of ROLIE CSIRT Extension
                     draft-ietf-mile-rolie-csirt-01
                     draft-ietf-mile-rolie-csirt-02

Abstract

   This document extends the Resource-Oriented Lightweight Information
   Exchange (ROLIE) core to add the information type categories and
   related requirements needed to support Computer Security Incident
   Response Team (CSIRT) use cases.  The indicator and incident
   information types are defined as ROLIE extensions.  Additional
   supporting requirements are also defined that describe the use of
   specific formats and link relations pertaining to the new information
   types.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 27, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Additional Requirements for the Atom Publishing Protocol  . .   4
     3.1.  Use of HTTP requests  . . . . . . . . . . . . . . . . . .   4
       3.1.1.  / (forward slash) Resource URL  . . . . . . . . . . .   4
   4.  Additional Requirements for the Atom Syndication Format . . .   4
   5.  Information-type Extensions . . . . . . . . . . . . . . . . .   4
     5.1.
     4.1.  The "incident" information type . . . . . . . . . . . . .   4
     5.2.
     4.2.  The "indicator" information type  . . . . . . . . . . . .   5
     5.3.  Use of the rolie:format element
   5.  Data format requirements  . . . . . . . . . . . . . . . . . .   5
       5.3.1.  IODEF
     5.1.  Incident Object Description Exchange Format . . . . . . .   6
       5.1.1.  Description . . . . . . . . . . . . . . . . . . . . .   6
       5.3.2.  STIX
       5.1.2.  Requirements  . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Structured Threat Information eXpression (STIX) Format  .   7
       5.2.1.  Description . . . . . . . . . . . . . . . . . . . .   6
   6.  rolie:property Extensions .   7
       5.2.2.  Requirements  . . . . . . . . . . . . . . . . .   6
     6.1.  urn:ietf:params:rolie:property:csirt:ID . . .   7
     5.3.  Malware Information Sharing Platform (MISP) Format  . . .   7
       5.3.1.  Creating MISP Event Entries . . .   6
   7.  Use of the atom:link element . . . . . . . . . .   8
       5.3.2.  MISP Feeds and Manifests  . . . . . .   6
     7.1.  Link relations for the 'incident'
           information-type . . . . . . . .   8
   6.  atom:link Extensions  . . . . . . . . . . . .   7
     7.2. . . . . . . . .   9
     6.1.  Link relations for the 'indicator' 'incident'
           information-type  . . . . . . . . . . . . . . . . . . . .   7
     7.3.   9
     6.2.  Link relations for both information-types . . the 'indicator'
           information-type  . . . . . .   8
   8.  Other Extensions . . . . . . . . . . . . . .  10
     6.3.  Link relations for both information-types . . . . . . . .   8
     8.1.  Use of  11
   7.  atom:category Extensions  . . . . . . . . . . . . . . . . . .   8
       8.1.1.  11
     7.1.  Newly registered category values  . . . . . . . . . .   8
       8.1.2. . .  12
     7.2.  Expectation and Impact Classes  . . . . . . . . . . .   9
   9. . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  12
     8.1.  information-type registrations  . . . . . . . . . . . . .   9
       9.1.1.  12
       8.1.1.  incident information-type . . . . . . . . . . . . . .   9
       9.1.2.  13
       8.1.2.  indicator information-type  . . . . . . . . . . . . .   9
     9.2.  13
     8.2.  atom:category scheme registrations  . . . . . . . . . . .  10
       9.2.1.  13
       8.2.1.  category:csirt:iodef:purpose  . . . . . . . . . . . .  10
       9.2.2.  13
       8.2.2.  category:csirt:iodef:restriction  . . . . . . . . . .  10
     9.3.  13
     8.3.  rolie:property name registrations . . . . . . . . . . . .  10
       9.3.1.  14
       8.3.1.  property:csirt:id . . . . . . . . . . . . . . . . . .  10
   10.  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11.  14
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  11  14
   Appendix A.  Non-Normative  Examples . . . . . . . . . . . . . . .  12
     A.1.  Use of Link Relations . . . . . . . . . . . . . . . . . .  12
       A.1.1. Use Case: Incident Sharing  . .  . . . . . . . . . . .  13
       A.1.2.  Use Case: Collaborative Investigation . . . . . . . .  15
       A.1.3.  Use Case:  Cyber Data Repository  . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20  17

1.  Introduction

   Threats to computer security are evolving ever more rapidly as time
   goes on.  As software increases in complexity, the number of
   vulnerabilities in systems and networks can increase exponentially.
   Threat actors looking to exploit these vulnerabilities are making
   more frequent and more widely distributed attacks across a large
   variety of systems.  The adoption of liberal information sharing
   amongst attackers allows a discovered vulnerability to be shared and
   used to attack a vulnerable system within a narrow window of time.
   As the skills and knowledge required to identify and combat these
   attacks become more and more specialized, even a well established and
   secure system may find itself unable to quickly respond to an
   incident.  Effective identification of and response to a
   sophisticated attack requires open cooperation and collaboration
   between defending operators, software vendors, and end-users.  To
   improve the timeliness of responses, automation must be used to
   acquire, contextualize, and put to use shared computer security
   information.

   CSIRTS share two primary forms of information: incidents and
   indicators.  Using these forms of information, analysts are able to
   perform a wide range of activities both proactive and reactive to
   ensure the security of their systems.

   Incident information describes a cyber security incident.  Such
   information may include attack characteristics, information about the
   attacker, and attack vector data.  Sharing this information helps
   analysts within the sharing community to inoculate their systems
   against similar attacks, providing proactive protection.

   Indicator information describes the symptoms or necessary pre-
   conditions of an attack.  Everything from system vulnerabilities to
   unexpected network traffic can help analysts secure systems and
   prepare for an attack.  Making this information available for sharing
   aids in the proactive defense of systems both within an operating
   unit but also for any CSIRTs that are part of a sharing consortium.

   As a means to bring automation of content discovery and dissemination
   into the CSIRT domain, this specification provides an extension to
   the Resource-Oriented Lightweight Information Exchange (ROLIE) core
   [RFC8322] designed to address CSIRT use cases.  The primary purpose
   of this extension is to define two new information types: incident,
   and indicator, along with formats and link relations that support
   these information-types.

2.  Terminology

   The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
   "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Definitions for some of the common computer security-related
   terminology used in this document can be found in Section 2 of
   [RFC5070].

3.  Additional Requirements for the Atom Publishing Protocol

   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.  Additional Requirements for the Atom Syndication Format

   This document does not specify any additional requirements for the
   Atom Syndication Format.  [RFC4287]

5.  Information-type Extensions

5.1.

4.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
   or pertaining to a computer security incident.  This document uses
   the definition of incident provided by [RFC4949].  Provided below is
   a non-exhaustive list of information that may be considered to be an
   incident information type.

   o  Timing information: start and end times for the incident and/or
      the response.

   o  Descriptive information: plain text or machine readable data that
      provides some degree of description of the incident itself.

   o  Response information: the methods and results of a response to the
      incident.

   o  Meta and contact information: data about the CSIRT that recorded
      the information, or the operator that enacted the response.

   o  Effect and result information: data that describes the effects of
      an incident, or what the final results of the incident are.

   Note again that this list is not exhaustive, any information that in
   is the abstract realm of an incident should be classified under this
   information-type.

5.2.

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
   indicators or any information surrounding them.  This document uses
   the definition of indicator provided by [RFC4949].  Some examples of
   indicator information is provided below, but note that indicator is
   defined in an abstract sense, to be understood as a flexible and
   widely-applicable definition.

   o  Specific vulnerabilities that indicate a vector for attack.

   o  Signs of malicious reconnaissance.

   o  Definitions of patterns of other indicators.

   o  Events that may indicate an attack and information regarding those
      events.

   o  Meta information about the collecting agent.

   This list is intended to provide examples of the indicator
   information-type, not to define it.

5.3.  Use of the rolie:format element

5.  Data format requirements

   This document does not contain any section defines usage guidance and additional requirements for the
   rolie:format element; the formats that follow are provided as
   examples of
   related to data formats that describe the incident above and indicator
   information type. beyond those specified in
   [RFC8322].  The following formats are in no particular order, and are
   not requirements, nor suggestions by the authors.

5.3.1.  IODEF expected to be commonly used to
   express software descriptor information.  For this reason, this
   document specifies additional requirements to ensure
   interoperability.

5.1.  Incident Object Description Exchange Format

5.1.1.  Description

   The Incident Object Description Exchange Format (IODEF) is a format
   for representing computer security information commonly exchanged
   between Computer Security Incident Response Teams (CSIRTs) or other
   operational security teams.

   IODEF conveys indicators, incident reports, response activities, and
   related meta-data in an XML serialization.  This information is
   formally structured in order to support and encourage automated
   machine-to-machine security communication, as well as enhanced
   processing at the endpoint.

   The full IODEF specification [RFC7970] provides further high-level
   discussion and technical details.

5.3.2.  STIX Format

   STIX is a structured language for describing

5.1.2.  Requirements

   For an Entry to be considered as a wide range of security
   resources.  STIX approaches "IODEF Entry", it MUST fulfill the problem with a focus on flexibility,
   automation, readability, and extensibility.
   following conditions:

   o  The use information-type of STIX as the content of an Entry does not impose any
   additional requirements on ROLIE implementations.

6.  rolie:property Extensions

   This document provides new registrations for valid rolie:property
   names.  These properties provide optional exposure point for valuable
   information in the linked content document.  Exposing is "indicator" or "incident".
      For a typical Entry, this is derived from the information in a rolie:property element means that clients do not
   need to download type of
      the linked document to determine if Feed it contains the
   information they are looking for.

6.1.  urn:ietf:params:rolie:property:csirt:ID

   Provides an XML element that can be populated with is contained in.  For a standalone Entry, this is
      provided by an identifier from
   the indicator or incident "atom:category" element.

   o

   o  The document linked to by an atom:content
   element.  This value SHOULD be a uniquely identifying value for the "href" attribute of the
      "atom:content" element is an IODEF document linked as per [RFC7970]

   A "IODEF Entry" MUST conform to in this entry's atom:content element.

7.  Use the following requirements:

   o  The value of the atom:link "type" attribute of the "atom:content" element

   These sections define requirements for atom:link elements in Entries.
   Note that
      MUST be "application/xml".

   o  There MUST be at least one "rolie:property" with the requirements are determined by "name"
      attribute equal to "urn:ietf:params:rolie:property:content-id" and
      the information type
   that appears in either "value" attribute exactly equal to the Entry "<Indicator-ID>" or the
      "<Incident-ID>" element in the parent Feed.

7.1.  Link relations attached IODEF document.  This
      allows for ROLIE consumers to more easily search for IODEF
      doucments without needing to download the 'incident' information-type

   If the category of an Entry doucment itself.

5.2.  Structured Threat Information eXpression (STIX) Format

5.2.1.  Description

   STIX is the incident information type, then
   the following requirements MUST be followed a structured language for inclusion describing a wide range of
   atom:link elements.

   +------------+----------------------------------------+-------------+
   | Name       | Description                            | Conformance |
   +------------+----------------------------------------+-------------+
   | indicators | Provides security
   resources.  STIX approaches the problem with a link focus on flexibility,
   automation, readability, and extensibility.

   The full STIX specification [stix2] provides further high-level
   discussion and technical details.

5.2.2.  Requirements

   For an Entry to be considered as a collection "STIX Entry", it MUST fulfill the
   following conditions:

   o  The information-type of     | SHOULD      |
   |            | zero the Entry is "indicator" or more instances "incident".
      For a typical Entry, this is derived from the information type of cyber        |             |
   |            | security indicators that are           |             |
   |            | associated with
      the resource.          |             |
   | evidence   | Provides Feed it is contained in.  For a link standalone Entry, this is
      provided by an "atom:category" element.

   o

   o  The document linked to a collection by the "href" attribute of     | SHOULD      |
   |            | zero or more resources that provides   |             |
   |            | some proof of attribution for an       |             |
   |            | incident. The evidence may or may not  |             |
   |            | have any identified chain of custody.  |             |
   | attacker   | Provides the
      "atom:content" element is a link STIX object as per [stix2]

   A "STIX Entry" MUST conform to a collection the following requirements:

   o  The value of     | SHOULD      |
   |            | zero the "type" attribute of the "atom:content" element
      MUST be "application/xml" or "application/json".

   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 "<id>" element in the
      attached STIX object . This allows for ROLIE consumers to more resources that provides a |             |
   |            | representation of
      easily search for STIX objects without needing to download the attacker.        |             |
   | vector     | Provides a link
      document itself.

5.3.  Malware Information Sharing Platform (MISP) Format

   MISP involves documentation, utilities, and formats designed to a collection
   faciliate the day-to=day duties of     | SHOULD      |
   |            | zero or more resources security operators.  MISP includes
   it's own data format that provides is used to share between MISP features.
   While MISP has Feed features that can share and distribute events, it
   has support for linking to other sharing methods like ROLIE.

   MISP is defined by a |             |
   |            | representation family of internet drafts and are actively being
   worked on.  With that in mind, this extension will provice non-
   normative guidance on using MISP format data in ROLIE.  In the method used by   |             |
   |            |
   future, when the attacker.                          |             |
   +------------+----------------------------------------+-------------+

    Table 1: Link Relations for Resource-Oriented Lightweight Indicator
                                 Exchange

7.2.  Link relations for MISP format is formally published, this document
   will be updated to normative requirements around MISP content.

5.3.1.  Creating MISP Event Entries

   MISP content should be syndicated in ROLIE using the 'indicator' following
   guidance:

   o  The information-type

   If the category of an the Entry is "indicator".  For a typical
      Entry, this is derived from the indicator information type, then type of the following requirements MUST be followed for inclusion of
   atom:link elements.

   +-----------+-----------------------------------------+-------------+
   | Name      | Description                             | Conformance |
   +-----------+-----------------------------------------+-------------+
   | incidents | Provides Feed it is
      contained in.  For a link 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 collection MISP Event object as per
      [I-D.dulaunoy-misp-core-format]

   o  The value of zero | SHOULD      |
   |           | or more instances the "type" attribute of incident           |             |
   |           | representations associated the "atom:content" element
      should be "application/xml".

   o  There should be at least one "rolie:property" with the     |             |
   |           | resource.                               |             |
   +-----------+-----------------------------------------+-------------+

    Table 2: Link Relations "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 Resource-Oriented Lightweight Indicator
                                 Exchange

7.3.  Link relations ROLIE consumers to more
      easily search for both information-types

   If MISP Events without needing to download the category of an
      document itself.

   o  It is also recommended to expose information in the ROLIE Entry
      that is either information-type, required and recommended to expose in the MISP Manifest
      format.  THis ensures better compatability between a ROLIE Feed
      and a MISP Manifest

      *  The following
   requirements MUST be followed for inclusion 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 atom:link elements.

   +-----------------------+-----------------------------+-------------+
   | Name                  | Description                 | Conformance |
   +-----------------------+-----------------------------+-------------+
   | assessments           | Provides MISP events, each event represented by
   its uuid.  Users request Events on a link to 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        | MAY         |
   |                       | collection variety of zero or more  |             |
   |                       | resources that represent    |             |
   |                       | metadata for each Event inline.  After examining
   the results of executing a  |             |
   |                       | benchmark.                  |             |
   | reports               | Provides minimized and stripped Event in the manifest, a link to user could search
   for the Event uuid of interest in a        | MAY         |
   |                       | collection locally located folder of zero or more  |             |
   |                       | resources 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 represent    |             | 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                      | RID reports. Description        | Conformance      |
   +---------------------------+--------------------+------------------+
   | traceRequests indicators                | Provides a link to a | MAY evidence         |
   |                           | a collection of    |                  |
   |                           | zero or more       |                  |
   |                           | resources instances of cyber |                  |
   |                           | security           |                  |
   |                           | indicators that represent    |                  |
   |                           | RID traceRequests. are associated     |                  |
   | investigationRequests                           | with the resource. |                  |
   | Provides a link to a      | MAY attacker           | Provides a link  |
   | collection of zero or more     |                    | to a collection  |
   | more resources that represent       |                    | of zero or more  |
   | RID investigationRequests. provides some proof of    |                    |
   +-----------------------+-----------------------------+-------------+

    Table 3: Link Relations resources that   |
   | attribution for Resource-Oriented Lightweight Indicator
                                 Exchange

8.  Other Extensions

   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
   names: 'urn:ietf:params:rolie:category:csirt:iodef:purpose' and
   'urn:ietf:params:rolie:category:csirt:iodef:restriction'.  These
   categories IODEF content exposure an        |                    | provides valuable metadata for the
   searching and organization a       |
   | incident. The evidence    |                    | representation   |
   | may or may not have any   |                    | of IODEF documents.

   When the name attribute attacker. |
   | identified chain of the category is
   'urn:ietf:params:rolie:category:csirt:iodef:purpose', the value
   attribute SHOULD be constrained as per section 3.2       |                    |                  |
   | custody.                  |                    |                  |
   | vector                    | Provides a link to |
   |                           | a collection of IODEF
   [RFC7970], e.g. traceback, mitigation, reporting,    |
   |                           | zero or other.

   When the name attribute more       |
   |                           | resources that     |
   |                           | provides a         |
   |                           | representation of  |
   |                           | the category is
   'urn:ietf:params:rolie:category:csirt:iodef:restriction', method used by |
   |                           | the value
   attribute SHOULD be constrained as per section 3.2 of IODEF
   [RFC7970], e.g. public, need-to-know, private, default.

8.1.2.  Expectation and Impact Classes

   It is frequently attacker.      |
   +---------------------------+--------------------+------------------+

    Table 1: Link Relations for Resource-Oriented Lightweight Indicator
                                 Exchange

6.2.  Link relations for the case that an organization will need to triage
   their investigation and response activities based upon, e.g., 'indicator' information-type

   If a ROLIE server supports the
   state indicator information-types, then
   these link relations MUST be supported.

   +-----------+-----------------------------------------+-------------+
   | Name      | Description                             | Conformance |
   +-----------+-----------------------------------------+-------------+
   | incidents | Provides a link to a collection of the current threat environment, zero |
   |           | or simply as a result more instances of
   having limited resources.

   In order to enable operators to effectively prioritize their response
   activity, it is RECOMMENDED that feed implementers provide Atom
   categories that correspond to incident           |
   |           | representations associated with the IODEF Expectation and Impact
   classes.  The availability of     |
   |           | resource.                               |
   +-----------+-----------------------------------------+-------------+

    Table 2: Link Relations for Resource-Oriented Lightweight Indicator
                                 Exchange

6.3.  Link relations for both information-types

   If a ROLIE server supports either the incident or the indicator
   information-types, then these feed categories will enable
   clients link relations MUST be supported.

   +-----------------------+------------------------+------------------+
   | Name                  | Description            | Conformance      |
   +-----------------------+------------------------+------------------+
   | assessments           | Provides a link to a   | reports          |
   |                       | collection of zero or  |                  |
   |                       | more easily retrieve and prioritize cyber security
   information resources that has already been identified as having    |                  |
   |                       | represent the results  |                  |
   |                       | of executing a specific
   potential impact,         |                  |
   |                       | benchmark.             |                  |
   | Provides a link to a  | traceRequests          | Provides a link  |
   | collection of zero or having |                        | to a specific expectation.

   Support for these categories may also enable efficiencies for
   organizations collection  |
   | more resources that already have established (or plan to establish)
   operational processes and workflows   |                        | of zero or more  |
   | represent RID         |                        | resources that are based on these IODEF
   classes.

9.  IANA Considerations

9.1.  information-type registrations

   IANA has added the following entries   |
   | reports.              |                        | represent RID    |
   |                       |                        | traceRequests.   |
   | investigationRequests | Provides a link to the "ROLIE Security Resource
   Information Type Sub-Registry" registry located at
   <https://www.iana.org/assignments/rolie/category/information-type> .

9.1.1.  incident information-type

   The entry is as follows:

      name: incident

      index: TBD

      reference: This document, Section 5.1

9.1.2.  indicator information-type

   The entry is as follows:

      name: indicator
      index: TBD

      reference: a   |
   |                       | collection of zero or  |
   |                       | more resources that    |
   |                       | represent RID          |
   |                       | investigationRequests. |
   +-----------------------+------------------------+------------------+

    Table 3: Link Relations for Resource-Oriented Lightweight Indicator
                                 Exchange

7.  atom:category Extensions
7.1.  Newly registered category values

   This document, Section 5.2

9.2. document registers two additional registered atom:category scheme registrations

   IANA has added
   names: 'urn:ietf:params:rolie:category:csirt:iodef:purpose' and
   'urn:ietf:params:rolie:category:csirt:iodef:restriction'.  These
   categories IODEF content exposure provides valuable metadata for the following entries to
   searching and organization of IODEF documents.

   When the "ROLIE URN Parameters"
   registry located in <https://www.iana.org/assignments/rolie/>.

9.2.1.  category:csirt:iodef:purpose

   The entry is as follows:

      name: category:csirt:iodef:purpose

      Extension IRI: urn:ietf:params:rolie:category:csirt:iodef:purpose

      Reference: This document, Section 8.1.1

      Subregistry: None

9.2.2.  category:csirt:iodef:restriction

   The entry is as follows:

      name: category:csirt:iodef:restriction

      Extension IRI:
      urn:ietf:params:rolie:category:csirt:iodef:restriction

      Reference: This document, Section 8.1.1

      Subregistry: None

9.3.  rolie:property name registrations

   IANA has added the following entries to attribute of the "ROLIE URN Parameters"
   registry located in <https://www.iana.org/assignments/rolie/>.

9.3.1.  property:csirt:id

   The entry category is
   'urn:ietf:params:rolie:category:csirt:iodef:purpose', the value
   attribute SHOULD be constrained as follows:

      name: property:csirt:id

      Extension IRI: urn:ietf:params:rolie:property:csirt:id

      Reference: This document, per section 6.3.1
      Subregistry: None

10.  Security Considerations

   This document implies 3.2 of IODEF
   [RFC7970], e.g.  traceback, mitigation, reporting, or other.

   When the use name attribute of ROLIE in high-security use cases, as
   such, added care should the category is
   'urn:ietf:params:rolie:category:csirt:iodef:restriction', the value
   attribute SHOULD be taken to fortify and secure ROLIE
   repositories constrained as per section 3.2 of IODEF
   [RFC7970], e.g.  public, need-to-know, private, default.

7.2.  Expectation and clients using this extension.  The guidance in the
   ROLIE core specification Impact Classes

   It is strongly recommended, frequently the case that an organization will need to triage
   their investigation and implementers
   should consider adding additional security measures response activities based upon, e.g., the
   state of the current threat environment, or simply as they see fit.

   When providing a private workspace for closed sharing, result of
   having limited resources.

   In order to enable operators to effectively prioritize their response
   activity, it is
   recommended RECOMMENDED that the ROLIE repository checks user authorization when
   the user sends a GET request feed implementers provide Atom
   categories that correspond to the service document.  If the user is
   not authorized to send any requests IODEF Expectation and Impact
   classes.  The availability of these feed categories will enable
   clients to more easily retrieve and prioritize cyber security
   information that has already been identified as having a given workspace specific
   potential impact, or
   collection, having a specific expectation.

   Support for these categories may also enable efficiencies for
   organizations that workspace or collection should be truncated from already have established (or plan to establish)
   operational processes and workflows that are based on these IODEF
   classes.

8.  IANA Considerations

8.1.  information-type registrations

   IANA has added the
   service document in following entries to the response.  In this way "ROLIE Security Resource
   Information Type Sub-Registry" registry located at
   <https://www.iana.org/assignments/rolie/category/information-type> .

8.1.1.  incident information-type

   The entry is as follows:

      name: incident

      index: TBD

      reference: This document, Section 4.1

8.1.2.  indicator information-type

   The entry is as follows:

      name: indicator

      index: TBD

      reference: This document, Section 4.2

8.2.  atom:category scheme registrations

   IANA has added the existence of
   unauthorized content remains unknown following entries to potential attackers,
   hopefully reducing attack surface.

11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use the "ROLIE URN Parameters"
   registry located in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI <https://www.iana.org/assignments/rolie/>.

8.2.1.  category:csirt:iodef:purpose

   The entry is as follows:

      name: category:csirt:iodef:purpose

      Extension IRI: urn:ietf:params:rolie:category:csirt:iodef:purpose

      Reference: This document, Section 7.1

      Subregistry: None

8.2.2.  category:csirt:iodef:restriction

   The entry is as follows:

      name: category:csirt:iodef:restriction

      Extension IRI:
      urn:ietf:params:rolie:category:csirt:iodef:restriction

      Reference: This document, Section 7.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

9.  Security Considerations

   This document implies the use of ROLIE in high-security use cases, as
   such, added care should be taken to fortify and secure ROLIE
   repositories and clients using this extension.  The guidance in the
   ROLIE core specification is strongly recommended, and implementers
   should consider adding additional security measures as they see fit.

   When providing a private workspace for closed sharing, it is
   recommended that the ROLIE repository checks user authorization when
   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
   collection, that workspace or collection should be truncated from the
   service document in the response.  In this way the existence of
   unauthorized content remains unknown to potential attackers,
   hopefully reducing attack surface.

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
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4287]  Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
              Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
              December 2005, <https://www.rfc-editor.org/info/rfc4287>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC5023]  Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
              Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
              October 2007, <https://www.rfc-editor.org/info/rfc5023>.

   [RFC5070]  Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
              Object Description Exchange Format", RFC 5070,
              DOI 10.17487/RFC5070, December 2007,
              <https://www.rfc-editor.org/info/rfc5070>.

   [RFC7970]  Danyliw, R., "The Incident Object Description Exchange
              Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
              November 2016, <https://www.rfc-editor.org/info/rfc7970>.

   [RFC8322]  Field, J., Banghart, S., and D. Waltermire, "Resource-
              Oriented Lightweight Information Exchange (ROLIE)",
              RFC 8322, DOI 10.17487/RFC8322, February 2018,
              <https://www.rfc-editor.org/info/rfc8322>.

   [stix2]    "Structured Threat Information Expression 2.0", July 2017.

Appendix A.  Non-Normative  Examples

   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
   Host: www.example.org
   Content-Type: application/atom+xml;type=entry
   Content-Length: 852

   <?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">
     <title>New Investigation Request</title>
     <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
   201 Created.

   HTTP/1.1 201 Created
   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"?>
   <entry xmlns="http://www.w3.org/2005/Atom"
     xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0">
     <title>New Investigation Request</title>
     <id>http://www.example.org/csirt/RID/InvestigationRequests/823</id>
     <!-- id and updated not guranteed to be preserved -->
     <!-- may want to profile that behavior in this document -->
     <updated>2012-08-12T11:08:30Z</updated>
     <published>2012-08-12T11:08:30Z</published>
     <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.example.org/csirt/private
           /incidents">123</iodef:IncidentID>
           <!-- ...additional incident data.... -->
         </iodef:Incident>
       </iodef:IODEF-Document>
     </content>
   </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 of Use

   Use of this extension in a ROLIE repository will not typically change
   that repository's operation.  As such, the DDOS feed.

   Example HTTP GET response for general examples provided
   by the ROLIE core document would serve as examples.  Provided below
   is 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" sample incident ROLIE entry containing an IODEF document:

  <?xml version="1.0" encoding="UTF-8"?>
<feed
  <entry 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>
    xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0">
    <id>f762c77c-057d-45c9-b805-677ab89aaf7c</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"/>
    <published>2018-09-04T18:13:51.0Z</published>
    <updated>2019-08-05T18:13:51.0Z</updated>
    <summary>A short description document containing an indicator of this DDOS attack, extracted
        from the IODEF Incident class, <description> element. 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:example:iodef"/>
        ns="urn:ietf:params:xml:ns:iodef-2.0"/>
    <content href="http://www.example.org/ddos/123456/data"/>
    </entry>

    <entry>
        <!-- ...another entry... --> type="application/xml"
        src="http://www.example.org/rolie/csirt/123456/data"/>
  </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

   Below 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 sample indicator ROLIE entry containing a browser).  However, this is not required and is STIX document:

   <?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>0c99df51-767f-4940-8a09-c4b607b6fe21</id>
     <title>Sample Indicator</title>
     <published>2018-09-04T18:13:51.0Z</published>
     <updated>2019-08-05T18:13:51.0Z</updated>
     <summary>A document containing an
   implementation choice that is out of scope for this specification. incident report. </summary>
     <link rel="self" href="http://www.example.org/rolie/CSIRT/654321"/>
     <link rel="feed" href="http://www.example.org/rolie/CSIRT/"/>
     <rolie:property name=urn:ietf:params:rolie:property:content-id
         value="exmaple:indicator:654321"/>
     <category
         scheme="urn:ietf:params:rolie:category:information-type"
         term="indicator"/>
     <rolie:format
         ns=http://stix.mitre.org/XMLSchema/core/1.2/stix_core.xsd"/>
     <content type="application/xml"
         src="http://www.example.org/rolie/csirt/654321/data"/>
   </entry>

Authors' Addresses

   Stephen A. Banghart
   National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, Maryland
   USA

   Phone: (301)975-4288
   Email: sab3@nist.gov

   John P. Field
   Pivotal Software, Inc.
   625 Avenue of the Americas
   New York, New York
   USA

   Phone: (646)792-5770
   Email: jfield@pivotal.io