One document matched: draft-ietf-mile-rolie-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="info" docName="draft-ietf-mile-rolie-01"> <!-- this is actually -03, and intended for WGLC -->
<!-- Ready for review. -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="ROLIE">Resource-Oriented Lightweight Indicator 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>
<date month="December" day="2" year="2015"/>
<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, a CSIRT or other stakeholder may share and exchange representations
of cyber security incidents, indicators, and other related information as Web-addressable resources.
The transport protocol binding is specified as HTTP(S) with a MIME media type of Atom+XML.
An appropriate set of link relation types specific to cyber security information sharing is defined.
The resource representations leverage the existing <xref target="RFC5070">IODEF</xref> and
<xref target="RFC6545">RID</xref>
specifications as appropriate. 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>
</abstract>
</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. The resource representations leverage the existing <xref target="RFC5070">IODEF</xref>
and <xref target="RFC6545">RID</xref>
specifications 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. Using this approach, a CSIRT or other stakeholder may exchange cyber
security incident and/or indicator information as Web-addressable resources.
<vspace blankLines="1"/>
The goal of this specification is to define a loosely-coupled, agile approach to cyber security
situational awareness. This approach has architectural advantages for some use case scenarios,
such as when a CSIRT
or other stakeholder is required to share cyber security information broadly (e.g., at internet scale), or
when an information sharing consortium requires support for asymmetric interactions amongst their stakeholders.
<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 Internet security threats are evolving ever more rapidly, and are
becoming ever more sophisticated than before. The threat actors are frequently distributed
and are not constrained to operating within a fixed, closed consortium.
The technical skills needed to perform effective analysis of a security incident,
or to even recognize an indicator of compromise are already
specialized and relatively scarce. As threats continue to evolve, even an established
network of CSIRT may find that it does not always have all of the skills and knowledge required to
immediately identify and respond to every new incident.
Effective identification of and response to a sophisticated, multi-stage attack frequently depends upon cooperation and
collaboration, not only amongst the defending CSIRTs, but also amongst other stakeholders,
including, potentially, individual 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 appropriately combat the evolving threats, the defending CSIRTs should be enabled to
operate in a more agile manner, sharing selected cyber security information proactively, if and as appropriate.
<vspace blankLines="1"/>
For example, a CSIRT analyst would benefit by having the ability to search a comprehensive collection of indicators
that has 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, 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. </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
CSIRTs participating in an information sharing consortium is limited to a relatively
smaller 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, a
CSIRT or other organization can more quickly and easily share relevant incident and
indicator information with a much larger and potentially more diverse constituency. A
client 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 CSIRT 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 CSIRT can enable any
authenticated and authorized client that is a member of the sharing community to quickly and easily navigate through any of the
cyber security information that that provider is willing to share. An authenticated
and authorized analyst may then make HTTP(S) requests to collect incident and indicator
information known at one CSIRT with threat actor data being made available from
another CSIRT. 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 CSIRTs and their stakeholders can be greatly improved. </t>
</section>
</section>
</section>
<section title="Authentication of Users" anchor="authN">
<t> In the store-and-forward, message-based model for information sharing client
authentication is provided via a Public Key Infrastructure (PKI) -based trust and mutually authenticated TLS between the
messaging system endpoints. There is no provision to support authentication of a client by
another means. As a result, participation in the sharing community is limited to those
organizations that have sufficient resources and capabilities to manage a PKI. <vspace
blankLines="1"/> A CSIRT may apply XML Security to the content of a message, however the
contact information provided within the message body represents a self-asserted identity,
and there is no guarantee that the contact information will be recognized by the peer. As
a result, the audit trail and the granularity of any authorization policies is limited to
the identity of the peer CSIRT organization. <vspace blankLines="1"/> A CSIRT implementing
this specification MUST implement server-authenticated TLS. The CSIRT may choose to
authenticate its client users via any suitable authentication scheme that can be
implemented via HTTP(S). A participating CSIRT MAY choose to support more than one
authentication method. Support for use of a Federated Identity approach is RECOMMENDED.
Establishing a specific end user identity prior to processing a request is RECOMMENDED.
Doing so will enable the source system to maintain a more complete audit trail of exactly
what cyber security incident and indicator information has been shared, when, and with
whom. </t>
</section>
<section title="Authorization Policy Enforcement" anchor="az-policy">
<t>A key aspect of any cyber security information sharing arrangement is assigning the
responsibility for authorization policy enforcement. The authorization policy must be
enforced either at the destination system, or the source system, or both. The following
sections discuss these alternatives in greater detail.</t>
<section title="Enforcement at Destination System">
<t> The store-and-forward, message-based approach to cyber security information sharing
requires that the origin system delegate authorization policy enforcement to the
destination system. The origin system may leverage XML Encryption and DigitalSignature
to protect the message content. In addition, the origin system assigns a number of
policy-related attribute values, including a "restriction" attribute, before the message
is sent. These labels indicate the sender's expectation for confidentiality enforcement
and appropriate handling at the destination. Section 9.1 of RFC6545 provides specific guidance
to implementers on use of the XML security standards in order to achieve the required levels of
security for the exchange of incident information.
<vspace blankLines="1"/>
Once the message has been received at the
destination system, the XML encryption and digital signature protections on the message
will be processed, and based upon the pre-established PKI-based trust relationships, the
message content is validated and decrypted. Typical implementations will then pass the
cleartext data to an internal Incident Handling System (IHS) for further review and/or
action by a human operator or analyst. Regardless of where in the deployment
architecture the XML message-level security is being handled, eventually the message
content will be made available as cleartext for handling by human systems analysts and
other operational staff. <vspace blankLines="1"/> The authorization policy enforcement
of the message contents must then be provided by the destination IHS. It is the
responsibility of the destination system to honor the intent of the policy restriction
labels assigned by the origin system. Ideally, these policy labels would serve as part
of a distributed Mandatory Access Control scheme. However, in practice a typical IHS
will employ a Discretionary Access Control (DAC) model rather than a MAC model and so
the policy related attributes are defined to represent handling "hints" and provide no
guarantee of enforcement at the destination. <vspace blankLines="1"/> As a result,
ensuring that the destination system or counterparty will in fact correctly enforce the
intended authorization policies becomes a key issue when entering into any information
sharing agreements. The origin CSIRT must accept a non-zero risk of information leakage,
and therefore must rely upon legal recourse as a compensating control. Establishing such
legal sharing agreements can be a slow and difficult process, as it assumes a high level
of trust in the peer, with respect to both intent and also technical capabilities. </t>
</section>
<section title="Enforcement at Source System" anchor="az-enforcement-at-source">
<t> In this model, the required authorization policy enforcements are implemented entirely
within the source system. Enforcing the required authorization policy controls at the
source system eliminates the risk of subsequent information leakage at the destination
system due to inadequate or incomplete implementation of the expected controls. The
destination system is not expected to perform any additional authorization enforcements.
Authorization enforcement at the source system may be based on, e.g. Role-based Access
Controls applied in the context of an established user identity. The source system may
use any appropriate authentication mechanism in order to determine the user identity of
the requestor, including, e.g. federated identity. An analyst or operator at a CSIRT may
request specific information on a given incident or indicator from a peer CSIRT, and the
source system will return a suitable representation of that resource based upon the
specific role of the requestor. A different authenticated user (perhaps from the same
destination CSIRT) may receive a different representation of the same resource, based
upon the source system applying suitable Role-based Access Control policy enforcements
for the second user identity.
<vspace blankLines="1"/>
Consistent with <xref target="RFC2616">HTTP</xref> a user's
request MAY be denied with a resulting HTTP status code value of 4xx such as 401 Unauthorized,
403 Forbidden, or 404 Not Found, or 405 Method Not Allowed, if and as appropriate.
</t>
</section>
</section>
</section>
<section title="RESTful Usage Model" anchor="usage-model">
<t>
This section describes the basic use of <xref target="RFC4287">Atom Syndication Format</xref> and
<xref target="RFC5023">Atom Publishing Protocol</xref> as a RESTful transport binding and
dynamic discovery protocol, respectively, for cyber security information sharing.
<vspace blankLines="1"/>
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.
</t>
<section title="Dynamic Service Discovery versus Static URL Template" anchor="dyn-v-static">
<t>
In order to specify a protocol for cyber security information sharing using the REST architectural style
it is necessary to define the set of resources to be modeled, and how these resources are related.
Based on this interface contract, clients will then interact with the REST service by navigating the
modeled entities, and their relationships. The interface contract between the client and the server may
either be statically bound or dynamically bound.
<vspace blankLines="1"/>
In the statically bound case, the clients have a priori knowledge of the resources that are supported.
In the REST architectural style this static interface contract takes the form of a URL template.
This approach is not appropriate for the cyber security information sharing domain for at least two reasons.
<vspace blankLines="1"/>
First, there is no standard for a cyber security domain model. While information security practitioners can
generally agree on some of the basic concepts that are important to modeling the cyber security domain --
such as "indicator,” "incident,” or “attacker,” -- there is no single domain model that can been referenced
as the basis for specifying a standardized RESTful URI Template. Second, the use of static URL templates creates
a tighter coupling between the client implementation and the server implementation. Security threats on the
internet are evolving ever more rapidly, and it will never be possible to establish a statically defined resource
model and URL Template. Even if there were an initial agreement on an appropriate URL template, it would eventually
need to change. If and when a CSIRT finds that it needs to change the URL template, then any existing deployed clients
would need to be upgraded.
<vspace blankLines="1"/>
Thus, rather than attempting to define a fixed set of resources via a URI Template, this document has instead specified
an approach based on dynamic discovery of resources via an Atom Publishing Protocol Service Document. By using this approach,
it is possible to standardize the RESTful usage model, without needing to standardize on the definitions of specific,
strongly-typed resources. A client can dynamically discover what resources are provided by a given CSIRT, and then
navigate that domain model accordingly A specific server implementation may still embody a particular URL template,
however the client does not need a priori knowledge of the format of the links, and the URL itself is effectively opaque
to the client. Clients are not bound to any particular server’s interface.
<vspace blankLines="1"/>
The following paragraphs provide a number of non-normative examples to illustrate the use of Atom Publishing Protocol for basic
cyber security information sharing service discovery, as well as the use of Atom Syndication Format as a mechanism to
publish cyber security information feeds.
<vspace blankLines="1"/>
Normative requirements are defined below, in <xref target="normative-requirements"></xref>.
</t>
</section>
<section title="Non-Normative Examples" anchor="non-norm-ex">
<section title="Service Discovery" anchor="svc-doc">
<t>This section provides a non-normative example of a client doing service discovery.
<vspace blankLines="1"/>
An Atom service document enables a client to dynamically discover what feeds a particular publisher makes available.
Thus, a CSIRT may use an Atom service document to enable clients of the CSIRT to determine what specific cyber security information
the CSIRT makes available to the community. The service document could be made available at any well known location, such as via a link
from the CSIRT's home page. One common technique is to include a link in the <HEAD> section of the organization's
home page, as shown below:
<vspace blankLines="1"/>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example of bootstrapping Service Document discovery:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
<link rel="introspection" type="application/atomsvc+xml" title="Atom Publishing Protocol Service Document" href="/csirt/svcdoc.xml" />
]]></artwork>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>A client may then format an HTTP GET request to retrieve the service document:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
GET /csirt/svcdoc.xml
Host: www.example.org
Accept: application/atomsvc+xml
]]></artwork>
<postamble>Notice the use of the HTTP Accept: request header, indicating the MIME type for Atom service discovery.
The response to this GET request will be an XML document that contains information on the specific
feed collections that are provided by the CSIRT.
</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET response:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:09:11 GMT
Content-Length: 570
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">Incidents</atom:title>
<collection href="http://example.org/csirt/incidents">
<atom:title type="text">Incidents Feed</atom:title>
<accept>application/atom+xml; type=entry</accept>
</collection>
</workspace>
</service>
]]></artwork>
<postamble>This simple Service Document example shows that this CSIRT provides one workspace, named "Incidents." Within that workspace, the CSIRT makes
one feed collection available. When attempting to GET or POST entries to that feed collection, the client must indicate a content type of application/atom+xml.
</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>A CSIRT may also offer a number of different feeds, each containing different types of cyber security information.
In the following example, the feeds have been categorized. This categorization will help the clients to decide which feeds
will meet their needs.
</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:10:11 GMT
Content-Length: 1912
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>
<atom:title>Cyber Security Information Sharing</atom:title>
<collection href="http://example.org/csirt/public/indicators" >
<atom:title>Public Indicators</atom:title>
<categories fixed="yes">
<atom:category scheme="http://example.org/csirt/restriction" term="public" />
<atom:category scheme="http://example.org/csirt/purpose" term="reporting" />
</categoies>
<accept>application/atom+xml; type=entry</accept>
</collection>
<collection href="http://example.org/csirt/public/incidents" >
<atom:title>Public Incidents</atom:title>
<categories fixed="yes">
<atom:category scheme="http://example.org/csirt/restriction" term="public" />
<atom:category scheme="http://example.org/csirt/purpose" term="reporting" />
</categoies>
<accept>application/atom+xml; type=entry</accept>
</collection>
</workspace>
<workspace>
<atom:title>Private Consortium Sharing</atom:title>
<collection href="http://example.org/csirt/private/incidents" >
<atom:title>Incidents</atom:title>
<accept>application/atom+xml;type=entry</accept>
<categories fixed="yes">
<atom:category scheme="http://example.org/csirt/purpose" term="traceback, mitigation, reporting" />
<atom:category scheme="http://example.org/csirt/restriction" term="private, need-to-know" />
</categories>
</collection>
</workspace>
</service>
]]></artwork>
<postamble>In this example, the CSIRT is providing a total of three feed collections, organized into two different workspaces.
The first workspace contains two feeds, consisting of publicly available indicators and publicly available incidents, respectively.
The second workspace provides one additional feed, for use by a sharing consortium. The feed contains incident information containing
entries related to three purposes: traceback, mitigation, and reporting. The entries in this feed are categorized with a restriction of either
"Need-to-Know" or "private". An appropriately authenticated and authorized client may then proceed to make GET requests for one or more
of these feeds. The publicly provided incident information may be accessible with or without authentication. However, users accessing
the feed targeted to the private sharing consortium would be expected to authenticate, and appropriate authorization policies would
subsequently be enforced by the feed provider. </postamble>
</figure>
</t>
</section>
<section title="Feed Retrieval" anchor="feed-doc">
<t>
This section provides a non-normative example of a client retrieving an incident feed.
<vspace blankLines="1"/>
Having discovered the available cyber security information sharing feeds, an authenticated and authorized client who is a member of the
private sharing consortium may be interested in receiving the feed of known incidents.
The client may retrieve this feed by performing an HTTP GET operation on the indicated URL.
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET request for a Feed:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
GET /csirt/private/incidents
Host: www.example.org
Accept: application/atom+xml
]]></artwork>
<postamble>The corresponding HTTP response would be an XML document containing the incidents feed:
</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET response for a Feed:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:20:11 GMT
Content-Length: 2882
Content-Type: application/atom+xml;type=feed;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns: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 xml:lang="en-US">http://www.example.org/csirt/private/incidents</id>
<title type="text" xml:lang="en-US">Atom formatted representation of a feed of IODEF documents</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/private/incidents" rel="self"/>
<entry>
<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"/> <!-- by convention -->
<link href="http://www.example.org/csirt/private/incidents/123456" rel="alternate"/> <!-- required by Atom spec -->
<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" />
<summary>A short description of this incident, extracted from the IODEF Incident class, <description> element. </summary>
</entry>
<entry>
<!-- ...another entry... -->
</entry>
</feed>
]]></artwork>
<postamble>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 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
incident. This example provides a RESTful alterntive to the RID investigation request messaage, as described in
sections 6.1 and 7.2 of RFC6545.
</postamble>
</figure>
</t>
</section>
<section title="Entry Retrieval" anchor="entry-doc">
<t>
This section provides a non-normative example of a client retrieving an incident as an Atom entry.
<vspace blankLines="1"/>
Having retrieved the feed of interest, the client may then decide based on the description and/or category information that one of the
entries in the feed is of further interest. The client may retrieve this incident Entry by performing an HTTP GET operation on the
indicated URL.
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET request for an Entry:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
GET /csirt/private/incidents/123456
Host: www.example.org
Accept: application/atom+xml
]]></artwork>
<postamble>The corresponding HTTP response would be an XML document containing the incident:
</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET response for an Entry:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:30:11 GMT
Content-Length: 4965
Content-Type: application/atom+xml;type=entry;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<entry>
<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"/> <!-- by convention -->
<link href="http://www.example.org/csirt/private/incidents/123456" rel="alternate"/> <!-- required by Atom spec -->
<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" />
<summary>A short description of this incident, extracted from the IODEF Incident class, <description> element. </summary>
<!-- Refer to section 5.9 for the list of supported (cyber information-specific) link relationships -->
<!-- Typical operations that can be performed on this IODEF message include edit -->
<link href="http://www.example.org/csirt/private/incidents/123456" rel="edit"/>
<!-- the next and previous are just sequential access, may not map to anything related to this IODEF Incident ID -->
<link href="http://www.example.org/csirt/private/incidents/123457" rel="next"/>
<link href="http://www.example.org/csirt/private/incidents/123455" rel="previous"/>
<!-- 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"/>
<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">
<!-- Note that the ID is assigned using a namespace that is our base URL, so that it can also be leveraged as an Atom link -->
<iodef:IncidentID name="http://www.example.org/csirt/private/incidents">123456</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>
Host involved in DoS attack
</iodef:Description>
<iodef:Assessment>
<iodef:Impact completion="failed" severity="low" type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>38765</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation action="rate-limit-host" severity="high">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
</iodef:Incident>
</iodef:IODEF-Document>
</content>
</entry>
]]></artwork>
<postamble>As can be seen in the example response, above, an IODEF document is contained within the Atom <content> element.
The client may now process the IODEF document as needed.</postamble>
</figure>
</t>
<t>
Note also that, as described previously, the content of the Atom <category> element is application-defined.
In the present context, the Atom categories have been assigned based on a mapping of the <restriction> and
<purpose> attributes, as defined in the IODEF schema.
In addition, the IODEF <incidentID> element has been judiciously chosen so that the associated name attribute, as well as the
corresponding incidentID value, can be concatenated in order to easily create the corresponding <id> element for the Atom entry.
These and other mappings are normatively defined in <xref target="normative-requirements"/>, below.
<vspace blankLines="1"/>
Finally, it should be noted that in order to optimize the client experience, and avoid an additional round trip, a feed provider
may choose to include the entry content inline, as part of the feed document. That is,
an Atom <entry> element within a Feed document may contain an Atom <content> element as a child. In this
case, the client will receive the full content of the entries within the feed. The decision
of whether to include the entry content inline or to include it as a link is a design choice left to the feed provider
(e.g. based upon local environmental factors such as the number of entries contained in a feed, the available network bandwidth, the
available server compute cycles, the expected client usage patterns, etc.).
</t>
</section>
<section title="Use of Link Relations" anchor="link-relations">
<t>
As noted previously, 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.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
The following sections provide NON-NORMATIVE examples of link relation usage.
Four 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.
</t>
<section title="Use Case: Incident Sharing" anchor="info-share">
<t> This section provides a non-normative example of an incident sharing use case.
<vspace blankLines="1"/>
In this use case, a member CSIRT shares incident information with another member CSIRT in the same consortium.
The client CSIRT retreives 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.
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET response for an incident entry:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<entry>
<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"/> <!-- by convention -->
<link href="http://www.example.org/csirt/private/incidents/123456" rel="alternate"/> <!-- required by Atom spec -->
<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/1234456/relationships/history" rel="history"/>
<link href="http://www.example.org/csirt/private/incidents/1234456/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"/>
<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">123456</iodef:IncidentID>
<!-- ...additional incident data.... -->
</iodef:Incident>
</iodef:IODEF-Document>
</content>
</entry>
]]></artwork>
<postamble>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. </postamble>
</figure>
</t>
</section>
<section title="Use Case: Collaborative Investigation" anchor="collab-analysis">
<t>This section provides a non-normative example of a collaborative investigation use case.
<vspace blankLines="1"/>
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.
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET response for the service document:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
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> <!-- perhaps we should have a more specific media type -->
</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>
]]></artwork>
<postamble>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.
</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>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.
</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
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">
<title>New Investigation Request</title>
<id>http://www.example2.org/csirt/private/incidents/123456</id> <!-- id and updated not guranteed to be preserved -->
<updated>2012-08-12T11:08:22Z</updated> <!-- may want to profile that behavior in this document -->
<author><name>Name of peer CSIRT</name></author>
<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>
]]></artwork>
<postamble>The receiving CSIRT acknowledges the request with HTTP return code 201 Created.
</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble></preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
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">
<title>New Investigation Request</title>
<id>http://www.example.org/csirt/RID/InvestigationRequests/823</id> <!-- id and updated not guranteed to be preserved -->
<updated>2012-08-12T11:08:30Z</updated> <!-- may want to profile that behavior in this document -->
<published>2012-08-12T11:08:30Z</published>
<author><name>Name of peer CSIRT</name></author>
<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>
]]></artwork>
<postamble>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.
</postamble>
</figure>
</t>
</section>
<section title="Use Case: Search (Query)" anchor="search-query">
<t>This section provides a non-normative example of a search use case.
<vspace blankLines="1"/>
The following example provides a RESTful alternative to the RID Query messaage, as described in
sections 6.5 and 7.4 of RFC6545. Note that in the RESTful approach described herein there is no requirement to
define a query language specific to RID queries. Instead, CSIRTs may provide support for search operations via
existing search facilities, and advertise these capabilities via an appropriate URL template. Clients
dynamically retrieve the search description document, and invoke specific searches via an instantiated URL template.
<vspace blankLines="1"/>
An HTTP response body may include a link relationship of type "search."
This link provides a reference to an OpenSearch description document.
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<preamble>Example HTTP response that includes a "search" link:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:20:11 GMT
Content-Length: nnnn
Content-Type: application/atom+xml;type=feed;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns: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">
<link href="http://www.example.org/opensearchdescription.xml" rel="search"
type="application/opensearchdescription+xml"
title="CSIRT search facility" />
<!-- ...other links... -->
<entry>
<!-- ...zero or more entries... -->
</entry>
</feed>
]]></artwork>
<postamble>The OpenSearch Description document contains the information needed by a client to request a search.
An example of an Open Search description document is shown below:</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title="" align="left">
<preamble>Example HTTP response that includes a "search" link:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>CSIRT search example</ShortName>
<Description>Cyber security information sharing consortium search interface</Description>
<Tags>example csirt indicator search</Tags>
<Contact>admin@example.org</Contact>
<!-- ...optionally, other elements, as per OpenSearch specification... -->
<Url type="application/opensearchdescription+xml" rel="self" template="http://www.example.com/csirt/opensearchdescription.xml"/>
<Url type="application/atom+xml" rel="results" template="http://www.example.org/csirt?q={searchTerms}&format=Atom+xml"/>
<LongName>www.example.org CSIRT search</LongName>
<Query role="example" searchTerms="incident" />
<Language>en-us</Language>
<OutputEncoding>UTF-8</OutputEncoding>
<InputEncoding>UTF-8</InputEncoding>
</OpenSearchDescription>
]]></artwork>
<postamble>The OpenSearch Description document shown above contains two <Url> elements that
contain parameterized URL templates. These templates provide a representation of how the client should
make search requests. The exact format of the query string, including the parameterization is specified
by the feed provider.</postamble>
</figure>
This OpenSearch Description Document also contains an example of a <Query> element.
Each <Query> element describes a specific search request that can be made by the client.
Note that the parameters of the <Query> element correspond to the URL template parameters.
In this way, a provider may fully describe the search interface available to the clients.
Section 5.12, below, provides specific NORMATIVE requirements for the use of Open Search.
</t>
</section>
<!-- adding new section for repository example -->
<section title="Use Case: Cyber Data Repository" anchor="cyber-repo">
<t>This section provides a non-normative example of a cyber security data repository use case.
<vspace blankLines="1"/>
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, becnmarks,
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.
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET request to a persistent repository for any resources representing Distributed Denial of Service (DDOS) attacks:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
GET /csirt/repository/ddos
Host: www.example.org
Accept: application/atom+xml
]]></artwork>
<postamble>The corresponding HTTP response would be an XML document containing the DDOS feed.
</postamble>
</figure>
<figure height="" suppress-title="false" width="" alt="" title=""
align="left">
<preamble>Example HTTP GET response for a DDOS feed:</preamble>
<artwork height="" name="" width="" type="" alt="" align="left"
xml:space="preserve"><![CDATA[
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:20:11 GMT
Content-Length: nnnn
Content-Type: application/atom+xml;type=feed;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns: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 xml:lang="en-US">http://www.example.org/csirt/repository/ddos</id>
<title type="text" xml:lang="en-US">Atom formatted representation of a feed of known ddos resources.</title>
<updated xml:lang="en-US">2012-05-04T18:13:51.0Z</updated>
<author>
<email>csirt@example.org</email>
<name>EMC CSIRT</name>
</author>
<!-- By convention there is usually a self link for the feed -->
<link href="http://www.example.org/csirt/repository/ddos" rel="self"/>
<entry>
<id>http://www.example.org/csirt/repository/ddos/123456</id>
<title>Sample DDOS Incident</title>
<link href="http://www.example.org/csirt/repository/ddos/123456" rel="self"/> <!-- by convention -->
<link href="http://www.example.org/csirt/repository/ddos/123456" rel="alternate"/> <!-- required by Atom spec -->
<link href="http://www.example.org/csirt/repository/ddos/987654" rel="related"/> <!-- link to a related DDOS resource in this repository -->
<link href="http://www.cyber-agency.gov/repository/indicators/1a2b3c" rel="related"/> <!-- link to a related DDOS resource in another repository -->
<published>2012-08-04T18:13:51.0Z</published>
<updated>2012-08-05T18:13:51.0Z</updated>
<!-- The category is based upon IODEF purpose and restriction attributes -->
<category term="traceback" scheme="purpose" label="trace back" />
<category term="need-to-know" scheme="restriction" label="need to know" />
<category term="ddos" scheme="ttp" label="tactics, techniques, and procedures"/>
<summary>A short description of this DDOS attack, extracted from the IODEF Incident class, <description> element. </summary>
</entry>
<entry>
<!-- ...another entry... -->
</entry>
</feed>
]]></artwork>
<postamble>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.
</postamble>
</figure>
Note that the provider of a persistent repostory is not obligated to follow any particular URL template scheme.
The repository available at the hypothetical provider "www.example.com" uses a different URL pattern than the hypothetical
repository available at "www.cyber-agency.gov". When a client de-references a link to resource that is located in a remote
repository the client may be challenged for authentication credentials acceptable to that provider. If the two repository
providers choose to support a federated identity scheme or some other form of single-sign-on technology, then the user experience can
be improved for interactive clients (e.g., a human user at a browser). However, this is not required and is an
implementation choice that is out of scope for this specification.
</t>
</section>
</section>
</section>
</section>
<section title=" Requirements for RESTful (Atom+xml) Binding" 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="Transport Layer Security" anchor="normative-transport-sec">
<t>Servers implementing this specification MUST support server-authenticated TLS.
<vspace blankLines="1"/>
Servers MAY support mutually authenticated TLS.</t>
</section>
<section title="Archiving and Paging" anchor="normative-archive-page">
<t>A feed may 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 may need to be divided into more managable 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.
<vspace blankLines="1"/>
Use cases that require capabilities for paging and archiving of feeds SHOULD support the mechanisms described in
<xref target="RFC5005">Feed Paging and Archiving</xref>.
</t>
</section>
<section title="Expectation and Impact Classes" anchor="normative-expectation-impact">
<t>It is frequently the case that a CSIRT 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 CSIRTs to effectively prioritize their response activity,
it is RECOMMENDED that feed implementors 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 catagories 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>Servers MUST require user authentication.
<vspace blankLines="1"/>
Servers MAY support more than one client authentication method.
<vspace blankLines="1"/>
Servers participating in an information sharing consotium 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"/>
Servers 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 IODEF schema as the content model
for the Atom Entry <content> element.
<vspace blankLines="1"/>
If the member entry content model is not IODEF, then 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="RFC2616">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="RFC2616"></xref></t>
</section>
<section title="Service Discovery">
<t>This specification requires that a CSIRT 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 CSIRT organization's Web home page or another well-known public resource.
</t>
<section title="Workspaces">
<t>The service document MAY include multiple workspaces.
Any CSIRT 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>A CSIRT 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 Indicator 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 actual cyber security event(s) that are 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>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/csirt/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 unkown 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 <xref format="title" target="az-policy">Authorization Policy Enforcement</xref> 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 CSIRT 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" anchor="sec-security">
<t>This document defines a resource-oriented approach to lightweight indicator 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"/>
As described above in the section <xref target="authN">Authentication of Users</xref>,
the approach described herein is based upon all policy enforcements being implemented at the point when a resource representation is created.
As such, CSIRTS 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"/>
As discussed above in the section <xref target="az-policy">Authorization Policy Enforcement</xref>, 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
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" anchor="sec-iana">
<t>This document does not require any actions from IANA.</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.2616" ?>
<?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="XMLencrypt" target="http://www.w3.org/TR/xmlenc-core/">
<front>
<title>XML Encryption Syntax and Processing</title>
<author initials="T." surname="Imaura" fullname="">
<organization />
</author>
<author initials="B." surname="Dillaway" fullname="">
<organization />
</author>
<author initials="E." surname="Simon" fullname="">
<organization />
</author>
<date month="December" year="2002" />
</front>
<seriesInfo name="W3C Recommendation" value="" />
</reference>
<reference anchor="XMLsig" target="http://www.w3.org/TR/xmldsig-core/">
<front>
<title>XML-Signature Syntax and Processing</title>
<author initials="M." surname="Bartel">
<organization />
</author>
<author initials="J." surname="Boyer">
<organization />
</author>
<author initials="B." surname="Fox">
<organization />
</author>
<author initials="B." surname="LaMaccia">
<organization />
</author>
<author initials="E." surname="Simon">
<organization />
</author>
<date month="June" year="2008" />
</front>
<seriesInfo name="W3C Recommendation" value="Second Edition" />
</reference>
<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.2396" ?>
<?rfc include="reference.RFC.2822" ?>
<?rfc include="reference.RFC.3339" ?>
<?rfc include="reference.RFC.3552" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.6546" ?>
</references>
<section title="Change Tracking" anchor="delta">
<t>Changes since -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>
<section title="Resource Authorization Model" anchor="xacml">
<t>As described in <xref target="az-enforcement-at-source"/> above, ROLIE assumes that all authorization policy enforcement is provided at the source server.
The implementation details of the authorization scheme chosen by a ROLIE-compliant provider are out of scope for this specification.
Implementers are free to choose any suitable authorization mechanism that is capable of fulfilling the policy enforcement requirements
relevant to their consortium and/or organization.
<vspace blankLines="1"/>
It is well known that one of the major barriers to information sharing is ensuring acceptable use of the information shared.
In the case of ROLIE, one way to lower that barrier may be to develop a XACML profile. Use of XACML would allow a ROLIE-compliant
provider to express their information sharing authorization policies in a standards-compliant, and machine-readable format.
<vspace blankLines="1"/>
This improved interoperability may, in turn, enable more agile interactions in the cyber security sharing community. For example,
a peer CSIRT, or another interested stakeholder such as an auditor, would be able to review and compare CSIRT sharing policies using
appropriate tooling.
<vspace blankLines="1"/>
The XACML 3.0 standard is based upon the notion that authorization policies are defined in terms of predicate logic expressions written against the
attributes associated with one or more of the following four entities:
<list style="symbols">
<t>SUBJECT</t>
<t>ACTION</t>
<t>RESOURCE</t>
<t>ENVIRONMENT</t>
</list>
Thus, a suitable approach to a XACML 3.0 profile for ROLIE authorization policies could begin by using the 3-tuple of
[SUBJECT, ACTION, RESOURCE] where:
<list style="symbols">
<t>SUBJECT is the suitably authenticated identity of the requestor.</t>
<t>ACTION is the associated HTTP method, GET, PUT, POST, DELETE, HEAD, (PATCH).</t>
<t>RESOURCE is an XPath expression that uniquely identifies the instance or type of the ROLIE resource being requested.</t>
</list>
Implementers who have a need may also choose to evaluate based upon the additional ENVIRONMENT factors, such as current threat level, and so on.
One could also write policy to consider the CVSS score associated with the resource, or the lifecycle phase of the resource (vulnerability
unverified, confirmed, patch available, etc.), and so on.
</t>
<t>
Having these policies expressed in a standards-compliant and machine-readable format could improve the agility and effectiveness of a cyber security
information sharing group or consortium, and enable better cyber defenses.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:18:26 |