One document matched: draft-ietf-mile-rolie-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/css" href="rfc7749.css"?>
<rfc ipr="trust200902" category="info" docName="draft-ietf-mile-rolie-02">
<!-- Working draft of draft02 -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="ROLIE">Resource-Oriented Lightweight Information Exchange</title>
<author initials="J.P." surname="Field" fullname="John P. Field">
<organization abbrev="Pivotal">Pivotal Software, Inc.</organization>
<address>
<postal>
<street>625 Avenue of the Americas</street>
<city>New York</city>
<region>New York</region>
<country>USA</country>
</postal>
<phone>(646)792-5770</phone>
<email>jfield@pivotal.io</email>
</address>
</author>
<author initials="S.A." surname="Banghart" fullname="Stephen A. Banghart">
<organization abbrev="NIST">National Institute of Standards and Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<country>USA</country>
</postal>
<phone>(301)975-4288</phone>
<email>sab3@nist.gov</email>
</address>
</author>
<date month="June" day="3" year="2016"/>
<area>Security</area>
<workgroup>MILE Working Group</workgroup>
<abstract>
<t> This document defines a resource-oriented approach to cyber security information sharing.
Using this approach, operators may share and exchange representations of cyber security
incidents, attack indicators, software vulnerabilities, and other related information as
Web-addressable resources. Furthermore, consumers and other stakeholders may access and
search this security content as needed, establishing a rapid and on-demand information
exchange network for restricted internal use or public access repositories. This
specification builds on and extends the Atom Publishing
Protocol and Atom Syndication Format to transport and
share cyber security resource representations. This document leverages the existing
representations IODEF and RID
where appropriate, and supports related cyber security representation standards.</t>
</abstract>
<note title="Contributing to this document">
<!--RFC EDITOR - Please remove this note before publishing -->
<t>The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests
at <eref target="https://github.com/CISecurity/ROLIE"/>. Instructions are on that page as well. Editorial changes can
be managed in GitHub, but any substantial issues need to be discussed on the MILE mailing list. </t>
</note>
</front>
<middle>
<section title="Introduction" anchor="starting-intro">
<t> This document defines a resource-oriented approach to cyber security information sharing
that follows the <xref target="REST" format="title" pageno="false">REST</xref> architectural
style. In this approach, cyber security resources are maintained in web-accessible
repositories structured as <xref target="RFC4287">Atom Syndication Format</xref> feeds.
Representations of content are categorized and organized into indexed collections, which are
requested by the consumer. As the set of resource collections are forward facing, the
consumer may search all available content for which they are authorized to view and request
that which is desired. Granular authentication and access controls permit only authorized
consumers the ability to view, read, or write to a given feed. This approach is in contrast
to, and meant to improve on, the traditional point-to-point messaging system, in which
consumers must request individual pieces of information from a server following a triggering
event. This traditional approach creates a closed system of information sharing that
encourages duplication of efforts and hinders automated cyber security systems.<vspace
blankLines="1"/> The goal of this document is to define the RESTful approach to cyber
security communication with the intent of increasing communication and sharing of incident
reports, vulnerability assessments, and other security content between producers, operators,
and consumers.<vspace blankLines="1"/> In order to exchange information as web-addressable
resources, the resource representations leverage the existing <xref target="RFC5070"
>IODEF</xref> and <xref target="RFC6545">RID</xref> specifications and other
representation standards as appropriate. The transport protocol binding is specified as
HTTP(S) with a media type of Atom+XML. An appropriate set of link relation types specific to
cyber security information sharing is defined.<vspace blankLines="1"/> Coexistence with
deployments that conform to existing specifications including <xref target="RFC6545"
>RID</xref> and <xref target="RFC6546">Transport of Real-time Inter-network Defense (RID)
Messages over HTTP/TLS</xref> is supported via appropriate use of HTTP status codes. </t>
</section>
<section title="Terminology" anchor="ext-terminology">
<t> 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 <xref target="RFC2119"/>. Definitions for some of the common computer
security-related terminology used in this document can be found in Section 2 of <xref
target="RFC5070"/>. </t>
</section>
<section title="Background and Motivation" anchor="back-motive">
<t> It is well known that the field of threats to computer security is evolving ever more
rapidly as time goes on. As software increases in complexity, the number of vulnerabilities
in our systems and networks 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 creates a
window of as little as a few hours between the discovery of a vulnerability and attacks on
the vulnerable system. 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 even end-users. <vspace blankLines="1"/> Existing
approaches to cyber security information sharing are based upon message exchange patterns
that are point-to-point, and event-driven. Sometimes, information that may be useful to, and
sharable with multiple peers is only made available to peers after they have specifically
requested it. Unfortunately, a sharing peer may not know, a priori, what information to
request from another peer. Sending unsolicited RID reports does provide a mechanism for
alerting, however these reports are again sent point-to-point, and must be reviewed for
relevance and then prioritized for action by the recipient. Thus, distribution of some
relevant incident and indicator information may exhibit significant latency. <vspace
blankLines="1"/> In order to adequately combat the evolving threats, computer security
resource producers should be enabled to share selected information proactively as
appropriate. Proactive sharing greatly aids knowledge dissemination as well as improving on
response times and usability.<vspace blankLines="1"/> For example, a cyber security analyst
would benefit by having the ability to search a comprehensive collection of attack
indicators that have been published by a government agency, or by another member of a
sharing consortium. The representation of each indicator may include links to the related
resources, enabling an appropriately authenticated and authorized analyst to freely navigate
the information space of indicators, incidents, vulnerabilities, and other cyber security
domain concepts, as needed. In general, a more Web-centric sharing approach will enable a
more dynamic and agile collaboration amongst a broader, and varying constituency. <vspace
blankLines="1"/> The following sections discuss additional specific technical issues that
motivate the development of an alternative approach. </t>
<section title="Message-oriented versus Resource-oriented Architecture" anchor="msg-vs-roa">
<t>The existing approaches to cyber security information sharing are based upon
message-oriented interactions. The following paragraphs explore some of the architectural
constraints associated with message-oriented interactions and consider the relative merits
of an alternative model based on a Resource-oriented architecture for use in some use case
scenarios. <vspace blankLines="1"/>ROLIE specifies a resource-oriented architecture.</t>
<section title="Message-oriented Architecture" anchor="message">
<t> In general, message-based integration architectures may be based upon either an
RPC-style or a document-style binding. The message types defined by RID represent an
example of an RPC-style request. This approach imposes implied requirements for
conversational state management on both of the communicating RID endpoint(s). Experience
has shown that this state management frequently becomes the limiting factor with respect
to the runtime scalability of an RPC-style architecture. <vspace blankLines="1"/> In
addition, the practical scalability of a peer-to-peer message-based approach will be
limited by the administrative procedures required to manage O(N^2) trust relationships
and at least O(N) policy groups. <vspace blankLines="1"/> As long as the number of
participating entities in an information sharing consortium is limited to a relatively
small number of nodes (i.e., O(2^N), where N < 5), these scalability constraints may
not represent a critical concern. However, when there is a requirement to support a
significantly larger number of participating peers, a different architectural approach
will be required. One alternative to the message-based approach that has demonstrated
scalability is the <xref target="REST">REST</xref> architectural style.</t>
</section>
<section title="Resource-Oriented Architecture" anchor="roa-benefits">
<t> Applying the REST architectural style to the problem domain of cyber security
information sharing would take the approach of exposing incidents, indicators, and any
other relevant types as simple Web-addressable resources. By using this approach, an
organization can more quickly and easily share relevant incident and indicator
information with a much larger and potentially more diverse constituency. A consumer may
leverage virtually any available HTTP user agent in order to make requests of the
service provider. This improved ease of use could enable more rapid adoption and broader
participation, thereby improving security for everyone. <vspace blankLines="1"/> A key
interoperability aspect of any RESTful Web service will be the choices regarding the
available resource representations. For example, clients may request that a given
resource representation be returned as either XML or JSON. In order to enable
back-compatibility and interoperability with existing implementations, <xref
target="RFC5070">IODEF</xref> is specified for this transport binding as a mandatory
to implement (MTI) data representation for incident and indicator resources. In addition
to the REQUIRED representation, an implementation MAY support additional representations
if and as needed such as IODEF extensions, the RID schema, or other schemas. For
example, an implementation may choose to provide support for returning a JSON
representation of an incident resource. <vspace blankLines="1"/> Finally, an important
principle of the REST architectural style is the use of hypertext links as the
embodiment of application state (HATEOAS). Rather than the server maintaining
conversational state for each client context, the server will instead include a suitable
set of hyperlinks in the resource representation that is returned to the client. In this
way, the server remains stateless with respect to a series of client requests. The
included hyperlinks provide the client with a specific set of permitted state
transitions. Using these links the client may perform an operation, such as updating or
deleting the resource representation. The client may also be provided with hypertext
links that can be used to navigate to any related resource. For example, the resource
representation for an incident object may contain links to the related indicator
resource(s). <vspace blankLines="1"/> This document specifies the use of <xref
target="RFC4287">Atom Syndication Format</xref> and <xref target="RFC5023">Atom
Publishing Protocol</xref> as the mechanism for representing the required hypertext
links. </t>
<section title="A Resource-Oriented Use Case: "Mashup"" anchor="mashup">
<t> In this section we consider a non-normative example use case scenario for creating a
cyber security "mashup". <vspace blankLines="1"/> Any operator can authorize any or
all members of the sharing community to quickly and easily navigate through any of the
cyber security information that that provider is willing to share. An analyst may then
make HTTP(S) requests to collect vulnerability information known at one producer and
threat actor data being made available from another producer. The resulting
correlations may yield new insights that enable a more timely and effective defensive
response. Of course, this report may, in turn, be made available to others as a new
Web-addressable resource, reachable via another URL. By employing the RESTful Web
service approach the effectiveness of the collaboration amongst a consortium of cyber
security stakeholders can be greatly improved. </t>
</section>
</section>
</section>
</section>
<section title=" Atom Publication Protocol and Atom Syndication Format TODO" anchor="atom">
<t> As described in <xref target="RFC5023">Atom Publishing Protocol</xref>, an Atom Service
Document is an XML-based document format that allows a client to dynamically discover the
collections provided by a publisher. <vspace blankLines="1"/> As described in <xref
target="RFC4287">Atom Syndication Format</xref>, Atom is an XML-based document format that
describes lists of related information items known as collections, or "feeds". Each feed
document contains a collection of zero or more related information items called "member
entries" or "entries". <vspace blankLines="1"/> When applied to the problem domain of cyber
security information sharing, an Atom feed may be used to represent any meaningful
collection of information resources such as a set of incidents, or indicators. Each entry in
a feed could then represent an individual incident, or indicator, or some other resource, as
appropriate. Additional feeds could be used to represent other meaningful and useful
collections of cyber security resources. A feed may be categorized, and any feed may contain
information from zero or more categories. The naming scheme and the semantic meaning of the
terms used to identify an Atom category are application-defined.<vspace blankLines="1"/>This
document assumes that the reader has an understanding of both Atom documents. Further
discussion of Atom's application to this domain a well of examples of its use are provided
in the BCG document.</t>
</section>
<section title=" Normative Requirements TODO" anchor="normative-requirements">
<t>This section provides the NORMATIVE requirements for using Atom format and Atom Pub as a
RESTful binding for cyber security information sharing.</t>
<section title="Atom Requirements" anchor="atom-req">
<t>Implementations of this specification MUST implement all requirements specified in Atom
Publishing Protocol and the Atom Syndication Format. (TODO: work on a more normative and
perhaps constrained requirement.)</t>
</section>
<section title="Transport Layer Security" anchor="normative-transport-sec">
<t>Implementations MUST support server-authenticated TLS. <vspace blankLines="1"
/>Implementations MAY support mutually authenticated TLS.</t>
</section>
<section title="Archiving and Paging" anchor="normative-archive-page">
<t>A feed can contain an arbitrary number of entries. In some cases, the complete response
to a given query may consist of a logical result set that contains a large number of
entries. As a practical matter, the full result set will likely need to be divided into
more manageable portions. For example, a query may produce a full result set that may need
to be grouped into logical pages, for purposes of rendering on a user interface. <vspace
blankLines="1"/> An historical feed may need to be stable, and/or divided into some
defined epochs. Implementations SHOULD support the mechanisms described in <xref
target="RFC5005">Feed Paging and Archiving</xref> to provide capabilities for paging and
archiving of feeds. </t>
</section>
<section title="Expectation and Impact Classes" anchor="normative-expectation-impact">
<t>It is frequently the case that an organization will need to triage their investigation
and response activities based upon, e.g., the state of the current threat environment, or
simply as a result of having limited resources. <vspace blankLines="1"/> In order to
enable operators to effectively prioritize their response activity, it is RECOMMENDED that
feed implementers provide Atom categories that correspond to the 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 specific potential impact, or having a specific expectation. <vspace
blankLines="1"/> Support for these categories may also enable efficiencies for
organizations that already have established (or plan to establish) operational processes
and workflows that are based on these IODEF classes. </t>
</section>
<section title="User Authentication" anchor="normative-user-auth">
<t>Implementations MUST support user authentication. User authentication MAY be enabled for
specific feeds.<vspace blankLines="1"/>Implementations MAY support more than one client
authentication method. <vspace blankLines="1"/> Servers participating in an information
sharing consortium and supporting interactive user logins by members of the consortium
SHOULD support client authentication via a federated identity scheme as per SAML 2.0.
<vspace blankLines="1"/> Implementations MAY support client authenticated TLS. </t>
</section>
<section title="User Authorization" anchor="normative-user-authz">
<t>This document does not mandate the use of any specific user authorization mechanisms.
However, service implementers SHOULD provide appropriate authorization checking for all
resource accesses, including individual Atom Entries, Atom Feeds, and Atom Service
Documents. <vspace blankLines="1"/> Authorization for a resource MAY be adjudicated based
on the value(s) of the associated Atom <category> element(s). <vspace blankLines="1"
/> When the content model for the Atom <content> element of an Atom Entry contains
an <IODEF-Document>, then authorization MUST be adjudicated based upon the Atom
<category> element(s), whose values have been mapped as per <xref
target="category-mapping"/>. <vspace blankLines="1"/> Any use of the <category>
element(s) as an input to an authorization policy decision MUST include both the "scheme"
and "term" attributes contained therein. As described in <xref target="category-mapping"/>
below, the namespace of the "term" attribute is scoped by the associated "scheme"
attribute. </t>
</section>
<section title="Content Model" anchor="content-model">
<t> Member entry resources providing a representation of an incident resource (e.g., as
specified in the link relation type) MUST use the IODEF schema as the content model for
the Atom Entry <content> element. <vspace blankLines="1"/> Member Entry resources
providing a representation of an indicator resource (e.g., as specified in the link
relation type) MUST use the IODEF schema as the content model for the Atom Entry
<content> element. <vspace blankLines="1"/> The resource representation MAY include
an appropriate indicator schema type within the <AdditionalData> element of the
IODEF Incident class. Supported indicator schema types SHALL be registered via an IANA
table (todo: IANA registration/review). <vspace blankLines="1"/> Member Entry resources
providing a representation of a RID report resource (e.g., as specified in the link
relation type) MUST use the RID schema as the content model for the Atom Entry
<content> element. <vspace blankLines="1"/> Member Entry resources providing
representation of other types, SHOULD use the schema appropriate for their data category
as the content model for the Atom Entry <content> element. These data categories
SHALL be registered via an IANA table.<vspace blankLines="1"/> The <content> element
of the Atom entry MUST contain an appropriate XML namespace declaration. </t>
</section>
<section title="HTTP methods" anchor="inc-http-methods">
<t>The following table defines the <xref target="RFC7235">HTTP</xref> uniform interface
methods supported by this specification: </t>
<texttable anchor="http-methods-table"
title="Uniform Interface for Resource-Oriented Lightweight Indicator Exchange">
<ttcol align="left">HTTP method</ttcol>
<ttcol align="left">Description</ttcol>
<c>GET</c>
<c>Returns a representation of an individual member entry resource, or a feed collection. </c>
<c>PUT</c>
<c>Replaces the current representation of the specified member entry resource with the
representation provided in the HTTP request body.</c>
<c>POST</c>
<c>Creates a new instance of a member entry resource. The representation of the new
resource is provided in the HTTP request body.</c>
<c>DELETE</c>
<c>Removes the indicated member entry resource, or feed collection.</c>
<c>HEAD</c>
<c>Returns metadata about the member entry resource, or feed collection, contained in HTTP
response headers.</c>
<c>PATCH</c>
<c>Support TBD.</c>
</texttable>
<t>Clients MUST be capable of recognizing and prepared to process any standard HTTP status
code, as defined in <xref target="RFC7235"/></t>
</section>
<section title="Service Discovery">
<t>This specification requires that a implementation MUST publish an Atom Service Document
that describes the set of cyber security information sharing feeds that are provided.
<vspace blankLines="1"/> The service document SHOULD be discoverable via the
organization's Web home page or another well-known public resource. </t>
<section title="Workspaces">
<t>The service document MAY include multiple workspaces. Any producer providing both
public feeds and private consortium feeds MUST place these different classes of feeds
into different workspaces, and provide appropriate descriptions and naming conventions
to indicate the intended audience of each workspace.</t>
</section>
<section title="Collections">
<t>An implementation MAY provide any number of collections within a given Workspace. It is
RECOMMENDED that each collection appear in only a single Workspace. It is RECOMMENDED
that at least one collection be provided that accepts new incident reports from users.
At least one collection MUST provide a feed of incident information for which the
content model for the entries uses the IODEF schema. The title of this collection SHOULD
be "Incidents". </t>
</section>
<section title="Service Document Security">
<t>Access to the service document MUST be protected via server-authenticated TLS and a
server-side certificate. <vspace blankLines="1"/> When deploying a service document for
use by a closed consortium, the service document MAY also be digitally signed and/or
encrypted, using XML DigSig and/or XML Encryption, respectively. </t>
</section>
</section>
<section title="Category Mapping" anchor="category-mapping">
<t>This section defines normative requirements for mapping IODEF metadata to corresponding
Atom category elements. (todo: decide between IANA registration of scheme, or use a full
URI). </t>
<section title="Collection Category">
<t>An Atom collection MAY hold entries from one or more categories. The collection
category set MUST contain at least the union of all the member entry categories. A
collection MAY have additional category metadata that are unique to the collection, and
not applicable to any individual member entry. A collection containing IODEF incident
content MUST contain at least two <category> elements. One category MUST be
specified with the value of the "scheme" attribute as "restriction". One category MUST
be specified with the value of the "scheme" attribute as "purpose". The value of the
"fixed" attribute for both of these category elements MUST be "yes". When the category
scheme="restriction", the allowable values for the "term" attribute are constrained as
per section 3.2 of IODEF, e.g. public, need-to-know, private, default. When the category
scheme="purpose", the allowable values for the "term" attribute are constrained as per
section 3.2 of IODEF, e.g. traceback, mitigation, reporting, other. </t>
</section>
<section title="Entry Category">
<t>An Atom entry containing IODEF content MUST contain at least two <category>
elements. One category MUST be specified with the value of the "scheme" attribute as
"restriction". One category MUST be specified with the value of the "scheme" attribute
as "purpose". When the category scheme="restriction", the value of the "term" attribute
must be exactly one of ( public, need-to-know, private, default). When the category
scheme="purpose", the value of the "term" attribute must be exactly one of (traceback,
mitigation, reporting, other). When the purpose is "other".... <vspace blankLines="1"/>
Any member entry MAY have any number of additional categories. </t>
</section>
</section>
<section title="Entry ID">
<t>The ID element for an Atom entry SHOULD be established via the concatenation of the value
of the name attribute from the IODEF <IncidentID> element and the corresponding
value of the <IncidentID> element. This requirement ensures a simple and direct
one-to-one relationship between an IODEF incident ID and a corresponding Feed entry ID and
avoids the need for any system to maintain a persistent store of these identity mappings.
<vspace blankLines="1"/> (todo: Note that this implies a constraint on the IODEF
document that is more restrictive than the current IODEF schema. IODEF section 3.3
requires only that the name be a STRING type. Here we are stating that name must be an
IRI. Possible request to update IODEF to constrain, or to support a new element or
attribute). </t>
</section>
<section title="Entry Content">
<t>The <content> element of an Atom <entry> SHOULD include an IODEF document.
The <entry> element SHOULD include an appropriate XML namespace declaration for the
IODEF schema. If the content model of the <entry> element does not follow the IODEF
schema, then the <entry> element MUST include an appropriate XML namespace
declaration. <vspace blankLines="1"/> A client MAY ignore content that is not using the
IODEF schema. </t>
</section>
<section title="Link Relations">
<t> In addition to the standard Link Relations defined by the Atom specification, this
specification defines the following additional Link Relation terms, which are introduced
specifically in support of the Resource-Oriented Lightweight Information Exchange
protocol. </t>
<texttable anchor="link-relations-table"
title="Link Relations for Resource-Oriented Lightweight Indicator Exchange">
<ttcol align="left">Name</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Conformance</ttcol>
<c>service</c>
<c>Provides a link to an atom service document associated with the collection feed.</c>
<c>MUST</c>
<c>search</c>
<c>Provides a link to an associated Open Search document that describes a URL template for
search queries.</c>
<c>MUST</c>
<c>history</c>
<c>Provides a link to a collection of zero or more historical entries that are associated
with the resource.</c>
<c>MUST</c>
<c>incidents</c>
<c>Provides a link to a collection of zero or more instances of incident representations
associated with the resource.</c>
<c>MUST</c>
<c>indicators</c>
<c>Provides a link to a collection of zero or more instances of cyber security indicators
that are associated with the resource.</c>
<c>MUST</c>
<c>information</c>
<c>Provides a link to a collection of zero or more instances of cyber security information
that is associated with the resource.</c>
<c>MUST</c>
<c>evidence</c>
<c>Provides a link to a collection of 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.</c>
<c>SHOULD</c>
<c>campaign</c>
<c>Provides a link to a collection of zero or more resources that provides a
representation of the associated cyber attack campaign.</c>
<c>SHOULD</c>
<c>attacker</c>
<c>Provides a link to a collection of zero or more resources that provides a
representation of the attacker.</c>
<c>SHOULD</c>
<c>vector</c>
<c>Provides a link to a collection of zero or more resources that provides a
representation of the method used by the attacker.</c>
<c>SHOULD</c>
<c>assessments</c>
<c>Provides a link to a collection of zero or more resources that represent the results of
executing a benchmark.</c>
<c>SHOULD</c>
<c>reports</c>
<c>Provides a link to a collection of zero or more resources that represent RID
reports.</c>
<c>SHOULD</c>
<c>traceRequests</c>
<c>Provides a link to a collection of zero or more resources that represent RID
traceRequests.</c>
<c>SHOULD</c>
<c>investigationRequests</c>
<c>Provides a link to a collection of zero or more resources that represent RID
investigationRequests.</c>
<c>SHOULD</c>
</texttable>
<t> Unless specifically registered with IANA these short names MUST be fully qualified via
concatenation with a base-uri. An appropriate base-uri could be established via agreement
amongst the members of an information sharing consortium. For example, the
rel="indicators" relationship would become
rel="http://www.example.org/rolie/incidents/relationships/indicators." </t>
<section title="Additional Link Relation Requirements" anchor="link-rel-notes">
<t> An IODEF document that is carried in an Atom Entry SHOULD NOT contain a
<relatedActivity> element. Instead, the related activity SHOULD be available via a
link rel=related. <vspace blankLines="1"/> An IODEF document that is carried in an Atom
Entry SHOULD NOT contain a <history> element. Instead, the related history SHOULD
be available via a link rel="history" (todo: or a fully qualified link rek name). The
associated href MAY leverage OpenSearch to specify the required query. <vspace
blankLines="1"/> An Atom Entry MAY include additional link relationships not specified
here. If a client encounters a link relationship of an unknown type the client MUST
ignore the offending link and continue processing the remaining resource representation
as if the offending link element did not appear. </t>
</section>
</section>
<section title="Member Entry Forward Security">
<t>As described in Authorization Policy Enforcement a RESTful model for cyber security
information sharing requires that all of the required security enforcement for feeds and
entries MUST be enforced at the source system, at the point the representation of the
given resource(s) is created. A provider SHALL NOT return any feed content or member entry
content for which the client identity has not been specifically authenticated, authorized,
and audited. <vspace blankLines="1"/> Sharing communities that have a requirement for
forward message security (such that client systems are required to participate in
providing message level security and/or distributed authorization policy enforcement),
MUST use the RID schema as the content model for the member entry <content> element. </t>
</section>
<section title="Date Mapping">
<t>The Atom feed <updated> element MUST be populated with the current time at the
instant the feed representation was generated. The Atom entry <published> element
MUST be populated with the same time value as the <reportTime> element from the
IODEF document. </t>
</section>
<section title="Search">
<t> Implementers MUST support <xref target="opensearch">OpenSearch 1.1</xref> as the
mechanism for describing how clients may form search requests. <vspace blankLines="1"/>
Implementers MUST provide a link with a relationship type of "search". This link SHALL
return an Open Search Description Document as defined in OpenSearch 1.1. <vspace
blankLines="1"/> Implementers MUST support an OpenSearch 1.1 compliant search URL
template that enables a search query via Atom Category, including the scheme attribute and
terms attribute as search parameters. <vspace blankLines="1"/> Implementers SHOULD support
search based upon the IODEF AlternativeID class as a search parameter. <vspace
blankLines="1"/> Implementers SHOULD support search based upon the four timestamp
elements of the IODEF Incident class: <startTime>, <EndTime>,
<DetectTime>, and <ReportTime>. <vspace blankLines="1"/> Implementers MAY
support additional search capabilities based upon any of the remaining elements of the
IODEF Incident class, including the <Description> element. <vspace blankLines="1"/>
Collections that support use of the RID schema as a content model in the Atom member entry
<content> element (e.g. in a report resource representation reachable via the
"report" link relationship) MUST support search operations that include the RID
MessageType as a search parameter, in addition to the aforementioned IODEF schema
elements, as contained within the <ReportSchema> element. <vspace blankLines="1"/>
Implementers MUST fully qualify all OpenSearch URL template parameter names using the
defined IODEF or RID XML namespaces, as appropriate. </t>
</section>
<section title="/ (forward slash) Resource URL" anchor="rid-ref">
<t>The "/" resource MAY be provided for compatibility with existing deployments that are
using <xref target="RFC6546"> Transport of Real-time Inter-network Defense (RID) Messages
over HTTP/TLS</xref>. Consistent with RFC6546 errata, a client requesting a GET on "/"
MUST receive an HTTP status code 405 Method Not Allowed. An implementation MAY provide
full support for RFC6546 such that a POST to "/" containing a recognized RID message type
just works. Alternatively, a client requesting a POST to "/" MAY receive an HTTP status
code 307 Temporary Redirect. In this case, the location header in the HTTP response will
provide the URL of the appropriate RID endpoint, and the client may repeat the POST method
at the indicated location. This resource could also leverage the new draft by reschke that
proposes HTTP status code 308 (cf: draft-reschke-http-status-308-07.txt). </t>
</section>
</section>
<section title="Security Considerations TODO" anchor="sec-security">
<t>This document defines a resource-oriented approach to lightweight information exchange
using HTTP, TLS, Atom Syndicate Format, and Atom Publishing Protocol. As such, implementers
must understand the security considerations described in those specifications. <vspace
blankLines="1"/> In addition, there are a number of additional security considerations
that are unique to this specification. <vspace blankLines="1"/> The approach described
herein is based upon all policy enforcements being implemented at the point when a resource
representation is created. As such, producers sharing cyber security information using this
specification must take care to authenticate their HTTP clients using a suitably strong user
authentication mechanism. Sharing communities that are exchanging information on well-known
indicators and incidents for purposes of public education may choose to rely upon, e.g. HTTP
Authentication, or similar. However, sharing communities that are engaged in sensitive
collaborative analysis and/or operational response for indicators and incidents targeting
high value information systems should adopt a suitably stronger user authentication
solution, such as TLS client certificates, or a risk-based or multi-factor approach. In
general, trust in the sharing consortium will depend upon the members maintaining adequate
user authentication mechanisms. <vspace blankLines="1"/> Collaborating consortiums may
benefit from the adoption of a federated identity solution, such as those based upon <xref
target="SAML-core">SAML-core</xref> and <xref target="SAML-bind">SAML-bind</xref> and
<xref target="SAML-prof">SAML-prof</xref> for Web-based authentication and
cross-organizational single sign-on. Dependency on a trusted third party identity provider
implies that appropriate care must be exercised to sufficiently secure the Identity
provider. Any attacks on the federated identity system would present a risk to the CISRT, as
a relying party. Potential mitigations include deployment of a federation-aware identity
provider that is under the control of the information sharing consortium, with suitably
stringent technical and management controls. <vspace blankLines="1"/> Authorization of
resource representations is the responsibility of the source system, i.e. based on the
authenticated user identity associated with an HTTP(S) request. The required authorization
policies that are to be enforced must therefore be managed by the security administrators of
the source system. Various authorization architectures would be suitable for this purpose,
such as <eref target="http://csrc.nist.gov/groups/SNS/rbac/">RBAC</eref> and/or ABAC, as
embodied in <xref target="XACML">XACML</xref>. In particular, implementers adopting XACML
may benefit from the capability to represent their authorization policies in a standardized,
interoperable format. <vspace blankLines="1"/> Additional security requirements such as
enforcing message-level security at the destination system could supplement the security
enforcements performed at the source system, however these destination-provided policy
enforcements are out of scope for this specification. Implementers requiring this capability
should consider leveraging, e.g. the <RIDPolicy> element in the RID schema. Refer to
RFC6545 section 9 for more information. <vspace blankLines="1"/> When security policies
relevant to the source system are to be enforced at both the source and destination systems,
implementers must take care to avoid unintended interactions of the separately enforced
policies. Potential risks will include unintended denial of service and/or unintended
information leakage. These problems may be mitigated by avoiding any dependence upon
enforcements performed at the destination system. When distributed enforcement is
unavoidable, the usage of a standard language (e.g. XACML) for the expression of
authorization policies will enable the source and destination systems to better coordinate
and align their respective policy expressions. <vspace blankLines="1"/> Adoption of the
information sharing approach described in this document will enable users to more easily
perform correlations across separate, and potentially unrelated, cyber security information
providers. A client may succeed in assembling a data set that would not have been permitted
within the context of the authorization policies of either provider when considered
individually. Thus, providers may face a risk of an attacker obtaining an access that
constitutes an undetected separation of duties (SOD) violation. It is important to note that
this risk is not unique to this specification, and a similar potential for abuse exists with
any other cyber security information sharing protocol. However, the wide availability of
tools for HTTP clients and Atom feed handling implies that the resources and technical
skills required for a successful exploit may be less than it was previously. This risk can
be best mitigated through appropriate vetting of the client at account provisioning time. In
addition, any increase in the risk of this type of abuse should be offset by the
corresponding increase in effectiveness that this specification affords to the defenders.
<vspace blankLines="1"/> While it is a goal of this specification to enable more agile
cyber security information sharing across a broader and varying constituency, there is
nothing in this specification that necessarily requires this type of deployment. A cyber
security information sharing consortium may chose to adopt this specification while
continuing to operate as a gated community with strictly limited membership. </t>
</section>
<section title="IANA Considerations TODO" anchor="sec-iana">
<t>TODO.</t>
</section>
<section title="Acknowledgements" anchor="acknowledgements">
<t>The author gratefully acknowledges the valuable contributions of Tom Maguire, Kathleen
Moriarty, and Vijayanand Bharadwaj. These individuals provided detailed review comments on
earlier drafts, and many suggestions that have helped to improve this document .</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.7235" ?>
<?rfc include="reference.RFC.4287" ?>
<?rfc include="reference.RFC.5005" ?>
<?rfc include="reference.RFC.5023" ?>
<?rfc include="reference.RFC.5070" ?>
<?rfc include="reference.RFC.6545" ?>
<reference anchor="opensearch"
target="http://www.opensearch.org/Specifications/OpenSearch/1.1">
<front>
<title>OpenSearch 1.1 draft 5 specification</title>
<author initials="D." surname="Clinton" fullname="Dewitt Clinton">
<organization abbrev="OpenSearch"> OpenSearch Community </organization>
</author>
<date year="2011"/>
</front>
</reference>
<reference anchor="SAML-core"
target="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">
<front>
<title>Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)
V2.0 </title>
<author initials="S." surname="Cantor" fullname="Scott Cantor">
<organization/>
</author>
<author initials="J." surname="Kemp" fullname="John Kemp">
<organization/>
</author>
<author initials="R." surname="Philpott" fullname="Rob Philpott">
<organization/>
</author>
<author initials="E." surname="Mahler" fullname="Eve Mahler">
<organization/>
</author>
<date day="15" month="March" year="2005"/>
</front>
<seriesInfo name="OASIS Standard" value=""/>
</reference>
<reference anchor="SAML-prof"
target="http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf">
<front>
<title>Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0</title>
<author initials="J." surname="Hughes" fullname="John Hughes">
<organization/>
</author>
<author initials="S." surname="Cantor" fullname="Scott Cantor">
<organization/>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization/>
</author>
<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
<organization/>
</author>
<author initials="P." surname="Mishra" fullname="Prateek Mishra">
<organization/>
</author>
<author initials="R." surname="Philpott" fullname="Rob Philpott">
<organization/>
</author>
<author initials="E." surname="Mahler" fullname="Eve Mahler">
<organization/>
</author>
<date day="15" month="March" year="2005"/>
</front>
<seriesInfo name="OASIS Standard" value=""/>
</reference>
<reference anchor="SAML-bind"
target="http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf">
<front>
<title>Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 </title>
<author initials="S." surname="Cantor" fullname="Scott Cantor">
<organization/>
</author>
<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
<organization/>
</author>
<author initials="J." surname="Kemp" fullname="John Kemp">
<organization/>
</author>
<author initials="R." surname="Philpott" fullname="Rob Philpott">
<organization/>
</author>
<author initials="E." surname="Mahler" fullname="Eve Mahler">
<organization/>
</author>
<date day="15" month="March" year="2005"/>
</front>
<seriesInfo name="OASIS Standard" value=""/>
</reference>
</references>
<references title="Informative References">
<reference anchor="XACML"
target="http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf">
<front>
<title>eXtensible Access Control Markup Language (XACML) Version 3.0</title>
<author initials="E." surname="Rissanen" fullname="Erik Rissanen">
<organization/>
</author>
<date day="10" month="August" year="2010"/>
</front>
</reference>
<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">
<front>
<title>Architectural Styles and the Design of Network-based Software Architectures</title>
<author initials="R." surname="Fielding" fullname="Roy Thomas Fielding">
<organization abbrev="UCI"> University of California, Irvine; Department of Information
and Computer Science </organization>
</author>
<date year="2000"/>
</front>
<format type="text/html" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm"
octets="7287"/>
</reference>
<?rfc include="reference.RFC.6546" ?>
</references>
<section title="Change Tracking" anchor="delta">
<t>Changes since draft-field-mile-rolie-01 version, December, 2015 to May 27, 2016: <list
style="symbols">
<t>Spun section 4 and some related contextual information into its own document see
TODO:Add reference </t>
<t>Recast document into a more general use perspective. The implication of CSIRTs as the
defacto end-user has been removed where ever possible. All of the original CSIRT based
use cases remain completely supported by this document, it has been opened up to
supported many other use cases.</t>
<t>Changed the content model to broaden support of representation</t>
<t>Edited and rewrote much of sections 1,2 and 3 in order to accomplish a broader scope
and greater readability</t>
<t>Removed any requirements from the Background section and, if not already stated, placed
them in the requirements section</t>
<t>Re-formatted the requirements section to make it clearer that it contains the
lions-share of the requirements of the specification</t>
</list>
</t>
<t>Changes made in draft-ietf-mile-rolie-01 since draft-field-mile-rolie-02 version, August
15, 2013 to December 2, 2015: <list style="symbols">
<t>Added section specifying the use of RFC5005 for Archive and Paging of feeds. See: <xref
target="normative-archive-page"/>
</t>
<t>Added section describing use of atom categories that correspond to IODEF expectation
class and impact classes. See: <xref target="normative-expectation-impact"/>
</t>
<t>Dropped references to adoption of a MILE-specific HTTP media type parameter.</t>
<t>Updated IANA Considerations section to clarify that no IANA actions are required.</t>
</list>
</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 07:18:59 |